Production test firmware is a separate firmware build loaded during manufacturing whose only job is to exercise and verify every hardware function on the board in a short, deterministic sequence. It is not the product firmware. Application firmware is written to run a product, not to prove a board is good, which is why boards loaded only with application firmware ship with untested hardware. 

Application firmware hides hardware faults, it does not find them 

Consider what your product firmware actually does on power-up. It initialises the peripherals it needs, connects to the network, and waits for input. If a relay driver is marginal, it will not know. If one of four ADC channels reads twelve percent low, it will report a number and carry on. If the second SPI flash is unpopulated, it may not be touched for weeks. 

A production operator loading application firmware sees a board that boots and a status LED that turns green. That is not a test. That is a boot. 

The functions that fail most often in manufacturing are precisely the ones application firmware exercises last or rarely. Connector continuity. Relay contacts. Buzzer and speaker paths. Display segments. RTC and its backup cell. Antenna and RF path. Current sense channels. External memory. Each of these needs to be driven deliberately, measured, and recorded.

What a good test firmware does 

Think of it the way phone manufacturers do. Every phone has a hidden self-diagnostic mode that runs display, touch, buttons, camera, sensors, speaker, microphone and radios through a scripted sequence with pass or fail per item. That is exactly the model to copy for your own hardware. 

A well-built production test firmware should: 

1. Enumerate and identify itself. Report the hardware variant it thinks it is on, its own test firmware version, and any board ID it can read. 
2. Test every peripheral independently. One test per function, each with a defined pass window, not a single go/no-go. 
3. Measure, not just detect. A test that reports "3.28 V" is worth ten times more than one that reports "PASS", because borderline readings are the early warning of a batch-level problem. 
4. Run fast. Target under 60 to 120 seconds for the full sequence. Anything longer gets skipped when the line is behind schedule. 
5. Be deterministic. No network dependency, no cloud calls, no timing races. The same board must produce the same result on every station. 
6. Log everything in a machine-readable format. Structured output over UART or USB, one line per test, with values, limits and verdicts. 
7. Write results and identity to the board. Serial number, MAC, provisioning keys and test pass flag written to non-volatile memory so the unit carries its own proof. 

The measurements are the point 

The single biggest missed opportunity in production testing is treating results as pass or fail and throwing away the numbers. 

If your test firmware records the actual measured value for every check, you get things that no pass or fail flag can give you. You can see a rail drifting across a reel of regulators. You can see the fourth station consistently reading lower than the other three, which is a fixture problem, not a board problem. You can see that the fifty boards that failed in the field all sat in the top five percent of a current measurement at production. 

That last one is the difference between a root cause and a guess. Borderline units that passed are the most valuable data in your factory, and they only exist if you logged the number. 

Test firmware and application firmware are different builds with different rules 

Keep them separate, and manage both as releases. 

Test firmware can and should do things application firmware must never do: drive outputs directly, bypass safety interlocks under controlled conditions, dump raw register values, expose a command shell. That is fine on a test bench and dangerous in the field, which is why the last step of the production flow must be a verified overwrite of test firmware with the released application firmware, and a record that the overwrite happened. 

Both builds need version control, both need to be released rather than passed around as files, and both need to be allocated to a specific variant and production lot. A test firmware that does not match the variant on the line will either fail good boards or pass bad ones. 

Where this fits in the production flow 

Test firmware sits after the power-up test and before mechanical assembly. 

Visual inspection, then cold test for impedance against a golden sample, then a current-limited power-up test, then test firmware load and full functional test. Only after the functional test passes does the board move to mechanical assembly, final assembly, QC and dispatch. The test firmware step is where the board stops being an assembly and starts being a verified unit.

How S3Suite handles test firmware 

• Test firmware is a managed release. It lives in the Engineering Suite alongside application firmware, with its own version history, and it is allocated to a specific variant and production load rather than emailed to the factory. 
• Station Kiosk runs the sequence. Each operator station loads the correct test firmware for the variant being built, and the operator selects the test they are running. 
• Logs are captured, not discarded. The S3 Hardware Agent collects structured serial output from the board and pushes it into the unit's record, so measured values are stored against the serial number. 
• Results attach to the device permanently. When that unit appears later in an RMA, its original production measurements are on the same screen as its field failure. 
• Automated test jigs can push results by API. If you are running jigs rather than manual stations, the jig posts test reports directly against each serial number. 
  

If you build volume hardware and have no test firmware 

Start with the five functions most likely to fail and most expensive to catch later. For most connected products that is: power rails under load, external memory, the radio or cellular path, the primary output stage such as relays or drivers, and the user interface. Write a firmware build that exercises those five, prints values with limits, and takes under a minute. Ship that to the line next build. 

You will find defects in the first lot. Every team does. 

FAQ 

What is production test firmware? 

A dedicated firmware build used only during manufacturing to exercise and measure every hardware function on the board in a short scripted sequence, producing structured pass or fail results with measured values per test. 

Why not just use the product firmware to test the board? 

Application firmware is written to run the product, not to prove the hardware. It exercises only what it needs, hides marginal behaviour, and produces no structured test record, so faulty boards pass simply by booting. 

How long should a production test take? 

Aim for 60 to 120 seconds for full functional coverage. Longer sequences get skipped or shortened by operators under line pressure, which defeats the purpose. 

Should test firmware be removed before shipping? 

Yes. The final step should overwrite test firmware with the released application firmware and record that the overwrite completed, because test builds typically expose unsafe direct control of outputs. 

Do we need automated test jigs to use test firmware? 

No. Test firmware works with a manual station and a serial terminal. Jigs add speed, repeatability and removal of operator error, but the firmware itself delivers most of the quality benefit on its own. 

CTA: RND Square builds production test firmware and test jigs for hardware teams entering volume. [Talk to us about your production test plan] 

Internal links: /insights/electronics-production-test-sequence, /insights/automated-test-jigs-electronics-production, /insights/testing-firmware-with-ai, /s3suite