BBB - LCD3 Cape and UDA1380 on i2s

Hello All,

I am trying to get my BeagleBone Black talking to a WaveShare UDA1380 board using I2S and I2C. I also need to have the LCD3 (Rev A1) Cape running.

I am a beginner when it comes to BBB hardware fiddling so I would appreciate some pointers.

From what I have read, the Audio Cape is compatible with the LCD3 Cape and “interfaces with the Multichannel Audio Serial Port of the AM335x via audio serial bus”. It looks like it uses I2C(19,20) as well as AUD_IN(25), AUD_OUT(28), AUD_FSX(29) and AUD_BCLK(31).

I then found these pins referenced in another post on this group

25 mcasp0_ahclkx
28 mcasp0_axr2
29 mcasp0_fsx
30 mcasp0_axr0
31 mcasp0_aclkx

So far so good, although the names are confusing (I don’t want to use the Audio Cape and was just using it as a reference point). Just compiling the info for this post is starting to make things clearer though.

The UDA1380 can be configured to use an incoming master clock, or provide the master clock. The pins (shown below) are on the WaveShare module the UDA1380 sits on. The I2C seems straight forward. I am guessing that if the BBB provided the SYSCLK, that would go to RX World Clock on the 1380 board. Then RX CLK, RX Data, RX World Select and TX Data would be connected to the BBB’s Mcasp0. This is where I get confused. Does the Audio Cape use I2S or are they names for another format (TDM ?). Does there need to be a SYSCLK?

I don’t need to use HDMI just in case that is relevant. I read that need to be disabled for one of these two capes.

Once I get the correct pins worked out, should I start learning about device trees etc, or is it something I need to compile into the kernel. I have found code for the UDA1380 in the linux kernel somewhere that defined all of the registers and settings and they seemed to match ok.

Anyhoo, any help will be appreciated. Below are some pinouts for the codec board, LCD3 cape and the Audio Cape.

UDA1380 Pinouts
Vcc
Gnd
SDA

SCL

TX Bit Clock
TX Word Select
TX Data
TX Master Clock

RX Bit CLock
RX Word Select
RX Data
RX World Clock

There is also a jumper to set the World Clock config ( Use incoming worldclock (SYSCLOCK), Output a master clock, or some something in the middle ) .

LCD3 Cap Pinout

Audio Cape Pinout

Update,

Things are starting to make more sense now. After looking at the device tree source for the audio cape, and then finding the other base source files inline, I think I am on the right track.

I am fairly sure I know how to connect it up. If I get it running I will try to post how I did it.

Of course any help on the device tree side of things will be greatly appreciated.

A late follow-up. Interesting.

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Justin Wright
Sent: 23 April 2015 00:24
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: BBB - LCD3 Cape and UDA1380 on i2s

I am fairly sure I know how to connect it up. If I get it running I will try to post how I did it.

And did it work?

BR.

And did it work?

BR.

I haven’t progress much yet. I am hoping that I can copy the audio cape dts files to get it hooked up, and then get the uda1380 into the kernel somehow. I have seen the code for the driver in the linux source.

I haven't progress much yet. I am hoping that I can copy the audio cape dts files to get it hooked up, and then get the uda1380 into the kernel somehow. I have seen the code for the > driver in the linux source.

Not sure if will be of any use but I've just opened a PR on the RCN overlay repo for a (TI sourced) DTS which I hope will work for the TI stereo codec on the audio cape. Not proved out though as I'm at a loss as to how to get it into the build .. :\\\

From the bb.org-overlays just:

./dtc-overlay.sh

./install.sh

Then from /boot/uEnv.txt:

cape_enable=bone_capemgr.enable_partno=BB-BONE-AUDI-02

(since hdmi-audio isn't enabled, this should work on the normal
am335x-boneblack.dtb)

Regards,

btw, just a small fixup.. :wink:

ocp -> /

https://github.com/beagleboard/bb.org-overlays/commit/956a1c25354532354c8a3d0f2b0ced96a36ccf4b

Regards,

Hi Robert

Then from /boot/uEnv.txt:

cape_enable=bone_capemgr.enable_partno=BB-BONE-AUDI-02

Cool. Glad to be able to add something to the mix. It looks like it is hooked up at boot.

root@arm:~# cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-BONE-AUDI-02

root@arm:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: EVM [DA830 EVM], device 0: AIC3X tlv320aic3x-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

But then ...

Playing WAVE 'sine2s.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
[ 37.697454] davinci-mcasp 48038000.mcasp: Transmit buffer underflow
underrun!!! (at least 0.330 ms long)

root@arm:~# arecord -r 44100 -f S16_LE -c 2 input.wav
Recording WAVE 'input.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
[ 148.568630] davinci-mcasp 48038000.mcasp: Receive buffer overflow
overrun!!! (at least 0.083 ms long)
[ 148.576993] davinci-mcasp 48038000.mcasp: Receive buffer overflow
overrun!!! (at least 2.847 ms long)
--------------------------snip!---------------------------------------

Hi Robert

Then from /boot/uEnv.txt:

cape_enable=bone_capemgr.enable_partno=BB-BONE-AUDI-02

Cool. Glad to be able to add something to the mix. It looks like it is hooked up at boot.

root@arm:~# cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-BONE-AUDI-02

root@arm:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: EVM [DA830 EVM], device 0: AIC3X tlv320aic3x-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Sweet! :wink:

But then ...

Playing WAVE 'sine2s.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
[ 37.697454] davinci-mcasp 48038000.mcasp: Transmit buffer underflow
underrun!!! (at least 0.330 ms long)

root@arm:~# arecord -r 44100 -f S16_LE -c 2 input.wav
Recording WAVE 'input.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
[ 148.568630] davinci-mcasp 48038000.mcasp: Receive buffer overflow
overrun!!! (at least 0.083 ms long)
[ 148.576993] davinci-mcasp 48038000.mcasp: Receive buffer overflow
overrun!!! (at least 2.847 ms long)
--------------------------snip!---------------------------------------

Yuck bugs..

Looking at...

http://mailman.alsa-project.org/pipermail/alsa-devel/2014-November/083797.html

Does it help to bump the cpufreq up before you try using it?

sudo cpufreq-set -g performance

No obvious fixes in next:

https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/davinci

I need to find my cape now.

Regards,

> root@arm:~# aplay -l
> **** List of PLAYBACK Hardware Devices **** card 0: EVM [DA830 EVM],
> device 0: AIC3X tlv320aic3x-hifi-0 []
> Subdevices: 1/1
> Subdevice #0: subdevice #0

Sweet! :wink:

:slight_smile: - BYW I assume that device presence means that it really is in place and not getting confused with HDMI audio? Still unclear as to the interactions between B3 hardware and 4.X kernels etc.

I need to find my cape now.

Yep :slight_smile:

cpufreq-set

Good idea. It helped. The underruns are now shorter ... but no cigar.

http://mailman.alsa-project.org/pipermail/alsa-devel/2014-November/083797.html

I'll follow this one up. Not quite sure where the TI stuff is in relation to mainline. Is there any (brief) summary of what has migrated? I'm pretty sure McASP and SPI are really well covered the former ... ? Is there any good reason to use TI BSP any more? I

> root@arm:~# aplay -l
> **** List of PLAYBACK Hardware Devices **** card 0: EVM [DA830 EVM],
> device 0: AIC3X tlv320aic3x-hifi-0 []
> Subdevices: 1/1
> Subdevice #0: subdevice #0

Sweet! :wink:

:slight_smile: - BYW I assume that device presence means that it really is in place and not getting confused with HDMI audio? Still unclear as to the interactions between B3 hardware and 4.X kernels etc.

No worries about hdmi audio, i couldn't get it working, so it's not
enabled in v4.1.x (yet)...

I need to find my cape now.

Yep :slight_smile:

cpufreq-set

Good idea. It helped. The underruns are now shorter ... but no cigar.

http://mailman.alsa-project.org/pipermail/alsa-devel/2014-November/083797.html

I'll follow this one up. Not quite sure where the TI stuff is in relation to mainline. Is there any (brief) summary of what has migrated? I'm pretty sure McASP and SPI are really well covered the former ... ? Is there any good reason to use TI BSP any more? I

So with the way TI did their bsp 3.14.x development, they pushed much
of it to mainline and backported many of the patchset's. So we should
be in really good shape for v4.1.x.. and since v4.1.x is going to be
kernel.org lts release, ti has added a v4.1.x branch

http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.1.y

I'm hoping to to backport much of ^^ so v4.1.x will be around for
awhile.. (until the next lts release next summer)

Regards,

http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-
kernel.git;a=shortlog;h=refs/heads/ti-linux-4.1.y

I'm hoping to to backport much of ^^ so v4.1.x will be around for awhile..
(until the next lts release next summer)

OK. That sound ideal. I am going to work off your 4.X.

What's the workflow? Is there a way to get stuff back into the tree via Github?

Finally a *big* thanks for all your efforts and help here. Much appreciated.

BR.

raw diff's with a sign-off is all that is required, don't worry about
adding the patch into the patch-scripts, i can take care of that.

We have raw git tree's here to:

https://github.com/beagleboard/linux/

(make sure to use the tag's as the 3.8/3.14/4.1 branches get rebased..)

Regards,

I haven't progress much yet. I am hoping that I can copy the audio cape dts files to get it hooked up, and then get the uda1380 into the kernel somehow. I have seen the code for the > driver in the linux source.

Not sure if you are committed to the UDA part. There is another board (created for the mbed project) which carries a TLV320AIC23B in a prototype friendly carrier. AFAICT this should just run when hooked up to the right Bone pins with the DTB loaded.

Pretty though it is not :slight_smile:

http://www.rs-online.com/designspark/electronics/eng/nodes/view/type:knowledge-item/slug:reference-design-of-mbed-audiocodec-module

Not sure if you are committed to the UDA part. There is another board (created for the mbed project) which carries a TLV320AIC23B in a prototype friendly carrier. AFAICT this should just run when hooked up to the right Bone pins with the DTB loaded.

I want to use them as I have 2 already. They have a built in, programmable AGC, which was the main reason I got them. I thought it would be easy to connect them up :slight_smile:

I came back to this thread to get some info I had typed in and was surprised by the number of new posts.