AnsweredAssumed Answered

Timing problem on Sharc SPI in slave mode

Question asked by NormC on Oct 8, 2015
Latest reply on Oct 20, 2015 by Harshit.Gaharwar

I'm using one of the SPIs on a 21489 Sharc for communication with a microprocessor. On the Sharc the SPI runs in slave mode. On rare occasions, when the master asserts CS/ just as the Sharc is about to write a value into the TX register, the value is lost: the SPI transfers a zero word instead. I'm writing the value only if the TXS is 0, of course. But it seems there is a race condition under which TXS cannot be relied on. The HW Ref Manual 1.1 describes this (pg 16-22, under Transmit Collision Error), but not well. For instance, what does this mean? "In this case TXS is not set and attempts to send new data and it isn’t clear if this write to TXSPI takes place when the load to the shift register is occurring (in other words a TXCOL condition)"


In any case the documented workaround (if TUNF is set, don't rely on TXS, but rather wait until SPIF goes low before writing to the TX buffer) does not seem to work. TXCOL still gets set, and the data value is lost, replaced by a zero on the SPI bus.


Is there any more detailed info that would help me develop a workaround? For instanced, what is the timing of TXS, TUNF, TXCOL and SPIF? When is SPIF cleared? Is there any example code that illustrates how to use this workaround?