Someone used the STM32F4 chip to validate the SPI functionality. When using two on-chip SPI modules for transmission and reception based on interrupts, it was found that there was always a loss of received data, seemingly losing the last 2 data points. The code used the HAL library’s API functions. What could be the reason?
I took the STM32F407 development board for verification testing. Using SPI1 for sending and SPI3 for receiving, both using interrupt mode.
Quickly, I reproduced the problem, which is the loss of received data. See the verification results below; sent 8 data points, only received 6 data points.
Now, with the same chip, that is, the same CPU completing transmission and reception based on interrupts. I suspect whether the arrangement of interrupt priorities between the different SPI modules is unreasonable, leading to this issue. If both have the same priority, the sending interrupt usually occurs before the receiving interrupt, which can lead to delayed reception. Through code tracing and debugging, I indeed found the SPI reception overflow phenomenon, meaning data extraction was not timely.
From this analysis, I feel that the data loss should be related to the communication speed, and the amount of lost data should not be fixed. Therefore, I significantly increased the SPI communication speed for further testing, and indeed, the amount of lost data increased. See the test results below; sent 8 data points but only received 1 data point. 【In the previous test, the SPI baud rate was 5.25Mb/s, now it has been changed to 21Mb/s.】
I adjusted the priority of the SPI3 receive interrupt to be higher than that of the SPI1 send interrupt, as shown in the figure below.
After testing with the code adjusted for interrupt priority, the results were completely normal.
Of course, we can also have other flexible handling methods. For example, using interrupts for sending and DMA for receiving, or using polling for sending and interrupts or DMA for receiving, or both using DMA mode as well.
The core issue here is that the interrupt priorities were not arranged reasonably. The STM32 ARM core interrupts are not many, but having fewer items often means more flexibility in usage. Well, that’s all for today’s topic.
Previous Recommendations
《Comprehensive Guide to Embedded Linux Drivers》
How to Efficiently Read Embedded Project Code?