Let's Control It

Posted: **18 May 2022, 19:20**

Hello everybody,

I just received my first 2 ESP-32 with 16MB flash. Of course, I didn't wait a microsecond to load the "max" version of ESPEasy firmware but I couldn't be successful. Those are my test results:

- The modules are ESP32-WROOM-32E and ESP32-WROOM-32UE both with 16MB flash.
- Those are the output of esptool flash_id option:

For ESP32-WROOM-32E

Code: Select all

esptool.py v3.3.1
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:c6:f7:ed:62:e0
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4018
Detected flash size: 16MB
Hard resetting via RTS pin...

For ESP32-WROOM-32UE

Code: Select all

esptool.py v3.3.1
Serial port /dev/ttyUSB0
Connecting........
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 10:97:bd:cb:ab:64
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4018
Detected flash size: 16MB
Hard resetting via RTS pin...

- I have loaded a "max" firmware:

Code: Select all

$ ./esptool/esptool --port /dev/ttyUSB0 -b 115200 write_flash -e -fs 16MB -fm dout 0x0 /home/antonioc/Arduino/"ESPEasy Platformio"/ESPEasy_mega-20220328/bin/ESP_Easy_mega_20220328_max_ESP32_16M8M_LittleFS-factory.bin
esptool.py v3.3.1
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 10:97:bd:cb:ab:64
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Erasing flash (this may take a while)...
Chip erase completed successfully in 56.4s
Compressed 2649520 bytes to 1475888...
Wrote 2649520 bytes (1475888 compressed) at 0x00000000 in 131.7 seconds (effective 160.9 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

After that, I did a hardware reset and when the ESP32 try to boot it enters in a infinite loop like this (serial console output):

Code: Select all

[18:10:25:760] rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[18:10:25:760] configsip: 0, SPIWP:0xee
[18:10:25:760] clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[18:10:25:760] mode:DOUT, clock div:1
[18:10:25:760] load:0x3fff0018,len:4
[18:10:25:760] load:0x3fff001c,len:1044
[18:10:25:760] load:0x40078000,len:10124
[18:10:25:760] load:0x40080400,len:5856
[18:10:25:760] entry 0x400806a8
[18:10:25:760] ets Jul 29 2019 12:21:46

I have tried almost all "max" images without success and with the same results. BUT if I load a "normal" image for 4MB chips, ESP32 works as expected. (ESP_Easy_mega_20220427_normal_ESP32_4M316k-factory.bin for example).
Also, have tried old "max" firmware, for instance, ESP_Easy_mega_20210802_max_ESP32_16M8M_LittleFS-factory.bin with the same unsuccessful results.

Could anyone help with this issue?

Thanks in advance

Posted: **18 May 2022, 20:46**

Can you try to flash it using the download tool made by Espressif?
This tool is included in the ZIP.

The tool has a checkbox on the right half of the GUI stating "do not change bin".
This is by default checked.

Please try to flash it with this tool, flash the -factory bin file of course and start from address 0.
If that still does not work well (which I don't expect), uncheck this checkbox I mentioned.

Posted: **18 May 2022, 20:50**

The ESP32 with 16 MB Flash seem to be quite sensitive wrt flash configuration, more than the 4 MB editions. This has mostly been resolved in the latest IDF 4.4 release, and that has been merged into ESPEasy, but not release yet.
You can download today's 'nightly' build, the latest merged improvements, from this Github Actions build. You will need the Binaries download, that contains a .zip file per build configuration. Using one of these MAX .bin files should get you going.

Posted: **18 May 2022, 20:55**

Here a build I just made for you...
https://www.dropbox.com/s/duidnvjpcnso1 ... y.zip?dl=0
It is not the mega branch, but it should work and has all commits upto today included.

N.B. please also check the esptool command arguments.
I don't think you need to include the flash size and flash mode, as that's also part of the bin file and some will be detected while flashing.

Posted: **18 May 2022, 21:08**

Just searched for some esptool.py writes in my history, I did a while ago...

Code: Select all

esptool -b 460800 --port COM6 write_flash --flash_freq 40m 0x000000 flash_16M-full.bin

Posted: **19 May 2022, 09:08**

Thanks for your replay.
I have followed your instructions but the results are the same. Flashed with both esptool.py and Espressif GUI tool.
I'm glad to do any test that you want.....
Thanks again.

Posted: **19 May 2022, 09:53**

There is no output at all regarding the ESPEasy firmware?
Can you try to erase all flash using esptool.py? There is an erase command which erases much faster than writing the blank bin.
Just to make sure there is not a half finished filesystem where the node crashes on.
Can you also try the 16M1M build? This one has a smaller file system part.
My theory is that creating the 8M filesystem may take so long that the watchdog may kick in and reset the node.
This may leave the filesystem in some incomplete state and that may cause crashes on reboot.

Posted: **19 May 2022, 19:07**

There is no output at all regarding the ESPEasy firmware?

Do you mean during ESP32 boot? If so,no at all. Here is a serial boot log. After first reset message (power on reset), the ESP32 goes into a infinite loop sending messages about "SW_RESET" very quickly.

Code: Select all

ets Jul 29 2019 12:21:46
[18:30:03:020] 
[18:30:03:020] rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[18:30:03:020] configsip: 0, SPIWP:0xee
[18:30:03:020] clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[18:30:03:020] mode:DOUT, clock div:2
[18:30:03:020] load:0x3fff0030,len:184
[18:30:03:020] load:0x40078000,len:12596
[18:30:03:020] load:0x40080400,len:2916
[18:30:03:020] entry 0x400805c4
[18:30:03:020] ets Jul 29 2019 12:21:46
[18:30:03:020] 
[18:30:03:020] rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[18:30:03:020] configsip: 0, SPIWP:0xee
[18:30:03:020] clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[18:30:03:020] mode:DOUT, clock div:2
[18:30:03:067] load:0x3fff0030,len:184
[18:30:03:067] load:0x40078000,len:12596
[18:30:03:067] load:0x40080400,len:2916
[18:30:03:067] entry 0x400805c4
[18:30:03:067] ets Jul 29 2019 12:21:46
[18:30:03:067] 
[18:30:03:067] rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
.
.
.

Regarding erasing flash, I did it with the same results. In fact, I do it almost of times when I have problems....
I have tried 16M1M build, erasing flash previously but also, with the same unsuccessful results....
If I can do anything to help, let me know.

Posted: **19 May 2022, 20:09**

What is the name of the .bin file you have flashed on the device?

Posted: **19 May 2022, 20:49**

ESP_Easy_mega_20220427_max_ESP32_16M1M-factory.bin

Both via esptool on linux and Windows GUI and erasing flash previously.

Posted: **19 May 2022, 20:52**

You really should download the file TD-er supplied in the Dropbox link above. That will work when flashed as suggested (initial flash of the factory.bin at address 0x0000).

Posted: **19 May 2022, 21:13**

I'm quite sure but I will try again in case I made a mistake.

Posted: **19 May 2022, 21:22**

The file on dropbox has 20220518 in the name, not 20220427

NB: No need to log in to dropbox, just close the popup.

Posted: **19 May 2022, 21:39**

Now, I'm really sure. Using ESP_Easy_mega_20220518_max_ESP32_16M8M_LittleFS.factory.bin file and flashed both esptool and Windows GUI....

Posted: **20 May 2022, 08:39**

Just another thought...
Can you load a 4M firmware again and then go over to the sysinfo page to see what chip size is detected?
I don't see the chip size being reported by esptool.py, so that makes me wonder whether it actually is a 16M module.
Another thing that might be happening here is that esptool.py does set a few bits while flashing:
- flash size
- Flash frequency

Those are based on what it detects and that's why there is a "do not change bin" option in the Espressif download tool.

Not sure if this will work, but you can also try the web flasher: https://td-er.nl/ESPEasy/20220428/
This is still a bit flaky with 16M modules, but it might be just what your board needs

N.B. the web flasher only works with Chrome/Edge on Windows as far as I know.

Posted: **20 May 2022, 18:23**

Hi TD-er
I have flashed a "normal" 4MB image (ESP_Easy_mega_20220427_normal_ESP32_4M316k-factory.bin) and surprise, only 4MB are detected. I have found that the ESP Chip Model is incorrect also: ESPEasy reports "ESP32-D0WDQ5" instead ESP32-D0WD-V3. I don't know if it is important... Following a screenshot.

: Screenshot from 2022-05-20 17-31-50.png (158.46 KiB) Viewed 51072 times

BUT when I run esptool with flash_id option, correct size is detected:

Code: Select all

~$ ./.local/bin/esptool.py --port /dev/ttyUSB0 flash_id
esptool.py v3.0
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:c6:f7:ed:62:e0
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4018
Detected flash size: 16MB
Hard resetting via RTS pin...

And if I flash with esptool using the option "--flash_size detect" it reports the correct size (if I specify the size, "--flash_size 16MB" it doesn't report anything).

Code: Select all

~$ ./esptool/esptool --port /dev/ttyUSB0 -b 460800 write_flash --flash_size detect --flash_freq 40m 0x000000 /home/antonioc/Arduino/"ESPEasy Platformio"/ESPEasy_mega-20220427/bin/ESP_Easy_mega_20220427_normal_ESP32_4M316k-factory.bin
esptool.py v3.3.1
Serial port /dev/ttyUSB0
Connecting......
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:c6:f7:ed:62:e0
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 16MB
Flash will be erased from 0x00000000 to 0x001b4fff...
Compressed 1788512 bytes to 988466...
Wrote 1788512 bytes (988466 compressed) at 0x00000000 in 25.2 seconds (effective 568.8 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

I will try web flasher in a few minutes..... Have to install chrome....
Thanks and don't hesitate to ask me for more tests.....

Posted: **20 May 2022, 22:59**

Hmm that looks interesting.
The flash ID is 6 HEX digits and we need to swap and strip hex bytes to get the vendor and the model.
Your chip is reported as vendor 0x18 and chip model 4020.
However esptool has those bytes swapped, vendor 0x20 and chip model 4018.
So it seems that I may have messed up those (or this order was changed in the core lib...)

Not sure if this really is an issue, but at least it is worth to look into.

Posted: **27 May 2022, 13:20**

TD-er,

I have been make some tests in order to go ahead with this issue but my limited knowledge of this matter doesn't allow me to reach a success solution so, this was what I have done:

- I have compiled last version of Tasmota in order to generate a 16MB compatible firmware.
- I uploaded it into my board with esptool.py
- Tasmota has detected the chip type correctly (ESP32-D0WD-V3)
- I was able to use entire filesystem up to 10MB

So, we can conclude that:
- My board is ok and
- esptool.py works

From now on, I don't know what I can do. May be this tests could help.

Thanks

Posted: **27 May 2022, 14:19**

Seems like you have your esptool.py command-line quite OK, except for the .bin file. The April builds don't seem to run nice on the 16MB ESP32s.

Try with this fresh build I just made please, it is fully up to par with the current 'mega' branch, that has the latest Espressif IDF 4.4(.1) included:

ESP_Easy_mega_20220527_max_ESP32_16M8M_LittleFS.factory.zip: (1.31 MiB) Downloaded 269 times

Posted: **27 May 2022, 17:18**

Yes, it works.....

After a few tests, everything seams to work as expected except that Chip Model is detected as ESP32-D0WDQ5-V3 instead of ESP32-D0WD-V3.

Thanks a lot for your support and knowledge.

Posted: **27 May 2022, 21:56**

That string of the detected CPU was something I had added, before it was part of the esp32 core.
I will have a look at these strings to see whether I may have to change them or maybe made a mistake somewhere.

Posted: **14 Jun 2022, 15:49**

Ath wrote: ↑27 May 2022, 14:19 Seems like you have your esptool.py command-line quite OK, except for the .bin file. The April builds don't seem to run nice on the 16MB ESP32s.

Try with this fresh build I just made please, it is fully up to par with the current 'mega' branch, that has the latest Espressif IDF 4.4(.1) included:
ESP_Easy_mega_20220527_max_ESP32_16M8M_LittleFS.factory.zip

Hello,
I have exactly the same issue.
This firmware work fine for me
ESP_Easy_mega_20220527_max_ESP32_16M8M_LittleFS.factory.zip

Do you have an ethernet version of this ?

Posted: **14 Jun 2022, 17:05**

Air-One wrote: ↑14 Jun 2022, 15:49 Hello,
I have exactly the same issue.
This firmware work fine for me
ESP_Easy_mega_20220527_max_ESP32_16M8M_LittleFS.factory.zip

Do you have an ethernet version of this ?

You can download the latest merge build (today) from here: https://github.com/letscontrolit/ESPEas ... 2493700557 (download the Binaries .zip file, ca. 619 MB, from the 'Artifacts' pane, that holds a separate zip file per build)
It requires a Github account to be able to download, but that account can be created for free, if you don't have one yet.

Posted: **20 Jun 2022, 07:06**

Hi all!
Just found this topic. Same issue with Wemos D32 Pro. As reported at their site - my version with 16MB flash and 4MB PSRAM. But I'm also can't use any "max" builds. Checked with latest mega-20220616. Same bootloop after flashing.
But instead old issue, reported by topic starter - I can see 16MB in Flash Chip Real Size. 4M316k versions flashes without bootloops.
Will check TD-er version soon.

Posted: **20 Jun 2022, 07:31**

sobolkz wrote: ↑20 Jun 2022, 07:06 Hi all!
Just found this topic. Same issue with Wemos D32 Pro. As reported at their site - my version with 16MB flash and 4MB PSRAM. But I'm also can't use any "max" builds. Checked with latest mega-20220616. Same bootloop after flashing.
But instead old issue, reported by topic starter - I can see 16MB in Flash Chip Real Size. 4M316k versions flashes without bootloops.
Will check TD-er version soon.

Be sure to flash the latest version via serial (using the .factory.bin), so the latest bootloader is flashed onto the unit. That should fix this. You can use the recently released 20220616 build available at Github releases page

Posted: **20 Jun 2022, 08:18**

Ath wrote: ↑20 Jun 2022, 07:31
Be sure to flash the latest version via serial (using the .factory.bin), so the latest bootloader is flashed onto the unit. That should fix this. You can use the recently released 20220616 build available at Github releases page

Yes, sure. I'm flashing .factory.bin via serial in this situation.

Posted: **20 Jun 2022, 09:05**

Are you able to collect the output via serial after flashing?
Please also try to power cycle the unit, just to be sure it isn't something left in memory or left uninitialized.

Posted: **20 Jun 2022, 09:31**

TD-er wrote: ↑20 Jun 2022, 09:05 Are you able to collect the output via serial after flashing?
Please also try to power cycle the unit, just to be sure it isn't something left in memory or left uninitialized.

OK, will check this too. B.T.W. - is it applicable before flashing ESPEasy image to "clear" flash instead burning blanc 16MB.bin via serial?
As I remember ESP8266 in some situations should be flashed with clear image for 100% flash updating.

Posted: **20 Jun 2022, 09:36**

Sure you can.
Either blank it using a blank image, or use the erase flash command via esptool.py.

Posted: **20 Jun 2022, 16:40**

No result:
Each flashing ends with hardware power disconnection.
You May's release:

esptool -b 115200 --port /dev/ttyUSB0 write_flash --flash_freq 40m 0x000000 ./ESP_Easy_mega_20220518_max_ESP32_16M8M_LittleFS.factory.bin
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting.....
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:6f:28:d1:9a:d8
Enabling default SPI flash mode...
Configuring flash size...
Auto-detected Flash size: 16MB
Erasing flash...
Took 7.28s to erase flash block
Wrote 2168832 bytes at 0x00000000 in 216.8 seconds (80.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Bootloop with:

rst:0x3 (SW_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DOUT, clock div:2
load:0x3fff0030,len:184
load:0x40078000,len:12596
load:0x40080400,len:2916
entry 0x400805c4
ets Jun 8 2016 00:22:57

Last release:

esptool -b 460800 --port /dev/ttyUSB0 write_flash --flash_freq 40m 0x000000 ./ESP_Easy_mega_20220616_max_ESP32_16M1M.factory.bin
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting.....
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:6f:28:d1:9a:d8
Changing baud rate to 460800
Changed.
Enabling default SPI flash mode...
Configuring flash size...
Auto-detected Flash size: 16MB
Erasing flash...
Took 7.88s to erase flash block
Wrote 2220032 bytes at 0x00000000 in 67.7 seconds (262.3 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Bootloop:

st:0x3 (SW_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DOUT, clock div:2
load:0x3fff0030,len:184
load:0x40078000,len:12596
load:0x40080400,len:2916
entry 0x400805c4
ets Jun 8 2016 00:22:57

Slow speed flashing:

esptool -b 115200 --port /dev/ttyUSB0 write_flash --flash_freq 40m 0x000000 ./ESP_Easy_mega_20220518_max_ESP32_16M8M_LittleFS.factory.bin
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting.....
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:6f:28:d1:9a:d8
Enabling default SPI flash mode...
Configuring flash size...
Auto-detected Flash size: 16MB
Erasing flash...
Took 7.28s to erase flash block
Wrote 2168832 bytes at 0x00000000 in 216.8 seconds (80.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Bootloop:

rst:0x3 (SW_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DOUT, clock div:2
load:0x3fff0030,len:184
load:0x40078000,len:12596
load:0x40080400,len:2916
entry 0x400805c4
ets Jun 8 2016 00:22:5

All "16M" images - same result.

display_4M316k was successfully flashed:

esptool -b 115200 --port /dev/ttyUSB0 write_flash --flash_freq 40m 0x000000 ./ESP_Easy_mega_20220616_display_ESP32_4M316k.factory.bin
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:6f:28:d1:9a:d8
Enabling default SPI flash mode...
Configuring flash size...
Auto-detected Flash size: 16MB
Erasing flash...
Took 5.22s to erase flash block
Wrote 1474560 bytes at 0x00000000 in 147.6 seconds (79.9 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Board info in 4M316K veb pages:

: Untitled.jpg (96.42 KiB) Viewed 50066 times

Posted: **20 Jun 2022, 16:44**

Can you try the same using the 16M1M build of ESPEasy, instead of the 16M8M_LittleFS build?

Posted: **20 Jun 2022, 18:12**

Ath wrote: ↑20 Jun 2022, 16:44 Can you try the same using the 16M1M build of ESPEasy, instead of the 16M8M_LittleFS build?

Same result with 16M1M version.

Posted: **20 Jun 2022, 20:23**

I had that same problem after upgraded flash to 16MB, I solved it by flashing with flash_download_tool_3.8.5 first ESP_Easy_mega_20220527_max_ESP32_16M8M_LittleFS.factory.zip from this topic and then the latest from 0616 max with ethernet via espeasy web interface.

Posted: **20 Jun 2022, 23:09**

Do you have "don't change bin" checked on the Espressif download tool?
esptool.py does change the bin while flashing, based on what (it thinks) it detects

Posted: **21 Jun 2022, 04:57**

TD-er wrote: ↑20 Jun 2022, 23:09 Do you have "don't change bin" checked on the Espressif download tool?
esptool.py does change the bin while flashing, based on what (it thinks) it detects

Hmm, I'm using Ubuntu. Will check with Windows soon.

Posted: **21 Jun 2022, 09:15**

Maybe esptool.py does have some option to not change the bin?

Posted: **21 Jun 2022, 11:21**

TD-er wrote: ↑21 Jun 2022, 09:15 Maybe esptool.py does have some option to not change the bin?

As I see there is no such options, but this option can be interesting:

By default, the serial transfer data is compressed for better performance. The -u/--no-compress option disables this behaviour.

I'll try to use Windows as primary way and if it'll not help - I'll try to use this option.

Posted: **21 Jun 2022, 17:11**

All done with Windows.
But 3.9.2 flash download tool was used. And ESP_Easy_mega_20220527_max_ESP32_16M8M_LittleFS.factory.bin was successfully flashed.

: 2022-06-21 21-10-32 MAX ESP32 - Google Chrome.jpg (101.12 KiB) Viewed 50012 times

: 2022-06-21 21-09-12 MAX ESP32 - Google Chrome.jpg (33.15 KiB) Viewed 50012 times

Posted: **21 Jun 2022, 21:31**

Just as a test, can you make an image on Linux of this 16M node using esptool.py by reading the entire flash?
And then flash this exact image again to another ESP unit?

Also, can you compare the read image and the factory.bin file, upto the size of the bin file?
The first 4k is probably enough.
Just to see if something was changed if you flash the image back using esptool.py.

Posted: **22 Jun 2022, 05:10**

TD-er wrote: ↑21 Jun 2022, 21:31 Just as a test, can you make an image on Linux of this 16M node using esptool.py by reading the entire flash?
And then flash this exact image again to another ESP unit?

Also, can you compare the read image and the factory.bin file, upto the size of the bin file?
The first 4k is probably enough.
Just to see if something was changed if you flash the image back using esptool.py.

I can check only files, haven't another ESP32 with 16MB flash

Am I right that reading whole flash from working device will add config.dat and presented rulesX into .bin file and final .bin file will be different from original image?
Or user's data placed outside of first 4K?

Posted: **22 Jun 2022, 09:34**

See the partition layout:
https://github.com/letscontrolit/ESPEas ... s8124k.csv

The first partition (NVS) starts at 0x9000, so anything before that one will be untouched by user data and should be the same as in the factory.bin file.
The difference between the "factory" bin and non-"factory" bin file is that the non-factory bin will be flashed (via OTA) starting at the address of either the "app0" or "app1" partition.
Which one is used, depends on which is the active partition for the current flashed firmware.
The "factory" bin will be flashed starting at address 0 and overwrite anything upto "non-factory" bin size + 0x10000.

Serial flash "factory" bin:
- Write starting at 0
- Overwrite bootloader + NVS partition + OTAdata partition + app0 partition upto the size of the firmware file.

OTA flash "non-factory" bin:
- Write starting at start of "the other" app partition
- Update flags in otadata partition to set the flashed partition as the boot partition.

What esptool.py does, is it sets 2 flags in the boot partition.
I think these are even within the first 128 bytes, but not really sure.
These flags are:
- detected flash size
- Flash frequency

The latest boot loader does allow to have different flash frequency set in the boot loader and the running sketch.
But I am not sure if this only allows to have a lower frequency at boot and higher in the sketch, or also allows the other way around.
I think it does set the flash frequency to 80 MHz while it is set in the sketch to run at 40 MHz.
This may cause the wrong flash operation parameters to be active for the actual frequency of the flash when the sketch is running.

Posted: **22 Jun 2022, 15:55**

TD-er wrote: ↑21 Jun 2022, 21:31 Just as a test, can you make an image on Linux of this 16M node using esptool.py by reading the entire flash?
And then flash this exact image again to another ESP unit?

Also, can you compare the read image and the factory.bin file, upto the size of the bin file?
The first 4k is probably enough.
Just to see if something was changed if you flash the image back using esptool.py.

No result:
$ esptool -b 460800 --port /dev/ttyUSB0 read_flash 0 0x400000 flash.bin
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:6f:28:d1:9a:d8
Changing baud rate to 460800
Changed.
Enabling default SPI flash mode...

A fatal error occurred: ESP32 ROM does not support function read_flash.

Posted: **22 Jun 2022, 17:35**

Maybe your version of esptool.py is too old?
You can try in a virtual env (so you're not messing up your system Python config) to upgrade your esptool.py to the latest version?

Posted: **23 Jun 2022, 14:07**

I've been looking into the build output a bit more and now I have updated the esptool.py myself to the latest build on my dev computer.

I see this in the output of my build (using esptool.py v4.1)

Code: Select all

Warning: Image file at 0x1000 is protected with a hash checksum, so not changing the flash size setting. Use the --flash_size=keep option instead of --flash_size=16MB in order to remove this warning, or use the --dont-append-digest option for the elf2image command in order to generate an image file without a hash checksum

I guess the builds made on the GitHub Actions builds and the one I made on my WSL box could have this checksum included.

But when flashing using an older flash tool, it might be that this check was not included and thus one of the flags may have changed during flashing on (some?) ESP32 boards with 16M flash.
If so, then the checksum fails and the board may try to reboot.

Not sure what to do now. Should I disable adding this checksum?
Or should we advice users to always flash using the latest flashing tools that won't patch the bin while flashing?

Posted: **23 Jun 2022, 17:02**

So, esptool was installed into venv, version v4.1 installed.
Flash was readed after it.
As I understand it isn't important now due to you last message

Let's accept the fact, that factory.bin firmware should be updated with latest version of esptool - only it can guaranty successful procedure.

Posted: **23 Jun 2022, 17:23**

You can also set the flash frequency and size to "keep".
That was present on older versions too.

Code: Select all

esptool -b 115200 --port /dev/ttyUSB0 write_flash --flash_freq keep --flash_size keep 0x000000 ./ESP_Easy_mega_20220518_max_ESP32_16M8M_LittleFS.factory.bin

Posted: **30 Jun 2022, 08:24**

OK, got some "good" news (depending on your reference point)...
Last night I got the same issues when trying to flash a 16M image to an ESP32 with 16M flash.
So the good part of it is that it is now fully reproducible on my setup.
The bad news is of course that I'm using the latest esptool.py and still run into these issues.

Let's Control It

Unable to run "max" firmware into a ESP-32 16MB

Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB

Re: Unable to run "max" firmware into a ESP-32 16MB