Flash page erase blocking on STM32F100

justin239955_st · ‎2013-06-06

Posted on June 06, 2013 at 17:58

Hi i've read all the post I could find on the subject and I know that accessing the flash during an erase command will stall the MCU. However the code i'm looking at is not accessing the flash (that's what i believe) and is taking too long:

switch(ActualFlashJob->type) {

case FLASH_PAGE_ERASE:

FLASH->CR |= FLASH_CR_PER;

FLASH->AR = ActualFlashJob->address;

m_EnterCritical();

t1 = GetTime();

FLASH->CR |= FLASH_CR_STRT; // This line takes 5.65ms

t1 = GetTime() - t1;

m_ExitCritical();

break;

This is part of the flash driver. GetTime() will return an internal counter in 125ns increment. Enter and Exit Critical will save/restore context and disable/enable interrupts.

The fact that setting the start bit takes 5ms+ to execute is beyond me.

Anyone has a tought on that?

Thanks,

Justin

#stm32-flash-erase-page #flash

Tesla DeLorean · ‎2013-06-06

Posted on June 06, 2013 at 18:57

Is the code running in RAM, are the interrupts/vector table in RAM?

What timer are you using? Estimated erase time for a 1KB page 20-40 ms

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

justin239955_st · ‎2013-06-06

Posted on June 06, 2013 at 19:29

The code executing in flash. The interrupt vector is also in flash.

GetTime() is using TIM2->CNT.

Again, the code is executing from flash, but at the moment the start bit is set, the interrupts are disabled. Could the second GetTime be stalling the mcu?

justin239955_st · ‎2013-06-06

Posted on June 06, 2013 at 19:33

I checked and yes the second GetTime was stalling the mcu.

Changing the GetTime for TIM2->CNT show 1us execution time.

This might be the 1st downside i see to using non-paginated memory..

jpeacock2399 · ‎2013-06-07

Posted on June 07, 2013 at 16:08

Onc you set the START bit the processor will stall the next instruction fetch from flash memory, until the flash operation completes. If you can't stall, for instance to reset a watchdog, you need to run the flash erase code from SRAM.

The internal flash is for code storage. Although ST touts it as substitute EEPROM in an app note it really doesn't work well in that regard, especially if you have an interrupt driven application running with lots of events. You'd be better off with external serial flash/EEPROM/FRAM on the SPI or I2C bus.

I use internal flash to store certain configuration parameters. These are read once at startup and only written in special circumstances, right before a reset. Otherwise I prefer using serial NOR with small sectors on an SPI bus.

Jack Peacock

justin239955_st · ‎2013-06-07

Posted on June 07, 2013 at 17:20

Thanks Jack for the response. I'm looking to add an external i2c memory to save more frequently updated data.