Specifications

Table Of Contents
ARM Debugger 1 9 S y m m e t r i c M u l t i p r o c e s s i n g
©1989-2014 Lauterbach GmbH
Symmetric Multiprocessing
A multi-core system used for Asymmetric Multiprocessing (AMP) has specialized cores which are used
for specific tasks. To debug such a system you need to open separate TRACE32 graphical user interfaces
(GUI) one for each core. On each GUI you debug the application which is assigned to this core and will
never be executed on an other core. The GUIs can be synchronized regarding program start and halt in
order to debug the cores interaction.
ARM11 MPCore and Cortex-A9 MPCore are examples for multi-core architectures which allow Symmetric
Multiprocessing (SMP). The included cores of identical type are connected to a single shared main
memory. Typically a proper SMP real-time operating system assigns the tasks to the cores. You will not know
on which core the task you are interested in will be executed.
To debug a SMP system you start only one TRACE32 GUI.
The selection of the proper SMP chip (e.g. ’CNS3420’ or ’OMAP4430’) causes the debugger to connect to
all included SMP-able cores on start-up (e.g. by ’SYStem.Up’). If you have a SMP-able core type selected
(e.g. ’ARM11MPCore’ or ’CortexA9MPCore’) you need to specify the number of cores you intend to SMP-
debug by SYStem.CONFIG CoreNumber <number>.
On a selected SMP chip (e.g. ’CNS3420’ or ’OMAP4430’) the CONFIG parameters of all cores are typically
known by the debugger. For a SMP-able core type you need to set them yourself (e.g. IRPRE, COREBASE,
...). Where needed multiple parameters are possible (e.g. ’SYStem.CONFIG.COREDEBUG.Base
0x80001000 0x80003000’.
System options and selected JTAG clock affect all cores. For the start-up the first core gets control over the
reset signals. ’SYStem.CONFIG Slave ON’ may only be used if none of the SMP cores may control the reset
lines and initialize the JTAG interface.
All cores will be started, stepped and halted together. An exception is the assembler single-step which will
affect only one core.
TRACE32 takes care that software and on-chip breakpoints will have effect on whatever core the task will
run.
When the task halts, e.g. due to a breakpoint hit, the TRACE32 GUI shows the core on which the debug
event has happened. The core number is shown in the state line at the bottom of the main window. You can
switch the GUIs perspective to the other cores when you right-click on the core number there. Alternatively
you can use the command CORE.select <number>.