You are viewing a static version of the site. Enable JavaScript to benefit from the
full functionality of this site and enable such things as forum posting.
Problems uploading to ESP32 with greater 4MB flash
ullix:
I have problems uploading to ESP32 having 8MB or 16MB flash. I am wondering if there is any setting in uecide, which needs to be changed?
I ordered 3 ESPs with 4, 8, 16 MB flash. I got chips with imprints in their metal cover of XX0H32, XX0H64, XX0H28 which might code for 32, 64, and (1)28 MBit.
Booting the virgin chips they all say "I (44) boot: SPI Flash Size : 4MB". Ooops.
However, when uploading my code from uecide, the "esptool.py v2.8-dev" tells me it autodetected 4, 8, and 16 MB. So, I believe it is true, after all.
Unfortunately, while everything worked normally using the 4MB chip, both 8 and 16MB failed. The esptool said:
Writing at 0x00018000... (8 %)
A fatal error occurred: Failed to write compressed data to flash after seq 2 (result was C100)
I did set the Flash-size in uecide's hardware options to 8 and 16 MB, resp.
I did a bunch of repeats with de-powering in between and what not. Apart from failing at between 5 and 16%, and at seq2 or seq 4, the results were all the same.
Booting the chips now gives almost the same output to terminal, except at the end it says:
E (434) phy_init: failed to validate PHY data partition
E (439) phy_init: failed to obtain PHY init data
abort() was called at PC 0x40182703 on core 0
Anything needs setting in uecide? Partitions?
matt:
No, UECIDE just calls the standard ESP32 tools depending on what board is selected. Have you done any tests using the Arduino IDE to confirm that the >4MB are indeed >4MB?
ullix:
One more test: I used the "supposed 4MB" variant, which has the XX0H32 imprint, for which esptool reports 4MB, and the ESP.getFlashChipSize() function reports 4MB.
I compiled with each of uecide's flash size options of 2, 4, 8, 16 MB, and the best I can say is that the outcome has always been identical.
What function is this Hardware_>Options->Flash size supposed to have?
matt:
It is used when generating the binary using esptool. It is passed as the --flash_size <size> parameter. When uploading the program to the chip it uses --flash_size detect to find out what the size is (something it can't do while compiling of course).
ullix:
This is one of the many puzzling things. First, the chips are correctly labelled as 4, 8, 16MB, as you will see in a moment.
The tool "esptool.py v2.8-dev" available under uecide correctly identifies the flash size, and correctly reports all chips as "revision 3". Unfortunately, the Arduino IDE, using esptool v2.6, identifies them as 'revision 2'. This is wrong! see e.g. https://www.esp32.com/viewtopic.php?t=16103
One can also check the firmware with command "ESP.getChipRevision()" and there one also gets revision 3.
I put together a small test script CHIPTEST, which I used for this present testing, to report details on chip, flash, and FFat FS. I am attaching a copy here. Use as is on uecide, but should you use it on Arduino be aware that the included file 'partitions.csv' is correctly used to set partitions under uecide, but it is ignored by Arduino! There you'll have to set the partitions manually.
Now you can get this :
partition addr: 0x290000; size: 0xd70000; label: ffat
FFat File system mounted
Total FFat space: 13938688
Free FFat space: 13938688
FlashChipSize: 16777216 (0x1000000)
ChipRevision: 3
omg! Who would possibly ever need more than 640kB -- uuuh -- 16 MB of flash for any microprocessor?
For all 3 chips I tried all uecide hardware --> optons --> flash size settings of 2, 4, 8, 16 MB. It didn't make one jota of a difference in any test. So, what is this setting really doing? Any example for when it does anything?
But: still can't upload my real program ...
matt:
It looks like it's used to fill in a byte (along with the flash frequency) in the header of the binary file. I guess the bootloader reads this value when it runs the program. Maybe the the bootloader reads it as part of the upload process. As far as I know it is not used for anything else at all. It's not used by compilation. It's not used by linking. It's not even used by the uploading, which auto-detects by what the chip reports.
Here's an example. 4MB:
00000000: e906 022f 5c0f 0840 ee00 0000 0000 0000 .../\..@........
16MB:
00000000: e906 024f 5c0f 0840 ee00 0000 0000 0000 ...O\..@........
All that changes is the 022f becomes 024f. That said, though, looking at the source code to esptool.py I'd expect to see 029f for 16MB, but I may be reading it wrong.
matt:
No, those values are right, I was looking at the esp8266 table.
1149 FLASH_SIZES = {
1150 '1MB':0x00,
1151 '2MB':0x10,
1152 '4MB':0x20,
1153 '8MB':0x30,
1154 '16MB':0x40
1155 }
matt:
In the esptool.py comments:
1775 # first 4 bytes of header are read by ROM bootloader for SPI
1776 # config, but currently unused
So it's used to set up the SPI. Maybe changing the flash frequency / flash mode may have an effect?
ullix:
but currently unused
Uhoh, this spells trouble in the long run. Thanks for figuring it out.
matt:
It doesn't say where it's currently unused. Is it not used by the bootloader? Or not used elsewhere?
matt:
All we have to go on are the comments, and they're vague. As far as I can tell everything is working correctly with the flash size. The other thing you can try is to reduce the upload baud rate. Maybe it's just unable to transfer the data reliably.
ullix:
Strange, all three ESP modules 4, 8, 16BM are now running smoothly under uecide with full upload speed ( 921600 baud).
I did run my CHIPTEST in between, but was that causal or coincidental? No idea. All is fine.
matt:
That is truly strange. Maybe there's been a change in the weather...
