FAQ for OCDS TriCore
Breakpoints in Peripherals Modules CPU "stopped by XXXevt" On-chip Breakpoints and Memory Protection Unable to Erase or Program Flash Memory Unable to do a Step or Go Command (Audo-NG) Single Step after SYStem.Mode Attach (older) TriCore Data Cache (TC10GP) TriCore Data Cache (TC11Ix) Unable to do a Step or Go Command (TC11XX) FLOWERROR when using OCDS-L2 Trace (TC1766) FLOWERROR when using OCDS-L2 Trace (TC1766ED) Single Step after SYStem.Mode Attach (TriCore) home Documents FAQ FAQ for OCDS TriCore PDF document ( 12KB / Jul-14-2008 )

FAQ for OCDS TriCore

Breakpoints in Peripherals Modules
		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 react on read/write accesses via the local memory bus. Peripheral accesses via FPI bus (SPB, RPB) are not detected. As a workaround, the breakpoint registers in the LMI Bridge can be programmed manually.
CPU "stopped by XXXevt"
		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 os probably in some undefined state. When using Target Based Flash Programming, the debugger shows "stopped by swevt" after each flash programming or erase action.
On-chip Breakpoints and Memory Protection
		When using on-chip breakpoints, the Memory Protection Registers are overwritten.
	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.
Unable to Erase or Program Flash Memory
		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.
Unable to do a Step or Go Command (Audo-NG)
		I have loaded my application into the target, but I can not step or go away from the reset address.
	TC11xx, TC1762, TC1764, TC1766 and TC1766ED devices have a silicon bug that prevents the instruction cache from being invalidated when the CPU is being 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.
Single Step after SYStem.Mode Attach (older)
		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.
TriCore Data Cache (TC10GP)
		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.
TriCore Data Cache (TC11Ix)
		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.
Unable to do a Step or Go Command (TC11XX)
		I have loaded my application into the target, but I can not step or go away from the reset address.
	TC11xx, TC1762, TC1764, TC1766 and TC1766ED devices have a silicon bug that prevents the instruction cache from being invalidated when the CPU is being 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.
FLOWERROR when using OCDS-L2 Trace (TC1766)
		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.
FLOWERROR when using OCDS-L2 Trace (TC1766ED)
		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.
Single Step after SYStem.Mode Attach (TriCore)
		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.