Microcontroller Failure Modes: Why They Happen and How to Prevent Them

Created: October 23, 2017
Updated: November 28, 2020

“Anything that can go wrong will go wrong” written on a whiteboard

I owe much of my design success to my college. Not because of the lab experiments where we learned what might accidentally blow up a capacitor, but because we learned that Murphy’s Law can strike when you least expect it to. Since I spent a lot of time playing Warcraft and struggling to finish up endless assignments, I relied on my computer to function at all times.

Back then, computers were pretty limited and it wasn’t uncommon to see the infamous Windows “Blue Screen Of Death” popup once in a while. While it’s frustrating to get interrupted from a game of Warcraft; losing hours of unsaved assignments to a system computer crash would send me into a massive panic attack. As a designer, you might have experienced a similar panic when your microcontroller causes failure in the field.

How Microcontroller Failure Mode Effects A System

In an embedded system, microcontroller failure mode (MCU) could have worse repercussions than missing your assignment’s deadline. MCUs are often the heart of applications like payment machines, medical devices, and security systems. These systems demand high stability and often have low tolerances for system failure rate.

A Microcontroller Unit that causes failure can cause a complete standstill in operations. This can inconvenience users or pose functional safety risks in critical applications. A safety mechanism is extremely important. For the clients, unreliable systems affect the operational capacity and potentially cause losses in revenue. For designers, having hundreds of their products constantly resulting in failure in the field is a huge blow to our pride, and can affect our reputation.

Businesspeople blaming frustrated colleague — *Pointing fingers doesn’t help a microcontroller that’s failed.*

Why A Microcontroller Fails And Who Should Be Responsible

A reliable embedded system requires a combined effort from the hardware designer and the firmware programmer. Some design faults can go undetected during the development phase and only rear their ugly heads once deployed. When this is the case, who should bear the larger portion of the responsibilities?

Before we start pointing fingers, let’s have a look at the reasons why you may have a failure mechanism.

1. Memory Stack Overflow

A microcontroller’s memory stack is a designated area of its internal RAM that is used meant for temporary usage. The size of a memory stack is limited and varies with different MCUs. When the firmware programmer allocates a variable greater than the stack size, a stack overflow may occur during the runtime and cause the firmware to cause a random hardware failure.

2. Illegal Pointers

In MCU firmware programming, a pointer is commonly used to indicate the address of a variable or program functions. Declaring and using pointers requires the firmware programmer to adhere to the strict syntax defined by the programming language, often in C. Introducing an illegal pointer by mistake can cause the MCU to attempt to process variables or functions in addresses that are outside its valid range. This could crash the MCU.

3. Unstable Voltage Source

Often an overlooked factor, an MCU needs stable power network to run reliably. MCU could fall into failure mode when its power source is constantly disrupted by external interference. A dip in the operating voltage could cause an MCU to behave erratically or freeze completely.

4. Electrical Interference

Failure to handle electrical interference, especially those induced from relays and motors could crash your MCU. During one of my earlier projects driving a simple DC motor, my MCU failed each time it tried to drive the motor in reverse. This problem was solved by increasing its electrical isolation using an operational amplifier.

5. Poor Assembly Processes

Occasionally, a microcontroller unit fail can have nothing to do with both the hardware or the firmware engineer. Low-quality solder joints on the MCU pins can result in unpredictable MCU behavior. If only a handful of your embedded systems are failing, you might start to investigate the process quality of your manufacturer.

Microchip production factory — *Your design is as good as your PCB assembler.*

Instead of playing the blame game, both hardware and firmware engineers must play their part in designing a reliable embedded system. Practicing good programming ethics and planning memory allocation beforehand are best practices to follow. For programmers, keeping things simple can be a wise choice for minimizing buggy codes.

Hardware designers need to consider the environment that the hardware will be used in and prepare for all possibilities. This means adhering to all the best basic design practices and fully utilizing your PCB software’s tools to test the design. When you need to access an easy-to-use PCB layout tool that includes everything needed to build high-quality manufacturable circuit boards, look no further than CircuitMaker. In addition to easy-to-use PCB design software, all CircuitMaker users have access to a personal workspace on the Altium 365 platform. You can upload and store your design data in the cloud, and you can easily view your projects via your web browser in a secure platform.

Start using CircuitMaker today and stay tuned for the new CircuitMaker Pro from Altium.