
October 13 1995, Draft 1
347
Chapter 7 Software Debugging
the warm–start operation is entirely operating system dependent, and the code need
pay no attention to the return structure information. The operation of OS–boot, nor-
mally supplied along with MiniMON29K, is described in a later section.
7.3.5 Advanced DBG and CFG Module Features
Normally the call to
dbg_control()
implies that a
built–in
breakpoint should be
taken. This gives the user an opportunity to down–load an application program be-
fore execution is continued. However, by setting the call
lr2
parameter to V_NOBRK
(254), no breakpoint will be taken and the call will return with no need for a GO mes-
sage from MonTIP. This enables the DebugCore to be initialized for operation, and is
useful where there is no requirement to download an application program. Of course
there are no call return values for the operating system warm–start to examine. The
facility enables the DebugCore to remain in a final system and only be called upon in
a
emergency
such as memory access violation.
The CFG module is used to configure the operation of the DBG module. There
is really no need to have the source code for the DBG module, only the CFG module.
After configuring the CFG, it can be assembled and linked with the
.o
debug core
modules (
dbg_core.o
and
dbg.o
). The CFG supplies the
cfg_peek()
and
cfg_poke()
functions, as well as defining the number of breakpoints supported and the size of the
DebugCore message send buffer. Note, however, that there is conditional assembly
code in the CFG module for a wide range of target hardware systems. In practice con-
figuring CFG normally means defining the correct symbol value during assembly.
Whenever the DebugCore is entered, the routine
cfg_core_enter()
is called.
This gives the DebugCore user an opportunity to control the state of the processor
during DebugCore operation. For example, normally the DebugCore runs with the
on–chip timer turned off. This means no timer progress is made and no timer inter-
rupts will occur while the DebugCore is in context. The timer can be re–enabled by
changing the code in
cfg_core_enter().
The supplied code also locks the processor
cache (only with processor members supporting cache). This prevents application
and operating system relevant data being displaced with DebugCore information.
The DebugCore is mainly written in the C language and makes use of applica-
tion space processor registers during its operation. On taking, say, a breakpoint and
entering the DebugCore, all the processor registers are copied to
shadow
memory
locations. Users examine and change the shadow values before they are returned to
registers when the DebugCore context is exited. It is possible that an external hard-
ware device could generate an interrupt when the DebugCore is
in–context
(inter-
rupts may be enabled in the
cfg_core_enter()
procedure). This could cause some
confusion as the interrupt handler may wish to modify some operating system as-
signed registers to record a change in the interrupting device status. The change
would be lost when the DebugCore exited. To overcome this problem, global regis-