Disabling ADC to make use of SPI0 on BELA

zajili

I'm using the CTAG FACE Starter Kit RevC (RevC according to the bottom of the PCB).

I updated to dev branch.

After resetting the board, the process seems to run fine. I did have this error that seemed to repeat during the audio loop before that though :

McASP unexpected transmit frame sync occurred
audio frame 62176 errorCode: 3

Next step would be to try with the SPI example and the correct device path I guess then.

EDIT:
I tried to use the SPI communication example with the corrected device path. I get the following error:

SPI: SPI_IOC_MESSAGE Failed |: Bad file descriptor
Spi: Transaction Failed

Which is perfectly understandable as there is no device at that path. I guess that because the analogs are disabled, the SPI0 initialization is skipped and that I'll have to initialize it.
Having absolutely no experience with linux drivers and device tree, do you have any clues as to where I could look to achieve that ? Can I do the initialization in the setup() function ?

Thank you kindly for your help.

giuliomoro

There's no analog inputs on the CTAG FACE, so there should be no need to disable them. I am surprised it crashes when you do, but just leave them at default.

You'll need to load the overlay though. I'll assume you are familiar with the terminal?

if on the host you see the mounted folder BELABOOT, safely remove it

from the host, copy the attached file to the board:

scp bb-spidev0-00a0.dts root@bela.local:/opt/bb.org-overlays/src/arm/BB-SPIDEV0-00A0.dts

ssh onto the board ssh root@bela.local

once you are on the board, build and install the overlay:

rm -rf /opt/bb.org-overlays/src/arm/BB-SPIDEV0-00A0.dtbo; make -C  /opt/bb.org-overlays all install

still on the board, edit the file /mnt/boot/uEnv.txt and add this line immediately after the one that starts with uboot_overlay_addr3:

uboot_overlay_addr4=/lib/firmware/BB-SPIDEV0-00A0.dtbo

safely reboot:

reboot

On reboot, you should have two pairs SPI devices:
/dev/spidev1.* : SPI0
/dev/spidev3.* : the gpio SPI used by the CTAG

have fun

bb-spidev0-00a0.dts

1kB

zajili

Thank you so much for the instructions, it seems to work perfectly !

I'll dig in and come back here if I find myself in a pinch again.

On another note, enabling/disabling analog inputs doesn't seem to have an effect on program execution since I updated to dev.
I do find it odd though that it has no effect on the project build:

make: Nothing to be done for 'all'.

If I can be of any help to investigate on the issue please let me know.

Otherwise this issue seems pretty much solved to me. Thank you again.

giuliomoro

zajili I do find it odd though that it has no effect on the project build:

enabling/disabling it doesn't rebuild the project, it only changes the command line flags passed to the project when it's run

zajili

Ok thanks for the info.

So I've been playing a little bit with the SPI and managed to acquire the signals on a scope except the CS signal.

I've tried several pins and several device paths /dev/spidev1.0 and /dev/spidev1.1 without any success.

I tried to uncomment the following line in the .dts file above:

			pinctrl-names = "default";
			//pinctrl-0 = <&bb_spi0_pins>;

and rebuilt the dtbo files but I forgot to umount the BELABOOT device which appeared to be a mistake as I couldn't connect to board after.

Hopefully, I managed to retrieve the board by reflashing the eMMC with an SD card as described here.

Do you have any idea why I can't detect the CS line shifting state ?

giuliomoro

zajili //pinctrl-0 = <&bb_spi0_pins>;

I removed that line because the pinmuxer is already set in the base BB-BELA00A1 device tree and requesting it here would prevent the fragment from loading because the pinmuxer driver would complain that those pins are already in use

In BB-BELA00A1:

            /* Pinmux for McSPI0 (analog i/o) */
            bela_spi0_pins: pinmux_bela_spi0_pins {
                pinctrl-single,pins = <
                    0x150 0x30 /* spi0_sclk,            P9_22 | MODE0 | INPUT_PULLUP */
                    0x154 0x30 /* spi0_d0,              P9_21 | MODE0 | INPUT_PULLUP */
                    0x158 0x10 /* spi0_d1,              P9_18 | MODE0 | OUTPUT_PULLUP */
                    0x15c 0x27 /* spi0_cs0,             P9_17 | MODE7 | OUTPUT_PULLUP */
                >;
            };

so P9.22, P9.21, P9.18 are set to MODE0 (SPI) and you should see the clock and data lines there. However, P9.17 is set to MODE7 (GPIO), so it won't toggle automatically with the transmission.

You can either:

control it from the calling program, asserting it before and deasserting it after a transmission. You'd use the Gpio class as shown in the example Digital/synchronous-gpio/. P9.17 in MODE7 is GPIO0[5], so you would do gpio.open(5, Gpio::OUTPUT); gpio.set(); in setup(), then gpio.clear() before the transmission and gpio.set() after the transmission
, or

you can change that line in /opt/bb.org-overlays/src/arm/BB-BELA-00A10.dts to

                    0x15c 0x20 /* spi0_cs0,             P9_17 | MODE0 | OUTPUT_PULLUP */

then rebuild and install:

rm -rf /opt/bb.org-overlays/src/arm/BB-BELA-00A1.dtbo
make -C  /opt/bb.org-overlays all install

And then when using /dev/spidev1.0 (not .1) it should toggle that pin automatically.

zajili

I haven't been able to make it work by modifying /opt/bb.org-overlays/src/arm/BB-BELA-00A10.dts.

I did manage to do it with the software driven version though.
However, it appears that in addition to the steps you described, one needs to comment the line that states that the SPI interface uses that GPIO in /opt/bb.org-overlays/src/arm/BB-SPIDEV0-00A0.dts , like so:

        /* state the resources this cape uses */
        exclusive-use =
                /* the pin header uses */
                "P9.17",        /* spi0_cs0 */
                "P9.18",        /* spi0_d1 */
                "P9.21",        /* spi0_d0 */
                // "P9.22",     /* spi0_sclk */
                /* the hardware ip uses */
                "spi0";

And for anyone passing by, gpio.open also requires another parameter for direction so the correct call would be gpio.open(5, Gpio::OUTPUT)

From what I understand, in the expression 0x15c 0x20, the value 0x15c refers to the pin number or address, and 0x20 represents the pin configuration as a bitfield.
If that's correct, I'm confused about why pin 0x15c and pin 0x158 don't have the same configuration value, since according to the comments they should be configured identically.

To be honest, I'm not sure if I'll really need the CS pin to be hardware driven by the SPI controller but I'm quite interested in getting it to work.

I'm really thankful for your replies as I'm able to understand linux kernel a little better now.

giuliomoro

zajili However, it appears that in addition to the steps you described, one needs to comment the line that states that the SPI interface uses that GPIO in /opt/bb.org-overlays/src/arm/BB-SPIDEV0-00A0.dts , like so:

I don't believe that information is used anywhere, but I may be wrong, and that change in particular shouldn't affect it. Did you see any changes when you commented that line

zajili If that's correct, I'm confused about why pin 0x15c and pin 0x158 don't have the same configuration value, since according to the comments they should be configured identically.

doesn't matter much. The bottom three bits set the mode (the signal that is connected to the pin, e.g.: spi vs gpio), while the others set some of the 'analog' properties of the pin, see:

As the pin in SPI0_CS mode is driven at all times, the "analog" properties are mostly irrelevant.
To make sure the settings have been picked up, run grep 95c $PINS and check that it returns 0x20 as expected.

zajili

giuliomoro I don't believe that information is used anywhere, but I may be wrong, and that change in particular shouldn't affect it. Did you see any changes when you commented that line

My bad about that, I removed the comment, rebuilt the .dtbo files and rerun the code with that line in effect and don't see any changes, i.e. the CS line is driven correctly. I probably didn't zoom out enough on the scope the first time I tried driving the GPIO line in the code.

Thanks a lot for the details of pin configuration. I suppose the screenshot is from the AM33xx datasheet/reference manual ?

giuliomoro To make sure the settings have been picked up, run grep 15c $PINS and check that it returns 0x20 as expected.

Unfortunately this command doesn't return anything. Pin 0 to pin 141 seem to be set however.

giuliomoro

zajili I suppose the screenshot is from the AM33xx datasheet/reference manual ?

You wish there was something as clear as that in their datasheet / TRM. It's from derek molloy's re-interpretation of that.
See (https://github.com/BelaPlatform/Bela/wiki/BeagleboneBlackBelaP8HeaderTable.pdf and (https://github.com/BelaPlatform/Bela/wiki/BeagleboneBlackBelaP9HeaderTable.pdf

zajili

giuliomoro

By using the pin address instead of the pin offset with the command grep 95c $PINS (P9.17 is 0x95c/15c) the returned configuration seems to be the correct one:

pin 87 (PIN87) 44e1095c 00000020 pinctrl-single

I've been working on another part of the project where I need to drive a different GPIO. The given GPIO matches P9.14 pin but somehow following the same steps as for the soft driven CS pin didn't give any results.

In the BB-BELA-00A1.dts the pin seems to be configured properly. And grep 848 $PINS matches the configuration in the .dts file.

In my code I tried to configure another instance of Gpio by calling gpio.open(50, Gpio::OUTPUT) and then tried to set or clear the pin but it didn't work.

Somehow, when I try to drive the pin using the Linux driver and without my project running it seems to work fine, i.e. I can observe on the scope the value written with echo 1 > /sys/class/gpio/gpio$GPIO_NUMBER/value

giuliomoro

zajili pin 87 (PIN87) 44e1095c 00000020 pinctrl-single

That should be fine, I expect if you use /dev/spidev1.0, then the Linux driver should toggle that pin.

zajili The given GPIO matches P9.14 pin but somehow following the same steps as for the soft driven CS pin didn't give any results.

P9.14 is a Bela digital pin, so that's handled via digitalRead()/digitalWrite() from the Bela core code. That's why it works as expected only when the Bela program is not running. If you don't need any digital channel, disable them in the IDE settings; otherwise, you can free up a specific pin by passing a bitmask via --disabled-digital-channels. P9.12 is Bela digital pin 6, so it would be:

--disabled-digital-channels 0x20

zajili

giuliomoro That should be fine, I expect if you use /dev/spidev1.0, then the Linux driver should toggle that pin.

Unfortunately this does not happen. I also find it weird because the other pins are correctly driven. For now I'm managing with soft driven CS but I'm afraid I'll encounter a performance hit somewhere down the line. Anyway it should be enough to at least validate some of the ECAD design we made in the team.

giuliomoro P9.14 is a Bela digital pin, so that's handled via digitalRead()/digitalWrite() from the Bela core code.

That makes sense then ! Thank you, I got it working by disabling the digital channels with the IDE setting.
As for the option to disable specific digital channels, I guess I need to enter the option in the setting Command line argument of the IDE settings ? If that's the case then --disabled-digital-channels doesn't seem to cut it even with 0xff as a bitfield.

giuliomoro

zajili Command line argument of the IDE settings ? If that's the case then --disabled-digital-channels doesn't seem to cut it even with 0xff as a bitfield.

Yes, that should work. Not sure why you don't see work effectively. Can you send a screenshot of your settings?

zajili

Hello,

Sorry for the late reply, here is a screenshot of the IDE settings I'm using. I removed the --disabled-digital-channels 0x20 from User Command Line Arguments: as it didn't seem to have any effect.