OSC Dev V006 Rev B Bring-Up - One Trace Cut for a Fresh-Chip Bootstrap

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.

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:

1. Scrape the solder mask off the top of the OPN2 ↔ ISNS- trace with a hobby knife to expose the bare copper underneath.
2. 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.
3. Verify isolation with the multimeter’s continuity function.
4. Plug in the WCH-LinkE and flash the USER option byte to nRST → GPIO.
5. Tin the two exposed copper stubs on either side of the cut, with generous flux.
6. Tin the back pads of an 0805 0 Ω resistor.
7. Position the resistor across the cut with tweezers so it sits on top of the tinned stubs.
8. 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.
9. Let it cool, then measure continuity again to confirm the bridge.

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.

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

1. Confirm SB1 is open.
2. Program the USER option byte via the WCH-LinkE at J4 to set nRST → GPIO.
3. 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.

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.

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.