cancel
Showing results for 
Search instead for 
Did you mean: 

HAL_UART_RegisterRxEventCallback Issue in v1.11.3 (rxState vs gState)

Isy777
Associate

 

Hi ST Community,

I'm encountering an issue using the following function in STM32Cube HAL v1.11.3:

 

HAL_UARTEx_ReceiveToIdle_DMA(&CLI_PORT_HANDLER, (uint8_t*)&cliPortRxBuff, sizeof(cliPortRxBuff)); HAL_UART_RegisterRxEventCallback(&CLI_PORT_HANDLER, (pUART_RxEventCallbackTypeDef)CLI_Serial_RxIdle_Complete);

In this version, I observed that the callback registration depends on huart->RxState:

if (huart->RxState == HAL_UART_STATE_READY) { huart->RxEventCallback = pCallback;}

However, RxState is not in the HAL_UART_STATE_READY state at the time of registration, which causes the callback not to be assigned—leading to broken UART behavior.

In contrast, previous versions (e.g., v1.11.0) checked gState, which allowed this registration to work as expected.

Questions:

  1. Why was RxState chosen for the condition in v1.11.3 instead of gState?

  2. What is the recommended workaround or best practice to ensure the callback can be registered successfully in this new version?

Appreciate your guidance on this.

Best regards,
Isaac

1 REPLY 1
TDK
Super User

1+2) The callback should be set prior to starting communication. Otherwise you have a race condition.

If you feel a post has answered your question, please click "Accept as Solution".