SPI ready time longer then expected.

[ulao]

I was noticing that the SPI complete flag is up to 2us after transfer. When i send less data, its even longer?

is this the time it takes to shift data from peripheral to memory for dma? The CS (nss) line comes up when expected but TRANSFER_WAIT flag much later. When I cut the data short it takes even longer.

[S.Ma]

No telepath on this forum...

16MHz or 180MHz core, HAL or direct coding? SPI with HW fifo or not? DMA or not? RTOS or bare metal ? How many active interrupts and priority? SPI sck frequency ?

[ulao]

whoops yeah sorry a little vague there.Stepped away from code but will report back on the missing. Will answer what I can and get more info later.

Chip stm32h7 - 480 MHz

using HAL

SPI with DMA with a 96Mhz clock 2 divider. ( clocked at 50MMhz)

RTOS

SPI sck frequency all pins are highest.

I do have a few interrupts abut need to count and check priority.

[S.Ma]

The transfer ends with dma rx completed, which should trigger the irq to raise nss.

HAL maybe one contributor to this delay.

[ulao]

it may very well all be Hal overhead here.

I do have interrupts set with 0 priority and it looks like I have about 12 other interrupts set. I use HAL_SPI_TxRxCpltCallback for the complete.

I tried stopping all other interrupts but it didnt change much.

.

[ulao]

this is not the case, there is something wrong here.

I start a while after my transmission.

//bring a debug line high

while ( hspi5.State != HAL_SPI_STATE_READY) {}

//bring a debug line low

then in void HAL_SPI_IRQHandler(SPI_HandleTypeDef *hspi)

I put another debug line high at the hspi->State = HAL_SPI_STATE_READY;

now the line does take 700ns ( a bit much imo) but the low line from above happens another 600ns later. Just seems a bit odd it takes that long to jump out and call a few call backs

[S.Ma]

Well in any case, interrupts will break the core pipeline, jump far with interrupt vector, then push registers, and break again when returning from interrupt. Usually cache won't help here.

On top of this, most ARM compiler seems to optimize code only withing the scope of a c source file.

And you also need to check the compiler optimisation settings.

So, for fun, comment the interrupt handler, create new one and put all interrupt executed code in the same source file. You can use debug timer to take a cycle snapshot at interrupt entering and one at exiting with keeping the max duration value for worst case....