Name
JTAG support — Usage
Use of JTAG for debugging
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 ARM920T core of the AT91RM9200 only supports two such hardware breakpoints, 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 bdi2000.dnp_sk23.cfg
file should
be used to setup and configure the hardware to an appropriate state to load
programs. This includes setting up the SDRAM controller.
The bdi2000.dnp_sk23.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 bdi2000.dnp_sk23.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.
Suitably configured RAM applications can be loaded either via GDB, or directly via the telnet CLI. For example:
Core#0>load 0x20008000 /test.bin bin
Loading /test.bin , please wait .... Loading program file passed Core#0>go 0x20008000
Consult the BDI2000 documentation for information on other formats.
Configuration of RAM applications
If the JTAG device has initialized the SDRAM, such as by using the
bdi2000.dnp_sk23.cfg
configuration on the BDI2000,
RAM applications can be loaded directly into SDRAM without requiring
a ROM monitor. This loading can be done directly through the JTAG device,
or where supported by the JTAG device, through GDB.
In order to configure the application to support this mode, some configuration
settings are required. Firstly CYGSEM_HAL_USE_ROM_MONITOR
must be disabled. This will also cause the
CYGBLD_HAL_ARM9_ATMEL_AT91RM9200_KITS_LOAD_LOW_RAM
configuration option to be enabled allowing the application to be built with
a set of memory layout files that will configure the linker script to set
the program load address to be within the physical SDRAM space. Secondly
the CYGDBG_HAL_DIAG_TO_DEBUG_CHAN
option should be
enabled in order to prevent HAL diagnostic output being encoded into
GDB ($O) packets.
Running RAM applications
Once loaded and running via JTAG, HAL diagnostic output will appear by default
on the serial debug port. USART 1 can be chosen instead by setting the
CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL
configuration option in the platform HAL to channel 1.
Warning | |
---|---|
If resetting the board using the JTAG device, such as by using the BDI2000 reset command, the Ethernet PHY fails to interface correctly with the AT91RM9200, and consequently all subsequent ethernet operations are impossible. Only a reset by pressing the reset button, cycling the power or due to a watchdog timeout will cause the PHY to reset correctly. |
2024-12-10 | eCosPro License |