This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-AM335X: AM335x SPI data input

Part Number: PROCESSOR-SDK-AM335X

Hi.

I am attempting to receive data via the SPI interface in master mode. I am using the mcspi driver in git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git branch ti-linux-5.10.y.

First question:

What is the role of SPIDATDIR0 and SPIDATDIR1 in MCSPI_SYST? On the surface, it would appear as though one or the other has to be set as an input when the SPI data is bidirectional. However, spi-omap2-mcspi.c does not set this register. This is even though the driver supports bidirectional data as evidenced by its handling of the ti,pindir-d0-out-d1-in property. For that property, it sets only the IS, DPE0 and DPE1 bits of the MCSPI_CH(i)CONF register. Is that a bug?

I am using SPI0 and the driver sets MCSPI_CH0CONF set to 0x201603fc. That is, IS = 1 (data line 1 for reception), DPE1 is 1 (no tx on SPIDAT[1]) and DPE0 is 0 (tx on SPIDAT[0]). I have changed MCSPI_SYST to 0x20 (SPIDAT[1] is input). I also tried it without that change.

My pin mux is: AM33XX_PADCONF(AM335X_PIN_SPI0_D1, PIN_INPUT_PULLUP, MUX_MODE0).

With a 'scope, I observe that SPI0_D1 is fixed high (due to the pull up). However, the driver reads all zeros in every read of MCSPI_RX0.

Second question: Given the above configuration, what can cause the data at D1 to not appear as receive data in MCSPI_RX0?

Thanks,
    Steve

  • I figured it out.  The problem was that the SPI clock pad mux was set to output instead of input.  We are the master, so the clock is indeed an output.  However, specifying input for the pad mux is really enabling the input path.  It seems that the SPI controller is getting the receive clock from the I/O pad even when it is internally clocked.