DEBUGGING TECHNIQUES

Introduction
Rule of Thumb: Write good, bug-free code from
start if you could
Testing/Debugging embedded software is more
difficult than application software
Post-shipment application problems are more
tolerable than embedded (real-time or life-critical)
software

Bugs/Errors

Main types
1.Syntax error

refers to a mistake in a statement's syntax.

A fatal error that the programmer must correct

before fully compiling the program.

Can be indicated by the compilers

2.Logic error
causes unexpected results or operation but not
failure.
Cannot be checked by the compilers, as the
program is syntactically valid.
Logic errors are usually the hardest to debug
3.Runtime error
A Runtime Error (Exception) is a problem that arise
when the program is executed.

DEBUGGING TECHNIQUES
1.
2.
3.

Testing on host machine

Instruction set simulators
Assert macro

1.Testing on host machine

Some reasons why you cant test (much, if any) on target

machine:
Test early (target may not ready or completely stable)
Exercise all code, including exceptions (real situations
may be difficult to exercise)
Develop reusable, repeatable test (difficult to do in target
environment, and likelihood of hitting the same bug is
low)
Store test results (target may not even have disk drive to
store results)

DEBUGGING TECHNIQUES

Basic Technique

Fig 10.1

Target system on the left: (hardware-indep code, hardware-dep

code, hw)
Test system (on host) on the right: (hardware-indep code same,
scaffold rest)
Scaffold provides (in software) all functionalities and calls to
hardware as in the hardware-dep and hardware components of the
target system more like a simulator for them!

2. Instruction Set Simulators

Using software to simulate:

The target microprocessor instruction set
The target memory (types - RAM)
The target microprocessor architecture (interconnections and
components)
Simulator does cross compilation of codes & places them in the
host system RAM
Uses linker & locator to port these codes & functions like the
code that runs on actual target machine.
Helps to develop the system before the final target system is ready

Capabilities of Simulators:

Collect statistics on instructions executed, bus cycles for estimating actual

times

Easier to test assembly code (for startup software and interrupt routines) in
simulator

Easier to test for portability since simulator takes same Map as the target

Other parts, e.g., timers and built-in peripherals, can be tested in the
corresponding simulated versions in the simulated microprocessor architecture
What simulators cant help:

Simulating and testing ASICs, sensors, actuators, specialized radios

Lacking I/O interfaces in simulator to support testing techniques discussed

(unless additional provision is made for I/O to support the scaffold; and scripts
to format and reformat files between the simulator, simulated memory, and the
scaffold)

3. The assert Macro

The assert is used (with a boolean-expression parameter)

to check assumptions
If the expression is TRUE nothing happens, if FALSE, a
message is printed and the program crashes
Assert works well in finding bugs early, when testing in
the host environment
On failure, assert causes a return to the host operating
systems (cant do on target, and cant print such message
on target may not have the display unit)

Assert macro that runs on the target are useful for spotting
problems:
1) disabling interrupts and spin in infinite loop
effectively stopping the system
2) turn on some pattern of LEDs or blinking device
3) write special code memory for logic analyzer to read
4) write location of the instruction that cause problem to
specific memory for logic analyzer to read
5) execute an illegal op or other to stop the system e.g.,
using in-circuit emulators

Thank you