DEV Community: Aaron Qian

CH32V006 Servo Controller Firmware - DXL 2.0 RX Timing

Aaron Qian — Wed, 10 Jun 2026 00:07:35 +0000

Originally published at aaronqian.com.

This is a design note for anyone bringing up a Dynamixel 2.0 servo on the CH32V006. You don't need prior DXL or RISC-V expertise; read it top to bottom. Protocol reference throughout is the DYNAMIXEL Protocol 2.0 spec.

If you're new here, OpenServoCore is my effort to turn cheap SG90 / MG90 servos into networked smart actuators with sensor feedback, cascade control, and a DYNAMIXEL-style TTL bus. This is the first post in a series on how the CH32V006 firmware meets DXL 2.0's timing budget on a $0.16 chip (qty. 1000+). Later posts will be linked here as they go live.

CH32V006 Limitations: DXL 2.0 does not require any idle period between the host's last byte and the servo's reply. The clean way to detect the host's wire-end is to use a chip class with proper UART hardware support, for example, STM32G0 / G4 class chips. They expose USART primitives that deliver the wire-end with zero publish latency, but they are also pricy. The V006 doesn't have anything equivalent, so we have to somehow have to do this in software-only regime built on the two USART flags it does give us.

TL;DR. Given software-only limitations, how does a DXL servo on the CH32V006 know precisely when the host's request ended on the wire, across every baud rate from 9600 up to 3 Mbaud (the V006's USART ceiling)? Call that moment the wire-end. It's the reference point the servo schedules its reply against, since the protocol's Return Delay Time (configurable from 2 µs) is measured from it, miss it and the reply lands in another servo's slot and causes bus contention.

The CH32V006's USART offers two usable signals: a per-byte interrupt (RXNE) that fires exactly at each byte's stop bit, and a per-packet interrupt (IDLE) that fires once after the line has been quiet for 9 bit-times. However, RXNE is precise but expensive (100k IRQs/second at 1 Mbaud). IDLE is cheap but its publish latency, ~1 character time, exceeds short RDTs at low baud. The answer is to pick between them based on (baud, RDT). This post details what each signal looks like, and how to construct a strategy to determine which strategy to select dynamically.

Glossary

A few protocol terms recur throughout. The V006-specific acronyms (BRR, NDTR, PFIC, HCLK, etc.) are introduced inline where they first show up.

Term	Meaning
DXL	DYNAMIXEL, Robotis's smart-servo bus and protocol. We speak DXL 2.0.
RDT	Return Delay Time. Servo-side reply offset from the host's request-end, configurable 2–508 µs in 2 µs steps.
Fast Sync / Bulk Read	DXL 2.0 read variant where the host addresses many servos at once and all replies stitch into one coalesced Status frame.
Coalesce	The zero-idle-gap stitching above. What the last servo's fire deadline has to preserve.
Wire-end	The moment a byte's stop bit finishes clocking out. The actual "wire just went idle" event.
IDLE / RXNE / TC	USART status flags. Line went idle / a byte arrived / TX shift register fully drained.

1. What's on the wire

DXL is a half-duplex serial bus, driven by a single host. Servos listens to host instruction packets and produce status packets. Since they all share a single physical DATA wrie, all nodes (host and servos) have to ensure they don't step on each other. Otherwise it will cause bus contention and garbled bytes.

The question the servo has to answer: after the host's request finishes, how long should I wait before replying?

The answer is a per-servo setting in the control table called Return Delay Time (RDT). Range: 2 to 508 microseconds, in 2 µs steps. The host writes it once during setup; the servo honors it on every reply.

Why precision matters: in Sync Read and Bulk Read, the host addresses many servos at once and they reply back-to-back in pre-assigned time slots. A servo that's 200 µs late steps on the next servo's reply and corrupts the bus. RDT is a hard deadline.

In the Fast Sync/Bulk variants the slots stitch into a single coalesced Status frame with zero idle gap, tightening the budget further. That case has its own architecture and its own write-up; this post stays with the foundation it sits on top of.

The foundation is two things the servo has to do, accurately:

Detect the wire-end, the moment the request's last byte finishes (specifically, when its stop bit clocks out).
Schedule its reply to start exactly RDT µs (plus any slot offset) after that moment.

(2) is mechanical once you have a precise wire-end timestamp: arm a hardware timer. The hard part is (1), getting that timestamp precisely across the full DXL baud range, and that's what the rest of this post is about.

2. The CH32V006: what we have to work with

For a dirt-cheap MCU, what is offers is not ideal for hardware based UART timing, but enough to make it work with some effort. Let's layout the relavent parts:

Core. QingKe V2A @ 48 MHz HCLK, single-cycle SRAM. Flash above 24 MHz takes 2 wait-states per fetch, which adds up inside a hot ISR. qingke-rt's highcode feature adds a .highcode section that boot-copies tagged functions into SRAM; we use it for the USART and SysTick handlers.

USART1. This is the DXL bus, and we will be using the following IRQs:

IDLE fires when the line has been idle for 9 bit-times of mark.
RXNE fires when a byte's stop bit clocks in.
TC fires when the last byte of a TX has fully shifted out of the register and onto wire.

All three multiplex onto the USART1 vector, so we need to demux in the ISR code.

DMA1 CH5 is wired to USART1_RX as a circular buffer. RX bytes stream into the buffer in the background, so the USART vector only has to handle IDLE / RXNE / TC, not byte copying.

SysTick. is a 32-bit free counter at 48 Mhz. We use this to schedule TX. The scheduler has to detect if the schedule is in the past, and if so, decided if it should send TX immediately, or it should just drop the response. Compare-match (CMP) mode raises an IRQ when CNT == CMP, so writing a CMP value that's already in the past schedules the IRQ for the next 32-bit wrap, 89 seconds away at 48 MHz. So that's something to be taken account into as well.

3. The two USART flags

The USART hardware hands us two different "the request ended" signals. Each has its own personality.

3.1 RXNE: "a byte just arrived"

Fires once for each byte received. The interrupt happens as the byte's stop bit clocks in, so the timestamp is exactly the wire-end of that byte. Very precise.

The catch is volume: at high baud you get a lot of these. At 3 Mbaud a stream of back-to-back bytes is 300,000 IRQs per second.

(V006 quirk: with RX DMA on, the data register is read before the IRQ handler entries, so STATR.RXNE always reads 0 inside the ISR; DMA wins the clear race. PFIC's pending bit latches per byte independently, so the IRQ still fires 1:1 per byte. Treat IRQ entry itself as "a byte arrived" and read the RX DMA cursor (NDTR, the channel's remaining-count register) for position.)

3.2 IDLE: "the wire went quiet"

Fires once after the line has been idle for 9 bit-times. One interrupt per packet, regardless of packet length. Cheap.

The catch is latency: the interrupt fires roughly one character time after the wire actually went quiet. So if you use the IRQ-entry timestamp as the wire-end, you're systematically a character-time late.

We fix the value by backdating: subtract 9 × BRR HCLK ticks from the IRQ-entry timestamp. That's straightforward. But there's a deeper problem: even with a correct wire-end value, the servo doesn't find out about wire-end until ~1 char-time after the wire went quiet. For low bauds, this is too late to send the response back. We already missed the schedule.

4. Why one char-time of delay breaks low baud

Here's how the reply scheduler is structured:

Wait until the wire-end timestamp shows up from the end-wire timing layer.
Arm SysTick CMP at wire_end + RDT.

The scheduler needs the wire-end timestamp to arrive before the deadline. With IDLE-based timing, the timestamp shows up roughly one character time after the wire-end happened. That's the publish latency, and it's baked into the IDLE flag; backdating fixes the value but not when you learn it.

What happens if publish latency exceeds RDT? The deadline is already in the past by the time the scheduler tries to use it. SysTick CMP can't be scheduled in the past, so the only thing it can do is fire immediately, which technically violates the protocol.

Concrete example: 9600 baud, RDT = 250 µs

quantity	value
`char_time = 9 bits / 9600 bps`	937.5 µs
publish latency (IDLE)	937.5 µs (one char time)
RDT (the deadline)	250.0 µs
late by	687.5 µs, every reply

The servo can never make this deadline in IDLE mode. At high baud the same math is fine. At 1 Mbaud the character time is 9 µs; with RDT = 250 µs the servo has ~241 µs of slack. IDLE is plenty fast.

So the answer is baud-dependent: low baud needs the per-byte (RXNE) approach, high baud is happy with the per-packet (IDLE) approach.

5. The decision rule

Use IDLE whenever it can meet the deadline; use RXNE when it can't:

char_time_us       = 9_000_000 / baud_hz       # publish latency of IDLE
rdt_us             = return_delay_2us × 2      # the deadline budget
pipeline_margin_us                             # headroom for ISR/dispatch work

use_rxne_framing = char_time_us + pipeline_margin_us > rdt_us

The pipeline_margin_us term accounts for the work between "IDLE ISR publishes timestamp" and "scheduler reads it." Measure on hardware and add a few µs of headroom. ~20 µs is a reasonable starting point on V006.

5.1 What does the rule pick?

With pipeline_margin_us = 0 to keep the numbers clean (a real margin nudges the boundary slightly toward more RXNE):

baud	char_time	RDT = 2 µs	RDT = 250 µs	RDT = 508 µs
9600	937.5 µs	RXNE	RXNE	RXNE
57600	156.3 µs	RXNE	IDLE	IDLE
115200	78.1 µs	RXNE	IDLE	IDLE
1 M	9.0 µs	RXNE	IDLE	IDLE
3 M	3.0 µs	RXNE	IDLE	IDLE

Quick read:

The minimum RDT (2 µs) always forces RXNE: no budget for publish latency.
At a typical RDT of 250 µs, IDLE works from 57600 baud upward.
Slow buses (below ~17.7 kbaud) need RXNE even at the max RDT.

The two strategies sit at opposite ends of the trade-off naturally: at low baud, bytes are slow and per-byte interrupts are cheap in total; at high baud, packets are short and per-packet interrupts are all you need.

6. End-to-end timelines

6.1 IDLE mode (typical high-baud operation)

Three bytes arrive close-packed. RXNE pulses per byte but the end-wire timing layer ignores them. After ~9 bit-times of quiet the IDLE IRQ fires; the handler backdates wire_end = now − 9·BRR and pushes (bytes_added, wire_end) onto the IDLE-stamp queue. Main loop parses; dispatcher calls request_complete(parsed_end); scheduler arms SysTick CMP at wire_end + RDT. SysTick fires → fire_now() flips TX_EN, enables DMA CH4.

One interrupt per request. Cheap and clean.

6.2 RXNE mode (low-baud or minimum-RDT operation)

At low baud the bytes are spread out, and each RXNE fires far enough apart that per-byte work is cheap. The handler overwrites a single-cell snapshot (rx_cursor, now) on every byte. Main loop parses; dispatcher reads the snapshot for parsed_end's position to get the wire-end tick; SysTick CMP arms at wire_end + RDT.

One interrupt per byte. At 9600 baud a 14-byte request is 14 interrupts spread across 14.5 ms, barely a blip. At 1 Mbaud it would be 14 interrupts in 140 µs, far too much, which is why the rule never picks RXNE at high baud.

6.3 Fast last-servo

A third path, the Fast Sync/Bulk last-servo reply, has to snoop predecessor slots and CRC bytes it didn't generate. It's its own architecture and out of scope here.

7. Interrupt responsibilities

Priority	IRQ	What it handles	Where it lives
High	USART1	IDLE + RXNE + TC (all multiplexed)	`.highcode` (SRAM)
High	SysTick CMP	Reply deadline → fire TX	`.highcode` (SRAM)
Low	DMA1_CH1	ADC kernel pump (20 kHz)	flash (cold path)

The TC branch of the USART1 vector is also where deferred state changes apply: a host-issued baud change can't retune the USART mid-reply, so it queues up and the TC handler re-tunes BRR and re-runs the IDLE-vs-RXNE framing decision once the reply has drained.

8. The consumer side

When the dispatcher finishes parsing a request, it asks the end-wire timing layer "when did this request's last byte hit the wire?" via request_complete(parsed_end). The lookup branches on the current end-wire timing mode.

In IDLE mode the end-wire timing layer scans the queue for the entry whose cumulative byte count matches parsed_end, returns that tick, and pops it. If no entry matches, return None: either the IDLE flag hasn't fired yet, or the queue overflowed and the matching entry was dropped.

In RXNE mode the end-wire timing layer reads the single-slot snapshot of the most recent byte's (position, tick). The consumer checks whether the position matches parsed_end:

If yes, return the tick.
If no (more bytes arrived between parse and lookup), return None.

Returning None is graceful degradation. Slot-timed callers (Sync, Bulk, Fast Read) must skip when the answer is unknown; they can't safely fire without a precise timestamp. Direct unicasts may proceed with an immediate fire, accepting the timing slip.

8.1 Why a queue for IDLE but a single cell for RXNE

Different timing regimes, different simplest solution.

IDLE mode runs at high baud. Packets can arrive faster than the main loop polls: three Sync Reads in quick succession will pile three IDLE timestamps before the dispatcher gets to any of them. A small FIFO absorbs the burst. Depth 4 is plenty.
RXNE mode runs at low baud. Inter-byte time is at least ~17 µs (at 57600) and grows to ~100 µs at 9600. The dispatcher's parse-and-lookup is sub-microsecond. By the time the next byte's IRQ fires, the previous packet's lookup has long since completed. No concurrent stacking, so a single cell suffices.

9. Where the V006 sits on the DXL 2.0 spec

Plain unicast and non-coalesced Sync/Bulk replies pass the spec across the full DXL 2.0 baud range, using the timing mode the decision rule picks at each (baud, RDT) pair.

baud	char_time	timing mode	plain DXL reply (RDT 250 µs)
9600	937.5 µs	RXNE	passes
57600	156.3 µs	IDLE	passes
115200	78.1 µs	IDLE	passes
1 M	9.0 µs	IDLE	passes
2 M	4.5 µs	IDLE	passes
3 M	3.0 µs	IDLE	passes

The harder case, Fast Sync/Bulk Read as the last servo (zero-idle coalesce + CRC over the whole frame), runs into a separate ceiling driven by SysTick CMP → TX_EN fire latency rather than by RX detection. That case has its own write-up.

CH32V006 Servo Controller Dev Board (Rev. B) Fab Ready

Aaron Qian — Tue, 09 Jun 2026 02:50:51 +0000

When the first Rev B board came back from PCBWay, I hooked up the WCH-LinkE, fired up the debugger, and tried to connect. The debugger reported no target at all. The board was clearly powered (3.3 V rail LED on, no heat, no smoke), and the LinkE itself was alive, but whatever was on the other end of the SWD lines wasn't answering. Unlike Rev A where I failed my way to debug success, I didn't actually have to probe to know what was going on this time. It immediately hit me that the Rev B schematic puts nRST and OPN2 on the same physical pin, and is tied to ground. This means the chip is held in reset forever, no way of changing nRST to GPIO via LinkE...

If you're new here, 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. The CH32V006 dev board is the firmware development platform for this project. Rev B is the second revision, announced in April and fabricated and assembled by PCBWay as a sponsored run.

TL;DR

Symptom: fresh Rev B board doesn't enumerate to the debugger. Chip held in reset.
Cause: nRST and OPN2 share a pin. Default function on a virgin chip is nRST. OPN2 is wired to ISNS-, the negative tap of the low-side shunt, which sits near GND. So the pin reads low and the MCU never leaves reset.
Workaround for the five sponsored boards: scrape off the solder mask to reveal the ISNS- copper trace, cut the trace, flash the USER option byte to remap nRST → GPIO, patch the trace back with a 0Ω 0805 resistor.
In-rev fix: added an SB1 solder bridge footprint on that segment. Close it after the option byte is flashed.
Status: Rev B is validated. Published files include the solder bridge patch.

The Rev A Story Behind This

Rev A had ISNS- routed to OPN0, which the V006's silicon refused to use as a differential negative input. The OPA fell back to single-ended with its negative tied internally to GND — effectively neutering the Kelvin sense traces and making bidirectional current sensing impossible. I wrote up the rest of the Rev B delta back in April when the design was done but not yet built. The fix was to move ISNS- to OPN2, which is a valid OPA negative input but happens to share its package pin with nRST. The trade was: lose hardware reset, gain proper differential current sense. The plan was to disable nRST at provisioning by programming the USER option byte.

That plan itself is fine, it just has a chicken-and-egg problem on a fresh chip that I totally didn't think about.

Powering On

The boards arrived in mid-May — five PCBA units, sponsored by PCBWay as a continuation of the Rev A run.

Five PCBA units, ESD-bagged, fresh from PCBWay.

Build and assembly quality was clean across all five, with no orientation surprises and no solder issues, and the pre-fab manufacturability review didn't catch anything this time around (Rev A had a pad-clearance call-out before fab; Rev B was quiet). When I plugged in USB-C, the 3.3 V rail LED came up immediately, and the silkscreen was correct everywhere I looked. From the outside everything looked right.

Then I went to flash firmware, which is where I ran into the bootstrap problem I described above. To free up the shared pin for OPA use, the USER option byte has to be reprogrammed to set nRST → GPIO, and the only way to do that is through the WCH-LinkE. But on a fresh chip whose nRST pin is being held low through the ISNS- path, the LinkE has nothing to talk to. The chip is held in reset by the very analog front end it's supposed to be sensing, and there's no way for me to reach it from the outside to fix the reason it's stuck.

Cut, Flash, Patch

The way out is to break the path between the MCU pin and ISNS- long enough to program the option byte. With OPN2 / nRST floating, the MCU's own internal pull-up brings the line high, the chip releases reset, the WCH-LinkE can flash the USER option byte to nRST → GPIO. After that, the pin is no longer a reset input, so reconnecting it to ISNS- is harmless. The OPA can do its job.

For the five sponsored boards, I did this by hand under a magnifier. The procedure I landed on, after a false start I'll mention in a moment, was:

Scrape the solder mask off the top of the OPN2 ↔ ISNS- trace with a hobby knife to expose the bare copper underneath.
Scrape harder across that exposed copper to take a tiny piece of the trace off and break continuity. The trick is keeping the cut narrow enough to avoid taking the surrounding ground pour with it.
Verify isolation with the multimeter's continuity function.
Plug in the WCH-LinkE and flash the USER option byte to nRST → GPIO.
Tin the two exposed copper stubs on either side of the cut, with generous flux.
Tin the back pads of an 0805 0 Ω resistor.
Position the resistor across the cut with tweezers so it sits on top of the tinned stubs.
Hit it with hot air while pressing down lightly on the resistor. The scrape leaves the bare copper slightly concave, so a bit of downward pressure is needed for the solder to wick up under the resistor's pads.
Let it cool, then measure continuity again to confirm the bridge.

Step 8 in progress on one of the boards — hot air aimed at the 0805 0 Ω resistor sitting across the cut, with the OSC logo visible in the corner. Holding a small downward pressure on the resistor while the solder reflows is what gets the joint to actually take.

The false start was that I first tried bridging the cut with just a plain solder blob — the way the in-rev SB1 footprint is meant to close. It didn't take. I couldn't get a blob to anchor across the scraped gap reliably, and I think the reason is that the bare copper surface left by the knife is too uneven and too small to hold a clean blob. An 0805 sitting on top gives the solder a flat surface to pull against, which is why that version worked. The real SB1 footprint won't have this problem because the pads are properly-fabbed flat copper, not whatever shape I happen to expose with a knife. So a plain blob is the right close for SB1; just not for a hand-scraped trace.

Five boards, five surgeries, all came up cleanly afterward. One thing I'm watching for, though: on a couple of the boards I couldn't keep the scrape perfectly inside the trace, and I nicked the surrounding ground pour. The exposed area is small, but the analog signal on ISNS- is small too — tens of millivolts at full-scale current — so a thinner local ground around the cut could in theory show up as a higher noise floor on the current sense from ground-bounce. I haven't characterized it yet, and it might not actually matter in practice. But it's another reason the properly-fabbed SB1 version is the cleaner long-term path: the bridge sits between intact ground-pour edges, with no exposed copper or thinned ground around the joint.

It works, but "every board needs a trace cut on first power-on" is not a thing I want to put in a README. The right shape is a footprint that's already there.

The In-Rev Fix: SB1

I added a 2-pad solder jumper, SB1, on the OPN2 ↔ ISNS- segment. Standard open-default solder-bridge footprint, so boards ship from fab with the bridge open by default.

SB1 sits between U2 and RS1, just left of the ISN- / ISN+ test points. Open from fab; close it with a small solder blob after flashing the option byte.

The first-boot procedure on the board README is now:

Confirm SB1 is open.
Program the USER option byte via the WCH-LinkE at J4 to set nRST → GPIO.
Close SB1 with a small solder blob.

After this, the board runs as designed. One-time step per fresh chip, comparable to soldering on a header.

This is small enough that I'm calling it an in-rev patch and not a Rev C. The schematic and layout were updated, the published Gerbers include the bridge, the existing Rev B tag still applies. The five sponsored boards I patched by hand are functionally equivalent to a freshly-fabbed board with SB1 closed. The two are the same Rev B as far as I'm concerned.

The cost is one extra step on the bring-up procedure. The benefit is that I don't burn another sponsored fab run on a single-trace change. PCBWay was generous; spending the next slot on this would not have been a good use of it.

On the Boards Themselves

The five PCBA units PCBWay delivered are clean, with no assembly issues, no orientation flags, and no rework needed on anything I could see under the magnifier.

Front (top) — components, silkscreen, logo, and QR code all clean. Back (bottom) — board name, OSC iconography, and the second QR code on the silkscreen.

What stands out across both Rev A and Rev B is how consistent the finish and the process are. The black soldermask is even, the white silkscreen sharp enough that all the small text and the QR codes are legible without a loupe, and the two-tone OSC logo (silkscreen letters plus exposed-copper decorative iconography) came out crisp. The O is the part I keep coming back to — there's an encoder-disk embellishment inside that letter, with thin radial slots, and it's small enough that I honestly didn't expect a fab to hold the edges cleanly at this scale. PCBWay did. On the service side, the same pre-fab manufacturability review runs every time — it caught a real pad-clearance issue KiCad's own DRC missed on Rev A, and turned up nothing on Rev B — and the same in-assembly verification photos for orientation-sensitive parts arrived in my inbox during the Rev B build, with the same little paper "+" cutouts next to LED anodes I remember from last time. Replies come back in the time zone I'd expect for a partner in China, and the back-and-forth feels collaborative rather than transactional. The only thing they couldn't catch on Rev B was a design-level issue that requires understanding the analog front end, and that's on me, not them.

What I want to credit specifically is that this is the second sponsored fab run, not the first. Hardware sponsorships in my corner of the internet usually go one round: boards arrive, post goes up, both sides move on. PCBWay came back for Rev B anyway, after the Rev A bug saga (published in full, three embarrassing mistakes, magnet-wire surgery, the whole thing), and it wasn't conditional on anything. No editorial review on the Rev A post, no editorial review on this one. The arrangement, both times, has been: fab the boards, write whatever you want. For an open-source project that has to be honest about its bugs to stay credible, that's the only sponsorship shape I can actually accept. It's rarer than it should be.

What the sponsorship also buys me concretely is the time and focus I'd otherwise spend on the parts that aren't OSC. Without it, every revision would mean shopping the BOM myself, hand-assembling the boards (or at minimum doing the QFP rework), and second-guessing build quality on every spin. PCBWay handles all of that. The boards arrive ready to run, the BOM gets sourced even when chip stock is tight (which it was for the V006 on Rev A), and the build quality is consistent enough that I can just trust it and move on to firmware. For a hobbyist project that runs on evenings and weekends, those compromises aren't marginal to skip — it's the difference between fighting the hardware and getting to write code. And PCBWay has now done this for me twice.

Without PCBWay, OSC would look different. The dev board iteration cost would gate the shape of the project, not just its cadence, and the "fail in the open" posture I want this project to have would be much harder to keep. So: thanks. Plainly, no strings attached.

If you want to fab your own Rev B, the easiest path is the PCBWay plug-in for KiCad (install from KiCad's Plugin and Content Manager). Open this project, hit upload, the Gerbers and BOM go straight to your cart. If you'd rather not install KiCad, the design is also up as a PCBWay community project — one click loads the validated files into the cart.

One tip from my own mistake on this run: if you want the OSC logo's exposed-copper iconography to come out gold-on-black the way it was designed, pick Immersion Gold (ENIG) for the surface finish. I accidentally left mine on HASL, which is a silver-tin coating, and the iconography ended up silver instead of gold. It still looks fine — the two-tone shape carries the logo on its own — but ENIG is the choice if you want the look from the Rev B announcement post.

Either way, remember the first-boot procedure above. SB1 is open from fab on purpose.

What's Next

Firmware never paused while Rev B was off being fabbed — DXL and comms have been the main thread of the last several weeks, since most of that work runs perfectly well on a Rev A board. What Rev B specifically unblocks is the OPA / current-sense path that Rev A literally couldn't do, so the cascade current loop can now move from "designed on paper" to "actually verified against working hardware."

The DXL comms path is going well. DXL 2.0 with FAST commands at 3 Mbps is live on the bench.

All five Rev B boards daisy-chained on the DXL bus (G/V/D), with the scope hooked to DATA and DBG on the first chip in the chain while I'm exercising the protocol stack. Terminal is mid yay -Syu, because that's how bench shots go.

The current implementation leans on software for RX / TX timing and TX scheduling, which works but couples the protocol layer to HSI fine-trim and a few other things I'd rather not be coupled to. I'm pivoting that whole stack to hardware-based timing — TIM2 input capture for RX edges, hardware-fired TX scheduling — so the protocol layer stops caring about microsecond-level CPU jitter. More articles about the DXL timing architecture coming soon, including why software timing hit a wall and what the hardware-timed version actually looks like.

With Rev B validated and the DXL transport getting its hardware-timing rework, the cascade current loop is the next big block after that.

The MCU pin is shared, and now there's a small bridge to make that explicit. A small price for a real differential OPA.

CH32V006 Servo Controller Dev Board (Rev. B) Designed

Aaron Qian — Sat, 02 May 2026 02:34:12 +0000

Rev A took board surgery to power on. Then I hit an RX line that refused to go LOW. Then I noticed a third defect I never wrote up: the differential current sensing on the OPA wasn't actually differential. Rev B is the respin that fixes all three, plus a handful of features I was going to need anyway.

TL;DR

Status: designed, not fabricated. I've reviewed Rev B carefully and don't expect another Rev A-scale surprise. But the hardware hasn't been built or validated yet. If you want to fab one yourself, wait for the bringup post. Or fab it at your own risk knowing the design is unproven.

The big-ticket items.

Fixed:

VDD/VCC swap.
UART RX contention. Added jumper on RX line to select between LinkE or TTL port.
Various silkscreen label fixes.
Battery polarity.
V006 OPA pin mapping for differential current sensing, and as a result:
- Reset pin & button gone, assigned as OPN2.
- Hardware fault trip via CMP2.
- 5V instead of RST pin for WCH-LinkE port.
- Added VSYS sense to extra pin.

Added:

External NTC connector with onboard / external select jumper.
PWM servo header for system ID.
Dual-mode encoder input (TIM2 quadrature or ADC analog).
First silkscreen logo for the project.

KiCad project: hardware/boards/osc-dev-v006. Full revision delta in the CHANGELOG.

Interactive 3D model of the board is available on the original post.

What's Fixed from Rev A

The fixes are the boring half of the story. They're show-stoppers when they're broken, and invisible when they're right. Five things.

VDD / VCC swap. This is the Rev A bug, the one that caused the MCU surgery saga. Rev B has the schematic right. A fresh chip will power on without magnet wire.

Top-row test-point silkscreen. Every label was wrong on Rev A (the photo lives in the TX_EN debug post). The labels are now what the underlying nets actually are.

Encoder connector labels. Same story, smaller surface area.

JST-PH battery polarity. Was reversed. Now it isn't.

TX_EN / UART RX contention. This one came out of the scope-debug session where I figured out the half-duplex buffer was actively driving RX. Rev B adds JP2, a jumper that routes the MCU's RX either through the TTL buffer (DXL mode, normal operation) or floats it (LinkE plain-UART mode, with the LinkE driving RX directly via J4). The point is that UART now works on a bare chip with no firmware running, which is the property that wchisp and similar tools actually require. Recovery-path peripherals shouldn't depend on firmware to function. A jumper is a small price for that property.

What's New

These are the additions, with the differential current sensing piece up front because it's the one Rev A literally can't do. The rest are features I folded in while the respin was happening anyway, mostly aimed at letting the dev board double as a system-ID rig later (motor constants, stock-servo characterization, that kind of thing). Same MCU, same motor driver, same shunt, same DXL bus. One board, three roles. The marginal cost of each was small enough that it would have been silly not to.

Differential current sensing, actually differential this time

This is the Rev A defect I haven't written up until now, and arguably the most serious one. ISNS- was routed to OPN0, which isn't a valid negative input for the V006's differential opamp. The only configuration the silicon would actually accept was one where the OPA's negative input was internally tied to ground. Which means the Kelvin sense traces on the GND side of the 10 mΩ shunt were doing nothing. The board was effectively single-ended, sensing the shunt against silicon GND, and could only see current flowing one direction. For a front end whose whole job is to feed a cascade current loop, that's a fatal flaw.

Rev B fixes this. ISNS- is now on OPN2 instead of OPN0. ISNS+ stays on the OPA positive side via OPP0. Because OPN2 shares its package pin with nRST, I had to remove the reset button and free up the pin for analog use. This means the USER option byte gets programmed to disable reset-on-NRST at provisioning. See Pin Remap for the full domino chain that hangs off this one decision.

What this actually buys is worth the trade-off though. Three things, in order of how big a deal each one is.

The first is accuracy. The Kelvin sense traces I'd laid out on either side of RS1 finally do their job. The OPA differentially measures the voltage across the shunt, instead of measuring single-ended with the negative input bonded to ground. Without actually using the Kelvin traces, the reading will be polluted by voltage drops along the GND return path.

The second, and the bigger deal, is bidirectional visibility. Rev A could only see current flowing into the motor. With differential OPA setup, the board can see current flowing in the other direction too, such as back-EMF during deceleration, regen, freewheeling current through the diodes during PWM off-time. All of these produce reverse current through the shunt, and a correct PI current loop needs the signed integral of that signal, not a clipped one. I'm sure more uses will surface as the firmware gets real (better state estimation, that kind of thing). Back-EMF and regen are the ones I can name with confidence today.

The third is that this is basically free. The shunt and MCU's internal opamp supports this with no extra BOM. The only cost is the hardware reset feature, which I can live without.

Hardware overcurrent / fault protection (CMP2)

The OPA output also feeds CMP2, the V006's internal comparator. The comparator can be configured to raise a fault on overcurrent and stop PWM generation without firmware runtime involvement. Even if the main loop is hung, the trip still fires through silicon.

With a 10 mΩ shunt, 32x gain on the PGA in self-biased differential mode (VBEN=1, VBSEL=1), and DRV's 4 A peak, the shunt drops ±40 mV at full-scale current. The OPA output sits at a ~1.44 V bias and swings ±1.28 V around it, putting the absolute range at 0.16 V to 2.72 V. This is well inside the ADC's 3.3 V range. The CMP2 negative side can be configured to trip on ~85% of VDD, which is ~2.8 V. This means although it won't trip on this development board on overcurrent (the DRV8212P self-limits at 4 A first), it CAN detect motor shorts and catastrophic current surges. The dev board is designed to be flexible for testing different kinds of servos, but still offer some protection against magic smokes.

For swap boards, the shunt can be sized so that the fault threshold of the specific servo lands near the top of the OPA range. Same role as on the dev board: catch hardware failure, not normal operation. For example, the SG90 datasheet specs a 650 mA stall, but inrush can spike well above that on startup, so we want the trip set with margin, somewhere around ~1.2 A (~2× datasheet stall) to ride above normal operation while still catching motor shorts and jams beyond mechanical stall. With a 35 mΩ shunt (a common 1206 1W value, easy to source), the OPA swings ±1.33 V around the 1.44 V bias at 1.2 A, putting the output at ~2.77 V. That's right at the CMP2 trip threshold of ~2.8 V (VBCMPSEL=10). Normal stall (650 mA) lands at ~2.16 V on the OPA output, comfortably below the trip. Bidirectionally, the ADC sees from −1.30 A (negative rail) to +1.67 A (positive rail) before saturation, plenty of headroom for back-EMF and regen.

External NTC connector and JP1 source select

The onboard NTC (TH1) measures ambient board temperature. That was useful as a stand-in for the V003's lost internal temperature sensor in the first version. It's not what you want during motor-stress testing, where the temperature that matters is the temperature of the motor windings. Rev B adds an external NTC connector (J6) and a jumper (JP1) to pick between the two. Onboard for ordinary firmware-dev work, motor-attached for characterization runs.

PWM servo header (J3)

A standard 1×3 hobby servo header, driven from IN1. With this connector, the encoder, and proper firmware, it opens up the possibility for servo characterization such as positional accuracy, slew rate, error percentage on repeated sweep / return-to-center tests. I have some fun ideas on setting up a rig based on this board to automatically ID a servo by streaming the data using the same single-wire UART protocol.

Dual-mode encoder input (J8)

ENCA and ENCB are now pin-mapped to both TIM2 and the ADC. Same 2×2 header, two acquisition modes, picked in firmware. The reason for this is that I didn't want to commit the dev board to one encoder strategy.

In TIM2 mode, the connector takes a standard digital quadrature encoder, magnetic or optical, and counts edges in hardware with no MCU overhead. This is the default mode for motor-speed feedback during motor-ID runs and for any off-the-shelf encoder integration.

In ADC mode, the same pins are sampled by the ADC, which means the connector also accepts ratiometric analog encoders. The specific use case in my head is something like the IR-quadrature sensor stack used in Adam Bäckström's ServoProject, where you read sin/cos directly off a pair of photodiodes, do sub-count interpolation in firmware, and end up with very high effective resolution from a homebrew flex-PCB sensor. Backlash-compensation work and the higher-precision experiments live here.

VSNS for direct VSYS sensing

Rev A inferred the system voltage from VSNA and VSNB (the motor-terminal sense dividers). That's fine when the motor is running, but it breaks when it's idle. Rev B adds a dedicated VSNS divider so the board measures VSYS directly regardless of what the motor driver is doing.

WCH-LinkE 5 V as a fourth power input (J4 pin 6)

The WCH-LinkE programmer has a +5V line to the target board. Since we no longer have nRST, this pin is now repurposed in Rev B as a power input, gated by an SS54 into the same OR network as USB-C, the JST battery, and the screw terminal. Now you can use LinkE as the sole power source for the board during development. No need for a separate USB-C cable.

PCB Art / Logo

I delayed and delayed coming up with a logo for OpenServoCore because one, I'm not really good at graphic design, and two, I just kept on prioritizing PCB / firmware related tasks. But I somehow decided that it was time because I want to actually include a nice looking logo on the Rev B PCB. So, I designed one this week, and it came out better than I thought.

The logo purposefully uses a two-tone design. This is because I can use one tone (white) as the silkscreen for the OSC letters themselves. And then use the golden color of exposed copper for the finer decorative symbols. It came out surprisingly well, given that I'm not a graphic designer.

There's also a small QR code on the silkscreen that points at the docs page for this board. I'd been putting this off for the same reason. This is a board meant for other people, and "scan to read the docs" is pretty much the standard these days.

MCU Pin Remap

The pin map is where the rest of the design rearranges itself around the OPN2 fix. Five things changed.

ISNS+ / ISNS- → OPP0 / OPN2. Fixes the Rev A defect where ISNS- was on OPN0 and the OPA could only run single-ended. See Differential current sensing for the why.

nRST removed. It shares a pin with OPN2, so the OPA fix forced this. The USER option byte gets programmed at provisioning to disable reset-on-NRST. The reset button and its RC debounce network are gone with it. Net pin budget: minus one reset, plus one working differential current sense.

ENCA / ENCB selectable between TIM2 and ADC. Same connector, two acquisition modes, picked in firmware. See Dual-mode encoder input for the why. Pin-map cost was finding channels that have both TIM2 capture and an ADC channel attached, which constrained the rest of the placement more than I expected.

STAT LED moved to a TIM1 channel. Gives the LED PWM brightness and pattern control instead of binary on/off. With the remaining pins, one of them happens to be TIM1 CH4 for remap 7. So I'm assigning the STAT LED to this pin for brightness control / breathing etc.

Board renamed. servo-dev-board-ch32v006 → osc-dev-v006. Matches the project's naming convention now that the board family is filling in.

Where to Get It

KiCad project lives in the OSC monorepo under hardware/boards/osc-dev-v006. The full revision delta is in CHANGELOG.md inside that directory.

There is one more note on component availability. When the first revision went out, JLCPCB had no CH32V006F8P6 stock at all and PCBWay had to source the chip externally. Now both JLCPCB and LCSC have restocked the part. At the time of writing, there are a couple thousand of them, so if you are confident enough to fabricate one, it should be doable via JLCPCB now.

What's Next

I don't expect any more serious issues with Rev B. It should just be plug and play. My plan is to order Rev B, do one more pass of validation, and start writing code for the OSC firmware. Most of the bringup work is already done on Rev A. When Rev B arrives, I just need to tweak the register setup a bit and it should be good to go.

The focus now shifts to firmware, fingers crossed.

CH32V006 Servo Controller Dev Board (Rev. A) UART Validation

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.

DEV Community: Aaron Qian

CH32V006 Servo Controller Firmware - DXL 2.0 RX Timing

Glossary

1. What's on the wire

2. The CH32V006: what we have to work with

3. The two USART flags

3.1 RXNE: "a byte just arrived"

3.2 IDLE: "the wire went quiet"

4. Why one char-time of delay breaks low baud

5. The decision rule

5.1 What does the rule pick?

6. End-to-end timelines

6.1 IDLE mode (typical high-baud operation)

6.2 RXNE mode (low-baud or minimum-RDT operation)

6.3 Fast last-servo

7. Interrupt responsibilities

8. The consumer side

8.1 Why a queue for IDLE but a single cell for RXNE

9. Where the V006 sits on the DXL 2.0 spec

CH32V006 Servo Controller Dev Board (Rev. B) Fab Ready

TL;DR

The Rev A Story Behind This

Powering On

Cut, Flash, Patch

The In-Rev Fix: SB1

On the Boards Themselves

What's Next

CH32V006 Servo Controller Dev Board (Rev. B) Designed

TL;DR

What's Fixed from Rev A

What's New

Differential current sensing, actually differential this time

Hardware overcurrent / fault protection (CMP2)

External NTC connector and JP1 source select

PWM servo header (J3)

Dual-mode encoder input (J8)

VSNS for direct VSYS sensing

WCH-LinkE 5 V as a fourth power input (J4 pin 6)

PCB Art / Logo

MCU Pin Remap

Where to Get It

What's Next

CH32V006 Servo Controller Dev Board (Rev. A) UART Validation

Background

TL;DR

Initial Troubleshooting

Narrowing It Down

Scope to the Rescue

Back to the Schematics

The Absurd Workaround

The Real Fix

tinyboot v0.4.0 Released — The API is Stable

Links

What is tinyboot

Platform Support

V00x Support

Everything Fits

Crate Restructure

Protocol and API Changes

Bug Fixes

Docs Overhaul

What "Stable" Means

What's Next