STM32F4 - FLASH Erase

[dibs]

Posted on December 11, 2013 at 20:54

I am attempting to erase a FLASH sector, but the process hangs. Any ideas on why this might be happening?

    FLASH_Unlock();    FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_OPERR |                 FLASH_FLAG_WRPERR |             FLASH_FLAG_PGAERR | FLASH_FLAG_PGPERR|FLASH_FLAG_PGSERR);     sector = GetSector(addr);    if (FLASH_EraseSector(sector, VoltageRange_3) != FLASH_COMPLETE) {         // error (flash,erase);        FLASH_Lock();        return 1;    } #stm32f4 #flash #flash-erase-watchdog

[Tesla DeLorean]

Posted on December 11, 2013 at 21:27

Thoughts...

The sector value is wrong. The code is running on the sector you are attempting to erase, this subroutine, or those of the library code. You don't check the BUSY (FLASH_WaitForLastOperation) prior to starting.

[dibs]

Posted on December 11, 2013 at 22:56

Option #2 is the winner. In my program, sectors 0-4 are populated with data upon programming. I tried my erase-write-check routine on sector 6 and it is working fine now.

---Since I have boot 0,1 pins tied to GND, my program will boot from the  ''Main Flash Memory.'' (0x8000 0000 - 0x080F FFFF). This includes Sectors 0-11 on the STM32F40x series.My follow up question:Is there a standard practice for how to allocate a sector to be used for things like calibration constants?What comes to mind is to only allow the program to exist in Sectors 2-11 and to have Sector 0 be reserved for constants. Is this something that is considered good practice or am I off the mark?

[Tesla DeLorean]

Posted on December 12, 2013 at 04:11

It all depends on how big everything is and how you want to floor plan the available space.

You pretty much have to commit sector 0 to some form of loader, I can fit an entire boot loader in there, including one capable of reading updates from an SD card. Perhaps use 0 and 1 if your loader needs 32 KB. If you have some write-once or board specific stuff you don't plan to erase, you could shrink your loader by 1 or 2KB and park that data at the very tail end, it at 0x08007C00 or whatever. It the loader really has to be >32 KB consider if you can carve a hole in the middle to save the 16 KB sectors, and use sectors 0 (16 KB) and 4 (64 KB) The other three 16 KB sectors are best suited to configuration or calibration data. ST's EEPROM emulation could also use them, but if you can manage them as flash, all the better. Consider your options not to erase, but rather journal a configuration structure and step through memory to find the last one written. If you want a secondary, or more complex loader, consider putting it in the 64 KB sector. Otherwise use it and the other 128 KB sectors for your application code. Depending on your available space, or secondary storage options (SD, NAND, etc), ponder if you can stage firmware updates in the upper sectors. There are many options, just remember the 128 KB sectors are very slow to erase, and best not touched during application run time.

[dibs]

Posted on December 12, 2013 at 15:50

Thanks Clive, you've been really helpful.

I need to wait until I figure out what I am going to be doing with my bootloader before I decide on the FLASH layout. 

[dibs]

Posted on February 12, 2014 at 14:05

If anyone is interested, I decided on a FLASH floor plan.

Sector 0:      Boot loader codeSector 1:      Log -- Logs ErrorsSector 2:      Used for sector copy then erase for config and logSector 3:      Configuration codeSector 4:      UnassignedSector 5-7:   Main program codeSector 8-10: Alternate codeSector 11:    Test bench code -- Will complete a self-test and send a report.

[munger]

Posted on June 09, 2014 at 14:17

I am trying to solve some of these same problems so this is great info.

Question: I know that if I use FLASH_EraseSector I pretty much stay there until the erase is complete. This is bad if I am trying to service a communication request at the same time. But ... what if I initiate the sector erase but don't wait for it? I'm going to taking apart FLASH_EraseSector and then use FLASH_GetStatus to check the status. Then, will I be able to execute other code while I'm waiting? That should work, right? FLASH_EraseSector doesn't stall the processor or anything like that?Thanks.Mike

[waclawek.jan]

Posted on June 09, 2014 at 14:42

> FLASH_EraseSector doesn't stall the processor or anything like that?

Have you read the fine manual? RM0090, ch. 3.6: Any attempt to read the Flash memory on STM32F4xx while it is being written or erased, causes the bus to stall.  [...] On STM32F42xxx and STM32F43xxx devices, two banks are available allowing read operation from one bank while a write/erase operation is performed to the other bank. JW

[munger]

Posted on June 09, 2014 at 16:25

Thanks Jan, good one. Actually I did have my manual open to that section (well, it's 3.5 in manual RM0368 for STM32F401) *and* I even had that paragraph circled, I guess I didn't believe it.

Here's the thing that seems weird to me: How can the function FLASH_WaitForLastOperation do anything at all? Certainly running that function would be doing code fetches. It seems like a bit of a paradox.Anyway, it's somewhat immaterial, clearly I can not go off and do another task while waiting for the flash to be erased or programmed.Thanks.Mike

[Tesla DeLorean]

Posted on June 09, 2014 at 18:11

It simply doesn't complete loop iterations until it's done. You can avoid the paradox and run code from RAM, which is what everyone used to have to do when writing external flash memories in the past. The STM32 just effectively stuffs wait states while the array is busy, obviating the real ownership of the problem by the coder. The side effect of course is it will stop the processor servicing other interrupts/peripherals in a timely manner.