You're right! It's hidden in core_cm3.h as the following in Release 3.1.2,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 */ } and as static __INLINE void NVIC_SystemReset(void) { 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 */ } in Release 3.2.0 Adds __DSB() and while(1) wait to your code. Not sure why they're different. Do you know? John F.
I use stm32f407. Is it possible reset cpu while debugger is running ?
I tried to reset cpu after can-frame is received with NVIC_SystemReset(). But after this function calling debugger jumped to HardFault_Handler(void). Am I missed something ?
I suspect the debugger being used might impact things, as will how the code is being run (ie User/System, RAM/FLASH). Presumably the debugger permits you to examine registers, memory and stack, to better understand/describe the failure.
What instruction/register is Hard Faulting? Don't know, then you'll need to use a Hard Fault handler that can decompose the faulting state rather than a while(1);
Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
I read fault registers inside faulting handler function. HFSR = 0x40000000, DFSR = 0x9, CFSR = 0x400. What does it mean ? What registers I need to examine else ?
This is strange. It seems like fault expected after previous command execution - write data to memory at 0x2000FFFF. As far as I understand fsr-register state talked - ''Imprecise data access error''. But this addr is in RAM memory range.
Is it possible to detect address of ''hard-faulting instruction '' ?
As far as I understand there is a set of status registers. MMFAR, BFAR - stores faulting address - associated with the attempted access. But this is accessed address not faulting instruction. Is there register stored hard-faulting instruction address?
It stores several registers on the stack, Joseph Yiu published an example in his Cortex M3 book. If your stack pointers are broken, this could be problematic.
An imprecise fault suggests an earlier write exiting the write buffer. See this example Frank put together.
But when hard fault occurred program stopped on first line TST LR,#4. Next instruction ITE EQ does not execute. Why? I cann't understand. LR=0xfffffffd. What does it mean?
LR contains a magic value, not a program counter. It infers which stack is in use, and allows the core to return from the faulting state. For more information refer to the core documentation.
Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..