ECSPI Slave Mode TXFIFO problem

[chris_f]

I'm having some trouble using the ECSPI on an i.MX6ULL in slave mode in a continuous streaming application.

Data received by the part is fine but I'm getting repetitions in the transmitted data i.e. words that have been written to ECSPI0_TXDATA only once are transmitted multiple times.

This post (Mailing List Archive: [PATCH v2 8/8] spi: imx: Add support for SPI Slave mode for imx53 and imx6 chi... ) mentions a possible cause but I can't see it in errata.

1. ECSPI has a HW issue when works in Slave mode, after 64
words written to TXFIFO, even TXFIFO becomes empty,
ECSPI_TXDATA keeps shift out the last word data,
so we have to disable ECSPI when in slave mode after the
transfer completes

Does this mean:

a) if I never completely fill the TXFIFO it will be OK?

b) never fill and never let it completely empty?

Any suggestion for a work-around would be welcome.

[igorpadykov]

Hi chris_f

one can check ERR009535 ecspi slave erratum in

Chip Errata for the i.MX 6ULL

Software support is described in Linux L4.14.98_2.0.0 Documentation

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[chris_f]

I'm using a custom kernel driver because slave mode was not implemented yet.

Seems there is a HW problem that for some reason is still not mentioned in the errata. This is from six years ago:

TX Issue on i.MX6 ECSPI (Slave) 

Is this described anywhere? Is there a work-around without using DMA?

[igorpadykov]

seems mentioned link is for i.MX6Q, not i.MX6ULL.

Slave mode example can be found in MX6ULL FreeRTOS  SDK

Welcome | MCUXpresso SDK Builder 

Best regards
igor

[chris_f]

I see that but I do wonder if it is related to my problems.

My application is quite high speed (144,000 32 bit transfers per second). The driver is running in an FIQ interrupt to keep up.

When I read TESTREG immediately after writing to the TXFIFO I do not get reliable results. Does sound like a similar problem to ERR009165 on the i.MX6Q part?

[chris_f]

TXFIFO and TESTREG behaviour is as expected if the i.MX6ULL is the only slave on the SPI bus.

Much like the problem of MISO not being going hi-Z when CS is high, the SPI module is all over the place if it is one of multiple slaves on the bus. e.g. write one 32 bit word to an unrelated slave on the same bus and the TXFIFO drops 6 entries. Go figure.