Electronic – Efficient way of writing to flash memory without losing data

cflashspi

For my project, I am writing some code that gets some results and I want to store these results on external flash memory. The external flash memory in question is a MX25R8035F. I found that writing without erasing only works the first time I wrote something to an address.

But because of this I'm running into some memory issues. The smallest erase is a sector erase (4096 bytes.) If I want to write to a specific address I would first need to read the sector that contains that address, change the bytes that I want to be changed and then write the whole sector (writing is only per page.)

Is there a more efficient way of using this external flash memory? Specifically using less memory to change one or two bytes.

The function I use now this can be found below:

uint8_t EXT_FLASH_write(size_t address, uint8_t *buf, size_t length) {

/*
 * The entire sector will be erased when writing to an offset inside that sector
 * Therefore this function will first retrieve all data inside the sector and update the retrieved
 * data with the values inside buff which and will then write the entire content back to the sector
 */

    uint8_t wbuf[4];
    SPI_Transaction transaction;
    uint32_t sectorBaseAddr;
    uint8_t temp[EXT_FLASH_ERASE_SECTOR_SIZE];
    uint8_t tries;
    size_t ilen; /* interim length per instruction */
    uint32_t bufIndex = 0;
    uint8_t pageIterations;

    while (length > 0) {
        // first retrieve entire sector so it can be erased on the chip
        sectorBaseAddr = EXT_FLASH_SECTOR_BASE_ADDR(address);
        EXT_FLASH_read(sectorBaseAddr, temp, EXT_FLASH_ERASE_SECTOR_SIZE);

        // Erase the sector on the chip
        EXT_FLASH_erase(address, EXT_FLASH_ERASE_SECTOR_SIZE);

        ilen = EXT_FLASH_PROGRAM_PAGE_SIZE
                - (address % EXT_FLASH_PROGRAM_PAGE_SIZE);
        if (length < ilen)
            ilen = length;

        memcpy(temp + (address - sectorBaseAddr), buf + bufIndex, length);

        bufIndex += ilen;
        address += ilen;
        length -= ilen;

        tries = 0;
        if (EXT_FLASH_writeEnable() != 0) {
            if (tries == EXT_FLASH_MAX_TRIES) {
                return 1;
            }
            tries++;
        }
        tries = 0;
        while (EXT_FLASH_waitReady() != 2) {
            if (tries == EXT_FLASH_MAX_TRIES) {
                return 1;
            }
            EXT_FLASH_writeEnable();
            tries++;
        }

        // programming the external flash can only be done in pages
        // so divide current sector into pages and write each page separately
         for (pageIterations = 0;
                 pageIterations * EXT_FLASH_PROGRAM_PAGE_SIZE
                         < EXT_FLASH_ERASE_SECTOR_SIZE; pageIterations++) {
            EXT_FLASH_select();

            wbuf[0] = EXT_FLASH_CODE_PROGRAM;
            wbuf[1] = ((sectorBaseAddr
                    + (pageIterations * EXT_FLASH_PROGRAM_PAGE_SIZE)) >> 16)
                    & 0xff;
            wbuf[2] = ((sectorBaseAddr
                    + (pageIterations * EXT_FLASH_PROGRAM_PAGE_SIZE)) >> 8)
                    & 0xff;
            wbuf[3] = (sectorBaseAddr
                    + (pageIterations * EXT_FLASH_PROGRAM_PAGE_SIZE)) & 0xff;

            // Configure the transaction
            transaction.count = sizeof(wbuf);
            transaction.txBuf = wbuf;
            transaction.rxBuf = NULL;

            if (!SPI_transfer(masterSpi, &transaction)) {
                /* failure */
                EXT_FLASH_deselect();
                return 1;
            }
            // Configure the transaction
            transaction.count = EXT_FLASH_PROGRAM_PAGE_SIZE;
            transaction.txBuf = temp
                    + (pageIterations * EXT_FLASH_PROGRAM_PAGE_SIZE);
            transaction.rxBuf = NULL;

            if (!SPI_transfer(masterSpi, &transaction)) {
                /* failure */
                EXT_FLASH_deselect();
                return 1;
            }

            EXT_FLASH_deselect();
        }
    }
    return 0;
}

Best Answer

FLASH is cheap and provides lot of memory, but comes with the cost of sector erase. So you might want to use EEPROM instead.

Of course it is possible to overcome this flash limitation with some clever software, which tracks the bits and bytes with a journal (i.e. you don't overwrite a byte value but write a new copy of it and note in the journal that the new byte is the recent one). But this is a really big software overhead and you might not want to do that.

Related Solutions

Electronic – Writing Flash on STM32

The short answer is that hardware is inherently unreliable. Something can always in theory go wrong that interrupts the write process or causes the wrong bit to be written.

The long answer is that Flash circuits are usually designed for maximum reliability. A sudden power loss on write will probably not cause corruption because the driver circuit may have enough capacitance or the capability to operate under a low-voltage condition long enough to finish draining the charge as necessary. A power loss on erasure might be trickier, because the high-voltage charge pump needs to complete its job. You really need to consult the manufacturer. The solution is probably just a sufficiently large power supply capacitor.

For a "soft" system reset with no power interruption, it would be pretty surprising if the hardware didn't always completely erase whatever bytes it was immediately working on. Usually the bytes are erased in a predefined order, so you can use the first or last ones to indicate whether a page is full or empty.

Are you trying to maintain integrity of the data with some external entity (for example, if the widget is active then its data is written), or just self-consistency of the data itself? In the latter, more reasonable case, you should focus on marking the successful completion of each write and erase operation within the Flash data stream, so incomplete operations get retried/ignored on reboot no matter the cause of failure.

Electronic – How to overwrite flash memory on STM32L series

Some types of non-volatile memory device use error-correcting logic which adds an extra few bits to each programmable chunk (e.g. 5 bits per 16, 6 per 32, 7 per 64, 8 per 128, etc.) Generally the error correction code is chosen so that all bits blank is a valid representation; in some cases, but not all, it may also be chosen such that all bits programmed is also a valid combination. For simplicity, I'll assume a code with which guards each group of 4 bits with 3 guard bits. Compute the three guard bits guard bit as being the xor of either data bits 0+1+3, 0+2+3, or 1+2+3. I'll also assume that a blank word is zero.

The 16 possible code values are thus

3210 ABC    3210 ABC    3210 ABC    3210 ABC
0000 000    0100 011    1000 111    1100 100
0001 110    0101 101    1001 001    1100 010
0010 101    0110 110    1010 010    1110 001
0011 011    0111 000    1011 100    1111 111

When a memory nybble is read, the system can see what bits ABC should be according to the table. If one of the seven bits in the word is misread, the combination of ABC bits that don't match the computed value will indicate which bit was wrong.

Suppose a memory system used the 16-bit code shown above, and one wanted to overwrite a byte value of 1110 (ECC bits 001) with a value of 1000 (ECC bits should be 111). The net effect would be that the system would write 1000 with ECC bits of 001. When the data is read back, the system would see that for a value of 1000, the ECC bits should be 111 but are instead 001. The fact that bits A and B are wrong means bit 0 of the data was wrong and should be flipped; the system would thus read the value as 1001 (whose ECC is correctly 001).

In most cases, there should be enough flexibility in the design of an error-correcting code to permit both all-bits-clear and all-bits-set to be regarded as valid combinations. Some systems do not do so, however. If an error-correcting code would require an all-bits-programmed word to have two or more of the ECC bits blank, then an attempt to obliterate a word which has those bits programmed would likely visibly fail; attempts to program many other values would likely yield a state which was only one bit error away from failure rather than two.

I really wish memory designers would allow for data to be obliterated even if they don't allow most other overwriting patterns. Especially with NAND flash, it would make some operations a lot easier.

Best Answer

Related Solutions

Electronic – Writing Flash on STM32

Electronic – How to overwrite flash memory on STM32L series

Related Topic