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.
There are many ways to debug hardware:
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.
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).
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.
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.
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.
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:
Note: To do testing you need an oscilloscope or a frequency counter and time interval measuring tool.
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.
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:
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.
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.
How to use the BMP280 for weather pressure measurement or altitude change detection.
How to use the TCS230 (/TCS3200) Color detector chip and easily add it to any of your projects.
How to use MC78M05BDTRKG for maximum current without using too large a heatsink pad and how to select the optimum input voltage.
How to use fixed point maths to save microcontroller memory by avoiding use of the floating point library.
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.
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...