TM4C1294KCPDT: Arm-based microcontrollers forum

Maccabi Luz

Part Number: TM4C1294KCPDT

for some time we are noticing a serious problem where the system starts up and it reads the eeprom values after eeprom init.
( SysCtlPeripheralEnable(SYSCTL_PERIPH_EEPROM0);
EEPROMInit(); )

EEPROMRead((uint32_t *)&eepromStruct, 0 , sizeof(eepromStruct));

from time to time one or more of the values is 0 and not as saved a week or a year earlier. Very problematic !!

writing is not the problem if I am doing it right and it seems to be right.

EEPROMProgram((uint32_t *)&eepromStruct, 0, sizeof(eepromStruct));

should I use a different address instead of 0 ? as I read the first part of eeprom is vulnerable or sensitive? actually what addresses should/can I use?

I read this in a post by Robert Adsett (5 years ago)

"I have had experience with EE failures, particularly under power fail and high EMI conditions, where a failure due to a power off or interference could cause writes anywhere in the device. I have heard of devices that if interrupted during power down the failure would preferentially affect the first locations (some people reserve the first few locations for that reason) "

so maybe I should start writing on a higher address.

TIA

Maccabi

over 1 year ago

0 Ralph Jacobi over 1 year ago

TI__Guru*** 128255 points

Hello Maccabi,

Maccabi Luz said:
I read this in a post by Robert Adsett (5 years ago)

"I have had experience with EE failures, particularly under power fail and high EMI conditions, where a failure due to a power off or interference could cause writes anywhere in the device. I have heard of devices that if interrupted during power down the failure would preferentially affect the first locations (some people reserve the first few locations for that reason) "

Robert did say this however he prefaced by saying:

"Bob will have better sources about the TM4C in particular but let me share some field observations from other devices."

So that statement was not indicative of his experience with EEPROM with TM4C129x devices.

If you are using a TM4C129 device then the only cause I can initially think of is Errata MEM#07. I am not certain if that could be applicable for your case.

Beyond that, there should not be an issue with any particular address being more vulnerable than the other. That is not an issue we have seen occur with TM4C129 devices at any point.

One other step you can take is adjust your startup procedure to make sure the EEPROM is initialized properly:

    //
    // Enable the EEPROM module.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_EEPROM0);
    
    //
    // Wait for the EEPROM module to be ready.
    //
    while(!SysCtlPeripheralReady(SYSCTL_PERIPH_EEPROM0))
    {
    }
    
    //
    // Wait for the EEPROM Initialization to complete.
    //
    ui32EEPROMInit = EEPROMInit();
    
    //
    // Check if the EEPROM Initialization returned an error and do not
    // proceed if so.
    //
    if(ui32EEPROMInit != EEPROM_INIT_OK)
    {
        while(1)
        {
        }
    }

Best Regards,

Ralph Jacobi

0 Maccabi Luz over 1 year ago in reply to Ralph Jacobi

Prodigy 150 points

Thanks for the answer Ralph,

I do have something missing:

while(!SysCtlPeripheralReady(SYSCTL_PERIPH_EEPROM0)) !!!

I hope that is the fix to my problem.

From your experience, could this be the reason for my problem?

Regards,

Maccabi

0 Ralph Jacobi over 1 year ago in reply to Maccabi Luz

TI__Guru*** 128255 points

Hello Maccabi,

I haven't seen your particular issue occur before so I can't really say from personal experience but given the best practice to properly initialize the EEPROM includes that step which differs from standard peripherals, it is possible prior device experts had observed your issue and the best practice was implemented to avoid such. I just don't have that background to comment with certainty.

Best Regards,

Ralph Jacobi