NVIC_SystemReset not working

[daviddavid942]

Posted on March 30, 2010 at 14:52

NVIC_SystemReset not working

[Tesla DeLorean]

Posted on May 17, 2011 at 13:45

I've always used NVIC_GenerateSystemReset();, but I'll observe that it doesn't reset the clocks, just the CPU and peripherals. I will further observe that enabling ROP requires a power cycle, and that using a software reset basically renders the device unusable (STM32F103RET) in experiments I did.

ROP only prevents the use of JTAG and the Boot Loader. -Clive

[daviddavid942]

Posted on May 17, 2011 at 13:45

Hi Clive,

I need a bit of elaboration here... <<I've always used NVIC_GenerateSystemReset();>> It doesn't seems to be available anymore in the library, but I guess the just change the name to NVIC_SystemReset(). <<it doesn't reset the clocks, just the CPU and peripherals>> This should be enough to apply ROP and/or WP, isn't it ? <<I will further observe that enabling ROP requires a power cycle>> The Flash programming manual says that a system reset is necessary/enough after changing... do I miss something ? <<and that using a software reset basically renders the device unusable >> The system reset generated by NVIC_SystemReset() is not a sw reset, it should leave the micro in a consistent usable way, am I wrong ? Anyway.. the main question remains... why is the NVIC_SystemReset is not working on my Keil MCBSTM32 demoboard ? M

[damh]

Posted on May 17, 2011 at 13:45

The internal bootloader does the hard reset (i.e. after ROP change) as following:

>>Write  at ''Application Interrupt and Reset Control Register'' value 0x05FA0004<< [0xE000ED0C] = 0x05FA0004 The dsb command (The Data Synchronization Barrier (DSB) instruction ensures that outstanding memory transactions complete before subsequent instructions execute.) and while loop are NOT used.

[daviddavid942]

Posted on May 17, 2011 at 13:45

Hi damnh,

the NVIC_SystemReset also uses the __DSB, the while loop is after that...static __INLINE void NVIC_SystemReset(void) {   SCB->AIRCR  = (NVIC_AIRCR_VECTKEY | (SCB->AIRCR & (0x700)) | (1<<NVIC_SYSRESETREQ)); /* Keep priority group unchanged */   __DSB();                                                                             /* Ensure completion of memory access */                while(1);                                                                            /* wait until reset */ } but ends up hanging into while(1) loop...

[damh]

Posted on May 17, 2011 at 13:45

This part is different:

>>(SCB->AIRCR & (0x700))<< Perhaps your debugger doesn't want you to reset the stm ;) This command sequence kicks the bind of the debugger.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:45

From stm32f10x_nvic.c V2.0.1

#define AIRCR_VECTKEY_MASK    ((u32)0x05FA0000) /******************************************************************************* * Function Name  : NVIC_GenerateSystemReset * Description    : Generates a system reset. * Input          : None * Output         : None * Return         : None *******************************************************************************/ void NVIC_GenerateSystemReset(void) {   SCB->AIRCR = AIRCR_VECTKEY_MASK | (u32)0x04; } As damh points out this is the method used by the boot loader, and generally works well. Your mileage may vary, but my experience with enabling ROP is that the power cycle worked, other ways basically broke the device, I'll hazard they erased the part. Perhaps I need to look at a newer library, but this one is otherwise working well. Suggest you do your own experiments and be prepared for lots of fun and joy. ROP isn't very effective, someone reasonably competent and equipped could defeat it. Weigh this against factory programming, test, repair and field upgrade issues. Are you doing the tests with a debugger attached? Does the reset work properly if it isn't? -Clive

[daviddavid942]

Posted on May 17, 2011 at 13:45

@damnh: the difference shouldn't mater, otherwise we got bigger problem with the micro and/or the compiler...

@clive1 after some experiments I've seen that the NVIC_SystemReset works only if I'm not debugging. Same for IWDG. If I use the debugger, both NVIC_SystemReset and IWDG are ineffective. I moved to the next problem: if I set the ROP (either by code or by adding the STM32F10xOPT.s and its flash programming algorithm to my project) the fw doesn't run. I obviously cannot connect with debugger so I don't know where it gets stuck bit it's in the early stages since no led or other signals are moving... Since NVIC_SystemReset and IWDG where not working with the debugger AND the ROP caused the block I thought that it was the reset that got stuck, but it was not. Or so I figured it out ...:-) Any hint on the ROP block ? I know it's no high security, but is enough for the typical use-case of our devices, so I'd like to use it.

[mdeneen2]

Posted on May 17, 2011 at 13:45 Have you looked at NVIC_GenerateCoreReset()?

[Tesla DeLorean]

Posted on May 17, 2011 at 13:45

I moved to the next problem: if I set the ROP (either by code or by adding the STM32F10xOPT.s and its flash programming algorithm to my project) the fw doesn't run. I obviously cannot connect with debugger so I don't know where it gets stuck bit it's in the early stages since no led or other signals are moving...

This is where I wasted a lot of time. I'm pretty sure it nukes the device, and tries to run a blank SP/PC vector (ie both 0xFFFFFFFF) which in turn is likely to Hard Fault. It's real hard to tell, as I have zero visibility. I instrumented the code right at the ResetVector to get GPIOA/USART1 enabled and tweet a couple of characters to the console (code that works fine at reset normally, a few dozen assembler instructions). Whatever goes awry does so very early. I'll take a look at NVIC_GenerateCoreReset() -Clive