This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM57L843: Implementing a LittleFS filesystem on the Emulated EEPROM using the F021 api.

Part Number: RM57L843
Other Parts Discussed in Thread: HALCOGEN

I have been trying to implement the littlefs file system to the Emulated EEPROM that is present on RM57Lx to store configuration values.

The eeprom has the error correction code programmed initially with the ecc codes being generated by the linker script.

I initialize the flash bank like so and then supply callback functions to write and read data to a specific address that is handled by little fs.

Fapi_initializeFlashBanks(150);
Fapi_setActiveFlashBank(Fapi_FlashBank7);
Fapi_enableEepromBankSectors(0xFFFFFFFF, 0);

The read function is implemented as such: 

int eeprom_read(const struct lfs_config *c, lfs_block_t block, lfs_off_t off, 
                void *buffer, lfs_size_t size) {

    struct lfs_context *ltxt = c->context;
    uint32_t addr = (ltxt->flash_sectors.u32BankStartAddress + (c->block_size * block) + off);

    while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady)
    {
      
    }

    Fapi_StatusType status = Fapi_doMarginRead(
        (uint32_t *)addr,
        (uint32_t *)buffer,
        size / 4,
        Fapi_NormalRead);
    if (status != Fapi_Status_Success) {
        fapiIndicateError(status);
    }
    return status;
}

The program function is implemented as such:

int eeprom_prog(const struct lfs_config *c, lfs_block_t block, lfs_off_t off, 
                const void *buffer, lfs_size_t size)
{

    struct lfs_context *ltxt = c->context;

    while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady)
    {
      ;
    }

    Fapi_StatusType status = Fapi_issueProgrammingCommand(
          (uint32_t *)(ltxt->flash_sectors.u32BankStartAddress + (c->block_size * block) + off), 
          (uint8_t *) buffer, 
                        size,
                        NULL, 
                           0, 
      Fapi_AutoEccGeneration);
   
    if (status != Fapi_Status_Success) {
        fapiIndicateError(status);
    }
    return status;
}

I also format the sectors via:

int eeprom_erase(const struct lfs_config *c, lfs_block_t block)
{
    struct lfs_context *ltxt = c->context;

    while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady)
    {
        ;
    }
 
    Fapi_StatusType status = Fapi_issueAsyncCommandWithAddress(
        Fapi_EraseSector, 
        (uint32_t *)(ltxt->flash_sectors.u32BankStartAddress + (c->block_size * block)));

    if (status != Fapi_Status_Success) {
        fapiIndicateError(status);
    }
    return status;
}

After programming the eeprom is erased and appears correct:

0xf0200000:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xf0200010:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xf0200020:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xf0200030:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xf0200040:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xf0200050:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xf0200060:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xf0200070:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xf0200080:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xf0200090:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xf02000a0:     0xffffffff      0xffffffff      0xffffffff      0xffffffff

However after initially creating and writing a few files:

The bit flips happen again. I would appreciate any pointers or guidance here to get the eeprom working. The bit flips appears as errors to the file system and will cause the filesystem to deem the block as unwritable, locking the filesystem.

  • Hi Rahul,

    We started working on your issue and we will provide an update ASAP.

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagdish,

    Could you provide any updates? We have been stumped by this problem for a while now and do not know hw to proceed. The documentation doesn't make it clear on how to write to individual address and I garauntee all the reads and writes the size of the EEPROM_BANK_WIDTH.

    Regards,

    Rahul

  • Hi Rahul,

    For using EEPROM (bank 7), the HALCOGen generates the FEE driver. You don't need to write your code for reading/writing data from/to EEPROM.

  • Hi QJ,

    I did look at using the FEE driver, but the limitation is that it writes blocks of data. Our use case in the application is store small configuration values in files and read and write from them, I can restructure the project to use the FEE driver but I was wondering if it was possible to write smaller 8 bytes of data directly to the eeeprom address(es)?

  • Yes, you can write data directly to flash bank 7 using F021 Flash API. The flipped the flash content is caused by the invalid ECC for the un-used flash.

    1. You can enable EOCV of flash control register.

    2. or program the ECC of whole bank 7 from linker cmd file

  • So we currently clear the eeprom on the initial program using the linker cmd file, with ecc correctly programmed. That works, we also set the EOCV as well as the EZCV bit but we still see the random bit flips in the memory. It is also difficult to debug with the JLink debugger as the debugger isn't aware of memory changes till we reset the gdb server.

  • we also set the EOCV as well as the EZCV bit but we still see the random bit flips in the memory.

    After being erased, the EEPROM content is 0xFFFFFFFFF, so setting EOCV bit only is enough.

  • Does the Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, 0xf0200000) potentially cause the ECC values to be incorrect? I notice that the bit flips only in the sectors we have programmed data/ erased the sector in.

    Update: We tracked the reads and programs to the memory addresses and found that are failures are from not being able to overwrite a previously written address:

    In the below example the last write doesn't work and we read the previous value again. 

    '0xf0200000': [ 'write 0xf7ff0ff000000001',
                                  'read  0xf7ff0ff000000001',
    'read 0xf7ff0ff000000001',
    'read 0xf7ff0ff000000001',
    'read 0xf7ff0ff000000001',
    'read 0xf7ff0ff000000001',
    'read 0xf7ff0ff000000001',
    'read 0xf7ff0ff000000001',
    'write 0xf7ff0ff000000003',
    'read 0xf7ff0ff000000001']


  • Does the Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, 0xf0200000) potentially cause the ECC values to be incorrect?

    It erases the flash sector and its ECC space. The content in both memory spaces (bank 7 sector and its ECC space) are 0xFFFFFFFF, so the ECC is invalid.

    In the below example the last write doesn't work and we read the previous value again. 

    You can not write data to an un-erased locations (whose content is not 0xFFFFFFFF).