Debugging with Heartbeat LEDs

• Tutorials
• Debugging

In this article I’ll discuss one of the most basic debugging tools in an embedded system: the heartbeat LED.  Picture this: you’re developing your first program for a new microcontroller. You’ve written the code, configured the programmer, downloaded the HEX file and now... what Your program is running - isn’t it?

Truth is that it’s hard to tell with most embedded software.  Compared to desktop or even server applications embedded software tend not to have very many obvious outputs.  For example, if your final application is a motor controller your main output is the motor. Can you wait to start debugging your software until you can hook up a motor to your microcontroller to see if it moves?  For that matter do you know that the motor will even start moving if your software is working properly?  Even in that case the motor sitting still might be the expected behavior of the system.

You don’t want to have to write all of your embedded software, construct an elaborate test plan to force one of your outputs to change, run it and be forced to debug every aspect of your software at once.  Insteadyou could take a piecemeal approach and start by testing a feature that’s a lot more basic such as a heartbeat LED.

The purpose of a heartbeat LED is to let you know that your microcontroller is actually doing something.  The idea is that your code should blink an LED at a rate you as a person can see - 1Hz perhaps.  The code to blink the LED should be in your main loop or if you have an RTOS in your idle task.  As long as the heartbeat LED is blinking your main loop or idle task is running uninhibited.

There are a quite a few simple mistakes that can a heartbeat LED can help diagnose.  For one, maybe your programmer claims to have downloaded your code but just plain didn’t.  Maybe your watchdog timer is misconfigured and is continually resetting your microcontroller. Maybe you’re stuck in a forever loop somewhere in your code - that will definitely cause the heartbeat LED to stop blinking.  Or maybe it’s a more nefarious issue: perhaps your heartbeat LED is blinking much slower than it should - your clock settings are off.  Errors like these will continually crop up while developing embedded systems and a heartbeat LED can help you diagnose these and other mistakes quickly and easily.

Most development boards have at least one LED somewhere for you to blink. The Arduino Decimilia has one on Port B, Pin 5 for example.  I’m using a custom-made board that has one on Port D, Pin 7.  This link shows some basic code to blink an LED at 1Hz.

There’s a problem with this code though: it uses delay loops.  That means that the microcontroller will do nothing except turn the light on and off.  Whenever it’s not changing the state of the light it’s fruitlessly looping through NOP commands.  Most programs I’ve written have a bit more to do than nothing. You could place useful code after the command to turn the light on but this will break your timing.  Suppose your useful code takes 10ms to run: your LED will be off for 500ms and then on for 500ms of delay plus 10ms of useful code execution.  And ideally you’d have your microcontroller using as much of its processing power performing useful operations as possible.  This scheme doesn’t allow that at all.

 The alternative is to use a hardware timer to measure the 500ms period.  A hardware timer can keep track of time independently of the main processor.  Thus, useful code can run in the background and the timer will keep counting.  Whenever the 500ms period expires the main processor can quickly toggle the light and go back to its useful business. This code will blink the LED at 1Hz by using a timer/counter to generate the timing instead of delay loops.

A Heartbeat LED is one of the most basic strategies you can use when debugging an embedded system. This simple idea will save you time and frustration when you’re developing embedded code.  

Sign in