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.

MSPM0G3519: EEPROM emulation init issue

Part Number: MSPM0G3519
Other Parts Discussed in Thread: SYSCONFIG

Hi, 

I am trying to use the EEPROM emulation (type B) on my MSPM0G3519. However, I can't get it to start properly.

The whole point of EEPROM emulation is to keep some data on reset. However, all examples I have found in the MSPM0 SDK start with the EEPROM emulation init, which wipes the memory. Hence, no data from before the last reset is kept.

I have tried a lot of things, but I can't get things to run and save data from one reset to the other.

Thanks in advance for your help,

Best regards,

Adrien Thurin

  • Have you tried not running under the debugger? If you reprogram the flash it will erase anything you have set aside.

  • What I do to test is I launch a debug session, and a some point unplug the debugger and reset the MCU. Then plug the debugger back in, and reconnect the target (without leaving the debug session at any time !). This way, the flash is not erased, and I should see the stored data. However, the flash is blank.

    Also, I can see in the source code that the EEPROM init function is always called when starting the code in the examples, and the init function erases the flash. So in the examples, the eeprom region is always erased by the software at the beginning, which is precicely my issue.

  • Hi Adrien,

    The EEPROM Emulation (Type B) init function is designed to format the allocated flash area by default, which can wipe previously saved data upon power-up. To retain data across resets, you must modify the EEPROM_TypeB_init() function in the SDK library to prevent formatting the flash if it has already been initialized. To do this:

    1. Find the library's EEPROM_TypeB_init() function source file (usually under the middleware section in your MSPM0 SDK path).
    2. By default, the initialization function performs an erase and format sequence. You need to wrap the formatting/erase operation in a check. Instead of blindly running the format sequence, you should only initialize the global variables to track active records from the existing Flash memory if it is already formatted.
    3. Check the first few bytes of the EEPROM data bank. If it contains valid programmed data (e.g., does not read 0xFFFFFFFF), bypass the erase and allow the firmware to scan and load the existing active groups

    I would also recommend reviewing the Emulate EEPROM With FLASH (Type B) Design Guide for a clearer understanding of how the SDK handles searching and restoring group states.

    -Brian

  • Hi Brian,

    Thanks, I will test that and let you know.

    In the meantime, is it possible to tell CCS not to wipe the part of the flash that is dedicated to the EEPROM emulation ? So as to make testing easier.

    Thanks in advance, 

    Best regards,

    Adrien

  • By default, placing your EEPROM section inside a standard .cmd file will tell the debugger to program and overwrite it. To stop CCS from overwriting this during a download, exclude your EEPROM sections from the generated .cmd linker file. Alternatively, you can use SysConfig in your project settings to uncheck "Linker File Generation," create a custom linker script, and ensure the EEPROM memory ranges are listed only as input sections rather than output files to be written. 

    These are a couple of suggestions, hopefully this can help in the meantime!

    -Brian

**Attention** This is a public forum