Use of JTAG/SWD for debugging
JTAG/SWD can be used to single-step and debug loaded applications, or even applications resident in ROM, including the GDB stub ROM.
Debugging of ROM applications is only possible if using hardware
breakpoints. The Cortex-M4 core of the K60-series only supports six
such hardware breakpoints, so they may need to be used sparingly. If
using a GDB front-end such as Eclipse, check it has not set
unnecessary extra breakpoints such as
main(). Some JTAG/SWD 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. This should not be necessary when using a SWD-based hardware debugger.
The default eCos configuration does not enable the use of ITM stimulus ports for the output of HAL diagnostics or Kernel instrumentation. If ITM output is required the architecture HAL package CYGPKG_HAL_CORTEXM provides options to enable such use. The host hardware debugger configuration may also need to be updated to provide the necessary ITM enable and capture support.
For HAL diagnostic (e.g.
the architecture CDL
should be updated to select ITM as the output
destination. Once the ITM option has been
allows the actual stimulus port used for the diagnostics to be
When the Kernel instrumentation option CYGPKG_KERNEL_INSTRUMENT is enabled then the CYGHWR_HAL_CORTEXM_ITM_INSTRUMENTATION option can be enabled to direct instrumentation record output via an ITM stimulus port, rather than into a local memory buffer. The stimulus port used can be configured via the CYGHWR_HAL_CORTEXM_ITM_INSTRUMENTATION_PORT_BASE option.
Normally a notable disadvantage with JTAG/SWD 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. Similarly OpenOCD has support for interpreting eCos thread information. Consult the PEEDI or OpenOCD documentation for more details as usage is beyond the scope of this document.
The OpenOCD debugger can be configured to support the on-board OSJTAG interface available via the USB J13 connection.
An example OpenOCD configuration file openocd_twr_k60n512.cfg is provided within the eCos platform HAL package in the source repository. This will be in the directory packages/hal/cortexm/kinetis/twr_k60n512/VERSION/misc relative to the root of your eCos installation.
This configuration file can be used with OpenOCD on the host as follows:
$ openocd -f openocd_twr_k60n512.cfg Open On-Chip Debugger 0.8.0-dev-hg8c51ca8dbc00-dirty (2013-09-09-17:18) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst cortex_m3 reset_config sysresetreq Info : add flash_bank kinetis k60.pflash Info : OSBDM has opened Info : This adapter doesn't support configurable speed Info : JTAG tap: k60.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) START... Info : k60.cpu: hardware has 6 breakpoints, 4 watchpoints END... Info : accepting 'gdb' connection from 3333 Halting CPU... Info : JTAG tap: k60.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) START... END...
By default openocd provides a telnet console on port 4444, and this can be used to interact with the target system. This console interface can be used to perform debugging, program the flash, etc.
To debug the target from the command line, arm-eabi-gdb should be connected to OpenOCD using it's default GDB server port of 3333. For example:
(gdb) target remote localhost:3333 Remote debugging using localhost:3333 0x1fff0006 in ?? () (gdb) monitor reset halt JTAG tap: k60.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00004e9c msp: 0x2000f800 (gdb)
The application can then be loaded and executed under GDB as normal. If you are using Eclipse then you may need to define a “preload” gdb macro to emit any necessary commands to OpenOCD prior to loading or executing. See the “Hardware Assisted Debugging” section of the “Eclipse/CDT for eCos application development” document's “Debugging eCos applications” chapter.
If you need to build your own copy of OpenOCD then when configuring the openocd tool build, the configure script can be given the option --enable-osbdm to provide for OSJTAG support.
Ronetix PEEDI notes
On the Ronetix PEEDI, the peedi_twr_k60n512.cfg file supplied in the platform HAL package should be used to setup and configure the hardware to an appropriate state to load programs.
The peedi_twr_k60n512.cfg file also contains 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 hardware breakpoints. If the breakpoint type is changed remember to use the reboot command on the PEEDI command line interface, or press the reset button to make the changes take effect.
The PEEDI provides a telnet console on the standard telnet port (23) for configuration and control, and gdb remote debugging access via port 9000. For example, to use the command line arm-eabi-gdb to connect to the target via the PEEDI, you would issue the following gdb command:
(gdb) target remote 111.222.333.444:9000
By default when the PEEDI is powered up, the target will always run the initialization section of the peedi_twr_k60n512.cfg file, and halts the target. This behaviour is repeated with the reset command.
If the board is reset with the 'reset' command, 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 reset. This mode is selected with the CORE0_STARTUP_MODE directive in the [TARGET] section of the peedi_twr_k60n512.cfg file. This conveniently allows the target to be connected to the JTAG debugger, and be able to reset and run the resident flash program 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:
twr_k60n512> memory load tftp://192.168.7.9/test.bin bin 0x20000000 ++ info: Loading image file: tftp://192.168.7.9/test.bin ++ info: At absolute address: 0x20000000 loading at 0x20000000 loading at 0x20004000 Successfully loaded 28KB (29064 bytes) in 0.1s twr_k60n512> go 0x20000000
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 “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/SWD applications
In order to configure the application to be downloaded and debugged
via a hardware debugger, it is recommended to use one of the JTAG
startup types (JTAG or ROM), which will implicitly cause two important
CYGSEM_HAL_USE_ROM_MONITOR will be
CYGDBG_HAL_DIAG_TO_DEBUG_CHAN option will be
enabled in order to prevent HAL diagnostic output being encoded into
GDB ($O) packets. These configuration changes could also be made by
hand, but use of one of the JTAG startup types will just work.
With these changes, any diagnostic output will appear out of the
configured diagnostic channel. By default the K60's JTAG startup types
output diagnostics via the USB CDC/ACM serial port on the J13 USB
connector. Alternatively diagnostic output can be configured to appear
in GDB instead. For this to work, you must enable the configuration
CYGSEM_HAL_DIAG_TO_GDBFILEIO_CHAN in 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