Hi All,
I am trying to reset the CPU in the middle of a debugging session. I am using Application Interrupt and Reset control register by setting the SysResetReq bit in the SCB block. (this preserves the current debugging session also).
However, as I am using ASM its a bit cumbersome. This is the code snippet I am trying to use..
AIRCR EQU 0xE000ED0C.
.
Any feedback/input help will always be appreciated.
Thanks!!
BR,
\ksnf3000
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.
Hi Ali,
I see from your screenshots that you still have values loaded in R0 and R1 registers. Is this after reset? because, i am seeing a complete empty register set i.e all registers are resetted to 0 including the ones I have used for stroring the values!!
Also, 1 thing I noticed was that this behavior is dependent to some extent on the breakpoints being used. I think till morning I was getting a result similar to yours, now suddenly everything seems to be 0!!
\Kashif
Hi
I think R0 and R1 are not 0 because I used the Simulator.
this is with STM32F4Discovery :
Kashif
I noticed that in your earlier posts you were writing 0x05FA0001, but more recently you quoted 0x05FA0004. AIRCR bit 0 is reserved, and the reset request bit is bit 2, so 0x05FA0004 is the correct value. This may explain the change in behaviour you report.
AIRCR Register has two control bits for reset:
_ SYSRESETREQ (bit 2)
_ VECTREST (bit 0) This is indented for use by Debuggers.
I see it now, thanks. I was reading the ARMv6-M architecture. VECTRESET is described in device user guides and ARMv7-M architecture. It does say that its use is reserved to debuggers so SYSRESETREQ would seem the better choice in this case.
on STM32F407VG A Software Reset causes bit 28 (SFTRSTF ) in RRC_CSR Register to set.
after soft reset , you can check this bit and if set branch
main check SFTRSTF
if set
branch resume
.....
......
Software reset set SYSRESETREQ
resume ......
sorry for my bad english
Thanks for the STM link, I will try this out with the STM32 board tommorrow and let you know the result.
jblack however, this complete reset has actually removed all the data, as you correctly pointed out ; so effectively whatever debugging data I thought was useful, now also has been resetted. And I think when I used a value of 1 (instead of 4) this was not happening. i will have to do this again to make sure as it seems very unpredictable. my main goal is : i write data to SRAM; perform a software reset; and then continue with the remainder of my program which now accesses the SRAM so that I can see how much data is retained after the software reset.
jblack @Ali: I have found something interesting. I think the value 0x05FA0004 or 0x05FA0001 which we are trying to write is not written in 1 cycle but multiple cycles. So probably that's the reason the code goes back in a loop and starts again and does not reset everything to zero. So, to confirm this I added DSB
loop ldr .....
B loop
On applying a break point at B loop I see that all registers have been reset to 0 and the debugger now points to the Start in the startup code effectively resetting the CPU. I think the DSB instruction makes sure that this writing fully takes place and then only is the CPU completely reset.
Please correct my understanding if I am wrong here.
Hi,
We had got complementary 10 number of kit with name as below from ARM University
Please send the Datasheets for the above mentioned Kit.
Please send some DSP Example testcases to be executed on this Kit.
Please send some general microcontroller based Example testcases to be executed on this Kit.
Thanks& Regards
Dr.Sayed Abdulhayan
Electronics& Communication Department
Dayananda Sagar College of Engineering
Visvesvaraya Technological University
Bangalore,India-560078
Mob-00-91-9986096513