Use of JTAG for debugging
JTAG can be used to single-step and debug loaded applications, or even applications resident in ROM, including RedBoot.
Debugging of ROM applications is only possible if using hardware
breakpoints. The Cortex-M3 core of the STM32 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 such as at
main(). Some JTAG devices give the option
of whether to set hardware or software breakpoints by default. Be
sure to configure your device appropriately.
When debugging via JTAG, you are likely to need to disable the default HAL idle thread action, otherwise there may be issues where the target fails to halt and the debugging session is unreliable. More details can be found in the Cortex-M architectural HAL.
Normally, a notable disadvantage with JTAG debugging is that it does not allow thread-aware debugging, such as the ability to inspect different eCos threads or their stack backtraces, set thread-specific breakpoints, and so on. Fortunately the Ronetix PEEDI JTAG unit does support thread-aware debugging of eCos applications, however extra configuration steps are required. Consult the PEEDI documentation for more details as usage is beyond the scope of this document.
Ronetix PEEDI notes
On the Ronetix PEEDI, the peedi.stm3220g.cfg or peedi.stm3240g.cfg file supplied in the platform HAL package should be used to setup and configure the hardware to an appropriate state to load programs. This includes setting up the clocks, GPIO lines, and FSMC memory controller for off-chip SRAM.
The peedi.stm3220g.cfg and peedi.stm3240g.cfg files also contain an option to define whether hardware or software breakpoints are used by default, using the CORE0_BREAKMODE directive in the [TARGET] section. The supplied version of the file defaults to software breakpoints. With this default, hardware breakpoints can still be set from GDB using the hbreak command, or in the eCosPro version of Eclipse by setting the Breakpoint Type - consult the "Eclipse/CDT for eCos application development" manual for details. The default can be changed to hardware breakpoints, and remember to use the reboot command on the PEEDI command line interface, or press the reset button to make the changes take effect.
On the PEEDI, debugging can be performed either via the telnet interface or using arm-eabi-gdb. In the case of the latter, arm-eabi-gdb needs to connect to TCP port 2000 on the PEEDI's IP address. For example:
(gdb) target remote 111.222.333.444:2000
By default when the PEEDI is powered up, the target will always run the initialization section of the relevant peedi.stm3220g.cfg or peedi.stm3240g.cfg file, and halts the target. This behaviour is repeated with the reset command.
If the board is reset either with the 'reset' command, or by pressing the reset button, and then the 'go' command is given, the board will boot from ROM as normal. A similar effect can be achieved in GDB by connecting with target remote and immediately typing continue or c.
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 CORE0_STARTUP_MODE directive in the [TARGET] section of the appropriate peedi.stm3220g.cfg or peedi.stm3240g.cfg file. 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. Finally, it is also possible to set a temporary default (unless the PEEDI is reset) by giving an argument to the reset command, for example reset run. Use the command help reset at the PEEDI command prompt for more options.
Suitably configured applications can be loaded either via GDB, or directly via the telnet CLI into RAM for execution. For example:
stm3220g> memory load tftp://192.168.7.9/test.bin bin 0x64000000 ++ info: Loading image file: tftp://192.168.7.9/test.bin ++ info: At absolute address: 0x64000000 loading at 0x64000000 loading at 0x64004000 Successfully loaded 28KB (29064 bytes) in 0.1s stm3220g> go 0x64000000
For Eclipse users wishing to debug ROM startup programs resident in Flash, it is worth highlighting that it is possible to use the eCosCentric Eclipse plugin to automatically reprogram Flash as the load sequence. To do so, you will need to install and use a TFTP server so that your application can be accessed from the PEEDI from there. You may then use a GDB command file, as described in more detail in the "Eclipse/CDT for eCos application development" manual. This file can then contain contents similar to the following example:
define doload shell arm-eabi-objcopy -O binary /path/to/eclipse/workspace/projectname/Debug/myapp /path/to/tftp/server/area/myapp.bin monitor flash program tftp://10.1.1.1/myapp.bin bin 0x08000000 erase set $pc=0x08000000 end
Obviously you will need to adjust the paths and names for your system and TFTP server requirements.
Configuration of JTAG applications
JTAG applications can be loaded directly into RAM 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, it
is recommended to use the JTAG startup type which will
implicitly cause two important settings to change. Firstly,
CYGSEM_HAL_USE_ROM_MONITOR must be
disabled. 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. These configuration changes could be
made by hand, but use of the JTAG startup type will just work.
With these changes, any diagnostic output will appear out of
the configured diagnostic channel, usually a serial port. An
eCosCentric extension allows diagnostic output to appear in
GDB instead. For this to work, you must enable the configuration
the common HAL package. Then after you load your application,
but before running it, you must give GDB the command:
(gdb) set hwdebug on
Eclipse users can do this by creating a GDB command file with the contents:
define postload set hwdebug on end