STM32L0 SPI communication with DMA, Slow CS

[Dude]

STM32L0 SPI communication with DMA. The SPI CS line is controlled with software. It appears to stay low for about 72uS when the communication only takes about 4uS. 

Right before setting the DMA to roll, I set the CS to 0. Nothing else is pending for the DMA. When the DMA RX full interrupt triggers, I set the CS to 1.

Why does the CS take as long as it does? How can I make this time shorter? I would like to do communications more often, if possible.

[Dude]

"Point here being, not clear if you check for this, and really no point in doing TWO interrupts to service this. TX will be leading, RX will be trailing, and the better point to address things, as the last bit has gone over the wire. You can drop CS, and pivot directly into the next transfer."

hmm..... Okay, so I shouldn't set the RX interrupt? Just take the end of the TX as the point to initiate the next transfer? That won't resolve the ~50uS that the Chip Select goes low, and then sits. But it could help the delay between transmissions?

[S.Ma]

Use only dma rx interrupt to raise CS.

Now, if you want to know where the code waste time, use a timer that counts usec as free run and overflow, capture the value at the beginning of the interrupt in a global var, and take a second snapshot at different points to know how long each interrupt segment last. In cortex M3+ there is a debug cycle counter for it that is missing here. In debug modd, put a breakpoint after the second timestamp reading so the interval time can be deducted.

Going step by step in the interrupt, while a bit disruptive, may tell you where most of the time is wasted, and if sequence reorg can be done to improve things.

[Dude]

I agree, I can time how long the code in the interrupt takes to execute. However, it seems somewhat independent of the interrupt. When I make the interrupt simply reset or clear the interrupt flag, it still takes a while.

[RusikOk]

Good day! did you manage to solve the speed problem? and if so how?