OCD 68HCS12

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

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        Reset        5

3.3        Advanced Options        6

3.4        Clock options        8

3.5        Memory Expansion Options        10

4        Download        11

5        Real-Time Memory Access        16

6        PLL Use        16

7        COP Use        17

8        Secure & Unsecure FLASH        19

9        Hot Attach        20

10        On-Chip Trace        21

11        Getting Started        25

12        Troubleshooting        29

12.1        Clock settings        29

12.2        STOP Instruction – Not supported        29

12.3        Flags cleared on read access of the Watch / SFR window        29

12.4        Checksum and software breakpoints        30

12.5        Target Vcc Debug I/O level        30

12.6        Verify errors on S12G        30

12.7        Design guidelines for the BDM debug signals        30


11Introduction

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

Since BDM control logic does not reside in the CPU core, BDM hardware commands can be executed while the CPU is operating normally. The control logic generally uses CPU dead cycles to execute these commands, but can steal cycles from the CPU when necessary. Other BDM commands are firmware based, and require the CPU to be in active background mode for execution. While BDM is active, the CPU executes a firmware program located in a small on-chip ROM that is available in the standard 64-Kbyte memory map only while BDM is active.

To stop the CPU after reset, BDM must be enabled (first phase) and activated (second phase).

After reset, the BDM is neither enabled nor active, except when CPU is started in the special single-chip mode. The debugger enables and activates it when necessary. In special single-chip mode, BDM is enabled and active immediately after reset.

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.

BDM is mainly used as a low cost debugging solution or alternatively for FLASH programming

When the user’s program is stopped, the CPU enters and operates in the BDM mode. Note that internal peripheral timers, previously active in the user’s program, remain active after the BDM mode is entered. However, interrupts are disabled when BDM mode is entered.

Debug Features:

Two hardware breakpoints

Unlimited software breakpoints

Real-time access

Fast flash programming

Hot Attach

COP Support

PLL Support

Secure & Unsecure Flash

On-Chip Trace

12Emulation Options

12.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 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 BDM signals. The user must ensure that the target power supply is connected to the Vref pin on the target BDM 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.

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!



12.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 for initialization sequence in case of a single chip application/CPU.

13CPU Setup

13.1General Options

CPU Setup dialog, Options menu

Interrupts Enabled When Stopped

On-chip debug module itself doesn’t support servicing interrupts while the application is stopped (interrupts in background). Setting of this option impacts only on the CPU behaviour during single step.

Disabling this option makes the Emulator mask the interrupts between the debug step command, which normally results in more predictive behaviour of applications using interrupts. This is a default setting.

If this option is enabled, the Emulator doesn’t mask interrupts and they can occur 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 disable 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.

13.2Reset

CPU Setup dialog, Reset menu

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!


13.3Advanced Options

HCS12 Advanced CPU Options

Breakpoints

Hardware Breakpoints

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

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

Software Breakpoints

Available hardware breakpoints often prove to be insufficient. Then the debugger can use unlimited software breakpoints to work around this limitation. Note that the debugger features unlimited software breakpoints in the CPU internal flash too.

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.

Using flash software breakpoints

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.

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.

Additionally, the CPU can operate in single chip and expanded mode. Refer to the CPU datasheet for more details on CPU operating modes.

In special single chip mode, the on-chip BDM firmware is active immediately out of the reset. The CPU is stopped immediately after reset and the debugger has complete control over the CPU.

IN ANY OTHER MODE THAN SPECIAL SINGLE CHIP, the on-chip BDM firmware is not active out of the reset and the CPU cannot be stopped immediately. After releasing the reset line, the CPU starts to execute the program and in the meantime, the debugger synchronizes with on-chip BDM firmware, activates and enables it, stops the CPU and gains control over the CPU.

Now, the problem pops up when the flash is empty or contains the program not being operational. In such case, the CPU may hang already while the debugger synchronizes with the on-chip BDM and tries to gain the control over the CPU. If the CPU hangs, the debug connection cannot be established.

In such case, the only alternative is to program the flash using special single chip mode in which the debugger controls the CPU immediately after reset. After the flash contains a valid program, Normal mode can be used.

It’s recommended to check ‘Execute software reset after hardware reset’ option in the CPU Setup dialog in all operating modes, except in special single-chip mode. When the option is checked, the CPU starts executing the code and after approx. 500us after reset is released, a BDM communication is established, CPU stopped, reset vector read and program counter preset to that address.

Reset

These options control the CPU behavior after RESET. This is necessary because the CPU cannot be stopped immediately after reset, except for special single chip mode. The CPU runs for approximately 500 μs before the Emulator can enable BDM communication and issue a stop command.

'Execute software reset after hardware reset' option stops the CPU, reads the reset vector from the memory and presets CPU program counter to that address. Since the CPU runs for 500 μs before the debugger can stop it, this reset is not equivalent to a regular hardware reset. Whether this option is safe to use it depends on the target application. Note that it makes no sense to use this option in special single chip mode since BDM is active immediately after reset and the CPU can be stopped at reset program counter.

'Stop execution after reset to set breakpoints and resume' option is available if the above option is not checked. You will want to use this option to allow the debugger to set breakpoints (software or hardware), for which the CPU must be stopped. The internal breakpoint logic resets on every hardware reset and therefore the breakpoints must be written again.

Use COP

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

Allow Modification

The modifications to FLASH memory are allowed when this option is checked. The option must be checked when the user wants to use software breakpoints in the internal flash or to modify the internal flash through the memory window.

Erase protected areas

If this option is selected, also the protected areas in the FLASH will be erased.

13.4Clock options

Note: Clock tab within the ‘CPU Setup’ dialog is not displayed when MC9S12P iCARD is selected since these settings are irrelevant for the MC9S12P devices.

Clock options menu

Use this clock after RESET

The CPU clock must be specified here to allow BDM communication synchronization.

Use fixed BDM clock frequency

When this option is checked, the CPU is configured not to change BDM clock when PLL is engaged.

Use this clock after CPU is set to running

If the PLL is engaged, BDM clock frequency is changed too. In order to keep the BDM communication synchronized with system clock, new clock (after the PLL is enabled) must be defined here, which will be used by the debugger after the CPU is set to running. See PLL Use chapter for more details on how to use this option.

The user can alternatively use ‘Use fixed BDM clock frequency’ option which yields more predictable debug behavior but results in debug performance not as good as when the BDM clock is equal to the PLL clock.

Keep this option unchecked if the PLL is not used.

Wait for application to configure PLL

Specifies the time to wait for the application to configure PLL in seconds before the second (running) clock is applied.

PLL Setting during download

The debugger can preset PLL to maximum CPU frequency just before the debug download respectively flash programming starts. This will increase the flash programming speed.

To speed up the BDM communication, the PLL settings can be set to Fast, if a PLL filter is present in the target. If there are problems with the automatic algorithm calculating the REFDV and SYNR values, those two values can be inserted manually by checking the Custom option. For more information about REFDV and SYNR values, please refer to the CPU datasheet.

13.5Memory Expansion Options

Enabled

Check this option in case of a banked application.


14Download

Internal FLASH

In case of HCS12P and HCS12S series, devices are programmed through the standard debug download while other devices are programmed through the ‘FLASH Program’ dialog.

Programming through debug download (HCS12P & HCS12S only)

A code residing in the internal flash is downloaded using a standard debug download. There is no need to invoke the flash programming dialog, which is the case for other HCS12 devices. The debugger takes care of the entire CPU configuration to program the file in the flash on Download debug command.

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.


winIDEA expects bank addresses in the download file by default. It’s recommended that the project is compiled in a way that the download file contains bank addresses.

If that's not possible and the file contains for instance linear addresses, the user must force linear memory space by selecting ‘Linear’ in the ‘Memory area’ combo box when specifying the download file.

The 'Enabled' option in the Hardware/Emulation Options/CPU Setup/Memory Expansion’ tab must be checked if the code is linked for a bank application. Uncheck the option, if it’s a non-bank project.

Programming through the ‘FLASH Program’ dialog

Code residing in the internal flash is programmed through the ‘FLASH Program’ dialog, which is invoked through the ‘FLASH/Program…’ menu.

The debugger expects bank addresses in the download file by default. It’s recommended that the project is compiled in a way that the download file contains bank addresses.

If that's not possible and the file contains, for instance, linear addresses, the user must force linear memory space by selecting ‘Linear’ in the ‘Memory area’ combo box when specifying the download file.

The 'Enabled' option in the Hardware/Emulation Options/CPU Setup/Memory Expansion’ tab must be checked if the code is linked for a bank application. It must be unchecked, if it’s a non-bank project.

Few parameters must be set in the ‘FLASH/FLASH Programming Setup’ dialog (FLASH/Setup…) before the internal flash can be actually programmed.

When the CPU internal flash is programmed, winIDEA takes care of most of the necessary settings. Don’t check ‘Verify on the fly’ option since this functionality cannot be supported on this CPU family.

Next, flash programming type must be selected. WinIDEA supports flash programming through the debug BDM port and fast FLASH monitor. Press ‘Hardware Setup…’ button in the ‘Target’ tab in the ‘FLASH Programming Setup’ dialog for the selection.

Normally, the user should go straight for fast FLASH monitor use. Programming through the BDM port is much slower and recommended to be used when troubleshooting flash programming.

When programming the flash through the monitor, make sure you don't relocate the internal CPU RAM. The debugger assumes default reset RAM location and allocates flash programming monitor adequately.

Flash programming through FLASH monitor can be additionally sped up by using on-chip PLL. Programming the code into the internal flash is actually executed by the CPU, executing a special flash programming monitor in the internal CPU RAM. Thereby, flash programming monitor execution depends on the system CPU clock. If the ‘Use fast PLL setting during download’ option in the ‘Hardware/Emulation Options/CPU Setup/Clock’ tab is checked, the debugger presets PLL to the maximum CPU clock and then programs the flash. After the flash programming is completed, the debugger resets the CPU to put the CPU back in the reset state.

If presetting PLL to the maximum CPU frequency fails, the debugger programs the flash at CPU default frequency without warning the user. PLL may fail to lock at maximum CPU frequency due to the target PLL loop filter not being present or simply not designed for the maximum CPU frequency.

A file or more files to be programmed can be selected in the ‘Download files’ tab within the ‘FLASH Programming Setup’ dialog. The alternative is to specify file(s) in the ‘Debug/Files for Download/Download files’ tab, where normally files for debug download are specified. Make sure that ‘Use Debug download files’ option (‘Target’ tab in the ‘FLASH Programming Setup’ dialog) is checked then. In first case, the option must be unchecked.

‘FLASH Program’ dialog should be invoked from the ‘FLASH’ menu after the flash programming is configured in the ‘FLASH Programming Setup’ dialog.


Normally, check boxes beside Load Files, Erase, Program and Verify buttons should be checked. Flash programming is started by pressing ‘Start’ button. During the flash programming, a status and eventual errors are displayed in the dialog.

The debugger can program the flash automatically before the download without any need for opening the ‘FLASH Program’ dialog by the user. Then ‘before download’ in the ‘Auto program FLASH’ combo box must be selected.


Internal RAM

Code, residing in the internal RAM, EEPROM or in the target RAM, must be downloaded using a so called Target Download. First, add files to be loaded in the ‘Target Download’ tab.

Next, select ‘Target download files’ selection in the ‘Target Download’ combo box. Now, Download debug command downloads all listed files.


Internal EEPROM

If the user needs to download certain data to the EEPROM memory in the download phase, the following must be done:

1) 'target download' must be used;

2) the ECLKDIV register must be set using the initialization sequence;

3) if the whole EEPROM is required, the EEPROM area must be relocated with the initialization sequence (by writing to the INITEE register). This is needed, because on some CPUs the EEPROM area is covered with the I/O area. Don't forget to set a proper offset for the download file when relocating EEPROM memory area.

4) The EEPROM writes must not be disabled.

15Real-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 the Software User's Guide for more information on Real-Time watches.

16PLL Use

After the PLL is activated, the CPU system clock changes and consequently the BDM clock. The debugger must synchronize to a new frequency, otherwise BDM communication falls out. Reset and PLL operating frequency must be entered in the ‘Clock’ tab in the ‘CPU Setup’ dialog.

After reset, the debugger connects to the on-chip BDM at ‘reset frequency’. There are less startup problems when using special single chip mode since the CPU stops immediately after reset. With any other CPU operating mode, a small portion of the program is executed before the CPU can be stopped after reset. This portion of the program must not initialize and engage the PLL yet or the debugger will fail to establish the control over the application.

Use special single chip mode whenever it’s possible. In any other mode, the user must assure that the PLL is not enabled within first 500μs of program execution. In worst case, the user must add a delay in his program to meet this requirement.

When the CPU is stopped after reset, the user can use step debug command to step through the program up to the PLL initialization routine since the debugger keeps using ‘reset frequency’. It’s dissuaded to step through the PLL initialization routine.

As soon as the CPU is set into running for the first time (this excludes source and code single step), the debugger will use the ‘operating frequency’ to communicate with the on-chip BDM. It’s recommended that the PLL is engaged shortly after the application resumes, which is normally the case. However, if that’s not the case, make sure that the application is not stopped before the PLL is engaged and the debugger is configured adequately. The user needs to estimate the time between the point when the program is resumed and when the PLL is actually engaged in the application and then enter it in seconds in the ‘Wait for application to configure PLL’ field.

Tip: Use ‘After download run until’ option in the ‘Debug/Files for download/Download Options’ tab and define the source line located after the PLL initialization routine. By doing so, you won’t need to worry about the PLL any longer since the debugger will already use new PLL clock when it stops.

Troubleshooting

First, check the PLL filter Make sure it’s implemented and has proper values. Note that PLL loop filter values depend on the reset and operating frequency.

17COP Use

Do note that in case of the MC9S12DP256 CPU, mask 0K79X or newer must be used when using COP.

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 expected to be serviced properly by the application.

When the debugger stops the CPU for the first time after reset (system initialization), a specific CPU register (COPCTL) must be written properly to enable COP support during debugging. When the user’s program is stopped during the debugging, the CPU enters BDM mode in which the COP timer must be stopped.

‘RESET From Target Enabled’ option in the ‘CPU Setup/Options’ 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.

Normal mode

In normal mode, COP is disabled after reset. Additionally, the CPU cannot be stopped immediately after reset. The CPU executes the user’s program for approximately 500μs before it can be stopped by the debugger, which then enters in the active BDM mode. After the CPU enters in the active BDM mode for the first time, RSBCK bit in the COPCTL register is set first. The user must enter the COPCTL value used in the application in the ‘Advanced’ dialog.

Do note that the user’s application must not write COPCTL register before the application is stopped for the first time by the debugger. This is necessary due to the reason that the COPCTL is write once register. Therefore, at least within 500us after reset, the application must not write to the COPCTL register or it must write the same value as the debugger (RSBCK=1).

HCS12 Advanced tab in the CPU Setup dialog

Special mode

In special mode, COP is disabled after reset and the CPU can be stopped immediately after reset by the debugger. After the CPU enters in the active BDM mode for the first time, the debugger writes to the COPCTL register. The COPCTL value from the ‘Advanced’ dialog is written and RSBCK bit set. The user must enter the COPCTL value used in the application in the ‘Advanced’ dialog.

Since COPCTL register is write any time in special mode, the application must set RSBCK bit too when writing to the COPCTL register.

18Secure & Unsecure FLASH

HCS12 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’s secured.

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

Flash is secured by pressing the 'Secure FLASH' button after the value of FSEC – FLASH Secure register is specified. After the FLASH is secured, BDM is locked and not operational after the next CPU reset.

HCS12 FLASH locking and unlocking

Do note that in case of the MC9S12DP256 CPU, mask 0K79X or newer must be used when unlocking BDM.

19Hot Attach

HCS12 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!


20On-Chip Trace

On-chip trace is not available on all HCS12 CPUs. MC9S12C32/64/96/128 and MC9S12E64/128/256 microcontrollers have one variation of the on-chip trace while HCS12P and HCS12S microcontrollers have an S12X alike on-chip-trace variation. Please, contact Freescale for complete up to date list.

A small trace buffer has been built onto the chip with the CPU. On-chip trace buffer consists of a 64-stage FIFO, which can store address or data bus information, and a flexible trigger system to decide when to capture bus information and what information to capture. The system does not use any microcontroller pins. Rather, it relies on the background debug system to access debug control registers and to read results out of the 64-stage FIFO.

Using a branch-trace mechanism, the instruction trace feature collects the information to trace program execution. For example, the branch-trace mechanism takes into account how many sequential instructions the processor has executed since the last taken branch or exception. Then the debugging tool can interpolate the instruction trace for sequential instructions from a local image of program memory contents. In this way, the debugging tool can reconstruct the full program flow. Self modifying code cannot be traced due to this concept.

MC9S12C32/64/96/128 and MC9S12E64/128/256

Note: On-chip trace doesn’t support bank applications since the on-chip trace records only 16-bits of the address without higher address bits, which define bank address. This restriction does not apply for HCS12S and HCS12P devices.

HCS12 On-Chip Trace Configuration

Trigger mode
A only

Trigger when condition A matches

A or B (addr)

Trigger when condition A or B matches

A Then B (addr)

Trigger when condition B matches but only after A condition matched.

A and B (Data)

Trigger when configured address, data and access type match within the same bus cycle.

A and Not B (Data)

Trigger when configured address and access type match and data doesn’t match within the same bus cycle.

Anything, record only B (data)

All cycles matching B condition are recorded.

A then record only B (data)

All cycles matching B condition are recorded after A condition has matched.

Inside Range

Trigger occurs when the address falls within a range defined by A and B condition.

Outside Range

Trigger occurs when the address falls outside of a range defined by A and B condition.

Trigger Position

Begin

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.

End

Trace buffer stops recording with the first branch before the trigger event. Additionally, 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.

Capture

Defines the Normal capture (default), the Loop 1 or Detail capture, as per Freescale specifications.

The intent of Loop 1 mode is to prevent the trace buffer from being filled entirely with duplicate information from a tight looping construct such as delays using dbne instruction. It will prevent duplicate entries in the trace buffer resulting from repeated bit-conditional branches.

In the Detail mode, address and data for all cycles except program fetch and free cycles are stored in the trace buffer. This mode is intended to supply additional information on indexed, indirect addressing modes were storing only the destination address would not provide all information required for a user to determine where his code was in error.

MC9S12P & MC9S12S

Trace can record in three modes:

Normal mode records all code fetches when the program fetches

Loop mode records all program fetches except if there are two or more consecutive

Detail mode records 64 data accesses. Each data access is identified by address, data, and access type (RD/WR). It cannot be found out which code caused each data access since no code fetches are recorded.

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 datasheet and there should be no indistinctness on how to set up a trigger after reading the CPU datasheet.


Trace Filter

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

Trace Mode

Defines the Normal capture (default), the Loop 1 or Detail capture, as per Freescale specifications.

In Normal mode, change of flow (COF) addresses will be stored.

Loop 1 mode, similarly to normal mode also stores only COF address information to the trace buffer, it however allows filtering out of redundant information. The intent of Loop 1 mode is to prevent the trace buffer from being filled entirely with duplicate information from a tight looping construct such as delays using dbne instruction or polling loops using BRSET/BRCLR instructions. It will prevent duplicate entries in the trace buffer resulting from repeated bit-conditional branches.

In the Detail mode, address and data for all memory and register accesses is stored in the trace buffer. In the case of XGATE tracing this means that initialization of the R1 register during a vector fetch is not traced. This mode is intended to supply additional information on indexed, indirect addressing modes were storing only the destination address would not provide all information required for a user to determine where his code was in error.

When tracing CPU activity in detail mode, all cycles except those when the CPU is either free or opcode fetch cycle.

Trigger Position

Begin

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.

Middle

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.

End

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.


21Getting 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.

Supply the power 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 ‘On-Chip (BDM, JTAG…)’ debugging type.

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 CPU clock frequency in the ‘Hardware/Emulation Options/CPU/CPU Setup/Clock’ tab that your target uses. Note that the BDM protocol operates synchronously to the CPU clock.

Select ‘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. It’s recommended to keep the default ‘5V’ setting since all existing supported CPUs have 5V tolerant BDM debug signals.

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 in the memory window.

Troubleshooting

If the debug CPU Reset command fails, verify:

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

clock frequency in your target and a frequency specified in winIDEA

physical clock signal

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

reset line of your target

There should be no other reset sources, which could disturb 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.

FLASH Programming

A file that has to be programmed must be added in the ‘Debug/Files for Download/Debug Files’ tab and ‘Use Debug download files’ option checked in the ‘FLASH/Setup…/Target’ tab.

winIDEA expects bank addresses in the download file by default. It’s recommended that the project is compiled in a way that the download file contains bank addresses. If that's not possible and the file contains for instance linear addresses, the user must force linear memory space by selecting ‘Linear’ in the ‘Memory area’ combo box when specifying the download file. Wrong addressing can result in download errors.

The 'Enabled' option in the Hardware/Emulation Options/CPU Setup/Memory Expansion’ tab must be checked if the code is linked for a bank application. It must be unchecked, if it’s a non-bank project.

Open ‘FLASH Programming Setup’ dialog from ‘FLASH/Setup…’ menu. Press ‘Hardware Setup…’ button in the ‘Target’ tab and select programming through flash monitor.

Open FLASH Program dialog from ‘FLASH/Program…’ menu and press Start button.

Now, the FLASH should be programmed.

Troubleshooting

If FLASH programming fails, verify if:

proper CPU is selected

Hot Attach’ option is unchecked

Try to program another CPU too. It’s possible that FLASH was already programmed more times than specified and it’s unusable.

Debugging

Execute ‘Download’ debug command.

The program should be stopped. Set a breakpoint on main and run the application. It should hit the breakpoint. Next, try to step in the disassembly window first and then in the source window. Next, run the application and then set a breakpoint in the program, which is executed. The program should stop at the breakpoint.

Troubleshooting

If any of the above tests fail, please

Read thoroughly PLL Use chapter when PLL is used.

Read thoroughly COP Use chapter when COP is used.

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.

22Troubleshooting

This section addresses HCS12 specific issues.

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

22.1Clock settings

Make sure that correct clock settings are entered in the CPU settings. If PLL is used, the PLL clock should be entered too. If settings don’t match the actual state of the CPU, debug and other functionalities might fail.

22.2STOP 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.

Note:

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.

22.3Flags cleared on read access of the Watch / SFR window

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.

22.4Checksum and software breakpoints

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

22.5Target Vcc Debug I/O level

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.

22.6Verify errors on S12G

One of the possible reasons is that the code is not properly linked and therefore linear addressing is used. Elf file must have symbols with banked addresses. +page2 option must be enabled, if cv695.exe converter is used.

22.7Design guidelines for the BDM debug signals

Note that there should be no capacitor on 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.