STM32F407 Sector Flash Erase forces WWDG reset

[robert.kanzur]

Hello all,

I am facing following problem:

Trying to perform an erase operation of a flash sector forces a WWDG reset. The WWDG is initialized with following settings:

  hwwdg.Instance = WWDG;
  hwwdg.Init.Prescaler = WWDG_PRESCALER_8;
  hwwdg.Init.Window = 127;
  hwwdg.Init.Counter = 127;
  hwwdg.Init.EWIMode = WWDG_EWI_ENABLE;

For my understanding, the WWDG acts as timeout watchdog only with this settings and can be refreshed no matter of the counter- window relation. Is this correct?

The early wakeup interrupt handles the refresh of the counter.

Calling the function FLASH_Erase_Sector to erase one sector from the HAL library (stm32f4xx_hal_flash_ex.c) leads to a MCU reset. From RCC it is recognizable that the reset was caused by WWDG.

Placing a breakpoint during debug session at the function executed after the FLASH_Erase_Sector does not cause a reset. Here is a code snippet from the HAL code, to show the breakpoint placement:

for(index = pEraseInit->Sector; index < (pEraseInit->NbSectors + pEraseInit->Sector); index++)
      {
        FLASH_Erase_Sector(index, (uint8_t) pEraseInit->VoltageRange);
 
        /* Wait for last operation to be completed */
        /* BREAKPOINT IS PLACED HERE */
        status = FLASH_WaitForLastOperation((uint32_t)FLASH_TIMEOUT_VALUE);
        
        /* If the erase operation is completed, disable the SER and SNB Bits */
        CLEAR_BIT(FLASH->CR, (FLASH_CR_SER | FLASH_CR_SNB));
 
        if(status != HAL_OK) 
        {
          /* In case of error, stop erase procedure and return the faulty sector*/
          *SectorError = index;
          break;
        }
      }

Did anyone experience a similar behavior and found a fix?

Thank you, any help is kindly appreciated.

[Yevgeni Tunik]

FLASH_Erase_Sector() freeses all code execution until the sector is fully erased, including refresh the watchdog.

Try to compare sector erase time versus timeout of the watchdog.

[TDK]

The solution would be to not access flash during the erase. You can do so by placing the code ran during that time in RAM.

Placing the breakpoint there halts the core which lets the erase operation finish while not letting WWDG advance if DBG_WWDG_STOP is set.

[robert.kanzur]

Hello, thank you both for the answers!

@TDK​ 

Could you explain the interplay between code execution from flash (I think this is what you mean with flash access?) and the WWDG? And what code would you reckon should be placed into RAM?

According to my understanding the flash erase is implemented as busy wait until the operation is finished or timeout expires. So there should be not other code execution, or is this assumption wrong?

Thank you very much for your help

[robert.kanzur]

Hello,

my current solution is turning off the APB1 clock for the WWDG before the flash erase and turning it back on after the operation has finished.

This seems to do the trick at first glance.

[Yevgeni Tunik]

Generally, suspending a watchdog is a bad idea. It breaks the goal of watchdog: hardware reset in case of the application is stuck.

[Yevgeni Tunik]

1. The bank of internal flash memory, which is busy with either write or erase, forces to pend (by the hardware) any accesses to this bank: either data read, data write, machine instruction fetch, and even DMA read or write.
2. Counting the watchdog timeout isn't depended upon any application activity. In case of the watchdog isn't refreshed (for any reason) during the timeout, the watchdog causes hardware reset.
3. You can place in RAM any code, including entire application.

[robert.kanzur]

I get your point, but in case the application is stuck and the WWDG clock is turned off, the IWDG is still active, which can be configured with a much higher count.

Thank your for your help

[robert.kanzur]

Thank you for clearing the points. Actually I have made a mistake with the clock calculation of the WWDG, therefore it is pretty clear now why the watchdog forces the restart.