Posted on May 17, 2011 at 13:30Per the cortex-m3 manual writing:
0x05FA0004->SCB_AIRCR engages a request for reset to all system peripherals. (Write 1 to SYSRESETREQ)
In an implementation of the usb dfu, we branch to user code from thread mode almost immediately after reset. In addition, handler mode logic in the USB LP_IRQ may update user code and engage a system reset so that the system branches to the new code.
The following code (runs as handler inside of USB_LP_IRQ) occasionally does the right thing:
*(SCB_AIRCR) = (u32)0x05FA004;
while (1) {
/* should never get here */
asm volatile(''nop'');
}
However, this does not consistently cause a reset, and the program often hangs inside of the inf. loop. I would just assume reset via AIRCR doesnt actually reset the PC and MSP, however this exact code HAS worked in the past.
What does ''request system reset'' actually mean? can it fail? How can we create a software reset with equivalent effect of pulling the reset line?
Is it possible to manually clear ourselves from handler mode, reset the PC and SP to the reset handler (pointed at 0x0800004), and reset any peripherals/exceptions such that we are very explicitly resetting the cortex without relying on flaky functionality from AIRCR?
We have had some promising results by setting the VECTRESET bit (0) of AIRCR, however technically this bit is ''reserved'' and not intended for application use. Whats the story on this bit?
Any and all input appreciated. Official response as to the exact functionality of SYSRESETREQ in AIRCR also desired. Thanks!
