Why is setting up SPI to re-transmit by DMA taking too long, 1uS??

[victagayun]

First, I would like to know if this code is correct to setup SPI to re-transmit by DMA again.

GPIOA->BSRR = (1<<5); // start
 
  DMA1->IFCR = 0x0FFFFFFF; // reset status
 
  DMA1_Channel3->CCR &= ~( DMA_CCR_EN );
 
  LL_DMA_SetDataLength(DMA1, LL_DMA_CHANNEL_3, ubNbDataToTransmit);
 
  DMA1_Channel3->CCR |= ( DMA_CCR_EN );
 
  GPIOA->BSRR = (1<<21); // reset/end +16

when taking the duration of the whole code, it is taking around 1uS as shown below.

CH1 (yellow) = GPIOA5

CH2 (blue) = SPI clk

Why is it taking around 1uS to execute these codes?

[KnarfB]

in STM32CubeIDE menu: Project > Properties > C/C++ Build > Settings

Also be sure that you have a separate Debug+Run configuration loading the release code (.elf) to the board.

[waclawek.jan]

You probably don't want to clear all DMA flags, if you use other DMAs, too.

Maybe some small speedup may be achieved by replacing the RMW operations to CCR by direct value writes.

JW

[Andreas Bolsch]

Yes, as long as no interrupt touching the very same register, it's much better to read CCR only once and keep its contents in a temp.

The same holds for LL_DMA_SetDataLength which internally does a RMW, too (via MODIFY_REG, strange enough) . If this is not optimized

away ...

[waclawek.jan]

> The same holds for LL_DMA_SetDataLength which internally does a RMW, too

That's dumb... highlights the merits of LL nicely, though.

> read CCR only once and keep its contents in a temp

IMO under the vast majority of scenarios you *know* what's the content of CCR, i.e. don't need to keep it in a variable, but simply write it as literal.

JW