STM32H7 HAL SPI_Receive does not consider SUSP flag

[ADunc.1]

Not an issue, just a recommendation for ST HAL developers...

STM32H7 firmware package, SPI_Receive (polled) does not consider the state of the SUSP flag.

During a polled SPI transfer that is larger than the receive fifo size, if the code is pre-empted (maybe a long interrupt or task switch) and the SPI rx fifo fills up, the SUSP flag is set and automatic clocking of SPI data is suspended.  The SPI transfer stops.  When handing returns to the SPI_Receive function, it reads the rx fifo, then hangs waiting for more data which will never come due the SPI clock being suspended.  Eventually the function times out and returns error.

I would recommend clearing the SUSP bit after each reading of the fifo to kick off data transfer again.

I don't need a workaround, just wanted to bring this to attention as could be quite confusing for some people who expect a blocking transfer to never timeout when in master mode.

[Saket_Om]

Hello @ADunc.1 

Thanks for your bug report.

The HAL_SPI_Receive() API does not configure the Master Automatic Suspend (MASRX) bit. As a result, if this bit remains unset, the SPI clock will not be suspended as expected.

[ADunc.1]

Even if the SPI_Receive function does not configure MASRX, there is no reason why it cant clear the SUSP flag after read as that would still work for both cases.

In fact, the API should set MASRX no matter what as it is the only way data overrun can be avoided if there are interrupts enabled or a RTOS.

The API can choose what bits it sets/clears on the SPI, it does with everything else, so no reason not to enable MASRX if not already enabled.

A polled SPI receive (master) should always clock and read the exact number of bytes.  There should be no reason why it should ever overrun, timeout or not complete.

[Saket_Om]

Hello @ADunc.1 

I reported your request internally.

Internal ticket number: 215523 (This is an internal tracking number and is not accessible or usable by customers).