2
\$\begingroup\$

I am designing a mixed-signal board with microcontroller that will need flash memory programming for its firmware, (self-)testing, and documentation for the final production steps.
I know there is a whole branch of the electronics manufacturing industry just around testing (ATE), but I have not yet found a simple list of steps and options for the basic process, just to get started and figure out the simplest, low cost way of automating this for a small scale.

Let's start with the essential flashing of the micro:

  1. Connect device to programmer (PC+Software)
  2. Click "program" button to flash firmware
  3. Disconnect device

How would one simplify this to minimal human involvement like

  1. Insert device
  2. Remove device

? Likely with

  • a test jig and spring-loaded probes (pogo-pins) for the connections.
  • a method for the computer to detect the device (switch, or retry until successful connection to MCU was established).
  • a human-machine interface (audio, visual via PC or on test jig)

The machine IO could be as "simple" as another microcontroller board (say Arduino) connected via serial port (UART/RS-232). Then the PC software might have to be customized to control the process (IO and Flasher software). Of course for flashing alone there are several options (vendor specific link, JTAG, bootloader).

Next of interest would be automated testing and calibration of the device. Of course, this is very specific to the hardware. The necessary equipment could be generalised as

  • power supply
  • signal generator (reference voltage / signal)
  • measuring device (multimeter, oscilloscope)
  • loads (sinks, sources)
  • interfaces

Instead of using self-test or IO routines on the hardware (separate testing firmware or test routines part of production firmware), low-level tests could be run by external control host via hardware Boundary scan / JTAG.

Depending on the circuit, this might be simplified to self-testing with a passive jig that mostly acts as a loopback device.

In any case, a general sequence for test/calibration might be:

  1. apply signal
  2. measure signal
  3. [calculate / store calibration parameters]

For instance, outputs could loop back to (multiple) inputs via the test jig. Analog signal calibration requires a reference that could be external. Signal switching might be required if using a reference with inputs (ADC) and outputs (DAC), e.g.

  1. apply external reference voltage to input
  2. calibrate input
  3. switch output to input
  4. self-calibrate output (adjust until output is same as reference)

Alternatively an external comparator could be used with the reference voltage for feedback (requiring an input and a routine to search for the correct output value). Of course, off-the-shelf test equipment with control interfaces are available and allow direct setting/measurement of analog signals to calculate calibration values.

Writing the calibration data to the device or attached memory requires corresponding data structures/addresses used by the firmware. The data could be written directly to memory where possible (flash memory limitations e.g. erase cycle, block size) or embedded into firmware/eeprom image before writing final production firmware. Alternatively, if the firmware has a calibration interface, this could be used to transfer/update these values after flashing once the device is running.

As for ID and documentation, if no hardware ID is present in the devices, one might be generated by the test environment and written to the device. Firmware and product information could be written to database and sent to label printer for physical ID on the device.

Of course, any solution is always a trade-off and can only be approached further based on the details of the test requirements.

I'd be interested in further ideas or pointers to accounts of implementations.


Also see:

\$\endgroup\$

closed as primarily opinion-based by Andy aka, RoyC, Voltage Spike, Dave Tweed Feb 14 '18 at 19:58

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

1
\$\begingroup\$

many free ARM programmers (ST-LINK utility, Jlink etc) have the automatic mode. I usually use ST-LINK utility + pogo pins. When the device is connected ST-LINK utility detects it, programs the flashes, sets the option bits (memory protection for example) and asks for the device disconnection - then waits for another one. Even doing it manually you can program 100-200 devices / hour.

Calibration is more difficult as you need to have

  1. Calibration utilities in your software - often with the signalling on the pin when the calibration is ready.

  2. Software on the PC side - usually I write my own programs for it. So it sets the calibration data and waits for the confirmation from the device, sets anothewr ones and so on. The signaling pin does not have to be dedicated - you just need it during the calibration. Only pad for the pogo pin is needed.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.