Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→The SYnch command
to allow concurrent assembler single steps between the cores controlled by different TRACE32 instances;
to allow synchronous system mode changes between the cores controlled by different TRACE32 instances.
[[File:AN-BELK-001_10.jpg|600px|thumb|center]]
The SYnch settings are reported below:
Connect
Establish a connection to the debugger attached to the defined communication port(s). Several debuggers ports can be specified, separated by space.
MasterGo ON
If the program execution is started, the program execution for all other processors which have SlaveGo ON is also started.
MasterBrk ON
If the program execution is stopped, the program execution for all other debuggers which have SlaveBrk ON is also stopped.
MasterStep ON
If an asm single step is executed, all processors which have SlaveStep ON will also asm single step.
MasterSystemMode ON
Invite other TRACE32 instances to perform system mode changes synchronously. System mode changes are typically performed by the commands SYStem.Mode <mode>
SlaveGo ON
The program execution is started, if a processor with MasterGo ON starts its program execution.
SlaveBrk ON
The program execution is stopped, if a processor with MasterBrk ON stops its program execution.
SlaveStep ON
A asm single step is performed, if a processor with MasterStep On performs an asm single step.
SlaveSystemMode ON
Synchronize with system mode changes in connected TRACE32 instances.
A summary of SYnch configuration is provided with command TargetSystem, which also allows to easily and rapidly modify the SYnch mode options.
Moreover the TargetSystem command provides a general overview of the whole multicore configuration and of the current state.
TargetSystem DEFault Title SYnch.All InterComPort /Global
There is a time delay between reaction of different cores. The reaction time of the slave core depends on the technical realisation of the synchronization. If no specific configuration is performed, the synchronization is done by software (eg: the master debugger informs the slave debugger via socket communication on the host about specified events). On the other side, if the on-chip Cross Trigger Interface is configured, the synchronization takes place directly on the processor. This is a faster solution and the time delay between reaction of different cores becomes around 0-10ns.
The CTI interface for chip Zynq is configured with the following commands. If CTI is configured, TRACE32 will use the faster solution for the synchronization.
&core0 SYStem.CONFIG.CTI.Base 0x80098000
&core0 SYStem.CONFIG.CTI.Config CORTEXV1
&core1 SYStem.CONFIG.CTI.Base 0x80099000
&core1 SYStem.CONFIG.CTI.Config CORTEXV1
===Setting up the Linux debug configuration===
The symbolic information is useful for HLL debugging, or setting breakpoints, stepping through the code, viewing variables, and many other aspects of debugging. The compiler must be configured in order to generate debug symbols. The vmlinux file for the running kernel must be available, in order to load the kernel debug symbols.
No instrumentation is needed in the kernel source code for debugging with Lauterbach, but it’s important that the vmlinux file is generated from the same kernel build as the zImage or uImage running on the system.
The Data.LOAD command is used to load the kernel symbols, and the sYmbol.SourcePATH command can be used, if necessary, to define additional search directories for the source files. The Data.LOAD command for vmlinux is applied to &core0, so that symbol information is not shared with the other TRACE32 application.
[[File:AN-BELK-001_12.jpg|600px|thumb|center]]
Specific options must be configured to avoid automatic Break of TRACE32 debugger, in case any of the following events happens due to normal Linux operations.
TrOnchip.Set UNDEF OFF ; may be used by Linux for FPU detection
TrOnchip.Set DABORT OFF ; used by Linux for page miss!
TrOnchip.Set PABORT OFF ; used by Linux for page miss!
In the following paragraphs, the basic TRACE32 Linux configuration will be introduced. For more details, please refer to:
“Training Linux Debugging” manual (training_rtos_linux.pdf)
“RTOS Debugger for Linux - Stop Mode” manual (rtos_linux_stop.pdf).
4.5.1 Kernel awareness
TRACE32 kernel awareness technology makes debugger aware of the OS running in the target system. Debug is significantly simplified, as the user can immediately access all the components of the OS and the application. The Executable and Linkable Format (ELF) binaries, created at kernel build time, are used also by Linux awareness.
The Linux kernel awareness is configured with the commands:
; loads Linux awareness
&core0 TASK.CONFIG ~~/demo/arm/kernel/linux/linux-3.x/linux3.t32
; loads Linux menu
&core0 MENU.ReProgram ~~/demo/arm/kernel/linux/linux-3.x/linux.men
The Linux kernel awareness is loaded into the first TRACE32 application, and will not affect the second one.
The Linux menu file (linux.men) includes many useful menu items developed for the TRACE32 GUI to ease Linux debugging.
4.5.2 MMU support
In Linux embedded, the Lauterbach debuggers provide a very tight integration with the RTOS. The kernel awareness supports Linux MMU format and is able to handle virtual memory addressing.
MMU.FORMAT LINUX swapper_pg_dir 0xc0000000--0xc1ffffff 0x00000000
TRANSlation.Create 0xc0000000--0xc1ffffff 0x00000000
TRANSlation.COMMON 0xbf000000--0xffffffff
TRANSlation.TableWalk ON
TRANSlation.ON
where the virtual address range is the virtual-to-physical kernel address mapping, according with results of command MMU.List KernelPageTable, executed when the kernel is up and running.
In the command TRANSlation.COMMON, the virtual address
[[File:AN-BELK-001_13.jpg|600px|thumb|center]]
range has been extended below the kernel start address, because kernel objects are loaded in this memory range.
4.5.3 Debugging of kernel modules
The Linux kernel can be compiled to allow linking of additional modules at runtime (kernel objects). The Lauterbach debuggers also support kernel modules debugging, starting from the initialization function.
[[File:AN-BELK-001_14.jpg|600px|thumb|center]]
====Debugging of user processes, threads, shared objects====
User process debugging is also available, starting from the very beginning of the process. If the process loads shared objects, they are loaded in the process address space when the related instructions are executed for the first time (demand paging).
The Lauterbach debuggers also support debug of threads for multithreaded processes. In this case, the same address space is shared between different threads and the symbolic information can be loaded only once per process.
In general, the same techniques used for debugging kernel code, such as setting breakpoints, stepping through code, watching variables, and viewing memory contents, can be performed in the same way for processes and tasks.
Virtual address spaces are distinguished in TRACE32 using the concept of spaceID, which is enabled with the option:
SYStem.Option MMUspaces ON
The memory addressing is extended using the lower 16 bit of the process PID, allowing in this way to distinguish between equal virtual addresses for different processes.
[[File:AN-BELK-001_15.jpg|600px|thumb|center]]
== Related documents and additional resources ==
