Skip to main content
Associate
June 23, 2025
Question

HAL_UART_RegisterRxEventCallback Issue in v1.11.3 (rxState vs gState)

  • June 23, 2025
  • 2 replies
  • 446 views

 

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

2 replies

TDK
Super User
June 23, 2025

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""."
ST Employee
June 24, 2025

Hello @Isy777,

This post has been escalated to the ST Online Support Team for additional assistance.  We'll contact you directly.

Best regards,
Maxime

​In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.