Skip to main content
Associate II
April 2, 2025
Question

STM32 SPI Configuration Issue on STM32F765ZGT – HAL_BUSY Error

  • April 2, 2025
  • 5 replies
  • 1038 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.

5 replies

Bob S
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
Associate II
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)

CTapp.1
Senior III
April 3, 2025

But what did you do before the call to HAL_SPI_Transmit?

All posts are made in a personal capacity. MISRA C++ Chair, MISRA C WG Member, Director The MISRA Consortium Limited (TMCL)
Bob S
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.

 

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

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Saket_Om