JTAG-based Debugging — Usage

JTAG Hardware Connection

JTAG-based debugging requires direct wiring of the JTAG probe lines to the external GPIO pins of a Raspberry Pi board. The eCosCentric TAP-HAT provides a simple way of doing this. The GPIO pins are not enabled for JTAG operation by default and need to be initialised by RedBoot when the board is booted. See the RedBoot JTAG Command section below for details of how to select and enable the set of pins to be used.

Lauterbach TRACE32

eCosPro includes support for JTAG-based debugging using the Lauterbach TRACE32 debugger with a Lauterbach Power Debug probe. This is currently the best solution for debugging of eCos SMP applications on the Raspberry Pi. You will need suitable licenses for ARM Architecture-v7, Architecture-v8 and multicore debugging in order to debug an SMP application, or an ARM11 license to debug the single core in an Raspberry Pi0 or Pi1.

The TRACE32 debugger needs a startup script to initialize it for the Raspberry Pi. Some example scripts are present in the Raspberry Pi platform HAL ( i.e. packages/hal/arm/cortexa/pi/VERSION/misc/trace32). The file ecospropi2-qt.cmm initializes TRACE32 to debug a Raspberry Pi2 using the QT based variant avaliable on some host operating systems. Similarly the file ecospropi3-qt.cmm initializes TRACE32 to debug a Raspberry Pi3, Pi2 v1.2, or CM3. Finally, ecospropi1-qt.cmm initializes TRACE32 to debug a Raspberry Pi1, Pi0, or CM1. Each of these files additionally loads layout1s-qt.cmm to define the initial window layout and ecospromenu.cmm to define an eCosPro menu.

The expectation in these scripts is that all files are present in the same directory, along with the application being debugged. It is recommended that these files be copied out of the source repository into a working directory to which the application can also be copied and that TRACE32 be started from the command line as follows:

$ cd /path/to/work/directory
$ t32marm64-qt -s ecospropi3-qt.cmm

Raspberry Pi boards cannot be reset from TRACE32, so the safest approach to debugging is to power cycle the board between runs. It is not necessary to exit TRACE32, so long as the eCosPro menu entries to re-attach or load a new application are used, TRACE32 can be re-attach to a reset board.

In addition to attaching to the target, these startup files define an additional eCosPro menu in the TRACE32 GUI. It contains the following entries:

MMU Table List
This entry causes a window showing the current state of the MMU tables for the current CPU to be displayed. In eCos, all CPUs should be using the same shared table.
Load eCos.t32
This loads the TRACE32 eCos RTOS specialization extension. This file should be copied out of the TRACE32 installation into the working directory. Note that depending on the version of TRACE32 in use, the eCos RTOS support may not be fully SMP-aware, so some information it displays in SMP application may be a little misleading. See the Lauterbach documentation on the RTOS debugger for eCos for more details of the functionality available.
Display Threads
Displays a list of current threads. In recent versions of TRACE32 the current thread on each CPU will be marked RUNNING with the CPU number beside it in parentheses. However, CPU affinity is not currently displayed.
Display Scheduler
Displays state of scheduler. Only those parts of the scheduler state common between single and multi-core systems will be displayed.
Display Thread Stacks
Displays a summary of stack usage for all threads. This includes the stack limits, current SP, and the maximum amount of stack each thread has used.
Reset Board
Reset the board. This requires an attachment between the SRST pin of the JTAG cable and the RUN pin on the Raspberry Pi board. If you are using an eCosCentric TAP-HAT adaptor, then the two pin header needs to be soldered in to the RUN-PEN holes on the Raspberry Pi board and the micro-probe lead connected between the centre SRST pin and the RUN pin.
After the RPi has been reset, this entry will re-attach TRACE32 to the board. Typically it will be executing in RedBoot.
Disable MMU
This will disable the MMU and Caches, which may be useful during development if an un-mapped view of memory is required. Any halted program cannot be restarted once this has been done.
Save Breakpoints
This entry saves the current set of breakpoints to breakpoints.cmm. The contents of this file is saved amd reloaded whenever an application file is loaded and allows breakpoint settings to be preserved across restarts of TRACE32. This menu entry provides an alternative way to save the current breakpoints. prior to exiting TRACE32 for example.
This entry disables the caches and MMU, loads the file app.elf from the current directory, and loads any breakpoints from breakpoints.cmm. This is the menu entry that should be used to load and run SMP applications for development and testing. The breakpoints.cmm file allows a set of current breakpoints to be saved using the Store button on the breakpoint list window and have them reloaded automatically each time the application is reloaded.
Load APP.ELF Syms+Bkpts
This entry loads just the symbol tables and debug information from the application and also loads breakpoints from breakpoints.cmm. This is useful if the application is already running when TRACE32 is attached. For example if it is a ROM startup application that has been loaded from the SD card, or an SMP startup application that was loaded by RedBoot.
This does exactly the same thing as the Load APP.ELF menu entry except that it loads redboot.elf. This has been useful in debugging RedBoot.
Load REDBOOT.ELF Syms+Bkpts
This does exactly the same thing as the Load APP.ELF Syms+Bkpts menu entry except that it loads symbold from redboot.elf.