Dear Texas Instruments Support,
We are currently developing a system that utilizes two TMS570LC43x microcontrollers, one configured as an SPI master and the other as an SPI slave, communicating via the mibSPI peripheral in a QSPI configuration. We have encountered an issue where a single bit shift occurs in the received data under specific conditions.
Hardware Configuration:
- Master and Slave: TMS570LC43x microcontrollers
- Connection: mibSPI peripheral used in compatibility mode in a QSPI setup
Software Configuration:
- Custom SPI driver
- mibSPI settings: VCLK at 75 MHz, 16-bit word length, baud rate prescale set to 8, WDELAY set to 3, and handshake via the ENA pin
Issue Description: The issue presents itself consistently whenever the SPI master abruptly stops a transmission mid-transaction. Per errata MIBSPI#137, we disable DMA and SPI, halting DMA requests first and then clearing the SPIEN field of SPIGCR1. While this method works under normal conditions, the edge-case scenario described causes the master to receive a shifted frame in the subsequent transaction, inserting an erroneous '0' bit in the RX data.
Tests Conducted:
- We have observed that manipulating the WDELAY value can seemingly resolve the issue; however, we are concerned this may not be addressing the underlying cause, which we suspect may be a race condition.
- We have ruled out DMA issues, as the problem persists with a single bit shift.
- We have implemented a reset workaround (powering down the SPI or resetting through SPIGCR0), which seems to resolve the problem, and points at the SPI module as being the source of the issue.
- Polarity and phase configuration changes have been tested, with Phase = 0 exacerbating the problem.
- Direct oscilloscope analysis is not possible at this time, but a full reset of the SPI module at the slave side (while only toggling SPIEN for the master between transactions) has not resolved the issue. We feel that this rules out any issue propagating from the slave.
Questions:
- Is there any known buffering issue or race condition that could lead to a bit being incorrectly buffered and shifted into the subsequent transaction?
- Are there any additional debugging steps that we can take without direct oscilloscope access to further isolate the problem?
- Is there a recommended approach for handling mid-transaction interruptions and subsequent SPI transactions that might address or avoid this issue?
We are seeking your technical expertise to understand and rectify this issue. The anomalous behavior appears to be tied inherently to the SPI master's mid-transaction interruptions, and it is critical for our system's reliability to find a robust solution. We appreciate any insights, recommendations, or further diagnostic steps that TI can provide.
Thank you for your assistance and we look forward to your prompt response.
Best regards
