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

Weird flash loop (No bootable app partitions in the partition table) #707

Closed
J0y8993 opened this issue Dec 13, 2024 · 8 comments
Closed
Assignees
Labels
bug Something isn't working status:needs-investigation Issue requires further investigation

Comments

@J0y8993
Copy link

J0y8993 commented Dec 13, 2024

So I am trying to flash an ESP32-WROOM-32 and I encounter two errors.
I am currently following along the Embedded Rust on ESP32 Book and I am on chapter 2.4.
I got some CC-Linking errors, when building the repo on NixOS (does anyone maybe know why as a side note?). Because of this I ditched NixOS for flashing and I am currently using the Docker container linked in the Book.
So here is a short video of what those errors look like.
issue.webm

  1. I get a timeout when I run cargo run -- --list-all-ports. I have to add the --no-stub flag, in order to make it work 100% of the time. (Idk why, but without the flag it only flashes some times.)
    Here the error message of the timeout:
esp@c36d78ffe227:/workspace/intro/hardware-check$ cargo run -- --list-all-ports 
    Finished `dev` profile [optimized + debuginfo] target(s) in 0.10s
     Running `espflash flash --monitor target/riscv32imc-esp-espidf/debug/hardware-check --list-all-ports`
[2024-12-13T15:47:30Z INFO ] 🚀 A new version of espflash is available: v3.2.0
✔ Use serial port '/dev/ttyUSB0'? · yes
[2024-12-13T15:47:31Z INFO ] Serial port: '/dev/ttyUSB0'
[2024-12-13T15:47:31Z INFO ] Connecting...
[2024-12-13T15:47:31Z INFO ] Using flash stub
Error: espflash::timeout

  × Error while connecting to device
  ╰─▶ Timeout while running command
  1. This is the main error. I am in a weird flash loop after entering the flash command. The full error (before repeating itself) looks like this:
esp@c36d78ffe227:/workspace/intro/hardware-check$ cargo run -- --list-all-ports --no-stub
    Finished `dev` profile [optimized + debuginfo] target(s) in 0.10s
     Running `espflash flash --monitor target/riscv32imc-esp-espidf/debug/hardware-check --list-all-ports --no-stub`
[2024-12-13T15:38:01Z INFO ] 🚀 A new version of espflash is available: v3.2.0
✔ Use serial port '/dev/ttyUSB0'? · yes
[2024-12-13T15:38:02Z INFO ] Serial port: '/dev/ttyUSB0'
[2024-12-13T15:38:02Z INFO ] Connecting...
Chip type:         esp32 (revision v1.0)
Crystal frequency: 40 MHz
Flash size:        4MB
Features:          WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC address:       24:6f:28:7b:88:3c
App/part. size:    1,149,840/4,128,768 bytes, 27.85%
[2024-12-13T15:38:03Z INFO ] Segment at address '0x1000' has not changed, skipping write
[2024-12-13T15:38:03Z INFO ] Segment at address '0x8000' has not changed, skipping write
[2024-12-13T15:38:04Z INFO ] Segment at address '0x10000' has not changed, skipping write
[2024-12-13T15:38:05Z INFO ] Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (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:DIO, clock div:2
load:0x3fff0030,len:7104
load:0x40078000,len:15576
load:0x40080400,len:4
ho 8 tail 4 room 4
load:0x40080404,len:3876
entry 0x4008064c
I (30) boot: ESP-IDF v5.1-beta1-378-gea5e0ff298-dirt 2nd stage bootloader
I (31) boot: compile time Jun  7 2023 07:48:23
I (33) boot: Multicore bootloader
I (37) boot: chip revision: v1.0
I (41) boot.esp32: SPI Speed      : 40MHz
I (45) boot.esp32: SPI Mode       : DIO
I (50) boot.esp32: SPI Flash Size : 4MB
I (54) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (63) 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 (97) esp_image: segment 0: paddr=00010020 vaddr=3c0d0020 size=0ffd8h ( 65496) load
E (106) esp_image: Segment 0 0x3c0d0020-0x3c0dfff8 invalid: bad load address range
0x3c0dfff8 - anon.ab806ba04efe4573400ddf1c6591897b.0.llvm.4787499095392638493
    at ??:??
E (114) boot: Factory app partition is not bootable
E (119) boot: No bootable app partitions in the partition table

Does anyone know hot to resolve this issue?
Thanks in advance!

Tasks

Preview Give feedback
No tasks being tracked yet.
@SergioGasquez
Copy link
Member

SergioGasquez commented Dec 16, 2024

A new version of espflash is available: v3.2.0

Can you try updating your espflash and see if the issue persists?

@J0y8993
Copy link
Author

J0y8993 commented Dec 16, 2024

@SergioGasquez I am using the docker image. I am unsure how I should update it inside of there?

@SergioGasquez
Copy link
Member

@SergioGasquez I am using the docker image. I am unsure how I should update it inside of there?

I assume that you ran the docker image a while ago. You could cargo install espflash, that should update it. Or delete the image and let https://github.com/esp-rs/std-training/blob/main/.devcontainer/Dockerfile#L37-L43 grab the latest version

@J0y8993
Copy link
Author

J0y8993 commented Dec 20, 2024

@SergioGasquez I installed the container new using the link you provide, therefore I have the newest esp version, but I still get the same loop. On a good-ish side the auto port detection was fixed...

@jessebraham jessebraham added the bug Something isn't working label Jan 9, 2025
@jessebraham jessebraham added the status:needs-investigation Issue requires further investigation label Jan 20, 2025
@theembeddedrustacean
Copy link

I have been experimenting with the same device (ESP-WROOM-32), and I am running into what seems to be a similar issue on the flashing end. This is with esp-flash v3.3.0.

[2025-02-06T08:32:15Z INFO ] Detected 2 serial ports
[2025-02-06T08:32:15Z INFO ] Ports which match a known common dev board are highlighted
[2025-02-06T08:32:15Z INFO ] Please select a port
[2025-02-06T08:32:16Z INFO ] Serial port: '/dev/cu.usbserial-0001'
[2025-02-06T08:32:16Z INFO ] Connecting...
[2025-02-06T08:32:18Z INFO ] Using flash stub
Chip type:         esp32 (revision v3.1)
Crystal frequency: 40 MHz
Flash size:        4MB
Features:          WiFi, BT, Dual Core, 240MHz, Coding Scheme None
MAC address:       e4:65:b8:13:bc:cc
App/part. size:    670,928/4,128,768 bytes, 16.25%
[2025-02-06T08:32:19Z INFO ] Segment at address '0x1000' has not changed, skipping write
[2025-02-06T08:32:19Z INFO ] Segment at address '0x8000' has not changed, skipping write
[2025-02-06T08:32:20Z INFO ] Segment at address '0x10000' has not changed, skipping write
[2025-02-06T08:32:20Z INFO ] Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (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:DIO, clock div:2
load:0x3fff0030,len:7104
load:0x40078000,len:15576
load:0x40080400,len:4
ho 8 tail 4 room 4
load:0x40080404,len:3876
entry 0x4008064c
I (31) boot: ESP-IDF v5.1-beta1-378-gea5e0ff298-dirt 2nd stage bootloader
I (31) boot: compile time Jun  7 2023 07:48:23
I (33) boot: Multicore bootloader
I (37) boot: chip revision: v3.1
I (41) boot.esp32: SPI Speed      : 40MHz
I (46) boot.esp32: SPI Mode       : DIO
I (50) boot.esp32: 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 (79) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 003f0000
I (94) boot: End of partition table
I (98) esp_image: segment 0: paddr=00010020 vaddr=00000001 size=000a4h (   164) 
I (106) esp_image: segment 1: paddr=000100cc vaddr=3ffb0000 size=015a0h (  5536) load
I (117) esp_image: segment 2: paddr=00011674 vaddr=3ffdbd94 size=00214h (   532) load
E (123) esp_image: Segment 2 0x3ffdbd94-0x3ffdbfa8 invalid: overlaps bootloader stack
E (131) boot: Factory app partition is not bootable
E (137) boot: No bootable app partitions in the partition table
ets Jul 29 2019 12:21:46

@SergioGasquez
Copy link
Member

Hi! Not sure if its the same problem, looking at @J0y8993 error again, Ive noticed that the issue is trying to flash an application for C3, the training was meant for this chip, (target/riscv32imc-esp-espidf/debug/hardware-check`) into an ESP32, see https://docs.esp-rs.org/std-training/01_intro.html#the-board. Running the training on an ESP32 (Xtensa) would require some changes on the training materials.

Regarding @theembeddedrustacean issue, it might be the same, but I don't have enough information, mind sharing a reproducer?

@SergioGasquez SergioGasquez self-assigned this Feb 6, 2025
@theembeddedrustacean
Copy link

theembeddedrustacean commented Feb 6, 2025

Hi! Not sure if its the same problem, looking at @J0y8993 error again, Ive noticed that the issue is trying to flash an application for C3, the training was meant for this chip, (target/riscv32imc-esp-espidf/debug/hardware-check`) into an ESP32, see https://docs.esp-rs.org/std-training/01_intro.html#the-board. Running the training on an ESP32 (Xtensa) would require some changes on the training materials.

Regarding @theembeddedrustacean issue, it might be the same, but I don't have enough information, mind sharing a reproducer?

You're probably right. After some tinkering, I actually encountered another issue that, upon fixing, resolved this one for me. It seems associated with the size of the binary generated.

To give some context, I was using embassy in a lib project, where I had to increase the embassy-executor task arena size. While the lib project was actually built successfully, I would face the error cited in this issue when flashing.

Upon creating a separate binary project and importing the crate from the lib project, when attempting to build, I got a linker error indicating that I was exceeding the available dram_seg. Upon reducing the task arena size to resolve the linker error, the build succeeded, and the flashing error was resolved as well.

While I am happy that now its working, I am really confused why the build actually succeeded in one case while in another it did not.

@SergioGasquez
Copy link
Member

Glad that is now resolved, Ill be closing the issue as this is not really related to espflash

@github-project-automation github-project-automation bot moved this from Todo to Done in esp-rs Feb 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working status:needs-investigation Issue requires further investigation
Projects
Archived in project
Development

No branches or pull requests

4 participants