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

3        CPU Setup        4

3.1        General Options        4

3.2        Debugging Options        5

3.3        Reset Options        7

3.4        Advanced Options        8

4        Download        9

5        COP Use        9

6        Secure & Unsecure FLASH        10

7        Real-Time Memory Access        11

8        Hot Attach        12

9        Access Breakpoints and On-Chip Trace        12

9.1        On-Chip Trace        14

9.2        Examples        17

10        Getting Started        20

11        Troubleshooting        24


The BDM term stands for Background Debug Mode. It is used for the system development and flash programming. The BDM firmware is implemented on the CPU silicon providing a comprehensive set of debug functionalities.

The BDM control logic communicates with an external development system serially, via the BKGD pin. This single-wire approach minimizes the number of pins needed for the development support.

When the user’s program is stopped, the CPU enters and operates in the BDM mode.  Note that interrupts are disabled when the BDM mode is entered.  Per default, internal peripheral modules, previously active in the user’s program, remain active after the BDM mode is entered. Some peripheral modules feature a software programmable option (typically done in the application startup code) to freeze the module operation whilst the microcontroller is in the BDM mode. Timer modules typically include the freeze feature. Serial interface modules typically do not include freeze feature. Refer to the microcontroller reference manual for more details on how to configure stopping an individual peripheral module in Freeze mode and which peripheral modules have this functionality

Debug Features:

Four hardware breakpoints

Unlimited software breakpoints

Real-time access

Access breakpoints

Fast flash programming

Hot Attach

COP Support

Secure & Unsecure Flash

On-Chip Trace

Note: Devices, such as MC9S12ZVL, which feature S12Z DebugLite module, do not have trace functionality, because it is not implemented on the device. Only three hardware breakpoints are available on such devices.

52Emulation Options

52.1Hardware Options

Emulation options, Hardware pane

Debug I/O levels

The development system can be configured in a way that the debug BDM signals are driven at 3.3V, 5V or target voltage level (Vref).

When 'Vref' Debug I/O level is selected, a voltage from the target debug connector connects to a voltage follower, which then powers debug tool buffers physically driving the BDM signals. The user must ensure that the target power supply is connected to the Vref pin on the target BDM connector and that the target is powered before the debug session is started. If these two conditions are not meet, the initial debug connection will most likely 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. A warning message pops up if no voltage or too low voltage is detected.

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!

52.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: Normally, there is no need to use the initialization sequence with S12Z microcontrollers.

53CPU Setup

53.1General Options

Options tab

Interrupts Enabled When Stopped

The on-chip BDM itself doesn’t support servicing interrupts while the application is stopped (e.g. interrupts in background). This option affects the CPU behavior during single step only.

When the option is unchecked (default), the debugger masks interrupts during Step debug command. This yields more predictable debugging of applications using interrupts.

If this option is checked, the debugger doesn’t mask interrupts and an interrupt can hit while stepping through the application. If there is a periodic interrupt, it may happen that the user will keep re-entering the interrupt while stepping. In such applications, it’s recommended to uncheck this option.

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.

53.2Debugging Options

Debugging tab

Execution Breakpoints
Hardware Breakpoints

Hardware breakpoints are breakpoints that are already provided by the CPU. Four hardware breakpoints are available and they function anywhere in the CPU space, which is not the case for software breakpoints, which typically cannot be used in a non-writeable memory (ROM) or in applications with self-modifying code. When 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 on-chip 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 (including in the internal program flash) 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 set instead.

Using flash software breakpoints

Many memory access operations have to be performed in background (hidden from the user) when setting clearing software breakpoint in the program flash. As this takes certain amount of time, user may notice this as a time lag between certain winIDEA operations.

A flash device has a limited number of programming cycles. Belonging flash sector is erased and programmed every time when a software breakpoint is set or removed. The debugger sets breakpoints hidden from the user also when a source step is executed. In worst case, a flash may become worn out due to intense and long lasting debugging using flash software breakpoints.

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.

53.3Reset Options

Reset tab

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 BDM 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. When the CPU operates in an environment with interferences, it’s recommended to add a capacitor to the target reset line. In order for the CPU to be able to initiate a reset and then to differentiate among the 'internal' and 'external target' reset (the length of less than 8 ECLK cycles), the capacitor must be relatively small. However, the interference can be in some cases so big that a bigger capacitor must be used. In such case, the debugger does not function correctly, if reset from the target is not disabled.

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.

RESET Output

The reset line from the debugger can be driven as an open drain or as push-pull line. Typically, open drain reset signals are used, but in special cases, push-pull signals are preferred.

A special case is, if a large capacitor is located on the reset line because of interference.

Next case is, if the target contains an external watchdog that cannot be disabled. During the debugging phase, it must somehow be disabled. In this case, the watchdog line should be connected to the CPU reset line through a serial resistor (for example 1k). If the emulator’s reset line is connected directly to the CPU reset line and its type is push–pull, then the watchdog can no longer reset the CPU by itself.

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

53.4Advanced Options

Advanced tab

Operating Mode

The debugger can force two CPU operating modes in which the CPU behaves differently:

Normal mode – some registers and bits are protected against accidental changes

Special mode – allows greater access to protected control registers and bits for special purposes such as testing and emulation. The debugger can force the CPU to active BDM mode immediately after reset while CPU operates in the special single-chip mode only.


When using COP, the user must enter the CPMUCOP value used in the application in the ‘Advanced’ dialog. See ‘COP Use’ chapter for more details on COP use.

Erase before download

If this option is checked, the internal flash will be completely erased before every debug download. When the option is not checked, only sectors where downloaded code fits in will be erased and programmed during the debug download.

Use monitor

This option specifies the usage of a FLASH monitor residing in the internal RAM instead of the standard flash programming through the BDM port only. This option must be checked if software breakpoints are used.

Make sure you don't relocate the internal CPU RAM when programming the flash through the monitor. The software assumes default reset RAM location and allocates flash programming monitor accordingly.


Internal flash, EEPROM and RAM are downloaded through the debug download. The debugger takes care of the entire CPU configuration to program the file in the flash and EEPROM.

Add files to be loaded in the internal flash in the ‘Download Files’ tab. Download debug command programs all listed files matching with the flash memory area in the internal flash.

55COP Use

The debugger needs no watchdog awareness while the watchdog is disabled. Following explanation is irrelevant for applications not using COP.

When using COP, it’s assumed that it’s serviced properly by the application.

When the debugger stops the microcontroller for the first time as part of the initial debug connection to the target microcontroller, it must write a proper value to the CPMUCOP register to enable COP support during the debugging. Whenever the application is stopped, the microcontroller enters the BDM mode in which the COP timer must be stopped too.

‘RESET From Target Enabled’ option in the ‘CPU Setup/Reset’ tab must be checked when COP is used in the application. If it’s not checked, the debugger cannot detect any reset source including COP.

If the application uses COP, the ‘Use COP’ option must be checked and COPCTL value from the application must be written in the COPCTL field.

After reset, the debugger writes a value defined in the COPCTL field to the COPCTL register and additionally sets RSBCK bit in the same register. Setting RSBCK bit stops the COP and RTI counters whenever the CPU is in Active BDM mode and thus assures proper operation of COP even when the application is being debugged.

56Secure & Unsecure FLASH

S12Z family features mechanism, which locks BDM if the flash is secured. This mechanism was built into the CPU to prevent memory read over the BDM by unauthorized person and thus protecting the code (intellectual property) in the internal flash.

Secured flash can be unsecured by BDM debugger, which executes special unlocking sequence. Note that FLASH is erased when it’s unsecured. There is no way to read the code from the internal flash after it was secured.

Flash is unsecured by pressing the 'Unsecure FLASH' button in the ‘Hardware/Hardware Tools/S12Z’ tab.

The BDM/FLASH can be locked by pressing the 'Secure FLASH' button. The value of FSEC – FLASH Secure register must be specified. After the FLASH is secured, BDM is locked and unavailable after the next CPU reset.

S12Z Secure/Unsecure FLASH

57Real-Time Memory Access

With this type of CPUs, real-time memory access is available. 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.

Please refer to winIDEA Help for more information on Real-Time watches.

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.

58Hot Attach

MC9S12X BDM allows attachment to a running target system without affecting its operation. Such operation 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.

Execute Download debug command.

Connect the BDM 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 CPU was stopped before detach, it will be set to running.

When running with Hot Attach, make sure that your program sets the RSBCK bit of the COPCTL register if the application is using COP. This way, the COP counter is disabled when the CPU is stopped.

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

59Access Breakpoints and On-Chip Trace

The same on-chip debug resources are shared among hardware execution breakpoints, access breakpoints and on-chip 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.

On-Chip Trace Trigger configuration

Access Breakpoints configuration

Four hardware comparator combinations are available, including an immediate match and a three stage state machine.

59.1On-Chip Trace

The trace buffer organized as FIFO is a 64 lines deep by 64-bits wide RAM array. Data is stored in mode dependent formats, which can record S12Z program execution.

Reconstructed program normally contains over 1000 code instructions, which may sound a lot but it’s really not a lot when comparing to the trace available on high-end in-circuit emulators.

Trace can record in four modes:

Normal mode records change of flow (COF) program counter addresses.

Loop1 mode, similarly to Normal mode also stores COF address information to the trace buffer, it however allows the filtering out of redundant information.

The intent of Loop1 mode is to prevent the trace buffer from being filled entirely with duplicate information from a loop construct such as delays using DBNE instruction. Loop1 mode only inhibits consecutive duplicate source address entries that would typically be stored in most tight looping constructs.

In Detail mode, address and data of data and vector accesses are recorded. This mode is intended to supply additional information on indexed, indirect addressing modes where storing only the destination address would not provide all information required for a user to determine where his code was in error.

In Pure PC mode, the PC addresses of all opcodes loaded into the execution stage, including illegal opcodes, are stored. Tracing from a single source, compression is implemented to increase the effective trace depth.

Pretty complex events (state machine) can be configured for the trigger event. Depending on whether the user needs to look forwards or backwards, the trigger can be located at the beginning, at the end or in the middle of the trace buffer.

Frame 0 in the trace points to the first program change after the trigger event. Thereby, the trigger event itself is forward from the frame 0. Moreover, the trigger event itself may even not be visible in the trace record. For instance, if a trigger is set on a data access and trace records code fetches (normal mode), no data accesses and thus no trigger event are recorded.

Trace configuration dialog entirely follows the trace description in the CPU reference manual and there should be no indistinctness on how to set up a trigger after reading it.

Trace configured to trigger on SendCANMsg execution and to record S12Z activity.

Trace Filter

The settings in this section are used to filter out unwanted results.


Per default it stores S12Z activity.

Trace Mode

Four trace operation modes can be selected:


Loop 1

Detail capture

Pure PC


Specifies a range of data to be recorded in the trace buffer:

All – all data is saved

From 0x000000 to Comparator D – all data from the beginning to the address specified in Comparator D is saved

From Comparator C to 0x7FFFFF– all data from the address specified in Comparator C to 0x7FFFFF is saved

From Comparator C to Comparator D – all data between the addresses specified in Comparator C and Comparator D is saved

Trigger Position


Trace buffer starts recording after the trigger event and continues until 64 locations are filled. Trigger event itself is not visible in the trace record unless the trigger was set on the branch instruction. No program execution before the first branch instruction, being recorded after the trigger event, can be seen in the trace window.


As soon as the trace is started, the trace buffer starts collecting the data. When the trigger condition is met, another 32 lines will be traced before ending the trace session, irrespective of the number of lines stored before the trigger occurred, then the trace buffer is disarmed and no more data is stored. T

The trace buffer requires to be filled with 32 locations before the trigger in order to read the collected information. For example, if the trace buffer doesn’t collect 32 branches before the trigger, no trace results can be displayed. User should make sure that enough code (generating 32 changes of flow) is executed before the trigger in order to use Middle trigger position.


Trace buffer stops recording with the first branch before the trigger event. Additionally, the trace buffer requires to be filled with all 64 locations before the trigger in order to read the collected information. For example, if the trace buffer doesn’t collect 64 branches before the trigger, no trace results can be displayed. User should make sure that enough code (generating 64 branch addresses) is executed before the trigger in order to use End trigger position. Note also that the trigger event itself is not visible in the trace record unless the trigger was set on the branch instruction. No program execution can be seen in the trace window after the branch instruction, being lastly filled in the trace buffer before the trigger event.

Time Stamp

Optionally time stamps can be added to trace buffer entries in Normal, Loop1 and Detail trace modes. Time stamps are not available for Pure PC mode.

The time stamp is generated from a 16-bit counter and is stored to the trace buffer each time a trace buffer entry is made.

Each time stamp indicates the number of bus cycles since the last entry.


Trace buffer entries are initiated according to the trace mode specification.

Comp D

Trace buffer entries are initiated on a match of comparator D.


Following examples demonstrate access breakpoints use. The same examples can be applied to the trace configuration since trigger and access breakpoints dialog are different just in few details.

Example 1: The application should stop when writing to the 0x1020-0x103F address range.

Following access breakpoints configuration will stop the application on first CPU write to the memory address range 0x1020-0x103F. Setting Mask field to 0 ignores the Data bus value.

Example 2: I’m getting an unexpected 0x15 byte written at address 0x101D.

Following access breakpoints configuration will stop the application on first CPU byte write 0x15 to the address 0x101D.

Example 4: I’m getting an unexpected 0x150A word written to the variable wCanACheckStatus.

Below access breakpoints configuration will stop the application on first write 0x150A to the 16-bit variable wCanACheckStatus.

60Getting Started

Quick start instructions help the user to start debugging a single-chip application in a very short time.

Setup and Initialization

Connect the emulator to the PC where winIDEA is installed.

Connect the power supply to the emulator and switch it on.

Select Hardware by selecting ‘Hardware/Hardware…’

Select ‘Communication’ tab within the same dialog and select the communication type that is going to be used.

Refer to ‘Setting up Communication’ document (delivered beside the emulator) for more details on how to configure each of the supported communications.

Execute communication test by pressing ‘Test’ button. There must be no packets with errors reported during the communication test.

Next, switch off the emulator and proceed with the configuration.

Select the CPU family, the iCARD and the CPU in the ‘Hardware/Emulation Options’ dialog.

Make sure that the ‘Hot attach to target’ option is unchecked in the ‘Hardware/Emulation Options/Hardware’ tab.

Set ‘Special Mode’ in the ‘Advanced’ tab for the operating mode.

Select the Debug I/O levels in the ‘Hardware/Emulation Options’ dialog. The development tool can drive debug BDM signals at 5, 3.3V or target Vcc level.

Normally, these are the minimum settings required by the emulator to be able to connect to the target CPU.

Verify if the BDM connector in the target matches with the pinout defined by the CPU vendor. The required connector pinout can be also found in the hardware reference document delivered beside the debug iCARD.

Connect the emulator to the target.

First power on the emulator and then the target! On power off, first the target needs to be switched off and then the emulator. Otherwise damage to the hardware may occur!

Close all debug windows in winIDEA except for the disassembly window.

Execute debug CPU Reset command.

WinIDEA should display STOP status and disassembly window should display the code around the address where the program counter points to. If that’s the case, the debugger is operational. You can inspect special function registers in the SFR window or read and modify (RAM) memory through the memory window.


If the debug CPU Reset command fails already, verify:

BDM cable, target BDM connector pinout and connection with the target

physical clock signal

Measure the EXTAL clock signal with an oscilloscope. It may happen that the crystal doesn’t oscillate.

reset line of your target

There should be no other reset sources, which could interrupt BDM communication. Remove all capacitors and other reset logic from the reset line and try again. Make sure that the ’RESET from target enabled’ option is checked in the ‘CPU Setup/Options’ tab.

Next step is to download the program or more precisely to program the CPU internal flash.


Note that flash programming process is executed during the debug download.

Add files to be downloaded to the flash in the ‘Debug/Files for Download/Debug Files’ tab.

Next, check whether the ‘Use monitor’ and the ‘Erase before download’ options are set in the ‘CPU Setup/Advanced’ dialog.

Execute ‘Download’ debug command.

The debugger should not report any verify errors on verify after the download and the CPU should stop at the address where the reset vector points to.


If download fails, verify

If proper CPU is selected in winIDEA

‘Hot Attach’ option is unchecked in the ‘Hardware/Emulation Options/Hardware’ tab

Debugging S12Z

It’s presumed now that the application is stopped at reset vector. Set an execution breakpoint on main function and run the application. It should hit the breakpoint. After that, try to step in the disassembly window first and then in the source window. Next, run the application and set a breakpoint in certain function which is executed. The program should stop at the breakpoint. At this point in time, debugger is supposed to be operational.


If any of the above steps fails, please

Read thoroughly ‘COP Use’ chapter.

Double-check the BDM connection. Try to press the BDM connector in the target with fingers to establish better connection and to eliminate possible source of the problem.


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

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

Be careful when the CPU has register bits that are cleared on read access. Do note that when such register (memory location) is accessed either by memory/watch window or SFR window, the flags are cleared and the application may behave different when using the emulator or the target CPU. It is recommended not to display such registers or the associated memory location in the memory/watch window during final test. Otherwise, it may happen that the target application doesn't work due to the bug in the code even though it works with the emulator. For instance, the user makes a mistake and does not clear the flag in the application. Using the emulator, the application works correctly since the user uses the SFR window, which clears the flag when the window is updated.

STOP Instruction – Not supported

When stop instruction is used to force the CPU in the standby mode, the BDM ceases to work. When STOP instruction is executed, the CPU enters standby mode and all system clocks are stopped. Consequently, on-chip BDM becomes inactive too and the BDM communication falls out.

STOP instruction is controlled by S bit in the CCR register. The STOP instruction is disabled and operates like the NOP instruction, when the S control bit is set.

Question: What is the common value of the pull-up for the BGND line? Is it good to add a capacitor?
Answer: It is not allowed to add capacitor to the bidirectional open-drain line. There must be no capacitor on the BGND and the RESET line. Target pull-up on the BGND line should have a value between 4k7 and 10k ohms because the debug iCARD has 1k ohms pull-up already.

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.