User`s guide

VxWorks
BSP Developer’s Guide, 6.0
128
If you want to debug an image during boot, there are two different conditions to
be aware of:
■
code running directly from flash
■
code that is copied into RAM and executed
Setting an Initial Breakpoint in a Flash Image
When the code is running directly from flash, opcodes are fetched from flash and
executed. Because it is not possible to modify the flash to insert the special opcode
that is used to generate the debug exception, software breakpoints are not
available.
Instead, if the processor supports it, you must set a hardware breakpoint. The
hardware breakpoint causes the processor to raise a debug exception, and control
is transferred to the debugger.
Setting an Initial Breakpoint in a Downloaded Image
When debugging a downloaded image, software breakpoints can be used, but
there is a condition on the use of software breakpoints. Recall that setting a
software breakpoint causes a memory location to be modified by saving the
opcode to a safe location and replacing it with a special opcode to generate the
exception. However, if the image is copied into RAM after the breakpoint is set, the
copy operation overwrites the special opcode, and the breakpoint is lost. For this
reason, software breakpoints must be set after the image is loaded.
The standard boot method is to load an image and start execution immediately
after loading it. However, this does not give you time to set any software
breakpoints.
When an OCD device is used, there are three ways to set software breakpoints
early in the boot sequence: separate load-and-go instructions, hardware
breakpoints, and forever loops.
Separate Load-and-Go Instructions
Many boot loaders allow an image to be loaded but not run, in addition to the
normal load-and-go command. With the VxWorks boot loader, the normal @
command causes the image to be loaded and execution to begin. However, it is also
possible to use the l command to load the image, and the g command to start