JTAG support — Usage
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
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.
files also contain an option to define whether hardware or software breakpoints are
used by default, using the
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
“eCosPro CDT plug-in user's guide” 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
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:
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.stm3240g.cfg file, and halts the target.
This behaviour is repeated with the reset
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
directive in the
[TARGET] section of the appropriate
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>
Consult the PEEDI documentation for information on other formats and loading mechanisms.
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 “eCosPro CDT plug-in user's guide” 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.
For details of using hardware debug with the Eclipse IDE see the “eCos Hardware Debugging” section of the “eCosPro CDT plug-in user's guide” manual.
|2019-06-13||eCosPro Non-Commercial Public License|