User code may cause subsequent flashing to fail unless bootloader is entered manually (ESPTOOL-1022) #1070
Comments
github-actions
bot
changed the title
thegoodhen
changed the title
dobairoland
changed the title
dobairoland
changed the title
|
Hi @thegoodhen, thanks for the detailed report and steps to reproduce. As mentioned in the linked ticket and #868, we don't know what causes this, but all points to a possible fix in the flasher stub. We will try to give this a proper look soon! |
|
Hello @radimkarnis No problem! So far I have managed to use a workaround (--no-stub) so I have been happy, but I also do believe the problem to be in a flasher stub. If you need me to look into it further, let me know. It was one of two critical problems in my project, the other being the fact that the ESP32 compilation on Arduino is taking way too long on regular computers (welp, that will take a bit of effort to figure out...). But relying on no-stub might slow down the upload process in theory (? haven't checked...) so I think it would still be good to get it resolved. Let me know if you need to test anything or look into the stub implementation for potential issues! |
Operating System
Windows 10
Esptool Version
esptool.py v4.6 4.6
Python Version
3.10.11
Chip Description
ESP32S3
Device Description
Mutliple different boards (custom, official devkits...) when using USB CDC output in user program.
Hardware Configuration
Not using UART, using hardware CDC only
How is Esptool Run
Both from Arduino IDE and directly from commandline
Full Esptool Command Line that Was Run
D:\work\stavebnice\debugusb>"C:\Users\thego\AppData\Local\Arduino15\packages\esp32\tools\esptool_py\4.6/esptool.exe" --chip esp32s3 --port "COM24" --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode keep --flash_freq keep --flash_size keep 0x0 "C:\Users\thego\AppData\Local\Temp\arduino\sketches\381CE3FFAA9043143049D630B96A721B/serialBugTest6.ino.bootloader.bin" 0x8000 "C:\Users\thego\AppData\Local\Temp\arduino\sketches\381CE3FFAA9043143049D630B96A721B/serialBugTest6.ino.partitions.bin" 0xe000 "C:\Users\thego\Documents\Arduino\hardware\gallino\esp32/tools/partitions/boot_app0.bin" 0x10000 "C:\Users\thego\AppData\Local\Temp\arduino\sketches\381CE3FFAA9043143049D630B96A721B/serialBugTest6.ino.bin"
Esptool Output
More Information
If the user code spams USB, subsequent flash will fail with "No serial data received" error, despite the fact the communication clearly works and the stub gets uploaded and runs (!!). This may be related to #1067
In order to resolve this issue, I must manually enter the bootloader, i.e. hold the BOOT button, tap the reset and then release the BOOT.
This is probably related to user data being sent once the device gets reset; adding 1 second delay to the beginning of the program resolves the issue.
I ran a diff of the trace and there are barely any differences between upload success and fail (except for the part where the data gets actually uploaded), only some registers reads seem to differ in 1 byte.
When the upload succeeds:
TRACE +0.002 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=b4800060
TRACE +0.000 Write 14 bytes: c0000a040000000000b4800060c0
TRACE +0.001 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a04000000b08400000000c0
TRACE +0.000 Received full packet: 010a04000000b08400000000
When it fails:
TRACE +0.002 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=b4800060
TRACE +0.000 Write 14 bytes: c0000a040000000000b4800060c0
TRACE +0.001 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a04000000b00400000000c0
TRACE +0.000 Received full packet: 010a04000000b00400000000
(half byte difference when reading register b4800060)
I suspected that the user code somehow gets entered after reset before the stub gets the chance to run, but further debugging suggest that this is not the issue. For now this seems to be either the bug of esptool or rather of the stub.
Adding --no-stub to the esp_tool parameters fixes the issue.
Other Steps to Reproduce
I Have Read the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: