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.

EK-TM4C1294XL: Permanent variables: stored in Flash or EEPROM?

Part Number: EK-TM4C1294XL

Hi to all,

and thanks in advance for your support.

I am just playing to store a small struct into permanent variables. The user will introduce this data and then, this data should be permanent stored, then I will need to be able to read again this data after cycle power.

I read in some treads to use a Flash, and I see the Flash_pb in the utilities library from Tivaware. But My question is about were is better to store this "permanent variables", in the flash? or in the EEPROM? 

I am usingt TM4C1294XL Launchpad, with Windows 7, CCS 7, compiler TI v16.9.1LTS.

Thanks in advance to clarify me this misunderstanding.

Jordi

  • Jordi,

    I'll try to make this text basic for future readers. As you are aware, both FLASH and EEPROM are non-volatile memories - as in "they supposedly keep the values when no power is applied".

    First comment: if your data is REALLY critical to your application, then you should consider external devices to store the values. Neither flash nor eeprom on these MCU's are "eternal". You probably saw the discussion on your recently commented note at the link below:
    e2e.ti.com/.../250463

    I prefer to use FRAM: this kind of memory has a VERY long life, a HUGE endurance, and requires very little power when you are writing into them. Of course, they are more expensive. Some TI MCU's (on the MSP family) even come with FRAM inside them, so if your project is not too much about processing power, if you are looking for a small solution, low power consumption, consider those. Other external NV storage options are external eproms and FLASH.

    For general "system configuration" NV parameters, I particularly use the internal eeprom. Why do I choose that against Flash?

    - No need to configure a separate storage area on the linker settings of the project, no need to force memory regions with pragmas.
    - Possibility to write smaller chunks of memory (to write a few bytes on flash, you will need to read a big chunck into RAM, merge with the new content, and then write the whole chunk back into flash).
    - If I'm not wrong, the overall processing of eeprom is faster and takes less power too - but that ain't too critical, for the actions of saving parameters are very rare on the overall product usage.

    On TM4C's, eeprom is said to have an endurance of 500,000 writes at least. It can be improved if you apply strategies of cycling through different pages, and other tricks. I did a quick search for Flash endurance on the datasheet, but couldn't find it - it was actually less than that if I'm not mistaken.

    So, the cons of using flash can be deducted above. On the other hand, there is much more space available in Flash memory. Another advantage of flash is that you can "directly see its content" on the debugger, or use the location as a pointer (which might become an actual disadvantage, for it is "less protected").

    Anyway, we have been having excellent results with eeprom. The configuration structures here are not even 100 bytes. As your eeprom library evolves, you should create checksum verification allied to some sort of "confirmed" mirrored storage, so that you never loose valid data. To be honest, in our case, all we do for now is to re-read eeprom after saving a structure, and confirming that the value matches.

    You did a much nicer "title selection" now! This might ignite some interesting comments.

    Cheers

    Bruno
  • Hi Bruno,

    Thanks for your comment, really appreciated. I am a beginner into this, so thanks for the suggestions about the forums.

    I am aware the life endurance of the EEPROM, but as this parameters are only for storage some settings, if I take in account the user use, it could take more than 70 years to loose this data. I think the system will be changed before the end of life of the EEPROM. I will take care about the data verification.

    I wrote this question because there are many places and treats talking about the Flash, but no many people talk about EEPROM. Thanks for clarify it. Really interesting.

    Jordi
  • Let me add a few comments

    Bruno Saraiva said:
    Neither flash nor eeprom on these MCU's are "eternal".

    This means that neither is your program. The life of flash/EE matches that of the micro's useful life as far as retention goes. Read/write cycles is a separate question.

    Bruno Saraiva said:
    I prefer to use FRAM: this kind of memory has a VERY long life, a HUGE endurance, and requires very little power when you are writing into them

    It is also orders of magnitude faster. A maximum write time of  ns for FRAM, ms for external EE and seconds for internal TM4C 'EE'

    This is a positive improvement in reliability as well since a write cycle should start with the NV memory write protected and end with it protected again. The FRAM devices keep the window of the memory not being write protected the shortest.

    Bruno Saraiva said:
    On TM4C's, eeprom is said to have an endurance of 500,000 writes at least. It can be improved if you apply strategies of cycling through different pages, and other tricks. I did a quick search for Flash endurance on the datasheet, but couldn't find it - it was actually less than that if I'm not mistaken.

    EE is actually emulated using flash on the TM4C. The emulation takes care of details like wear leveling etc... This will increase the typical lifetime.

    Robert