STM32F103C6 Increase flash page erase time with IWDG active

[xbalmes]

Posted on February 28, 2013 at 11:58

Hi, I've noticed an extra time in the erase page process when the IWDG is active. I haven't measured it (I notice a change in the blinking frequency of a led) and it's not a big deal, but I can't find any reference in the datasheets and I'd like to know if it's normal and the reason.

Thanks in advance.

#flash #flash-erase-time-watchdog

[Tesla DeLorean]

Posted on February 28, 2013 at 12:34

Code execution in flash, or reading the flash array, will cause the CPU to stall while any erase/write is pending.

[xbalmes]

Posted on February 28, 2013 at 12:55

Thanks Clive,

the erase code is the same with or without the IWDG running. After I start an erase I wait in a loop (CPU surely stalled). The only difference is that the watchdog is running (WDG period >> erase time)

    while( (FLASH->SR & FLASH_FLAG_BSY) );

  

The stall time should be the same with or without watchdog (I think)

Is there any explanation for an erase time increase when the watchdog is ON?

[Tesla DeLorean]

Posted on February 28, 2013 at 13:04

But how/where is the LED blinking?

I wouldn't expect the watchdog to change anything.

[xbalmes]

Posted on February 28, 2013 at 13:44

I wouldn't too... that's why it surprises me this effect.

I have something like this (pseudocode):

for (add = start address to end address) {

ErasePage(add);

BlinkLed();

}

[jpeacock2399]

Posted on February 28, 2013 at 15:51

Is all your code in SRAM, including the subroutines?  Does the part reset immediately after the flash erase?

There can be as much as a 2:1 variance in erase times depending on the part.  An 'F407 erases a 64KB sector between 550ms and 1100ms.  What kind of delay are you seeing that's unexpected?

  Jack Peacock

[Tesla DeLorean]

Posted on February 28, 2013 at 15:58

The F103 mentioned is a low density part, 32KB Flash, with 1KB sectors.

[xbalmes]

Posted on February 28, 2013 at 16:35

Hi Jack, the code is all in flash, thus the micro gets stalled (in a boot zone ''never'' erased) The bootloader first erases the application zone and next receives the binary via UART and saves it in the flash.

I've measured it with an oscilloscope. When the IWDG is disabled the page erase time is 21 mS. When it's enabled it increases to 43 mS. As I said it's not a big deal (the overall process lasts 15 seconds) but I  can't see the relation between a watchdog running and the flash erase time.

Of course it would be better if the time reamained the same, as speed is a constraint in this project (many units must be updated sequentally)

[abelloni]

Posted on March 17, 2013 at 18:35

Hi all,

i've seen a similar behavior in my program when i try to enable IWDG (STM32L152). I use I2C to write to an external eeprom and since it is required to wait at least 5ms between two write, i made a simple routine that count in a loop up to a value.

Everything works ok, but when i enable IWDG, that loop takes longer and the watchdog resets the micro. I'm using HSE clock at 8Mhz, it seems like when i enable the IWDG the micro start using LSI (37Khz) instead of the HSE clock, is it possible?

[Tesla DeLorean]

Posted on March 17, 2013 at 22:59

I'm using HSE clock at 8Mhz, it seems like when i enable the IWDG the micro start using LSI (37Khz) instead of the HSE clock, is it possible?

Well it's definitely going to enable the LSI, it should be a trivial exercise to gather the clock settings and display what the core thinks is going on, so one shouldn't have to guess or hypothesize.

Perhaps you can post a code example that demonstrates the condition?