Flashing `esp32-s3` with `probe-rs` causes flash algorithm verification fail about probe-rs HOT 14 OPEN

I chose Esp-Idf version 5.

Thank you, this is where the problem lies. Esp-idf does something fishy that we're not prepared to deal with.

from probe-rs.

@bugadani Would it be wise to choose ESP-IDF version 4?

from probe-rs.

Hold on, I'm trying V4 and will report back.

from probe-rs.

You should instead try and put your board into Download mode before flashing: press and hold Reset, press and hold Boot0, release Reset, release Boot0. You'll probably be able to flash the board, but I don't think you'll be able to debug it yet. I'll have to look into it some more, I've largely been ignoring this issue but we know about it because the devkits ship with some esp-idf based default firmware.

from probe-rs.

No change with either V4 or V5.
I get the following error.

 INFO probe_rs::session: Core status: Halted(Breakpoint(Software))
 INFO probe_rs::session: Core status: Halted(Breakpoint(Software))
 WARN probe_rs::util::rtt: No RTT header info was present in the ELF file. Does your firmware run RTT?
 INFO probe_rs::session: Core status: Halted(Breakpoint(Software))
 INFO probe_rs::session: Core status: Halted(Breakpoint(Software))                                                                                                                                                         Error: The flashing procedure failed for 'target/xtensa-esp32s3-espidf/debug/esp32'.

Caused by:
    0: Failed to erase flash sector at address 0x00010000.
    1: The execution of 'erase_sector' failed with code 65536. This might indicate a problem with the flash algorithm.

Do we have a tracking issue for this board / ESP-IDF v5? Or is it just the XTENSA tracking issue?

from probe-rs.

After trying the ESP32-C3 in a past issue and now with this board failing, this sadly marks the end of my rust debugging journey on espressif board for now.

I will buy the C6 and report back.

from probe-rs.

I will buy the C6 and report back.

Please do not waste your money when the issue is specific to the software framework you're trying to use. Also please read my last message on what you may try. You can also try bare-metal development with esp-hal, if you can get past replacing the esp-idf based default firmware on your devkit it should be a much smoother experience.

from probe-rs.

Whoops, error on my part. I have tried entering Download mode exactly how you told me. I see no difference in behaviour. Should I see any feedback from the board?

It's also not my money since my employer pays for the boards, so I see no issue in wasting a bit of money lol.

I'm not sure bare-metal development is enough for my use case. I need access to file storage, bluetooth le and the wifi component.

Not being able to debug is not ideal, but espflash works without issue, so I can flash that way and work my way through with print statements.

from probe-rs.

Download mode doesn't have a visual indicator, unfortunately.

One more thing you may try is erasing the board with espflash erase-flash. If that doesn't work and probe-rs fails you, you can always fall back to espflash. This will get eventually resolved but it's not really anyone's priority as far as I can tell.

from probe-rs.

This has been my workflow for the past weeks already. Openocd also works without issue, but I can't get debugging symbols to be correct when using cppdbg and a gdb server with my rust projects.

from probe-rs.

Are there any beginner Issues I could look at? If anything, I have a lot of time since this project is partly relevant to my PhD and I'm essentially getting paid for working on this. I would love to contribute, if possible, but I would still consider myself a beginner in embedded development.

from probe-rs.

Running with --chip-erase also gives the following output, if it helps.

probe-rs run --chip esp32s3 target/xtensa-esp32s3-espidf/debug/esp32 --chi
p-erase
 WARN probe_rs::util::rtt: No RTT header info was present in the ELF file. Does your firmware run RTT?
ERROR nusb::platform::macos_iokit::transfer: Failed to submit transfer on endpoint 2: e000404f                                 WARN probe_rs::session: Could not clear all hardware breakpoints: An error with the usage of the probe occurred

Caused by:
    0: USB Communication Error
    1: unknown error                                                                                                          ERROR nusb::platform::macos_iokit::transfer: Failed to submit transfer on endpoint 2: e000404f                                 WARN probe_rs::session: Failed to deconfigure device during shutdown: An error with the usage of the probe occurred

Caused by:
    0: USB Communication Error
    1: unknown error                                                                                                          Error: The flashing procedure failed for 'target/xtensa-esp32s3-espidf/debug/esp32'.

Caused by:
    0: Failed to erase the whole chip.
    1: Something during the interaction with the core went wrong
    2: An error with the usage of the probe occurred
    3: USB Communication Error
    4: unknown error

I have not yet figured out how to run probe-rs without erasing first (since I do that with espflash already)

from probe-rs.

Running with --chip-erase also gives the following output, if it helps.

Well I did ask you to run espflash flash-erase for a reason, and not probe-rs with whatever chip-erase it can do :)

I have a few assigned to me that seemed like low hanging fruit :)

None of these are relevant to your issue, unfortunately.

This current issue is similar to #1963 and @MabezDev is also working on #2164 which is intended to solve similar issues, hopefully finishing that PR will help.

from probe-rs.

Well I did ask you to run espflash flash-erase for a reason, and not probe-rs with whatever chip-erase it can do :)

Yes :) Sorry if I was a bit unclear, running espflash flash-erase and then trying to flash with probe-rs does not work either. I just wanted to provide more error outputs to be helpful.

None of these are relevant to your issue, unfortunately.

I will try to look into them to learn more about how probe-rs works :)

This current issue is similar to #1963 and @MabezDev is also working on #2164 which is intended to solve similar issues, hopefully finishing that PR will help.

Thanks for the guidance, I'm looking forward to it

from probe-rs.