STM32 SPI receiving stuck problem

When calling the following SPI function during debugging, the following two problems were found:

1. If you set a breakpoint at the third line while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_RXNE) == RESET);, it will get stuck in this while statement and cause the watchdog to reset;

2. Running at full speed will trigger the watchdog reset program. The program only calls spi without interruption. It is determined that it is caused by spi. The SPI rate drops from 16M to 2M, and there is no reset in a short time.

uint8_t SPI2_SendOneByte(uint8_t u8Data) //SPI2 sends one byte

{

/* Wait for the send buffer to be empty, TXE event*/

while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_TXE) == RESET);

/* Write the data register and write the data to be written into the send buffer*/

SPI_I2S_SendData(SPI2, u8Data);

/* Wait for the receive buffer to be non-empty, RXNE event*/

while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_RXNE) == RESET);

/* Read the data register and get the receive buffer data*/

return SPI_I2S_ReceiveData(SPI2);

}

After testing and consulting online information, it was found that it was caused by tracking the SPI register during debugging. The solution is to close the corresponding SPI register tracking window during debugging. The specific reason was not found in the official document. I saw such a paragraph on the Internet, which can explain this imagination:

During the debugging process, the status of peripheral registers can be easily viewed using the register or memory display window of the debugging software.

Many friends have encountered this problem: during single-step debugging, they can never see changes in certain flag bits in the display window. When these flag bits should be set, they are displayed as 0 in the window. Many people mistakenly believe that this is a chip problem.

We know that the status register bits of many STM32 peripherals can be cleared by reading certain registers (such as many flag bits in I2C_SR1 of I2C). During the debugging process, whenever the program stops at a set breakpoint or single-step stop, the debugging software will automatically read out the contents of all specified registers and memories and refresh the window display. This read operation of the debugging software happens to clear those flag bits, resulting in the phenomenon described above.

There are several simple ways to solve this problem: 1. Close the register or memory display window. 2. Do not display these sensitive registers in the register or memory display window. 3. Do not place breakpoints before the operation of these sensitive register bits to ensure that these register bits are not accidentally operated by the debugging software.