Other Parts Discussed in Thread: AFE5401-Q1
Tool/software: Linux
I am getting a SPI slave read issue on AM5728, where AM5728 is the master. The SPI readback shows shifted and flipped bits, however the data is OK when viewed from a scope.
In single SPI transaction I send 0x09 0x00 0x08 (1 byte ADDR, 2 byte DATA), and expect to get back 0x00 0x00 0x08. However, the driver reads back 0x00 0x00 0x60. Below scope screenshot is the MISO, clock, CSEN when viewed from scope, the last byte is clearly 0x08 however the driver has read back 0x60. When changing the bit I get the following transformation:
0x01 (scope) -> 0x01 (driver)
0x02 (scope) -> 0x06 (driver)
0x04 (scope) -> 0x18 (driver)
0x08 (scope) -> 0x60 (driver)
Setup:
- SPI mode is 3 (clock idle high, latch on rising edge), freq 50kHz
- Linux spidev driver, device tree:
0x3a4 (PIN_INPUT | MUX_MODE0) /* spi1_sclk */
0x3ac (PIN_INPUT_PULLDOWN | MUX_MODE0) /* spi1_d0 */
0x3a8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* spi1_d1 */
0x3b0 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* spi1_cs0 */
&mcspi1 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&mcspi1_pins_default>;
ti,spi-num-cs = <1>;
spidev1_0: spidev1@0 {
compatible = "spidev";
reg = <0>;
spi-max-frequency = <20000000>;
spi-cpha;
spi-cpol;
};
};
A snippet of driver registers during the read:
mcspi_write_cs_reg 2C 201103FF
mcspi_read_cs_reg 2C 201103FF
spidev spi1.0: setup: speed 50000, sample trailing edge, clk inverted
mcspi_write_cs_reg 2C 201103FF
mcspi_read_cs_reg 2C 201103FF
mcspi_write_cs_reg 34 3B01
mcspi_read_cs_reg 34 3B01
spidev spi1.0: write-8 09
spidev spi1.0: read-8 00
spidev spi1.0: write-8 00
spidev spi1.0: read-8 00
spidev spi1.0: write-8 08
spidev spi1.0: read-8 60
mcspi_write_cs_reg 34 3B01
mcspi_read_cs_reg 34 3B01
mcspi_write_cs_reg 34 3B00
mcspi_read_cs_reg 34 3B00
mcspi_write_cs_reg 34 0
mcspi_write_cs_reg 2C 201103CB
mcspi_read_cs_reg 2C 201103CB
spidev spi1.0: setup: speed 16000000, sample trailing edge, clk inverted
mcspi_write_cs_reg 34 0
mcspi_read_cs_reg 34 0
Is there anything wrong with my configuration that would case this, or any hints as to the issue? Since the scope is showing correct read out this seems like SPI module / driver is not correctly latching the receive data.
