Very few write cycles in stm32f4

Question

I'm using a STM32F401VCT6U "discovery" board, and I need to provide a way for the user to write addresses in memory at runtime.

I wrote what can be simplified to the following function:

uint8_t Write(uint32_t address, uint8_t* values, uint8_t count) 
{
    uint8_t index;
    for (index = 0; index < count; ++index) {
        if (IS_FLASH_ADDRESS(address+index)) {
            /* flash write */
            FLASH_Unlock();
            if (FLASH_ProgramByte(address+index, values[index]) != FLASH_COMPLETE) {
                  return FLASH_ERROR;
            }
            FLASH_Lock();
        } else {
            /* ram write */
            ((uint8_t*)address)[index] = values[index]
        }
    }
    return NO_ERROR;
}

In the above, address is the base address, values is a buffer of size at least count which contains the bytes to write to memory and count the number of bytes to write.

Now, my problem is the following: when the above function is called with a base address in flash and count=100, it works normally the first few times, writing the passed values buffer to flash. After those first few calls however, I cannot write just any value anymore: I can only reset bits in the values in flash, eg an attempt to write 0xFF to 0x7F will leave 0x7F in the flash, while writing 0xFE to 0x7F will leave 0x7E, and 0x00 to any value will be successful (but no other value will be writable to the address afterwards).

I can still write normally to other addresses in the flash by changing the base address, but again only a few times (two or three calls with count=100).

This behaviour suggests that the maximum write count of the flash has been reached, but I cannot imagine it can be so fast. I'd expect at the very least 10,000 writes before exhaustion. So what am I doing wrong?

Put the if/else outside the for loop to begin with!!! As far as I can tell, you can also unlock/lock the flash outside the for loop. — barak manos
I can start with that as obviously it is useless for it to be inside the loop (flash and ram don't overlap...). Will that solve the problem? — dureuill
I would provide two separate functions - one for Flash and one for RAM. At the beginning of each function, I would assert that the requested memory space is indeed valid for that function. Then, simply perform the entire operation without any conditions. For the flash, as I've already mentioned, I would unlock/lock it outside the loop. In addition, I would check if there's a function "better" than FLASH_ProgramByte (e.g., FLASH_ProgramChunk). For the RAM, an additional improvement would be to write 4 bytes at a time, but you'll have to split the loop in order to avoid alignment issues. — barak manos
Thanks, I will try your recommandations and report on the result. — dureuill

Ricibob Ricibob · Accepted Answer · 2015-06-11T08:21:47

You have missunderstood how flash works - it is not for example as straight forward as writing EEPROM. The behaviour you are discribing is normal for flash.
To repeatidly write the same address of flash the whole sector must be first erased using FLASH_EraseSector. Generally any data that needs to preserved during this erase needs to be either buffered in RAM or in another flash sector.
If you are repeatidly writing a small block of data and are worried about flash burnout do to many erase write cycles you would want to write an interface to the flash where each write you move your data along the flash sector to unwriten flash, keeping track of its current offset from the start of sector. Only then when you run out of bytes in the sector would you need to erase and start again at start of sector.

Very few write cycles in stm32f4

3 Answers

Solution

Erase Policy

List of flash sector in STM32F4