Forem: Aaron Qian

Rev A UART Validation - RX Stuck High (TTL Buffer / TX_EN Gotcha)

Aaron Qian — Sun, 26 Apr 2026 10:41:26 +0000

Background

If you're new to the project, OpenServoCore is my effort to turn cheap MG90S-class servos into networked smart actuators with sensor feedback, cascade control, and a DYNAMIXEL-style TTL bus. tinyboot is the Rust bootloader that runs on those boards. It fits in the CH32V003's 1920-byte system flash and gives you CRC-validated OTA updates over UART, with trial boot and automatic rollback.

TL;DR

For those of you who just want a summary:

Symptom: UART RX on the Rev A V006 dev board wouldn’t go low. TX worked fine.
Triage: Scope showed only ~180 mV ripple on a 3.3 V line. Something was actively driving it high.
Diagnosis: The half-duplex TTL front-end was the culprit. TX_EN wasn’t just “TX enable”, it controlled whether the buffer was actively driving RX.

Still suggest you to at least skim through though. Those scope debug photos, videos, and schematic screenshots are probably still worth your time.

Initial Troubleshooting

The Rev A CH32V006 OpenServoCore dev board just came back from fabrication, and the first task was bringing the V006 port of tinyboot up on it. The V006's UART controller shares the same silicon as the V003, so you'd think the existing HAL driver would just work. But alas, things are never that simple... The tinyboot CLI couldn't reach the flashed bootloader at all. Same silicon, same driver, but the V006 was completely silent on UART.

To eliminate the possibility of other driver or init issues, I wrote a separate UART test app to dig into it more thoroughly. I first wrote a bare minimal app that just initialized UART using the same HAL driver and sent out "Hello world" periodically via the TX line. For the PC, I used CuteCom, a graphical serial terminal. Immediately I got garbage, but this is actually a good sign. It means the MCU is sending things out, just the clock needs some tweaking. And after some RCC tweaks, I was able to get the right clocks setup to receive TX with no issues. So far so good.

Narrowing It Down

The test app was happily transmitting bytes out over UART, but sending bytes back was a completely different story. The line was basically silent. It didn't matter how I tweaked the UART register settings or how many times I read and re-read the reference manual, I always got silence, nothing was reaching the chip. Given that the HAL code and the UART controller in the silicon are essentially the same as the V003, and that "Hello world" was coming out of the MCU's TX (proving clock init is sound), the only conclusion I could come up with was that the issue isn't in the firmware. It's in the hardware.

So I moved on to the schematic and the PCB layout, looking for anything wrong: a swapped pull-up, an inverted wire, anything. The UART TX/RX connector I used for testing is routed directly from the MCU. The same TX/RX routes also branch off to a half-duplex DXL TTL front-end. I had a brief suspicion that this might have something to do with RX not working, but couldn't come up with a plausible theory to back it up, so I moved on.

Scope to the Rescue

When I ran out of ideas on why RX didn't work, I decided to look at the signal directly with a scope to isolate whether anything was actually reaching the MCU. I have a neat one liner for this:

yes U | tr -d '\n' > /dev/ttyACM0

This bash command sends alternating zeros and ones to the MCU's RX line, making scoping easy. It works like this:

yes U repeatedly sends out U\n to STDOUT. U is 0x55 in hex, and 0b01010101 in binary, which produces alternating HIGHs and LOWs on the scope once the start and stop bits are taken into account.
tr -d '\n' strips \n from the stream, so we have UUUUUU forever.
> /dev/ttyACM0 pipes the whole stream into the TTY, in this case my WCH-LinkE serial port.

So I hooked up the scope, blasted UUUUUUUUU into the RX line, and what I saw was a square wave, but a teeny tiny one...

Zooming in on the scope:

The waveform was there. The shape was right. But it was riding on top of 3.3 V with maybe 180 mV of amplitude. The maximum was 3.38 V, the minimum 3.20 V. Something was holding the line near the rail so hard that my USB UART adapter could only pull it down by a couple hundred millivolts. This is a big clue!

To rule out the wiring, I touched RX directly to ground. The line snapped to 0 V cleanly. So the connection was fine. The driver just couldn't win against whatever was holding RX high.

Back to the Schematics

Looking at the TTL DXL front-end again, the RX line goes through a tri-state buffer (SN74LVC2G241) that implements half-duplex direction switching. TX_EN selects the direction:

TX_EN low (default, held by a pulldown): the buffer routes DATA to RX. The MCU listens to the bus.
TX_EN high: the buffer routes TX to DATA. The MCU talks to the bus.

This is when I had my facepalm moment. I had been picturing the buffer as some kind of passive switch that just connects two wires together. But after thinking about it for a few minutes, I realized that's not the case at all.

When TX_EN is low, the buffer's output stage is actively driving RX with whatever it sees on DATA. And DATA has its own 10K pullup, per the DXL TTL reference, so when nobody is talking on the bus, DATA sits at 3.3 V. The buffer reads that, and pushes 3.3 V back out through its high-side MOSFET onto RX. Simplified, RX is pretty much hooked directly to 3.3 V through maybe 20 Ω of MOSFET resistance, acting as a strong pull-up.

So when I was sending bytes from the USB UART adapter into RX, I was not fighting a passive 10K pullup. I was fighting a CMOS push-pull output stage. The 74LVC2G241 has very low high-side R_DS(on) and 24 mA of drive. A typical USB UART chip's TX output is much weaker. The two formed a voltage divider, and the buffer won. The line stayed parked near 3.3 V, with my adapter pulling it down by a couple hundred millivolts every time it tried to send a 0. That was my "ripple."

A hard short to ground bypasses that contention entirely, which is why poking RX with a ground clip snapped it cleanly to 0 V.

The Absurd Workaround

As absurd as it sounds, the workaround was to assert TX_EN, while reading from RX. Why would I assert the transmit enable when my problem was on the receive side? Because TX_EN isn't really a transmit enable. From firmware's perspective it's asserted when you talk and deasserted when you listen. But electrically, it's a mux select that picks which buffer drives the bus. Treating those as the same thing is what set me up for confusion in the first place.

With it held high, the DATA to RX buffer is disabled, RX falls back to its own pullup, and the USB UART adapter can drive it without a fight. Poking 3.3 V onto TX_EN confirmed it in real time:

Touching 3.3 V to TX_EN snaps the ripple into a clean rail-to-rail square wave. Release it and the line flat-lines back near 3.3 V. The buffer is the whole problem.

For those eagle-eyed viewers, yes. I'm touching the TP that says TX... But the electric trace is actually TX_EN.

This is another embarrassing yet hilarious mistake that got its own story, where I somehow "fixed" the issue by creating magic smoke on my board.

The Real Fix

The workaround is assert TX_EN in firmware, however, this is not a real fix. Drive TX_EN high in the bootloader's startup code and only release it when the MCU genuinely wants to talk. It works, costs nothing, and ships today. But it means UART functionality on this board now depends on the firmware running correctly.

The right fix should be in hardware by adding a jumper on the RX line. Shorted means TTL mode, where RX is wired through the buffer as before. Open means plain UART mode, where RX bypasses the buffer entirely and goes straight to the MCU. More involved, requires a board respin, and adds a small amount of inconvenience for the user. But the UART works without any firmware running.

For Rev. B, I'm going with the jumper.

The reason is wchisp. That tool, and others like it, use the UART to read and write the CH32's Option Bytes. Those operations happen outside of any firmware I write. If my UART hardware depends on my firmware to function, then a misconfigured Option Byte, a half-flashed bootloader, or a chip fresh from the factory can lock me out of the recovery path. The whole appeal of UART-based programming is that it works on a bare chip with nothing running. That property has to live in hardware, not in firmware.

The rule I'm taking from this: recovery-path peripherals should not depend on firmware to function. For half-duplex TTL designs specifically, that means the RX line has to be usable as a standalone UART without anything running on the MCU. A jumper is a small price to ensure hardware recoverability.

And TX_EN is really a line selector, and buffers actively drives outputs. I'll remember that one for a while.

tinyboot v0.4.0 Released — The API is Stable

Aaron Qian — Thu, 23 Apr 2026 05:10:00 +0000

If you've been following tinyboot, you might have noticed there was no announcement for v0.3.0. That release added CH32V103 support, but things were still in flux. Crate structure was shifting, APIs were changing, the protocol was being reworked. I didn't want to write up something that'd be outdated in two weeks. I wanted to wait until the dust settled. And with v0.4.0, we have finally arrived at this point.

What is tinyboot

tinyboot is a minimal bootloader for resource constrained MCUs. It is written in Rust, and it fits in 1920 bytes of system flash, leaving all user flash free for your application, except a small page (64 bytes on V003) of user flash to store boot metadata. It gives you CRC-validated firmware updates over UART with trial boot and automatic fallback to bootloader service mode when trials run out. The kind of safe OTA update story you'd expect from a much larger bootloader, squeezed into the constraints of a $0.22 MCU.

It's currently focused on the CH32 family, but the core is chip-agnostic and designed to be portable. If you're interested in bringing tinyboot to another chip family, see the porting section of the handbook.

I'm building it as part of OpenServoCore, an open-source smart servo platform. tinyboot handles the OTA updates via the existing single wire UART (Dynamixel TTL), so you don't have to tear your robot apart and open up each servo, unsolder the board just to flash a new firmware.

Platform Support

Family	Status
CH32V003	Supported
CH32V00x	New in v0.4.0
CH32V103	Supported
CH32X03x	Planned

V00x Support

The biggest addition in v0.4.0 is full support for the CH32V00x family: V002, V004, V005, V006, and V007. This is the release that matters most for OpenServoCore, because the OSC dev board runs on the CH32V006. Hardware validation for this release was done on the actual dev board.

Getting here wasn't entirely smooth. I ran into a hardware issue where the RX line wouldn't work without driving the inverse TX_EN line, which took a scope session to figure out. But that's a story for another post. I'm just glad I was able to finally get RX to work and complete the hardware test.

Everything Fits

TX_EN support used to overflow system flash on some chip variants. That's not acceptable. TX_EN isn't optional for OpenServoCore. It's required for half-duplex RS-485 / DXL TTL communication.

As of v0.4.0, all chip variants compile with TX_EN enabled and fit in system flash. The V103 was the outlier. It has a split flash layout, and I moved the UART transport into the second region to make it fit. That trick deserves its own post. Down the road, that second region also has enough room for a USB transport, so flashing via USB on V103 is a real possibility.

Crate Restructure

The previous three separate crates (tinyboot-ch32-boot, -app, -hal) are now merged into a single tinyboot-ch32 crate with boot, app, and hal modules. There's also a new tinyboot-ch32-rt, a minimal runtime because qingke-rt is too large for system flash.

This wasn't a planned refactor. It was the natural result of continuous iteration during tinyboot's early development. I'd rather get the architecture right early by sacrificing API stability than lock in the wrong abstractions.

tinyboot-ch32 is currently git-only and not published to crates.io. It depends on a git version of ch32-metapac that includes flash fixes for the V00x family that haven't been released yet.

Protocol and API Changes

The wire protocol now uses 24-bit addresses instead of 32-bit, freeing the fourth byte for per-command flags. 24 bits is still 16MB of addressable space, more than enough for these MCUs. The standalone Flush command is gone; it's now a flag on the final Write. Cleaner on the wire, simpler in the dispatcher, improves the developer experience, and best of all no size increase due to zero-cost abstractions via Rust's union types.

On the API side: BootMode became RunMode to separate the concept of boot flash region selection vs bootloader run mode (handoff or service). BootClient was also removed after the crates merge. Boolean parameters in the public API became semantic enums (Duplex::Half instead of half_duplex: true). Last but not least, flash lock/unlock is now scoped per operation instead of manual.

Bug Fixes

Two nasty half-duplex communication bugs, both found during hardware validation on the dev board:

The dispatcher wasn't flushing the transport after sending a response. On a full-duplex UART you'd never notice, but on RS-485 / DXL TTL half-duplex the data just sits in the buffer and never goes out on the wire.

The ring buffer wasn't resetting its head/tail pointers after flushing buffered writes to flash. The buffer was logically empty but the pointers were advanced, so subsequent writes would eventually wrap incorrectly. I didn't notice this before because I didn't do back-to-back flash commands with the tinyboot CLI.

Docs Overhaul

Documentation has been completely rewritten for users instead of maintainers, and a user handbook has been created. When the architecture is changing every release, writing user-facing docs is a losing game. Now that things have stabilized, it actually makes sense.

What "Stable" Means

To be clear, tinyboot is not production-grade. But as of v0.4.0, it's stable in the ways that matter:

Architecture stable: no more big crate restructures.
Protocol stable: no more wire format changes.
Features stable: all core features compile and fit on all supported chips.
Behavior stable: no obvious bugs.

This means I'm shifting focus. tinyboot satisfies all of OpenServoCore's needs, and my attention is moving to rewriting the OSC firmware. I'll still maintain tinyboot, and issues and PRs are welcome, but active feature development is pausing for now.

What's Next

USB transport for V103 (the second flash region has room).
CH32X03x support eventually.
But the immediate priority is OpenServoCore firmware.