Using MCUs to unit test hardware.

[paulca]

Wondering if it's common in the professional world of MCU dev or hardware generally to use an MCU in a similar way to how you would integration test something in software.

Unitest/integration tests Ill deliberately conflate them for now.

I first did this when I wanted to learn SMD soldering a few years back.  I bought and soldered some Atmel EEPROMs and wondered "How do I know they work"?

So I wrote some Arduino code to erase, write, verify the chips.  One failed with a short under the chip, worked when fixed.

So I have tried to carry on doing this where possible.  Especially where there is SMD ICs.  Or even through hole, but for different reasons.

The largest "puppet" rig so far was a full 40 pin IC.  The Z80.  Including testing power cycling, reset timing etc.

If I flip that upside down I can stick pin headers into the Z80 socket and puppet the board with the MCU pretending to be  CPU or just spaming IO lines and reading the databus to test gates.

I can assume this runs out of legs as it's "slow".  It works in slow and static land, but if you introduce anything with timing or dynamic RAM it fails instantly.  In some cases for my puppet and test rigs I have to generate the clock from the puppet rig.  Not all chips will be happy with a chopping, stop/start clock.

In theory,  I suppose for your "big ICs" you could put out strategic test points.  Part populate the PCB, pogo-probe the test points and run the MCU test on the IC.  Not a "production techique" but a way to validate a prototype board matches expected functionality quickly.

The alternative is of course the end to end test.  Give it the input conditions, test the output conditions, if they match your done. Those can often hide many, many bugs though and produce little to no context in event of failure.

[Doctorandus_P]

I suggest you have a look at JTAG. It's widely known as a "programming protocol", but it can do much more. For example, it can daisy chain all I/O pins of multiple devices on a PCB, and then you can shift test vectors though these flipflops to test extra circuitry (for example simple logic gates, address decoders, TTL glue logic, etc)  that is in between the bigger IC's that support JTAG (for example uC, FPGA, advanced ADC).

For the rest, it seems quite logical to program a uC in the factory with a test program (For example during "bed of nails" production testing), and then reprogram the uC with the final application afterwards. But as long as there is enough Flash in the uC, it usually makes more sense to simply add the test code to the application, combined with some way (Uart, SPI, I2C, I2S, whatever is available) to communicate with the uC during testing.

Normally electronics is tested quite thoroughly during manufacturing, and in various ways (For example AOI, temperature cycling, burn in test). If a big part of the testing can be done by an on board uC, then a (networked) assembly can be made as an integral part of the testing. For example, a room with a few thousand phones, all connected to an USB "distribution network" (Regular USB only supports a few levels deep nesting). that collect test data during thermal or burn in tests.

Industrial electronics is probably tested more thoroughly then consumer electronics, but even consumers will be pissed if even a single sensor on their new phone is defective, and this can harm a companies reputation too. So everything is tested, from copper tracks on the bare PCB, to misplaced parts during SMT P&P and soldering errors. Testing is a whole specialized branch in the electronics industry. Adafruit has made a few video's about how they test their own production, and how they design their test jigs.

[peter-h]

In every product I've done since the Z80 days, I always wrote a pretty full factory test module. This gets done early on and then the code can be re-used for the normal product function.

[NorthGuy]

Yes of course. I used to do it with breadboards, now I make test boards with an MCU and few components on it. I can add lots of testpoints on them (which would be hard on the final board). Then I can test code, watch signals, noise, make sure that the hardware I use works as expected and meets requirements. This is very easy to do nowadays.