TM4E123GH6ZRB: Unwanted locked EEPROM

Hi Fabio,

Fabio Antonio CASSINI said:

- does TI kernel code (SYS/BIOS 6.35.04.50) ever access those registers?

I don't think so.  Are you using TI-RTOS in your application?

Fabio Antonio CASSINI said:

- could be for some reason that some chips came from TI with EEPROM already locked?

No.

I have some questions. Is the entire EEPROM locked or some blocks are locked? When you said the EEPROM is write protected, can you confirm that the NOPERM bit in the EEDONE register is set when you attempt to write? 

 Can you also setup watchpoint registers to watch for any writes from the CPU to the EEPROM registers? This will help debug if any CPU writes to the password registers. 

Thank you, Chrales,
your quick answer is very appreciated!

Here are my answers point by point:

- Are you using TI-RTOS in your application?
I confirm I use TI-RTOS.

- Is the entire EEPROM locked or some blocks are locked?
The entire EEPROM is locked: the NOPERM bit in the EEDONE register is set until I perform the Debug Mass Erase.

- Can you also setup watchpoint registers to watch for any writes from the CPU to the EEPROM registers?
I did it and I saw no such writes; take into account that this thing can not obviously work across Full Power OFF and then ON cycles.

Another questions that arises is whether any kind of electrical shock could cause the locking action: I am thinking about power bounces when power is suddenly removed...

Thank you again for your words: have a nice day!

Fabio

Hi Fabio,
Do you remember if you have any power loss or reset while in the middle of an EEprom write operation?

After you perform a mass erase, did the EEprom become locked right away with the first EEprom write or it becomes locked after many EEprom write operations? Basically, how long do you need to wait for the problem to occur?

Can you repeat the same behavior on other units you have?

Hi, Charles.

The true problem is that I could not reply that behavior under control: anytime we work on our development environments, no problems of that kind occur.

Actually there is the chance of a power loss during EEPROM write, because of possible updates of some permanent data; but we never experimented such a block; do you think power loss could be the cause?

We had about ten cases until now, and after Debug Mass Erase we never saw the problem again on the same part: it seems we have a sort of one-time event; in any case: unfortunately we just have not been able to reproduce the lock.

Just yesterday I heard of one specific customer stating that the malfunctioning we discovered due to this lock came after some time of our module plugged-in on their carrier: may be we can understand more analizing their hardware. More on this later...

Cheers

    Fabio

Hi Fabio,
Do you have any update since last time? Please be aware of the errata associated with the EEprom memory particularly the MEM#03, MEM#04, MEM#07.

Hi, Charles,

thank you for your attention.

We worked with the customer's carrier board, and we discovered there were problems due to a retarded LPC clock that caused malfunctioning LPC transactions; we are still not able to understand why and how this can cause the EEPROM blocking, and a few times we found the device Flash containing our code corrupted.

I gave a look to the errata you mention: I was aware of these possibilities, but until now we never encountered such a problem, and our certifications test also power interructions.

I will keep you in touch for any news... have a nice day!

    Fabio