JTAG can be used to single-step and debug loaded RAM applications, or even
applications resident in ROM, including RedBoot.
Debugging of ROM applications is only possible if using hardware breakpoints. The
XScale only supports four such hardware breakpoints - two for instruction breakpoints
and two for data breakpoints, and so they should be used sparingly. If using a GDB
front-end such as Eclipse, check it
has not set unnecessary extra breakpoints. Some JTAG devices give the option
of whether to set hardware or software breakpoints by default. Be sure to configure
your device appropriately.
Abatron BDI2000 notes
On the Abatron BDI2000, the ixdp425.cfg file that is
included with the BDI2000 software should
be used to setup and configure the hardware to an appropriate state to load
programs. This includes setting up the SDRAM controller.
The ixdp425.cfg file also contains an option
to define whether hardware or software breakpoints are used by default, using
the BREAKMODE directive in the [TARGET]
section. Edit this file if you wish to use software break points, and remember
to use the boot command on the BDI2000 command line interface
to make the changes take effect.
On the BDI2000, debugging can be
performed either via the telnet interface or using arm-eabi-gdb
and the bdiGDB interface. In the case of the latter, arm-eabi-gdb
needs to connect to TCP port 2001 on the BDI2000's IP address. For example:
(gdb) target remote 111.222.333.444:2001
By default when the BDI2000 is powered up, the target will always run the
initialization section of the ixdp425.cfg
file (which configures the SDRAM among other things), and halts the target.
This behavior is repeated with the reset halt command.
If the board is reset when in 'reset halt' mode
(either with the 'reset halt' or 'reset'
commands, or by pressing the reset button) and the 'go'
command is then given, then the board will boot as normal. If a ROMRAM RedBoot
is resident in Flash, it will be run.
It is also possible for the target to always run, without initialization,
after the reset button has been pressed.
This mode is selected with the reset run command. This
conveniently allows the target to be connected to the JTAG debugger, and
be able to reset it with the reset button, without being required to always
type 'go' every time. Thereafter, invoking the
reset command will repeat the previous reset style. Also
in this mode, exceptions will be handled by board software, rather than
causing the JTAG debugger to halt the CPU.