Overrun flag when using SPI in interrupt mode (HAL_SPI_Receive_IT())

Question

Hello,I'm reading data from an external device using SPI in Receive Only Master mode. For this, I'm using the HAL function HAL_SPI_Receive_IT(), which as its name suggests doesn't use DMA, but is non-blocking and calls HAL_SPI_RxCpltCallback() when it's done and my buffer holds the number of bytes I asked for.Everything runs fine at 10Mbits/s, but when I increase the speed to 12Mbits/s (the external device supports up to 20Mbits/s SPI, and my STM32H750 runs at 400MHz SYSCLK), I start getting overruns (HAL_SPI_ErrorCallback() is called and I see that the OVR flag in the SPI SR is set). I'm always waiting until HAL_SPI_RxCpltCallback() or HAL_SPI_ErrorCallback() get called before starting a new transfer, and hspi1.State is HAL_SPI_STATE_READY when I start it. I don't understand what could cause an overrun.From the STM32H750 reference manual:"An overrun condition occurs when data are received by a master or slave and the RxFIFOhas not enough space to store these received data. This can happen if the software or theDMA did not have enough time to read the previously received data (stored in the RxFIFO)."As mentioned I'm not using DMA. And the buffer I give to HAL_SPI_Receive_IT() is allocated big enough to hold the data. What can cause this overrun?Thank you for your help

berendi · Accepted Answer

Let's do some math first. You are receiving at 12 MBits/s, that's 1.5 MBytes/sec. No idea about the data width, assuming 8 bit data it's 1.5 million interrupts/second. At 400 MHz core speed it means that the interrupt handler has 266 cycles to complete its task, or an overrun will occur. That's not a lot, but there are a few things that you can do about it.

Don't use HAL, it's too slow. (I'm surprised that it managed to handle 10 Mbits.) Look at the source HAL_SPI_IRQHandler() function. Even if receiving is handled relatively early, it still checks half a dozen variables and registers to decide what to do before finally reading the data register. Reimplement the whole mess from scratch, hard-coding data width and other parameters. Do not ever check for anything that is known at development time (think about it every time before writing an if or switch). For starters,

void SPI1_IRQHandler(void) {
 uint32_t sr;
 uint8_t data;
 sr = SPI1->SR;
 if(sr & SPI_SR_RXP) {
 data = *(volatile uint8_t *)&SPI1->RXDR;
 // put data into a buffer or process it otherwise
 }
 if(sr & SPI_SR_TXP) {
 // generate data to be sent, or read it from the outgoing buffer
 *(volatile uint8_t *)&SPI1->RXDR = data;
 }
 // handle error conditions
}

Don't forget to declare as volatile everything that is used to communicate between the main program and the interrupt handler.

Depending on how you are processing the received data (if you don't have to act on every byte immediately), it might make sense to receive 16 or 32 bits at once (check SPI implementation and functional description in the reference manual), either by setting DSIZE or enabling the FIFO.
When receiving lots of data to be processed later, switch to DMA transfer.

RMcCa · Answer

Not using dma could cause this.Try toggling a pin to check the isr timing.Ditching hal and writing your own isr can help as well.​

Sign up

Login with SSO

Login to the community

Login with SSO