TMS320F280039C: SPI TX data abnomal

Hi Liu,

Apologies for the delay, this thread was just routed to me. Configuration wise, ensure that the clock phase, polarity, CS settings, etc. match on both devices. Have you checked that the controller device is sending the data correctly? If so, have you checked the target device's registers to see if the data is incorrect in SPIDAT, SPIRXBUF, or both. How much data are you transmitting/receiving at a time? Ensure it matches across the devices, and the correct bit-shift is applied when receiving 16 or more bits at a time on the C2000 side. Please work with the controller device's team for questions on the controller. 

Best Regards,

Aishwarya

Hello Aishwarya，

We have re-tested this issue over the past few days and observed that when the inter-frame gap between the data sent from the master to the slave is too small (e.g., 320.36μs in this case), the header of the data frame sent by the slave is prone to errors. Specifically, the data in the header of the slave's abnormal frame originates from the tail end of the previous frame sent by the master. After extending the time interval between the two frames sent by the master to 1.3ms, the anomaly did not recur during our re-tests. I am curious whether a small inter-frame gap would affect the slave's data processing? Furthermore, with a baud rate of 1 Mbps, a 320.36μs gap doesn't seem particularly small—why would the data sent by the DSP still encounter anomalies?

By the way, the Delay time of SPISTE valid to SPICLK is about 580-600ns and the  Delay time of SPICLK to SPISTE invalid is about 80-100ns(as show in the 2 figures below),is there any risk to the DSP SPI work?

Liu,

This is helpful information! HW wise timing requirements seems to be met, but SW wise, it looks like the target application needs some additional time to execute interrupts and process data/prepare any buffers. I would add timing margin to account for this accordingly.

Best Regards,

Aishwarya