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        3

2        Emulation Options        6

2.1        Hardware Options        6

2.2        Initialization Sequence        7

2.3        Initialization After Download Sequence        7

2.4        JTAG Scan Speed        8

3        CPU Setup        9

3.1        General Options        9

3.2        Debugging Options        10

3.3        Reset        11

3.4        Nexus        13

3.5        SoC Advanced        15

3.6        Synchronization        16

3.7        SoC Options        18

3.8        Core Specific options        21

4        Flash        24

4.1        Programming        24

4.2        ECC Corruption        24

5        VLE        25

6        Debugging Multi-Core Application        27

7        eTPU Debug        29

8        SPT Debug        30

8.1        SPT Instruction Jamming        31

8.2        SPT Trace        31

9        Hot Attach        32

10        Real-Time Memory Access        32

11        Programming the OTP memory (TEST, UTEST)        33

12        MMU Support        35

13        Access Breakpoints        37

14        Trace, Profiler and Coverage        38

14.1        Nexus trace        38

14.2        Aurora trace port        38

14.3        Coverage        40

14.4        Profiler        40

15        Getting Started        41

16        Troubleshooting        41

16.1        The debugger cannot connect to the target microcontroller        41

16.2        When running the application it doesn’t reach main function        41

16.3        Access to an unallocated address hangs the microcontroller        42

16.4        Internal watchdog resets the CPU while debugging        42

16.5        MMU TLB Entry for this address not found        42

16.6        SFR access and peripheral module power status        42

16.7        Checksum and software breakpoints        43

16.8        Trace doesn’t work when in SAFE mode        43

16.9        Trace trigger doesn’t work – analyzer remains in WAITING state        43

16.10        Not all code is loaded and the program doesn’t run        43

16.11        Errors in recording when using iTrace GT / PRO        44


This document covers on-chip debugging for Freescale MPC5xxx and ST SPC5x microcontrollers while Nexus trace use is explained in separate documents. Nexus trace is explained separately for microcontrollers with Nexus Class 2+ and Nexus Class 3+ interface. Below table provides an overview of supported microcontrollers and trace related information. Note that the table doesn’t list all supported microcontrollers. Contact iSYSTEM for the up-to-date list of supported devices or check the ‘Supported MCUs’ section at www.isystem.com.




Nexus Level

On Chip Trace Buffer

Nexus MDO size

Nexus double data rate






































3+(Z6), 2+(Z0)

BGA256 emulation device
















2M Leopard
















Andorra 2M























MPC5606S in QFP176 & BGA208 emulation device




































MPC5604B & MPC5607B BGA208 emulation device










3M Bolero


MPC5646C in BGA256 only





MPC5601P MPC5602P














1M Pictus





















Matterhorn ED
















McKinley ED



























Calypso 3M



12/16 on BGA324






Calypso 6M














RaceRunner Ultra







Cobra 55














Rainier ED





































Eiger ED







Chorus 1M







Chorus 1M ED







Chorus 4M







Chorus 4M EMU














Bernina EMU






Nexus level

Real-time memory access

Program Trace

Ownership Trace

Data Trace
















Microcontrollers can feature the full 32-bit Power ISA instruction set as well as the ability to implement variable length encoding (VLE) instructions. For instance, Freescale MPC551x devices are designed to run the variable length encoding (VLE) instructions only, which delivers a high level of code density, significantly reducing memory requirements.  

Basic debugging is based on on-chip debug control logic accessible through the JTAG debug interface while trace, profiler and execution coverage are implemented by using IEEEE-ISTO 5001-2003 Nexus Class 2+ or Class 3+ interface.


Four or eight hardware execution breakpoints – depending on the core type

Unlimited software breakpoints including in the internal CPU flash

Access breakpoints

Real-time memory access

Flash programming

Hot Attach

MMU support

eTPU debugging

On-Chip Nexus Trace (e200, eTPU1, eTPU2, eDMA, FlexRay)


Execution Coverage

36Emulation Options

36.1Hardware Options

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.

Sampling threshold levels (iTRACE PRO/GT only)

Voltage levels of the debug input and output signals are adjusted depending on the setting.

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!

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

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

36.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 MPC5xxx and SPC56 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.

37CPU Setup

37.1General Options

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

MMU aware breakpoints and memory access

If checked, breakpoints are set with physical addresses, memory accesses are performed using virtual/physical mapping.

If the option is cleared, no distinction is made between physical and virtual addresses.

Note: This option is available for MPC55xx devices only.

37.2Debugging Options

PowerPC Family Debugging Options

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.

Allow access to unimplemented registers

When this option is checked, the debugger will allow access to the core registers (SPRs, PMRs, DCRs), which are not directly supported yet by winIDEA SFRs window.

Possible use case would be if the customer finds a core register, which is not listed yet in the SFRs window. By checking this option and addressing this missing core register in the watch window, user gets immediate access to this register before winIDEA fix is provided.

Note that if you try to access unimplemented core registers, the CPU may hang. Therefore, use this option with caution.

Ignore Access errors

When checked, the debugger identifies memory access errors for individual memory location(s). When the option is unchecked, the debugger would declare access error for remaining memory locations once one access error is detected within a memory read block, which is used in the disassembly window or memory window.

Program only modified FLASH sectors

Optionally, when a download is performed into an already programmed device, only the FLASH sectors which have been modified are programmed. This speeds up download times when only small changes are performed.


RESET from target enabled

Beside the debugger, the target can have additional external reset sources, like power-on reset, watchdog circuitry or even reset push-button. In general, it’s recommended to disable all external reset sources in the target, which may disturb the debugger in a way that debug communication is lost and complete system needs to be reinitialized.

It’s recommended that all reset sources are designed as an open drain type. ‘Reset from Target Enabled’ option in the ‘CPU Setup/Options’ tab must be normally checked to assure safer debugging.  Then the debugger can detect any reset source and service it properly.

Since target reset lines are designed as an open drain type, the debugger can detect all resets, even if they have been initiated by hardware other than the emulator itself. In certain applications, though, the requirement to disable this type of checking is required.

To disable reset sources from the target to be detected by the debugger, uncheck the ‘RESET From Target Enabled’ option. In this case, only the emulator will be able to generate a reset and the debugger will ignore all reset sources from the target.

Note: Wrong setting of this option can significantly change the operation of the target!

Stop after target RESET

CPU can be optionally stopped after the CPU reset is detected and handled. If the option is unchecked, the application is resumed upon reset release.


Note: This tab is available only when debugging is performed via iC5000 or iTRACE PRO/GT system. Only configuration options which are relevant to the selected CPU and platform are displayed.

Nexus MDO width

Nexus signals can be located on the alternate CPU pins, which can be configured for different alternate functions.

The MPC5500 devices allow configuring Nexus MDO port either as 4 or 12-bit port. A 12-bit MDO implementation ensures optimum Nexus operation. A 4-bit MDO implementation requires less CPU signals than the 12-bit MDO but the Nexus throughput is decreased, which is a crucial factor for correct trace operation. Note that the trace displays errors when the CPU doesn’t manage to send out complete Nexus messages to the external development system. It’s highly probably that 4-bit MDO port will result in trace errors while 12-bit MDO port will function flawlessly.

MPC551x device can have either 4-bit or 8-bit Nexus MDO port and MPC56xx devices can have either 2-bit or 4-bit Nexus MDO port.

The debugger displays available Nexus MDO width based on selected CPU. See also overview table on page 2 for available MDO width for different microcontrollers.

In general the user should opt for wider Nexus port since it provides maximum bandwidth of the Nexus interface. When the target implements only the lower Nexus MDO count of the two possible, the system will be more prone to Nexus overflows.

Nexus clock divider

This selection directly affects Nexus clock.

1:1 selection yields maximum Nexus clock. However, typically when the CPU clock goes over 100MHz, 1:2 selection must be used in order to reduce the Nexus clock frequency. Note that Nexus signals are typically located on CPU I/O pins as an alternate operation. Output drivers of the I/O ports are typically designed for frequencies below 100MHz, which means they are not capable of driving Nexus signals at e.g. 128MHz. For this reason, Nexus clock is controlled over the Nexus clock divider in order not to exceed the maximum frequency of the physical Nexus ports.
For example, let’s take a look MPC5643L device. As long as the CPU runs at 64MHz, 1:1 Nexus clock divider will work. When the same CPU runs at 128MHz, 1:2 Nexus clock divider must be used. However, this also halves the Nexus port bandwidth that is the amount of information which can be broadcasted over the Nexus port. Nexus overflows will occur when the nexus port bandwidth is exceeded.

Therefore, per default the divider should be 1:1 and it should be set to1:2 only when otherwise Nexus clock would exceed the maximum frequency of the Nexus port.

Note: Refer to the CPU’s Reference Manual / AC Specifications / PAD AC Specifications for maximum port frequency of a particular device.

Nexus data rate

On some fast CPUs, it is possible to configure CPU to broadcast Nexus messages at double data rate (at every clock edge), which yields double Nexus port bandwidth. This means the Nexus trace will less likely overflow, which happens when the Nexus traffic is higher than the Nexus port bandwidth.

Sampling at

Per default, Nexus signals are sampled at positive edge of the Nexus clock. However, some targets may have delayed Nexus data signals comparing to the Nexus clock to such extent that it might be necessary to sample data on negative edge of the Nexus clock in order to capture valid Nexus information.

Force periodic Nexus SYNC

When there are problems with the trace or profiler (for instance no content is displayed), it is recommended to check this option for test. If the application runs in some loop, which generates no SYNC nexus messages it may happen that the trace decoder cannot reconstruct any absolute CPU address from the recorded Nexus messages. When this option is checked, the debugger periodically inserts extra Nexus SYNC messages, which allow the trace and the profiler to reconstruct absolute CPU address for every such message.

37.5SoC Advanced


Microcontrollers from the MPC57xx series can have two reset signals connected (in the target) to the debug JTAG connector or the debug Aurora connector. Nexus Mictor38 connector has one reset signal only. Beside the default RESET line (JTAG connector - pin 9), optionally “Power on reset” line can be connected (JTAG connector - pin 8) to the target debug connector. When both reset lines are connected and have to be driven by the debugger, select the ‘Power on Reset’ for e200 Reset selection. When ‘RESET’ setting is selected the debugger drives only default RESET line.

Assume Invariant MMU in iTest mode

MMU refresh consumes considerable amount of time, but is required for correct debugging.

isystem.test operations however can be accelerated considerable if MMU configuration is considered to be preserved by a test execution. Per default the option is unchecked.

Override OnCE Parameters

Enable this option to override default OnCE parameters. Changing of OnCE parameters is not necessary and should be only done when instructed to do so by iSYSTEM.

Custom Init RAM Range

When debug session is established winIDEA initializes the minimal supported size of RAM for the applicable family of devices. If your device offers more RAM then enable this option and specify the RAM start address and size. winIDEA will then initialize all RAM in this range. Large RAM ranges may take a while to initialize. Choose fastest possible JTAG communication speed (refer to JTAG Scan Speed chapter for details) to speed up the process.


Note: This tab is available on multi-core devices only (e.g. MPC5646C, MPC5668G).

Check the Enable check box when both cores are required to run synchronously during the debug session. Additionally define which core is a master and which a slave. The slave core will stop when the master core is stopped and it will go into running when the master core resumes the execution.

Below block scheme shows how EVTO (Nexus event out pin) and EVTI (Nexus event in pin) are connected between the two cores on MPC5646C.

Each core can be configured in a way that EVTO is generated when the associated application is stopped (e.g. breakpoint hit) and that the core is stopped at devt2 request.

With below configuration, the secondary core is the master and will stop the primary core whenever it stops.

With next configuration, the primary core is the master and will stop the secondary core whenever it stops.

If both ticks are checked, it means both cores will stop whenever any of the cores is stopped. The same applies for run operation.

Certain multi-core microcontrollers have capability that both cores are master and slave at the same time (e.g. MPC5643L) while others allow each core to be either master or slave only (e.g. MPC5517).

Note: Synchronization and Nexus trace trigger use the same on-chip debug resources (EVTO pin), which means these two functionalities are excluding to each other. Either synchronization or Nexus trace trigger can be used at a time while both cannot be used at the same time.

37.7SoC Options

Low Power Debug

This option is only needed on certain microcontrollers, where debug module is powered off on entry to low power mode. With Low Power Debug option disabled winIDEA will lose debug connection to the MCU when low power mode is entered. To enable normal debug experience Low Power Debug option should be enabled on such microcontrollers, e.g.: MPC551x, MPC560xB, MPC560xP, MPC560xS, MPC567xK, MPC5668x, MPC564xA, MPC564xL, MPC564xR, SPC56EL70, MPC562xA, MPC574xx (Calypso, Calypso 3M).

Low Power Debug option enables the synchronization of entry to low power mode and exit from low power mode with the emulator:

When Run after exiting low power state option is checked, the CPU is put into running after exiting the low power mode. Otherwise, by default the CPU is stopped.

When Stop before entering low power state option is checked, the debugger stops the CPU when the CPU receives a request to enter the low power mode. Under this condition the CPU will enter low power mode as soon as the user resumes the program (e.g. via Run debug command).

If a Display message box option is enabled in the Debug / Hardware Breakpoints / Action settings, winIDEA will notify the user when low power mode is entered or exited (it will show "Enter to low power mode" or "Low power mode exit" respectively). This option is disabled by default.

Nexus / EBI operation (MPC551x only)

MPC551x devices share the same pins between (debug) Nexus port and EBI bus. The user must select how the pins are used in his application. If Nexus operation is selected, external bus can not be used. If EBI operation is selected, Nexus trace is available except that trigger is not available.

On HW breakpoint generate EVTO only (don’t stop). Trace port must be initialized and multi-core synchronization disabled.

This option was introduced for a very specific customer requirement. When hardware execution or access breakpoint hits (watchpoint), it’s reported only on the Nexus EVTO pin while the application is not stopped. Per default this option is unchecked.

Internal RAM

Flash programming is implemented by loading small monitor into the internal CPU SRAM and executing its code hidden from the user. Since the target CPU SRAM features ECC control, it must be initialized before it can be used by the debugger.

Per default, workspace is configured to initialize internal RAM always. This ensures that internal SRAM and flash are writable at any time during the debug session.

When ‘Never’ is selected, the debugger does not initialize the CPU SRAM. This allows analyzing the CPU state after the CPU reset without RAM ECC initialization being performed by the debugger. Note that in this case SRAM and flash are not writable during the debug download or after the debug reset.

A third selection ‘Automatically (FLASH, RAM modification)’ is also available. In this case, the initialization is performed at the moment when the user tries to modify SRAM or program flash (e.g. debug download, write in memory window, etc.).

Note: Before the application can write to the RAM it must perform RAM ECC initialization in the startup code.

MMU for FLASH, internal RAM and SFRs (not recommended)

Under some circumstances the user may use ‘Go To’ address after the debug download or debug CPU reset. In such case, BAM code, which is otherwise executed by the CPU and configures MMU among other things, is skipped and the CPU program counter preset. Consequentially, program counter points to the address range for which the MMU is not configured and the debugger pops up an error “MMU TLB Entry for this address not found. Ensure correct MMU configuration«. To overcome this problem, check the Initialize 'MMU for FLASH, internal RAM and SFRs’ option in order for the debugger to configure the MMU after the CPU reset instead of the BAM code.

Note that when ‘Go To’ address points to VLE code section, ‘Configure MMU for VLE code’ option should be checked too.  Note that some devices support PowerPC instruction set only, some VLE instruction set only and some both instruction sets. Refer to the reference manual of your particular device for supported instruction set(s).

Note: It is not recommended to use ‘Go To’ address after the debug download or the debug CPU reset unless the user is really aware of the consequences skipping the BAM and application startup code. It can easily happen that application being debugged with this option checked will not run in standalone.

Initialize trace port at startup

On some CPUs, certain CPU registers must be configured before Nexus trace can be used.

Allow flash modification only during download

When this option is checked, internal flash can be modified only through the debug download. When unchecked, it can be modified via memory window too.

Before download mass erase

Optionally, user can force mass erase of Program and/or Data flash instead of the default sector erase being used by the debug download.

Allow shadow and test memory programming (not recommended)

When this option is checked, shadow and test memory block may be programmed via debug download or memory window. Make sure you don’t accidentally overwrite censorship or any other vital register which can permanently lock the CPU.

During the debug download and a memory write through the memory window complete shadow flash block is first read then erased and after that modified data is written to flash (read/modify/write). There is no check where the data is written to. Password ,for example, (also invalid!) can be set in this way. Debugging is impossible, if unknown password is written to the shadow block!

Test flash is write-once, therefore it can’t be erased. Make sure to only program the same memory locations once.

‘Hardware/Flash/Mass erase’ command doesn’t erase the shadow block. During the mass erase, shadow block is first read, and then erased and after that a non-user area of shadow block is written back. For instance, on MPC560x non user area consists of 0x200000-0x200007 and 0x203DD0-0x203FFF.

For more information on programming these regions refer to the Programming the OTP memory (TEST, UTEST) chapter.

Use password

This option is available only for certain devices (e.g. Bolero, Leopard, Calypso, Racerunner devices) and allows unlocking the CPU which was previously locked. Some devices are already password protected when new or they may be locked later on by writing a password to specific memory regions.

Note: It is recommended that the CPU goes through the power on reset when applying a new password. On certain devices it has been noticed that when changing the password, the debugger could not attach to the microcontroller with a modified valid password until the target was switched off and on.

Enable this option and enter the 16-bit values combining a valid password to unlock it. If your device is password protected by device manufacturer contact the manufacturer to obtain a valid password.

64-bit passwords might be swapped. If the password is being swapped, the user has to swap lower and higher 32-bit values when entering the password in winIDEA (compared to the password that was written to Shadow / UTEST memory). For example:

Value written to Shadow memory:  0123 4567 89AB CDEF

Swapped value entered to winIDEA: 89AB CDEF 0123 4567

256-bit passwords are always swapped and winIDEA therefore swaps the password by default. In this case enter the value exactly as it was written in the UTEST memory.


Devices with 256-bit passwords can only be unlocked by using Hot Attach functionality, because the CPU needs to be running when the password is provided. Note that regular download is not possible on locked devices (even if valid password is provided), but Target Download can be used instead. For debugging purposes it is advised to disable the password protection, to avoid these limitations.


Nexus Pin Assignment (PINCR)

Certain microcontrollers (e.g. SPC570S50L) can have Nexus signals routed to different physical pins. This routing is configured through the registers, which are not memory mapped and accessible only through the debug interface. User must set value of the PINCR and DCI_CR register according to his specific target application. The debugger will configure these registers when Nexus port is being used. Refer to the microcontroller’s reference manual for more information on Nexus pin assignment.


37.8Core Specific options

Core-specific settings

Equivalent dialog is available for each of the cores supported by the MCU, as these settings may be set differently per-core.

Execution Breakpoints
Hardware Breakpoints

Hardware breakpoints are breakpoints that are already provided by the CPU. The number of hardware breakpoints is limited to four or eight, depending on the core. 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 hardware breakpoints are 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.

The same on-chip debug resources are shared among hardware execution breakpoints, access breakpoints and trace trigger. Consequentially, debug resources used by one debug functionality are not available for the other two debug functionalities. In practice this would mean that no trace trigger can be set for instance on instruction address, when four execution breakpoints are set already.

Software Breakpoints

Available hardware breakpoints often prove to be insufficient. Then the debugger can use unlimited software breakpoints to work around this limitation. The debugger also features unlimited software breakpoints in the MPC5xxx internal flash, which operate slowly comparing to hardware breakpoints due to the relatively large flash sectors.

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.

Stop CPU Activities When Stopped

When this option is checked, peripheral functions like timers are stopped as soon as the application is stopped. However, this works fine only when hardware execution breakpoints are used for debugging. Per default, software execution breakpoints use the BGND instruction and for this instruction this option does not stop the timers. There is an alternative to use the TRAP instruction for software execution breakpoints (CPU Setup/MPC55xx tab) since it stops the timers too but the user must have in mind that the TRAP instruction can be used by the application too. In this case, a user TRAP instruction would stop the timers too. The BGND instruction is reserved exclusively for debugging.

In general, it is recommended that the option is checked in order to have more predictable behavior of the application using the peripheral functions.

Note: This option is not available for all microcontrollers.

Stop TimeBase during step operation

When checked, the debugger disables the TimeBase during the debug step operation. This yields more predictable behavior of the timers and interrupts depending on the timers during debugging.

This option directly controls the TBEN bit in the HID0 register (core register). On some microcontrollers, this bit directly controls all the peripheral clocks already while on some MCUs individual peripheral clock control is additionally controlled via the associated FRZ bit (for example, the FRZ bit in the PITMCR register controls the timers of the Periodic Interrupt Timer (PIT) module when the MPC5643L is in debug mode).

This option is typically used in combination with the ‘Stop CPU Activities When Stopped’ in the ‘CPU Setup/Options’ tab.

Note: This option is not available for all microcontrollers

Stop when released from reset

This option is available when debugging e200z0 core of the MPC5516 device. After power on, the e200z0 core is in reset state and no debug operation can be performed. It’s recommended to check the option when there is a need to debug the e200z0 startup code.

Note: This option is not available for all microcontrollers

Use TRAP instruction for software breakpoints in PowerPC mode

Check the option when the limitation of the default software breakpoint instruction (BGND) is unacceptable for the target application being debugged. See more details on limitation at the ‘Stop CPU Activities When Stopped’ option description (CPU Setup/Options tab).

Use BDM memory access when stopped (MPC553x/555x/556x only)

When checked, the BDM interface will be used to access memory rather than Nexus interface. BDM interface is slower, but it allows caches to remain untouched to view memory. With Nexus access, caches are flushed when CPU is stopped.

eTPU specific options

These options are only available for eTPU cores. The Nexus eTPU Development Interface provides real-time development capabilities for the eTPU system including two engines (one for each eTPU module) and the coherent dual-parameter controller (CDC). Refer to the Nexus Dual eTPU Development Interface chapter in the eTPU Reference Manual for more details on below options.

Stop pin in debug mode

This option controls whether the eTPU engine pins are sampled when any of the eTPU engine enters debug mode. When it’s checked, the pins are not sampled during debug mode or when executing a forced instruction from the microinstruction register.

Stop TCR clocks

This option controls whether the TCR clocks from the eTPU engine stop running when the eTPU enters debug mode.

Halt on twin engine breakpoint (if available)

It controls the action taken on breakpoint occurrences at the twin engine. If the twin engine that is causing a breakpoint exit debug state, the engine shall resume its operation.

Halt on primary core breakpoint

When checked, the eTPU module is stopped when the main e200 core is stopped.

Register access helper location

The shared data memory (SDM) works as data RAM that can be accessed by the device core and up to two eTPU engines. This memory is alternatively referred to as eTPU shared parameter RAM (SPRAM). When any of the eTPU modules is in debug mode, one 32-bit SPRAM location is hidden used by the debugger. Before the eTPU operation is resumed, the debugger restores the used location SPRAM with the original value. The problem arises when one eTPU is stopped (in debug mode) while the other is still running and using exactly the same SPRAM location, which the debugger uses to control the first eTPU. In order to prevent this, the user should use this option and tell the debugger, which SPRAM address is not used by the application and can be freely used for debugging.



Internal program and data flash are programmed through the standard debug download. The debugger identifies which code from the download file fits in the internal flash and programs it during the debug download. Sectors are first erased, and then programmed with values from the download file. Only sectors, which are programmed, are erased.

To speed up the flash programming through the debug download, check the ‘Program only modified Flash sectors’ option in the Hardware/Emulation Options/CPU Setup/Debugging’ dialog.

Mass erase is performed manually via the ‘Hardware/FLASH -> Mass Erase’ command. It erases both, program and data flash.

Internal flash memory can be modified:

through the debug download

via the initialization sequence which is executed before the debug download

anytime on manual request through the target debug download (without resetting the microcontroller once the debug session is active)

through the memory window

through the ‘Hardware/Tools/Memory’ tab

from other scripting (e.g. Python) and programming (e.g. C) languages accessing winIDEA through the isystem.connect interface

A standard FLASH setup dialog accessible from the FLASH menu is used only for programming external flash devices.

Note: The debugger resolves all ECC (Error Correction Code) errors prior to erasing and programming the flash.

38.2ECC Corruption

If ECC of the flash needs to be tested, ECC error can be induced via the Hardware / Tools / Memory dialog.

ECC corruption is realized by overwriting FLASH locations. If this is done indiscriminately, the device can be rendered permanently unusable.

Note: winIDEA does not support inducing ECC errors in SRAM. However, this can be done manually using the CPU’s ECC Error Generation register. Refer to the CPU’s reference manual for more information on this register.


VLE stands for a variable length encoding and is an instruction set enhancement allowing reduced code size footprint. MPC5500 family (e200z1 core) introduces VLE besides a standard 32-bit Power ISA instruction set. Note that there are few MPC5500 devices which do not have VLE (MPC5553 and MPC5554). Check specific CPU reference manual for supported VLE. Second core (e200z0) of the MPC551x has VLE instruction set only.

The debugger supports both instruction sets. Some compilers (e.g. Metrowerks) generate a debug info which allows the debugger to distinguish between the code belonging to one instruction set or to the other. This allows the debugger to color the code differently, so the user evidently sees which instruction set is executed. VLE code is colored purple.

Standard PowerPC instruction set

VLE instruction set

If the debugger cannot automatically recognize which code from the download file is the standard PowerPC or VLE type, the user can manually define the VLE areas in the ‘Debug/Files For Download…/VLE’ tab.

40Debugging Multi-Core Application

When a microcontroller features two or more cores, each core is debugged in an individual winIDEA instance. In order to debug the second (non-primary) core (for example 2nd e200z0 core of the MPC551x), first primary winIDEA instance and workspace is opened, which allows compiling the complete project, downloading the code in the MCU program flash and debugging the primary (main) core.

In order to debug the 2nd core (e200z0H in the below screenshot), new winIDEA instance is opened from the ‘Debug/Core’ menu.

2nd core is debugged more or less in the same way as a primary core. 2nd core winIDEA instance provides all standard debug windows such as disassembly window, memory window, watch window, variable window, source window, trace window, etc.

The application code for 2nd (and any further) core is loaded by the primary winIDEA instance/workspace, which downloads the application code in the MCU internal program flash. Program flash is shared amongst all cores available. 2nd (and any further) core winIDEA instance requires to download only symbols for the specific core being debugged. Don’t forget to specify the necessary download file including debug symbols in each non-primary core winIDEA instance.

As an example, next winIDEA screenshot shows a list of available non-primary cores on a high-end microcontroller, featuring one main core plus 4 additional cores.

Typically, when the microcontroller is released from the reset state, the main core first executes code from the Boot Assistant Module (BAM), which initializes certain modules (e.g. MMU), then reads reset configuration and starts the user code.

Typically, all other non-primary cores are started by the primary core application code. On certain MCUs (Freescale MPC57xx or ST SPC57), other cores can also be started directly by the Boot Assistant Module already, which means they can start running at the same time (out of reset) when main core starts executing the code.

Execution Breakpoints

Typically, the debugger (primary winIDEA instance) downloads the application code in the program flash and stops at program start point. At this point in time, all other cores are still in the reset state. The state could be different if the Boot Assistant Module (where applicable) would start the other non-primary cores directly.

Now, if the user sets execution breakpoint(s) on any non-primary core, these are not applied to the specific core yet since the core is still in reset state and the debugger has no control over its operation yet. For the same reason on-chip breakpoint logic is not operational yet either.  In this stage, the debugger periodically (few times per second) checks the debug status (reset, run, stop, etc.) of each core. As soon as the debugger detects that the non-primary core is being released from the reset state (which happens when main application is being run), it configures the on-chip debug logic and applies the execution breakpoints. This results in a certain delay between the moments when the core exits reset and when the execution breakpoints start acting. Consequentially, certain code on this core is being executed already before the execution breakpoints start acting. Clearly, any execution breakpoint, set in this part of code being executed from reset on only, will not hit.

If such behavior is not desired, the debugger provides, for each non-primary core, an option Stop when released from reset in the Core-specific tabs in the Hardware / Emulation Options / CPU / CPU Setup dialog. When this option is checked, the core will stop immediately after exiting the reset. Check this option, when main focus is debugging the code being executed immediately after reset and not a real-time behavior of the complete target application. For real-time application behavior, this option should not be checked.

Software execution breakpoints are not available on non-primary cores since setting and clearing a software breakpoint means reprogramming (erase-program) the program flash. Any non-primary core could in the meantime, while software execution breakpoint is being applied, try to execute the code from the same flash sector, which would result in the application malfunction.

Debugger still provides software execution breakpoints for the primary (main) core. They can be used when debugging a single core application (either on a single or a multi-core microcontroller). However, as soon as the application runs on multiple cores, software execution breakpoints should not be used to prevent problems mentioned in the previous paragraph.

41eTPU Debug

The Enhanced Timing Processor Unit (eTPU) has its own Nexus class 3 interface, the Nexus Dual eTPU Development Interface (NDEDI).  The Nexus Dual eTPU Development Interface provides real-time development capabilities for the eTPU system including two engines and the coherent dual parameter controller (CDC) in compliance with the IEEE-ISTO 5001-2002 standard. The main development features supported are hardware execution breakpoints, register and memory access, instruction and source step, run/stop control, branch (program) trace, data trace and ownership trace. Combined, these features make the interface for each engine compliant with Class 3 of the IEEE-ISTO 5001-2002 standard.

In order to debug the MPC5500 application, first a main winIDEA workspace window must be open, which allows compiling the complete project, downloading the code in the CPU internal flash and debugging the e200 core, eDMA and FlexRay. In order to debug the eTPU1 or the eTPU2, a new winIDEA session is open for each eTPU being debugged from the ‘Debug/Core’ menu.

In general, eTPU1 and eTPU2 modules are debugged in the same way as an e200 core. Each eTPU module has its own winIDEA instance with standard debug windows as disassembly window, memory window, watch window, source window, trace window, etc. However, note that the code for eTPUs is loaded by the main workspace, which loads the code into the internal flash. eTPU winIDEA session must therefore download only symbols, which are required for high-level eTPU debugging. Don’t forget to specify the necessary download files for each eTPU winIDEA session.

42SPT Debug

In order to start debugging the Signal Processing Toolbox (SPT) open the winIDEA workspace of the main core and establish the debug session. Then open SPT winIDEA instance by selecting Debug / Core / SPT:

Opening SPT winIDEA instance

SPT is different then a typical core handled by winIDEA, therefore the debug experience differs as well. SPT may be in any of the following states:

Status display in winIDEA instance for this core will reflect these states instead of typical statuses (stop, run, halted, reset) in order to provide more clarity to the user. One of the major differences is the STOP state. On other cores this status means that the execution of the user's code is stopped and the core is ready for debug. On SPT, however, this means that a STOP command was used and debugging is not possible. Instead, there is a DEBUG state, which means that the CPU has stopped executing user's code and is ready for debug.

SPT has 4 breakpoints, but they work as post-execution breakpoints.

Note that Run command typically puts the SPT in RUN state, but if there are any breakpoints set, then the SPT will step until the next breakpoint (enter RUN state and then immediately enter DEBUG state). This is done automatically by SPT.

42.1SPT Instruction Jamming

Instructions may be directly filled to the command sequencer. This can be done through isystem.connect API. Following is a python example for SPT instruction jamming:

import isystem.connect as ic

cmgr = ic.ConnectionMgr()


ideCtrl = ic.CIDEController(cmgr)

print(ideCtrl.serviceCall('/IOPEN/HW.Debug.InstructionStuff', 'InstrHex: 04000000000000000000123456789abc'))
#set.immed 0x123456789ABC, WR_0


42.2SPT Trace

In order to trace the SPT trace may be configured through NXMC 2 trigger dialog. Enable Manual Trigger / Recorder configuration in the Analyzer Configuration and then select Configure to set up the trigger.

NXMC 2 trigger tab

These settings are very SPT specific and you must be aware of what crossbar master is selected. Note that NXMC2 can only generate data messages and watchpoints. It can not generate program messages despite that SPT-Sequencer can be selected as a crossbar master.

43Hot Attach

The development system allows attachment to a running target system without affecting its operation. Such operation mode is called Hot Attach.

It’s assumed that there is a running target with no debugger connected. To hot attach:

Check the ‘Hot attach to target’ option in the ‘Hardware/Emulation Options/Hardware’ tab. Note that Vref debug I/O level must not be used. Correct voltage needs to be chosen.

Execute Download debug command, winIDEA will show the ATTACH status.

Connect the 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 if necessary.

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

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

44Real-Time Memory Access

The on-chip debug module supports real-time memory access. Watch window’s Rt.Watch panes can be configured to inspect memory without stalling the CPU. Optionally, memory and SFR windows can be configured to use real-time access as well.

Note: Real-time memory access is not supported on MPC5601D, MPC5602D, MPC5602P and SPC560P40 due to on-chip debug restrictions.

In general it is not recommended to use real-time access for Special Function Registers (SFRs) window. 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.

45Programming the OTP memory (TEST, UTEST)

One-time programmable (OTP) memory is present on MPC56xx (shadow and TEST memory), MPC57xx and SPC58xx (UTEST memory). This memory can only be programmed once; therefore the programing of this memory is disabled by default in order to prevent any accidental writes to these regions. In order to enable programming of the OTP memory, enable the Allow shadow and test memory programming option which is available in Hardware / CPU Options / MPC5xxx dialog:

Hardware / CPU Options / MPC5xxx dialog

These memory regions need to be programmed in 8- or 16-byte memory writes, depending on the selected MCU. Please refer to the MCU's reference manual for details on OTM memory map and configuration details.

Note that programming the OTP region by writing directly to the memory window can potentially lock the device, because the memory writes through the memory window are performed in 1-byte chunks.

Best method to write to the OTP regions is by running a script, which uses isystem.connect API to connect to winIDEA. This is a basic example of such script written in Python:

import isystem.connect as ic

cmgr = ic.ConnectionMgr()

dbgCtrl = ic.CDebugFacade(cmgr)

DCF_START_ADDR = 0x00400400 #make sure it is aligned correctly!

   #make sure the buffer size matches the desired write width!

   outBuffer = ic.VectorBYTE([0x00, 0x00, 0x55, 0xAA, 0x00, 0x10, 0x00, 0xB0, 0x00, 0x00, 0x55, 0xAA, 0x00, 0x10, 0x00, 0xB0])

dbgCtrl.writeMemory(ic.IConnectDebug.fMonitor, 0, DCF_START_ADDR,  len(outBuffer), 1, outBuffer)

   print("Memory write successful.")

except Exception as exMsg:

   print("Memory write not successful: " + str(exMsg))


Make sure that the memory address to which you are writing is correctly aligned (e.g. for 16-byte access, the address needs to be aligned to 16 bytes) and that the size of the output buffer is correct (e.g. 16 bytes for a 16-byte access). As long as these rules are followed, winIDEA will use the appropriate memory access size.

It can happen that you need to program a shorter value to the OTP region (e.g. you need to program an 8-byte value, but the access must be 16-byte). This is not allowed.

In such case a simple workaround is to repeat the same value for upper and lower 8 bytes (as shown in the sample script above).

Hint: If you are unsure that your script is written correctly, you can first make a dummy write to the RAM memory and only after you see that the value is written exactly as you intended, you make a memory write to the OTP memory.

46MMU Support

Normally MMU is initialized by Boot Assistant Module (BAM). After reset the CPU first executes code from BAM, which initializes MMU, then reads reset configuration word and starts running user code.

However, the debugger must initialize MMU when some debug option is used that circumvent BAM to be initialized upon reset (e.g. overriding startup PC using ‘CPU Setup/Advanced’ dialog). The debugger can configure MMU through Initialization sequence use. When no such option is used, the debugger doesn’t need to configure MMU.

Below is an excerpt from the initialization file (.ini), which initializes MPC5554 MMU in case when the program counter is preset (overridden) after the CPU reset.

S "SPR":(270) L 0x10000000

S "SPR":(271) L 0xC0000500

S "SPR":(272) L 0xFFF0000A

S "SPR":(273) L 0xFFF0003F

I 7C0007A4

S "SPR":(270) L  0x10030000

S "SPR":(271) L  0xC0000400

S "SPR":(272) L  0x40000008

S "SPR":(273) L  0x4000003F

I 7C0007A4

S "SPR":(270) L  0x10040000

S "SPR":(271) L  0xC0000500

S "SPR":(272) L  0xC3F00008

S "SPR":(273) L  0xC3F0003F

I 7C0007A4

S "SPR":(270) L  0x10010000

S "SPR":(271) L  0xC0000700

S "SPR":(272) L  0x00000000

S "SPR":(273) L  0x0000003F

I 7C0007A4

S "SPR":(270) L  0x10020000

S "SPR":(271) L  0xC0000700

S "SPR":(272) L  0x20000000

S "SPR":(273) L  0x2000003F

I 7C0007A4

Virtual to physical address mapping of the individual memory pages is displayed in the MMU Table Walk window. The window can be selected from the ‘Debug/MMU Table Walk’ menu for all CPUs with MMU.

A direct entry of a virtual address is possible.

The MMU Table Walk dialog

Exhaustive information on MMU and also certain core related information are displayed through the plugin windows.

For the detailed information on TLBs (Translation Lookaside Buffer), open the MMU inspector window from the Plugins menu. It displays parameters like virtual address, physical address, block size, VLE, Write-through, Guarded, Cacheable, Memory Coherence, etc..

MMU inspector – TLBs display

47Access Breakpoints

The same on-chip debug resources are shared among hardware execution breakpoints, access breakpoints and trace trigger. Consequentially, debug resources used by one debug functionality are not available for the other two debug functionalities. In practice this would mean that no trace trigger can be set for instance on instruction address, when four execution breakpoints are set already.

The debug interface of the MPC5xxx family includes up to eight Instruction Address Comparators (IAC1-8), out of which each can be configured for a specific address or two in pair can be configured for an address range, and two Data Address Comparators (DAC1-2), which can be set to two addresses or one range. The ranges can be specified with the Inside, Outside or Mask combinations or the entire object can be used. Read or write accesses can be differentiated.

On some microcontrollers a data value (DVC1-2) can be set for each of the data address comparators (DAC1-2) and/or a counter (CNT1-2) can be additionally used to count the comparator matches. The breakpoint hits when the counter reaches 0.

Note: Hardware breakpoints dialog above shows maximum amount of possible on-chip debug resources. Some MPC5xxx devices implement only a subset of these resources. Only implemented on-chip debug resources are enabled and can be configured in the dialog depending on the select target CPU.

Refer to the Development Capabilities and Interface section of the respective CPU Reference Manual for more details on access breakpoints debug resources.


Since configuring access breakpoints may require deeper knowledge of the available on-chip debug resources, an easy to use Wizard (button in the left bottom corner) is available, which allows setting up few basic access breakpoints scenarios in few steps. Sometimes it’s also a good starting point for setting up more complex access breakpoints by first configuring basic access breakpoint using Wizard and then adjusting existing or configuring additional fields and options.

48Trace, Profiler and Coverage

MPC5xxx devices provide either:

MDO trace port or Aurora trace port, where Nexus trace information is pushed immediately off-chip to the external debug tool

On-Chip Trace Buffer, where Nexus trace information is stored in a dedicated trace buffer until it’s full and then read through debug interface and uploaded to the PC for further analysis. Only a dedicated emulation devices support this technology.

Devices may support one or several of these trace technologies, availability depends on the chosen MPC5xxx device.

48.1Nexus trace

For more information on Nexus trace, refer to winIDEA Contents Help describing MPC5xxx SPC5x Nexus L2+ trace  and MPC5xxx SPC5x Nexus L3+ trace  in details. Which type/level of Nexus interface implements a specific microcontroller can be found in the microcontroller reference manual. Nexus level for most popular microcontrollers can be also found in the table at the beginning of this document.

Note: All content in this chapter is valid for all three technologies: MDO trace, Aurora trace, On-Chip Trace buffer

48.2Aurora trace port

Some MPC57xx emulation devices provide Aurora trace port (physical interface), which is supported by iSYSTEM iC6000 On-Chip Analyzer including Aurora protocol support.

A high-speed Aurora interface from Xilinx is being used as a trace port on high-end (typically multi-core) microcontrollers, where previous trace port technology could no longer keep up with increased trace data bandwidth requirement. Comparing to the older microcontrollers (e.g. MPC5554), more data has to be broadcasted outside the MCU in the same time slot due to higher operating frequencies and the trace information coming at the same time from multiple cores. Note that a dedicated Aurora debug connector is provided on the target.

Some emulation devices can broadcast on-chip trace information either to a dedicated on-chip trace buffer or to an external debug tool over the Aurora interface.

Select ‘Aurora Trace Port’ in the Hardware / Analyzer Setup dialog for Aurora interface use and select ‘On-chip’ for on-chip trace buffer use.

Aurora specific settings are available in the ‘Aurora’ tab in the ‘Hardware/Emulation Options/CPU/CPU Setup’ dialog. Number of Aurora lanes and a baudrate (speed) can be configured.

Number of lanes – select a maximum number available on your target configuration. This depends on the MPC5xxx device used, but may be additionally limited if only a portion of lanes is physically connected to the Aurora trace port connector on the target board.

Baudrate – select the maximum baudrate available. Aurora works in Gbit/s range, so the target board needs to be carefully designed and manufactured. If any issues arise, lower the baudrate to the value that is acceptable for your target board design.

Hardware / CPU Setup dialog with Aurora settings


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.


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.

49Getting Started

11)Connect the system

12)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.

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

14)Execute debug reset

15)The CPU should stop on location to which the reset vector points

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

17)If you passed all 6 steps successfully, the debugger is operational and you may proceed to download the code in the internal CPU flash.

18)Specify the download in the 'Debug/Files for download/Download files' tab.

19)Execute Debug download, which should download the code in the internal CPU flash.


This section addresses Freescale MPC5xxx and ST STPC56 specific issues.

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

50.1The debugger cannot connect to the target microcontroller

1.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 debug session fails or may behave unpredictably.

2.Try Slow JTAG Scan speed in the Emulation Options dialog.

3.Device may be locked (either factory protected or locked later on by writing to the Shadow / UTEST memory). Refer to Use password option in SoC Options to unlock it. You will need a valid password to unlock the device.

50.2When running the application it doesn’t reach main function

Q: When I run the code after the download, it never reaches the main function. Flash programming doesn’t report any verify error. What could be the problem?

A: Most probably the application remains in the BAM program because specific “startup” parameters were not programmed properly in the internal flash or left in the BAM area from an old (different) application. After the reset, the CPU starts executing a so called BAM (Boot Assist Module) program. Refer to CPU reference manual for more details on BAM. The BAM searches the internal flash memory for a valid reset configuration halfword (RCHW). A valid RCHW is a 16-bit value that contains a fixed 8-bit boot identifier and some configuration bits, which define location of boot code and the boot configuration options. If the BAM program does find a valid RCHW, the watchdog is enabled, the BAM program fetches the reset vector from the address of the BOOT_BLOCK_ADDRESS + 0x4, and branches to the reset boot vector. Check if valid RCHW and valid reset vector are set in user application and programmed through the debug download.

Simple manual Mass erase from ‘Hardware/FLASH/Mass Erase’ before debug download may solve the problem already. Try this first.

50.3Access to an unallocated address hangs the microcontroller

On some MPC56xx microcontrollers, if memory access to an unallocated address is executed, the microcontroller hangs. This state can be exited only by issuing reset. Use debug windows with caution to prevent accidentally accessing such locations.

Use case

Question: Whenever we add the pointer in the watch window and expand the elements in it, and then try to continue debugging, all values get corrupt and in the disassembly we see "Illegal Instructions".  We don’t try to modify the contents of the pointer, we only read it. What is the problem?
Answer: Yes, when the debugger reads from an unallocated memory region (no physical memory there), the CPU resets or the debug interface freezes and a debug reset is required then. It must be avoided reading memory from an unallocated memory region. In this case when ConfigPtr is expanded, some fields, which are read, point to an unallocated memory region. Afterwards you made a debug source step, which made the CPU irresponsive. This can happen if you read from unallocated memory region using the SFR, Memory or Watch window. This phenomenon has been observed on MPC560x, SPC560P and SPC560B devices.

50.4Internal watchdog resets the CPU while debugging

While debugging MPC551x devices, the internal watchdog must be disabled because the watchdog is not stopped when the application is stopped (microcontroller is in the debug mode). In such case, the watchdog could reset the microcontroller while the application is stopped and the debugger would lose the control over it. Set WTE bit in the RCHW (Reset Configuration Halfword) to 0. Write 0x01 to the RCHW instead of 0x05.

50.5MMU TLB Entry for this address not found

If GoTo is used before the MMU is configured, this error will occur. Also, if you preset the PC counter after the CPU reset, MMU might not be configured for the address range to which you preset program counter. Either don’t use ‘Go To’ option and the application will configure MMU accordingly or refer to Initialize ‘MMU for FLASH, internal RAM and SFRs (not recommended)’ option.

50.6SFR access and peripheral module power status

In case of problems when accessing SFRs on MPC56xx devices, check if clock(s) for peripheral modules are switched on.

For instance, for Bolero device with 512KB internal flash, write 0x80808000 to the CGM_SC_DC0 register (address 0xC3FE037C) before accessing any SFR. This switches on clocks for all peripheral modules.

Some devices have more CGM_SC_DCn registers controlling microcontroller peripheral modules. For instance on one ST device, additionally 0x000000FE needs to be written to the ME.RUNPC[0].R in order to make things working. Refer to the microcontroller reference manual of the particular device for more details on how to enable access to the available peripheral modules.

If this is the problem, use the Hardware/Emulation Options/Initialization Sequence to enable access to the peripheral modules and don’t forget to add this write also to the application startup code since the issue is not related to the debugging only. After reset, peripheral modules are powered off to save power. If these peripheral registers are read by the application or the debugger, a bus error is generated and the CPU gets stuck.

50.7Checksum and software breakpoints

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

50.8Trace doesn’t work when in SAFE mode

MPC5675k can sometimes stay in SAFE mode which disables MCKO signal and trace cannot function. As a workaround use the below init sequence which switches CPU from SAFE into DRUN mode:

A RGM_FES W 0x4080

A ME_MCTL L 0x30005AF0

A ME_MCTL L 0x3000A50F

50.9Trace trigger doesn’t work – analyzer remains in WAITING state

EVTO signal is used in winIDEA as a trace trigger. To generate the trigger event (EVTO), it has to be enabled in the trace trigger configuration window:

Additionally, Nexus pins on certain MPC57xx microcontrollers can have different functions. Use PINCR and DCI_CR register to specify which pin on the microcontroller is used for the EVTO0 signal. Refer to the microcontroller’s reference manual for more information on the Nexus pin assignment.

50.10Not all code is loaded and the program doesn’t run

Q: I download the file, which is in Elf/dwarf format. I don’t get any verify errors. However, the code doesn’t run. It seems like not all code was really loaded. What could be the problem?
A: In your particular case, 'Load Code from' in the winIDEA Elf/Dwarf Options dialog (click Properties after specifying the download file) is set to Program Header / Virtual.

As usual, the choice between virtual and physical addresses is compiler and linker configuration dependent. If 'not all code is loaded', the following procedure is advisable:
1. generate map file
2. in winIDEA, Elf properties, select 'Dump Elf header'
3. Compare map file to the PROGRAM HEADERS entries for VIRTADDR and PHYADDR and see which is suitable

In this particular case the PROGRAM HEADERS part looks like this:





  0 LOAD           174       300         0         0       300         5         4

  1 LOAD           474        18       400       400        18         5         4

  2 LOAD           174         0       500       500         0         5         4

  3 LOAD           48C       724       500       500       724         5         4

  4 LOAD           174         0  20000000  20000000         0         7         4

  5 LOAD           174         0  20000400  20000400         0         7         4

  6 LOAD           BB0         4  20000400       C24         4         7         4

  7 LOAD           BB4         0  20000404  20000404       11C         7         4

  8 LOAD           BB4         0  20000520  20000520         0         7         4

  9 LOAD           BB4        18  20000520       C28        18         7         4

As you (should) know, a C/C++ application must initialize global data before entering main. The initialized data segment is copied from ROM to RAM, uninitialized (.bss) is simply zeroed.

On your specific CPU, ROM/FLASH resides on address 0, while RAM resides on address 20000000h. The program headers layout shows a few entries where PHYADDR is different to VIRTADDR. It is obvious that in this configuration the PHYADDR denotes the FLASH load location and VIRTADDR the link location (the address of RAM where variables will be accessed). Since apparently the application is PROMable (i.e. startup code will copy .initdata to .data), we must ensure that the FLASH is loaded with initialized data image and the correct choice is to select "Program Header / Physical"

Note that on average in 70% of cases Program Header / Virtual is the right choice, so winIDEA uses this setting per default.

50.11Errors in recording when using iTrace GT / PRO

Q: I'm using MPC5556 together with iTrace GT and NEXUS-MPC55xx/56xx probe. I get errors during the profiling session.

A: Frist check your settings in Hardware / Emulation Options / Hardware tab. Manually enter the sampling threshold level for the probe:

Emulation Options, Hardware tab

2. Try selecting bigger Nexus divider (e.g. 1:4 instead of 1:2) in Hardware / CPU Options, Nexus tab. Depending on the microcontroller you are using there is a maximum frequency with which the data may be sampled. This typically ranges from 40MHz to 80MHz. Depending on the CPU clock you are using appropriate Nexus divider must be used. Note that a lower Nexus clock could result in trace FIFO overflows. The highest possible Nexus clock (lowest possible Nexus divider) should be used.

3. Check the length of the trace lines on your target board. There may be signal integrity issues. Make sure the MCKO line is terminated properly.

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.