General debugging methods

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.

ICE

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).

ICD (PIC microcontroller)

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.

Simulation

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).

Advantages

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

Disadvantages

  • 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.

LCD

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.

Advantages

  • 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).

Disadvantages

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

LED

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 (unless you have a fancy logic analyser available!). 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.

Summary

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.

Extra Bits

Listening to Digital Signals

The buzz option on a multimeter is really useful because it tells you immediately when there is a short, without you having to read the resistance reading on the display.

The following circuits use a similar idea except that they don't check for shorts, but let you listen to digital signals in your circuit.

The main use for this circuit I have at the moment is to listen to the ICSP signal from MPLAB X when programming a chip. MPLAB X can take quite a while before it has re-built the code (C) and then started the programmer (software) and then gets around to do the actual programming (a different piece of software). All the while you are left staring at the screen waiting for the "programming complete" message to appear!

Then you can test the code out - probably finding that you left out a tiny action and therefore have to go through the whole process again!

This listener circuit lets you forget about MPLAB X so you can do another task such as examining the code you are writing or reading the datasheet etc. Since you can listen for the end of programming using this circuit it means you can save some time which is always a good thing.

Figure 1 shows use of a digital logic FET that has, as you would expect, a gate voltage that is sensitive to logic levels. For the 2N7000 Vgs is between 0.8V and 3.0V - if you need 3v3 logic the 2N7002 has Vgs from 1V to 2.5V but for typical values the typical Vgs for both parts is 2.1V

The 2N7000 is very useful as it does not draw current through the gate so it can be attached to any (logic) signal in your system. This is in contrast to the circuit shown in Figure 2 where a darlington pair is used - in this case a small current is drawn through the base via the 1k resistor

digital listener circuit 2N7000

The darlington pair (Figure 2) stops too much current being drawn through the base (as is the case when a single transistor is used) since the Beta (current gain) of each transistor multiplies the other. It is similar in operation to the FET except that its trigger voltage is ~1.4V.

digital listener circuit darlington

If you want to listen to different signals (perhaps they occur at different times) e.g. ISCP and serial output then Figure 3 shows how to use two diodes as a diode-OR gate.

digital listener circuit diode-or-gate

Note: you can use a piezo crystal (mine was attached to the case of an old watch which meant it should be louder - but it was still too quiet!)

Note: you can use any old NPN transistor eg, with Beta 100 or better.

Comments

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

Don’t see the comments box? Log in to your Facebook account, give Facebook consent, then return to this page and refresh it.




Privacy Policy | Contact | About Me

Site Map | Terms of Use