• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 1032 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LP-MSPM0L1306: Emulation EEPROM using FLASH

vamsi krishna
Prodigy 50 points
Part Number: LP-MSPM0L1306
Other Parts Discussed in Thread: MSPM0L1306

HI,

I was looking to store the configuration parameters into the Emulated EEPROM, I was working with the Example code emulation_type_b where i can run that successfully and i can see the data stored in location start from 0x0001000 from memory browser. but how can i conform that data still there in flash after power of and on.

I have tried loading data @ 0x00001000 1st and stopped the debugging then run the debugger again this time i was expecting to see the previously loaded data in memory browser before loading the data again but it was all default values 0xFFFFFFFF

can anyone help here

  • +1
    TI__Mastermind 28070 points

    Hi Vamsi,

    Just as a heads up, the EEPROM examples are early revisions and will likely still need some additional testing and updates. That said, you should still be able to see the results of your previous write in flash memory. When the debugger is launched the second time, it is probably just erasing all of non-main flash and then reprogramming.

    After you debug/run the first time, but before you launch the second debug session, you should change your debug configuration (shown below) for that project so it is set to Load Symbols Only. 

    Make sure you click apply so the changes are preserved. On next debug you should still be able to see the data written to this memory location. 

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 50 points

    That worked thanks Brandon, but when I run the debug with this config it stucks in default handler's while (1) is that expected? if so, can I know why 

  • 0 in reply to vamsi krishna
    TI__Mastermind 28070 points

    Hi Vamsi,

    Have you modified anything in the project in any other ways? This isn't exactly expected but I have seen it on this example before. Specifically in the past I have seen this from hard faults related to Flash memory access. 

    To explain further, this example currently runs fully from flash, and also write to the same flash bank. Typically we would want to run functions which run while we are writing to flash from SRAM. This is planned to be fixed in a future update, probably with some reorganization of the DL_FLASHCTL library. If you need to do this in the short term for validation, it can be done with some modifications to the linker and the example/driverlib code to put the correct functions in SRAM. 

    Best Regards.
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 50 points

    Hi Brandon,

    I have changed base address from 0x00001000 to 0x0000E000

  • 0 in reply to vamsi krishna
    TI__Mastermind 28070 points

    Hi Vamsi,

    I don't see an obvious reason why that would cause you to hit the default handler, but we can do a quick check by running your code from SRAM to see if its related to what I described. The issue I described does sometimes have this symptom where seemingly unrelated code changes can cause faults. 

    Inside your linker command file (mspm0l1306.cmd), change the highlighted code below from "FLASH" to "SRAM". Then load and run the code again. 

    This will put all of your program into SRAM instead of Flash, and should hopefully allow you to hit the end of program breakpoint. 

    Best Regards,
    Brandon Fisher