DEV Community: Aaron Qian

OSC DEV V006 Rev B Is Ready

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.

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 of that board, routed this week and ready to fab.

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.

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.

DEV Community: Aaron Qian

OSC DEV V006 Rev B Is Ready

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

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

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