-
Notifications
You must be signed in to change notification settings - Fork 7.7k
How to debug ets_loader.c errors - ESP32-C6 (Adafruit Feather C6) has boot loop with ets_loader.c 67
#10418
-
Hi, the same sketch builds fine and flashes fine locally. When instead building in CI the device boot loops with:
15:12:17:072 -> ESP-ROM:esp32c6-20220919
15:12:17:072 -> Build:Sep 19 2022
15:12:17:073 -> rst:0x7 (TG0_WDT_HPSYS),boot:0xb (SPI_FAST_FLASH_BOOT)
15:12:17:073 -> Saved PC:0x4001a9f4
15:12:17:073 -> SPIWP:0xee
15:12:17:073 -> mode:QIO, clock div:2
15:12:17:075 -> load:0x4086c410,len:0xcf8
15:12:17:085 -> ets_loader.c 67
This is with debuglevel verbose. I'm hoping someone has some ideas to try, or ways of debugging this.
I've tried flicking flash memory mode (DIO/QIO) as that was a previously similar issue.
The fully qualified build name + flags are here: https://github.com/adafruit/ci-arduino/blob/ci-wippersnapper/all_platforms.py#L21
Also here with an unmodified toolchain (same result): https://github.com/adafruit/ci-arduino/blob/master/all_platforms.py#L21
esp32:esp32:adafruit_feather_esp32c6:CDCOnBoot=cdc,CPUFreq=160,FlashFreq=80,FlashMode=qio,PartitionScheme=min_spiffs
Related issue: adafruit/Adafruit_Wippersnapper_Arduino#636
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 3 comments 3 replies
-
@VojtechBartoska Could you please take a look at this, thanks!
Beta Was this translation helpful? Give feedback.
All reactions
-
This is still the case. We have to pin esptool to 4.6 otherwise get the ETS Loader boot loop.
Here is the flash from the boot looping version upto and including app0 partition:
flash_ESP32-C6 (revision 1)_40_4c_ca_5a_75_04_0x0_0x1f0000b.zip
And here is the same code built with the same arduino-cli and libs, but merge_bin is then called with esptool 4.6 instead of pip latest (works fine as expected):
wippersnapper.wippersnapper_feather_esp32c6.littlefs.1.0.0-adafruit-3a90d609.combined.bin.zip
The diff shows 3 minor changes:
header / magic bytes:
image
unknown - presumably before the free space a minor discrepancy
image
and compile time change:
image
Beta Was this translation helpful? Give feedback.
All reactions
-
Just to give two comparable files that were both combined.bin so the same size. One from the release v111 (broken boot loop), and one from the PR fix with esptool==4.6 (working):
ets_loader_c6_boot_crash.zip
There's a little more info when using hex diff like from https://web.imhex.werwolv.net/ (open both files then View -> Diffing)
Beta Was this translation helpful? Give feedback.
All reactions
-
@radimkarnis Do you know what could be the change in esptool that might be causing this ?
Beta Was this translation helpful? Give feedback.
All reactions
-
A summary of the changes, just that one early byte (0x0002 from 00 to 02), then a bunch around 0x4F70. Then an unknown bit in the beginning of the app partition 0x100B0-CF and then the compile timestamp changes in the middle (ignore) followed by a final unknown change too at 0x187DDF.
Left is boot loop file (WipperSnapper release 111), right is working version (esptool 4.6).
image
Here are the zip files (all bins plus elf and map) of the release 111 (boot loops with ets_loader), and then the CI assets built the same but merge-bin called after pip installed esptool 4.6 instead of latest.
boot loops and merged with esptool latest via pip:
wippersnapper.wippersnapper_feather_esp32c6.littlefs.1.0.0-beta.111.zip
working normally and merged with esptool==4.6:
wippersnapper.wippersnapper_feather_esp32c6.littlefs.1.0.0-adafruit-3a90d609.zip
In our firmware scenario, you'd in theory also flash the secrets file to the spiffs partition, but you should see output without that setup.
If you want to recreate that bit too then get a free adafruit.com account and goto io.adafruit.com then New Device, pick the c6 feather and run the web installer or get the offline bin, flash the board with it.
That gets you the wifi + io account secrets setup in your spiffs partition.
Then flash one of the two firmwares over the top at 0x0, using one of the combined.bin files and without erasing first.
Beta Was this translation helpful? Give feedback.
All reactions
-
@tyeth What values does the magic sequence have for both cases? In what flash mode the firmware should run?
What flags exactly does your build and flash commands have?
This looks like, you are trying to start the 1st stage bootloader in mode QIO which is not possible!
Booting can be done at max. in mod DIO. The 2nd stage bootloader switches from DIO to QIO
15:12:17:073 -> mode:QIO, clock div:2
If you flash locally the build system takes care to flash the boot mode at max. with DIO
Beta Was this translation helpful? Give feedback.