Can an embedded system be designed to support electrical manufacturing testing?

Question

Background
Desktop computers and laptops can be configure to dual boot. Example: Ubuntu and Window on the same computer/laptop.

Question: Can a similar concept be applied to embedded system? If so this can greatly benefit electrical manufacturing testing. Electrical manufacturing testing depends on high throughput. So booting a complete for example Embedded Linux system is not efficient and almost never done in electrical manufacturing test environment. So with some type of electronic switch/signal (may be provided by the tester) is possible to load very fast a minimalist set of software that already program to the processor that will enable testing of the board. For example verify the external crystal (XT) is correct and functioning.

Per @ouflak comment: I am aware of a particular NEC V850 micro-controller based application, where all micro-controllers were programmed using a gang programmer before been placed on the PCB board. During Electrical manufacturing test, the tester would force micro-controller to load very small program and communicate to the PCB board via the CAN bus to activate sections of the embedded system for testing purposes.

Similarly I would like to investigate how a beaglebone black like PCB running Android architecture/design can be modified to boot from a section of the flash for electrical manufacturing test only. There is no point loading and testing the graphic controller for TI Sitara as vendor TI as already done perform this function. All that is need is to test and verify the PCB manufacturing process.

---

Answer 1

I have done something similar with a small 8-bit microcontroller in a medical device. The factory had two pieces of firmware:

First, factory test firmware is downloaded. It has the algorithms for exercising the subassembly and talking to the factory test equipment. Factory test are performed.

Second, field firmware is downloaded. Field firmware has its own field self-test (smaller in scope, doesn't use factory test equipment). When the field self-test also passes, we conclude that the subassembly is good.

This allowed to remove the factory test code from the main firmware. That made the field firmware easier to develop: I didn't have to worry about a remote possibility that some test mode would jump at the end user. The memory footprint was also reduced.

Answer 2

What you ask is quite commonly done in various forms. For embedded microcontrollers, this usually takes one of two forms:

1. There are two separate firmware builds, one for manufacturing test and one for normal operation. The test process loads the first firmware into the device, does test, calibration, etc, then loads the second firmware into the device. This may include customizing some of the values in the production firmware based on calibration measurements taken in the first phase.

2. Add manufacturing test features to the production firmware. This is more common in my experience.

   Often the device needs to communicate to a host computer in some way. This usually means a command set is implemented. With this method, a few extra commands are added that are only used during manufacturing test. If the end user never sends command directly (use a canned app on the host, for example), then you generally don't publish the protocol and you can add whatever commands you want. If the user communicates with the device directly, then the last step in manufacturing might be to disable the additional commands or features. For example, I've used the trick a few times on serialized units where the extra features are only available when the serial number is the unprogrammed value of all 1s. The last step in manufacturing is to allocate a new serial number and program it into the device if the device meets all measured specs.

   The extra features don't have to be all firmware either, although you don't want to burden the production cost too much. In one case I implemented a command/response interface using the built-in UART, although the end unit is stand-alone with no communications interface. In this case, the UART signals were available via bare pads on the bottom of the board. Pogo pins on the test fixture connected to them and allowed access to the command set. End users know nothing about this feature and only see two round pads on the bottom of the board. In this case there are no security issues, so in the extremely unlikely case (hasn't happened as far that I know) a user monkeys around with it, they could end up "breaking" the device. Of course that's no different than monkeying around with any other parts of the board you're not supposed to connect to.

   In other cases, there are hidden secret ways to access "test mode". For example, the GPS unit in my car does strange things when certain buttons are held down during power up. I've created devices that required a certain unlikely button click sequence, usually within timing constraints.

Answer 3

It is doable, but depends on having enough storage space to contain both the full image and the small test image. There is often an initial program that runs, often referred to as the bootloader. The bootloader's job is to set up and launch the main application, and often to provide a recovery path for updating firmware.

It would not be hard, and is done in some products, for the bootloader to check an I/O and use that to select the image to load.

Here is a real-world example: On my cell phone the is an initial part called "fastboot" that checks for a button (volume down I think; can't recall at the moment) where either it will load the main Android system if nothing is pressed, or a recovery image if it is pressed. The recovery image starts very fast, but has limited functionality. It can access the filesystem and it wouldn't be stretch to put some diagnostic test options in there.

On other embedded systems, every byte of storage might count, and in those the designer has to weigh having diagnostics and recovery against fitting the required featureset at all.

Addendum: original answer had a comment asking for elaboration about detecting a button press or similar to select the image.

In many cases the bootloader is written in code similar to the rest of the system (often C or assembly). As such, it has the same level of access to the hardware that the normal software has. In many cases, the button or similar is a simple I/O line that can be read as a direct GPIO on the processor, or via a simple bus read to an external GPIO Expander (e.g. SPI or I2C bus), either of which wouldn't occupy much space in the bootloader's image.

For something that is explicitly designed for manufacture testing (as opposed to recovery or field testing) it would be less likely to be implemented on a user accessible button. A cheap but not easily accidentally tripped method would be a couple solder pads on the PCB that could be shorted together to invoke the test (ranging from using a simple screw driver to being implemented with a bed-of-nails style rig).