STM32F407 : IWDG and erase flash sector

Pablo Devanne · ‎2017-03-20

Posted on March 20, 2017 at 15:53

Hi,

In my application I'm using the Independent watchdog on a STM32F407 with a maximum reload period of 2 ms. During some maintenance operations, we need to save some configuration parameters in flash memory. Even if we use the 16 kB sector, the erase time is greater than 2 ms and the IWDG make the MCU reset. Because there is only on flash bank on the 407 I can't kick the watchdog during the flash erase operation (and the bus stalls anyway), and it is not possible to disable the IWDG.

In order to avoid these resets, I tried to reconfigure the IWDG with a max reload period of a few seconds which is, I measured, way greater than the time needed for the erase operation.

In debug, the registers of the IWDG looks fine after the reconfiguration but when I tried in release or in debug but with no break point near the erase sector routine I have a IWDG reset.

Is there any way to avoid this behavior or am I just not correctly reconfiguring the IWDG ?

Many thanks in advance,

Pablo

waclawek.jan · ‎2017-03-23

Posted on March 23, 2017 at 23:59

OK so I played for some more and I'd recommend you in any watchdog timing change to:

IWDG->KR = 0x5555; // allow accessing other registers

IWDG->RLR = 4; // any timeout you want

while (IWDG->SR AND IWDG_SR_RVU) != 0) { // this takes 6 LSI clocks

IWDG->KR = 0xAAAA; // kick the dog (*)

}

// okay by here the dog timing according to the new setting is active

I tried only the lowest prescaler (i.e. IWDG->PR = 0) so there might be gotchas with other prescaler settings.

I'll describe my detailed findings in a separate thread and some time later, it's almost midnight here and I desperately need some sleep, tomorrow workday again.

JW

View solution in original post

Pablo Devanne · ‎2017-03-23

Posted on March 23, 2017 at 09:47

A solution could be to locate the IVT in RAM and to use a timer to generate a 1ms interrupt, the ISR would be in ram and would kick the watchdog. Then, when the maintenance operation is done, de-initialize the timer for normal behavior. But I am not really seduced by this method.

Do you have another idea ?

waclawek.jan · ‎2017-03-23

Posted on March 23, 2017 at 10:03

IMO there are details in the IWDG working which are not properly documented, see for example

https://community.st.com/0D50X00009XkYEQSA3

The freshly loaded values might not get active until one 'old period' elapsed for example. Try waiting 1-2ms after changing the IWDG parameters, while kicking the dog otten enough, after that try the FLASH programming.

ST might want to comment both here and in the linked thread.

JW

AvaTar · ‎2017-03-23

Posted on March 23, 2017 at 12:14

A possible solution might be to reset the MCU, and re-initialize without the IWDG for flashing. When done, either init the IWDG, or reset again and proceed with a 'normal' startup.

AvaTar · ‎2017-03-23

Posted on March 23, 2017 at 13:08

But I am not really seduced by this method.

I would be wary of this idea as well , for two reason.

First, erase/program times are temperature-dependent. Higher temperatures might leave users with corrupted devices.

Second, the effort for keeping your 'maintenance code' in RAM might grow exponentially. I recently had a bootloader implementation with code update via CAN/UDS, with hardly enough resources to keep the whole CAN stack in RAM.

Pablo Devanne · ‎2017-03-23

Posted on March 23, 2017 at 16:40

Actually I can't really afford a MCU reset for maintenance operations because it will cause a re-initialization of the whole system ...

Thanks for the temperature dependent erase time information

I will try the solution describe below !

Pablo Devanne · ‎2017-03-23

Posted on March 23, 2017 at 16:47

Thanks I will try this solution and come back to you.

But if I understand well, if I configure the watchdog for a 2 seconds period in order to erase my sectors and write them, I will have to wait for 2 seconds to get back to the 2ms behavior after reconfiguration ... That's not really what you could expect from a watchdog peripheral ...

waclawek.jan · ‎2017-03-23

Posted on March 23, 2017 at 16:51

I didn't say that's how it's exactly behaving, all what I said was that the RM does not give an exact description of the behaviour.

You can try this quickly on a simplified minimal example, you don't need to implement it into your actual machine.

JW

waclawek.jan · ‎2017-03-23

Posted on March 23, 2017 at 23:59

OK so I played for some more and I'd recommend you in any watchdog timing change to:

IWDG->KR = 0x5555; // allow accessing other registers

IWDG->RLR = 4; // any timeout you want

while (IWDG->SR AND IWDG_SR_RVU) != 0) { // this takes 6 LSI clocks

IWDG->KR = 0xAAAA; // kick the dog (*)

}

// okay by here the dog timing according to the new setting is active

I tried only the lowest prescaler (i.e. IWDG->PR = 0) so there might be gotchas with other prescaler settings.

I'll describe my detailed findings in a separate thread and some time later, it's almost midnight here and I desperately need some sleep, tomorrow workday again.

JW

AvaTar · ‎2017-03-24

Posted on March 24, 2017 at 09:33

Actually I can't really afford a MCU reset for maintenance operations because it will cause a re-initialization of the whole system ...

That's exactly the point.

Not sure what your term 'maintenance' exactly includes, but it is not the normal operation mode.

Turning off the IWDG by restarting would be one way to solve your issue.

Working on a control unit for heavy machinery, and we never do updates/flashing during normal operation.

Changing over from 'app mode' into 'update mode' is done via MCU reset, exactly to turn off such 'disturbances' like watchdogs.

BTW, the datasheet for the MCU we use specifies a worst-case Flash mass-erase time of 10 seconds.