Part Number: TMS320F28386D
Greetings
We are using a TSM320F28386D DSP in the motherboard of one of our products, which also includes a microprocessor and an FPGA. There are two SPI channels being used to communicate with the uP, which acts as the master, with a period of 4ms and 8ms each. Both channels have two DMA channels each, one for SIMO and another one for SOMI, and transmit at a baudrate of 25Mbps.
We use SPI communication with DMA support to manage the peripheral buffers. Each DMA channel will post a Hardware Interrupt when the defined number of bursts is completed, however, we find that randomly, about 40% of the times the 4ms period RX interrupt will not pop. Instead, it is called at the beggining of the following transmission, which seems to suggest that some frames go missing and the DMA transmit is still waiting for one last burst. The application then detects a wrong CRC and performs a recovery to be ready for next transmission.
Some considerations:
- Issues related with the HW of the paths or the electronics in general are out of the table, since DSP-uP comms worked just fine in the same conditions in previous versions. Plus, halving the baudrate had no effect.
- The period between transmissions has also been substantially increased with no effect. Also we've checked through debugging and GPIO that overrun does not happen.
- The problem seems to be fixed when optimization is turned OFF. Level 0 optimization is used in the failing and previous versions. Most of the time it is enough to turn off optimization for the SPI driver source file but sometimes it is required to remove optimization from the rest of the drivers, depending on what's in the application code. Leaving optimization unused is not an option, since the use of inlining is a must.
- All variables involved in DMA dumps are defined as volatile.
- All 4 DMA channels used in SPI buffer management are also used to perform 1/2 one shot memory dumps between variables as soon as the transmission ends. When the dumps are done, they are reconfigured to be ready to manage the SPI buffer when the master (uP) starts communication. Since we've checked that the functions that prepare DMA channels for next transmission are always done way before it starts (no overruns), this should not result in faulty performance.
- Disabling inlining didn't have an effect on the failure. Nor did using the --aliased_variables parameter.
- The version of CCS used is 12.1.0.00007 and the compiler version is TI v22.6.0.LTS
We've been checking the "Optimizing C/C++ Compiler User Guide", but nothing has worked so far. Any kind of advice will be very much appreciated. Thanks in advance!
