OCD XC166 XC2000

Parent Previous Next

This document is intended to be used together with the CPU reference manual provided by the silicon vendor. This document assumes knowledge of the CPU functionality and the terminology and concepts defined and explained in the CPU reference manual. Basic knowledge of winIDEA is also necessary. This document deals with specifics and advanced details and it is not meant as a basic or introductory text.


Contents        1

1        Introduction        2

2        Emulation options        3

2.1        Hardware Options        3

2.2        Initialization Sequence        4

2.3        Initialization After Download Sequence        4

2.4        JTAG Scan Speed        5

3        CPU Setup        6

3.1        General Options        6

3.2        Debugging Options        7

3.3        Reset Options        8

3.4        Advanced Options        8

4        Real-Time Memory Access        10

5        Access Breakpoints        10

6        Internal FLASH Programming        11

7        Hot Attach        14

8        Trace        15

9        Profiler        18

10        Coverage        18

11        Getting Started        19

12        Troubleshooting        19

12.1        Debugger cannot connect to the CPU        19

12.2        Debug I/O levels JTAG power supply        19

12.3        Flash programming fails        19

12.4        Checksum and software breakpoints        19


The Infineon XC166/XC2000 family based on C166SV2 core includes an innovative debug system, which provides comfortable on-chip debug support (OCDS) to be controlled directly via debug interface pins.

OCDS is used to debug the user software running in the customer’s system environment. The OCDS is controlled by an external debugging device via the debug interface.

All the debug functions are controlled by the debug interface, the OCDS function control and by the debug IO control (called Cerberus), which provide all the functionality necessary to interact between the debug interface (the external debugger) and the internal system including the OCDS controller.

Due to the lack of the trace functionality on standard devices, Infineon offers a special emulation device (XC2000ED), which also features trace with on-chip trace buffer.

Debug Features

On-chip breakpoints

Unlimited software breakpoints

Access breakpoints

Real-time access

Adjustable debug-mode level (interrupts in background)

Fast internal/external flash programming

DAP or JTAG debug interface

Trace, Profiler and Execution Coverage on XC2000ED (emulation device)

15Emulation options

15.1Hardware Options

Emulation options, Hardware pane

Debug I/O levels

The development system can be configured in a way that the debug JTAG signals are driven by the emulator or by the target voltage (Vref).

When 'Vref' Debug I/O level is selected, a voltage applied to the belonging reference voltage pin on the target debug connector is used as a reference voltage for voltage follower, which powers buffers, driving the debug
JTAG signals. The user must ensure that the target power supply is connected to the Vref pin on the target JTAG connector and that it is switched on before the debug session is started. If these two conditions are not meet, it is highly probably that the initial debug connection will fail already. However in some cases it may succeed but then the system will behave abnormal.

Check Vref on startup

This option is available for iC5000 development system only. When checked, the system will check the presence of voltage on the Vref pin on the target debug connector. If no voltage or too low voltage is detected, a warning message is pop up.

Hot Attach

The debugger supports Hot Attach function. This is a function, which enables the emulator to be connected to a working target device and have all debug functions available. See Hot Attach chapter for more details on Hot Attach use.

Note: Hot Attach function cannot be used for any flash programming or code download!

15.2Initialization Sequence

Before the flash programming or download can take place, the user must ensure that the memory is accessible. This is very important since there are many applications using memory resources (e.g. external RAM, external flash), which are not accessible after the CPU reset. In that case, the debugger must execute after the CPU reset a so called initialization sequence, which configures necessary CPU chip selects and then the download or flash programming can actually take place. The user must set up the initialization sequence based on his application. Detailed information may be found in the Initialization Sequence help topic.

Note: Keep the default ‘Specify’ and ‘0’ setting for Address offset within the Initialization tab.

15.3Initialization After Download Sequence

There are rare cases when a different initialization of the CPU is required for debug download and after the debug download. When Initialization After Download is used, typically the ‘Reset CPU after DL/reset commands (invalidates initialization)’ option described in the previous chapter is checked too.

15.4JTAG Scan Speed

JTAG Scan Speed definition

Scan speed

The JTAG chain scanning speed can be set to:

Slow - long delays are introduced in the JTAG scanning to support the slowest devices. JTAG clock frequency varying from 1 kHz to 2000 kHz can be set.

Fast – the JTAG chain is scanned with no delays.

Other scan speed types (not supported for XC166/XC2000 family) can be seen and are automatically forced to Slow.

Slow and Fast JTAG scanning is implemented by means of software toggling the necessary JTAG signals.

In general, Fast mode should be used as a default setting. If Fast mode fails or the debugging is unstable, try Slow mode at different scan frequencies until you find a working setting.

Use – Scan Speed during Initialization

On some systems, slower scan speed must be used during initialization, during which the CPU clock is raised (PLL engaged) and then higher scan speeds can be used in operation. In such case, this option and the appropriate scan speed must be selected.

16CPU Setup

16.1General Options

XC166 Family Debugging Options

Cache downloaded code only (do not load to target)

When this option is checked, the download files will not propagate to the target using standard debug download but the Target download files will.

In cases, where the application is previously programmed in the target or it's programmed through the flash programming dialog, the user may uncheck 'Load code' in the 'Properties' dialog when specifying the debug download file(s). By doing so, the debugger loads only the necessary debug information for high level debugging while it doesn't load any code. However, debug functionalities like ETM and Nexus trace will not work then since an exact code image of the executed code is required as a prerequisite for the correct trace program flow reconstruction. This applies also for the call stack on some CPU platforms. In such applications, 'Load code' option should remain checked and 'Cache downloaded code only (do not load to target)' option checked instead. This will yield in debug information and code image loaded to the debugger but no memory writes will propagate to the target, which otherwise normally load the code to the target.

16.2Debugging Options

XC166 Family Debugging Options

Execution Breakpoints
Hardware Breakpoints

Hardware breakpoints are breakpoints that are already provided by the CPU. The number of hardware breakpoints is limited to four. The advantage is that they function anywhere in the CPU space, which is not the case for software breakpoints, which normally cannot be used in the FLASH memory, non-writeable memory (ROM) or self-modifying code. If the option 'Use hardware breakpoints' is selected, only hardware breakpoints are used for execution breakpoints.

Note that the debugger, when executing source step debug command, uses one breakpoint. Hence, when all available hardware breakpoints are used as execution breakpoints, the debugger may fail to execute debug step. The debugger offers 'Reserve one breakpoint for high-level debugging' option in the Debug/Debug Options/Debugging' tab to circumvent this. By default this option is checked and the user can uncheck it anytime.

Software Breakpoints

Available hardware breakpoints often prove to be insufficient. Then the debugger can use unlimited software breakpoints to work around this limitation.

When a software breakpoint is being used, the program first attempts to modify the source code by placing a break instruction into the code. If setting software breakpoint fails, a hardware breakpoint is used instead.

Note: 'Debug mode level' 17 is taken by default (see ‘Advanced’ tab) when software breakpoints are selected. This prevents stacked breaks.

Set/clear SW BPs before Run

When the option is checked, then a software breakpoint is not set/cleared immediately, but is just remembered. Only when the CPU is set to running are the breakpoints committed. This way several breakpoints can be changed but only one re-FLASH operation takes place. This is especially noticeable in testIDEA operation with many stubs and also during a regular debugging session when several breakpoints are set/cleared within the same flash erase block.

16.3Reset Options

XC166 Family Reset Options

RESET duration

Select the width of the RESET signal pulse.

16.4Advanced Options

XC166 Advanced Emulation Options

Override startup register values

This option overrides the default Instruction Pointer reset value with the value set.

Generate BRK_OUT

Depending on the chosen options, the dedicated BRK_OUT pin is driven on software breakpoints, hardware breakpoints and/or active BRK_IN pin.


XC166/XC2000 device can feature JTAG, DAP or both debug interfaces. JTAG or DAP debug mode must be selected depending on the debug interface used. Additionally, DAP clock must be selected when DAP debug interface is used.

Note: The debugger must be connected to the target DAP connector (10-pin 1.27 mm pitch) when DAP debug mode is selected and to the target JTAG connector (16-pin 2.54mm pitch) when JTAG debug mode is selected.

Debug level

The on-chip OCDS has an associated debug level. The processor rules are:

-The processor enters debug mode only if the OCDS debug mode level is greater than the current task level

-In debug mode, an interrupt or PEC request is accepted only if its level is greater that the current task level and greater or equal than the OCDS debug level.

As an example, a debug level of 10 is able to stop any task running at level 9 and below. Once stopped, any interrupt of level 10 or higher suspends the debug mode and is executed.

If the processor receives an interrupt or PEC request while it is in debug mode and the request priority is greater or equal to the debug level, it is then accepted. The processor will then return to debug mode at the end of the interrupt routine or once the PEC has been done. This feature allows critical routines/PEC (with a high priority) to run even while the debug of low priority routines is taking place.

Thereby, if the user wants to execute some interrupts in background while the user’s program is stopped, the corresponding debug mode level must be set.

Valid values are:

1 to 16:        respectively breaks task level 0 to 15

17:        break all levels from 0 to 15 and hardware traps

By default, debug mode level 17 is set and should not be changed if no interrupts in background needs to be serviced.

Break on BRK_IN

The BRK_IN pin is monitored and the execution is stopped if the BRK_IN pin goes to active.

Suspend when Stopped

This option selects the XC166 peripherals to be suspended whenever the CPU stops.

This option is available only for earlier XC166 CPUs. For CPUs, which don’t have this option available, check if the CPU features any KSCCFG (Kernel State Configuration) register. The debugger configures OCDS (on-chip debug module) in a way that whenever the application is stopped, OCDS suspends peripherals, which are configured for this action. Individual peripheral module(s) can be suspended via SUMCFG bit in the belonging KSCCFG register (for example timer block GPT2 is suspended by configuring the GPT12E_KSCCFG register).  Refer to the specific Microcontroller User Manual for more details.

17Real-Time Memory Access

XC166/XC2000 debug module supports real-time memory access. Watch window’s Rt.Watch panes can be configured to inspect memory with minimum intrusion while the application is running. Optionally, memory and SFR windows can be configured to use real-time access as well.

In general it is not recommended to use real-time access for Special Function Registers (SFRs) window. In reality, real-time access still means stealing some CPU cycles. As long as the number of real-time access requests stays low, this is negligible and doesn't affect the application. However, if you update all SFRs or memory window via real-time access, you may notice different application behavior due to stealing too many CPU cycles.

When a particular special function register needs to be updated in real-time, put it in the real-time watch window (don't forget to enable real-time access in the SFRs window but keep SFRs window closed or open but with SFRs collapsed). This allows observing a special function register in real-time with minimum intrusion on the application.

Using “alternative” monitor access to update a memory location or a memory mapped special function register while the application is running works like this: the application is stopped, the memory is read and then the application is resumed. Hence the impact on real time execution is severe and use monitor access for 'update while running' only if you are aware of the consequences and can work with them.

18Access Breakpoints

XC166/XC2000 Access Breakpoints

Access breakpoints are implemented by programming the hardware trigger generation unit, which consists of two paths. The upper R path is for one range comparison and the lower E path for one equal comparison.

R path can compare a single value, range or outside of range. It can break on:

-Data value (read or write)

-Data address of reads

-Data address of writes

E path can compare one or two values. Single mask is applied to the first value and also to the second when set. 0 bit in the mask ignores according bit in the value (e.g. comparison with mask 0x07 considers only lowest three bits). It can break on:

-Data value (read or write)

-Write address

TASKID (content of the DTIDR register used by advanced real time operating systems to store the task ID of the active task).

When set on address, the CPU will break whenever this address is accessed. Have in mind that typically variables are accessed by the data initialization code in the startup code first. When set on data, it will break whenever the specified value occurs on the CPU data bus.

Access breakpoints are post execution breakpoints, which means that the CPU stops after the access breakpoint event actually occurred. When the application is stopped you need to look few instructions back for the instruction being the root cause of the breakpoint match.

19Internal FLASH Programming

Internal XC166/XC2000 flash programming is configured differently depending on the target device.

Newer devices are programmed through the standard debug download. The debugger recognizes, which code from the download file fits in the internal flash, and programs it during the debug download. In this case, a standard FLASH setup dialog accessible from the FLASH menu is used only for programming external flash devices.

Newer devices, supporting internal flash programming through the regular debug download, are distinguished in the CPU list with additional flash size information, which is separated with “-“ character after the microcontroller name. Flash size information matches with the standard Infineon marking convention. For instance, XC2336B-24 selection stands for Infineon XC2336B device with 192KB flash and XC2336B-40 stands for XC2336B with 320KB flash. Once the newer device is selected, according flash device occurs under the Hardware menu, where the default settings can be modified if required.

For older devices, the microcontroller internal flash is programmed through the external flash programming method. The external flash device has to be selected in the ‘FLASH Programming Setup’ dialog. Next, ‘Infineon’ must be selected for the manufacturer and the exact target CPU type under the Device. A proper flash base offset address must be entered too (typically 0xC00000). Finally, make sure that the file being programmed is linked to the flash address. If not, use file offset when adding such a file.

FLASH Programming Target Setup

FLASH Programming Device Setup

Check 'Only involved sectors' option in the Scope tab because XC166/XC2000 flash doesn't provide mass erase (entire chip) command.

Internal flash programming configuration

Finally, the user must allocate flash programming monitor (‘Hardware Setup’ button in the ‘Target’ tab). It’s recommended to allocate it in the internal program SRAM, which resides at address 0xE0 0000.

FLASH Monitor configuration

20Hot Attach

Infineon XC166/XC2000 debug module support includes a Hot Attach function, which allows the emulator to connect to a working target device and have all debug functions available. As such, it is a very convenient troubleshooting tool when the application misbehaves after a longer time. The user can connect to and inspect such an application after the problem pops-up.


~4K7 ohm pull-up must be added on the TRST JTAG debug line, which keeps the TRST pin high all the time, when the debugger is connected and when not connected.

To hot attach to a running target with no debugger connected:

It is presumed that the debugger is not connected to the target and both emulator and the target powered

Check the ‘Hot attach to target’ option in the ‘Hardware/Emulation Options/Hardware’ tab.

Execute Download debug command.

Connect the JTAG debug cable to the target system

Select the 'Attach' debug command in the ‘Debug’ menu to attach to the target system.

Now, the debugger should display run status and the application can be stopped and debugged.

Select 'Detach' debug command in the ‘Debug’ menu to disconnect from the target application. If the CPU was stopped before detach, it will be set to running.


Refer to winIDEA Contents Help, Analyzer Window section (or alternatively to the standalone Analyzer.pdf document) for general information on Trace user interface and use.

Per default, XC2000 target processors don’t provide debug trace functionality, which is often necessary during the development and test process. As an alternative, Infineon offers XC2000ED emulation device, which features Nexus compliant on-chip trace (MCDS) in conjunction with the standard OCDS debug module, which is controlled by the external tool through the JTAG or DAP debug interface. The emulation device is mounted on a small piggyback, which then connects to the target, replacing the original target microcontroller. The external development tool is connected to either DAP or JTAG debug connector in the target.

XC2000ED trace features:

PTU - Program Trace Unit

DTU – Data Trace Unit

OTU – Ownership Trace  (meant as ‘Task ID’ or ‘Process ID’ trace)


Internally, MCDS and TMEM block are the most important blocks of the XC2000ED trace.

Trace Memory (TMEM)

TMEM is a 4kBytes on-chip trace buffer, which stores the trace messages coming out of the trace unit. Valid data in the buffer is uploaded by the external debugger, which then reconstructs the original program flow.

In case of program trace, TMEM stores only information of non-sequential instructions being executed. All sequential instructions between the non-sequential instructions are reconstructed by the debugger exploiting code image information extracted from the debug download file(s). The trace concept does not allow tracing of the self-modifying code. An example of self-modifying code would be a boot-loader, which copies some code in the internal RAM, where it’s then executed. This code cannot be traced as long as its image is not part of the debug download file.

Note: Only the code included in the download files can be traced.

No considerable compression is possible for Data and Ownership trace due to the nature of the data, which needs to be captured. Depending on the traffic of the Data and Ownership messages, the trace buffer can run out relatively quickly. To get the most out the trace memory, Infineon implemented complex qualification and trigger units, which allows to capture respectively filter only the information of interest. It’s up to the user to set up an optimal filter in order to capture only the important information out of the vast amount of information, which PTU, DTU and OTU provide.

Multi-Core Debug Solution (MCDS)

Major blocks of the MCDS are:

oProgram Trace Unit (PTU)

oData Trace Unit (DTU)

oOwnership trace unit (OTU)

oWatch-point Trace Unit (WTU)

oTime Stamp Unit (TSU)

oTrace Qualifier Unit (TQU)

oand the glue logic, which connects everything together


The generic PTU is able to process the instruction pointer of an arbitrary processor core.


The generic DTU is able to process transactions on an arbitrary bus system, consisting of address, data and control information


Ownership is a NEXUS term; it translates to “Task ID” or “Process ID” for most practical purposes. The generic OTU is able to process the ownership information of an arbitrary processor core if implemented in hardware4).


All comparators are implemented inside trace units (PTU, DTU, OTU). To keep the trace units simple, each of them is allowed to produce up to one trace message per clock cycle only. The watch-point trace messages are produced here to resolve the obvious problem of a watch-point and the “normal” trace being requested at the same time.


This block delivers all time information, both for internal use (time tags) and messages (time stamps), to all the other parts of MCDS.


The TQU is the container for all Event and Action Logic. The calculation of the trace qualification signals needed by the trace units (DCU, PTU, DTU, OTU, WTU and TSU) is centralized in a unit of this kind.

Note that a detail explanation of the XC2000ED trace is beyond the scope of this document. Contact your local Infineon representative if you need more details. Due to the complexity of the MCDS block, iSYSTEM tools offer a simple and intuitive Trace Wizard, which makes easy to set up most often trigger and qualifiers (trigger & qualifier on program counter and trigger & qualifier on data.

XC2000ED trace configuration dialog look and feel

iSYSTEM Trace Wizard is invoked in the left bottom corner in the Trigger dialog.

Trace Wizard

Before the trace is used, Cycle duration setting must be set in the ‘Hardware/Analyzer Setup’ dialog. The trace time stamp information is implemented on a CPU tick level only. Therefore, it’s up to the user to find out the CPU cycle duration in his target application and enter that value here. This type of time stamps doesn’t provide accurate trace time information where the microcontroller frequency is not constant during the trace session.

‘Hardware/Analyzer Setup’ dialog


Refer to winIDEA Contents Help, Profiler Concepts section for Profiler theory and background.

Refer to winIDEA Contents Help, Analyzer Window section (or alternatively to the standalone Analyzer.pdf document) for information on Profiler user interface and use.

Note: Profiler is available on XC2000 Emulation Device (XC2000ED) only.


XC2000 development system features a so called off-line coverage. Off-line coverage is entirely based on the trace record. It first uses trace to record the executed code (capture time is limited by the 4kBytes on-chip trace (MCDS) buffer) and then offline executed instructions and source lines are extracted by means of software and the results displayed. Due to limited on-chip trace buffer, it’s impossible to perform infinite coverage on complete application. Only a section of application code can be tested for coverage metrics.

Refer to winIDEA Contents Help, Coverage Concepts section for Coverage theory and background.

Refer to winIDEA Contents Help, Analyzer Window section (or alternatively to the standalone Analyzer.pdf document) for information on Coverage user interface and use.

Note: Coverage is available on XC2000 Emulation Device (XC2000ED) only.

24Getting Started

1)Connect the system

2)Make sure that the target debug connector pinout matches with the one requested by a debug tool. If it doesn’t, make some adaptation to comply with the standard connector otherwise the target or the debug tool may be damaged.

3)Power up the emulator and then power up the target.

4)Execute debug reset

5)The CPU should stop on reset location, either on 0x0 or 0xC00000 depending on the state of EA pin which is sampled after driving the CPU out of reset.

6)Open memory window at internal CPU RAM location(s) and check whether you are able to modify its content.

7)If you passed all 6 steps successfully, the debugger is operational. Now you may add the download file and load the code to the RAM

8)To program the flash or download the code to the RAM, which is not accessible after reset, make sure you use the initialization sequence to enable the access. First, the debugger executes reset, then the initialization sequence and finally the download or flash programming is carried out.


This section addresses XC166 and XC2000 specific issues.

For tips and hints on problems, which are architecture independent refer to the general troubleshooting section.

25.1Debugger cannot connect to the CPU

If the debugger cannot connect to the target microcontroller, try to decrease the debug interface frequency. For the JTAG debug interface try ‘Slow’ JTAG Scan speed and when debugging through the DAP debug interface try with low DAP frequency e.g. 1000 kHz.

25.2Debug I/O levels JTAG power supply

Make sure that the power supply is applied to the target JTAG connector when ‘Vref’ is selected for Debug I/O levels in the Hardware/Emulator Options/Hardware tab, otherwise emulation fails or may behave unpredictably.

25.3Flash programming fails

When flash programming fails, double check that proper device, flash base offset address and flash monitor RAM address are selected in the ‘FLASH/Setup’ dialog.

25.4Checksum and software breakpoints

When performing any kind of checksum, remove all software breakpoints since they may impact the checksum result.

Disclaimer: iSYSTEM assumes no responsibility for any errors which may appear in this document, reserves the right to change devices or specifications detailed herein at any time without notice, and does not make any commitment to update the information herein.

© iSYSTEM. All rights reserved.