Overview

In this topic:

•Debug Status

•Debug Session start types

•Establishing a Debug Session

A Debug Session refers the systematic process of gaining control over a microcontroller to debug and analyze its behavior using winIDEA.

This session typically comprises several steps, such as BlueBox initialization, symbol loading, managing reset signals, establishing a connection with the microcontroller, configuring core debug registers, and performing device reset. Additionally, it may involve attaching to a currently running device without disrupting its operation.

The primary use cases, Reset and Download, involve initiating an Active Debug Session, enabling you to:

•Execute a reset or download code to your target device.

•Exercise control over its execution through Run Control commands.

•Navigate through the code systematically by stepping through its lines.

A visual representation of these common scenarios is depicted below.

Debug Session simplified

Debug Status

Within the winIDEA interface, real-time information regarding the establishment of a debug session and the current SoC (core) state is displayed in the lower right corner as the Debug Status.

For example, when the target is in a running state, the displayed CPU status is expected to indicate RUN. Conversely, when the target is in a stopped state, the displayed CPU status should reflect STOP. This visual representation serves as a quick reference for users to comprehend the ongoing state of the CPU during the debugging process.

Debug Status indicates the following:

•winIDEA is not connected to the BlueBox (    OFFLINE    )

•winIDEA is connected to the BlueBox (all Debug Status, except the above)

•SoC status

•Core(s) status

For more information refer to Debug Status.

Debug Session start types

There are three most used Debug Session start types. Attach is least intrusive, followed by Reset, and the most intrusive Download.

When initiating a Debug Session start operation in winIDEA, the BlueBox undergoes an initialization process, and the configured applications symbols are loaded into winIDEA regardless of the Debug Session start type.

After any Debug Session starts an ongoing status read loop begins. In this loop, various status readings are collected. Most relevant are: supply signals on the debug connectors, reset line state, SoC status and core status for all observed cores.

All three Debug Session start types can be performed via winIDEA Debug menu. For the shortcut list refer to Toolbars and Shortcuts.

Download

The Download is a double Reset with an addition of a programming stage in between. First Reset prepares the target SoC for winIDEA to load a helper code for non-volatile storage programming. winIDEA then utilizes the loaded code to transfer configured binaries to the storage in this stage referred to as programming.

*Second Reset after programming ensures a cleaned-up target system from the programming side effects for the application to run. The second Reset can be optionally skipped if programming is performed to a volatile storage (RAM) as resetting the SoC might corrupt the written code.

You have the option to condition this procedure with initialization scripts.

Reset

When initiating a Reset operation in winIDEA the reset signal is engaged immediately after common winIDEA and BlueBox initializations. Then the analog switches on the adapter, leading to the target, are activated putting the target in a reset state. Debug registers are then configured, exercising available and configured mechanisms preventing code execution after the next step which is the reset signal release. SoC is then shown in STOP state. This completes the debug session start and the session transits to the status read loop.

You have the option to condition this procedure with initialization scripts.

Attach

Attach might need three steps depending on the BlueBox generation used.

On older BlueBox types the winIDEA and the BlueBox must be prepared for physical connection by selecting Debug | Prepare to Attach first. This needs to be done with the target physically disconnected from the target. It makes a BlueBox enter a stage where all the pins are in a non-disruptive state for the target (e.g. reset signal is set to high).

Next any BlueBox can be physically connected to the target with a cable. Debug session is then fully entered by clicking Debug | Attach.

With the iC7 BlueBox Debuggers you may have a debug cable connected, skip Debug | Prepare to Attach and click Debug | Attach immediately.

The reset signal is released when starting a debug session. This way a running target is not disturbed when final switches on the debug connector are enabled. Debug registers are then configured and SoC is shown in the RUN state. This completes the debug session start and the session transits to the status read loop.

At the end of the debug session a user selects Debug | Detach which cleans up all the changes in the target that were done for the debugging purposes. SoC is put to run. After that a debug cable can be safely disconnected from the target.

It is suspicious if the reset signal is reported ACTIVE while using Attach. It is probably being activated from the target side.

You have the option to condition this procedure with initialization scripts.

Establishing a Debug Session

To establish a Debug Session you can also use these commands:

•Debug | Load Symbols Only - Same as Debug | Reset.

•Debug | Run - Same as Debug | Download but after programming the device is set to running.

Ending a Debug Session

There are two types of ending a Debug Session from the perspective of a target.

Detach

Debug | Detach cleans all the changes in the target that are done due to the debugging purposes, and debug is disabled (e.g. breakpoints are removed). The target is set to RUN.

End Session

To end a Debug Session and leave the target in a state as before, use Debug | End Session.

Troubleshooting

For troubleshooting tips refer to Knowledge Base.

More resources

•Debug Status

•Initialization Sequence

•Knowledge Base - Troubleshooting tips