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.

TM4C1290NCPDT: Internal EEPROM

Part Number: TM4C1290NCPDT

Hi,

In our application development we are using TM4C1290NCPDT customized board.

Internal EEPROM we configured with protection & password lock mechanism. Using PROT -0x0 

We have loader & application. In application we wrote some value in EEPROM & locked the block. After reset if we read data from internal EEPROM it is getting 0xFF.

After reset If we do unlock with password only getting correct data  MAP_EEPROMBlockUnlock() .Is it expected behavior?

But as per data sheet if we use PROT as 0 read should work without password.

and in data sheet mentioned , 

After reset without MAP_EEPROMBlockUnlock() function read will work or not? Can you help on this?

  • Hello,

    After reading through your post I get the general issue here.

    Can you share the code you are using for this process so I can try and re-create the issue on my end?

    That would help me investigate this quicker.

    Best Regards,

    Ralph Jacobi

  •  We configured internal EEPROM with protection & password lock mechanism. Using PROT -0x0.

     MAP_EEPROMBlockHide(block) function we used to hide only one block of data. We are not locking block0, But in some cases it made block 0 to lock. So while reading always getting data as 0xFF.

    As per data sheet PROT - 0 will allow to read with out unlock. In our application we are facing some issue after reset if use MAP_EEPROMBlockUnlock()  only getting correct data.

    Is it any specific reason the block 0 gets locks? How to avoid the above scenario?

    In our application block0 never used.

  • Hello Thalapushpam,

    I haven't used the EEPROM in this manner before so I don't have any firsthand insights about what is occurring. That is why I requested the code you are using to cause this error so I can try and replicate the error in order to further debug and make a determination about what is occurring and how to avoid the issue.

    Best Regards,

    Ralph Jacobi