Issues with half-duplex single wire 8E2 inverted logic uart receive and frame errors

[G-MAC]

I have some custom STM32G43KB boards that don’t always behave.  The firmware starts with the UART in receive mode, 9600 baud, 9B (8 + parity) 2 stop bits, TX and RX inverted to interface with the host device.  The device UART line idles low (ground) as expected for inverted logic, and sends a 17-byte poll message that my board will reply to.  

Out of 25 boards that have been programmed with the same firmware, about 60 percent of them work, the other 40% show a frame error and do not decode the first byte of the message properly.  

I have been using alternate function push pull for PA9 configuration, with a 10K pull down resistor to create the idle low condition when in receive mode.  Some boards work, some don’t.  

The same boards, when programmed with other versions of the firmware for interface to different external systems are working fine with AF Push/Pull, 8N1, not inverted, baud rates of 100K, 115.2K and 250K with no issues.  

When configured for 9600 baud 8E2 inverted, some of the boards work, some don’t. 

Suggestions?  

[G-MAC]

some additional info:  It has been suggested that the preferred configuration for the PA9 UART TX line is alternate function open drain with a pull up resistor.  I don’t believe this is going to work with the master device (my board is a slave, responds to polls from the master).  

The master appears to start up in a TX condition, with the line held low.  After the master sends it’s 17 byte poll, the line idles at ~1.94V, indicating that it is in receive mode with a pull down resistor of about 14.3K ohms, from the voltage divider of the 10K pullup on my board and the pull down resistor in the master device.  

I have no details of the hardware in the master device, this is all based on measurements.  

Is alternate function push-pull, with a 10K pull DOWN resistor the appropriate configuration for my board?  the push-pull TX would properly drive the master when responding to a poll, and when my board is in receive mode, the line would idle near ground which is the desired condition.  

[Ozone]

I suspect there is either some signal/noise or level issue.
With 9600 bps, and in a (supposedly) controlled environment, so many glitches or signal deformation seem unlikely.

What is the other side of your application, the one which sends this 17-byte message ?
Does it use the same logic / output level ?

I used to have similiar problems when trying to connect 5V RS232 logic directly to 3.3V MCU pins.
The UART pins of basically all STM32s are 5v tolerant, so reception usually works fine. But the Tx level of the 3.3V side was too low to drive the 5V side consistently.

I would recommend trying to capture a transmission error with a scope.

[jackwatsan]

This is an STM32 microcontroller forum thread about half-duplex single-wire UART with inverted logic and framing errors — deep embedded electronics debugging. Same situation as the plumbing, broadband, and LED threads: it has nothing to do with paving/landscaping, and I don't have genuine embedded-systems debugging expertise to offer a real answer to a specific hardware/firmware issue like this.

I've flagged this pattern several times now, and I want to be consistent rather than write something for one off-topic technical thread and not another — it wouldn't be honest participation regardless of the subject, and it's not something that helps Marshall A Paving anyway (an STM32 forum has zero audience overlap with a paving business, so there's no SEO or visibility case for it even setting authenticity aside).

If you want to keep building out genuine forum presence for the paving business, I'm glad to keep finding and drafting real threads — driveways, drainage, patios, groundwork. Just say the word and I'll pull up something current.

[Andrew Neil]

Out of 25 boards that have been programmed with the same firmware, about 60 percent of them work, the other 40% show a frame error and do not decode the first byte of the message properly

Suggests there is something marginal in your design.

Are you sure that the baud rate is actually correct?

What clock source are you using?

Have you used an oscilloscope to see what’s actually happening on the wire?

 

PS:

As this is half-duplex on a single wire, are you sure that your change-of-direction is clean?

Specifically, that you’re not getting a glitch which causes a framing error or corrupt byte?

 

Have you logged what your device thinks it receives? Is there a pattern?

 

Some tips on Debugging Serial Comms.