flash fail on esp32-c3

[nim65s]

flash fail on esp32-c3

[noppej]

Glad to hear it is working though!

Me too. I thought I was going to have to buy a new dev kit ... except DigiKey Canada sells them with a minimum order quantity of 240 units (Cdn$ 6760.89) ... ROTFL

[MabezDev]

stlink is swd only, so you won't be able to flash a esp with that, so I will ignore case 2 here.

As for using the usb-serial-jtag on the esp32c3, its working for me?

Could you try holding the boot pin down whilst plugging in the USB? If the board is resetting because of the previously flashed application fast enough, the usb-serial-jtag device can reset too. Putting it into download mode should stop that behavior.

[nim65s]

This one is still broken for me

[MabezDev]

That said, first I had to run into ... thread 'main' panicked at probe-rs/src/probe/espusbjtag/protocol.rs:152:38: index out of bounds: the len is 0 but the index is 0 ... a few times. The good news, it is reproduce-able if you set speed 24000 on your connection.

I've run into that too, it looks like an nusb issue/difference - I should be able to solve that too. Glad to hear it is working though!

[MabezDev]

FYI #2173 has fixed the index out of range issue on a cold start up of the espusbjtag probe.

[nim65s]

Thanks for your answer. I already have a blinky flashed (with espflash), and when I hold the BOOT button while plugging the USB (or puhing the RST button), the LED is not blinking, so I guess it is effectively in download mode, but I still have the exact same error message, whether I release BOOT before runningcargo run --example blinky --release or not 😢

And thanks for the info on stlink. Could you recommend a device with the ability to flash + RTT + debug for esp32-c3 ? I tried a pickit 4, but probe-rs says No debug probes were found., and a hs-probe, but I get The connected probe does not support the interface 'RISC-V'

As I'm trying to make USB devices, embedded usb-serial-jtag on newer esp32-c3 chips won't be an option for RTT/debug anyways.

[bugadani]

It's possible we weren't rigorous enough when testing some of the latest changes. Could you please try copying either https://github.com/probe-rs/probe-rs/blame/f13397ec4feeb4bb3c3ed044a087224fa6f1c34e/probe-rs/targets/esp32c3.yaml or https://github.com/probe-rs/probe-rs/blame/6df7fbd0f656ad5ff9889d198baee0a6af6fd081/probe-rs/targets/esp32c3.yaml to your project root and changing your runner to runner = "probe-rs run --chip esp32c3 --chip-description-path esp32c3.yaml"?

[nim65s]

Thanks @bugadani, it looks like this is working for me with both files ! I also have RTT output here.

And I can reproduce the previous error by using the file from master https://github.com/probe-rs/probe-rs/blob/master/probe-rs/targets/esp32c3.yaml

[bugadani]

I don't have a C3 so I can't test it, but I re-generated the flash loader here. Can I ask one of you to test if this is better or still broken?

[MabezDev]

I've reproduced the error now, but it seems somewhat random as to when it happens.

Could you try:

1. Flash with espflash instead of probe-rs
2. Once the app is running (check the serial monitor to see that its not resetting repeatedly)
3. Try flashing with probe-rs again

For me this consistently works provided there is an application already running.

[nim65s]

Flashing blinky with espflash works, and the monitor looks good. After this, trying to flash again blinky with probe-rs still time out.

[noppej]

@MabezDev and @bugadani I'm still unable to flash my esp32-c3 with probe-rs master branch. espflash works fine.

The error I get varies between three:

1. Same as what @nim65s encountered

Connecting to the chip was unsuccessful.
  "A RISC-V specific error occurred."
  	"Timeout during DMI access."

3. probe-rs panics (usually if I did the thing ^^^ with holding the boot button while plugging in USB) with

thread 'main' panicked at probe-rs/src/probe/espusbjtag/protocol.rs:152:38:
index out of bounds: the len is 0 but the index is 0

[noppej]

@MabezDev or @bugadani ... I hooked up the UART monitor to my board, and it complains about SHA-256 comparision failed. Is this significant or a red-herring?

(50) boot: ESP-IDF v5.1-beta1-378-gea5e0ff298-dirt 2nd stage bootloader
(50) boot: compile time Jun  7 2023 07:59:10
(51) boot: chip revision: v0.3
(55) boot.esp32c3: SPI Speed      : 40MHz
(60) boot.esp32c3: SPI Mode       : DIO
(65) boot.esp32c3: SPI Flash Size : 4MB
(69) boot: Enabling RNG early entropy source...
(75) boot: Partition Table:
(78) boot: ## Label            Usage          Type ST Offset   Length
(86) boot:  0 nvs              WiFi data        01 02 00009000 00006000
(93) boot:  1 phy_init         RF data          01 01 0000f000 00001000
(101) boot:  2 factory          factory app      00 00 00010000 003f0000
(108) boot: End of partition table
(112) esp_image: segment 0: paddr=00010020 vaddr=3c030020 size=06f14h ( 28436) map
(127) esp_image: segment 1: paddr=00016f3c vaddr=40380000 size=011fch (  4604) load
(130) esp_image: segment 2: paddr=00018140 vaddr=00000000 size=07ed8h ( 32472) 
(144) esp_image: segment 3: paddr=00020020 vaddr=42000020 size=2fd54h (195924) map
(189) boot: Loaded app from partition at offset 0x10000
(189) boot: Disabling RNG early entropy source...
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:0x3fcd5820,len:0x171c
load:0x403cc710,len:0x968
load:0x403ce710,len:0x2f68
SHA-256 comparison failed:
Calculated: 1d06b938c0222bf626e0bdf46178b1b37ab24d03f0360fc8fcf7153c2571deaf
Expected: 68d7bdf643ba446b8ed7ae8423241d442fd052b2bc77091100ba06fd65dcf8d5
Attempting to boot anyway...
entry 0x403cc710
(50) boot: ESP-IDF v5.1-beta1-378-gea5e0ff298-dirt 2nd stage bootloader
(50) boot: compile time Jun  7 2023 07:59:10
(51) boot: chip revision: v0.3
(55) boot.esp32c3: SPI Speed      : 40MHz
(60) boot.esp32c3: SPI Mode       : DIO
(65) boot.esp32c3: SPI Flash Size : 4MB
(69) boot: Enabling RNG early entropy source...
(75) boot: Partition Table:
(78) boot: ## Label            Usage          Type ST Offset   Length
(86) boot:  0 nvs              WiFi data        01 02 00009000 00006000
(93) boot:  1 phy_init         RF data          01 01 0000f000 00001000
(101) boot:  2 factory          factory app      00 00 00010000 003f0000
(108) boot: End of partition table
(112) esp_image: segment 0: paddr=00010020 vaddr=3c030020 size=06f14h ( 28436) map
(127) esp_image: segment 1: paddr=00016f3c vaddr=40380000 size=011fch (  4604) load
(130) esp_image: segment 2: paddr=00018140 vaddr=00000000 size=07ed8h ( 32472) 
(144) esp_image: segment 3: paddr=00020020 vaddr=42000020 size=2fd54h (195924) map
(189) boot: Loaded app from partition at offset 0x10000
(189) boot: Disabling RNG early entropy source...

[bugadani]

Is this significant or a red-herring?

It's a bug in espflash, nothing to worry about.

[noppej]

So not related to the inability to flash? #2023 (comment)

[bugadani]

No, the SHA comparison problem is a purely cosmetic issue caused by espflash. The library modifies prebuild bootloader images, but does not (yet) recalculate its checksum before handing it back to probe-rs.

[noppej]

Do you think I have a hardware problem, or are other people (besides OP) also having problems with this chip?

[MabezDev]

@noppej @nim65s Could you try this branch please: #2151.

I noticed the core was still running after attach, which could be very bad since we start poking the flash chip in the sequences, meaning cache pulls and the probe are likely to collide and well after that all bets are off.

[noppej]

WhootWhoot ... that works for me! 5 times in a row (I'm an experienced optimist ... LOL)

That said, first I had to run into ... thread 'main' panicked at probe-rs/src/probe/espusbjtag/protocol.rs:152:38: index out of bounds: the len is 0 but the index is 0 ... a few times. The good news, it is reproduce-able if you set speed 24000 on your connection.

[bugadani]

The good news, it is reproduce-able if you set speed 24000

Well then, don't 😅. The error message is consistent with the MCU restarting mid-flash, but 24MHz may also be just too fast for it. I'm assuming you're using an external JTAG probe if this makes a consistent difference - the espusbjtag driver just ignores --speed.

[noppej]

the espusbjtag driver just ignores --speed.

That just proves that my test case was a red herring. I am not using external probe ... direct connect to the esp32-c3 devkit.

After unplugging, and the replugging, I get the error consistently. Then I hold down boot while plugging in, then reset, and then I can flash again. Let me know if you need help debugging.

[juliankrieger]

Do you think I have a hardware problem, or are other people (besides OP) also having problems with this chip?

I am unfortunately also having similar issues with the C3 Devkit M1. Seems like the default speed is too high. Setting it to 10k worked for me so far.