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
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!!
Thanks!
\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