ESP32-S3 - Random crashes when reading/writing flash (ESPTOOL-608) #832
Comments
github-actions
bot
changed the title
|
Hi @mrdude2478, |
|
Sorry for the late reply, I had lent out the dongle to a friend and just got it back. I am still getting the same random read errors with 4.5.dev3. Here's the output: Note: If flashing via Arduino IDE, I never get an error flashing, but with esptool, I usually get an error, So com port and PC settings are fine. Regards. |
But you don't read flash with Arduino, only write to it - so, does flashing directly with esptool also work? If writing flash works, we can focus solely on the
|
|
Thanks, with --no-stub I get more success (I already said this in the first post), but it takes a very long time - over an hour to read, and sometimes crashes with the same errors. I have also tried reading at various baud rates all the way down to 9600. I am aware you don't read flash with Arduino, only write - but I never get any errors writing with Arduino, whereas with esptool I do. If you look at the output I posted I clearly states that I am using "esptool.py v4.5.dev3" as per your advice. I know you are trying to help, I am just pointing out the issues though with ESP32-S3, I know it's a new-ish chip, maybe the issue is something to do with timing during read cycles??? |
Sorry, I overlooked that.
But I am asking about the version of esptool in Arduino - it actually also uses esptool.py to flash the chip. So if flashing works in Arduino but doesn't when esptool is downloaded directly, there must be a regression between these two versions. If we can locate the version when this regression got introduced, it will be easy to fix. |
|
This has been added to boards manager: Installed board: Arduino output says - esptool.py v4.2.1 during flashing. Does that help? |
Yes, this is what I am asking about. So this means there was a change somewhere between In that case, a quick fix for you is to just use esptool v4.2.1 ( We can try to identify the exact change that introduced the regression. Would you be willing to help us with that? If yes, you would have to install esptool in development mode. Please, let me know if you can do that. |
|
Thanks for the reply, I installed the latest build in dev mode - this is the output when trying to dump: |
|
Update: I have uninstalled python, cleaned the registry, removed all python environmental variables, removed all orphaned python files from my AppData/local folder & roaming folders + temp files, carried out a disc cleanup, rebooted my PC and checked to see if anything python related exists - so I have purged my system of python and anything python related. Then I ran the latest esptool.exe posted yesterday - and the problem still persists even after everything is cleaned??? Maybe it's the onboad 16MB flash, it just seems wierd I can always flash successfully with Arduino and the baudrate uses 921600 with that as well, where it fails with esptool.exe. I will leave python uninstalled for now, and follow instructions from this point. Also I find it weird why 4.2.1 esptool.py works in Arduino, yet 4.2.1esptool.exe gives this error? |
|
Next thing I did was manually replace esptool.exe in Arduino from 4.2.1 to 4.5 - see pic: Then flashed the board from Arduino - Next try again - 4.5 now causes Arduino to fail randomly (never had this issue before) This is weird, perhaps Arduino is using some different command line option to flash as I never get any errors with it ??? |
|
Next using the same command line options that Arduino uses to flash the firmware partition of the chip: (using 4.5 esptool.exe) Output: Using the same command line option with 4.2.1 esptool.exe It seems something code wise broke 4.5/4.4 compared to 4.2.1... I tested flashing with 4.2.1 ten times in a row using the above command line option and it never failed. (adding --flash_mode dio to the command line when writing with 4.2.1 makes it work) OK, now I figured 4.2.1 works ok using the --flash_mode dio option, where 4.4/4.5 fails so I made a gui to test at different baud rates etc, to save me typing..... Hopefully 4.5/4.6 will be fixed and will stop crashing.... |
|
Further testing shows that this commit is what broke the functionality: Oct - 17 - Flasher stub: Increase CPU frequency to 240 MHz for ESP32-S3 Oct - 11 - OK Also when using no stub option, this seems to work better so I think it's something to do with that stub code that's causing the problems. I then replaced esptool/targets/stub_flasher/stub_flasher_32s3.json from commit 0656f77 with the one in the latest esptool.py v4.6-dev build and this seems to fix the issues I was having flashing the chip, however it wouldn't read the chip if over 0xFFFFF bytes. |
|
@mrdude2478 thanks for your awesome investigation! I suspected this commit might be the culprit. There were multiple reports that this caused some issues, but this was later fixed in f37f384 - this fix was reported to help in all cases (see #808 for more info). For some reason, this didn't help in your case. What's also weird is that in your case it's pretty random (in some cases flashing even succeeds). In other reports, this failed right away. Unfortunately, I am not able to reproduce this issue. It has proven to be heavily dependent on the chip and flashing environment. So it is quite difficult to debug and fix. |
Ok so this is getting even weirder. The stub in the current |
|
Thanks for replying, I don't know how these stub files are encrypted - they look to be some sort of hashed base64, but I couldn't decrypt them, do you have any idea so that I can compare both files and them maybe edit the contents of the one in commit 0656f77 so that it can read a 16MB flash? |
|
@mrdude2478 of course, you can find the source in the |
Thanks I'll have a look at that. |
Maybe you read that wrong - I am using the stub from commit [0656f77] with the latest esptool (v4.6-dev). The new stub file that comes with everything after commit [0656f77] is what is causing the issues. |
|
Maybe reverting the increased clock for flash and SPI commit? Seems it makes trouble sometimes. Better a bit slower and working always. |
|
I am not sure what the vendor is, the dongle is here 16MB flash: https://www.lilygo.cc/products/t-dongle-s3 I used a magnifying glass to see the flash chip and I think it says winbond, but my eyesight is not the best so I could be mistaken. |
|
@mrdude2478 there was another solution proposed here: https://github.com/radimkarnis/esptool/tree/test/lower_cpu_freq If you could try this branch and verify if this works in your case, I would by grateful. |
|
Yes, I'll try it just in about 10 minutes. Also I think the flash is winbond - W25Q32 |
|
Yes, success - I was able to read the enitre 16MB flash on the first attempt. This is the first time I have been able to do this. Thanks for that link, do you think you will be able to tell me how to convert the python file into an exe, I tried using pyinstaller, It worked making an exe but I couldn't get it to pack the stub files with the exe - maybe I use the wrong arguments. |
|
@mrdude2478 Winbond if genuine known to be a high quality flash. The pyinstaller command |
|
@mrdude2478 thanks for verifying! as @Jason2866 said, you need to use the |
|
Thanks, I'll test that out later, I need to have a sleep now as I am struggling to keep my eyes open. Thanks for all the help. |
|
@mrdude2478 Compiled versions with Clock 160Mhz built from latest master, just clock changed https://github.com/Jason2866/esptool/releases/tag/v4.5.1 |
Thank you very much. That's very much appreciated. |
|
@Jason2866 thanks for making that easier. @mrdude2478 if this version works for you, I will bring this change upstream and add it to esptool. |
Flashing is a 100% improvement, I don't get any errors with this version, however reading still has random read issues. I checked from that github page again, and that was the same - maybe it was a fluke the first time I used it, but definately this is an improvement for flashing the chip as I haven't had an error and I've tried flashing about 20 times to test. |
|
Just tested out of curiosity serial baud rate 2M, never worked before. I thought the problem is the USB serial chip which stalls. Seems i was wrong, tried a few times. Was always successful with 2M. So the issue was in esptool.py. Did not test since what commit this high speed is working. Nice! |
|
With Pyinstaller in windows I managed to get esptool to compile into a single exe like this: I navigated into the root esptool folder and then issued this command: This worked fine and put all the files needed into the proper locations, that command line seems a little long compared to the other examples posted for linux, did I do something wrong & there's perhaps a shorter way??? I am only asking for future reference. @Jason2866 , did you try reading the entire flash contents as well as writing? With 4.2.1 I can succesfully read partitions if I set the offsets and partition size for firmware/bootloader/partitions sections of the chip - but not the entire chip - so I need to read a section at a time and then manually join them. With the exe you posted I can flash really well (thanks), but reading is a different matter - is there something you can adjust in the code to lower the reading clock speed of the chip as I believe this is why there's an issue? Also I am not sure if this info is of any use, but the chip manufacturer is reported as: |
@Jason2866 it is important to note that the fix we are talking about only applies to USB-Serial/JTAG mode on the S3. In this mode, a USB-to-UART bridge ("USB serial chip") is not used. |
|
@mrdude2478 I am far away to have a clue how to do this. Just copied the value for 160Mhz from the provided test branch in the actual code base. Did not test to read the whole flash with this version. Had no issues with the 240Mhz clocked one so i do not expect this version won't work. Will have a look when i find time for. |
Tried both modes (JTAG and classic Serial). Both worked fine for flashing. So a other change was done since the last time trying higher USB serial classic speed. |
|
Please re-open issue. After trying the new builds I was still having issues with crashing, even after the cpu clock speed was reduced by half. I ended up installing the sdk and have found that this was causing the issues in reading/writing. esptool\flasher_stub\include\soc_support.h Picture below shows mods: Altering the code to what is shown in the picture and then re-compiling the stubs fixed the errors I was having and now gives the same stability as this commit version 8386dcb. After this is where the issues began. I looked at that code and am unsure what adding these addresses on to those clock registers actually does, as when the code was altered the chip is able to be read/write much better (always 100% successfully). I put the cpu period back to 240 Mhz, and this was also working fine. I had a look here: And saw that the Sytem registers were at 0x600C_0000, I couldn't see an entry for 0x600C_0060 so I am not sure how that make a difference, maybe the code in the register address is being overwritten and that's why verification failed??? I also tried defining the clock conf reg to address: 0x600FE000: (8 KB Fast Memory) This also worked fine, so I think using the address: 0x600C_0060 is causing issues and something is overwriting the data when reading/writing the chip. Offset change seems to fix problem 100% |
* docs: espsecure remote signing using a HSM broken link fix * fix(rfc2217_server): Use new reset sequences * fix(ESP32-S3): Lower CPU freq to improve flasher stub stability Closes espressif#832 * fix: Unknown chip (ID or magic number) error * pyinstaller: fix glibc dependency on gnu/linux pyinstaller package for linux is built within the ubuntu-latest image in github workflow. This may cause prbolem with glibc symbol versions on older distributions, where the new symbol versions are not available. Fix this by building on the older ubuntu version. Closes espressif#843 Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com> * tests: Create custom `host_test` marker for tests without real chip connected Closes espressif#838 * fix(ESP32-S3): Temporarily disable increasing CPU freq Related to espressif#848 Related to espressif#842 * build: add esp_rfc2217_server to published scripts Closes espressif#846 * Update version to v4.5.1 * Update version to v4.6-dev * espefuse: Hide sensitive info by default during burning burn_key and burn_key_digest Adds --show-sensitive-info flag for two commands: burn_key and burn_key_digest. * flasher_stub: pass -mabi=ilp32 to the RISC-V compiler This is a no-op change for the upstream toolchain (compiled stubs are binary identical), but is required when building with Debian's riscv64-unknown-elf-gcc compiler. * flasher_stub: allow passing extra CFLAGS The flasher_stub Makefile allows for some system-local configuration, either through local.mk, or through environment variables. For example, the compiler prefix can be overridden, by defining e.g. CROSS_ESPRISCV32. However, passing additional flags to the compiler isn't possible right now. Add EXTRA_CFLAGS and EXTRA_CFLAGS_ESPRISCV32 to allow for that option. * flasher_stub: collect all targets at the top, DRY * flasher_stub: make target selection more modular Rather than a special "make esp32", create WITHOUT_* variables to selectively disable chip families. Currently, WITHOUT_ESP8266, WITHOUT_ESP32_XTENSA and WITHOUT_ESP32_RISCV32 are defined, but the code can be easily adjusted to allow for all kinds of other sets/combinations. * flasher_stub: create %.json targets, make all a proper PHONY * flasher_stub: drop --embed from wrap_stub.py Since commit 94f29a5 the flasher stub is not embedded in the Python source, but rather included as simple json files. As such, wrap_stub.py --embed was converted to basically just vary the build dir. Rather than keep this indirection and for better clarity, remove that piece of code and replace it by a simple "cp" in the Makefile. While at it, replace the target name from "embed" to "install", as this more akin to a "make install" step. * espefuse: Support burning ECDSA_KEY from pem file - fix some assert check in test_espefuse.py - add tests to cover the new functionality * espefuse(c2): Fix BLOCK_KEY0 view for summary cmd when SB + FE keys are burnt For C2 secure boot + flash enc block, we saw that in summary cmd "0's" from secure boot digest part (upper 128 bit) were translated into "?'s" when the block was read protected. For C2, we should apply this translation for lower 128 bits only. * fix(ESP32-C6): Fix get_pkg_version and get_{major,minor}_chip_version * image_info: removed check that reserved bytes in image header are zero IDF may start using parts of the reserved bytes in the extended header at any time, which will break chip auto-detect in image_info. * build: limit max cryptography version to 40 * fix: Set flash parameters even with --flash_size keep Related to espressif/esp-idf#10788 Related to espressif/esp-idf#10959 * build: add arm and arm64 as build target Closes espressif#845 * Fix typo in serial protocol docs Fixes misspelling of `triggered` in serial protocol docs. Signed-off-by: hasheddan <georgedanielmangum@gmail.com> * Support more recent reedsolo packages - https://github.com/tomerfiliba-org/reedsolomon/releases/tag/v1.6.1 - this seems to be related to licenses only. - https://github.com/tomerfiliba-org/reedsolomon/releases/tag/v1.7.0 - this is related to installation. Closes espressif#872 * build(arm): add pip extra url for github action build * ci: Fix libffi symlinks for cryptography>=40 * espefuse: Prevent burning XTS_AES and ECDSA keys into BLOCK9 (BLOCK_KEY5) eFuse module has a hardware bug. It is related to ESP32-C3, C6, S3, H2 chips: - BLOCK9 (BLOCK_KEY5) can not be used by XTS_AES keys. For H2 chips, the BLOCK9 (BLOCK_KEY5) can not be used by ECDSA keys. S2 does not have such a hardware bug. * image_info: Display disabled WP pin as disabled The image formats know about the special value 0xee used to disable WP. Display this with image_info. E.g.: ESP32-C3 extended image header ============================== WP pin: 0xee (disabled) * image_info: Print chip ID's name if known Example: Flash pins drive settings: clk_drv: 0x0, q_drv: 0x0, d_drv: 0x0, cs0_drv: 0x0, hd_drv: 0x0, wp_drv: 0x0 Chip ID: 5 (ESP32-C3) Minimal chip revision: v0.0, (legacy min_rev = 0) Maximal chip revision: v655.35 An unknown ID will be printed as: Chip ID: 42 (Unknown ID) * tests: Make the testsuite Windows compatible * espefuse: Adds external esp instance Closes espressif#873 * espefuse: Improve efuse error viewing * espefuse: Explicit setting of efuse time settings EFUSE_PWR_ON_NUM in C3 has default value = 0x2880, now = 0x3000 * docs(Boot log): Add all esp targets to cover boot troubleshooting Closes espressif#732 * fix: USB-JTAG-Serial PID detection error * esptool: Move bootdesc on the top of the ram segment * espefuse: Move some vars under init method to speedup tool after adding yaml support * espefuse: Adds yaml efuse description files for all chip - esptool: Updates eFuses wafer major&minor versions - esptool(esp32c6): Adds package versions - espefuse(esp32c6): Replace PKG_VERSION BLK_VERSION_MINOR BLK_VERSION_MAJOR - espefuse(esp32c6): Adds adc calib efuses - espefuse: Adds yaml files for Build with PyInstaller * efuse(H2): Adds RF Calibration Information * espsecure: Improve error message for incorrect PEM format Closes espressif#881 * bugfix(usb_jtag_serial): Autofeed super watchdog (SWD) to avoid resets during flashing * esptool: Read 64-bit MAC address on C6 and H2 * bugfix: Adjust wrapper scripts to not import themselves * bugfix(espsecure): Print a clear error message if incompatible OpenSSL backend is used Closes espressif#878 * fix: inconsistent usage of dirs separator * feat(esptool): add option to dump whole flash based on detected size Closes espressif#461 * Update version to v4.6 * Update version to v4.7-dev * fix(ESP32-S3): Correct RTC WDT registers to fix resets during flashing * Update version to v4.6.1 * Update version to v4.7-dev * docs: add explanation for flash_id example to avoid confusion * docs(boot-log): fix list formatting * docs: add c2, c6 and h2 as build targets * fix(compressed upload): Accept short data blocks with only Adler-32 bytes * fix(CH9102F): Suggest to install new serial drivers if writing to RAM fails * esptool & espefuse: Fix byte order in MAC (for C6 and H2) MAC: 60:55:f9:ff:fe:f7:2c:a2 (EUI64, used for IEEE802154) BASE MAC: 60:55:f9:f7:2c:a2 (used for BT) MAC_EXT: ff:fe * Update version to v4.6.2 * Update version to v4.7 * change: Add conventional precommit linter * ci(pre-commit): Update version of `conventional-precommit-linter` * feat(get_security_info): Improved the output format and added more details * fix(esp32-c2): Enable flashing in secure download mode Closes espressif#895 * ci: Add DangerJS checks to GL and GH * feat(esptool): Add PICO package for ESP32S3 and flash/psram efuses * feat(esptool): Add tests for get_chip_features * feat(esptool): Add new packages for ESP32C3 and flash efuses * fix(expand file args): Correctly print the expanded command * feat(espsecure): Allow prompting for HSM PIN in read_hsm_config If hsm_config does not contain "credentials" the user will be prompted for the HSM PIN. This avoids the need to have HSM PINs typed in config files which is not a good security practice. ADJUNCT: Updated documentation to reflect new usage Closes espressif#900 * fix(dangerGH): Update token permissions - allow Danger to add comments to PR * fix(elf2image): fix text/rodata mapping overlap issue on uni-idrom bus chips * fix: assert in esp32 exclusive workaround * docs: Add other resources page * fix(autodetection): Remove the ESP32-S2 ROM class from get_security_info autodetection * change(pre-commit): Bump version conventional-precommit-linter to 1.2.1 * feat(esptool): added target to esp32p4 * feat(espefuse): Add support for esp32p4 chip * fix: Fix redirection of STDOUT Closes espressif#904 * fix(danger-github): Fir Danger GitHub token permission * ci(danger-github): Fix github-action-bot permissions for posting Danger output * ci: Shared danger to local stage (remove possible double CI pipelines) * ci: add 'flake8-import-order' as a dependecy to flake8 * fix(bin_image): Check only ELF sections when searching for .flash.appdesc Closes espressif#917 * feat(efuse): ESP32P4 adds ecdsa_key support * feat(efuse): Update key purpose table and tests * feat(esp32-s3): Support >16MB quad flash chips Adds support for the W25Q256 and GD25Q256 flash chips. Closes espressif#883 * ci(dev_release): Upload dev releases to PyPI with GH Actions * ci: fix pipeline for building docs * feat(merge_bin): add support for uf2 format * feat(esp32c3): Support ECO6 and ECO7 magic numbers * ci(gitlab_ci): Change only/except syntax to rules * fix(flasher_stub): fix usb-serial-jtag enabled non-related intr source * fix(loader): Could not open serial port message adjusted * ci(gitlab): Fix deploying docs to production * ci(github): Fix pyinstaller builds on ubuntu * docs(basic-commands): added note for PowerShell users for merge_bin command Closes espressif#923 * feat: Add support for Python 3.12 * feat(loader): Added hints for some serial port issues when rising port error Closes espressif/esp-idf#12366 * feat: add support for get_security_info on esp32c3 ECO7 * docs(troubleshooting): Explain issues when flashing with USB-Serial/JTAG or USB-OTG Closes espressif#924 * feat(espefuse): Update the way to complete the operation * docs(boot_mode_selection): Correct secondary strapping pin boot mode levels Closes espressif#928 * feat(espefuse): Adds efuse ADC calibration data for ESP32H2 * feat(rfc2217_server): Add hard reset sequence * feat(elf2image): add ram-only-header argument The ram-only-header configuration makes only the RAM segments visible to the ROM bootloader placing them at the beginning of the file and altering the segment count from the image header with the quantity of these segments, and also writing only their checksum. This segment placement also may not result as optimal as the standard way regarding the padding gap use among the flash segments that could result in a less fragmented binary. The image built must then handle the basic hardware initialization and the flash mapping for code execution after ROM bootloader boot it. Signed-off-by: Marek Matej <marek.matej@espressif.com> Signed-off-by: Almir Okato <almir.okato@espressif.com> * feat(esp32p4): Stub flasher support * refactor(stub_flasher): Cleanup, make adding new targets easier * feat: add support for intel hex format --------- Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com> Signed-off-by: hasheddan <georgedanielmangum@gmail.com> Signed-off-by: Marek Matej <marek.matej@espressif.com> Signed-off-by: Almir Okato <almir.okato@espressif.com> Co-authored-by: harshal.patil <harshal.patil@espressif.com> Co-authored-by: radim.karnis <radim.karnis@espressif.com> Co-authored-by: Frantisek Hrbata <frantisek.hrbata@espressif.com> Co-authored-by: Peter Dragun <peter.dragun@espressif.com> Co-authored-by: KonstantinKondrashov <konstantin@espressif.com> Co-authored-by: Faidon Liambotis <paravoid@debian.org> Co-authored-by: XiNGRZ <hi@xingrz.me> Co-authored-by: Marius Vikhammer <marius.vikhammer@espressif.com> Co-authored-by: hasheddan <georgedanielmangum@gmail.com> Co-authored-by: Roland Dobai <roland@espressif.com> Co-authored-by: Trent Piepho <tpiepho@gmail.com> Co-authored-by: Dean Gardiner <me@dgardiner.net> Co-authored-by: Massimiliano Montagni <massimiliano@solutiontech.tech> Co-authored-by: Tomas Sebestik <tomas.sebestik@espressif.com> Co-authored-by: Aditya Patwardhan <aditya.patwardhan@espressif.com> Co-authored-by: Richard Retanubun <richard.retanubun@mmbnetworks.com> Co-authored-by: wuzhenghui <wuzhenghui@espressif.com> Co-authored-by: Armando <douyiwen@espressif.com> Co-authored-by: Jakub Kocka <jakub.kocka@espressif.com> Co-authored-by: 20162026 <36726858+20162026@users.noreply.github.com> Co-authored-by: Almir Okato <almir.okato@espressif.com>
* docs: espsecure remote signing using a HSM broken link fix * fix(rfc2217_server): Use new reset sequences * fix(ESP32-S3): Lower CPU freq to improve flasher stub stability Closes espressif#832 * fix: Unknown chip (ID or magic number) error * pyinstaller: fix glibc dependency on gnu/linux pyinstaller package for linux is built within the ubuntu-latest image in github workflow. This may cause prbolem with glibc symbol versions on older distributions, where the new symbol versions are not available. Fix this by building on the older ubuntu version. Closes espressif#843 Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com> * tests: Create custom `host_test` marker for tests without real chip connected Closes espressif#838 * fix(ESP32-S3): Temporarily disable increasing CPU freq Related to espressif#848 Related to espressif#842 * build: add esp_rfc2217_server to published scripts Closes espressif#846 * Update version to v4.5.1 * Update version to v4.6-dev * espefuse: Hide sensitive info by default during burning burn_key and burn_key_digest Adds --show-sensitive-info flag for two commands: burn_key and burn_key_digest. * flasher_stub: pass -mabi=ilp32 to the RISC-V compiler This is a no-op change for the upstream toolchain (compiled stubs are binary identical), but is required when building with Debian's riscv64-unknown-elf-gcc compiler. * flasher_stub: allow passing extra CFLAGS The flasher_stub Makefile allows for some system-local configuration, either through local.mk, or through environment variables. For example, the compiler prefix can be overridden, by defining e.g. CROSS_ESPRISCV32. However, passing additional flags to the compiler isn't possible right now. Add EXTRA_CFLAGS and EXTRA_CFLAGS_ESPRISCV32 to allow for that option. * flasher_stub: collect all targets at the top, DRY * flasher_stub: make target selection more modular Rather than a special "make esp32", create WITHOUT_* variables to selectively disable chip families. Currently, WITHOUT_ESP8266, WITHOUT_ESP32_XTENSA and WITHOUT_ESP32_RISCV32 are defined, but the code can be easily adjusted to allow for all kinds of other sets/combinations. * flasher_stub: create %.json targets, make all a proper PHONY * flasher_stub: drop --embed from wrap_stub.py Since commit 94f29a5 the flasher stub is not embedded in the Python source, but rather included as simple json files. As such, wrap_stub.py --embed was converted to basically just vary the build dir. Rather than keep this indirection and for better clarity, remove that piece of code and replace it by a simple "cp" in the Makefile. While at it, replace the target name from "embed" to "install", as this more akin to a "make install" step. * espefuse: Support burning ECDSA_KEY from pem file - fix some assert check in test_espefuse.py - add tests to cover the new functionality * espefuse(c2): Fix BLOCK_KEY0 view for summary cmd when SB + FE keys are burnt For C2 secure boot + flash enc block, we saw that in summary cmd "0's" from secure boot digest part (upper 128 bit) were translated into "?'s" when the block was read protected. For C2, we should apply this translation for lower 128 bits only. * fix(ESP32-C6): Fix get_pkg_version and get_{major,minor}_chip_version * image_info: removed check that reserved bytes in image header are zero IDF may start using parts of the reserved bytes in the extended header at any time, which will break chip auto-detect in image_info. * build: limit max cryptography version to 40 * fix: Set flash parameters even with --flash_size keep Related to espressif/esp-idf#10788 Related to espressif/esp-idf#10959 * build: add arm and arm64 as build target Closes espressif#845 * Fix typo in serial protocol docs Fixes misspelling of `triggered` in serial protocol docs. Signed-off-by: hasheddan <georgedanielmangum@gmail.com> * Support more recent reedsolo packages - https://github.com/tomerfiliba-org/reedsolomon/releases/tag/v1.6.1 - this seems to be related to licenses only. - https://github.com/tomerfiliba-org/reedsolomon/releases/tag/v1.7.0 - this is related to installation. Closes espressif#872 * build(arm): add pip extra url for github action build * ci: Fix libffi symlinks for cryptography>=40 * espefuse: Prevent burning XTS_AES and ECDSA keys into BLOCK9 (BLOCK_KEY5) eFuse module has a hardware bug. It is related to ESP32-C3, C6, S3, H2 chips: - BLOCK9 (BLOCK_KEY5) can not be used by XTS_AES keys. For H2 chips, the BLOCK9 (BLOCK_KEY5) can not be used by ECDSA keys. S2 does not have such a hardware bug. * image_info: Display disabled WP pin as disabled The image formats know about the special value 0xee used to disable WP. Display this with image_info. E.g.: ESP32-C3 extended image header ============================== WP pin: 0xee (disabled) * image_info: Print chip ID's name if known Example: Flash pins drive settings: clk_drv: 0x0, q_drv: 0x0, d_drv: 0x0, cs0_drv: 0x0, hd_drv: 0x0, wp_drv: 0x0 Chip ID: 5 (ESP32-C3) Minimal chip revision: v0.0, (legacy min_rev = 0) Maximal chip revision: v655.35 An unknown ID will be printed as: Chip ID: 42 (Unknown ID) * tests: Make the testsuite Windows compatible * espefuse: Adds external esp instance Closes espressif#873 * espefuse: Improve efuse error viewing * espefuse: Explicit setting of efuse time settings EFUSE_PWR_ON_NUM in C3 has default value = 0x2880, now = 0x3000 * docs(Boot log): Add all esp targets to cover boot troubleshooting Closes espressif#732 * fix: USB-JTAG-Serial PID detection error * esptool: Move bootdesc on the top of the ram segment * espefuse: Move some vars under init method to speedup tool after adding yaml support * espefuse: Adds yaml efuse description files for all chip - esptool: Updates eFuses wafer major&minor versions - esptool(esp32c6): Adds package versions - espefuse(esp32c6): Replace PKG_VERSION BLK_VERSION_MINOR BLK_VERSION_MAJOR - espefuse(esp32c6): Adds adc calib efuses - espefuse: Adds yaml files for Build with PyInstaller * efuse(H2): Adds RF Calibration Information * espsecure: Improve error message for incorrect PEM format Closes espressif#881 * bugfix(usb_jtag_serial): Autofeed super watchdog (SWD) to avoid resets during flashing * esptool: Read 64-bit MAC address on C6 and H2 * bugfix: Adjust wrapper scripts to not import themselves * bugfix(espsecure): Print a clear error message if incompatible OpenSSL backend is used Closes espressif#878 * fix: inconsistent usage of dirs separator * feat(esptool): add option to dump whole flash based on detected size Closes espressif#461 * Update version to v4.6 * Update version to v4.7-dev * fix(ESP32-S3): Correct RTC WDT registers to fix resets during flashing * Update version to v4.6.1 * Update version to v4.7-dev * docs: add explanation for flash_id example to avoid confusion * docs(boot-log): fix list formatting * docs: add c2, c6 and h2 as build targets * fix(compressed upload): Accept short data blocks with only Adler-32 bytes * fix(CH9102F): Suggest to install new serial drivers if writing to RAM fails * esptool & espefuse: Fix byte order in MAC (for C6 and H2) MAC: 60:55:f9:ff:fe:f7:2c:a2 (EUI64, used for IEEE802154) BASE MAC: 60:55:f9:f7:2c:a2 (used for BT) MAC_EXT: ff:fe * Update version to v4.6.2 * Update version to v4.7 * change: Add conventional precommit linter * ci(pre-commit): Update version of `conventional-precommit-linter` * feat(get_security_info): Improved the output format and added more details * fix(esp32-c2): Enable flashing in secure download mode Closes espressif#895 * ci: Add DangerJS checks to GL and GH * feat(esptool): Add PICO package for ESP32S3 and flash/psram efuses * feat(esptool): Add tests for get_chip_features * feat(esptool): Add new packages for ESP32C3 and flash efuses * fix(expand file args): Correctly print the expanded command * feat(espsecure): Allow prompting for HSM PIN in read_hsm_config If hsm_config does not contain "credentials" the user will be prompted for the HSM PIN. This avoids the need to have HSM PINs typed in config files which is not a good security practice. ADJUNCT: Updated documentation to reflect new usage Closes espressif#900 * fix(dangerGH): Update token permissions - allow Danger to add comments to PR * fix(elf2image): fix text/rodata mapping overlap issue on uni-idrom bus chips * fix: assert in esp32 exclusive workaround * docs: Add other resources page * fix(autodetection): Remove the ESP32-S2 ROM class from get_security_info autodetection * change(pre-commit): Bump version conventional-precommit-linter to 1.2.1 * feat(esptool): added target to esp32p4 * feat(espefuse): Add support for esp32p4 chip * fix: Fix redirection of STDOUT Closes espressif#904 * fix(danger-github): Fir Danger GitHub token permission * ci(danger-github): Fix github-action-bot permissions for posting Danger output * ci: Shared danger to local stage (remove possible double CI pipelines) * ci: add 'flake8-import-order' as a dependecy to flake8 * fix(bin_image): Check only ELF sections when searching for .flash.appdesc Closes espressif#917 * feat(efuse): ESP32P4 adds ecdsa_key support * feat(efuse): Update key purpose table and tests * feat(esp32-s3): Support >16MB quad flash chips Adds support for the W25Q256 and GD25Q256 flash chips. Closes espressif#883 * ci(dev_release): Upload dev releases to PyPI with GH Actions * ci: fix pipeline for building docs * feat(merge_bin): add support for uf2 format * feat(esp32c3): Support ECO6 and ECO7 magic numbers * ci(gitlab_ci): Change only/except syntax to rules * fix(flasher_stub): fix usb-serial-jtag enabled non-related intr source * fix(loader): Could not open serial port message adjusted * ci(gitlab): Fix deploying docs to production * ci(github): Fix pyinstaller builds on ubuntu * docs(basic-commands): added note for PowerShell users for merge_bin command Closes espressif#923 * feat: Add support for Python 3.12 * feat(loader): Added hints for some serial port issues when rising port error Closes espressif/esp-idf#12366 * feat: add support for get_security_info on esp32c3 ECO7 * docs(troubleshooting): Explain issues when flashing with USB-Serial/JTAG or USB-OTG Closes espressif#924 * feat(espefuse): Update the way to complete the operation * docs(boot_mode_selection): Correct secondary strapping pin boot mode levels Closes espressif#928 * feat(espefuse): Adds efuse ADC calibration data for ESP32H2 * feat(rfc2217_server): Add hard reset sequence * feat(elf2image): add ram-only-header argument The ram-only-header configuration makes only the RAM segments visible to the ROM bootloader placing them at the beginning of the file and altering the segment count from the image header with the quantity of these segments, and also writing only their checksum. This segment placement also may not result as optimal as the standard way regarding the padding gap use among the flash segments that could result in a less fragmented binary. The image built must then handle the basic hardware initialization and the flash mapping for code execution after ROM bootloader boot it. Signed-off-by: Marek Matej <marek.matej@espressif.com> Signed-off-by: Almir Okato <almir.okato@espressif.com> * feat(esp32p4): Stub flasher support * refactor(stub_flasher): Cleanup, make adding new targets easier * feat: add support for intel hex format * feat(xip_psram): support xip psram feature on esp32p4 Expanded IROM / DROM range to include psram space as well * Delete docs directory * Delete .gitlab-ci.yml * Delete .pre-commit-config.yaml * Delete MANIFEST.in * Update build_esptool.yml * Delete .github/workflows/test_esptool.yml --------- Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com> Signed-off-by: hasheddan <georgedanielmangum@gmail.com> Signed-off-by: Marek Matej <marek.matej@espressif.com> Signed-off-by: Almir Okato <almir.okato@espressif.com> Co-authored-by: harshal.patil <harshal.patil@espressif.com> Co-authored-by: radim.karnis <radim.karnis@espressif.com> Co-authored-by: Frantisek Hrbata <frantisek.hrbata@espressif.com> Co-authored-by: Peter Dragun <peter.dragun@espressif.com> Co-authored-by: KonstantinKondrashov <konstantin@espressif.com> Co-authored-by: Faidon Liambotis <paravoid@debian.org> Co-authored-by: XiNGRZ <hi@xingrz.me> Co-authored-by: Marius Vikhammer <marius.vikhammer@espressif.com> Co-authored-by: hasheddan <georgedanielmangum@gmail.com> Co-authored-by: Roland Dobai <roland@espressif.com> Co-authored-by: Trent Piepho <tpiepho@gmail.com> Co-authored-by: Dean Gardiner <me@dgardiner.net> Co-authored-by: Massimiliano Montagni <massimiliano@solutiontech.tech> Co-authored-by: Tomas Sebestik <tomas.sebestik@espressif.com> Co-authored-by: Aditya Patwardhan <aditya.patwardhan@espressif.com> Co-authored-by: Richard Retanubun <richard.retanubun@mmbnetworks.com> Co-authored-by: wuzhenghui <wuzhenghui@espressif.com> Co-authored-by: Armando <douyiwen@espressif.com> Co-authored-by: Jakub Kocka <jakub.kocka@espressif.com> Co-authored-by: 20162026 <36726858+20162026@users.noreply.github.com> Co-authored-by: Almir Okato <almir.okato@espressif.com>
Operating System
Windows 10 64 bit
Esptool Version
Release v4.4
Python Version
Python 3.11
Chip Description
ESP32-S3
Device Description
Lilygo-T-Dongle S3
Hardware Configuration
Nothing attached to the board, onboad LED and TFT screen are attached/pre-soldered to GPIO pins.
How is Esptool Run
Windows tool
Full Esptool Command Line that Was Run
python esptool.py -b 460800 --port COM3 --chip esp32s3 read_flash 0x0 0x1000000 T-Dongle-S3.bin
Esptool Output
No response
More Information
Flash read at various baud rates, esptool randomly crashes at various percentages during the read/write cycle. Also during writing the flash seems to have more success flashing using the No Stub option.
Other Steps to Reproduce
Tried reading and writing using these commands.
Backup:
python esptool.py -b 460800 --port COM3 --chip esp32s3 read_flash 0x0 0x1000000 T-Dongle-S3.bin
Flash:
python esptool.py -b 460800 --port COM3 write_flash --flash_freq keep 0x000000 T-Dongle-S3.bin
Using no-stub option, gives more success but takes hours to read and mostly fails trying to read the full 16MB flash.
I Have Read the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: