ESP8266 flash write cycle limit

[GelirDurum]

I have a problem with ESP8266 12E and 12F series about write commands. When I need to write data to the flash in ESP8266 it only allows to around 6800 times with (w+) command. I am using both integer and float and lastest and previous firmwares but nothing changes. An example simple code is below. With ESPlorer I run the codes and when both test1 lua and test2 lua reaches to 3400 file system starts to reset the module. I only activate module by formatting it. If I use just one file it reaches around 6800 cycle of writing. With (a+) command and 2 files I only managed to write up to total 13600 number somehow. Then again a format is needed. I do not how to erase and where to erase flash form lua file. Any help would be appreciated.

test=0
tmr.alarm(6, 100, 1, function() 
             file.open("test1.lua","w+")       
              file.writeline(test)
            file.close()
             file.open("test2.lua","w+")       
              file.writeline(test)      
            file.close()

            test=test+1
end)

[akalinin-ms]

I have this problem too. And in native C (not only in lua module).

[pjsg]

On lua, does the module reset? If so, then can you provide the output of node.bootreason() and the contents of the mapfile that was output by the build.....

[akalinin-ms]

I have other observation(suspicion). With SPIFFS_DGB. I saw next picture.

page index byte len:         256
object lookup pages:         1
page pages per block:        16
page header length:          5
object header index entries: 107
object index entries:        125
available file descriptors:  4
free blocks:                 135

All static but except "free blocks".

free blocks:                 133
free blocks:                 131
free blocks:                 129
...

free blocks:                 5
free blocks:                 3
Reset reason: REASON_EXCEPTION_RST
free blocks:                 3
Reset reason: REASON_EXCEPTION_RST
...

"free blocks" have leaks. It is happened if we run timer once and reset device. Sorry for my bad grammar.

[pjsg]

I'm trying to debug this issue -- I suspect that it is another alignment error. It turns out that the current version of spiffs from the master repo has a (difference) alignment error in it. Unfortunately, I'm finding it difficult to build the nodemcu flavor of spiffs with the testcases. I'm trying to build it on my linux system. The other option would be to move to the newer version of spiffs and move it over, being careful not to edit most of the files (to make it easy to bring new patches over in the future).

Thoughts?

[devyte]

For what it's worth, in my experience, it pays off in the long run to bite the bullet in these cases, meaning go to the newer spiffs version, and pave the way for easier upgrades later.

[pjsg]

I suspect that you are right -- but this will require significant testing. I'm reluctant to do this in a hurry. The good news is that there are some changes in the base source to deal with systems that have alignment constraints.

[GelirDurum]

I try same code with dev branch for 30 hours. I wrote over then 1000000 cycle. Dev branch have no error for this issue.

[akalinin-ms]

I found my fix: pellepl/spiffs@7c54937

My spiffs before fail on spiffs_gc_check when fs.free_blocks < 3.

[akalinin-ms]

I suggest to take over the bug fix for pellepl/spiffs@7c54937

[pjsg]

My feeling is that we want to take the real spiffs master code rather than cherry-picking individual commits. However, the spiffs code currently fails the spiffs self-tests when using our settings for block/sector/page sizes. I filed a ticket: pellepl/spiffs#77 for them to investigate.

[pjsg]

With the new master code, the lua code above runs for over 6300 iterations before I got bored. This would seem to be an improvement! There will be a PR for this fix soon.

[TerryE]

Philip, the OP quoted 6800 as the failure point.

[pjsg]

The 6800 was with one file, it was 3400 with two files as in the sample code (or at least that is what I understood)

[jmattsson]

@pjsg The spiffs version used in spiffsimg matches our current NodeMCU version and does run the test suite, if that helps?

[pjsg]

There is a format change in the latest version of spiffs. I was thinking of binding the spiffsimg code much more tightly to the nodemcu code -- making it use the same set of sources so that we are assured that it is binary compatible.

[pjsg]

I ran the test for 32000 cycles -- still working fine!

[TerryE]

Philip, have a look at my luac.cross patch. This works the issue of how to dual use, in ESP and on host.

[marcelstoer]

Fixed by #1226.