12 DEBUGGING NOTES

This chapter contains the following sections:

Debugging Assembly Language

Debugging Multiple Programs

Debugging with Interrupts Enabled
Detailed Description

Here are a few notes about debugging in special situations:

12.1 Debugging Assembly Language

You may debug assembly language programs or modules much as you do C source. The s, S and si commands single step through the assembly source. You may place code breakpoints on assembly language instructions with the bi command.

For additional information on debugging assembly code, see $autosrc, $mixedasm and $symbols in the Reserved Special Variables table in section 3.4.

There is a restriction on debugging assembly language code:

12.2 Debugging Multiple Programs

You probably have only one linked and located absolute object file that describes the whole system load. However, for various reasons, you may want to build your system load by linking and locating into several files. The debugger can handle the symbols from only one load module in one absolute object file at a time. Consequently, if there are several absolute files or several load modules within one absolute file, you will have to change the context from one to another explicitly. Use the N command or the Load Symbolic Debug Info dialog to load the appropriate symbols. This does not disturb the state of the target system.

You can also download the image part of another absolute object file (using the dn command), without leaving the debugger.

12.3 Debugging with Interrupts Enabled

When debugging an application where interrupts occur frequently, single-stepping is very difficult because the debugger steps into the interrupt routine rather than following the current execution path. The reason is that during the idle time between single steps an interrupt becomes pending.

To be able to single-step your application you can link some small routines with your application that will help CrossView Pro to avoid this situation.

In EDE, from the Project menu select Project Options... Expand the Linker/Locator entry and select Linker Miscellaneous. Enable the Debug with interrupts check box.

In a makefile or on the command line you can supply the option -uxvw_iss_start to the linker to extract the module from the library.

You have to force a rebuild of your application, as the make utility does not detect changes in options. This module disables the interrupts when the program is stopped, and does not enable them during single-stepping. When the program execution is continued, the interrupt enable flags are restored to their previous state. As single-stepping is not a real-time process anyway, this gives the least interference with your application.

Debugging with interrupts enabled interferes with the 'hardware pofiling' option, as they both require the use of the software interrupt. You can use only one of them at a time.

12.3.1 Detailed Description

If CrossView Pro detects the label "xvw_iss_start" in the application it inserts a "trap" instruction instead of a "debug" instruction at each breakpoint position. So, when the breakpoint position is hit, the DSP starts executing the trap handler routine "trap_handler". The trap handler marks the current interrupt flags and disables the interrupts by manipulating the hardware stack contents. It then replaces the originating "trap" instruction by a "debug" instruction, sets the return address one position back and returns to the newly inserted "debug" instruction. So, finally the situation is the same as without the additional routine, but interrupts are switched off in a very fast way (the debugger would be too slow to do this by itself, there would be interrupts pending already).

During single-stepping, the interrupts remain switched off. This means that no interrupts are accepted during single-stepping. When a go command is issued, the saved interrupt state is restored in the processor before starting to execute code by the xvw_iss_start routine (the interrupt mask and start address are placed in xvw_iss_buffer).

An important issue is that code that manipulates the interrupt bits in the status register during single-stepping is not recognized. This may lead to two situations:

1. Interrupts are enabled, and the single-step fix will fail (interrupts are stepped into again). On the next go this will be fixed again, but an incorrect mask may have been restored (the one that was saved on the previous breakpoint).

2. Interrupts are disabled. On the next go an incorrect mask will be restored (the one that was saved on the previous breakpoint). Interrupts are now enabled when they should not have been.

All in all it is best to put a breakpoint after code that manipulates the interrupt mask bits and issue a go.


Copyright © 2002 Altium BV