Debugging Audio Cape configuration

[jrb...@colorado.edu]

I don't have an Audio Cape (everywhere is out of stock) but I just want to test the set up as if I did.

I ran all steps as given by the instructions (http://elinux.org/CircuitCo:Audio_Cape_RevB) including installing a new DT overlay,

disabling HDMI and adding to the slots file.

Then I try speaker-test -D default:EVM and put an oscilloscope on pin P9_28.  No waveform comes out.  This should be the I2S serial output, but it's just a flat line.  I have no idea how to debug this.

Any suggestions?

[g...@novadsp.com]

> I ran all steps as given by the instructions
> (http://elinux.org/CircuitCo:Audio_Cape_RevB) including installing a new DT overlay, disabling HDMI and adding to the slots file.

>Then I try speaker-test -D default:EVM and put an oscilloscope on pin
>P9_28. No waveform comes out. This should be the I2S serial output, but it's just a flat line. I have no idea how to debug this.

What do you get if you check pinctrl? Are things set up as expected?

sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins

[jrb...@colorado.edu]

Seems like it:

Relevant pins:

From dts:

                                pinctrl-single,pins = <

                                        0x1ac 0x00      /* mcasp0_ahclkx,             MODE0 | INPUT */

                                        0x19c 0x22              /* mcasp0_ahclkr, */

                                        0x194 0x20      /* mcasp0_fsx,                MODE0 | OUTPUT  */

                                        0x190 0x20      /* mcasp0_aclkr.mcasp0_aclkx, MODE0 | OUTPUT_PULLDOWN */

                                        0x198 0x20

                                >;

From pinmux-pins (in same order as above):

pin 107 (44e109ac): 48038000.mcasp (GPIO UNCLAIMED) function pinmux_bone_audio_cape_audio_pins group pinmux_bone_audio_cape_audio_pins

pin 103 (44e1099c): 48038000.mcasp (GPIO UNCLAIMED) function pinmux_bone_audio_cape_audio_pins group pinmux_bone_audio_cape_audio_pins

pin 101 (44e10994): 48038000.mcasp (GPIO UNCLAIMED) function pinmux_bone_audio_cape_audio_pins group pinmux_bone_audio_cape_audio_pins

pin 100 (44e10990): 48038000.mcasp (GPIO UNCLAIMED) function pinmux_bone_audio_cape_audio_pins group pinmux_bone_audio_cape_audio_pins

pin 102 (44e10998): 48038000.mcasp (GPIO UNCLAIMED) function pinmux_bone_audio_cape_audio_pins group pinmux_bone_audio_cape_audio_pins

And in /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins all the modes are as they should be from the .dts, except offset 0x198 has 0x70 instead of the given 0x20 mode from the .dts file.

I have tried this on two separate BBB's with identical results.

root@beaglebone:~# cat /sys/devices/bone_capemgr.9/slots 

 0: 54:PF--- 

 1: 55:PF--- 

 2: 56:PF--- 

 3: 57:PF--- 

 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G

 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI

 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN

 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-AUDI-02

[colin....@biocharger.com]

What distro and version are you using? I know on Debian after a certain build ( I don't know which ) that BB-BONE-AUDI-02 is installed as part of the kernel - if this is your case then the dts you are looking at may not be the same at kernel dtbo is using - just a thought.... 

I had this issue with 3.13.8-bone70 

[jrb...@colorado.edu]

On Friday, July 3, 2015 at 7:14:16 PM UTC-6, colin....@biocharger.com wrote:

What distro and version are you using? I know on Debian after a certain build ( I don't know which ) that BB-BONE-AUDI-02 is installed as part of the kernel - if this is your case then the dts you are looking at may not be the same at kernel dtbo is using - just a thought.... 

I had this issue with 3.13.8-bone70 

I'm using 

Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux

I'm not sure what you're saying though.  I know that /lib/firmware/BB-BONE-AUDI-02.dtbo is the right one because I compiled it myself from the dts.  Are you saying that it may conflict with another one already hardcoded in the kernel?

When you had this issue, how did you resolve it?

I suppose I could unload the dtbo and see if P9_28 comes to life?!

 

[William Hermans]

There was a change between 3.8.13-bone68, and 3.8.13-bone69 related to I2C as I recall. That caused his problem.

Full post is here, and was quite recent: https://groups.google.com/forum/#!searchin/beagleboard/audio$20cape|sort:date/beagleboard/2dXgKp9T8_g/j6o9Q8Jy2-QJ

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jrb...@colorado.edu]

On Friday, July 3, 2015 at 9:59:05 PM UTC-6, William Hermans wrote:

There was a change between 3.8.13-bone68, and 3.8.13-bone69 related to I2C as I recall. That caused his problem.

Thanks William.  I read that thread (which has more to do with Audio Cape's conflicts with the LCD Cape) and tried on a whim just commenting out pins 18 and 19, plus renaming the dtbo to BB-BONE-AUDI-03 but nothing changed... P9_28 is still flat when playing sound.

[William Hermans]

OK so from this page: http://elinux.org/BBB_Audio_Cape_RevB_Getting_Started

Since this Audio Cape uses the same audio signal from the onboard HDMI interface, you need to disable the audio portion of the HDMI by edit the uEnv.txt at /boot/uboot. Add this line to the uEnv.txt file:

    optargs=capemgr.disable_partno=BB-BONELT-HDMI

Reboot your BBB. Log in and check the capemgr:

    root@beaglebone:~# cat /sys/devices/bone_capemgr*/slots

        0: 54:PF--- 
        1: 55:PF--- 
        2: 56:PF--- 
        3: 57:PF--- 
        4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
        5

: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
        6: ff:P-O-L Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN

If memory serves HDMIN is the audio portion of the hdmi output. So the wiki is wrong. And seems I'm correct.

debian@beaglebone:~$ cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=3.8.13-bone70
#dtb=
cmdline=quiet init=/lib/systemd/systemd

##Example
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Disable HDMI/eMMC
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

##Disable HDMI
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

##Disable eMMC
#cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G

##Audio Cape (needs HDMI Audio disabled)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02


##enable BBB: eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

[William Hermans]

humm actually /boot/uEnv.txt say the opposite of what I said. However I still believe that to be wrong. Unless the file names have been swapped . . .

[William Hermans]

Disregard, I was remembering backwards apparently.

[Colin Bester]

I don't know when the change happened but am pretty sure when I was using bone47 I didn't have issue with kernel included audio cape. When I upgraded (I'm now using bone68) I found that audio cape was included so compiling your own and placing in /lib/firmware made no difference as it was already included - work around is to rename the file to something else (in my case I called it BB-BONE-AUDI-03.... and added this to my capemgr startup.

[jrb...@colorado.edu]

Well, I'm perplexed then.  I have bone47 on two different BBB's and both have been configured the same way: compile dts and put the dtbo in /lib/firmware, disable HDMI (and HDMIN), add BB-BONE-AUDI-02 to the capemgr file so it gets added at startup.

But I don't see anything coming out of the AUD_DOUT pin on either board.  No idea what could be wrong nor what I can do to debug it.

And I did try renaming to BB-BONE-AUDI-03 to no effect.

Is there anywhere I can go for help?!

[jrb...@colorado.edu]

Latest thoughts on this: I think perhaps the problem is that I should not expect to see serial data from P9_28 (I2S serial data out) without an actual Audio Cape.  There are probably I2C (control) and I2S (audio content) requirements, such as clocks and so forth, that are required before the BBB will output data.

Unfortunately, I know virtually nothing about hardware.  

I would just buy an Audio Cape, but I have not seen them in stock anywhere for the past month, and there seems to be no indication of when they'll be available again.

[Colin Bester]

If it'd help I could run same tests for you with and without audio cape and test the theory - I am running bone68 but suspect results will be the same - it'd be good to know if you can see output or not.

[g...@novadsp.com]

Hi all,

> Thanks William. I read that thread (which has more to do with Audio Cape's conflicts with the LCD Cape) and tried on a whim just commenting out pins 18 and 19, plus renaming the
> dtbo to BB-BONE-AUDI-03 but nothing changed... P9_28 is still flat when playing sound.

I'm using a later kernel version but I think the basic configurations should still apply (i.e. same pins/same overlay/same cape)

Gists here https://gist.github.com/ca8a33407cdef56cdb3e.git and here https://gist.github.com/1605ceb9c4565141cae2.git show slots and pinmux before and after loading the audio overlay.

I'm getting a couple of odd messages in dmesg:

[ 709.782296] davinci_evm ocp:sound: ASoC: CPU DAI (null) not registered
[ 709.789827] davinci_evm ocp:sound: snd_soc_register_card failed (-517)
[ 709.813163] davinci_evm ocp:sound: tlv320aic3x-hifi <-> 48038000.mcasp mapping ok

Most importantly without an audio cape in place

root@arm:/# speaker-test -D default:EVM

appears to work.

With a cape in place there are recurring error messages about buffer underruns as I reported here last week.

In neither case do I see any obvious I2S activity. There is a tool set for I2C manipulation. It would be really helpful to have one for I2S!.

[jrb...@colorado.edu]

Colin,

That would be phenomenally helpful!  Do you have a scope?

I'm curious if you see any life on pin 28 of the P9 header with and without a cape.  I suspect you will see data with the cape (because the DAC on the cape board is talking to the BBB's processor), but nothing without it.

I unfortunately don't have a way to "fake" the cape. 

[Colin Bester]

Yes I have a scope and will run tests for you when I get back to my desk. 

Sent from my iPhone

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/xfv4BY1AiEA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[jrb...@colorado.edu]

Just an update on this: I used a scope without a cape (because I don't own one, and estimated backorder on MCM is 52 days).  I verified no life on AUD_DOUT P9_28, but I _do_ see life on pins 19 and 20, which are the I2C SDA and SCL lines.  As soon as I commence sound output, the SCL goes live with a regular pulse, and we see an I2C START on SDA.

So I think this means if I had an actual I2C slave responding to the proper address, the BBB would then start outputting serial data on its I2S output pin, P9_28.  But without this, I won't see anything.

So it's not a driver or overlay issue, it would appear. 

[William Hermans]

Latest thoughts on this: I think perhaps the problem is that I should not expect to see serial data from P9_28 (I2S serial data out) without an actual Audio Cape.  There are probably I2C (control) and I2S (audio content) requirements, such as clocks and so forth, that are required before the BBB will output data.

Unfortunately, I know virtually nothing about hardware.  

I would just buy an Audio Cape, but I have not seen them in stock anywhere for the past month, and there seems to be no indication of when they'll be available again.

I had the same idea, and was wondering if the audio would not be cumming out hdmi instead as well.  I can verify that a CAN cape behaves this way .  .. but it is CAN, and not I2S . . .

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Colin Bester]

On beaglebone black (Debian3.8.13-bone68) I ran tests with and without an audio cape (rev B) and confirm that speaker-test -D default:EVM does not output anything on P9_28 without the audio cape connected. With audio cape connected I do see ouput on P9_28.

[jrb...@colorado.edu]

Thanks Colin!

This means that the I2C protocol running on pins P9_19 and P9_20 (19 SCL, 20 SDA) is required to complete before the BBB will send audio data on P9_28 (AUD_DOUT).

Without a cape, I don't see how I can get audio data... perhaps I can use an Arduino and the Wire.h library to act as an I2C slave and that may do it.

Or wait 51 more days for the Audio Capes to be back in stock.

In any case, thanks again!  

[Rick Mann]

> On Jul 5, 2015, at 08:41 , jrb...@colorado.edu wrote:
>
> Or wait 51 more days for the Audio Capes to be back in stock.

Where does one buy an audio cape? I've never been able to find a rev B.


--
Rick Mann
rm...@latencyzero.com

[jrb...@colorado.edu]

They're sold by a number of vendors (see the wiki for links) but all are out of stock.  Looks like it will be months before they get more in.