# Using TRACE32 ## Overview This chapter describes various issues related to using TRACE32. It covers the following topics: - Error messages “debug port fail” or “debug port time out” - Debugger window displays flickering data - Using wildcards in the symbol browser - Warning message when stepping into functions - Error message “running(off)” - Error message “Emulation debug port fail…” - Debugging exceptions in the target application - TRACE32 fails with message “bus error” - TRACE32 fails with message “access timeout, processor running” - TRACE32 terminates with request for license file - Running the debugger without the GUI ## Error messages “debug port fail” or “debug port time out” The TRACE32 debugger command system.up is typically the first command executed in a debug session. If this command generates the error message “debug port fail” or “debug port time out”, open the debugger AREA window to view any additional messages that might have been generated (for example, “target processor in reset” is simply a follow-up error message). The “debug port” error messages can be generated for a number of reasons: - The target system has no power, or the debug cable is not connected to the target. This results in the additional error message “target power fail”. - The command system.cpu was specified with an invalid processor type. - The JTAG interface experienced an electrical problem – check the schematic. - The debug features need to be enabled (jumpered) on the target. For example, the debugger will not work if signal nTRST is directly connected to ground on the target side. (This is a known issue on some SURF boards.) - The target system is in an unrecoverable state – re-power it and try again. - The target system cannot communicate with the debugger while in reset. If this occurs, instead of using the system.up command try using system.mode attach followed by break, or alternatively “system.option enreset off”. - The default JTAG clock speed is too fast, especially when the target processor is emulated or when using an FPGA-based target. In this case try using the command “system.jtagclock 50kHz”; then after the target is working, try gradually increasing the specified clock speed. - The target processor needs adaptive clocking. In this case specify RTCK mode with the command “system.jtagclock rtck” (which is typical for ARM cores). - The debugger multicore settings are missing when the target is a daisy-chained multi-core system. To check this, enter the command “diag 3400” and then view the AREA window: - The value “ir\_width > 5” indicates that the multicore settings are necessary. - The value “ir\_width = 4” (ARM9) indicates that the multicore settings are unnecessary. - If no value is displayed, there may be a problem with the JTAG interface. - The target processor has no clock. - The target processor is held in reset. - A watchdog timer exists which needs to be deactivated. ## Debugger window displays flickering data If the data in a debugger window is flickering, try one of the following solutions: - Ensure that turbo mode is disabled (using the command “system.option turbo off”). - The default JTAG clock speed may be too fast. Try using the command “system.jtagclock 50kHz”; then if the flickering disappears, try gradually increasing the specified JTAG clock speed. - Check that the MMU is correctly programmed. If not, the data displayed may not be the data you think it is. ## Warning message when stepping into functions When the TRACE32 debugger breaks/steps into a function, it attempts to read source code information based on the debug symbols it encounters in the newly-entered function. If the source code information can’t be found, the debugger will generate a warning message. If a warning message appears while you are debugging a program, two options are available for helping TRACE32 find the correct source path: ### Solution 1: Use the following command to remove six path variables and replace them with a string containing the path to the source code files. For example: d.load.elf ..\..\build\ig_server.reloc /STRIPPART 6 /PATH L:\user\tools Copy to clipboard #### Solution 2: Use the command symbol.sourcepath to directly specify the source file. For example: symbol.sourcepath + L:\user\tools\rtos\okl-1.3.4\libs\qurt\src\qmsgq\sys-iguana\qMsgQClient.c Copy to clipboard ## Error message “running(off)” If the TRACE32 debugger displays the message “running(off)” after you click on Continue, this indicates that a thread continued executing past a stop instruction. (Note that a thread normally cannot execute past a stop.) The most probable cause for this event is that the target application crashed, which then caused the RTOS kernel to execute an assert which stopped all the threads. To debug the cause of the assert, use the procedure described in [Debugging exceptions in the target application](https://docs.qualcomm.com/doc/80-N2040-28/topic/using-trace32.html#debug-exception-target-app). ## Error message “Emulation debug port fail…” If the TRACE32 debugger displays the message: `Emulation debug port fail. Unable to set up debugging, ISDB clock off` …this means that no clocks are reaching ISDB (as indicated by the ISDB enable register field ISDB\_CLK\_OFF being set to 1). This usually indicates is that no clocks are being driven to the Hexagon at the point where the debugger tries to access ISDB. The debugger sets JTAG\_ISDB\_EN and then polls ISDB\_CLK\_OFF; if it does not see the value flip to zero after a period of time, the debugger gives up. By default the debugger polls ISDB\_CLK\_OFF 100 times before giving up. The poll count can be changed by using the command “DIAG 3003. xxx”, where xxx specifies the poll count. Note Changing the poll count will affect other timeouts, and may result in strange behavior if the count is set too high. Note also that the DIAG command is not supported by Lauterbach. ## Debugging exceptions in the target application Optimally, the RTOS kernel would respond to a user page fault or unhandled exception in the target application by performing the following actions: 1. Stop all other executing threads 2. Flush memory 3. Report the register state of the current hardware thread 4. Stop itself However, hardware limitations in the Hexagon V2 processor prevent the current hardware thread from immediately stopping the other hardware threads. Therefore, the best method for catching these exceptions is to set breakpoints on the following label symbols: - hexagon\_page\_fault - hexagon\_error\_exception When the breakpoint is hit, use the debug tools to obtain the necessary register and thread information from the TCB (thread control block). The following table shows the memory structure of the TCB. **Table A-1 TCB structure** | **Field** | **Description** | | --- | --- | | myself\_global | Thread global ID | | thread\_state | Thread state
| | partner | Thread partner


Contains thread ID of the other thread involved in an IPC
operation (or -1 for a wait-for-message from anyone) | | priority | Thread priority | | context | Hexagon processor unit (0-3) that hardware thread is currently
using. Set to -1 if unit not scheduled. | | scheduled\_unit | Hexagon processor unit (0-3) that hardware thread is scheduled
to use. | Note The information in this section applies only to the Hexagon V2 processor. ## TRACE32 fails with message “bus error” If the TRACE32 debugger displays the message “bus error” and then fails, this indicates that either TRACE32 or the RTOS awareness module attempted to access undefined memory. The TRACE32 debugger maintains a cache copy of the MMU translations (which are a superset of the static mapping from ELF files, L4 page tables, and TLB). The debugger scripts configure the MMU and provide information on the kernel MMU mapping and the base address for the root task page table. These scripts must be configured correctly. The debugger is set to trigger an autoscan whenever it finds a mismatch. This scan involves the RTOS awareness module providing correct page table pointers. The RTOS awareness module may not be initialized to the correct physical address. A workaround is to set only on-chip breakpoints. ## TRACE32 fails with message “access timeout…” If the TRACE32 debugger displays the message “access timeout, processor running” and loses control of the target, this indicates that the debugger has tried to execute a command that accesses the target, but the target was running. Note This message also appears when the stop of the target does not work (e.g., Hexagon is in the OFF state). ## TRACE32 terminates with request for license file Whenever TRACE32 is started with an unlicensed software component (e.g., processor or GDI extension), Lauterbach allows 60 minutes of free use, after which the application automatically terminates with a message stating that a valid license is required. To use TRACE32 without having to restart it every 60 minutes, you must purchase licenses for the components in question. ## Running the debugger without the GUI To start the TRACE32 debugger without the GUI add the following command to the TRACE32 configuration file (config.t32): `SCREEN=OFF` Note Running TRACE32 without the GUI is typically done when a user needs to execute automated tests. Last Published: Oct 06, 2026 [Previous Topic Using the MCD arguments](https://docs.qualcomm.com/bundle/publicresource/80-N2040-28/topics/debugging-applications-on-the-software-simulator.md)