Bringing the board to life

No powerStep 0 — Receiving inspection

Before a probe touches anything.

1. Put the ESD strap on first, and work on a mat. Handle every board by its edges.
2. Photograph the packaging before you open it, and each board as it comes out. If there is shipping damage, this is your evidence. A 300 × 322 mm 6-layer board is a plausible flex casualty in transit.
3. Support each board flat. 1.6 mm thick over a 300 mm span is a floppy ratio, and the underside is populated with passives — support it on something soft and full-area, never clamped by two edges.
4. Visual inspection of all five. Look for tombstoned passives, solder bridges, missing parts, and — most valuable — sweep your eye down the FET field checking that every SOT-323 pin-1 marker is in the same corner. Rotation was already verified on JLC's DFM image before production, so this is confirmation rather than discovery, but it is the one fault that takes out all four boards at once.
5. The bare board will probably still carry its two 5 mm edge rails, since depaneling is a PCBA-side option. Snapping those off an unpopulated board by hand is safe. Do not flex the four assembled ones.
6. Set the bare board aside. Its job is to be looked at and to be a reference artefact — it is the die artwork with nothing in the way. It is also your spare.

No powerStep 1 — VCC↔VSS resistance

Measure resistance from a VCC bond pad to a VSS bond pad on each of the four assembled boards. Record the polarity and the range with every number — on this board a bare figure in ohms is meaningless, for the reason below.

Gate: red on VSS reads a few hundred ohms and the value changes with range; red on VCC reads OL on a low range.

There is no resistive path between the rails at all — verified against gen/netlist.json by tools/step1_model.py. The meter is reading a junction: every pull-down FET's body diode conducts VSS → drain, and where that drain carries a 10 kΩ pull-up it forms a VSS → VCC branch. There are 1,899 such body diodes across 947 nets. So what the meter displays is a diode drop divided by whatever current the selected range happens to source, and it legitimately reads 195 Ω, 314 Ω or 3.77 kΩ for the same board.

What identifies a genuine fault is therefore not a low number, but a number that behaves like a resistance:

• Under ~1 Ω — a solder bridge. The rails are solid planes with thousands of stitching vias; a bridge reads a fraction of an ohm, not hundreds.
• The same value on every range, in both polarities — a real resistive path. A junction cannot do this; its apparent resistance must move with range.
• One board unlike the other three.

5 VStep 2 — Board alone at 5 V, unclocked, no Pico

This is the single most informative measurement in the whole project. It finds a bridged rail, a reel loaded backwards, and missing pull-ups — the faults that would otherwise be identical on all four boards.

Procedure

1. Croc-clip the supply to a VCC bond pad and a VSS bond pad.
2. Set the current limit to 0.5 A and the voltage to 5 V.
3. Ramp the voltage up from zero while watching the current, rather than switching 5 V on in one step.
4. Read the current at 5 V.

What the number means

Gate: a current reading you understand, on a board you are willing to keep.

5 VStep 3 — Optional: an external clock, and watch the LEDs

Worth doing. It is the first evidence that the logic itself lives, and it needs no firmware.

1. Croc-clip a function generator to the Φ0 bond pad.
2. Drive clk0 push-pull at a few kHz. The board has no pull-up on clk0 — an open-drain driver would leave it floating, and a dynamic CPU cannot survive that.
3. Watch the register LEDs.

The data bus floats, because no memory is connected, so the CPU executes garbage. That is fine and expected. What matters is that the register LEDs move. Movement proves two things at once: the internal clock phases (cclk, 482 gates; cp1, 198 gates) are being regenerated on-board at full VCC swing, and the dynamic logic is holding charge between edges.

void setup() {
  pinMode(8, OUTPUT); digitalWrite(8, LOW);   // RES asserted low
  tone(9, 4500);                              // clock running FIRST
  delay(20);                                  // ~90 clocks at 4.5 kHz
  digitalWrite(8, HIGH);                      // release reset
}
void loop() {}                                // tone() is timer-driven

No powerStep 4 — The eight-site 10 kΩ rework

Full illustrated instructions, with true-scale renders of all eight sites and their neighbouring designators: the rev A rework page. Follow that page for the procedure; this is only why it belongs here in the sequence.

The board as fabricated has a device-ratio defect: the eight data-bus output drivers use a BSS138W as the load against a BSS138W as the pull-down — a 1:1 ratio where ratioed NMOS needs a weak load. Measured consequences at 5 V, per contended site:

The thermal problem is the loud one, but the functional problem is the serious one: a contended node sits at 1.0–1.9 V against a 1.1–1.5 V receiver threshold, so the CPU can write wrong data. The fix is simulated end-to-end in sim/revb_driver.sp, two stages deep to a real chip output — it costs nothing in speed (271 ns rise against a 25 µs budget) and it makes the output level higher, not lower.

Eight sites, all on the front face, in one column at x ≈ 220 mm (dor6/dor7 at x ≈ 216.5 mm), 11–14 mm apart. Same part, same orientation, identical copper — it is the same operation eight times.

Gate, per site: pin 3 lead to a VCC bond pad reads 10 kΩ; pad 3 to VCC still reads ~0 Ω.

Gate, whole board: VCC to VSS still reads high — you have not introduced a bridge.

Clean the flux off after each site and inspect under magnification. Then repeat Step 1 and Step 2 on the reworked board; Step 2 should be essentially unchanged, since contention was near zero unclocked anyway.

No powerStep 5 — Solder the Pico

1. Flash the tester firmware onto the bare module first, on the bench, and confirm it enumerates over USB. Reasons below.
2. Solder the Pico 2 W module onto the underside site.
3. Solder pin 39. This is not a decision to be made per board.
4. Repeat the Step 1 resistance measurement.
5. Only then apply power.

Why flash it before soldering, when it can be reflashed in place

It can be reprogrammed in place, indefinitely and without touching the button: pico_stdio_usb/reset_interface.c is linked into all three firmwares, so the SDK's 1200-baud-touch reset-to-bootloader works and picotool can reboot the module into its bootloader over USB. Flashing once beforehand is still worth it:

• You get to reject a bad module while rejecting it is still cheap. A dead or damaged Pico soldered to this board is a miserable desolder job — the footprint's 3.2 × 1.6 mm pads run under the module — and you would be doing it beside 4,051 transistors you care about. Two minutes on the bench buys that away.
• The first flash is the one that needs BOOTSEL, held while power-cycling. That is the awkward operation, and it is the one you can do off the board.
• It makes the first power-up a known state rather than merely a harmless one. A blank module is safe — RP2350 GPIOs default to inputs — but safe and known are not the same thing.

Why pin 39 must be soldered rather than left off, which was considered and rejected:

• It removes the power-sequencing question entirely. Board VCC and Pico VSYS become one node, so the hazard of a 5 V core driving 26 clamp diodes into a dead 3V3 rail becomes unreachable.
• An unsoldered pin 39 is not an open circuit — it is an intermittent contact. The footprint's 3.2 × 1.6 mm pads extend inward, under the module, so an unsoldered castellation is two flat copper faces held apart only by whatever standoff the neighbouring joints happen to give. Board flex or a croc clip closes it. A rail that makes and breaks corrupts every dynamic node at once, and it reads as a random CPU fault.

With pin 39 soldered, either end can supply power: a bench supply on the bond pads runs the board and feeds VSYS (connect USB for serial only), or USB into the Pico runs everything through the module Schottky. Use the bench supply for anything that matters — USB-only is not viable at 5 V now that the real clocked current is known.

5 VStep 6 — First clocked run: the A-register counter

This is the “it is alive” moment.

1. Build and flash the tester firmware (pico-controller/tester, PICO_BOARD=pico2_w).
2. Power the board at 5 V from the bench supply, current limit at 1 A for this step. USB may stay connected for serial — the module Schottky drops VBUS to ~4.7–4.8 V, so a 5.0 V bench supply wins the node and the diode blocks back-feed into the host.
3. Open the serial terminal. Press h for the command list.
4. Run the default image — an A-register counter loop — and watch the A LEDs count.

For this step the only LEDs that matter are the A column, at x ≈ 145 in the middle of the datapath. If they count and nothing else moves, that is exactly right: the counter loop touches A and the PC, so expect the PCL column to be busy too.

The default clock is a 50 µs half-period, i.e. 10 kHz.

Watch the supply current

Gate: with the rework done, clocked current should stay in the low hundreds of mA.

If it jumps toward 1.8–2.1 A, a rework site did not take. That current step is the measurement — it is the cheapest whole-board verification of the rework you will get. Go back and re-check the eight sites.

Useful commands at this point

R          reset sequence (assert, 8 cycles, release)
c N        run N cycles (quiet)
t N        run N cycles, printing each bus cycle
s [N]      step N instructions, printing cycles
d [N]      dump the last N trace entries
x A L      hexdump L bytes of the image at offset A (hex)
m A B..    poke bytes at offset A (all hex)
z          zero the cycle counter and trace

If the LEDs do not count, t is the tool: it prints cycle  addr(14-bit)  data  r/W  SYNC per cycle, so you can see whether the CPU is fetching sensible addresses at all.

5 VStep 7 — Measure the clock window

Two unknowns that only hardware can settle, and they are the two ends of the same window.

The ceiling — p

Walk the clock up with p US (half-period in µs) until the CPU stops executing correctly. Simulation predicts ~20 kHz at 5 V (~10 kHz at 3.3 V), set by the decode-PLA input lines driving up to 71 gates behind a single 10 kΩ pull-up. The M2 target was ≥50 kHz, so this is a known shortfall, not a surprise.

The floor — W

Only after the rework. This is the test the safety rules exist for.

Dynamic logic has a lower clock bound as well as an upper one: stop too long and the stored charge leaks away. w MS freezes the clock for MS milliseconds and asks whether the state survived; W [MAXMS] finds the boundary by bisection, running a 0 ms control first so a broken harness cannot masquerade as a result.

The worst nodes are sb1..sb7 — one gate of capacitance (32 pF) against twelve FET channels leaking them. The big nets are the safe ones. The decisive number: at the 20 kHz ceiling the worst node must leak under 53 nA per FET (under 27 nA at 3.3 V), or the floor rises above the ceiling and there is no working clock at all. Typical parts are ~1 nA, giving ~50× margin — but SPICE could not resolve leakage at this level, so this is genuinely unmeasured until you measure it.

1. Start with sub-millisecond stalls and ramp up.
2. Keep the current limit on and watch the current through the stall.
3. The result also bounds how long the tester's single-step pause may safely last.

5 VStep 8 — The functional test: the acceptance gate

The bring-up acceptance target is Klaus Dormann's 6502_65C02_functional_tests — the standard suite for 6502 re-implementations rather than emulators.

Run the decimal test first

6502_decimal_test.a65 before the main suite. Decimal mode comes free from the netlist and is the thing emulators most often get wrong, so it is a high-information, short test.

Build the images

Do not assemble by hand. tools/build_functest.py drives the suite's own assembler and does the board-specific work — it needs a checkout of the suite as a sibling directory and Docker, because AS65 1.42 is an i386 binary:

python3 tools/build_functest.py            # both tests
python3 tools/build_functest.py decimal    # just one

Outputs land in gen/functest/: a .hex ready for L, and a _traps.csv listing every self-loop with its source line. The script sets ram_top = $40 (the suite's own preset for a 16k mirrored system), folds 64 KB to 16 KB the way the hardware does and fails on a real aliasing collision, patches the reset vector, and extracts the verdict map.

The addresses you need

Run it

p 50          # the conservative default clock
L             # paste gen/functest/<test>.hex into the terminal
k 0200        # watcher at the progress address ($0001 for the decimal test)
R             # reset
g             # go: run until a self-loop, printing progress

The reset vector is already patched in the image, so the old m 3FFC 00 04 step is no longer needed.

How to read the verdict

The suite has no I/O, so the firmware reads two side channels off the bus: writes to the progress address give live progress, and a repeated opcode-fetch address gives the verdict. Pass and fail are both self-loops, distinguished only by address — which is why the generated _traps.csv matters. It gives every failure address its source line and the test_case number that was current, so a stop narrows 4,051 FETs to a functional block.