CPU Reset during a Debug session

When your CPU has taken the reset, execution will resume from your defined reset handler.  At this point you will by definition have exited from your reset wait loop.

From the ARMv6-M Architecture Reference Manual:

7.5.16. Reset management

In ARMv6-M, the AIRCR provides a mechanism for a system reset, see Application Interrupt and Reset Control Register, AIRCR.  Setting the AIRCR.SYSRESETREQ control bit to 1 requests a reset by an external system resource. The system components that are reset by this request are implementation defined. A Local reset is required as part of a system reset request.

Setting the SYSRESETREQ bit to 1 does not guarantee that the reset takes place immediately. A typical code sequence to synchronize reset following a write to the relevant control bit is:

      DSB; 
Loop  B    Loop; 

When your CPU has taken the reset, execution will resume from your defined reset handler.  At this point you will by definition have exited from your reset wait loop.

From the ARMv6-M Architecture Reference Manual:

7.5.16. Reset management

In ARMv6-M, the AIRCR provides a mechanism for a system reset, see Application Interrupt and Reset Control Register, AIRCR.  Setting the AIRCR.SYSRESETREQ control bit to 1 requests a reset by an external system resource. The system components that are reset by this request are implementation defined. A Local reset is required as part of a system reset request.

Setting the SYSRESETREQ bit to 1 does not guarantee that the reset takes place immediately. A typical code sequence to synchronize reset following a write to the relevant control bit is:

      DSB; 
Loop  B    Loop; 

Hi Jon,

Thanks for your reply. However, I did observe that the debugger points to the Reset_handler in the startup code once the code has run (without providing a local request). Strange, or is there something that I maybe missing?

Would be glad if you can clarify this?

My query is that I would like to implement a conditional CPU reset i.e only once should the CPU reset and after reset it should continue from where it stopped (since its in the debug mode) and not enter a reset loop.

BR,

\Kashif

This excerpt is from the ARM Architecture, so some behaviours are implementation-defined.  You need to look at the documentation for your specific system.

In general though I'm not sure I understand your problem.  You have a halting debug session and you want to trigger a reset of the CPU.  To this end you embed instructions to request a reset, which will cause execution to resume at the reset handler.  This is the behaviour defined by the architecture.  You can continue to debug, but you have effectively thrown away your program state because you triggered a reset.

So, what problem are you trying to solve?

Well this is the problem I'm trying to solve actually.I want to preserve the SRAM contents of my system so that even after a soft-reset (done by the program), I am able to view the SRAM contents effectively from the point where I left the system at reset. The interval between the reset and the accessing of the SRAM will be varied later.

Thanks!

The state of SRAM in your system after a soft reset will be determined by the design of your specific system.  You need to consult the manufacturer's documentation for that.

If I understand correctly, your software requires the ability to initiate a soft reset while preserving some amount of state in the SRAM.  Is this data or are you executing out of SRAM at this point?  You have suggested earlier that you would like the system to resume execution where it left off after triggering the reset.  This is not the behaviour of the hardware so you would need to implement your software such that after the reset handler has executed and you have re-initialised your CPU, you pick up the state and resume whatever processing you suspended to do the reset.