Skip to main content
Graduate
August 7, 2025
Solved

STM32H7 HAL SPI_Receive does not consider SUSP flag

  • August 7, 2025
  • 2 replies
  • 377 views

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.

 

    This topic has been closed for replies.
    Best answer by Saket_Om

    Hello @ADunc.1 

    The issue has been resolved and now available on GitHub. Please check the link below.

    [HAL][SPI] Clear auto suspend flag in HAL_SPI_Receive() · STMicroelectronics/stm32h7xx-hal-driver@64687ba · GitHub

    2 replies

    Technical Moderator
    August 7, 2025

    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.

     

    Saket_Om_1-1754559499492.png

     

     

    ADunc.1Author
    Graduate
    August 7, 2025

    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.

    Technical Moderator
    August 8, 2025

    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).

    Saket_OmAnswer
    Technical Moderator
    September 17, 2025

    Hello @ADunc.1 

    The issue has been resolved and now available on GitHub. Please check the link below.

    [HAL][SPI] Clear auto suspend flag in HAL_SPI_Receive() · STMicroelectronics/stm32h7xx-hal-driver@64687ba · GitHub