ESP8266 Community Forum

- Wed Sep 29, 2021 7:14 am #92484 I was going to put this in the Native SDK section, but I figure only well worn individuals would even know about this?

I am writing a replacement class for EEPROMClass to do wear leveling within the flash sector. I also want to write the class to detect and not use bad 4 byte regions. I see that spi_flash_read() and spi_flash_write() return errors SpiFlashOpResult for error and timeout. Can someone describe...

What causes SPI_FLASH_RESULT_ERR?
What causes SPI_FLASH_RESULT_TIMEOUT?
When flash is getting worn out, what happens when some region is faulty? I assume it causes one or other of those errors. I also assume it does not cause a reboot of the ESP8266? BUT - I hate to assume.

Thanks.

3 lines of code = Complete IoT, App, Web Server
w/ GUI Admin Client, Drag & Drop File Manager, OTA Built-In, Access Point Manager,
Performance Metrics, Web Socket Comms, App API, All running on ESP8266...
Even usable on ESP-01S --- Please check it out!
https://inqonthat.com/inqportal-the-three-line-promise/
https://InqOnThat.com/inqportal

- Wed Sep 29, 2021 7:53 pm #92490 You might be interested in the snippet I posted right at the start of this forum area

https://www.esp8266.com/viewtopic.php?f=166&t=19530

- Thu Sep 30, 2021 7:08 am #92492 Thanks, confirms some of the things I've read or am figuring out by trial and error.

Although my code is written generically, I plan on its first use as the EEPROM replacement and setting it to use just the one (and same sector) as EEPROM. I have a similar round-robin methodology, however, I don't need the param/value pair scheme and I don't overwrite the old data. This saves that extra write on the flash. This, as of this morning is working. I'm still continuing the research on what happens when flash goes bad... (1) in general how it behaves and (2) how do Espressif's routines respond when it does.

As I was writing the O.P. I was debating about asking if anyone had any old ESP8266's with known bad flash portions and thought the logistics would be a headache getting them. Later had the epiphany to just make my own. I have a bunch of ESP-01s just gathering dust and hammering one didn't seem that big a deal...

I have the full sector (4096) erasing, writing, reading, validating... in hopes of finally getting some bad memory location errors and actually see what I'm looking for. AND then to develop and test handling such errors. I'm glad I did, I'm finding some other things out that I haven't seen on the Internet.

(1) The Abuser is nearing 600,000 cycles - While the Internet says 10,000 to 100,000 is a reasonable expectation.
(2) Its slowing down - When it first started, it was able to do 18 cycles/second, now its around 4 cycles/second. Although the Internet mentions slowing, it usually suggests that its more related to fragmentation, on-going re-ordering, but never about the actual process of writing getting slower. I'd really be interested in the actual science describing why a worn memory location take longer to write than fresh one.

Attachments

3 lines of code = Complete IoT, App, Web Server
w/ GUI Admin Client, Drag & Drop File Manager, OTA Built-In, Access Point Manager,
Performance Metrics, Web Socket Comms, App API, All running on ESP8266...
Even usable on ESP-01S --- Please check it out!
https://inqonthat.com/inqportal-the-three-line-promise/
https://InqOnThat.com/inqportal

- Thu Sep 30, 2021 10:23 am #92496 Flash memory becoming slow after time, is only applicable to SSD disk drives. It has nothing to with flash chips in itself.

The flash chips commonly used for ESP8266 don't have magic faulty sector replacement like an SSD does. If the sector is bad, it's bad and remains bad.

For a few months now I am running a script that uploads a picture to two ESP's every half our. Until now, I have not seen errors.

I agree that the actual life cycle of most flash memories is probably way higher than specified for. I have never had flash erase or write errors.