BenchPod

Bring-up went well; so far, everything except one minor issue: the RP2350B's flash. Here's a picture of the board, then more about the W25Q64JVSSIQ (flash) component.

While doing the PCB layout in KiCad across 2 screens, with the mouse pointer focused on the schematic view rather than the PCB window, I accidentally hit a button, and the flash component moved within the schematic. I only realized it a few minutes later, so I couldn't use ctrl+z. I moved the flash symbol back, fixed the messed-up wiring, and continued with the PCB. What actually happened that I didn't realize is that the symbol was mirrored, and all the wiring was correctly placed, but to the wrong, mirrored pins. I then traced it like that in the PCB, and that's how my flash doesn't work in v1. Luckily, I don't need it, so I just flash to SRAM instead for this version. The flash for the iCE40 was actually untouched, so that one works! Here's a screenshot of how the mirrored symbol looked, pretty obvious, but I didn't check it in detail in the schematic anymore, as I didn't make any changes.

Quickly shipped the v1 of our bench board to validate bring-up while still iterating on the design. Did I know analog has such a steep learning curve?! Finally sat down to do a full SPICE analysis and... turns out I've been feeding pure noise straight into my ADC. The VTOP and VBOTTOM pins of the ADC08060 are missing their resistors. Oopsie. Guess I'll be scratching a trace or two and squeezing in some resistors.

Also tried to replicate the analog capture flow using a cheap Aliexpress ADC/DAC and a step motor, only to realize the ADC does AC coupling, and my DC signal is gone. Definitely spending some more time than anticipated on the analog path for the waveform capture, replay, and fault injection.

On the pictures:
1) breadboarded the iCE40 + RP2350 + ESP32 (wifi) with the iCE40 connected to Aliexpress ADC/DAC (DAC works end-to-end over wifi, but needs another ADC for capture to work - the v1 that will arrive shortly with the noise issue, but that's solvable)
2) LTspice showing the missing resistors on the ADC input pin

Let's talk about BenchPod's design decisions. The first version is produced by JLCPCB and is in transit. Once arrived, I'll test the basic functionalities and iterate on the design.

The core problem that BenchPod is built around is that test hardware doesn't scale across a team. A board sits on one engineer's desk, someone else needs it, and people end up waiting or working in the dark. Using a board usually means being in the same room as it is. Flashing firmware, running tests, checking a signal, none of that should require physical presence. So the design goal for v1 was a single board that lives in the lab and that the whole team can reach remotely. The goal is also to not make it too expensive, so you can keep the board attached to every target.

Why RP2350B

The RP2350B is the 80-pin variant, chosen for the extra GPIO since this board has a lot to drive. It also has PIO, which can run protocol logic in dedicated state machines without tying up the main cores. That covers many peripheral mocking use cases without requiring anything more exotic. RP2350B will handle most of the digital stuff (I2C & SPI sensor simulation for example).

Why an FPGA

For everything PIO can't handle, faster protocols, the logic analyzer, analog input capture, there's an iCE40 on board. It's an inexpensive way to get real FPGA capability without the board cost getting out of hand. In v1, the FPGA is handling logic analysis and analog input.

Power control

Being able to turn the target board on and off remotely is more useful than it sounds. It means you can flash a new firmware version, power cycle the board, and watch the serial output without touching anything. That makes BenchPod a natural fit for a testing pipeline: flash, boot, test, repeat. You could also keep devices powered off until you need them, something that might be useful if you have lots of them.

WiFi and the ESP32

The decision to have a separate chip for WiFi rather than a combined solution was deliberate. Keeping connectivity separate from the main MCU means the RP2350B can focus entirely on the testing workload. The ESP32-C3-MINI-1 was the practical choice: it's pre-certified, JLCPCB can assemble it, it's inexpensive, and there's official AT firmware that handles WiFi over UART. A Pico 2 W would have worked too, but it costs more and doesn't have out-of-the-box AT. I might revisit this choice when adding Ethernet, though, or if I find a decent, inexpensive ESP32 alternative to use as a WiFi modem (the alternatives are quite expensive, so I settled on this).

On the analog side

The analog input is the most experimental part of this design. The current setup is basic, 8-bit, and limited bandwidth. The goal for v1 is to validate the signal path and the architecture. If that works, bumping up the resolution and speed is a straightforward next step. I've already started designing v2 analog input/output, and one of the differences is going to be supporting higher voltages, then scaling them down, so we keep the precision.

CAN

CAN support is on the board for when it's needed. The idea is to simulate devices on a CAN bus, which is useful for teams building anything that talks CAN. The details of how that gets exposed in the SDK are still to be worked out.

What v1 actually is

This is a bring-up board. The goal is to find out what works, what doesn't, and what needs a respin. It's not production-ready and isn't trying to be. The schematic and PCB were sent to JLCPCB last week and the boards are now in transit, with delivery expected soon. 

Board Layers

4 layers. Most important signals on the top, then 2 GND layers, then the signals that don't fit on top + power. After watching Rick Hartley's lecture explaining proper grounding, I ended up with 2 solid GND planes to ensure signal integrity for the analog part ([1] YouTube link at the bottom).

The KiCad files are in the GitHub repo. Here's a view of the PCB:

[1] Proper grounding: