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

Incorrect bootloader mode (SPI_DOWNLOAD_BOOT) (ESPTOOL-507) #774

Closed
1 task done
osterwood opened this issue Sep 1, 2022 · 4 comments
Closed
1 task done

Incorrect bootloader mode (SPI_DOWNLOAD_BOOT) (ESPTOOL-507) #774

osterwood opened this issue Sep 1, 2022 · 4 comments

Comments

@osterwood
Copy link

Operating System

macOS / Linux

Esptool Version

v4.2.1

Python Version

3.10.4

Chip Description

ESP32C3

Device Description

Custom board with a linux system controlling BOOT and CHIP_EN pins. Flashing is done via a UART.

Hardware Configuration

Various GPIO to a power management system

How is Esptool Run

CLI

Full Esptool Command Line that Was Run

esptool.py --before no_reset --chip esp32c3 --port DEV_PATH chip_id

Esptool Output

WARNING: Pre-connection option "no_reset" was selected. Connection may fail if the chip is not in bootloader or flasher stub mode.
Connecting......................................

A fatal error occurred: Failed to connect to ESP32-C3: No serial data received.

More Information

When I connect a serial console to the UART and enter bootloader, I now see the following output:

[00]ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0x1 (SPI_DOWNLOAD_BOOT)
wait spi download

Prior to the failure, I was observing this output:

[00]ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0x5 (DOWNLOAD(USB/UART0/1))
waiting for download

Interestingly, the code I have on the ESP32C3 still runs fine when the chip is reset in normal boot mode. The only failure seems to be in entering the correct download mode.

In between "working" and "cannot refresh" included some probing of the running ESP32 where the VDD_SPI net was accidentally brought to ~0v a few times. Could this have corrupted part of the built-in SPI and could the be preventing re-flashing?

Is there a way to recover a device which is entering this non-standard SPI_DOWNLOAD_BOOT mode?

Normal boot out is this:

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xd (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x172c
load:0x403ce000,len:0x928
load:0x403d0000,len:0x2ce0
entry 0x403ce000
I (30) boot: ESP-IDF v4.4-dev-2825-gb63ec47238 2nd stage bootloader
I (30) boot: compile time 12:10:40
I (30) boot: chip revision: 3
I (33) boot_comm: chip revision: 3, min. bootloader chip revision: 0
I (46) boot.esp32c3: SPI Speed      : 80MHz
I (46) boot.esp32c3: SPI Mode       : DIO
I (50) boot.esp32c3: SPI Flash Size : 4MB
I (55) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 003f0000
I (93) boot: End of partition table
I (98) boot_comm: chip revision: 3, min. application chip revision: 0
I (105) esp_image: segment 0: paddr=00010020 vaddr=3c070020 size=211d0h (135632) map
I (134) esp_image: segment 1: paddr=000311f8 vaddr=3fc8a000 size=01514h (  5396) load
I (135) esp_image: segment 2: paddr=00032714 vaddr=40380000 size=09e90h ( 40592) load
I (147) esp_image: segment 3: paddr=0003c5ac vaddr=50000010 size=00010h (    16) load
I (148) esp_image: segment 4: paddr=0003c5c4 vaddr=00000000 size=03a54h ( 14932) 
I (158) esp_image: segment 5: paddr=00040020 vaddr=42000020 size=69308h (430856) map
I (232) boot: Loaded app from partition at offset 0x10000
I (232) boot: Disabling RNG early entropy source...
I (243) cpu_start: Pro cpu up.
I (252) cpu_start: Pro cpu start user code
I (252) cpu_start: cpu freq: 160000000
I (252) cpu_start: Application information:
I (255) cpu_start: Project name:     libespidf
I (260) cpu_start: App version:      1
I (264) cpu_start: Compile time:     Sep  1 2022 00:41:50
I (270) cpu_start: ELF file SHA256:  0000000000000000...
I (276) cpu_start: ESP-IDF:          b059440
I (281) heap_init: Initializing. RAM available for dynamic allocation:
I (289) heap_init: At 3FC8C540 len 000501D0 (320 KiB): DRAM
I (295) heap_init: At 3FCDC710 len 00002950 (10 KiB): STACK/DRAM
I (302) heap_init: At 50000020 len 00001FE0 (7 KiB): RTCRAM
I (308) spi_flash: detected chip: generic
I (313) spi_flash: flash io: dio
I (317) sleep: Configure to isolate all GPIO pins in sleep state
I (323) sleep: Enable automatic switching of GPIO sleep configuration
I (330) cpu_start: Starting scheduler.
I (335) firmware: booted

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

  • I confirm I have read the troubleshooting guide.
@github-actions github-actions bot changed the title Incorrect bootloader mode (SPI_DOWNLOAD_BOOT) Incorrect bootloader mode (SPI_DOWNLOAD_BOOT) (ESPTOOL-507) Sep 1, 2022
@radimkarnis
Copy link
Collaborator

Hello @osterwood,

Custom board with a linux system controlling BOOT and CHIP_EN pins. Flashing is done via a UART.

Does this mean you are using a custom solution to switch the board into the download mode? You disable auto-reset behavior with `--before no_reset, so you must ensure to do that manually (or programmatically with a custom script?).

The problem might be in your custom board pulling some of the strapping pins (mainly GPIO8 and GPIO2). This is a handy summary of boot modes as a result of different strapping pins configurations:

image

Interestingly, the code I have on the ESP32C3 still runs fine when the chip is reset in normal boot mode. ... Could this have corrupted part of the built-in SPI and could the be preventing re-flashing?

There is nothing wrong with the ESP, it is not corrupted. esptool.py should be able to communicate with it even if no SPI flash chip is attached. This issue is just a matter of a wrong boot mode.

Please check your strapping pins and try to enter the standard download mode.

@osterwood
Copy link
Author

Thanks for the handy table mapping GPIO state to boot mode (with output messages). That is super useful -- and would be great to have included in the online documentation (https://docs.espressif.com/projects/esptool/en/latest/esp32c3/advanced-topics/boot-mode-selection.html)

Looks like GPIO8 is low when it should be high (e.g. chip is seeing 100 instead of 110). I'll look into that.

@radimkarnis
Copy link
Collaborator

There is an active feature request to update the documentation: #732 It is in the pipeline!

Let me please know if you manage to resolve your issue.

@osterwood
Copy link
Author

That was in fact the issue. Pulled GPIO8 high and now everything is okay. That changed in our setup and I hadn't realized it.

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