STM32F103C6 HardFault after erase flash with IWDG active

[xbalmes]

Posted on February 26, 2013 at 17:41

Hi, I'm new to Cortex M3. I've a custom boot working correctly: first I erase the 32K flash and after I write the memory with no problems.

I need to activate the Independent Watchdog, and when I do it the microcontroller ends jumping to the HardFault interrupt. The erase process ends correcly. The first watchdog reload counter after it causes the microcontroller to get in Hardfault interrupt (IWDG_ReloadCounter();)The watchdog reset time is set to the maximum (26 sec).Does anybody know what could be happening?Thanks in advance. #flash-iwdg-wwdg #watchdog-flash-iwdg

[Tesla DeLorean]

Posted on February 26, 2013 at 19:07

You should make sure the vector table is where it should be (ie you and processor (SCB->VTOR) agree), it hasn't been erased, and functions pointed too exist in non-erased memory.

If this is in fact a Hard Fault you should examine the processor state, and stacked context, and understand where the processor faulted, and attempt to diagnose why. A better routine will output this for you rather than sit in an infinite loop. Depending on the tool chain if you aren't handling an interrupt properly it will dump into a common area with a while(1); Make sure that your naming/linkage of other interrupts goes where you expect, and you know what interrupts are enabled when doing the erase.

[xbalmes]

Posted on February 27, 2013 at 08:53

Hi clive,

thanks for your fast answer. Vector table should be right, as the boot starts fine, and after a programming the application starts correctly. I'll give it another look.I'll try to examine the processor state and stacked context in order to diagnose the reasonRegards

[jpeacock2399]

Posted on February 27, 2013 at 16:11

The gotcha when erasing a large flash section is the risk of the IWG timing out during the stalled code period while the erase is in progress.  One option is to make sure the IWDG period is always greater than the total worst case flash erase time, and that the IWDG is reset just before the erase begins. 

The other option is to place a small erase routine in SRAM so code doesn't stall while the erase is in progress.  I use this since I have both the IWDG and WWDG watchdogs running with relatively short timeouts.  The early warning WWDG can be trapped to reset it before timeout, and the IWDG can be periodically reset during the flash BUSY poll.   Jack Peacock

[xbalmes]

Posted on February 28, 2013 at 10:20

Hi Jack and Clive,

thanks for your answers. I finally found the problem and it was rookie mistake. As it's a third-party development I didn't realize that some libraries weren't included in the boot module... I was calling a function just erased.That's why it fell in Hard Fault. Smart, isn't it?Thanks again.