Bureaucrats, dave_user, Administrators
4,650
edits
Changes
no edit summary
====PRACTICE macros for multiple TRACE32====
The startup script, started automatically at the first TRACE32 application, is fully able to configure the whole debug system, providing PRACTICE commands both to the current instance of TRACE32 application, and to the second instance. It’s also possible to deliver the same PRACTICE command to both instances with a single command line. The command redirection is possible using the INTERCOM feature. Typically some PRACTICE macros can be defined for this purpose.
<pre>
&core0="" ;only to improve readability
&core1="intercom localhost:&intercomport_core1"
&core1 ¶m
RETURN
</pre>
In this way, all CPU-specific configuration commands can be performed in the same way for each TRACE32 application, or distinguishing between different configurations. For example:
<pre>
&both SYStem.RESet
</pre>
or:
<pre>
&core0 SYStem.CPU ZYNQ-7000CORE0
&core1 SYStem.CPU ZYNQ-7000CORE1
</pre>
====The SYnch command====
The synchronization between different TRACE32 applications is done by SYnch command group, which allows the following purposes:
* to establish a start/stop synchronization between the cores controlled by different TRACE32 instances;* 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.png|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.
<pre>
TargetSystem DEFault Title SYnch.All InterComPort /Global
</pre>
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.
<pre>
&core0 SYStem.CONFIG.CTI.Base 0x80098000
&core0 SYStem.CONFIG.CTI.Config CORTEXV1
&core1 SYStem.CONFIG.CTI.Base 0x80099000
&core1 SYStem.CONFIG.CTI.Config CORTEXV1
</pre>
===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 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 <code>sYmbol.SourcePATH </code> command can be used, if necessary, to define additional search directories for the source files. The <code>Data.LOAD </code> command for vmlinux is applied to &core0, so that symbol information is not shared with the other TRACE32 application.
[[File:AN-BELK-001_12.png|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.
<pre>
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!
</pre>
In the following paragraphs, the basic TRACE32 Linux configuration will be introduced. For more details, please refer to:
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:
<pre>
; 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
</pre>
The Linux kernel awareness is loaded into the first TRACE32 application, and will not affect the second one.
The Linux menu file (<code>linux.men</code>) includes many useful menu items developed for the TRACE32 GUI to ease Linux debugging.
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.
<pre>
MMU.FORMAT LINUX swapper_pg_dir 0xc0000000--0xc1ffffff 0x00000000
TRANSlation.Create 0xc0000000--0xc1ffffff 0x00000000
TRANSlation.TableWalk ON
TRANSlation.ON
</pre>where the virtual address range is the virtual-to-physical kernel address mapping, according with results of command <code>MMU.List KernelPageTable</code>, executed when the kernel is up and running.In the command <code>TRANSlation.COMMON</code>, the virtual addressrange has been extended below the kernel start address, because kernel objects are loaded in this memory range.
[[File:AN-BELK-001_13.png|600px|thumb|center]]
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.png|600px|thumb|center]]
