FAQs for TriCore Debugger

The embedded tools company

Search FAQs

PDF document ( 137KB / 27-Mar-2022 )

After SYStem.Mode Up the target is running and the debugger shows "running (PLL lock wait)". How can I stop program execution?
Ref: 0394

The information that the PLL is not locked is read by the debugger from the register PMSCR located in the SCU. Whether the PLL is locked or not does not affect the debug connection, so this is not an error but an information.

However this CPU state is often observed in cases where the debugger seems to have a debug connection established but the target does not respond to debugger commands such as break. Although the debug connection is broken completely, the debugger thinks to get valid responses from the target without being able to recognize that they are invalid. So for the debugger the target state is that the TriCore is running and the PLL is not locked.

An additional check that the debug connection is not working correctly is performing a JTAG chain scan. For this, execute "Menu -> Help -> Support -> Systeminfo..." and check the results at the end of the file in section "JTAG Chain": If the chain scan failed and you see a message such as "TDO stays constantly low" there is no target connection possible with this device.

There may be two main reasons: Either there is a physical or logical connection problem, or your TriCore device is broken. You may want to cross-check with another target system or debugger. Remove all extension cords and connect the debug cable directly to your target device.

After updating to a newer TRACE32 software version I get an error message "command locked" when executing MCDS commands.
Ref: 0567

Some TC2xx and TC3xx variants, e.g. ADAS or Extended Feature (Feature Packages A and X) have MCDS or MCDSlight implemented and available, but not tested by Infineon during the production.

Starting from R.2021.02, TRACE32 disabled MCDS support for non-emulation devices: TRACE32 will only enable MCDS for devices where MCDS or MCDSlight are officially supported by Infineon (e.g. Emulation Devices and ADAS+Trace devices).

In case the chip has a miniMCDS, this is always tested. Thus MCDS support for these devices remains enabled.

Can the TRACE32 debugger or the user application interfere with internal FLASH programming?
Ref: 0580

Simultaneous read-while-write access within a single FLASH bank is not supported by the chip. Reading from a FLASH bank while it is programmed can interfere with the programming, resulting in incorrectly programmed FLASH content. In worst cases, this may end up in a permanently locked device.

When using TRACE32 functionality for programming the FLASH, make sure that no chip component concurrently accesses the FLASH bank that is currently being programmed.

When using TRACE32 while the application or a third-party tool is programming the FLASH, make sure that TRACE32 does not access the FLASH bank currently being programmed. This can be achieved by:
  • Closing all windows showing content from this FLASH bank, e.g. Data.dump or List.auto
  • Using MAP.DenyAccess <flash_bank_range> to protect the FLASH bank address range from debugger access.

For a better debug performance, should I use the CombiProbe instead of a TriCore debug cable?
Ref: 0496

The CombiProbe supports the DAPWide debug port type and a debug clock of up to 160 MHz. Additionally, timing-critical parts of the target communication is implemented in hardware. So in contrast to a TriCore debug cable, higher data rates may only be achieved in some corner cases. For regular debugging you will normally not notice any performance improvements.

The only situation where the CombiProbe will achieve its high performance is the DAP streaming (Trace.METHOD CAnalyzer), where the onchip trace buffer is read via a special mechanism. The chip only supports this mechanism for the DAP streaming mode.

I cannot connect to my target after installing Version 2018.01.0000092378 or newer.
Ref: 0442

This FAQ applies if:
  • you are using JTAG to connect to your target
  • you are not explicitly configuring the connection type, i.e., you are not using SYStem.CONFIG DEBUGPORTTYPE in your start-up script
  • You are using Version 2018.01.0000092378 or newer
The default setting for SYStem.CONFIG DEBUGPORTYPE changed in Version S.2018.01.0000092378 from JTAG to DAP2.
Reasons: DAP has better robustness, is supported by all current TriCore CPUs and is preferred by most customers.
Solution: Explicitly set SYStem.CONFIG DEBUGPORTTYPE JTAG.

JTAG communication is not possible with some AURIX devices.
Ref: 0413

On some TriCore AURIX devices the TDI pin, which is necessary for JTAG communication, is replaced by the VDDPSB (3.3V) pin.
Therefore it is not possible to debug via JTAG. Instead DAP mode can be used (see command SYStem.CONFIG.DEBUGPORTTYPE DAP).
Note that currently only Emulation Devices in an LQFP package (except Fusion Quad and TC27x-Astep) are affected, e.g. TC275TE, TC264DE, TC265DE. Please consult the Infineon documentation for details.

My CPU is no longer hold in SYStem.Mode Down after installing version 2018.01.0000092477 or newer.
Ref: 0443

The behavior of SYStem.Mode Down was changed in version S.2018.01.0000092378. Now, the debug port is tristated and reset is no longer activated.
The old behavior can be restored by adding SYStem.Option DOWNMODE ReSeT to one of your start-up scripts (see "Automatic Start-up Scripts" in practice_user.pdf).

Sometimes, after writing to cache memory using the debugger the data reverts back to the original value. What could be the problem?
Ref: 0564

This FAQ applies to AURIX devices (TC2xx and TC3xx).

When the debugger accesses the memory through the system bus this will update the memory but not the data cached by the CPU and this might cause cache coherency issues.
The debugger can overcome this in different ways. One possibility to access the cache by the debugger is to MAP the cache data and tags via MTU. Check that the option "SYStem.Option MAPCACHE ON" (default) is set.

Due to the internal architecture of the CPU (e.g. usage of the store buffers), stores might not become visible immediately in the data cache and the memory. This introduces another level of incoherency (e.g. between the content of the store buffers and the data caches).
Consider setting "SYStem.Option DSYNC ReadWrite". This will execute the dsync instruction on the first read or write to ensure that the CPU writes all data back to caches and memory.

Consider also setting "SYStem.Option DCREAD ON" to display the correct cached data when using the access class "D". In this case e.g. Var.Watch / Var.View window will display variables from the CPUs point of view.

  • It is not possible to access cached memory areas while the CPU is running. In this case, physical memory is accessed.
  • Early AURIX devices (TC27x-Astep, TC2Dx) behave like AUDO devices and are not covered by this FAQ.
  • For more details about different options and use-cases for the cache handling by the debugger, please refer to the paragraph "Accessing Cached Memory Areas and Cache Inspection" in debugger_tricore.pdf:

TRACE32 shows error "ambiguous symbol", what can I do about it?
Ref: 0406

Each TriCore core of an AURIX chip is equipped with directly attached memories: Program Scratch Pad Ram (PSPR) and Data Scratch Pad Ram (DSPR), accessible by itself via core-local and global addressing, accessible by other cores via global addressing.

When accessing its own memory, accessing via global addresses has no (!) impact on access speed.

When having different code and therefore different symbols on each core, core-local addressing can easily lead to ambiguous symbols. Imagine a function "foo" at address P:0xC0000100 on core 0 and a completely different function "bar" at address P:0xC0000100 on core 1.

Using global addressing avoids such ambiguities, in the above example "foo" would be at address P:0x70100100 and "bar" at P:0x60100100 .

In general, it is recommended to use global addressing only, avoid core-local-addressing whenever possible. Modify the linker script file in your compiler toolchain.

What Debug Protocol should I use: DAP or JTAG?
Ref: 0495

This FAQ applies to you, if your TriCore chip and your TriCore debug cable support DAP and JTAG.
  • All TriCore debug cables with a grey ribbon cable support DAP and JTAG. TriCore debug cables with a blue ribbon cable only support JTAG. See the "Application Note Debug Cable TriCore" (tricore_app_ocds.pdf) for details.
  • All TriCore AUDO-Future chips (TC1797, TC1767) and newer (TC2xx, TC3xx) support DAP and JTAG. See the Infineon documentation of your TriCore chip for details.
For all target boards, where only one chip is connected to the debug port, DAP is the preferred debug port type. Due to the CRC, the communication is way more robust, and transmission errors can be detected by the chip as well as by the debugger. Also target resets can be detected much more reliable. The protocol overhead does not affect debug performance.

If more than one chip is connected to the debug port (so-called daisy-chaning), JTAG is mandatory. Please note that in this case, only one TriCore chip is allowed in the chain, and the TriCore chip must be the first device in the chain. Contact Lauterbach support to avoid creating a system that is bricked by design.

When the CPU has halted the debugger shows "stopped by swevt" or "stopped by tr0evt".
Ref: 0283

The message in the status bar reflects the current state of the CPU, and probably why it has reached this state.
  • stopped
    The CPU has stopped because the user issued the Break command.
  • stopped by breakpoint
    The CPU has stopped because of a breakpoint condition (software or on-chip), and the breakpoint condition was set up via the debugger (e.g. Break.Set command).
  • stopped by XXXevt
    The TriCore CPU has stopped due to an event not triggered by the debugger. It shows the reason reported in the Debug Status Register, where XXXevt can be
    • swevt
      software event, the CPU has executed a debug or debug16 instruction
    • extevt
      external event, e.g. event on nBRKIN line via the JTAG cable
    • crevt
      access to a Core Special Function Register (SFR) (feature not used by debugger)
    • tr0evt or tr1evt
      Memory Protection event, normally used by on-chip breakpoints
  • stopped by unknown
    An unknown event has occured, the CPU is probably in some undefined state.

When using Target Based Flash Programming, the debugger shows "stopped by swevt" after each flash programming or erase action.

When using on-chip breakpoints, the Memory Protection Registers are overwritten.
Ref: 0198

Up to core version 1.3.1 the TriCore architecture intends using the Memory Protection Registers for implementing on-chip breakpoints. This means that you can not have on-chip breakpoints and memory protection at the same time. When debugging, the Memory Protection is normally not needed and should be disabled. You may want to configure your RTOS to do this automatically when a debugger is detected.

Use "SYStem.Option STEPSOFT ON" for debugging your Memory Protection Unit. With some additional configuration, this is also possible from FLASH memory. Make sure to set only software-breakpoints, e.g. by setting "Break.IMPLementation Program SOFT". Additionally, on TC v1.3.1 devices, you might want to set "SYStem.Option BREAKFIX OFF".

Which signal is connected to the TRIG pin (pin 18) of the TriCore AGBT trace converter?
Ref: 0568

Both TriCore AGBT trace converters (LA-3829 for Serial Trace Preprocessor and LA-3556 for Power Trace Serial) are routing the WDTDIS/OCDSE signal from the debug connectors to the TRIG pin.

Then the debugger can e.g. use this to disable an external watchdog via the command:

For more details please refer to the following paragraphs in the document Application Note Debug Cable TriCore.
  • Controlling an External Watchdog
  • Converter 16-pin OCDS-L1/ 40-pin HSSTP to ERF8 for TriCore
  • Converter OCDS-L1/ AUTO26/ PowerTrace Serial to ERF8 for TriCore

Why does the TriCore chip show that an SMU alarm was raised?
Ref: 0433

If the SMU is set up strict, some debugger accesses might cause an SMU Alarm (SRI bus error), because the chip can not differentiate between illegal and debugger accesses.

Usually this is caused when the debugger tries to set software breakpoints on a flash memory region. Use the command MAP.BOnchip <addressrange> to force the debugger to set onchip breakpoints in the respective memory region.

To prevent all debugger accesses to a certain memory region, the command MAP.DenyAccess <addressrange> can be used.

Copyright © 2022 Lauterbach GmbH, Altlaufstr.40, 85635 Höhenkirchen-Siegertsbrunn, Germany   Impressum     Privacy Policy
The information presented is intended to give overview information only.
Changes and technical enhancements or modifications can be made without notice. Report Errors
Last generated/modified: 30-Sep-2022