Name
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/
).
The file VERSION
/misc/trace32ecospropi2-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.
- (Re-)Attach
- 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. - Load APP.ELF
-
This entry disables the caches and MMU, loads the file
app.elf
from the current directory, and loads any breakpoints frombreakpoints.cmm
. This is the menu entry that should be used to load and run SMP applications for development and testing. Thebreakpoints.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. - Load REDBOOT.ELF
-
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
.
2024-12-10 | eCosPro Non-Commercial Public License |