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.
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
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
Again, new details:
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
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?
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
Hi Vladan,
When do you expect feedback from your team? Is it reasonable to expect something tomorrow (November 15th)?
Thanks
Cedric
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
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
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
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
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
Hi all,
Cedric already described our usecase, so I will just add some details and summarize:
Thanks,
Alexey
Additional details on TX issue: