# Developing a Hardware Test Plan for a Microcontroller - Past Experience

I am using this Microcontroller using 3.3V for power.

Using GPIO pins to drive some LEDs and send some ports for sending UART, LIN signals.

I'm using a 16MHz crystal.

Can someone tell me what the main parameters are that I should test in Hardware Testing of the microcontroller?

For example, suppose I have an I2C interface between the MCU and a slave. I would check the Vih, Voh levels, rise time, fall time, frequency, and period of the interface. I am asking along similar lines, what are the major test cases that one might overlook while validating the MCU section in testing?

Please help with your past experience working with Microcontrollers which you might have overlooked during testing and had some issues with it.

• Design validation test or production test? Feb 27 '20 at 3:34
• Design validation Feb 27 '20 at 3:41

## 3 Answers

3.3V for power.

• Line and Load regulation
• Tolerance of 3.3 V
• Ripple
• Output current - MCU and other peripherals

Using GPIO pins to drive some LEDs

• LED currents
• GPIO rise time and fall time
• Pulse width
• PWM Frequency
• $$\ V_{OH}\$$, $$\ V_{OL}\$$ of the GPIOs

and send some ports for sending UART,

• baud rate
• rise time, fall time
• ON time, OFF time
• $$\ V_{OH}\$$, $$\ V_{OL}\$$, for UART Tx Pin
• $$\ V_{IH}\$$, $$\ V_{IL}\$$ for Rx

LIN signals.

• Timing and voltage levels as per LIN protocol. similar to UART
• Tolerance and worst case bus voltages from external device
• Bus short condition and open condition

I'm using 16MHz crystal

• freq. measurement - Direct or via buffered divided output
• Voltage levels

If 12 V is from a battery (inputs from markus)

• Idle system current
• Sleep mode current
• Active mode current
• RF or Full Power ON Mode current
• Almost all the above tests at lower limit of the battery
• Stable temperature of the board (after running for 8 to 10 hours), especially the power section.

Power on.

• Reset single timing
• Clock stabilising timing
• Power supply timing
• IMHO, you should add: idle system power consumption, sleep mode power consumption, run-mode power consumption, run-mode temperatures, clock frequency validation (incl. internal 32khz OSC). If targeting mass-production one should do EMI testing, if a housing already exists do ESD testing. If battery-operated test the brown-out-detection. Feb 27 '20 at 10:03
• Thank you for the clear answer. Any major past experience issue you can share while using microcontrollers and these type of circuits? Feb 27 '20 at 12:12
• In addition, test if brown-out detection and watchdog work. The former is easy to do by just slowly lowering supply, the latter might need some project-specific modifications. Also, keeping the MCU running for a long time with a scope triggered on falling edge of reset line is a good idea (unless the product actually uses external resets). Feb 27 '20 at 13:26
• Thank you for the information Feb 28 '20 at 2:56

The scope of testing you take on for a pre-bought component focuses on looking for defects at the board level: opens, shorts, possible ESD damage. This would be done on every board. Typically this a combination of functional tests and some electrical parameter tests. How much you do of this depends on the expected defect rate of your components and the product as a whole.

You would also validate your system with voltage margin, thermal and shock+vibe testing to ensure that your board meets its intended environment spec.

Chip testing is a bit different: you apply test vectors to find faults in the internal logic. This is done when the part is manufactured.

• Thank you for the answer. Like, I am using this microcontroller in a board. I have performed the board bring-up. I have tested for open, short, voltage rail impedances and voltage levels. Just want to understand what are the basic tests that a person might miss out while testing the Microcontroller section of a board (having GPIOs, serial interfaces and other basic features). Like, from any of your past experience. Trying to learn, so that I can capture those test cases in my board Feb 27 '20 at 3:44

For design validation: scope the heck out of it. Perform detailed signal characterization on any critical signals. Clocks can be especially troublesome, but for a self-contained MCU, you probably won't have any really high frequency clocks.

Over-test for margin (without stressing anything too much). If your Vcc is +/- 10%, test at -15%. If your temperature range is 0 - 70 degC, test at -10 to 80 degC. If you don't have any margin, it is hard to be confident that the 10th unit won't fail at your normal range.

Testing a interface: try to increase the repetitions as much as possible. Automate the data flow in a loop. Example: send and verify a million messages overnight.

Try to crash it with crazy input. If you had a keyboard for input, a manager I knew would perform a lunch box test. He would set his lunch box on your keyboard, pressing most of the keys simultaneously, attempting to crash the system. Try to invent something similar for whatever I/O you have. Don't let someone else find a bug like this.

This is your reputation on the line, don't let it go to production until you are satisfied. I occasionally had managers that wanted to cut me off after the product appeared to be working, don't let this happen.

• Thank for for you answer Feb 27 '20 at 4:53
• Black box testing through lunch box testing :) Feb 27 '20 at 13:28