I have a project using all custom code (not HAL) in which I have two 6 byte SPI DMA transactions running periodically based on timers. It's set up so I can even pause the main CPU and these transactions will continue. I've found that in certain conditions, one of the SPI transactions on SPI3 will glitch and get delayed for 1 byte, leaving a 1 byte gap. This ends up overlapping the next transaction and causing some problems. The specific conditions that seem to cause this are that a USB TX CTR interrupt has recently occurred (and completed), and that SPI2 has started a transaction just before the SPI3 transaction. My assumption with this transactions is that the DMA has plenty of time to load one byte into the SPI fifo even when loading to two different SPIs. Unless there is something with the USB preventing the DMA from operating at that time? The CTR seems like a hint that maybe USB is using the bus to load another 64 bytes to some other buffer? I don't know what could cause this. At the specific time of the glitch the CPU is usually involved with doing nothing - waiting in a while(1) loop.
Are there any interactions of USB that would affect DMA? There does not seem to be any direct connection to DMA that I can find.
SPI3 glitch at the blue line below
Showing that it time syncs just after a USB_LP_IRQHandler execution. This glitch only occurs after something is happening on USB. But at the exact time of the glitch the code running is while(1) in system::run.
