Debugging Without an In-Circuit Emulator

Although we highly recommend the use of an ICE for embedded applications, there are times when, an ICE is not an option. This articles presents some techniques that may be useful when debugging without an ICE.

Simlulate the Embedded Environment on the Host

To the fullest extent possible, debug the code on the host. This may require some extra software to simulate I/O ports and the like, but it can save much time in the long run. Write the simulation code so that you can run and test the system just as you would on the target board. When you have debugged the code as much as possible, the code must then be loaded onto the target.

Loading Code onto the Target

At the most primitive level code may only be "loaded" by burning the software into EPROM and plugging the EPROM into the board. The system is then tested by powering up, and observing if the system does what it is supposed to. When using this approach we recommend that the code be burned into EPROM incrementally, and verified at each step. Where possible, light up LED's or the like to indicate status, and use switches (if the board has any) for "keyboard" input..

Another approach (assuming that the board has extra RAM and a link to the outside world like an RS-232 port) is to write a very small monitor that will allow for code downloading, memory inspection/modification, single stepping, and breakpoints. Once a successful monitor is developed, it resides in EPROM and all test software is downloaded.

Building a Simple Monitor

In order to build a monitor your embedded system must have a link to the outside world (usually RS-232) which is connected to a standard "dumb" terminal. The most primitive monitor should have at least the following features to be useful.

1. Basic command interface to accept commands.
2. Ability to accept code over a serial link and load it into memory.
3. Ability to display and modify memory and registers.
4. Ability to single step.
5. Ability to set at least 1 breakpoint.
6. Ability to start and to break out of execution.

Each of these is discussed in more detail below.

Command Interface

This code can be tested and debugged almost completely on the host. The commands should be simple single letter commands with zero or more arguments.

Downloading

The download code can be tested and debugged almost completely on the host also. Use a very simple download scheme, e.g., load in one large block. For example, word 0 contains the number of bytes to follow, word 1 contains the address at which to load, and the last byte is an XOR checksum.

Memory Commands

A simple command to display a memory byte is sufficient. When the value is displayed the user has the option of typing in a new value, or pressing carriage return to display the next byte of memory; the operation is stopped by typing a non-numeric character. A single command can be used to display all registers.

Single Stepping

Some processors have a bit in the status word that can be set to generate a software after each instruction, which makes the single step software much easier to implement. If the processor does not have this feature you must do the equivalent of setting a breakpoint at each successive instruction, which can be a chore because you must determine where the next instruction is, as this is dependent upon the number of operands and the type of the current instruction.

Breakpoints

A breakpoint is typically created by replacing the instruction at the breakpoint with a breakpoint instruction (sometimes a special type of software interrupt) or an illegal instruction. When the breakpoint instruction or illegal instruction is encountered, an interrupt occurs which vectors into an isr which restores the original instruction and invokes the debug command interface. When the user eventually types, for example, "C" for continue, the machine state is restored and program execution resumes.

Starting and Stopping

A command is required to start program execution, and a special key is required that will interrupt program execution and invoke the debugger command interface.

Debugging without a Monitor

If an RS-232 connection is available, debugging can still be done without a monitor by using printf's. However, increased flexibility can be obtained by using inline breakpoints.

Inline Breakpoints

An inline breakpoint is set by inserting the code "debug(x)" at various points in the code. "x" is the name of a global variable whose value (0 or 1) determines whether the debugger stops or not, which allows for selective enabling/disabling of breakpoints. The code for the function "debug" might look as follows.

void debug(int x)
{
	int cmd;

	if (x == 0) return;

	for (;;) {
		printf("\n > ");
		scanf("%d", &cmd);

		switch (cmd) {
        
	        /* Case statements for each command... */

		}
	}
}

The idea is to insert inline breakpoints at desired locations and change the value of the "x" by using a debug command to change the value of the relevant global variable. For example, suppose the breakpoint "debug(Global5)" is set at various places in the code. By using a debug command to set Global5 to 0 one can disable all breakpoints that use Global5 as their argument. Note also that in order to get into the debug function, at least one breakpoint must be set. Typically, during initial debugging, all inline breakpoints are enabled, and then selectively turned on/off as required.

Remarks

Debugging can be done without an ICE but an RS-232 connection is almost essential when an ICE is not present. Although the board resident monitor sounds good in principal, we recommend against it because it deals in machine code only and has no symbolic capability. To make the monitor really useful, much work is involved. On the other hand, the inline breakpoint technique requires minimal code and can be developed within a day or so. Therefore, in general, we recommend the inline breakpoint approach.

We welcome comments. Let us know what subjects you would like written up. Send comments to mike@Ticsrealtime.com