winIDEA Help

This chapter explains setup for the reset in the initialization operation. Open Hardware  / CPU Options / Reset.

 

 

Require correct Device ID when attaching to SoC

Device ID is verified if it is present in the  SoC (SFR/JSON) description. The following warnings are displayed in the Progress window:

 

 

 

Configured boot core

Selected the boot core according to your application design.

 

 

 

RESET pin

RESET pin connected

When the reset line from the target is not connected to the debug connector, disable winIDEA to check the level of reset pin by uncheck the checkbox off. This option is checked by default.

 

Latch target RESET

System reset line drivers on the debugger side and the target side are open collectors. Either can pull it low. Assertion from target side can be missed by the debugger if it is shorter than poll period of the reset line. When the option is checked (default) the debugger hardware latches the reset line when being pulled low by target system. When polled next time the winIDEA acknowledges reset state. This yields a delay from when line is asserted by the target reset and the acknowledgment by winIDEA and potential restart of the application. An example is an application where the CPU is periodically set into a power save mode and then woken up by an external reset circuit. In such a case, a delay introduced by the debugger would yield application not operating properly.

 

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 method

Regular (default, best debug experience)
This reset method assumes that TRST and SRST signals are separately connected from the microcontroller to the target debug connector. When the debug session is initialized a debug module is reset first via the TRST while the microcontroller is held in reset via the SRST thus preventing the core to run. The SRST is released after the debug module has been configured to stop the core after SRST is released.

 

Stop and preset

This is a method doesn't drive any hardware signals and should only be used if Regular or SoC reset is not possible. First the microcontroller is reset via the SRST signal. Since the debug logic is not accessible when SRST is applied, the reset is released and the microcontroller starts executing the boot code, possibly the user application. As soon as the debug session is initialized, the CPU is stopped. Note that some of the code will already be executed, which means that the microcontroller is no longer in a "fresh" state.

You can additionally enable the Preset option (in Hardware / CPU Options / SoC) and specify the entry address to which you wish to preset the program counter.

 

 

Reset method explanation

Different reset methods are possible due to the problems arising from various wiring of the TRST (JTAG TAP reset), the SRST (system / CPU reset) and possible other reset signals (e.g. POR - power on reset) in the target system or inside the SoC (System on Chip). It is recommended that these otherwise independent signals are not connected together. However, sometimes they are tied together which can conflict with the debugger controlling the target microcontroller.

Proper reset wiring on debug connector should have independent TRST and SRST signals. Also their functionality should be independent –i.e. target debug module is reset when only TRST is activated while rest of the system continues running. Respectively debug module is left intact while only system is reset via SRST signal. This functionality depends on silicon and board design.

To keep the functionality needed for proper target initialization (explained further in text) other reset signals should be wired not to disrupt the described reset functionality. E.g. SRST if often replaced with POR signal on debug connector. Or sometimes SRST and POR are connected. POR usually resets debug module like TRST does which is not expected by emulation tools when putting system in reset state via SRST debug signal. Power on reset should be one time event after powering on the system and should not repeat while power stays on.

 

Following are the desired steps for proper initialization when debugger connects to the target (assuming target system is already powered on and debug connector is attached):

1.Target system is put in reset with activating SRST and not releasing it.

2.Target debug module is reset: TRST is activated for a moment and then released.

3.While system is still in reset a debug mechanism is set up to stop CPU execution when released from reset (also other debug settings are applied).

4.SRST is released and core doesn’t run. The target microcontroller is in known state and ready for next debug actions.

 

 

Driving the SRST signal

 

The diagram above shows how the SRST line is driven when a reset is applied. Depending on your hardware, it is possible to adjust the timings to your need.

 

RESET Duration

Specify the length of the RESET pulse. Note that in case of the Regular reset method, the debug logic is configured before the SRST is released, which makes the pulse a bit longer then specified with the RESET duration value.

 

Post RESET Delay

This delay is particularly relevant when using SoC or Stop and preset reset methods. Once the SRST is released, the on-chip debug module may need some time to become operational. This time can also depend on any additional reset circuitry on the target system. winIDEA will wait for the specified time before trying to establish a debug session. Keep in mind that the longer this delay, more of the code will be executed before the CPU is stopped or reset, so you should keep this setting as low as possible, while still giving the system time to stabilize. Note that this delay is irrelevant for the Regular reset method, where the debug logic is configured before SRST is released. However, this delay may still be used to prevent user actions for the specified amount of time, in case you have additional hardware in your system, which needs more time to become fully operational.

 

RESET drive mode:

•Open Drain - RESET pin is configured as an open drain output. This is the preferred configuration. winIDEA can also detect when the external circuit on the target activates the RESET pin.

•Push-Pull - RESET pin is configured as a push-pull output. Should be used with caution. The external circuit on the target must not actively drive the RESET pin, otherwise the debug adapter might get bricked.

•None - RESET pin is configured as read-only. The Latch target RESET functionality is not changed.

 

Not all RESET drive modes are available in all configurations, e.g., None mode is not supported by iC5000.

 

 

RAM Initialization

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.

 

Never

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.

 

Always

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.

 

Auto (Download)

In this case, the initialization is performed at the moment when the user tries to modify program flash (e.g. debug download, write in memory window, etc.). Not all CPU SRAM is initialized but only a small amount of it, which is needed for a programming monitor.

 

 

 

At Initialization

Disable watchdog

Checked by default on devices which have internal watchdog. If internal watchdog is not supported, this option is greyed out. Internal watchdog is disabled at Default and Custom initialization.

 

Suspend peripherals while stopped

When this option is checked, selected peripheral functions (e.g., timers) are stopped when the application is stopped. Peripheral functions can be selected via the button . It is generally recommended that this option is checked, as this results in more predictable behavior of the debugged application when using these peripheral functions.

Refer to the microcontroller and architecture reference manuals for details.

 

 

Detect Watchdog reset

winIDEA detects whether a reset has occurred within a configurable time period after the reset has been released. Watchdog detection is checked only after Reset/Program/Attach is performed from a disconnected debugger (Debug | End Session) and not on every Reset/Program/Attach.

The detection feature is disabled by default. However, you can specify the time period (in milliseconds) for checking the target's reset. The Progress window displays the results, e.g. Detecting watchdog activity for 1000 milliseconds. Reset asserted, probably watchdog activity.

 

 

Initialization

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. For detailed information refer to Initialization Sequence help topic.

 

 

Cleanup before Detach

This call point extends the emulation detach and is called on:

•Disconnect (Debug | End Session)

•Detach procedure (Debug | Detach)

 

By default the script runs all cores.