Follow up on the EEPROM write/erase cycle limitation discussions on the ASCII>Char conversion thread
I’ve had a 3.2" Enhanced Running an EEPROM stress test for a number of weeks now. It simply stores a running cycle count, writes that count to EEPROM address 500 (4 bytes), reads the address back out to verify written data then indicates any errors found. Every 10,000 cycles in inserts an additional 10 second pause between the write and read operations and every 100,000 cycles it inserts a 3 minute pause (to look for loss of data integrity was wear accumulates)
Here are the results:
The top line is the current cycle count and write value.
Seconds line is the last read value returned from EEPROM address 500.
Third line is location of 1st write/read error
Fourth line is number of write/read errors
Notice that the 1st error occurred at 11,300,000 which is just over the 10M rating of the EEPROM chip and FAR in excess of Nextion’s stated 10K limitation.
Data Integrity Over Time
Also note that the cycle count of the first error is divisible by 100k so a 3 minute pause was just taken after the write operation before read/verify taking place. The previous write/read at 11,299,999 was obviously fine as was the previous 10 second pause at 11,290,000. This indicates that symptoms of wear on Nextion EEPROM match those common to other EEPROM failures - an overly stressed location first shows shortened storage times (starting at years then eventually down to minutes and even milliseconds). At 10M write/reads I disconnected power from the device for 7 days and the data at this location was still viable. Sometime after the 10M cycle data integrity began to fall from at least 7 days to just 3 minutes by the 11.3M write cycle. By the 15M cycle errors began to show up after only 10 second delays and by 20M cycles the data wasn’t lasting even 50 milliseconds before corrupting.
A few interesting things to note as well as some other inaccuracies uncovered with official documentation:
EEprom Error Message / bkcmd Return Data
Notice the red “EEprom Write Error” message displayed in the upper left corner of the screen. This is NOT a feature from the stress tester’s code. This message is being directly displayed by the Nextion firmware itself. Once displayed operation pauses for a couple seconds then the message clears and operation resumes. The “EEPROM Operation Failed” Return Data is also sent over serial (0x1D 0xFF 0xFF 0xFF) regardless of the bkcmd setting (official docs show setting bkcmd=0 should prevent this return data on EEPROM write errors).
Nextion Verifies Writes
The red error message and the EEPROM Failure return data occur immediately after the WRITE operation itself, not when attempting to read the location. It appears the Nextion wepo EEPROM write operations automatically include a read/verify step. This can be used to verify EEPROM integrity.
Wear is localized
After data failure began to regularly show at EEPROM address location 500 at 20M cycles, I stress tested the adjacent cells at 496 and 504, each four bytes wide) and found zero signs of wear. This indicates that the Nextion utilizes the more efficient byte level erase/write operations rather than page level which limits any wear to the specific bytes being erased/written.
In light of the 10M+ cycle counts, byte localized wear and automatic error detection I now feel confident that setting aside address space in EEPROM for dedicated byte swap operations between different variable types (such as ASCII conversion) is safe and reliable (in addition to quick and simple).