Skip to main content
Graduate
April 2, 2025
Question

STM32 SPI Configuration Issue on STM32F765ZGT – HAL_BUSY Error

  • April 2, 2025
  • 4 replies
  • 997 views

Hello Everyone,

I am currently configuring SPI on the STM32F765ZGT board and using both blocking (polling) and interrupt-based methods for SPI transmission and reception. However, I am encountering an issue where the following condition evaluates to true, resulting in a HAL_BUSY error:

 

if (hspi->State != HAL_SPI_STATE_READY)
{
errorcode = HAL_BUSY;
goto error;
}
I would appreciate any insights on what might be causing this issue and potential solutions to resolve it.

Thank you in advance!

    This topic has been closed for replies.

    4 replies

    Super User
    April 2, 2025

    That piece of code is inside the HAL SPI functions.  We need to see what YOUR code does - how and when it calls the HAL SPI functions. And which call results in the BUSY return.

    Is your program using an RTOS (FreeRTOS, ThreadX, etc.)?

    In general, BUSY means the HAL SPI code thinks the interface is already doing something.  So (in general) look for an SPI call when the previous IT (interrupt) or DMA based SPI operation is still in progress.

    anuj18apAuthor
    Graduate
    April 3, 2025

    Is your program using an RTOS (FreeRTOS, ThreadX, etc.)?  : No

     

    I am printing the state before this condition

    printf("SPI State: %d\n", hspi->State);
    if (hspi->State != HAL_SPI_STATE_READY)
    {
    errorcode = HAL_BUSY;
    goto error;
    }

    i am getting
    SPI State: 1       (1 means already in ready state)

    Graduate II
    April 3, 2025

    But what did you do before the call to HAL_SPI_Transmit?

    Super User
    April 3, 2025

    > But what did you do before the call to HAL_SPI_Transmit?

    Actually show ALL of your calls to ALL of the SPI transmit/receive functions, or at least all the ones up to the call you showed above.

     

    Technical Moderator
    April 7, 2025

    Hello @anuj18ap 

    The issue arises because the SPI polling process is being called before the SPI interrupt process finishes.

    To resolve this, you need to add a flag in the SPI transfer complete callback function. Then, check this flag in the main function before calling the polling process.