2015-11-24 05:09 AM
Hello,
I'm currently working on a STM32F302VB and I need to perform a Soft Reset. On previous projects with STM32F030C8 and STM32F407, I've used the NVIC_SystemReset() function without any problems, but for some reason it doesn't work now.The implementation I use is this one:__STATIC_INLINE void NVIC_SystemReset(void){
__DSB(); /* Ensure all outstanding memory accesses included
buffered write are completed before reset */
SCB->AIRCR = ((0x5FA << SCB_AIRCR_VECTKEY_Pos) |
(SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |
SCB_AIRCR_SYSRESETREQ_Msk); /* Keep priority group unchanged */
__DSB(); /* Ensure completion of memory access */
while(1); /* wait until reset */
}found in core_cm4.h.The function is called and all instructions are executed, but it gets stuck in the while loop and reset never happens.After some research I've implemented the reset using assembly instead, as follows:asm(''\tdsb \n\t''
''ldr r0, =0xE000ED0C\n\t''
''ldr r1, =0x05FA0007\n\t''
''str r1, [r0, &sharp0]\n\t''
''dsb\n''
''Infinite_Loop:\n\t''
''b Infinite_Loop'');
This does perform the Soft Reset. The only difference I see is that NVIC_SystemReset() keeps the priority group unchanged, and doesn't set the VECTCLRACTIVE and VECTRESET bits (bits 1 and 0). Those bits aren't supposed to be set for a reset, as it says in the programming manual: ''When writing to the register you must write 0 to [these] bit[s], otherwise behavior is unpredictable.''But when I use 0x05FA0004 instead of 0x05FA0007 in the above assembly code, the controller gets stuck in the while loop, as it does with the NVIC_SystemReset() function. I've also tried running it without debugging, and it doesn't work either, the processor gets stuck. So for now it seems I have no other choice than setting those two bits and hope the unpredictable behavior is tolerable.Does anyone have an idea what's going on?Thanks #stm32 #reset
2015-11-24 05:45 AM
Is there anything going on externally with the pin?
What tools are being used here?2015-11-26 03:09 AM
Thank you for your reply.
Someone pointed out to me that if the nRST pin was pulled high during the soft reset, it could block it, and indeed due to a routing mistake, the pin was being pulled high and that prevented the reset from happening.Turns out that the pin is taken into account even during a soft reset, as it says in the Reference Manual:''[Reset] sources act on the NRST pin and it is always kept low during the delay phase'', so I should have known!
Anyway, removing the pull up did the trick and the NVIC_SystemReset() function now works as expected.I guess setting the VECTCLRACTIVE and VECTRESET bits forced the reset somehow... That's what you call unpredictable behavior!Thank you!