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.

Access & manipulate EEPROM data while debugging in CCS (TM4C1294XL)

Hello everyone,

I was wondering If it's possible to manipulate data in the EEPROM during a paused debugging session in CCS.

I know there is a memory viewer available and I'm able to access&manipulate the internal RAM but not the EEPROM.

Is there a way?

Thanks a lot!

Regards,

Michael

  • Hello Michael,

    The short answer is yes you can modify EEPROM during debug; however, this has to be done by direct register manipulation via the debugger (manual implementation of the same process used by the driver code).

    The longer answer is really no; however, because this is really Flash emulated EEPROM which means that you are really only creating a new copy of the value which supersedes the old value. Each time you "update" or write a new value, note that the offset register will auto-increment to the next offset.
  • Hello Chuck,

    thank you very much for your answer. I see, but it sound's a bit difficult.

    By "direct register manipulation" you mean e.g. the way I access the registers of peripherals?
    Can you give me an example how am I supposed to access, e.g. the first 32bit word of the EEPROM?

    Thanking you in anticipation,

    Michael

  • Hello Michael,

    Yes, I mean the same way that you would access the registers of peripherals. Essentially, there is a EEPROM module on the device that has registers that are used to program and read the EEPROM data. This module is, more or less, a state machine implementing the memory management needed for flash EEPROM emulation and you would need to manually follow the same steps that the TivaWare APIs for EEPROM functionality have implemented in code. You are correct that this is not a user friendly way to do it, but is the only mechanism available during debug since the EEPROM is really a collection of flash sectors/banks on chip and has to be written using the appropriate process just as program flash or any other nonvolatile memory (aside from perhaps FRAM).

    For what purpose were are you looking to manipulate the EEPROM during debug? Testing?
  • Yes, I like to do this for testing purposes. I think I will add some test methods and jump there with "move to line" in CCS when I need them.

    Maybe you have the kindness to have a short look on my following code section:

    First I define the location/address for every 32bit uint in EEPROM:

    // EEPROM ADDRESSES:
    
    #define _SYSTEM_STARTS_ADDRESS_        0x400
    #define _RUNTIME_PUMP1_ADDRESS_        0x404
    #define _RUNTIME_PUMP2_ADDRESS_        0x408
    #define _RUNTIME_PUMP3_ADDRESS_        0x40C
    #define _HIGHWATER_COUNTER_ADDRESS_    0x410
    #define _HIGHWATER_TIME_ADDRESS_       0x414
    #define _LOWWATER_COUNTER_ADDRESS      0x418

    secondly, I call a method to update the uint value (e.g. for PUMP1 @0x404) once in a while:

    void EEPROMAddPump1Runtime()
    {
    	unsigned int pumpRuntime = 0;
    	EEPROMRead(&pumpRuntime, _RUNTIME_PUMP1_ADDRESS_, sizeof(unsigned int));
    	pumpRuntime++;
    	EEPROMProgram(&pumpRuntime, _RUNTIME_PUMP1_ADDRESS_, sizeof(unsigned int));
    
    }

    Is this a common way to define addresses & update the EEPROM, or is there a better solution to do this?

    I thought, to put them all in one "big" array (0x400 ... 0x418), but the workload to update just one value (e.g. 0x404) will be unnecessarily high, right!?

    Regards

    Michael

  • Michael,

    Your code looks like it should work fine. Another alternative is to remap the EEPROM APIs to some dummy area of RAM to test your code using data in RAM that can be modified on the fly. i.e., replace the EEPROM APIs with test stubs returning whatever data you want them to for reads and store where you want for writes.

  • If you are not already using TDD, I'd suggest adding it. It could lift some of this testing away from the micro.

    Robert