I am working with the STM32F769NIH6 microcontroller and it's communicating with a different processor using a home-made SPI-based protocol where the STM32F769NIH6 is the slave. The master clocks data at 11 MHz and the STM32F769NIH6 is running at 120 MHz. FIFO is disabled on the Tx stream (can't easily enable it without changing the protocol), but it has the highest priority (DMA_PRIORITY_VERY_HIGH) and the Rx stream has the lowest priortity (DMA_PRIORITY_LOW). The buffer with Tx-data resides in "TCMRAM"-section of the RAM. Every once in a while I get DMA Tx stream FIFO errors and it's strange given the slow speed of the SPI-clock, I'm sending a rather small packet (16 bytes) and there are not a lot of other peripherals using the same DMA (DMA2). Also, the problem doesn't seem to get worse when I add a lot of load to the DMA (by running a stress test) so it seems it's some kind of latency issue rather than a throughput issue. Does anybody have any suggestions on how I can debug/solve this? Would using a cached area of RAM instead of TCMRAM help? How would I then tell the processor to "suck in" data from my Tx-buffer into its cache after I have put new data into it?
Thanks, that solved the problem. It's amazing how I sometimes can't see the forest because the trees are in the way... It's strange, though, that I get error interrupts from something that isn't used, but that's a different story.
It's explained (although you'd need to think in the same way the authors of the DMA module were thinking to actually understand that explanation) in AN4031, note under Software sequence to enable DMA subchapter.
