IMX6ULL ESPI Slave Mode Data Missing

[j_george]

Brief of the Issue

We are testing SPI slave mode communication on iMX6ULL using the Colibri Evaluation Board. The observation is that some bytes – supposed to be sent by the slave device – are missing and not seen on the MISO line.

 Setup

1. An ESP8266 is configured as the SPI master, with a clock frequency of 125kHz. The master simply sends a set number of bytes over SPI.
2. The Colibri device contains an image that has a custom device driver which configures the SPI registers (slave mode), and just sends some bytes to the master with some data with  pre-defined values. The TX FIFO is filled with 32 words of data initially as a part of configuration..
3. The SPI bus only contains one slave. CS pin is connected to GND so that the device is always active.

Description of the Issue

The slave device receives all the bytes sent by the master. However, in the response data sent by the slave device, some words are missing and zeros are received instead of the actual data.

There are two observations associated with the issue:

1. First two words received on the bus are missing and zeros are received instead.
2. After the first two words, every next 256th word is missing and zero is received instead.

The following table shows the first observation.

Data Put into Slave (i.MXULL) TX FIFO	Data Seen on the MISO line
aa bb cc 01	00 00 00 00
aa bb cc 02	00 00 00 00
aa bb cc 03	aa bb cc 03
aa bb cc 04	aa bb cc 04

The first observation is consistent across resets, and the second one across every cycle of 256 words.

The data was analyzed from the master device, using a logic analyzer and scope.

Please note that we are not using the standard Linux driver in our case, we have a simple driver that configures the registers and fills up the TXFIFO. When there are 16 words in RXFIFO read them and fill TXFIFO with 16 words. This is the logic. 

Debugging Steps Performed

1. Changing the SPI clock frequency. No difference observed.
2. Tweaking the SPI register configuration. No difference observed.
3. Running the experiment at varied CPU loads, including 100% load. No difference observed.
4. Check the SPI FIFO configuration, interrupt handling, DMA configuration, do driver code review, test with different data patterns.  : Everything has been tried out. Could not fix the issue.
5. “SPI slave mode on i.MX6UL is affected by errata ERR009535, the burst completion by SS signal in slave mode is not functional” as per ERR009535 in the errata. Went through the errata, and confirmed that it does not apply to our issue as we are not de-asserting the SS line at any time. The slave is always kept active. Burst length is set to 32 bits, and the master transmits data continuously.
6. The TX FIFO is never empty, since it is filled initially and for every read from the RX FIFO, we are filling the TX FIFO also with data.
7. We checked if any of the flags like TXFIFO Empty, RXFIFO FULL, etc. are asserted, but none observed. 
8. The register configuration is attached. The dividers are configured properly.

[Alejandro_Salas]

Hello @j_george 

I hope you are doing very well.

Please refer to the chapter 3.2.1 TXFIFO issue in slave mode of AN13633 (Using Enhanced Configurable SPI (ECSPI) as Slave in Linux). That application note describe perfectly the issue you are having:

Also the chapter 3.2.3.1:

It appears it is an issue on the TXFIFO and spi-imx driver.

I hope this can helps to you.

Best regards,

Salas.

[j_george]

Hello Alejandro_Salas,

Thank you. We had seen this Application Note and we ran some tests:

About 3.2.1 - The issue describes that the last data repeats after 64 words and that it happens with the TX FIFO is empty. But in our case, we ensure that TXFIFO is always at least 50% full. It is never empty and we confirmed this by monitoring the TXFIFO EMPTY status flag. The FIFO never indicates an empty. In our case, a word is just vanished. The next word is as expected. 

About 3.2.3.1: This is where we have a doubt. In our case, the burst length is configured as 32Bits. And RX Threshold to 15. So the intention is that our SPI transfers are all 4bytes (1 word) and we get interrupts at 16 Words (1/4th of FIFO FULL). And in the ISR we fill the TXFIFO with next 16 words to send, to that TXFIFO is never empty. The SS is tied to Ground. So the SS is not toggling. Is that an issue? We are aware that there is an errata that says, SPI transfers cannot be ended with the SS Edge and should depend only on Burst Length. This is why we have disregarded the SS and also because this is a Point to Point link. So as per the errata, we should be safe. 

I saw that the spi-imx slave driver in Linux is limiting the transactions to max 64 words and at the end, the ECSPI block is disabled and enabled. In our case,  even the first 2 words are missing after disabling and enabling the block. 

[Alejandro_Salas]

Hello @j_george 

The SS has a different behavior when working as Slave instead of Master, are you using the dedicated SS of the ECSPI module or do you have a GPIO as SS?

Is possible to share your Device Tree related to your ECSPI configuration? 

I am not sure if this weird behavior is caused from the SS signal, but you can try to to untied of ground and control it from your master device.

Best regards,

Salas.

[j_george]

Hello, 

We tried with controlling the Chip Select from the master and we still see that the second word from the slave (IMX6ULL) is missing.

Here is the capture from the logic analyzer.

So the CS is not solving our issue here. 

[j_george]

Hello,

After a lot of testing, we seem to see that when the CS is toggled, there is ever so slight improvement but not great. 

With CS:  We get around 16 words of Zeroes and then the data comes out without any errors. 

Without CS:  The first two words are wrong and then the data comes properly. But also every other 128th word is also Zero instead of the actual data.

So can you please confirm if in the slave mode, CS toggling is an absolute necessity or not?  We were planning to keep the CS held low all the time.