Is it feasible to test microprocessor/microcontroller?

Question

What I can do if I want to test the microcontroller?

Answer 1

Generally in the embedded systems I design, I first try to add as much circuitry as needed to test out the overall system, in addition to the microcontroller itself, without adding extra cost (I might add an diagnostic LED for basic output at a cost of a few cents.) Usually this means using whatever leftover analog channels I have available to poke around the system and check that everything is okay, such as different power rails, etc.

Then I write a special manufacturing test firmware which is first loaded into the microcontroller after the board has been stuffed with parts, but before it is put into its final case. Obviously, if the programmer can't load the test firmware into the micro and run it, then you have a problem. But since most microcontrollers use only a couple of pins for programming, in addition to reset, power and ground, even if there is something else wrong on the board usually the micro can be fired up.

If the micro starts up, then one can run some simple tests, such as various RAM tests and a CRC across the code to make sure the RAM is okay and the program is flashed correctly. Although it would be possible to run a test of various instructions, I usually do not bother to do that.

I usually blink the LED once on starting up, and then perhaps twice after completing a series of basic tests. If the flashes are spaced a second apart, this gives a rough check that the timer circuitry is working. If there is a failure, I blink the LED in a specific pattern -- i.e. long flash, followed by 'n' short flashes indicating an error code.

I then try to check as many of the peripheral ports as possible. How you do this is of course dependent on the specific micro and your particular circuitry. You can usually test the I2C, SPI and other busses by simply accessing various peripherals on the board. An external UART can be tested by hooking it up to a PC with a terminal program. Testing the UART is usually a good test of the oscillator frequency, since the UART clock is usually tied to the system clock.

You can even write a program on the PC that interfaces to the micro via the UART to control the testing program, and log results.

I try to have a separate voltage reference in the circuit, that can be used to test against the other power rails. I like the 4.096 voltage references, since using a 12-bit ADC, one bit = 1mV. It can then be used to check other power rails. For voltages over 4.096, such as +5, you will need a voltage divider. If the device is battery driven, you will want to sink the voltage divider with an output port to avoid a constant battery drain.

Answer 2

Depends on what you are trying to achieve.

If serious.

Provide:

• Appartus that can set supply voltage to anywhere in legal range.

• Ability to control clock over whole useful range in modes you will use it in.

• Temperature controlled chamber across range.

• Ability to apply stimulii to I/O pins across legasl ranges.
  I/O loading resistance and capacitive.
  Rise/fall / hold times where relevant.
  ESD tests to meet allowed spec

• Any other physical or electrical parameter than can be varied within specified range that you care about.

Then:

Write test suite to exercise key functions on various combinations while varying all parameters with legal ranges in all combinations.

Realistically:

Set supply and temperature to worst case that you expect, load I/O to max expected. Run intelligent test programs.

Answer 3

If you want test your controller, the simplest way is to write a test program, like making some pins high and some low. Now let the processor run and test the pins using LED or Multimeters.

From my experience, the processor/controller is damaged only by short circuiting the pins or by some power supply problems

You may find some details here,

Answer 4

In a production setting you write and run a self-test on your controller. You either put the device in a jig with pogo pins, or you connect through the USB port (or some other port).

A jig is more effort, you basically build a test device with its own controller that tests your product. The advantage of using a jig is that you can measure signals that are not available to the mcu.