SPI TXCNT and RXCNT

[andyjones]

Sometimes, at the "end" of a long 16-bit SPI frame transfer, the P1011 (SPI Master) shows RXCNT = 32, TXCNT = 30, and DON =0.  I suspect the full RX buffer encountered during the transfer has caused the SPI Master to suspended the transfer of the last character, but cannot find this behaviour detailed anywhere. 

I understand that the application SW has made an assumption that if the TXCNT indicates so many bytes have been sent from the TX Buffer, then a corresponding number of bytes will have been received into the RX Buffer (and attempts to read that many bytes out of the RX FIFO without checking RXCNT), but I wonder if propagation through TX and RX shift registers upsets that assumption.

A colleague wonders if the discrepancy has instead come about though the TX side not always keeping the TX FIFO adequately filled, so that at some point, transmission continued without valid data to send.  Would that happen, or would the SPI CLK pause when the buffer is empty but the full frame has not yet been sent?

Is there a more detailed description of P1011/P1020 SPI operation that you could direct me to?

Thanks,

[Pavel]

Is there simple program example for detection similar incorrect behavior?

Attached file contains simple eSPI program code.

Have a great day,
Pavel Chubakov

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

[andyjones]

Hi Pavel,

I've not been able to get access to the rig, to test your offering.  In the mean time, what I have found is that the witnessed behaviour of the SPI_CLK stopping when the RXCNT = 32, keeping the SPI_CS0 active, appears to be consistent with SPI behaviour described in AN3904 (relating to another part of the Power Architecture range), MPC5212e SPI.  Can you confirm whether the underlined statement, and the note from AN3904 are equally applicable to our P1011 SPI behaviour?

“…we have

to count with the delay (a few processor ticks) between the Tx/Rx FIFO slices and the Tx/Rx shift

register in the SPI module. There are a few possible ways to do this. The simplest way to cover it

is to compare the amount of transmitted data and amount of received data. This is why polling

mode is not recommended for SPI mode.

NOTE

In SPI master mode the PSC controls the serial data transfers. If the Tx FIFO

becomes empty (underrun) or the Rx FIFO becomes full (overflow) in the

middle of a multi-byte transfer, rather than set the Tx underrun or Rx

overflow status bits, the PSC keeps the slave select signal low/active and

stops the SCKL serial clock. When the Tx FIFO is no longer empty and the

Rx FIFO no longer full, the transfer proceeds.”

Up to this point, at each TXTHR triggered interrupt, our code has been reading as many words from the 32-byte RX FIFO as we are able to load into the TX FIFO, and has, I was told, been robust.  However, on closer examination, it seems there may have been a filtering out of these events, and only reporting a series of events in a row.  So, we are gearing up to check if the events are happening but are getting filtered out by Software. 

Is it possible to determine when the TXCNT decrements relative to the TX of the byte that triggers the Interrupt, and how long is it before the corresponding RX buffer has a matching number of received bytes?  Is this a timing formula based on SPI clock cycles, CCB, or other?

Thanks,

Andy