Reset is INACTIVE
When trying to establish a debug session, the message Reset is INACTIVE appears in the Progress window and/or log file.
Explanation
The reset line state is reported for informational purposes. It is the state sensed on the reset signal of the debug connector. Message is usually informative when trying to understand or follow what is happening while establishing a debug connection with the target SoC which can be complex on its own.
How a reset signal behaves depends on the way a debugger (any debugger) is driving it and how a target itself is driving it.
Driving it from a debugger (winIDEA) side is based on:
- if target SoC debug registers are accessible while the SoC is in reset
- if it is configured to be used at all - the debug connector might not have it connected
- what kind of a debug connection start is required (intrusive kind, e.g. Download or Reset vs. unintrusive Attach)
The most usual reasons for actively driving a reset signal from the target side are:
- driven by the target SoC itself
- external watchdog
- board reset push button
- signal interference
Note that a stronger drive (high or low) from the target side might override the reset signal level asserted from a debugger side.
Reset is ACTIVE means that the reset line was sensed low at the moment of the
message. Reset is INACTIVE means that the reset line was sensed high at the moment of the
message. The image below shows how a Reset is handled in winIDEA when you click Debug | Reset.
Most used debug connection start types
There are 3 most used debug connection start types (in the order of intrusiveness): Attach (least intrusive), Reset, and Download. There are additional recovery types, e.g. from power loss.
Attach
The reset signal is released immediately 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 initialized and SoC is shown in the RUN state. It is up to you to stop the application later, e.g. by setting a breakpoint.
It is suspicious if the reset signal is reported ACTIVE while using Attach. It is probably being activated from the target side.
Reset
The debug connection is started with the reset signal active. The goal is to prevent any target SoC code execution by activating the reset signal and enable the debug stop mechanism which stops cores after the reset signal is released. The reset signal in this desired process is first reported ACTIVE and then INACTIVE just before an SoC is presented in the STOP state.
Process deviates from the desired sequence when the reset catch mechanism can't be configured while the reset signal is active. In such case, the reset signal is released and immediately after that the debug stop command is issued over the debug connection. It is impossible to prevent some of the code from executing before stopping the target. You can then utilize the preset mechanism provided in winIDEA to get the application to the point of interest, e.g. reset vector.
It is important to acknowledge that some target code did execute if the reset signal was reported INACTIVE before other debug start messages.
Download
The Download is Reset as described above two times with an addition of a programming stage in between. First Reset prepares the target SoC fresh out of reset for winIDEA to then load a helper monitor code for nonvolatile storage programming. Second Reset after programming then ensure a cleaned-up 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 as resetting the SoC might corrupt the written code.