Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esp32c3 - faulty flash size reported by boot.esp32c3 when flashed with esptool 4.4 (ESPTOOL-615) #837

Closed
1 task done
pljakobs opened this issue Feb 13, 2023 · 5 comments

Comments

@pljakobs
Copy link

pljakobs commented Feb 13, 2023

Operating System

Fedora 37

Esptool Version

esptool.py v4.4

Python Version

Python 3.11.1

Chip Description

esp32c3

Device Description

AI Thinker esp32c3-01m

Hardware Configuration

Pins {1, 5, 6, 7 and 10 connected to MOSFET gates

How is Esptool Run

Sming make flash

Full Esptool Command Line that Was Run

python3 /opt/sming/Sming/Components/esptool/esptool/esptool.py -p /dev/ttyUSB1 -b 115200 --chip esp32c3 --before default_reset --after hard_reset write_flash -z -fs 4MB -ff 40m -fm dio 0x0 /opt/sming/Sming/out/Esp32/esp32c3/debug/build/esp32/sdk/bootloader/bootloader.bin 0x00008000 out/Esp32/esp32c3/debug/firmware/partitions.bin   0x00010000 out/Esp32/esp32c3/debug/firmware/app.bin

Esptool Output

Serial port /dev/ttyUSB1
Connecting....
Chip is ESP32-C3 (revision v0.3)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 7c:df:a1:68:c8:b8
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00004fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x00010000 to 0x0002bfff...
Warning: Image file at 0x0 is protected with a hash checksum, so not changing the flash frequency setting. Use the --flash_frequency=keep option instead of --flash_frequency=40m 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
Warning: Image file at 0x0 is protected with a hash checksum, so not changing the flash size setting. Use the --flash_size=keep option instead of --flash_size=4MB 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
Compressed 20384 bytes to 12277...
Wrote 20384 bytes (12277 compressed) at 0x00000000 in 1.4 seconds (effective 114.5 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 121...
Wrote 3072 bytes (121 compressed) at 0x00008000 in 0.1 seconds (effective 307.5 kbit/s)...
Hash of data verified.
Compressed 113248 bytes to 65714...
Wrote 113248 bytes (65714 compressed) at 0x00010000 in 6.4 seconds (effective 141.2 kbit/s)...
Hash of data verified.

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

More Information

using esptool 4.4, the esp32c3 module is hung in a boot loop. boot.esp32c3 detects a (faulty, afaik) Flash size of 2MB

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x403d15ae
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x185c
load:0x403ce000,len:0x8d4
load:0x403d0000,len:0x2e1c
entry 0x403ce000
I (35) boot: ESP-IDF v4.3.4-347-gdbb0e36aa0 2nd stage bootloader
I (35) boot: compile time 10:43:47
I (35) boot: chip revision: 3
I (38) boot.esp32c3: SPI Speed      : 80MHz
I (43) boot.esp32c3: SPI Mode       : DIO
I (48) boot.esp32c3: SPI Flash Size : 2MB
I (52) boot: Enabling RNG early entropy source...
E (58) flash_parts: partition 0 invalid - offset 0x0 size 0x400000 exceeds flash chip size 0x200000
E (67) boot: Failed to verify partition table
E (72) boot: load partition table error!

with the older version of esptool, this works fine:

$ python3 /opt/sming/Sming/Components/esptool/esptool/esptool.py version
esptool.py v3.2-dev
3.2-dev

output:

python3 /opt/sming/Sming/Components/esptool/esptool/esptool.py -p /dev/ttyUSB1 -b 115200 --chip esp32c3 --before default_reset --after hard_reset write_flash -z -fs 4MB -ff 40m -fm dio 0x0 /opt/sming/Sming/out/Esp32/esp32c3/debug/build/esp32/sdk/bootloader/bootloader.bin 0x00008000 out/Esp32/esp32c3/debug/firmware/partitions.bin   0x00010000 out/Esp32/esp32c3/debug/firmware/app.bin
esptool.py v3.2-dev
Serial port /dev/ttyUSB1
Connecting....
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: 7c:df:a1:68:c8:b8
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00004fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x00010000 to 0x00032fff...
Flash params set to 0x0220
Compressed 20384 bytes to 12281...
Wrote 20384 bytes (12281 compressed) at 0x00000000 in 1.4 seconds (effective 114.5 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 121...
Wrote 3072 bytes (121 compressed) at 0x00008000 in 0.1 seconds (effective 306.9 kbit/s)...
Hash of data verified.
Compressed 141440 bytes to 82883...
Wrote 141440 bytes (82883 compressed) at 0x00010000 in 7.6 seconds (effective 149.2 kbit/s)...
Hash of data verified.

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

esp startup

    ▒ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fcd6100,len:0x185c
load:0x403ce000,len:0x8d4
load:0x403d0000,len:0x2e1c
SHA-256 comparison failed:
Calculated: 9235e74fd2385af06f644de6d6f2b455f6a8a7c8f6e847011e9248f0b02f84ef
Expected: 9fea2f49f233341c756f296a4b9b8ad596225e2b8de5b85661943b3ce59f6ac4
Attempting to boot anyway...
entry 0x403ce000
I (50) boot: ESP-IDF v4.3.4-347-gdbb0e36aa0 2nd stage bootloader
I (50) boot: compile time 10:53:48
I (50) boot: chip revision: 3
I (53) boot.esp32c3: SPI Speed      : 40MHz
I (58) boot.esp32c3: SPI Mode       : DIO
I (62) boot.esp32c3: SPI Flash Size : 4MB
I (67) boot: Enabling RNG early entropy source...
I (73) boot: Partition Table:
I (76) boot: ## Label            Usage          Type ST Offset   Length
I (83) boot:  0 spiFlash         unknown          02 01 00000000 00400000
I (91) boot:  1 nvs              WiFi data        01 02 00009000 00006000
I (98) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (106) boot:  3 factory          factory app      00 00 00010000 000f0000
I (113) boot: End of partition table
I (118) esp_image: segment 0: paddr=00010020 vaddr=3c010020 size=075ech ( 30188) map
I (133) esp_image: segment 1: paddr=00017614 vaddr=3fc8a000 size=01a18h (  6680) load
I (136) esp_image: segment 2: paddr=00019034 vaddr=40380000 size=06fe4h ( 28644) load
I (150) esp_image: segment 3: paddr=00020020 vaddr=42000020 size=0f9b4h ( 63924) map
I (165) esp_image: segment 4: paddr=0002f9dc vaddr=40386fe4 size=02e78h ( 11896) load
I (172) boot: Loaded app from partition at offset 0x10000
I (172) boot: Disabling RNG early entropy source...
I (185) cpu_start: Pro cpu up.
I (194) cpu_start: Pro cpu start user code
I (194) cpu_start: cpu freq: 160000000
I (194) cpu_start: Application information:
I (197) cpu_start: Project name:     Sming
I (202) cpu_start: App version:      4.7.0
I (206) cpu_start: Compile time:     Feb 13 2023 10:53:44
I (213) cpu_start: ELF file SHA256:  489ba9b38c105450...
I (219) cpu_start: ESP-IDF:          v4.3.4-347-gdbb0e36aa0
I (225) heap_init: Initializing. RAM available for dynamic allocation:
I (232) heap_init: At 3FC8CE20 len 000331E0 (204 KiB): DRAM
I (238) heap_init: At 3FCC0000 len 0001F060 (124 KiB): STACK/DRAM
I (245) heap_init: At 50000020 len 00001FE0 (7 KiB): RTCRAM

I was able to reproduce this with other versions of esptool, flashing the exact same binary files.

$ ~/esptool-v3.3.2-linux-amd64/esptool version                                                                                                                                                                   esptool.py v3.3.2
3.3.2

-> successful start

$ ~/.local/bin/esptool.py version
esptool.py v4.4
4.4

-> boot loop

Other Steps to Reproduce

As this is initially reproduced using sming, switching between branches that have updated the esptool.py submodule exposes the issue.

I Have Read the Troubleshooting Guide

  • I confirm I have read the troubleshooting guide.
@github-actions github-actions bot changed the title esp32c3 - faulty flash size reported by boot.esp32c3 when flashed with esptool 4.4 esp32c3 - faulty flash size reported by boot.esp32c3 when flashed with esptool 4.4 (ESPTOOL-615) Feb 13, 2023
@pljakobs
Copy link
Author

one more thing: both versions of esptool identify the chip correctly when using "flash_id"

$ ~/.local/bin/esptool.py version
esptool.py v4.4
4.4
$ ~/.local/bin/esptool.py -p /dev/ttyUSB1 -b 115200 --chip esp32c3 flash_id
esptool.py v4.4
Serial port /dev/ttyUSB1
Connecting........................
Chip is ESP32-C3 (revision v0.3)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 7c:df:a1:68:c8:b8
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...
$ ~/esptool-v3.3.2-linux-amd64/esptool -p /dev/ttyUSB1 -b 115200 --chip esp32c3 flash_id
esptool.py v3.3.2
Serial port /dev/ttyUSB1
Connecting..............
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: 7c:df:a1:68:c8:b8
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...

@dobairoland
Copy link
Collaborator

HI @pljakobs. These two warnings explain the situation.

Warning: Image file at 0x0 is protected with a hash checksum, so not changing the flash frequency setting. Use the --flash_frequency=keep option instead of --flash_frequency=40m 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
Warning: Image file at 0x0 is protected with a hash checksum, so not changing the flash size setting. Use the --flash_size=keep option instead of --flash_size=4MB 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

The bootloader was not built with the 4MB and 40MHz options. This is a breaking change between those two major versions of esptool and the build system needs to be adjusted. If a pre-built bootloader is used and not taken into account the target chip then the --dont-append-digest option needs to be added when the bootloader is produced.

The other solution is set the right flash parameters when the bootloader is built and this behavior won't be observed.

@pljakobs
Copy link
Author

thanks for the quick response @dobairoland
when would the bootloader be built? Sming imports esptool as a git submodule and, afaik, builds it as part of the overal build process. I have run make submodules-clean which should remove all pre-built code in the submodules including esptool - I would have assumed that that also triggers a rebuild of the bootloader?

@dobairoland
Copy link
Collaborator

I'm sorry I'm not familiar with Sming. You can look for the elf2image command invoked for the bootloader. The right flash parameters need to be specified at that moment (or --dont-append-digest).

@pljakobs
Copy link
Author

has been resolved. It seems to have been something in my sming build config, cleaning it helped. Thanks for your support!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants