Bad flash writes with v1.5.1 (increased power usage???)

[rab]

I've found that flash writes sometimes fail (silently) with sdk v1.5.1, but they used to work fine with older sdks. Some users of rBoot have noticed this and I have been able to reproduce it myself just by recompiling with sdk v1.5.1. All the spi_flash_write calls return success, but after writing a rom (~250k) there may be one of more unwritten areas (0xff) in the flash. The number, position and size of the unwritten area varies each time.

I have seen this before when users have not had enough power - too few mA from their power supply - to flash and use wifi at the same time (and the write still does not return an error). Now it is happening on devices that were fine before sdk v1.5.1 so I suspect that the new sdk is using more power than the old version.

To make it worse if you try to read the flash back to check the data is correct, it appears to come from the cache and so it looks fine (but if you use esptool.py to read the flash you can see it is bad). This means it is not possible to check the write worked at all!

Can you advise on how to fix this?

Richard.

[ESP_Faye]

Hi,

Sorry that we could not duplicate your problem, could you provide your test code for debugging ?

[rab]

I have created a (fairly simple) test case:
https://github.com/raburton/flashwritebug
Instruction are in the readme.txt
I have tested the code with the new v1.5.2 sdk and the bug is still there. The flash write gets blocks of 0xff bytes (I assume these are erased, but not rewritten) in the middle of the file. This seems to happen on any sustained write, so I assume it will affect the sdk bootloader ota write just as much as as rBoot ota.

Richard.

[rab]

p.s. examples of bad writes are included on github so you can see what has happened.

[henkep]

This is of great concern for us as we are using rBoot and are now left in a situation where we can´t upgrade to any of the newer SDK´s since OTA fails every time for us using the newer SDK´s.

//Henrik Pedersen

[rab]

Any update on this bug? It's causing a real problem for users and preventing upgrade to latest SDK.

[piersfinlayson]

I can reproduce this with Richard's test app. I notice that in all failed cases the "unwritten" bytes (the 0xff bytes) start at the start of a sector. Given the way the test app works I'm wondering if spi_flash_erase_sector is returning before completion and actually being applied after the spi_flash_write which immediately follows it (and straddles sectors), although this sounds rather odd.

I wrote my own simpler test app to see if I can repro it with that. I can't so far. The key different being my test app isn't doing anything active with the network, so not drawing as much power.

[giox]

Same problem here on both ESP-01 and ESP-12.

[ESP_Faye]

Hi,

Please have a try with the attachment based on ESP8266_NONOS_SDK_V1.5.2.

If your problem is still unsolved, please feel free to let us know.

[rab]

Sorry, but the problem is not fixed. I still get intermittent bad flashes with the test application on github when using the new library.

Richard.