Showing results for 
Search instead for 
Did you mean: 

Troubleshooting STM32 Communication: Unexpected Behavior in UART Callbacks

Associate III

Hello STM32 Community,

I am currently working with the STM32L476RG microcontroller and am facing challenges in receiving data within the callback function during USART transmission. Both the TX and RX of the UART channel are declared in "normal" DMA mode, and global interrupts are enabled. My code is structured as follows:


Main function of STM32CubeIDE:

txByte = '0';

HAL_UART_Transmit_DMA(&huart1, &txByte, 1);

Callback functions of STM32CubeIDE:

void HAL_UART_TxCpltCallback (UART_HandleTypeDef *huart){
HAL_UART_Receive_DMA(&huart1, rxData, 500 * 4);
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart){
count = count + 1;
if(count == 1){
Python code on my desktop:

binary_data1 = b''.join(struct.pack('<I', data) for data in step_position_data[0:500])

while True:
     if ser.in_waiting > 0:
          byte =

          if (byte == '0'):


I am attempting to establish communication between my computer and the STM32 board. The main function of the STM32 board transmits the byte '0' to my computer, which then reads the byte and writes the binary_data, a buffer of size 500 uint32_t. Simultaneously, since the transmission is complete, the code in HAL_UART_TxCpltCallback function (HAL_UART_Receive_DMA(&huart1, rxData, 500 * 4);) should be executed, and I expected the LED to toggle through the HAL_UART_RxCpltCallback function.

However, despite the successful reception of the byte by my computer and the verification of binary_data transmission with the "sent" message, the LED did not toggle. It appears that HAL_UART_Receive_DMA(&huart1, rxData, 500 * 4) in HAL_UART_TxCpltCallback is not functioning as expected. This is puzzling, considering that the exact reverse (receiving in the main function and transmitting in the callback) worked successfully. I would greatly appreciate any assistance or insights if anyone has encountered a similar issue and found a solution. Thank you!


Perhaps walk before you run. Receive a single character in blocking mode to establish correct configuration and connectivity between device and computer.

Might need to ensure computer is sending data and not buffering parts of it. There's probably a flush function or socket setting which manipulates this.

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