Vince Patron

PCBA Functional Tester using Raspberry Pi

Thu, 11 Sep 2025 21:29:33 -0500

Our PCBA production was ramping up to thousands of wireless sensor boards so we really needed a more automated way of testing and programming these boards.

Most test engineers would use a Windows PC, a bunch of DAQ (data acquisition) modules, power supplies, an interface circuit board and a separate pogo pin test fixture which all would take up a lab bench or test rack.

Instead, this tester design shrinks everything into the size of a shoe box.

A Tiny Read-Only Computer

A Raspberry Pi 3B+ running Linux was used. I configured the Pi’s root filesystem to be read only. This means the file system cannot be corrupted by improper shutdown. In fact there’s no OFF switch: you just pull the AC cord and put the tester away!

In this mode, the OS creates a file system in RAM (Overlay File System). Any files that are “written” are actually updated in RAM. On reboot, changes are lost and the system starts up completely fresh.

USB Hub, SWD Programmer and Test Instrumentation

The host PC connects to this with a single USB connection, to an on-board USB hub (Adafruit 5999). This tiny hub’s downstream connections are:

the DUT’s USB port
an ST-Link V2 SWD programmer
a thermal receipt printer
an MCP2221A USB-to-I2C/UART/GPIO/ADC/DAC converter, which controls:
- 128x32 pixel OLED display
- additional GPIO for reading DUT state
- load switches
- reading DUT analog voltages

The DUT has a Nordic MCU. Instead of a $300 J-Link JTAG programmer, I used a $5 ST-Micro ST-Link V2 programmer thanks to the open-source OpenOCD project. I added external ESD diodes to make the bare SWD pins more robust.

DAQ in a Chip

The Microchip MCP2221A is really a neat chip. It does USB 2.0 to a host and gives you I2C, ADC, DAC, UART and GPIO interfaces. So it’s basically a DAQ but in SOIC package. Add some decoupling caps and your ready to do data acquisition and control the world!

Of course for the size and price, the interface blocks are low performance (10-bit ADC, 5-bit DAC) but it’s perfect for functional testing.

Probe Board and Tester Board in One

The tester board is also the probe board. This keeps the system compact and simple. The circuitry has to be carefully placed in the spare areas between pogo/spring pins.

Test Software

The test software I wrote in Python using off-the-shelf libraries for the MCP2221A IO chip, Bluetooth scan function and ESC/POS printer.

The DUT is programmed with a special test firmware to put it into special test modes during testing. If the test passes, the DUT is reprogrammed with the production firmware.

Instructional Video

Here’s a short on how easy this tester is to use for assembly technicians.

Your browser does not support the video tag.

Firmware Programmer using a Raspberry Pi

Sat, 31 Aug 2024 07:01:35 -0500

Work needed a low-cost way to program all the different firmware for various products. They ranged from nRF52 BLE beacons, LTE modems, and ESP32-based sensors.

They also needed to:

Pick up the MAC address of each BLE sensor via Bluetooth scan and print a tiny label with a QR code.
Scan the barcode of a SIM card and print a QR code.

I figured it a factory setting it was easier to have a small footprint, limited feature programmer box than to have a bunch of laptops.

System Components

Raspberry Pi
20x4 character LCD with I2C backpack (Amazon)
4-button board (AliExpress)
Barcode scanner module (AliExpress)

The code was written in Python. I made a menu system that picked the function to perform.

The I2C backpack on the LCD makes it much easier to connect, needing only 4 wires to the Pi. It uses an I2C GPIO expander to control the parallel interface of the character LCD.

Text LCD with I2C board, 4-button board, Raspberry Pi in the box

I made 8 or 10 of these programmers and we deployed thousands of devices into the field that year before we outgrew this system.

Enclosure

A 3D printed enclosure can be easily mass produced instead of modifying an off-the-shelf enclosure one by one. We did not have a CNC mill at the time, anyway.

So this was the perfect excuse to build up my 3D modeling skills. OpenSCAD is free and easy to use once you get used to it. It works well if you like writing code and your device does not have complicated curves.

Enclosure in OpenSCAD

Software

I wrote the software in Python with help from libraries that supported the label printer and the Bluetooth scanning.

The menuing system was from scratch. The menu was defined as a large tuple in a JSON-like format and Python logic that went through the menu items as the buttons were pressed.

Label Printer

The label printing function prints the MAC address of a sensor it found over Bluetooth, or a SIM card scanned by the barcode scanner.

Ethernet Dropout Challenging Debug

Wed, 18 Jan 2023 06:31:43 -0600

I got a call one day that some new floor scrubbing robots being trialed in the field would get stuck for 15 or 20 seconds even after an obstruction was cleared.

These new robots were outfitted with a camera tower so they could scan grocery store shelves as they autonomously scrubbed the floor of the store. The SW team said they could see the Ethernet connection disconnect between the main computer and the camera computer.

A sporadic event

The Ethernet drops were hard to replicate as it only happened several times a day at seeming random times.

I was finally able to find a robot that had a lot of dropouts and had that moved to the lab. I set it up with an oscilloscope with a differential probe watching the Ethernet signal and tried many things to see if I could get the Ethernet to disconnect.

Finally reproduced the issue

I finally did it. Here’s what I saw. Here’s a normal scope plot (Tektronix heatmap enabled):

Normal Ethernet 10/100 signal

But when the emergency stop was released, there were sudden bad incursions into the eye diagram, just extreme noise.

Sudden Noise on Ethernet 10/100 signal

And then the two computers stopped talking to each, leaving only the sync signal. It’s like the communication got so garbled that they just disconnected from each other.

Disconnected Ethernet 10/100 signal

After some time puzzling over the schematics of the two computer systems I spotted a tiny mistake, so easy to miss.

The connection between the two computers can be simplified to the schematic below. Can you spot the problem?

Simplifed connection diagram between Main MCU and Camera MCU

It’s so small most engineers would probably miss it. In fact, each computer would likely pass all testing of their ethernet ports.

So here’s the problem: the Main CPU’s ethernet transformer’s center-tap is grounded to electrical ground, but the Camera CPU has its ethernet transformer grounded to chassis ground (the correct way). See the different ground symbols in the schematic above?

This would cause common-mode noise to get coupled into the Main MCU’s electrical ground instead of being shunted harmlessly into the machine’s chassis ground. And it turns out coming out of emergency stop causes a huge noise spike in the machine because the motor controller closes a relay and applies 1,500 uF of capacitance to the battery! (More of that in another post…)

So this problem only happens when:

the two systems are connected together, and
there is a very large electrical noise event

A field workaround

A big problem with updating the Main MCU board was that we already had thousands of machines deployed in the field. Reworking thousands of units was out of the question.

I had an idea to use an isolation cable to galvanically isolate the two sides of the Ethernet connection and basically isolate the main MCU externally.

To quickly test this theory, I wired up a cable that had an extra Ethernet transformer in the middle. The idea was that this cable can be installed only on the few problematic machines in the field.

Proving the issue with a cable solution

And it worked! The cable provided isolation between the two systems and robots that previously had Ethernet dropouts no longer had the issue.

While off-the-shelf isolators were readily available, they mostly had RJ-45 connectors. The cabling we used had metal industrial locking connectors. This simple PC board let us cut an existing cable in half, solder the board in, and heatshrink the whole thing and send them off for installation.

The problem is still out there

The problem will probably continue to persist because a few designs will ground Ethernet incorrectly.

Here’s part of a schematic for an evaluation board from a major IC manufacturer that makes the same mistake. Granted the board is to demonstrate a PoE DC/DC converter, but an engineer might see this schematic and follow the same grounding mistakenly.

Example from an evaluation board from a major IC manufacturer

Engineers reading this will hopefully learn from this example and do it right. This was a great example of debugging that truly got down to root cause.

Sparky Battery Emulator

Thu, 23 Jan 2014 06:38:51 -0600

The Need

In 2014, I was with the team writing the PMIC drivers for a mobile phone. The developers were complaining that it was very tedious to test the phone’s charging and discharging because a full charge/discharge cycle took so long. Worse, there were several times that driver code was released only to find that charging was broken during field testing.

The developers had the phones hooked up to bench power supplies, but “charging” a power supply would just cause the voltage to jump up and the phone indicate that the battery was 100% charged.

There were also corner cases to be simulated that needed firmware to adjust the charging. For example, if the battery was too cold, the phone must charge at half the normal rate, or not at all if it was very cold, or if the battery was between 2.5 V and 3.1 V it must trickle charge it up 3.1 V before fast charging. But a battery below 2.5 V is already damaged and must not be charged at all for safety reasons.

The Solution: Emulate the Battery

Sparky Mobile Phone Battery Emulator

I knew this required a two-quadrant power supply that not only sources a voltage and outputs current but can also sink current and force a voltage level when an external source (a mobile phone) tries to “charge” it.

A Two-Quandrant Buck Regulator

After reviewing many possible designs (power op-amp, op-amp with a class-AB output stage, buck regulator with a tracking current sink, etc), I found Linear Tech (now Analog) offered a complete module (LTM8052) which even had the inductor built in. This was the heart of “Sparky”, a complete battery emulator for mobile phones.

Sparky Battery Emulator circuitry

I paired the LTM8052 two-quadrant buck regulator with a PIC MCU to give it a USB interface and intelligence. I wrote the firmware in C using Microchip’s MPLAB IDE and HAL drivers.

When sinking current, the LTM8052 forces the output to the programmed voltage and sinks current by dumping it back into its input.

On the input side you would normally add a zener diode to sink the charging current. Instead, I used a MOSFET in a voltage follower configuration to emulate a zener diode. A MOSFET is so much easier to bolt to a heatsink. Quite a bit of heat had to be dissipated during phone charging.

Battery Emulation Features

Charging and discharging
- the voltage slowly rises and falls as it’s charged and discharged just like the original battery
- uses a Voltage vs. SoC (state of charge) lookup table derived from characterized parameters of the original battery
Emulates battery ESR (effective series resistance)
- output voltage dips and rises depending on charge/discharge current due to emulated series resistance
- programmable ESR value including open cell condition
- can adjust ESR based on SoC and temperature lookup tables (future FW feature)
Emulates battery thermistor
- programmable digital potentiometer to set any sensor temperature
- also emulates short and open thermistor
Interface
- Text LCD display shows real time voltage, current, emulated state-of-charge, and emulated temperature
- Buttons for live settings changes
- USB interface for control and data logging

Because of these features, to the mobile, the emulator looked and acted like the original battery. To the developer, he can now simulate any battery condition and verify that the PMIC and firmware works correctly in all corner conditions and fault cases..

In Actual Use

There were two use cases for Sparky. The obvious one was on each firmware and software developers desk if they were working on anything related to charging, discharging and gauging the state of charge of mobile phones.

The second use case was in automated Regression Testing. The company had banks of phones of every model that ran automated testing. Every firmware release candidate had to first pass this rigorous automated regression testing before going to human testers.

Regression Tester Rack with Sparky Battery Emulator

With Sparky added to the testing bank, phone charging became part of this automated testing. There were no more software releases with broken charging or gauging after that.

PMIC Eval Board with GUI

Mon, 11 Jun 2012 19:29:03 -0500

In 2012, I was a PMIC Applications Engineer at a large fabless semiconductor company. I lead my colleague and I to develop a PMIC evaluation board complete with an extensive interative GUI.

The PMIC itself was very complicated and had so many functions. It had USB charging, many buck regulators, many linear regulators, LED drivers, ADC inputs, GPIO pins, a keyboard matrix scanner and a Battery Management System (fuel gauge).

Plus, the regulator voltages, configuration and logic, everything was register programmable; it had no external programming resistors or dividers.

An Eval Board To Understand and Test the PMIC

As a Senior Applications Engineer, I was tasked to write the customer-facing datasheet for this massive chip. It was really tricky to figure out how all the functions worked, what bits controlled what, and how all these functions interacted just from talking to IC designers and reading design docs (many were preliminary).

So I had the idea to make a very extensive evaluation system for it, including a GUI to control and demonstrate all the features and functions on the chip. This helped me write the datasheet because I could test what I was writing immediately on the eval board.

But everyone also wanted a board. Applications Engineers could emulate customers setup and help them debug issues, both internal and external firmware engineers writing code could try various register settings interactively. And all you needed was a PC and power supply.

Quite a number of these eval boards were made and sent to various departments as well as to key external customers.

My first extensive GUI app

GUI and event driven programming were new to me at the time. An engineer from a different department gave me a Visual Basic book (circa 2012) and I learned how to use Visual Basic on Windows and write using event-driven code instead of procedural programming.

I was proud of this GUI. I took the event-driven feature to heart so not only did it allow you to control every feature interactively but it also showed real-time readings. Every status bit, the voltage of every regulator, battery and charger and the frequency of every clock output were all updated in real-time on the GUI.

Microchip Microcontroller

Between the PC and eval board, I made a custom USB interface using a PIC Microcontroller. I used MPLAB and wrote in C using the Microchip’s HAL.

Xilinx and Verilog

The PMIC was controlled using the company’s proprietary serial bus. The challenge was that this ran at 9.6 Mbps, way too fast to bit-bang with a low-cost microcontroller of the era.

This was probably the biggest technical hurdle. Discrete logic would have been a horrible and brittle design. I settled on using a Xilinx CPLD because it was simpler (non-volatile) and a full FPGA was not needed. I ran though Xilinx tutorials and test projects and taught myself Verilog. (I later took an official FPGA class at the university extension and got an A.)

I came up with a simple design where the MCU could serially load a buffer, a string of shift registers, at its leisure. Once the correct number of bits were in, it sent the packet to the PMIC at 9.6 Mbps.

Along the way, if the packet was a read, it picked up the serial data from the PMIC and stored it into a string of shift registers.

The MCU could then serially read the data from the PMIC at its leisure.

A Useful Block

The MCU and CPLD portion of this design turned out to be a boon for another team who needed a simple way to control their RF chip with the same proprietary serial bus protocol. They incorporated it into their own RFIC eval board.