Skip to main content
Associate II
May 18, 2026
Solved

USART Half-Duplex Open-Drain: Waiting for TC flag causes garbled data

  • May 18, 2026
  • 3 replies
  • 296 views

Hello everyone,

I have encountered a strange issue with my UART transmission function on an STM32 microcontroller operating in Half-Duplex Open-Drain mode.

Currently, the function works perfectly fine without checking the TC flag. However, when I add a check to wait for the transmission completion at the end of the function, my logic analyzer shows completely garbled bytes (corrupted data).

Here is the code that works perfectly (without the TC check):

void send_array(uint8_t *arr, uint8_t size)
{
 /* Receiver disable */
 USART3->CR1 &= ~(CR1_RE);

 for (int i = 0; i < size; i++)
 {
 /* Wait until Transmit data register is empty */
 while(!(USART3->SR & SR_TXE)){}

 /* Send byte */
 USART3->DR = arr[i];
 }

 /* Receiver enable */
 USART3->CR1 |= CR1_RE;
}

And here is the modification that breaks the transmission and leads to garbled bytes on the analyzer:

void send_array(uint8_t *arr, uint8_t size)
{
 /* Receiver disable */
 USART3->CR1 &= ~(CR1_RE);

 for (int i = 0; i < size; i++)
 {
 /* Wait until Transmit data register is empty */
 while(!(USART3->SR & SR_TXE)){}

 /* Send byte */
 USART3->DR = arr[i];
 }

 /* Waiting for TC here causes garbled data */
 while(!(USART3->SR & SR_TC)){}

 /* Receiver enable */
 USART3->CR1 |= CR1_RE;
}

Can anyone explain the underlying hardware reason for this behavior? Why does waiting for the TC flag disrupt framing or synchronization in Half-Duplex mode?

Thank you in advance!


Edited to apply source code formatting - please see How to insert source code for future reference.

Best answer by Andrew Neil

Welcome to the forum.

Please give more details of your setup - see: 

How to write your question to maximize your chances to find a solution 

 

What is at the other end of your link? Are you sure that is behaving correctly ?

 


@Rafo wrote:

my logic analyzer shows completely garbled bytes (corrupted data).


Have you also looked at the line with an oscilloscope, to verify that all is well in the analogue domain - clean, good edges, no noise, etc ... ?

If it's not clean in the analogue domain, then an LA can give misleading results...

3 replies

waclawek.jan
Super User
May 19, 2026

> my logic analyzer shows completely garbled bytes (corrupted data).

Show. Both the good and the bad. And explain why is the bad bad.

JW

Andrew Neil
Andrew NeilBest answer
Super User
May 19, 2026

Welcome to the forum.

Please give more details of your setup - see: 

How to write your question to maximize your chances to find a solution 

 

What is at the other end of your link? Are you sure that is behaving correctly ?

 


@Rafo wrote:

my logic analyzer shows completely garbled bytes (corrupted data).


Have you also looked at the line with an oscilloscope, to verify that all is well in the analogue domain - clean, good edges, no noise, etc ... ?

If it's not clean in the analogue domain, then an LA can give misleading results...

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
RafoAuthor
Associate II
May 20, 2026

Hi everyone, thanks for the help!

The problem is solved. The pull-up resistor value was indeed too large, which caused a slow rise time. On top of that, my logic analyzer was also glitching, which added to the initial confusion.

For testing, I sent a 0x55 byte to get an alternating bit pattern, and you can see the result in the attached oscilloscope screenshot. The long flat pause at the high level is the idle time while waiting for the TC flag between transmissions.

Everything is working perfectly now. Thanks again!