[4.0] read_flash - stub cannot read full 16MB (ESPTOOL-460) #745
Comments
github-actions
bot
changed the title
|
Reading with How much of the flash should I expect to be usable currently? I will adjust my partition table accordingly, even if temporarily must limit to 8MB flash.... |
|
I also have had problems with read_flash Microsoft Windows [Version 10.0.19044.1865] D:\Documents\ARDUINO\esp32\RejasCan_v3-1>esptool.lnk flash_id D:\Documents\ARDUINO\esp32\RejasCan_v3-1>esptool.lnk --no-stub -b 1000000000 read_flash 0 0x100000 flash_1mbb_contents.bin D:\Documents\ARDUINO\esp32\RejasCan_v3-1>esptool.lnk --no-stub read_flash 0 0x400000 flash_4mb_contents.bin D:\Documents\ARDUINO\esp32\RejasCan_v3-1> |
|
Great! Based on the bot comment (ESPTOOL-460), I understand that this entered the Espressif bug triage database. (( In other words, someone will at least look at this issue some more. )) Looking forward to the stub (or even the no-stub) working for these 32MB Flash devkits.... |
|
Hi @dobairland, With 4.3, the Unfortunately, the issue persists with v4.3: FYI, the following works reliably at higher baud rate, so the cables are not suspect: Anyways, the failure is 100% repro, and takes less than 10 seconds: Simply connect a DevKit-C1 (N32R8) using its UART port. |
|
Thanks for checking. We will try to address this soon.... |
|
@dobairoland: Hello, Roland! This is just a periodic check-in. I will limit these to once per ~3-4 weeks, unless you suggest a different period of time. The purpose is to see if there is any update on the issue. For example, have you been able to reproduce the underlying issue (even if not understanding the root cause)? Is there a different (but currently supported) method to read and write to the full 32MB of flash on these devices? Thanks! |
|
Hello @henrygab, I can verify that the issue is completely reproducible, your detailed report is spot on. The root cause is not fully known yet. You can see We haven't come up with a fix, yet. |
|
Hello @radimkarnis , First, I want to thank you for your open communication on what you discovered in the last post. I appreciate your sharing the status. Another month has flown by, so I thought I'd check in again ... see if any updates (even if only that you've tried three ideas, and each one hit a blocking issue; or that a new ROM / chip revision will be necessary). I realize it's not possible to change the ROM, so any software workaround would require some amazing hack. If you do end up creating such a hack, I'd love to hear the story ... and both cringe and cheer at your creative solution! Thanks again for the last update, letting us all know it's related to a failing assertion in the ROM, and good luck! |
|
@henrygab Imho it should be possible to solve with the stub. Since the stub does not have the need to use the (faulty?) rom routines. Everything needed can be baked in the stub code. |
|
I thought I had found an answer on an unrelated forum (forum shown below). While it doesn't fail with the "Invalid head of packet (0x6F):" error immediately, read_flash fails at 2097152 (14%) regardless of what baud rate I attempt. e.g. "esptool -b 115200 read_flash 0 0xE00000 flash_contents.bin" running on ubuntu 18.04. https://forum.micropython.org/viewtopic.php?t=7138 |
|
@radimkarnis -- Monthly request for an update. Can you verify if the potential fix Jason2866 found will be sufficient to resolve the issue? It does appear to be a bug in the code, and would seem to be directly related. If this is the right fix, can you push for it to be integrated into a release ASAP? |
|
I'm working on this actively. That potential fix with other similar ones solves only the 16 MB boundary issue. I thought that I will fix it together with the 32 MB support issue but since that is more complicated, I'll separate it and prepare this one earlier. |
|
@henrygab although the potential fix @Jason2866 made fixes the issue of not being able to read/write the last byte of 16M flash, it doesn't explain the behavior you reported. This isn't related. Nevertheless, I have tried it and it still fails exactly as you described. |
|
Bummer! Would have been great if such a simple root cause. Happy holidays and new year! |
|
Wishing you happy holidays and a bright 2023 from your friends at Espressif! |
* fix(setup): Use latest reedsolo package which can be installed with Python3.10 and Cython Closes espressif#711 * feat(ci): Publish development releases with custom pipeline * fix(ci): The development release job should not run by default Gitlab rules:if adds the job if any of the rules are true. * fix(ci): Merge two "ci" directories and build_tools into one * fix(secure download mode): Fix SDM detection on S2/S3 * fix(secure download mode): Reconnect if ROM refuses to respond Closes espressif#813 * fix(flasher_stub): Correct boundaries for SPIWrite4B and SPIRead4B SPIWrite4B and SPIRead4B functions are required for flash sizes bigger than 16MB. This fix corrects the boundaries so SPIWrite and SPIRead would be used for the whole 16MB area. The octal flash support for 32 MB chips (espressif#795) will be added in a follow-up commit. Closes espressif#745 Co-authored-by: Roland Dobai <[email protected]> Co-authored-by: radim.karnis <[email protected]>
* Tasmota changes * stubs updated * S3 16MB fix (#4) * fix(setup): Use latest reedsolo package which can be installed with Python3.10 and Cython Closes espressif#711 * feat(ci): Publish development releases with custom pipeline * fix(ci): The development release job should not run by default Gitlab rules:if adds the job if any of the rules are true. * fix(ci): Merge two "ci" directories and build_tools into one * fix(secure download mode): Fix SDM detection on S2/S3 * fix(secure download mode): Reconnect if ROM refuses to respond Closes espressif#813 * fix(flasher_stub): Correct boundaries for SPIWrite4B and SPIRead4B SPIWrite4B and SPIRead4B functions are required for flash sizes bigger than 16MB. This fix corrects the boundaries so SPIWrite and SPIRead would be used for the whole 16MB area. The octal flash support for 32 MB chips (espressif#795) will be added in a follow-up commit. Closes espressif#745 Co-authored-by: Roland Dobai <[email protected]> Co-authored-by: radim.karnis <[email protected]> * Update stub_flasher_32s3beta2.json * Update build_esptool.yml * Update build_esptool.yml * stubs updated Co-authored-by: Github BUILD <[email protected]> Co-authored-by: Roland Dobai <[email protected]> Co-authored-by: radim.karnis <[email protected]>
* S3 16MB fix (#4) * fix(setup): Use latest reedsolo package which can be installed with Python3.10 and Cython Closes espressif#711 * feat(ci): Publish development releases with custom pipeline * fix(ci): The development release job should not run by default Gitlab rules:if adds the job if any of the rules are true. * fix(ci): Merge two "ci" directories and build_tools into one * fix(secure download mode): Fix SDM detection on S2/S3 * fix(secure download mode): Reconnect if ROM refuses to respond Closes espressif#813 * fix(flasher_stub): Correct boundaries for SPIWrite4B and SPIRead4B SPIWrite4B and SPIRead4B functions are required for flash sizes bigger than 16MB. This fix corrects the boundaries so SPIWrite and SPIRead would be used for the whole 16MB area. The octal flash support for 32 MB chips (espressif#795) will be added in a follow-up commit. Closes espressif#745 Co-authored-by: Roland Dobai <[email protected]> Co-authored-by: radim.karnis <[email protected]> * Update stub_flasher_32s3beta2.json * Update build_esptool.yml * Update build_esptool.yml * stubs updated Co-authored-by: Github BUILD <[email protected]> Co-authored-by: Roland Dobai <[email protected]> Co-authored-by: radim.karnis <[email protected]> * stubs updated * stubs updated Co-authored-by: Github BUILD <[email protected]> Co-authored-by: Roland Dobai <[email protected]> Co-authored-by: radim.karnis <[email protected]>
SPIWrite4B and SPIRead4B functions are required for flash sizes bigger than 16MB. This fix corrects the boundaries so SPIWrite and SPIRead would be used for the whole 16MB area. The octal flash support for 32 MB chips (espressif/esptool#795) will be added in a follow-up commit. Closes espressif/esptool#745
Octal flash support tested up to 32MB. Quad flash support is limited to 16MB at this moment. Closes espressif/esptool#795 Closes espressif/esptool#745 The next release will solve espressif/esp-idf#10323 as well.
|
Just wondering if anyone has a fix to this? I am getting a failure right at 2MB the failure address + the offset = 2MB seems weird I can do the verify_flash command
which returns the correct response digest matching/mismatching |
Operating System
Windows 11 (21H2 Build 22000.675)
Version
other
Python Version
.EXE release v4.0 of tool (although I have 3.9.13 installed)
Chip Description
ESP32-S3-DevKitC-1 (N32R8V)
Device Description
ESP32-S3-DevKitC-1 (N32R8V) ... which has 32MB of flash, but I'm only trying to dump 16MB using the stub....
Hardware Configuration
Nothing but a USB cable connecting the
UARTport to the PC.How is Esptool Run
No IDE, straight from cmd.exe
Full Esptool Command Line that Was Run
esptool --baud 115200 read_flash 16252928 524288 ..\ESP32-S3-DevKitC-1-N32R8__start-at-15.5MB.bin
Esptool Output
More Information
This is a fresh-from-the-factory device, never written to, and still running the default blink sketch.
When trying to dump 32MB, the tool reports (as expected) that the stub supports up to 16MB:
The following tables show 100% reproducible results for various combinations of start address and size being dumped.
Fails immediately when end address == 16MB
The following is the fatal error printed for each failure below:
Seems the stub cannot actually be used to dump 16MB flash directly, because it does not like the end address being equal to 16MB.
Starting at 0, fails dumping >8MB
I have not noticed how the inputs affect these 100% repro failures, based on this evidence.
100% repro with varied start/size
The above table confuses my guesses ... although 100% reproducible, the failure point does not appear to correspond to an address, does not appear to correspond to an amount completed, ... Not sure what else I could offer here.
So, in summary, the stub can read many of the addresses, but there's something wrong with its handling of >8MB (not >16MB as suggested). See attached traces for trace output of two commands that immediately report the
Invalid head of packet (0x6F)error.Other Steps to Reproduce
No response
I Have Read the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: