FAQs for TriCore


The embedded tools company

Search FAQs



PDF document ( 60KB / 07-Sep-2016 )


TOP

Breakpoints in Peripherals Modules

Ref: 0170
When setting a read/write breakpoint to a peripheral module the program execution is not stopped.

The comparators used by the on-chip breakpoints only have an effect on non-peripheral address segments.
As a workaround, the breakpoint registers in the LMI Bridge can be programmed manually.

TOP

CPU "stopped by XXXevt"

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

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.

TOP

FLOWERROR when using OCDS-L2 Trace

Ref: 0188
For my TriBoard-TC1766 I have set up my trace configuration correctly, but all I get is FLOWERROR.

On some older TriBoards-TC1766 (below version .300) two trace lines are swapped. Use "SYStem.Option TB1766FIX ON" for correcting this by software.

TOP

Interrupt taken on single-step

Ref: 0398
When single-stepping I always enter the interrupt handler although IMASKASM and IMASKHLL is enabled.

Some devices with a TriCore v1.3.1 core have a silicon issue that an acknowlegded interrupt is always taken, even if interrupts are disabled after acknowlege. This is documented as Errata CPU_TC.115.

Affected devices: TC1167, TC1197, TC1736, TC1767, TC1797 and corresponding Emulation Devices.

Worarkound:
  1. Disable interrupts permanently while single-stepping.
  2. Enable SYStem.Option STEPSOFT (RAM) or SYStem.Option STEPONCHIP (RAM, FLASH). This will not prevent the interrupt from being taken but will execute the interrupt handler silently in background.


Further documentation:
  • Infineon User Documentation for your device
  • Infineon Errata Sheet for your device (CPU_TC.115)
  • TRACE32 Processor Architecture Manual for TriCore, chapters
    • Debugging, Single Stepping
    • Command Reference, SYStem.Option STEPONCHIP
    • Command Reference, SYStem.Option STEPSOFT


TOP

On-chip Breakpoints and Memory Protection

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

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".

TOP

Single Step after SYStem.Mode Attach

Ref: 0173
When switching to SYStem.Mode Attach, the CPU can be stopped and started but breakpoints are not working.

For older TriCore deriviatives (e.g. Rider-D, TC10GP, TC17x5, TC19x0, ...) OCDS can only be enabled at reset. When attaching, the target is running and reset has already been performed.
If you want to use breakpoints and single stepping, you have to pull nBRKIN and nOCDSE to ground at reset.
This does not apply to newer TriCore CPUs such as AUDO-NG, AUDO-FUTURE or newer.

TOP

Single stepping seems to hang

Ref: 0415
Single stepping seems to hang when debugging optimized code.

When stepping through optimized code, TRACE32 sometimes seems not to execute the step correctly, the program counter (PC) remains at the same HLL line for multiple steps. The List window usually shows a drill-down box (a + sign) next to the line number.

This is a result of the compiler settings and compiler output. As a workaround, summarize adjacent blocks of assembler code when loading an application, e.g. with Data.LOAD.Elf my_application.elf /SingleLineAdjacent .
Please see chapter "Debugging Optimized Code" in the TriCore Processor Architecture Manual (debugger_tricore.pdf) for details.

TOP

SMU Alarm is raised

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

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.

TOP

Unable to break TriCore, debugger shows "running (PLL lock wait)".

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

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 withput 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.

TOP

Unable to Erase or Program Flash Memory

Ref: 0190
When using target based flash programming algorithms, flash is not completely erased or programmed.

Target based flash programming algorithms are running on the CPU itself. When the watchdog is not disabled, they are interrupted by the watchdog's reset.
See the flash programming demos how to disable the watchdog manually.

TOP

Unable to do a Step or Go Command (Audo-NG)

Ref: 0189
I have loaded my application into the target, but I can not step or go away from the reset address.

TC11xx and AUDO-NG devices, e.g. TC1766, TC1796, have a silicon bug that prevents the instruction cache from being invalidated when the CPU is halted.
Software breakpoints (which are used by default) use the DEBUG16 instruction to halt the processor and are being replaced in memory by the original instruction when the core is released to running state. Due to the silicon bug, the DEBUG16 instruction is still in the instruction cache at this time and will be executed.
Workarounds:
  • Force the debugger to use on-chip breakpoints by default by defining the whole memory region as ROM/ FLASH: MAP.BOnchip
  • There is a workaround for forcing the instruction cache to be invalidated. Please see the demoscripts for more information. Be sure to put the instruction sequence to an address range not used by your application, otherwise it would run into the DEBUG16 instruction.


TOP

Board does not boot (AURIX)

Ref: 0414
My Infineon TriBoard does not boot and SYStem.Up fails.

Please make sure the Hardware Book Configuration settings are correct. On Infineon TriBoards there is a DIP switch which allows to modify the HWCFG settings.
TC275T-Bstep an later devices usually require DIPSWITCH1 to be off, otherwise the board is not powered correctly (check the voltage LEDs). Please consult the TriBoard Manual or other Infineon documentation for details.

TOP

JTAG communication does not work (AURIX)

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

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.

TOP

TRACE32 shows error ambiguous symbol (AURIX)

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

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.

TOP

TriCore Data Cache (TC10GP)

Ref: 0207
The debugger displays wrong data for internal memory, but the processor behaves correct.

TC10GP and TC11Ix have a data cache (DCACHE within DMI) which is not accessible by the debugger. The debugger shows invalid internal memory instead. This bug only affects the internal memory. The cache from EMU can be bypassed by switching to the uncached memory segment.
As a workarounds, disable the cache.
For TC1110, TC1115 and TC1130 this problem is fixed by flushing the cache.

TOP

TriCore Data Cache (TC11Ix)

Ref: 0207
The debugger displays wrong data for internal memory, but the processor behaves correct.

TC10GP and TC11Ix have a data cache (DCACHE within DMI) which is not accessible by the debugger. The debugger shows invalid internal memory instead. This bug only affects the internal memory. The cache from EMU can be bypassed by switching to the uncached memory segment.
As a workarounds, disable the cache.
For TC1110, TC1115 and TC1130 this problem is fixed by flushing the cache.

TOP

Unable to do a Step or Go Command (TC11XX)

Ref: 0189
I have loaded my application into the target, but I can not step or go away from the reset address.

TC11xx and AUDO-NG devices, e.g. TC1766, TC1796, have a silicon bug that prevents the instruction cache from being invalidated when the CPU is halted.
Software breakpoints (which are used by default) use the DEBUG16 instruction to halt the processor and are being replaced in memory by the original instruction when the core is released to running state. Due to the silicon bug, the DEBUG16 instruction is still in the instruction cache at this time and will be executed.
Workarounds:
  • Force the debugger to use on-chip breakpoints by default by defining the whole memory region as ROM/ FLASH: MAP.BOnchip
  • There is a workaround for forcing the instruction cache to be invalidated. Please see the demoscripts for more information. Be sure to put the instruction sequence to an address range not used by your application, otherwise it would run into the DEBUG16 instruction.





Copyright © 2016 Lauterbach GmbH, Altlaufstr.40, D-85635 Höhenkirchen-Siegertsbrunn, Germany  Impressum
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: 22-Sep-2016