Become a subscriber (Free)

Join 29,000 other subscribers to receive subscriber sale discounts and other free resources.
Don't worry -- youre-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.

Privacy Policy | Contact | About Me

Site Map | Terms of Use

Visit our Facebook Page:

   Click Here

Recent Articles

  1. How to use the BMP280 Barometric Pressure chip with the Arduino

    How to use the BMP280 for weather pressure measurement or altitude change detection.

    Read more

  2. The TCS230 Color Sensing Chip: How it works and how to use it.

    How to use the TCS230 (/TCS3200) Color detector chip and easily add it to any of your projects.

    Read more

  3. All about the MC78M05BDTRKG Linear Voltage Regulator

    How to use MC78M05BDTRKG for maximum current without using too large a heatsink pad and how to select the optimum input voltage.

    Read more

  4. Fixed point: A fast and easy way to save tons of microcntroller flash memory

    How to use fixed point maths to save microcontroller memory by avoiding use of the floating point library.

    Read more

  5. How to use the DHT22 (or DHT11) with an Arduino; Full code, description and device differences.

    Essential Guide to the DHT22/11 humidity sensor with library code guide and Full Arduino Tutorial. Learn how to Easily determine Humidity, Dew point and Heat Index.

    Read more

  6. The Essential I2C Tutorial: All you need to know about I2C...

    I2C tutorial: Learn all about the 2 wire I2C serial protocol. Learn how easy it is to use, how it works and when to use it...

    Read more

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

Back to Top