When debugging Cortex-M3 processors, developers have the option of using either a processor-only reset or a full reset. The choice depends on the specific debugging needs. A processor-only reset is faster but does not fully reset the system. A full reset takes longer but resets the entire system, which is sometimes necessary for debugging.
What is a Processor-Only Reset?
A processor-only reset, as the name suggests, only resets the Cortex-M3 processor itself. It does not reset any peripherals or other system components outside the processor. When a processor-only reset occurs, the processor registers like the program counter and stack pointer are reset to their initial values. The processor restarts execution from the reset vector as if it has just powered on. However, the rest of the system remains untouched.
The processor-only reset is triggered by the debug module within the Cortex-M3 system. It directly controls the processor reset circuitry without needing to assert or deassert external reset pins. This makes the processor-only reset very fast compared to a full system reset. It typically takes only a few clock cycles to complete.
Advantages of Processor-Only Reset
- Much faster reset time since only processor core is reset
- Peripherals and other system state are not disturbed
- Can quickly restart code execution from reset vector
- Useful for quickly testing code paths multiple times
Disadvantages of Processor-Only Reset
- Does not fully reset system, peripherals retain state
- Cannot deterministically restart system from known state
- May not clear processor errors caused by peripherals
What is a Full System Reset?
In contrast to a processor-only reset, a full system reset resets the entire Cortex-M3 system including all peripherals and external components. This is achieved by asserting the external system reset pin, which drives the reset line to the processor and all other system components.
When a full system reset occurs, the entire system is reset as if power was freshly applied. The processor core is reset identically to a processor-only reset. In addition, all peripherals like timers, UARTs, I/O ports, etc are reset to their initial states. External components and bus fabric are also reset. The reset essentially forces a reboot of the entire system.
Advantages of Full System Reset
- Resets entire system including processor and peripherals
- Puts system into known/deterministic state
- Clears any processor errors caused by peripherals
- Needed when debugging system-level errors
Disadvantages of Full System Reset
- Much slower reset time due to resetting entire system
- Resets processor and peripherals unnecessarily
- Loses system and peripheral state
When to Use Processor-Only vs Full System Reset?
In summary, processor-only reset is faster but limited in scope, while full system reset is slower but more thorough. Following are some guidelines on when to use each reset method:
- Use processor-only reset when quickly testing or iterating on code within the Cortex-M3 processor itself. Avoids slow full system reset.
- Use full system reset when testing code that interacts with peripherals or external components. Ensures entire system is in known state.
- Use full system reset after making changes to system, peripheral, or reset configuration. Initializes entire system properly.
- Use full system reset if debugging errors that could be caused by improper peripheral state. Processor reset may not clear peripheral errors.
- Use processor-only reset if system has already been debugged and validated. Quickly restarts processor execution.
In debugging complex errors, it is often helpful to try both reset methods. A processor-only reset may fix simple processor errors, while a full system reset is needed for complex system-wide issues.
Performing Processor-Only Reset
Processor-only reset is triggered by the Cortex-M3 debug module. There are a few different ways to do this:
- Using the debugger’s processor reset command (e.g. ARM KEIL, IAR EWARM)
- Set the AIRCR.SYSRESETREQ bit in the Arm Cortex System Control Register. This causes a local processor reset.
- Assert the nRESET signal for a short pulse (less than 2 cycles). This causes the processor core to reset but not peripherals.
The debugger reset command is usually the easiest approach. The debugger handles asserting the appropriate reset control signals internally. From the user’s perspective, there is a simple reset button or menu option.
Processor Reset Using Debugger
As an example, here are the steps to do a processor-only reset using the ARM KEIL uVision debugger:
- Launch uVision and load the project binary
- Open the Start/Stop Debug Session control panel
- Click on the “Reset” button to reset the processor
The debugger will pulse the processor reset pin for a short time without affecting the full system reset pin. This quickly resets the processor only in a few cycles compared to hundreds of cycles for a full reset.
Processor Reset via AIRCR.SYSRESETREQ
The Cortex-M3 AIRCR register provides direct control over resets. Setting the SYSRESETREQ bit causes a local processor reset independent of the system reset pin.
To use SYSRESETREQ for processor reset:
- Write 1 to AIRCR.SYSRESETREQ
- Processor will now reset its state within a few cycles
- Poll AIRCR.SYSRESETREQ until it reads 0, indicating reset complete
- Processor is now reset and ready for new execution
This provides very fine-grained control over the processor reset right from software. However, remember to clear SYSRESETREQ afterwards, otherwise processor will constantly remain in reset state.
Performing Full System Reset
Unlike processor reset, a full system reset must drive the external system reset pin. This is typically exposed as a reset line, button, or IO pin on the development board. Ways to trigger full system reset include:
- Using debugger system reset feature (may be combined with processor reset)
- Driving external reset pin from GPIO or reset button
- Issuing board specific reset command (e.g. STM32 ST-LINK utility)
The external system reset line is required to reset all peripherals and components in addition to the processor core itself. Again, the debugger system reset option is usually most convenient.
System Reset with Debugger
Debuggers that support Cortex-M3 MCUs should provide a system or board reset option. For example, the steps to do a full system reset with KEIL uVision:
- Launch uVision and load debug session
- Open Start/Stop Debug Session control panel
- Click on “System Reset” button (may be combined with processor reset)
This will assert the external system reset pin driving the entire board reset. This takes much longer than a processor-only reset due to resetting external components. But it provides a clean restart of the full system.
System Reset via nRESET Pin
The nRESET pin can directly force a system reset by driving it low. This can be done a few different ways:
- Toggle nRESET pin from debugger probe or board test points
- Drive nRESET from spare GPIO or microcontroller pin
- Press external reset button connected to nRESET
Asserting nRESET low for more than 100ms will reset the entire system. Toggle the pin back high to come out of reset. This provides full manual control over system reset.
Comparing Reset Options
| Reset Method | Scope | Speed | Control |
|---|---|---|---|
| Processor-Only (CORE) | CPU core registers | Very fast | Debug module or software |
| System Reset (nRESET) | Entire system/board | Slow | External reset pin |
Processor reset quickly resets the CPU state while system reset completely reboots the board. Choose reset method based on debugging needs.
Reset Configuration
For reset to function properly, the reset sources and configuration must be set up correctly:
- Enable debug module reset control in system reset controller
- Configure system reset pin as input with pull-up
- Connect nRESET pin to reset button, debugger probe, etc
- Setup reset handler code at processor reset vector
It is also important to initialize peripherals and external components properly after reset in code, whether processor or system reset.
Debugging Reset Issues
If encountering issues with reset, here are some things to check:
- Reset not deasserted – Use scope to check nRESET pin asserted
- Multiple reset sources enabled – Disable other sources
- Reset control not enabled – Turn on debug module reset
- Reset not triggering – Check reset trigger source
- Peripherals not resetting – May need full system reset
For stuck resets, remove any external reset sources and use scope to probe reset pins. This can identify the reset source at fault.
Conclusion
In summary, the processor-only reset quickly resets the Cortex-M3 CPU state while the full system reset resets the entire board system. Processor reset is useful for fast iteration during debug. System reset helps start from a known system state.
Understanding reset options helps leverage them for more effective debugging. Match reset method to the particular situation for best results. Keep reset control and configuration in mind as well. Both processor and system reset are valuable tools for Cortex-M3 debugging.
