Pinmuxing for SPI, UART, and GPIO Access

ben.d.manley · April 21, 2018, 8:49pm

I’ve been trying to use the SPI pins on the BeagleBoard-X15, but as far as I can tell I have not been changing the correct pins to the correct muxmodes.

On the TI PinMux Tool, I set it up for spi4 (pin AA4 for CS0, AB3 for D0, AB9 for D1, and AA3 for SCLK. These, as far as I can tell from this spreadsheet, correspond to the extension pins 17.39, 17.40, 17.09, and 17.10, respectively.). I see the autogenerated files on the right side, but I’m not sure what parts of that information must be put into the device tree file, or exactly how syntactically to do that. The most relevant information seems to be in the genericFileFormatPadConf.txt file:

0x4A003744 0x50002 AA3 CTRL_CORE_PAD_MCASP5_ACLKX mcasp5_aclkx spi4_sclk
0x4A00374C 0x50002 AB3 CTRL_CORE_PAD_MCASP5_AXR0 mcasp5_axr0 spi4_d0
0x4A003748 0x10002 AB9 CTRL_CORE_PAD_MCASP5_FSX mcasp5_fsx spi4_d1
0x4A003750 0x10002 AA4 CTRL_CORE_PAD_MCASP5_AXR1 mcasp_axr1 spi4_cs0

(That is with Rx checked off for D0 and SCLK)

The file I’ve been editing is the am57xx-beagle-x15-revc.dtb. Right now, this is the spi4 module in my .dtb:

spi@480ba000 {
pinctrl-names = “default”;
pinctrl-0 = <&mcspi4_pins>;
compatible = “ti,omap4-mcspi”;
reg = <0x480ba000 0x200>;
interrupts = <0x0 0x2b 0x4>;
#address-cells = <0x1>;
#size-cells = <0x0>;
ti,hwmods = “mcspi4”;
ti,spi-num-cs = <0x1>;
dmas = <0xb1 0x46 0xb1 0x47>;
dma-names = “tx0”, “rx0”;
status = “okay”;
linux,phandle = <0x1ea>;
phandle = <0x1ea>;

mcspi4_pins: mcspi4_pins {
pinctrl-single,pins = <
… (SEE BELOW) …

;

};

spidev@0 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = “linux,spidev”;
spi-max-frequency = <0x1312d00>;
reg = <0x0>;
status = “okay”;
};

};

Inside of that mcspi4_pins block, inside of pinctrl-single,pins, I’ve tried a multitude of different syntaxes and modes. At first, I started with this block because documentation online said it was correct:

However, this gives a “cannot parse input tree” error when attempting to compile from dts to dtb.

I’ve tried putting variations of the PinMux Tool information in there, but nothing has worked. Besides editing the dtb file (I am actually editing a copy called am57xx-beagle-x15-revc-ben.dtb), I have changed the /boot/uEnv.txt file to use am57xx-beagle-x15-revc-ben.dtb (and I have tested and proven that my edited file is used or booting), I have edited the config-4.9.35-ti-r44 file by changing the CONFIG_SPI_SPIDEV and similar configuration lines from “= m” to “= y”.

The furthest I have gotten is being able to see the correct spidevX.X folders in /dev. I’m not sure how to get this part of my system working.

As a final addition, I wanted to ask if the process for accessing UARTs and GPIOs is similar / how that should be done.

Thank you!

jkridner · April 22, 2018, 8:51pm

I’ve been trying to use the SPI pins on the BeagleBoard-X15, but as far as I can tell I have not been changing the correct pins to the correct muxmodes.

On the TI PinMux Tool, I set it up for spi4 (pin AA4 for CS0, AB3 for D0, AB9 for D1, and AA3 for SCLK. These, as far as I can tell from this spreadsheet, correspond to the extension pins 17.39, 17.40, 17.09, and 17.10, respectively.). I see the autogenerated files on the right side, but I’m not sure what parts of that information must be put into the device tree file, or exactly how syntactically to do that. The most relevant information seems to be in the genericFileFormatPadConf.txt file:

0x4A003744 0x50002 AA3 CTRL_CORE_PAD_MCASP5_ACLKX mcasp5_aclkx spi4_sclk
0x4A00374C 0x50002 AB3 CTRL_CORE_PAD_MCASP5_AXR0 mcasp5_axr0 spi4_d0
0x4A003748 0x10002 AB9 CTRL_CORE_PAD_MCASP5_FSX mcasp5_fsx spi4_d1
0x4A003750 0x10002 AA4 CTRL_CORE_PAD_MCASP5_AXR1 mcasp_axr1 spi4_cs0

(That is with Rx checked off for D0 and SCLK)

The file I’ve been editing is the am57xx-beagle-x15-revc.dtb. Right now, this is the spi4 module in my .dtb:

spi@480ba000 {
pinctrl-names = “default”;
pinctrl-0 = <&mcspi4_pins>;
compatible = “ti,omap4-mcspi”;
reg = <0x480ba000 0x200>;
interrupts = <0x0 0x2b 0x4>;
#address-cells = <0x1>;
#size-cells = <0x0>;
ti,hwmods = “mcspi4”;
ti,spi-num-cs = <0x1>;
dmas = <0xb1 0x46 0xb1 0x47>;
dma-names = “tx0”, “rx0”;
status = “okay”;
linux,phandle = <0x1ea>;
phandle = <0x1ea>;

mcspi4_pins: mcspi4_pins {
pinctrl-single,pins = <
… (SEE BELOW) …

;

};

spidev@0 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = “linux,spidev”;
spi-max-frequency = <0x1312d00>;
reg = <0x0>;
status = “okay”;
};

};

Inside of that mcspi4_pins block, inside of pinctrl-single,pins, I’ve tried a multitude of different syntaxes and modes. At first, I started with this block because documentation online said it was correct:

0x344 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE2)
0x348 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE2)
0x34c (PIN_OUTPUT_PULLUP | MANUAL_MODE | MUX_MODE2)
0x350 (PIN_OUTPUT_PULLUP | MANUAL_MODE | MUX_MODE2)

However, this gives a “cannot parse input tree” error when attempting to compile from dts to dtb.

Which file did you see that syntax? Was there an include file specified that defined the macros?

I’ve tried putting variations of the PinMux Tool information in there, but nothing has worked. Besides editing the dtb file (I am actually editing a copy called am57xx-beagle-x15-revc-ben.dtb), I have changed the /boot/uEnv.txt file to use am57xx-beagle-x15-revc-ben.dtb (and I have tested and proven that my edited file is used or booting), I have edited the config-4.9.35-ti-r44 file by changing the CONFIG_SPI_SPIDEV and similar configuration lines from “= m” to “= y”.

The furthest I have gotten is being able to see the correct spidevX.X folders in /dev. I’m not sure how to get this part of my system working.

What syntax are you using to send SPI data? Can you share the kernel log provided by ‘dmesg’?

There’s a way to dump the active pinmux modes (register values). I’ll try to find it.

As a final addition, I wanted to ask if the process for accessing UARTs and GPIOs is similar / how that should be done.

Should be similar.

ben.d.manley · April 22, 2018, 9:43pm

The syntax with the device tree came from using dtc to create a .dts file from am57xx-beagle-x15-revc.dtb (that I copied and edited into am57xx-beagle-x15-revc-ben.dtb). The syntax with the 0x4A003744… came from genericFileFormatPadConf.txt on the TI PinMux Tool, and it did not include any /include files. The syntax with the 0x344 (PIN_INPUT_PULLUP…), I found online from multiple people saying it worked for them.

For SPI data, I’m using a Python SpiDev library. As of right now, I was essentially just using writebytes([0x01]) and readbytes(8) to attempt to get a message from a SPI device. It connects to the spidevX.X folders in /dev, but no data is coming through it.

I’ve attached the dmesg output to this post. (Ignore the lines with errors like cs2 >= max 2 involving spi - those are from SPI1, SPI2, and SPI3, where I haven’t yet changed the configuration to have more than 1 chip select each). The lines that I noticed were:

[ 2.414171] pinctrl-single 4a003400.pinmux: please update dts to use #pinctrl-cells = <1>

and

[ 9.599171] spi_master spi4: cannot find modalias for /ocp/spi@480ba000/mcspi4_pins
[ 9.608313] spi_master spi4: Failed to create SPI device for /ocp/spi@480ba000/mcspi4_pins
[ 9.608345] spi spi4.0: not using DMA for McSPI (-19)

dmesgoutput.txt (35.2 KB)

MHE · April 22, 2018, 10:52pm

Hi Ben,

My guide can help you :

https://github.com/mhe747/dawnboard/blob/master/BeagleSDR_KernelHack.md

After my tests on SPI, which doesn’t show any voltage activities detected by my osciloscope. MCSPI maybe not working in Beagleboard-x15, the pin configuration maybe missing from the Kernel ?
So good luck, and tell us if you manage to.

BR,

Mich.

jkridner · April 25, 2018, 5:21pm

Ben,

Just a bit of a primer on editing your dtb.

You should probably start by updating your kernel.

cd /opt/scripts
git pull
cd tools
sudo ./update_kernel.sh --lts-4_14

REBOOT

You should be editing the dts via /opt/source/dtb-4.14-ti.

cd /opt/source
git clone https://github.com/RobertCNelson/dtb-rebuilder.git dtb-4.14-ti
cd dtb-4.14-ti
cp src/arm/am57xx-beagle-x15.dts src/arm/am57xx-beagle-x15-ben.dts

EDIT src/arm/am57xx-beagle-x15-ben.dts

make
sudo make install

I believe you already know how to specify your dtb in /boot/uEnv.txt.

dtb=am57xx-beagle-x15-ben.dtb

jkridner · April 25, 2018, 5:23pm

Ben,

Just a bit of a primer on editing your dtb.

You should probably start by updating your kernel.

cd /opt/scripts
git pull
cd tools
sudo ./update_kernel.sh --lts-4_14

REBOOT

You should be editing the dts via /opt/source/dtb-4.14-ti.

cd /opt/source
git clone https://github.com/RobertCNelson/dtb-rebuilder.git dtb-4.14-ti
cd dtb-4.14-ti
cp src/arm/am57xx-beagle-x15.dts src/arm/am57xx-beagle-x15-ben.dts

ooops, should be:

cp src/arm/am57xx-beagle-x15-revc.dts src/arm/am57xx-beagle-x15-ben.dts

jkridner · April 25, 2018, 5:26pm

Can you provide the contents of /sys/kernel/debug/pinctrl/4a003400.pinmux/pins ?

jkridner · April 25, 2018, 5:41pm

Heard you reboot without having the dtb specified available for the new kernel. Sorry for sending you down that path.

Grab an X15 image off of https://beagleboard.org/latest-images and use http://etcher.io to write it to a microSD.

After you boot…

sudo mount /dev/mmcblk1p1 /mnt

EDIT /mnt/boot/uEnv.txt to comment out the dtb= line

sync

REBOOT

Then you can get about the business of editing your new dtb. Wish the bootloader config was smart enough to use the default when the manually supplied option cannot be found.

MHE · April 25, 2018, 6:26pm

Hi Jason,

Thank you for the link. However after checking out the file am57xx-beagle-x15.dts
I can’t find any pin muxing for mcspi4. What does it do ? Did you try by yourself the mcspi ? Did you manage to have it worked ?

BR,

MHE · April 25, 2018, 6:34pm

Attached file is my pinmux file “4a003400_pinmux.txt” … Can you imagine the cause ?

4a003400_pinmux.txt (13.9 KB)

ben.d.manley · April 25, 2018, 6:42pm

I have attached the pins file as you requested - this is after editing the .dts, making the dtb in the boot directory, editing uEnv.txt accordingly, and rebooting.

pins (13.9 KB)

MHE · April 25, 2018, 10:16pm

Tested the new version of Kernel 4.14 of RobertCNelson,
however the matrix-app-launcher doesn’t work, seems something broken with the non-official TI Kernel.
maybe opencl examples don’t work too.

ben.d.manley · April 26, 2018, 3:37am

Ended up flashing the new X15 image onto it (nothing to lose, so just reset it all). Changed the pinmux configuration, compiled the dtb, and rebooted. The pin information in /sys/kernel/debug/pinctrl/4a003400.pinmux changed from its original state, so hopefully it worked. About to test the clock signal with an oscilloscope. Attached is the dmesg output of the board right now.

dmesg_output.txt (31.6 KB)

MHE · April 26, 2018, 5:37am

Hi Ben,

May I have a snapshot (plz, use your smartphone to take photo) of your oscilloscope showing activities of SPI ? also which pin did you test ? on which port ? P17 ?

Thanks

PS: btw is it normal that rpmsg was disabled ? and did you see the matrix gui ?

MHE · April 27, 2018, 7:49pm

Hi,

I think the SPI Pin Mux may not properly work in the TI Processor-SDK 4.xx kernel. It may have something related to.
Indeed, I have following traces in my Kernel that Ben seems not having met at all :

[ 2.869937] pinctrl-single 4a003400.pinmux: could not add functions for mcspi4_pins 4294960020x

That should stands for pin mux fault in the linux kernel of TI Processor SDK. Either they use a Kernel locked version,
either the CPU pins were not exactly same as those mentionned in the datasheet.

I just can’t use another Kernel version because the one inside of Processor SDK comes with all AM5728 cores firmware.
It is the multi-core enabled version…

What a pity we can’t afford the spi feature. I remember those good old days, when the 1st Beagleboard came already with SPI,
and used to work flawlessly. Whatever…

Thank you Jason and Ben for all !

Mich.

ben.d.manley · April 29, 2018, 4:51am

Unfortunately I am no longer with the oscilloscope. I was sending out one byte at a time, so if I ever saw anything on the oscilloscope it was just one line that would instantly appear and disappear. This worked for multiple different MCSPI4 pin sets on P17

ben.d.manley · April 29, 2018, 5:16am

For both UART3 and MCSPI4, I was able to see signals out on the oscilloscope when working with the py-serial and py-spidev libraries after changing the dts and dtsi in opt/source/dtb-4.14-ti/src/arm. Still figuring out exactly why Im not getting data back from the devices, but I will reach out to the manufacturers of those devices about that.

On a semi-related note:

Upon adding many different pin sets to the TI PinMux Tool (multiple SPI buses, a UART, a few GPIO, a SATA, and two USB), I have run into a set of pin conflicts that I'm not sure about.

When using all of these sets, there are inevitable pin conflicts between the pins on the extension headers (16, 17, 18, and 19). However, there are certain pins that seem to not be on the extension header (like led usr 0 and 1, and HDMI ct hpd, pins that can have SPI1 muxmodes), but are these actually usuable and accessible?

Also, I don't think I have a full understanding of how a sensor would talk over a USB connection (unless it works in /dev/ttyUSB* and is serial), how a hard drive would talk over SATA, or exactly how those work with pinmuxing (if its as straightforward as with SPI and UART or if there's extra stuff that needs to be done)

Thanks!

MHE · April 29, 2018, 10:20am

Ben,

I think the pin-muxing is just a mess. We all have same issue. SPI never hits interrupt, that’s why no data back to get received. Worse than that, I don’t even detect any voltage activities of SPI output.

Nobody seems to know how and why that works or not.
I tested on all 4 ports. Really no spi signal anywhere… I use the TI Kernel Linux am57xx-evm 4.9.59-ga75d8e9305.

I eventually recommend to contact TI forum. Just keep us in your pipe. For now, I give up the SPI feature. What a pity, really.

zmatt · May 20, 2018, 7:56pm

Device tree fragment:

https://github.com/mvduin/py-uio/blob/master/dts/bbx15-spi-test.dtsi

PRU firmware:

https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/bbx15-spi-test.pasm

Test script:

https://github.com/mvduin/py-uio/blob/master/pru-examples/bbx15-spi-test.py

If you haven’t used py-uio before, be sure to install this udev rule:
https://github.com/mvduin/py-uio/blob/master/etc/udev/rules.d/uio-pruss.rules

Hope this is useful

Matthijs

jkridner · May 21, 2018, 3:06pm

Great tips, thanks!