Become a subscriber (Free)

Join 29,000 other subscribers to receive subscriber sale discounts and other free resources.
Don't worry -- your e-mail address is totally secure. I promise to use it only to send you MicroZine.

Methods for debugging microcontroller hardware.

Most of these debugging techniques can be applied to any microcontroller since they do not use any specific tools. These methods are at the metal level i.e. lowest hardware level and you can make use of them when you do not have access to expensive logic analysers or In-Circuit-Emulators. Even though they are simple they are still very effective.

General debugging methods

There are many ways to debug hardware:

  • ICE.
  • ICD.
  • Simulation.
  • Serial RS232.
  • LCD.
  • LED.
  • Hardware pins.
  • Logic Analyzer.


The In Circuit Emulator is the most expensive way to debug your hardware. You buy a special processor that physically takes the place of the normal processor. This special processor allows software access to the internal operation of the processor (you can set breakpoints on hardware modules).


The next best thing to ICE is ICD (In Circuit Debug) Sometimes known as (BDM - Background Debug Mode). It lets you single step through code actually running in the target processor.

For ICD the processor has a small amount of built in hardware that can halt the processor when the program reaches a specific address. The software can then read back all the registers and processor state. Since all processors that support ICD have the ICD hardware built in, the only extra cost is the ICD communication hardware (between the PC and the processor/microcontroller).

If you don't have an ICE or ICD then you have several choices for getting debug data out of the microcontroller. These are RS232, an LCD or a port pin.

Simulation is also a useful debugging method before you even start debugging the hardware.


You can simulate code at the assembler level but it is much easier for debugging if you use a source level simulator built into a compiler environment.

With a built in simulator you can step through the high level language code and see its effect on memory and variables without having to look at the assembler code directly. This lets you focus on the high level language operation and lets you concentrate on the problem you are trying to solve.

One great advantage of the simulator is that you do not have to wait to download and program the target processor (you do have to re-compile the code after changing its source code though). So you can cut out the time consuming programming task just by using the simulator.

Using the simulator lets you quickly see the effect of changes and view the internal operation of your code. You can step through the code and set breakpoints (where the simulator must stop and wait) at any point in the code. When you are satisfied with the operation of the code you can try it on the hardware knowing that the code is more likely to work.

Some simulators show you how long the code is taking - showing you clock cycles taken by high level statements and some provide a stopwatch facility. This can be reset at any point in the code and lets you see, accurately, how long code is taking - useful for time critical code.

Note: Simulators are no good for debugging interrupts.

Debugging using hardware

Serial RS232

Newer microcontrollers have a built in UART giving you a virtually free debug tool that uses minimal resources and needs very little software coding.

For debug output you need to connect the UART output pin (TX) to a suitable level translator circuit e.g. a MAX232 chip. You may even get away with direct connection (via a resistor) to the input of your PC serial port (but this depends on the specifics of your PC hardware) - using a translator chip will always work.

Note : If you don't want to put a level translator chip on your board then you can put one on an external board (between the PC and the production board). This works fine as long as the TTL leads from the microcontroller to the level translator chip are kept short (~15cm).


  • Minimal coding.
  • Simple to use.
  • Minimal extra hardware.


  • Takes a long time to output a character (~1ms).
  • Takes even longer for blocks of characters (~10s of ms).
  • Needs extra hardware.

Even through it takes time to output a character it is a useful debug tool as you can output the value of a variable to see what the microcontroller is really doing.


An LCD (Liquid Crystal Display) gives a convenient way of displaying debugging information. It is also useful for many different applications that need a text display output.

It is a module that displays text characters and a common screen size is 2 rows of 16 characters.

Most LCD modules use the HD44780 controller chip which is why LCD routines built into high level languages always work.


  • Very quick update (40us 4 bit data bus).
  • Useful in many projects as the main display interface.
  • Simple to interface to an 8 bit port (only needs six of the 8 bits).


  • Uses up an 8 bit port.
  • Hardware is more expensive (e.g. compared to a serial port chip).


Using an LED as a microcontroller 'alive' indicator.

Even though it is such a simple thing to blink an LED on and off it is extremely useful as a debugging tool as you can tell at a glance whether the code you just downloaded is working.

Sometimes you can will incorrectly set parameters on the programming software or compiler which will stop the code dead.

The LED indicator gives a quick health check for your microcontroller which is easy to see.

Pin Debugging

This is the simplest and crudest debugging method; using any available port pin. Simply set or reset this pin at any point in the code that you want to monitor.

It has minimal impact on the code speed or size and can give you the following information:

  • You can tell if the code is active.
  • It gives you the repetition rate.
  • It gives you the routine time length (if you set the pin at the start and reset it at the end).

Note: To do testing you need an oscilloscope or a frequency counter and time interval measuring tool.

Debugging interrupts

First of all do not use RS232 to generate debug data from within an interrupt. RS232 is simply too slow and interrupt routines must usually be fast so that they let the rest of the program do its job. If you use RS232 it will cause slow down the ISR (Interrupt Service Routine) which can affect how the rest of the program operates - it may even crash.

On a project that I worked on a software engineer (who was used to working on PC software) used RS232 output in the ISR. The ISR was a high speed transmission system - the system would randomly fail. To a software engineer this immediately indicated a loose wire (or equivalent). This was reinforced as months of design and testing had been done in a PC environment. The software progressed and could not possibly be wrong!

Of course the blame game starts - software blames hardware & hardware blames software. The logic analyzer is brought out, simpler code written and a period of analysis ensues.

To avoid all this it is best for the hardware designer to write simple code to exercise the hardware at the lowest level. All you need is to make code repeat a task e.g. writing to a data latch so that you can see the signal quality on an oscilloscope.

What is the best way to debug an ISR

The best way is to use a spare pin on the microcontroller. You set this pin at the start of the ISR and clear it at the end. You observe the pin using an oscilloscope. This gives you lots of information:

  • It indicates that the interrupt has been called.
  • It gives you the interrupt repetition rate.
  • It gives you the interrupt routine time length.

So using a single output pin for debug gives the fastest method which has the least effect on code. You could use more pins to show different information.

Note: You could use a pin connected to an LED if there are no other spare pins available.

Even if you only have a logic probe to view the pin this debug method still gives useful information i.e. it shows that the interrupt is active.

Logic Analyzer

This tool attaches to the pins you want to observe and captures the waveforms displaying multiple traces on a single display. It uses a trigger module that can be set to activate on combinations of the input signals or on their length. So you can trigger on specific patterns or on glitches or both.

For non-microcontroller based systems (e.g. 80486 based) where the data and address bus are exposed a logic analyzer can show the address and data organized into hex words i.e. readable. Some can disassemble the instructions showing what the processor was doing at the trigger point.

For a microcontroller based system the logic analyzer can be useful in examining peripheral operation e.g. for debugging the SPI or IIC busses some logic analyzers also have built in support for these protocols.

Another use for the logic analyzer is to capture output over a long period of time depending on the memory capacity of the logic analyzer. This is useful if you have a very difficult problem that only occasionally appears - you can set a trigger point on execution of a spcific sequence of code or a specific set of transistions on signal lines.


In short there are many techniques to debug your hardware ranging from simple (an output pin) to complex (a logic analyzer). All of them can be useful depending on the problem you want to solve.

New! Comments

Have your say about what you just read! Leave me a comment in the box below.

Claim Your: Useful

"Arduino Software Guide"

   Right Now...

Privacy Policy | Contact | About Me

Site Map | Terms of Use

Visit our Facebook Page:

   Click Here

Sign up for MicroZine
''The'' Microcontroller Newsletter

Enter your first Name and primary email address in the form below:

And receive absolutely FREE a full project for:

"Measuring Analogue Voltages
Without An ADC"

(Using only one pin).

Instant Download:
You Can
Get It Right Now

Warning: This project could be  Removed 
at any time.  

It will  NOT be 
available indefinitely SO
To avoid 
disappointment  get it:


Don't worry -- your e-mail address is totally secure. I promise to use it only to send you MicroZine
Remember this is a project with full description and fully debugged C Source code - and it's not available from the main website.

You can only get it through this newsletter.

To get exclusive access Enter your first name Name and primary email address Now in the form above.:

But wait !

There's more...

You'll receive more
free and exclusive reports as well as site information and site product updates

Scroll up to the form above and sign up NOW. Don't forget it's FREE and if you don't like it, you can unsubscribe at any time.

Click Here Now to use the form above to get your Valuable information absolutely free.

Readers Comments

"I wanted to thank
you so so so much
for all the information
you have provided in
your site it's


- Ranish Pottath

"This site really is
the best and my favorite.
I find here many useful
projects and tips."

- Milan


"Awesome site,
very, very easy and nice
to navigate!"

- Matt

Learn Microcontrollers

"Interested in

Sign up for The
Free 7 day guide:


"I am a newbie to PIC
and I wanted to say
 how great your
site has been for me."

- Dave


"Your site is a great
and perfect work.

- Suresh


"I couldn't find the correct
words to define
yourweb site.

Very useful, uncovered,
honest and clear.

Thanks so much for
your time and works.

- Anon

Recent Articles

  1. Eye Tracking System

    Eye tracking : How to detect the gaze of your eye and track where you are looking.

    Read more

  2. DS18B20: How to use it on the Arduino Uno.

    How to Easily Use the DS18B20 Maxim One-Wire thermometer with Arduino example code using both external powered and parasitic powered devices.

    Read more

  3. The best Microcontroller projects and resources.

    Do you want to learn how to use a microcontroller in your electronic projects or do you need inspiration for your next project? If so you have found the right place!

    Read more