TX Issue on i.MX6 ECSPI (Slave)

[cedricatmentor]

ssue description
======================
In Slave mode writing to ECSPIx_TXDATA(TXFIFO) works as expected - words are shifted from TXFIFO to MISO line during transfers initiated by SPI Master. But this works only for first 64 words written to ECSPIx_TXDATA. After writing to ECSPIx_TXDATA for 65th time, iMX starts always sending 65th word on MISO. TXCNT in ECSPIx_TESTREG shows that TXFIFO is empty (==0). Subsequent writings to TXFIFO will not work (iMX will still send 65th word on MISO line).

SPI configuration
======================
SPI Bus - ECSPI2
SS_POL=0
SS_CTL=0
SCLK_POL=0
SCLK_PHA=0
BURST_LENGTH=0x01F // 32bit
CHANNEL_MODE = 0 //Slave mode

Steps to reproduce
======================
1) Configure SPI channel (ECSPI2) as a Slave;
2) Set BURST_LENGTH=0x01F;
3) Initiate one transfer with 64 words in tx_buf or 64 tranfers with 1 word or 16 tranfers with 4 words. I.e. TXFIFO should be written 64 times.
4) Next write to TXFIFO should make iMX to always shift this 65th word to MISO line.

[cedricatmentor]

Hi Vladan,

My customer is inquiring what are Freescale plans regarding this HW issue. Do you believe HW would be fixed or would you instead have the SW work-around documented? As indicated above, Alexey has made good progress implementing the SW work-around that uses DMA and so far no issues were observed. On our side, we will have to prove out our SW work-around to our customer as they want to make sure that it won't impact system performance.

Thanks!

Cedric

[VladanJovanovic]

Hi Cedric,

I'll need to wait for our teams to provide more feedback on this issue. Unfortunately no comments yet, but I'll update you as soon as possible.

best regards,

Vladan

[cedricatmentor]

Again, new details:

• When issue is happening (i.e. garbage is sent when there is no explicit TX activity), TXFIFO full bit is cleared, and number of words in TXFIFO is 0, meaning that TXFIFO is empty;
• Clock disable/enable between transfers doesn't help;
• Complete disabling of SPI block (EN bit in ECSPIx_CONFIGREG) fixes the issue for the next 64 words. Then it starts to happen again;

[VladanJovanovic]

Hi Cedric,

let me try to understand the issue: problem you are seeing is that, with empty TXFIFO in slave mode, ECSPI is sending out last written word, instead of zeros?

Looking at some of the later comments you sent it looks like writing to TXFIFO will work.

What kind of data transfer are you trying to achieve here (why is current behavior of ECSPI not acceptable)?

best regards,

Vladan

[cedricatmentor]

Hi Vladan,

Both Alexey and I tried to provide more details. Do you now have a better understanding of the use-case and issue we are facing? Do you need additional details? Are we incorrectly using the HW somehow? Any recommendations?

[VladanJovanovic]

Hi Cedric,

I'm waiting for comments from our teams. Documentation does mention that ECSPI in slave mode should shift out zeroes when FIFO is empty, but that does not seem to be the case according to what you're seeing.

Regards,

Vladan

[cedricatmentor]

Hi Vladan,

When do you expect feedback from your team? Is it reasonable to expect something tomorrow (November 15th)?

Thanks

Cedric

[VladanJovanovic]

Hi Cedric,

I think beginning of next week we should have some more comments. In any case, this does seem to be an issue with SPI that would require a workaround in the end. Is the current approach you have for workaround OK for you?

One approach recommended by our team was to use TX THRESHOLD DMA event or interrupt detect that the TXFIFO is about to underrun and continuously write zeroes to the FIFO until the new data is ready, preventing the FIFO from under-running.

best regards,

Vladan

[alexeyfirago]

Hi Vladan,

Many thanks for this update. We actually redesigning our driver to use DMA, and we've workarounded TX issue in the way similar to what you suggested (constant DMA from buffer with zeros to TXFIFO). So far TX issue is not observed anymore with this workaround.

Best regards,

Alexey

[laufei]

Hi, Alexey

I am debugging the DMA SPI function, it doesn't work now which the spi can't send data out. So can you send your driver of i.MX6 SPI DMA function for my reference if possible?

Thank you very much.

Kind Regards

Fe la

[cedricatmentor]

Hi Vladan,

Thanks. Good to know that you have people from your team looking into this. Let us know if you need additional details (e.g. register dumps).

Regards,

Cedric

[cedricatmentor]

Hi Vladan,

First many thanks for your support. The issue we have is that ECSPI is unexpectedly repeating the last byte from our previous transaction. I have asked the engineer (Alexey Firago) working on this issue on our side to check your question and feedback (he's the one who actually provided me the details that I have posted above).

Our project involves a Freescale PPC5517 running AUTOSAR 3 and acting as SPI master and a Freescale i.MX6Q running Android ICS and acting as SPI slave. The communication protocol we use is ASAM XCP: a simple command/response protocol. The SPI master sends at regular intervals commands or dummy frames (at a rate of 1.5mbps). The dummy frames allow the SPI slave to asynchronously write responses back to the SPI master or initiate its own commands (such as the XCP connect command when Android is up).

Cedric

[alexeyfirago]

Hi all,

Cedric already described our usecase, so I will just add some details and summarize:

• When TXFIFO is empty, iMX sends wrong value instead of zeros;
• "Wrong value" is not the last word from previous transaction, but 64*N-th word (counting from enabling of eCSPI);
• Writing to TXFIFO will work, iMX will send all written words and will start to send this wrong value again;
• We are trying to workaround this issue by always explicitly responding to each and every master's transaction in driver, but it would be great if this issue could be workarounded using some another way (register(s) writing/clearing).

Thanks,

Alexey

[cedricatmentor]

Additional details on TX issue:

• Issue was confirmed on SabreSD board;
• Issue is confirmed only with masters continuously sending data for now;
• The garbage value appeared on the bus instead of 0 is 64th word not 65th;
• Garbage value shifted to MISO instead of 0, (i.e 64th word) is replaced later with 128th word, then with 64*3-th, 64*4-th, etc;
• Subsequent writings to TXFIFO WILL work: when we are explicitly writing a value to TXFIFO iMX6 sends it correctly, but after sending everything from TXFIFO it starts to send garbage value - 64*n-th word;
• The reason why we see "sending forever" case with original spidev driver - spidev only sends data which it gets from userspace, so TXFIFO is not written explicitly when userspace utility is not called;