support for W25Q128 flash chip

[stephaneAG]

Hi

I had few ESP-01 handy as well as a Winbond W25Q128 flash chip, so I decided to give the flash replacement procedure a try before running on it the latest Espruino firmware ( .. )

The last step being actually flashing the chip, I'm now wondering how to mod esptool.py to support it ( .. )

If any hint on those, feel free to give me an update ;)

https://github.com/stephaneAG/EspruinoDocs/blob/master/tutorials/ESP8266_FlashUpgrade.md

keep up the good work ;p
+

[projectgus]

Hi stephane,

Interesting hack!

I think from the esptool.py side it should more or less "just work" as a 32mbit chip. The flash-size parameter is for the software & ROM routines on the ESP to know how large the flash chip is. 32mbit (-fs 32m) is the largest supported by the Espressif SDK (and possibly also the the ROM bootloader will check this value). There are no other constant values supported by the SDK to indicate larger flash sizes.

So, to begin with, I'd suggest just flashing with -fs 32m and make sure it works that much.

Regarding actually using the extra 96Mbits of flash, I believe all of the ROM SPIErase/SPIWrite/etc routines check a data structure in RAM called "flashchip" (initialised by the ROM) to determine the flash size and whether an operation is out of bounds. You could try overriding this value to trick the ROM routines into letting you attempt operations on higher offsets.

However, I also suspect (I don't know for sure) that the SPI hardware may not support addressing beyond the number of address bits required for 32Mbit. So requesting past this address may just wrap the actual SPI operation, so it returns back to the beginning.

If this turns out to be the case, you could always write your own SPI access routines that talk to the hardware directly instead of via the ROM functions...

If you have a logic analyzer, tracing the SPI flash commands while messing with the bootloader stub is probably a place to start. That way you can see exactly what is going out to the chip each time.

Good luck! :)

Angus

[projectgus]

Hi @stephaneAG ,

How did you go with this? Is there anything you think we can/should add in esptool.py to support oversize flash of this kind? Otherwise I might close this issue.

Angus

[pfalcon]

There're now off-shelf modules with more than 4MB of flash. I'm in particular concerned with how auto-detection works on them - it's rather unpleasant (for a user) when his 16MB device treated as 0.5MB. That's why implemented auto-detection the I did originally, so any unknown flash ID leads to error with all info which a user can report and get resolution. The way you requested it to be changed, auto-detection is not reliable and can give a user headache, as well as anyone who supports software on wide variety of modules.

I'm going to look into this, but it probably will take as much time as between auto-detection RFC and actual implementation.

[projectgus]

Do you have some URLs or flash ids for the modules which are shipping with 16MB?

[pfalcon]

Wemos Pro or how they called it. It now lies in my board dump along with dozens of other boards and in few months I'll get to power it up and read the ID.

[mcauser]

WeMos D1 Mini Pro:
https://www.wemos.cc/product/d1-mini-pro.html
Features a WinBond W25Q128FVSG.

$ esptool.py --port /dev/tty.SLAB_USBtoUART -b 115200 flash_id
esptool.py v1.2.1
Connecting...
Manufacturer: ef
Device: 4018

[marcelstoer]

32mbit is the largest supported by the Espressif SDK

I was told that according to the ESP8266EX data sheet it supports max 128mbit. The advent of those 16MB WeMos modules kind-of proves that.

The NodeMCU firmware project still hosts its own copy of esptool.py (don't ask, I don't like it). It has had partial support for 64m and 128m since June:
nodemcu/nodemcu-firmware@7ecd625#diff-e6e8c9cf42985f99554a22a8a34b90e4 I say partial because I don't see how that quick-fix would play nice with auto-size detection.

[sandmarq]

I have the same WeMos d1 mini pro and I was wondering if anyone had any plan to look at this issue.

./esptool.py --port /dev/ttyUSB0 -b 115200 flash_id
esptool.py v2.0-beta1
Connecting....
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Manufacturer: ef
Device: 4018
Hard resetting...

I was able to flash it by forcing it to use only 4M of the 16M.

[marcelstoer]

Any chance this will be included in 2.0?

[projectgus]

Any chance this will be included in 2.0?

Sure. If the ESP8266 ROM bootloader is happy with these new flash size header values (0x80 and 0x90) then we can add these as well. If that's the case, could you please send a pull request which adds these same values as used in nodemcu's fork?

[devsaurus]

Current master correctly detects the 16MB flash but aborts with an error message that this size isn't supported by the chip. This seems to be too restrictive, but are these new flash size values (0x80 and 0x90) supported by the SDK? IMO there's not much use in introducing new values if the SDK can't determine the location of the init data from them.

AFAIK the existing solutions for Arduino and NodeMCU apply some kind of tweak to use the module in a "known good" configuration like 4MB or 1MB. Guess a 100% clean approach needs support from the SDK for 8/16MB, anything else is a workaround.

My proposal for "8/16MB support by esptool.py on ESP8266" is to turn the error-and-abort condition when >4MB is detected into a warning and set the flash size to e.g. 1MB automatically. Any tweaks in the firmware are still required for sure - just the flash autodetection shouldn't block downloading anymore.

Any objections / additions? I'd come up with a respective PR.