SPI unaccountable lock. Amazing behaviour. Test software included, STM32F401 Blackpill, no additional hardware required.

[Syntax]

My SPI gets stuck (waiting for RX register not empy flag, <SPI1->SR & 1> that never arrives). The operation is written with registers, not HAL.

BUT! it only gets stuck after a fixed number of successful repeated operations, all the same, inside a loop.

ALSO! the number depends by a previous use of HAL_delay() :) outside my repetition loop.

I understand that it is not possible to make a diagnosis without reading the source, more info, e.s.o. but maybe someone has same suggestion on where to start to find what happens?

[waclawek.jan]

Which STM32?

Don't look at the SPI registers using debugger. Reading SPI_DR (from debugger) clears RXNE.

JW

[S.Ma]

In SPI 4 wire mode, when TXE, you write to the DR to at minima generate the SCK bit clock pulses needed for shifting.

The RXNE is used to know when these bit shifting has ended and you can read DR.

If your SPI has HW FIFO, things get more interesting...

And as said, SW delays are not necessary, they hide bugs. Don't put the SPI HW registers on a watch or SFR register window, the debugger will read the registers and hickup the code normal operation.

[Syntax]

Thank for suggestions, but lock happens also while program is free running. For those that would like to experiment I have uploaded the whole project. Only the Blackpill STM32F401 is needed, without any additional hardware.

The relevant lines of code are in main.c, 143 and 162.

[gbm]

My wild guess without looking at the code: 16-bit access to the DR register while the SPI is set to 8-bit frames.

[Syntax]

Tnx How to access at 8 bit?

[waclawek.jan]

That's not the issue here: SPI in 'F4 does not have data packing as the newer STM32 models do.

JW

[waclawek.jan]

Don't use GPIOx_ODR to change GPIO pin state. Use exclusively GPIOx_BSRR.

JW