1

I have an SPI bus between a MAX V device and an AM335x processor. The MAX V device has an SPI setup to repeatedly send a STD_LOGIC_VECTOR defined as "x0100". This seems to work fine. The output on a scope is repeatedly the same value.

In Linux, I seem to get either shifted data, or some random data. Using spi-tools from here https://github.com/cpb-/spi-tools

When these tools are used, I get the following:

# spi-config -d /dev/spidev0.0 -m 1 -s 10000000
# spi-pipe -d /dev/spidev0.0 -b 2 -n 1 < /dev/urandom | hexdump
0000000 0202
0000002
# spi-pipe -d /dev/spidev0.0 -b 2 -n 1 < /dev/urandom | hexdump
0000000 0a0a
0000002
# spi-pipe -d /dev/spidev0.0 -b 2 -n 1 < /dev/urandom | hexdump
0000000 2a2a
0000002
# spi-pipe -d /dev/spidev0.0 -b 2 -n 1 < /dev/urandom | hexdump
0000000 aaaa
0000002
# spi-pipe -d /dev/spidev0.0 -b 2 -n 1 < /dev/urandom | hexdump
0000000 aaaa
0000002

You can see how the device is configured there. On the scope, the MISO pin is clearly outputting "00000010 00000000" for every 16 clock cycles on SCLK. What is happening here? How can I repeatedly get the correct value from the device?

For clarity, here is the relevant parts of the device tree and the kernel configuration.

Kernel

CONFIG_SPI=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_GPIO=y
CONFIG_SPI_BITBANG=y
CONFIG_SPI_OMAP24XX=y
CONFIG_SPI_TI_QSPI=y
CONFIG_SPI_SPIDEV=y
CONFIG_REGMAP_SPI=y
CONFIG_MTD_SPI_NOR=y
CONFIG_SPI_CADENCE_QUADSPI=y

Device Tree

&spi1 {
    /* spi1 bus is connected to the CPLD only on CS0 */
    status = "okay";
    pinctrl-names = "default";
    pinctrl-0 = <&spi1_pins>;
    ti,pindir-d0-out-d1-in;
    cpld_spidev: cpld_spidev@0 {
        status = "okay";
        compatible = "linux,spidev";
        spi-max-frequency = <1000000>;
        reg = <0>;
    };
};

Also here is a screengrab of the waveforms produced. enter image description here

Really the end goal is an app to report the version stated as the STD_LOGIC_VECTOR, on the MAX V device. So 0100 is intended to be version 1.00.

Ollie Sharratt
  • 95
  • 14
  • `0xAAAA` and so on are quite suspicious from HW point of view, i.e. they are looks like meander signal, which may point to pin misconfiguration (you got CLK as data). – 0andriy Feb 17 '21 at 11:50
  • I agree. I’m not sure if Linux is doing something odd here. The device tree / pinmux are 100% based on the hardware – Ollie Sharratt Feb 18 '21 at 00:17

1 Answers1

0

Use the uboot_overlay in /boot/uEnv.txt called BB-SPIDEV0-00A0.dtbo.

If you need any more info, please ask. Oh! And there is a fellow, Dr. Molloy, that had produced a book a while back.

chp08/spi/ is the location of the file you will need to test the SPI Device.

The command is simply spidev_test

De Funct
  • 452
  • 2
  • 10
  • https://www.oshwa.org/a-resolution-to-redefine-spi-signal-names/ is a thing now. Heads up! – De Funct Feb 17 '21 at 21:10
  • Thank you. Maybe I am misinterpreting this but using a cape overlay for the beaglebone when this is a custom board is a strange approach, however I will look into modifying my own device tree to be similar. – Ollie Sharratt Feb 18 '21 at 00:17
  • Oh...you have a custom board. Okay. No issue. I see you are using the am335x. Okay. Did you try the online, TI.com pinmux tool? It shows the 'overlay' needed or .dts file associated w/ your custom config. – De Funct Feb 18 '21 at 20:13