Audio Cape Rev A

Neil_Cobbett · January 13, 2021, 12:37am

HI,

Has anyone managed to get the old/original Circuit Co Audio Cape Revision A working on the later kernels?

This is the dts file associated with cape board and has worked fine on the older 3.x kernels:

BB-BONE-AUDI-01.dts

It doesn’t seem to be installed/supported as part of the latest /lib/firmware directory.
It compiles ok but when added to uEnv.txt it doesn’t work:

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[fe926a6a4cf5805041878d7df82b58c00b4f902e]
eeprom:[A335BNLTBWA51712EW004800]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 2019.04-00002-g07d5700e21 (Mar 06 2020 - 11:24:55 -0600)]:[location: dd MBR]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 2018.03-00002-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.03-00002-gac9cce7c6a]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-I2C1-FAST-00A0]
UBOOT: Loaded Overlay:[BB-PWM2-00A0]
UBOOT: Loaded Overlay:[BB-UART1-00A0]
UBOOT: Loaded Overlay:[BB-UART2-00A0]
kernel:[5.4.87-bone-rt-r41]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr1=/lib/firmware/BB-UART2-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr2=/lib/firmware/BB-PWM2-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr3=/lib/firmware/BB-I2C1-FAST-00A0.dtbo]
uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-BONE-AUDI-01-00A0.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403]
pkg:[bb-customizations]:[1.20200306.0-0rcnee0~buster+20200306]
pkg:[bb-usb-gadgets]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker
tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_cor
e.default_quality=100 quiet]
dmesg | grep remote
[ 1.933071] remoteproc remoteproc0: wkup_m3 is available
[ 2.109940] remoteproc remoteproc0: powering up wkup_m3
[ 2.109966] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
[ 2.110232] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[ 1.565521] pinctrl-single 44e10800.pinmux: 142 pins, size 568
[ 1.921849] pinctrl-single 44e10800.pinmux: pin PIN18 already requested by ocp:P9_14_pinmux; cannot claim for ocp:gpio-leds-cape-audio
[ 1.921870] pinctrl-single 44e10800.pinmux: pin-18 (ocp:gpio-leds-cape-audio) status -22
[ 1.921881] pinctrl-single 44e10800.pinmux: could not request pin 18 (PIN18) from group pinmux_bone_audio_cape_led_pins on device pinctrl-single
[ 43.009888] pinctrl-single 44e10800.pinmux: pin PIN100 already requested by ocp:P9_31_pinmux; cannot claim for 48038000.mcasp
[ 43.009914] pinctrl-single 44e10800.pinmux: pin-100 (48038000.mcasp) status -22
[ 43.009926] pinctrl-single 44e10800.pinmux: could not request pin 100 (PIN100) from group pinmux_bone_audio_cape_audio_pins on device pinctrl-single
dmesg | grep gpio-of-helper
[ 1.577714] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

DarthRay79 · January 14, 2021, 3:16am

Neil,
I think I can help. I worked on a custom prototype board and set up my own TLV320 with an Octavo RED board in predevelopment in the device tree and is working fine. Some things you absolutely need to know before changing things in the cape dts file.
-What I2C bus and pinmux are you using.
-What MCASP bus are you using in pinmux? Definitely need 2 of the 4 RX pins.

You need to learn how to set up your asound.conf file. This has so many possibilities based on how you want to sample the audio.
-If using a cape and making changes, use install.sh or it won’t work.
-The better option is to learn how to create your own device tree and put it as an Overlay in the uEnv.txt file.

If the actual cape hasn’t changed at all (pins). Then I’ll show you how to just make a device tree of that cape overlay.

I’ll provide more details tomorrow.

Regards,
Ray

Neil_Cobbett · January 14, 2021, 11:48am

Hi Ray,

Thanks for the offer of help, very much appreciated! I’ve been going around in circles for days with this problem. I developed my own cape around the TLV320 (in c. 2016) and it had been working fine previously. I’ve upgraded from 3.x kernel to 4.x with some issues with device tree changes (in c. 2018) but solved them pretty quickly. This time, again I want to upgrade to a later kernel and use a RT kernel due to some timing ‘jitter’ issues I was having with the collected data. The cape records the VLF radio spectrum (basically audio) and is used to detect things like solar flares. It’s very sensitive to phase shifts in signal so needs very precise timing to keep running (I use a GPS Pulse per second fed into the other channel of the sound card to act as an accurate phase reference marker - GPS satellites use atomic clocks). I started with a fresh Beaglebone Install using the latest LTS RT kernel rather than working with a patched system with numerous ‘hacks’. I moved my DTS files across and recompiled but have gotten stuck with the McASP not working and ALSA not detecting the soundcard. It is to do with either the DTS file or some step with uBoot loading the DTBO and ALSA detecting the hardware.

Anyway, on to your questions:

I2C is using i2C2 ‘bus 2’
TLV320 is mapped to 0x1b
I can also see the device assigned on this bus with the i2cdetect command.

McASP Pins:

"P9.31",	/* mcasp0: mcasp0_aclkx */
"P9.29",	/* mcasp0: mcasp0_fsx */
"P9.28",	/* mcasp0: mcasp0_axr2 */
"P9.25",	/* mcasp0: mcasp0_ahclkx */

3.

Direction and Mode setting of the multiplexer:

pinctrl-single,pins = <
					0x190 0x20	/* mcasp0_aclkx.mcasp0_aclkx, INPUT | MODE0 */
					0x194 0x20	/* mcasp0_fsx.mcasp0_fsx,     INPUT | MODE0 */
					0x19c 0x22	/* mcasp0_ahclkr.mcasp0_axr2, INPUT | MODE2 */
					0x1ac 0x22	/* mcasp0_ahclkx.mcasp0_axr3, INPUT | MODE2 */

NB: ^^^ not sure this direction setting ir tight but it has worked fine previously so I have not touched it.

The dtbo worked fine in the last iteration using a 4.4 Kernel. I upgraded to a 5.4 RT kernel (RT_PREEMPT patch). At first it complained with mapping the pins:

[ 43.009888] pinctrl-single 44e10800.pinmux: pin PIN100 already requested by ocp:P9_31_pinmux; cannot claim for 48038000.mcasp
[ 43.009914] pinctrl-single 44e10800.pinmux: pin-100 (48038000.mcasp) status -22
[ 43.009926] pinctrl-single 44e10800.pinmux: could not request pin 100 (PIN100) from group pinmux_bone_audio_cape_audio_pins on device pinctrl-single

Doing a bit of searching on the web (where is the documentation for all this new/changed information?) I found I now need to add the following to the DTS file:

P9_25_pinmux { status = "disabled"; };	/* mcasp0_ahclkx */
			P9_28_pinmux { status = "disabled"; };	/* mcasp0_axr2 */
			P9_29_pinmux { status = "disabled"; };	/* mcasp0_fsx */
			P9_30_pinmux { status = "disabled"; };	/* mcasp0_axr0 */
			P9_31_pinmux { status = "disabled"; };	/* mcasp0_aclkx */

Like I say, I’m not sure if this is what needs to be done since I can’t find any documentation to confirm but after drilling into newer DTS files (AUDI-02), I see that to define my own pins, I need to ‘disable’ them from some sort of generic Devicetree mapping.

Running ‘sudo /opt/scripts/tools.version.sh’ to look for problems, I am now seeing no conflicts with ^^4. added to my DTS file. However, Alsa is still not detecting the soundcard; using aplay -l. I’m not sure if it is to do with me misunderstanding ^^ 4. or I am missing a further step somewhere along the way. I’ve done quite a bit of Alsa work before and I am used to editing asound.conf files. I dsnoop to allow different experiments to connect to the same input sound stream simultaneously. For some reason the Kernel is loading Alsa BUT Alsa isn’t seeing any soundcard hardware. (BTW I’ve disabled HDMI; uboot_overlay_options:[disable_uboot_overlay_video=1) since this use to conflict with adding an additional soundcard.

RE: ‘If using a cape and making changes, use install.sh or it won’t work.’

Can you explain what you mean here? Previously, I compiled dts in my own directory with dtc to get dtbo, copied dtbo to /lib/firmware then pointed the uEnv file at the dtbo file. Has this step changed or do I need to do another intermediate step?

RE: ‘-The better option is to learn how to create your own device tree and put it as an Overlay in the uEnv.txt file.’
I think this is what I am doing already.

What would be really good to have is some diagnostic tools like we had in the older 3.x kernel. Someway of easily checking the pin assignments and some sort of debugging of the device tree. Also a reference document. A lot of the stuff I find on line to explain how to create DTS files and add user defined cape boards is out of date and mappings in /sys have changed.

I’ve attached by DTS file. NB: I have added fragment@0 to fix ^^^4 but other than that the old ‘working’ DTS file is the same.

Thanks for offering to help Ray!
Neil

BB-BONE-AUDI-01.dts (2.57 KB)

Neil_Cobbett · January 14, 2021, 1:36pm

Hi Ray,

A bit more information:

This is my CODEC:
tlv320aic3104

For McASP, pin maps as follows:

BBB P9 TLV320
P25 AUD_IN P40
P28 AUD_OUT P41
P29 FS/WCLK P39
P31 BCLK P38

The codec is clocked by a dedicated temperature controlled 12MHz oscillator

The pin description in the DTS is a little misleading.

Neil

Neil_Cobbett · January 14, 2021, 2:59pm

I’ve just gone over my DTS in detail and realise I made one mistake… I defined one of the pins as and Input when it should be an output. Perhaps the later device tree code is less tolerant of naming outputs as inputs and refuses to load it? Other than that I can find nothing wrong with the DTS file.

fragment@1 {
target = <&am33xx_pinmux>;
overlay {

bone_audio_cape_audio_pins: pinmux_bone_audio_cape_audio_pins {
pinctrl-single,pins = <
0x190 0x20 /* P31 BCLK mcasp0_aclkx, INPUT MODE0 /
0x194 0x20 / P29 WCLK/FS mcasp0_fsx, INPUT MODE0 /
0x19c 0x22 / P28 AUD_OUT mcasp0_axr2 INPUT MODE2 /
0x1ac 0x02 / P25 AUD_IN mcasp0_axr3 OUTPUT MODE2 */

/*
* AUD_IN and AUD_OUT are from perspective of the CODEC, therefore reversed for Multiplexer assignments
* i.e. AUD_IN is OUTPUT and AUD_OUT is INPUT
*/

ALSO FOR REFERENCE these are the McASP pins with correct labelling being used to interface to the CODEC:

“P9.31”, /* BCLK mcasp0_aclkx /
“P9.29”, / WCLK/FS mcasp0_fsx /
“P9.28”, / AUD_OUT mcasp0_axr2 /
“P9.25”, / AUD_IN mcasp0_axr3 */

I’m just about to try it out to see if this fixes the issue with no usable sound codec.

Neil

DarthRay79 · January 14, 2021, 3:58pm

Neil,

Here’s some loooooong info based on the information you sent. They correlate to the answers you provided below plus more.

That’s good that i2cdetect found the device on the bus. This tells me that ALSA is not setting up the device driver properly (Through the MCASP pins). I noticed in my development, everything has to be just right in order for that to happen.
for the MCASP Pins, you are also using "P9.31 " /* mcasp0: mcasp0_axr3 */
Both axr2 and axr3 cannot be both inputs. AXR is bi-directional, but the audio codec needs one to be set to transmit (X) and one to be receive ®. Why it ever worked before is a mystery. And setting up their direction is two parts… in the device tree pinmux and in the serialization of the “sound” node of the device tree. I’ll give an example below. I’ve always had to define whether it’s a PULLUP or PULLDOWN also and do not believe these can be left free-floating.
If you are creating a “.dtbo” file, that is a CAPE OVERLAY, not a DEVICE TREE file (which ends with “.dtb”). It’s been stated to move away from CAPE OVERLAYS as they are extremely buggy. You can create a Device Tree and it is used an overlay to the active device tree. The reason you seen what you did is that address “190” was being used by the Kernel and you can’t allocate two device pinmux using the same pin address.
To see issues, you should be using $ dmesg in your terminal. It outputs the kernel log form /var/logs/ messages. It’ll tell you if it’s running the TLV320 in there. You can also see if your sound codec is being used by typing $ alsamixer in the terminal. This will bring up a GUI of your sound codec. It should be something different than PulseAudio. Furthermore, add the following line to your overlay in the fragment for sound {…}, just below the capability line: simple-audio-card,name = “Audio Name I Want”;

Whatever you put as “Audio Name I Want” will show up in place of PulseAudio if ASLA is using the TLV320 codec when you check alsamixer.

Whenever you change or create a Cape Overlay you MUST run “/opt/source/bb.org-overlays/install.sh”. You are doing most of what needs to be done… except rebuilding the /boot/initrd.img- file (mine is initrd.img-4.19.94-ti-r50). Just running install.sh is all you need to do, it will put everything in the firmware directory and rebuild the image.

So why does it have to be this way?.. Form my understanding, if your new cape is different than the one in that image file or you created a new cape overlay, it will not match what’s in that image file. I believe this is done as sort of a checksum to ensure it’s a valid overlay for a device. That you cna’t just plug anything in and destroy the device. The idea was a cape can be added (connected) and nothing done to the uEnv.txt file and the cape is automatically loaded for use by detecting the cape, putting it’s overlay in one of the four cape manager slots and using it to overlay the active device tree. I bet if you check $ dmesg in the terminal, you’ll find a line that says it failed to load BB-BONE-AUDI-02.

Device trees are in an entirely different location… /opt/source/dtb--ti/src/arm. As an example, mine is /opt/source/dtb-4.19-ti/src/arm. Be weary, they now add the last and newest dtb directories as well. use the one that matches your kernel number in the uEnv.txt file. If you create a device tree, the make file will use dtc to build it from /opt/source/dtb--ti/. Here’s an example of how I rebuild device trees and use them. I copy “my_devicetree.dts” to /opt/source/dtb-4.19/src/arm/. usually by just putting the uSD card in my laptop.

$ cd /opt/source/dtb-4.19-ti/
$ sudo touch src/arm/*

sudo touch will change the timestamp of all files (*) in that directory. If not you will get an error when building the device tree for the time being in the future.
$ sudo make src/arm/my_devicetree.dtb
If there are any errors, it’ll tell you the line number. fix it.
$ sudo cp src/arm/my_devicetree.dtb /boot/dtbs//

Then in the uEnv.txt file, I uncomment #dtb= to dtb=my_devicetree.dtb. A device tree does not have to be built into the intird.img file.

Lastly,
In your mcasp{…} node fragment. You’ll see numbers under the serial-dir configuraiton. Those number correlate to te RX you are using. In BB-BONE-AUDI-02, the first line is 0 0 2 1 and correlate to RX0 RX1 RX2 RX3. As you can see RX2 is set as Recieve (or RX) and RX3 is set to Transmit (or TX). Those need to match the input/output direction in the pinmux… which is not the case we see. I never got my development audio board to work until I set the direcitons accordingly. If RX2 is set to RX, then the pin should be an INPUT, if RX3 is set to TX, then it’s pin should be an OUTPUT.

I attached an example of the Cape Overlay I did before I moved to using a device tree instead. This worked fine for my prototype device (not the exact same as your audio cape device), but you can see how I had to change things to make it work. If you are using a 3104, just change everything form 3106 to 3104 (I think it’s 3 places).

Sorry it was a lot but I learned a lot over the last 2 years working on a linux based Embedded System for my employer. And I like ppl to try and use information to develop on their own.

Does the Audio Cape Device pinout actually match BB-BONE-AUDI-02?

Hi Ray,

Thanks for the offer of help, very much appreciated! I’ve been going around in circles for days with this problem. I developed my own cape around the TLV320 (in c. 2016) and it had been working fine previously. I’ve upgraded from 3.x kernel to 4.x with some issues with device tree changes (in c. 2018) but solved them pretty quickly. This time, again I want to upgrade to a later kernel and use a RT kernel due to some timing ‘jitter’ issues I was having with the collected data. The cape records the VLF radio spectrum (basically audio) and is used to detect things like solar flares. It’s very sensitive to phase shifts in signal so needs very precise timing to keep running (I use a GPS Pulse per second fed into the other channel of the sound card to act as an accurate phase reference marker - GPS satellites use atomic clocks). I started with a fresh Beaglebone Install using the latest LTS RT kernel rather than working with a patched system with numerous ‘hacks’. I moved my DTS files across and recompiled but have gotten stuck with the McASP not working and ALSA not detecting the soundcard. It is to do with either the DTS file or some step with uBoot loading the DTBO and ALSA detecting the hardware.

Anyway, on to your questions:

I2C is using i2C2 ‘bus 2’
TLV320 is mapped to 0x1b
I can also see the device assigned on this bus with the i2cdetect command.

McASP Pins:

"P9.31",	/* mcasp0: mcasp0_aclkx */
"P9.29",	/* mcasp0: mcasp0_fsx */
"P9.28",	/* mcasp0: mcasp0_axr2 */
"P9.25",	/* mcasp0: mcasp0_ahclkx */

3.

Direction and Mode setting of the multiplexer:

pinctrl-single,pins = <
					0x190 0x20	/* mcasp0_aclkx.mcasp0_aclkx, INPUT | MODE0 */
					0x194 0x20	/* mcasp0_fsx.mcasp0_fsx,     INPUT | MODE0 */
					0x19c 0x22	/* mcasp0_ahclkr.mcasp0_axr2, INPUT | MODE2 */
					0x1ac 0x22	/* mcasp0_ahclkx.mcasp0_axr3, INPUT | MODE2 */

NB: ^^^ not sure this direction setting ir tight but it has worked fine previously so I have not touched it.

The dtbo worked fine in the last iteration using a 4.4 Kernel. I upgraded to a 5.4 RT kernel (RT_PREEMPT patch). At first it complained with mapping the pins:

[ 43.009888] pinctrl-single 44e10800.pinmux: pin PIN100 already requested by ocp:P9_31_pinmux; cannot claim for 48038000.mcasp
[ 43.009914] pinctrl-single 44e10800.pinmux: pin-100 (48038000.mcasp) status -22
[ 43.009926] pinctrl-single 44e10800.pinmux: could not request pin 100 (PIN100) from group pinmux_bone_audio_cape_audio_pins on device pinctrl-single

Doing a bit of searching on the web (where is the documentation for all this new/changed information?) I found I now need to add the following to the DTS file:

P9_25_pinmux { status = "disabled"; };	/* mcasp0_ahclkx */
			P9_28_pinmux { status = "disabled"; };	/* mcasp0_axr2 */
			P9_29_pinmux { status = "disabled"; };	/* mcasp0_fsx */
			P9_30_pinmux { status = "disabled"; };	/* mcasp0_axr0 */
			P9_31_pinmux { status = "disabled"; };	/* mcasp0_aclkx */

Like I say, I’m not sure if this is what needs to be done since I can’t find any documentation to confirm but after drilling into newer DTS files (AUDI-02), I see that to define my own pins, I need to ‘disable’ them from some sort of generic Devicetree mapping.

Running ‘sudo /opt/scripts/tools.version.sh’ to look for problems, I am now seeing no conflicts with ^^4. added to my DTS file. However, Alsa is still not detecting the soundcard; using aplay -l. I’m not sure if it is to do with me misunderstanding ^^ 4. or I am missing a further step somewhere along the way. I’ve done quite a bit of Alsa work before and I am used to editing asound.conf files. I dsnoop to allow different experiments to connect to the same input sound stream simultaneously. For some reason the Kernel is loading Alsa BUT Alsa isn’t seeing any soundcard hardware. (BTW I’ve disabled HDMI; uboot_overlay_options:[disable_uboot_overlay_video=1) since this use to conflict with adding an additional soundcard.

RE: ‘If using a cape and making changes, use install.sh or it won’t work.’

Can you explain what you mean here? Previously, I compiled dts in my own directory with dtc to get dtbo, copied dtbo to /lib/firmware then pointed the uEnv file at the dtbo file. Has this step changed or do I need to do another intermediate step?

RE: ‘-The better option is to learn how to create your own device tree and put it as an Overlay in the uEnv.txt file.’
I think this is what I am doing already.

What would be really good to have is some diagnostic tools like we had in the older 3.x kernel. Someway of easily checking the pin assignments and some sort of debugging of the device tree. Also a reference document. A lot of the stuff I find on line to explain how to create DTS files and add user defined cape boards is out of date and mappings in /sys have changed.

I’ve attached by DTS file. NB: I have added fragment@0 to fix ^^^4 but other than that the old ‘working’ DTS file is the same.

Thanks for offering to help Ray!
Neil

DarthRay79 · January 14, 2021, 4:07pm

Ooops, forgot to attach my example Cape Overlay.

Neil,

Here’s some loooooong info based on the information you sent. They correlate to the answers you provided below plus more.

That’s good that i2cdetect found the device on the bus. This tells me that ALSA is not setting up the device driver properly (Through the MCASP pins). I noticed in my development, everything has to be just right in order for that to happen.
for the MCASP Pins, you are also using "P9.31 " /* mcasp0: mcasp0_axr3 */
Both axr2 and axr3 cannot be both inputs. AXR is bi-directional, but the audio codec needs one to be set to transmit (X) and one to be receive ®. Why it ever worked before is a mystery. And setting up their direction is two parts… in the device tree pinmux and in the serialization of the “sound” node of the device tree. I’ll give an example below. I’ve always had to define whether it’s a PULLUP or PULLDOWN also and do not believe these can be left free-floating.
If you are creating a “.dtbo” file, that is a CAPE OVERLAY, not a DEVICE TREE file (which ends with “.dtb”). It’s been stated to move away from CAPE OVERLAYS as they are extremely buggy. You can create a Device Tree and it is used an overlay to the active device tree. The reason you seen what you did is that address “190” was being used by the Kernel and you can’t allocate two device pinmux using the same pin address.
To see issues, you should be using $ dmesg in your terminal. It outputs the kernel log form /var/logs/ messages. It’ll tell you if it’s running the TLV320 in there. You can also see if your sound codec is being used by typing $ alsamixer in the terminal. This will bring up a GUI of your sound codec. It should be something different than PulseAudio. Furthermore, add the following line to your overlay in the fragment for sound {…}, just below the capability line: simple-audio-card,name = “Audio Name I Want”;

Whatever you put as “Audio Name I Want” will show up in place of PulseAudio if ASLA is using the TLV320 codec when you check alsamixer.

Whenever you change or create a Cape Overlay you MUST run “/opt/source/bb.org-overlays/install.sh”. You are doing most of what needs to be done… except rebuilding the /boot/initrd.img- file (mine is initrd.img-4.19.94-ti-r50). Just running install.sh is all you need to do, it will put everything in the firmware directory and rebuild the image.

So why does it have to be this way?.. Form my understanding, if your new cape is different than the one in that image file or you created a new cape overlay, it will not match what’s in that image file. I believe this is done as sort of a checksum to ensure it’s a valid overlay for a device. That you cna’t just plug anything in and destroy the device. The idea was a cape can be added (connected) and nothing done to the uEnv.txt file and the cape is automatically loaded for use by detecting the cape, putting it’s overlay in one of the four cape manager slots and using it to overlay the active device tree. I bet if you check $ dmesg in the terminal, you’ll find a line that says it failed to load BB-BONE-AUDI-02.

Device trees are in an entirely different location… /opt/source/dtb--ti/src/arm. As an example, mine is /opt/source/dtb-4.19-ti/src/arm. Be weary, they now add the last and newest dtb directories as well. use the one that matches your kernel number in the uEnv.txt file. If you create a device tree, the make file will use dtc to build it from /opt/source/dtb--ti/. Here’s an example of how I rebuild device trees and use them. I copy “my_devicetree.dts” to /opt/source/dtb-4.19/src/arm/. usually by just putting the uSD card in my laptop.

$ cd /opt/source/dtb-4.19-ti/
$ sudo touch src/arm/*

sudo touch will change the timestamp of all files (*) in that directory. If not you will get an error when building the device tree for the time being in the future.
$ sudo make src/arm/my_devicetree.dtb
If there are any errors, it’ll tell you the line number. fix it.
$ sudo cp src/arm/my_devicetree.dtb /boot/dtbs//

Then in the uEnv.txt file, I uncomment #dtb= to dtb=my_devicetree.dtb. A device tree does not have to be built into the intird.img file.

Lastly,
In your mcasp{…} node fragment. You’ll see numbers under the serial-dir configuraiton. Those number correlate to te RX you are using. In BB-BONE-AUDI-02, the first line is 0 0 2 1 and correlate to RX0 RX1 RX2 RX3. As you can see RX2 is set as Recieve (or RX) and RX3 is set to Transmit (or TX). Those need to match the input/output direction in the pinmux… which is not the case we see. I never got my development audio board to work until I set the direcitons accordingly. If RX2 is set to RX, then the pin should be an INPUT, if RX3 is set to TX, then it’s pin should be an OUTPUT.

I attached an example of the Cape Overlay I did before I moved to using a device tree instead. This worked fine for my prototype device (not the exact same as your audio cape device), but you can see how I had to change things to make it work. If you are using a 3104, just change everything form 3106 to 3104 (I think it’s 3 places).

Sorry it was a lot but I learned a lot over the last 2 years working on a linux based Embedded System for my employer. And I like ppl to try and use information to develop on their own.

Does the Audio Cape Device pinout actually match BB-BONE-AUDI-02?

Hi Ray,

Thanks for the offer of help, very much appreciated! I’ve been going around in circles for days with this problem. I developed my own cape around the TLV320 (in c. 2016) and it had been working fine previously. I’ve upgraded from 3.x kernel to 4.x with some issues with device tree changes (in c. 2018) but solved them pretty quickly. This time, again I want to upgrade to a later kernel and use a RT kernel due to some timing ‘jitter’ issues I was having with the collected data. The cape records the VLF radio spectrum (basically audio) and is used to detect things like solar flares. It’s very sensitive to phase shifts in signal so needs very precise timing to keep running (I use a GPS Pulse per second fed into the other channel of the sound card to act as an accurate phase reference marker - GPS satellites use atomic clocks). I started with a fresh Beaglebone Install using the latest LTS RT kernel rather than working with a patched system with numerous ‘hacks’. I moved my DTS files across and recompiled but have gotten stuck with the McASP not working and ALSA not detecting the soundcard. It is to do with either the DTS file or some step with uBoot loading the DTBO and ALSA detecting the hardware.

Anyway, on to your questions:

I2C is using i2C2 ‘bus 2’
TLV320 is mapped to 0x1b
I can also see the device assigned on this bus with the i2cdetect command.

McASP Pins:

"P9.31",	/* mcasp0: mcasp0_aclkx */
"P9.29",	/* mcasp0: mcasp0_fsx */
"P9.28",	/* mcasp0: mcasp0_axr2 */
"P9.25",	/* mcasp0: mcasp0_ahclkx */

3.

Direction and Mode setting of the multiplexer:

pinctrl-single,pins = <
					0x190 0x20	/* mcasp0_aclkx.mcasp0_aclkx, INPUT | MODE0 */
					0x194 0x20	/* mcasp0_fsx.mcasp0_fsx,     INPUT | MODE0 */
					0x19c 0x22	/* mcasp0_ahclkr.mcasp0_axr2, INPUT | MODE2 */
					0x1ac 0x22	/* mcasp0_ahclkx.mcasp0_axr3, INPUT | MODE2 */

NB: ^^^ not sure this direction setting ir tight but it has worked fine previously so I have not touched it.

The dtbo worked fine in the last iteration using a 4.4 Kernel. I upgraded to a 5.4 RT kernel (RT_PREEMPT patch). At first it complained with mapping the pins:

[ 43.009888] pinctrl-single 44e10800.pinmux: pin PIN100 already requested by ocp:P9_31_pinmux; cannot claim for 48038000.mcasp
[ 43.009914] pinctrl-single 44e10800.pinmux: pin-100 (48038000.mcasp) status -22
[ 43.009926] pinctrl-single 44e10800.pinmux: could not request pin 100 (PIN100) from group pinmux_bone_audio_cape_audio_pins on device pinctrl-single

Doing a bit of searching on the web (where is the documentation for all this new/changed information?) I found I now need to add the following to the DTS file:

P9_25_pinmux { status = "disabled"; };	/* mcasp0_ahclkx */
			P9_28_pinmux { status = "disabled"; };	/* mcasp0_axr2 */
			P9_29_pinmux { status = "disabled"; };	/* mcasp0_fsx */
			P9_30_pinmux { status = "disabled"; };	/* mcasp0_axr0 */
			P9_31_pinmux { status = "disabled"; };	/* mcasp0_aclkx */

Like I say, I’m not sure if this is what needs to be done since I can’t find any documentation to confirm but after drilling into newer DTS files (AUDI-02), I see that to define my own pins, I need to ‘disable’ them from some sort of generic Devicetree mapping.

Running ‘sudo /opt/scripts/tools.version.sh’ to look for problems, I am now seeing no conflicts with ^^4. added to my DTS file. However, Alsa is still not detecting the soundcard; using aplay -l. I’m not sure if it is to do with me misunderstanding ^^ 4. or I am missing a further step somewhere along the way. I’ve done quite a bit of Alsa work before and I am used to editing asound.conf files. I dsnoop to allow different experiments to connect to the same input sound stream simultaneously. For some reason the Kernel is loading Alsa BUT Alsa isn’t seeing any soundcard hardware. (BTW I’ve disabled HDMI; uboot_overlay_options:[disable_uboot_overlay_video=1) since this use to conflict with adding an additional soundcard.

RE: ‘If using a cape and making changes, use install.sh or it won’t work.’

Can you explain what you mean here? Previously, I compiled dts in my own directory with dtc to get dtbo, copied dtbo to /lib/firmware then pointed the uEnv file at the dtbo file. Has this step changed or do I need to do another intermediate step?

RE: ‘-The better option is to learn how to create your own device tree and put it as an Overlay in the uEnv.txt file.’
I think this is what I am doing already.

What would be really good to have is some diagnostic tools like we had in the older 3.x kernel. Someway of easily checking the pin assignments and some sort of debugging of the device tree. Also a reference document. A lot of the stuff I find on line to explain how to create DTS files and add user defined cape boards is out of date and mappings in /sys have changed.

I’ve attached by DTS file. NB: I have added fragment@0 to fix ^^^4 but other than that the old ‘working’ DTS file is the same.

Thanks for offering to help Ray!
Neil

TLV320-OVERLAY-01-00A0.dts (3.8 KB)

Samer_Abbas · January 15, 2021, 8:47pm

Hi Neil,

Not sure if you already solved this but you are getting this error due to following:

[ 43.009888] pinctrl-single 44e10800.pinmux: pin PIN100 already requested by ocp:P9_31_pinmux; cannot claim for 48038000.mcasp
[ 43.009914] pinctrl-single 44e10800.pinmux: pin-100 (48038000.mcasp) status -22
[ 43.009926] pinctrl-single 44e10800.pinmux: could not request pin 100 (PIN100) from group pinmux_bone_audio_cape_audio_pins on device pinctrl-single

Your custom board is loading am335x-boneblack-uboot-univ.dts as the device tree. This dts adds am335x-bone-common-univ.dtsi which is already claiming P9_31. So just comment anything related to P9_31 on am335x-bone-common-univ.dtsi and rebuild am335x-boneblack-uboot-univ.dts.

Thank you,
Samer

Neil_Cobbett · January 18, 2021, 1:12pm

Thanks Samer,

I still need to work out how to do this. I’m just returning to Beaglebone after a few years break and ‘everything’ has changed

At the moment I am loading DTBO’s via the uboot loader but speaking with Ray, he suggests doing it like you said. I still need to work it out and have a play.

Many thanks
Neil