2026-05-18 10:59 AM - last edited on 2026-05-19 1:06 AM by Andrew Neil
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.
Solved! Go to Solution.
2026-05-19 1:52 AM
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...
2026-05-19 1:42 AM
> my logic analyzer shows completely garbled bytes (corrupted data).
Show. Both the good and the bad. And explain why is the bad bad.
JW
2026-05-19 1:52 AM
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...
2026-05-20 12:29 AM
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!
We’re moving the ST Community to a new platform to give you a better and more reliable community experience.