PIC18F Read/Write Reliability Test

[tarun172]

All,
    I am following up my previous about EEPROM memory read/write retention issue. See link below:

https://www.eevblog.com/forum/microcontrollers/pic-eeprom-memory-retention/msg1322750/#msg1322750

I believe I have a fix for this issue. I ran few tests and manually erased/wrote in EEPROM memory location at-least a dozen times. Is there a way to automate this test? I am thinking of writing a script.

 - Tarun
 

[JPortici]

did you find out the actual cause of the problem? (which PIC18? that is a very important detail)

[picandmix]

Hi,

I ran reliability tests on Pic18F Eeprom many years ago, it ran for 400,000 cycles before I was able to get just one single byte to fail.

Have pic18f  projects running for years , saving and read out data daily, no problem.

You only  have to look at the datasheet to see that 100,000 is the minimum Microchip specify, typically 1m.

Your original problem is clearly related to your code and / or a hardware problem, neither of which we know anything about.

Why not post your code and hardware design and chip number and we may be able to help overcome the problem ?

[@rt]

To test a single location you could write 0x00 to it, and verify that by reading it back.
Anything other than zero in the read buffer means at least one bit failed.

You could come up with your own brand of wear levelling by shifting the data you’re saving,
one length of the data you’re saving to the right, every time you save it (assuming small data compared to EEPROM space).
The rest of the EEPROM should be 0xFF, and you can search from EEPROM location zero for your data when you read it.
Also assuming you can suffer the performance hit of potentially reading the entire EEPROM.

[MarkF]

To test a single location you could write 0x00 to it, and verify that by reading it back.
Anything other than zero in the read buffer means at least one bit failed.

There are many ways a location can fail.  I would at least do an all zeros, all ones and alternating bits sequence (i.e. 0x00, 0xFF, 0x55, 0xAA).  A more aggressive test could add a rolling 1 (all bits 0 with a single bit set to 1) through the location followed by a rolling 0 (all bits 1 with a single bit set to 0).

[@rt]

I forgot you may fail to erase a byte (if that happens).
Do locations actually fail to erase?

Also for the wear levelling, 0x00 and 0xFF could both be valid data,
so the actual data being saved might need a magic header to identify it.

[MarkF]

You could have a bit that is stuck high or stuck low (all high and all low tests).
Also, the bit could be shorted to an adjacent bit (alternating high/low tests and rolling bit tests).

[tarun172]

@JPortici, Still trying to determine and re-create the issue. Few months back, I spent few days chasing this problem. Clearly, EEPROM write is getting executed very often (more often than I want and anticipate), enough to cause this failure. I moved that portion of code and added flags to track EEPROM write execution so that it does not execute often. I thought for sure that I fixed the problem.For a long time, I did not see this problem. But clearly the problem is not resolved.

@rt @MarkF: Would you think frequency erasing and loading new firmware may cause this issue since I am working on and adding new firmware? I am using MPLAB ICD3 programmer.

[TechieTX]

I forgot you may fail to erase a byte (if that happens).
Do locations actually fail to erase?

Yes, that can happen.  I've designed a bunch of different device programmers over 3 decades, and one of the failure modes was trapping electrons in the oxide layer.  If they're hot enough (high enough energy), they jump the floating gate gap.  If they're merely warm, they don't, or not far enough. That can leave a partial charge trapped on the edge of the gate that might be seen as 'programmed' by the sense amp, and isn't erasable with tunneling erasure.  Sometimes another erase cycle will clear it.

I did one programmer for a (Philips or National) micro that was amusing.  I was careful in the design to match the programming specs, including the sharp rise-time required for the VPP pulse.  My board was in production for a few months when I got a call from the apps engineer for that product line, wondering if I'd done anything 'special' when I created the cheap programmer board.  Nope! I replied, and told him I'd been surprised to see that nearly all of the cells programmed with the first group of programming pulses, and the few remaining cells programmed by the end of the second group.  The apps engineer said "Yeah, we know..." with a pregnant pause.  I said "Wow, if you've been into it at that level, then you probably know more about that programmer circuit than I do."     Turns out NOBODY had been able to program that batch of parts reliably except *me*, and my programmer never produced a bad chip.  They'd hit the cells with a bunch of groups of programming pulses and the gates wouldn't program, still reading ERASED.  I never did hear how they fixed that issue, but I'm guessing they spun the silicon one more time.

[tarun172]

Thank you everyone for your inputs. I found spurious writes to two different places in my firmware. This caused EEPROM writes up-to 1000 per minute!! Working to fix this problem.