Closed efferre79 closed 3 years ago
dobairoland
commented
3 years ago Hi @efferre79. Could you please re-run the commands with the latest master branch? We have added recently an additional flush exactly at the place of your failure.
Please provide also the trace output for the first case when you run stub successfully.
efferre79
commented
3 years ago I have just tested version from git v3.1-dev, it still doesn't work.
You can find two traces here, the first one is when working running the first time, the second trace when trying to execute again where it gets stuck
dobairoland
commented
3 years ago Hi @efferre79. Thank you for providing the traces. I haven't figured out yet what the problem is.
I need to reset the hardware by disconnecting and reconnecting the USB2serial dongle. As there is no reset button, I have connected the GPIO0 pin to GND with a wire during operations with esptool.
Why haven't you connected GPIO0 to the DTR signal coming from USB2serial? Is the EN signal connected to RTS?
efferre79
commented
3 years ago The Shelly V3 exposes, on a header accessible from outside the enclosure, only +VCC, GND, GPIO0, TX and RX. I have read in the tasmota docs that the GPIO0 must be pulled low during power cycle to enter into bootloader mode, the logic level of GPIO0 later can be kept low without interfering with esptool operations. I can connect the DTR to GPIO0 but it seems it doesn't enter in boot mode, is there any specific way to use esptool in that case (I have tried with option _--before defaultreset without luck)?
I have also a Sonoff Basic R3 which has a push button connected to the GPIO0 pin, also in that case I observe the same behaviour with esptool even if the low level on GPIO0 is kept only for a few seconds.
dobairoland
commented
3 years ago Hi @efferre79. Esptool resets the chip using the serial DTR and RTS signals. More information about this can found here: https://github.com/espressif/esptool/wiki/ESP8266-Boot-Mode-Selection#automatic-bootloader
I suspect that in your case reset never happens and esptool communicates with the stub loader in the consequent run (but it expects to talk with the ROM code). Esptool sends the SYNC request and receives a SYNC response. However, it expects more SYNC responses which is the usual from the ROM code.
You can try --before no_reset or --before no_reset_no_sync when you run esptool the second time. Maybe it will help you.
efferre79
commented
3 years ago I tested your suggestion, when using the stub I need to pass --before no_reset_no_sync after the first successfull command to be able to communicate with the chip. If I use --before no_reset_no_sync at first call it doesn't work. Do you think the stub code should be changed? When talking directly to the ROM code it seems there is no need to reset the device, does the stub code need a reset of the chip after each execution of esptool?
dobairoland
commented
3 years ago Thank you for the feedback. Your results confirm my assumptions.
Usually one wants to reset the chip after the communication was done with esptool in order that the chip would do what is intended to do: Boot from ROM and execute the desired program. The flasher stub is not supposed to stay there. It is only a helper program for esptool to support more advanced features in comparison with the ROM code. I hope this answers your question.
I don't think anything is wrong with the flasher stub. Behind your issue is the fact that you cannot reset the chip properly.
Certainly, a new feature for the stub would be great which would allow to "reuse" the stub. I will thing about it. You can use the above workaround until then.
dobairoland
commented
3 years ago Hi @efferre79. Could you please try the modifications I did in my fork https://github.com/dobairoland/esptool?
python ./esptool.py -p COM37 flash_id
python ./esptool.py -p COM37 flash_idI cannot reproduce exactly your hardware setup but I think the above might work now. If it is not then please try also the following ones.
python ./esptool.py -p COM37 --after no_reset flash_id
python ./esptool.py -p COM37 flash_idpython ./esptool.py -p COM37 --after no_reset flash_id
python ./esptool.py -p COM37 --before no_reset_no_sync flash_idpython ./esptool.py -p COM37 flash_id python ./esptool.py -p COM37 flash_id
Device freshly connected. First command was successful, then it hangs on second
I cannot reproduce exactly your hardware setup but I think the above might work now. If it is not then please try also the following ones.
python ./esptool.py -p COM37 --after no_reset flash_id python ./esptool.py -p COM37 flash_id
Device freshly connected. First command was successful, then it hangs on second
python ./esptool.py -p COM37 --after no_reset flash_id python ./esptool.py -p COM37 --before no_reset_no_sync flash_id
Device freshly connected. Both commands execute successfully here
efferre79
commented
3 years ago Here is the tracing of the two first commands you suggested (without --before or --after switches). In the second run the stub sends back 8 SYNC but the response value field is different comparing to responses in first case
dobairoland
commented
3 years ago Thank you @efferre79 for your patience and cooperation with this. I see in the traces what I did wrong.
I pushed a new version to https://github.com/dobairoland/esptool. Could you please try again? I've rewritten my previous commit so probably you will need to re-clone the repo or reset to the new commit.
efferre79
commented
3 years ago I have just tested on hardware units I own (Sonoff Basic R3 and Shelly 1 V3), they both work now with your fork, thanks!
But I need a clarification. When I execute the command I see Uploading stub... and Stub running..... It seems that at each esptool execution the stub is re-uploaded to the chip, I was thinking that with your changes the same stub instance uploaded at first run was kept running on the chip supporting multiple calls from esptool
dobairoland
commented
3 years ago Great! I'm happy that it works now.
Yes, the stub is uploaded again.
I was thinking that with your changes the same stub instance uploaded at first run was kept running on the chip supporting multiple calls from esptool
That you could achieve even without my fix by using --before no_reset_no_sync.
The default option for --before is default_reset. Esptool resets the chip into ROM bootloader mode and do synchronization. This isn't happening in your case and esptool thinks that it talks to the ROM bootloader but in fact to the stub loader. I fixed the stub loader to respond as it would be the ROM bootloader.
efferre79
commented
3 years ago Thanks! Should I close this issue or are you going to close when the fix is included into master?
dobairoland
commented
3 years ago I will close this issue. Thank you!
dobairoland
commented
3 years ago I've made another improvement in https://github.com/dobairoland/esptool. Flasher stub will be now detected and esptool will print "Stub is already running. No upload is necessary.". I made this feature compatible with other MCUs as well.
efferre79
commented
3 years ago Great! I confirm it works here as you describe, that it is what I expected :-)
I have also seen the new --after=no_reset_stub option. It would be nice to know which is default behaviour of --after and --before switches (when not specified on command line), for instance directly in the help text.
whoim2
commented
9 months ago Hello! I have a slightly different problem, but it is also related to the stub. I am flashing esp32c2 via the Internet from a Linux server, connecting the esp via socat and using the socket in esptool. I enter the board into boot mode manually and reset it manually, this is normal. The problem is that the firmware is only installed the second time. The first time the stub is loaded, ESPtool throws an error. The second time, without rebooting the ESP, everything works fine. What can you think of in my case? I suspect the stub is not responding in time.
esptool.py --chip esp32s2 --port socket://127.0.0.1:1724 --before no_reset --after no_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size 4MB ..... files
esptool.py v3.3.3 Serial port socket://127.0.0.1:1724 WARNING: Pre-connection option "no_reset" was selected. Connection may fail if the chip is not in bootloader or flasher stub mode. Connecting... Device PID identification is only supported on COM and /dev/ serial ports. .... Chip is ESP32-S2FNR2 (revision v0.0) Features: WiFi, Embedded Flash 4MB, Embedded PSRAM 2MB, ADC and temperature sensor calibration in BLK2 of efuse V2 Crystal is 40MHz MAC: c0:4e:30:4b:60:3e Uploading stub... Running stub... Traceback (most recent call last): File "/usr/local/bin/esptool.py", line 5651, in <module> _main() File "/usr/local/bin/esptool.py", line 5644, in _main main() File "/usr/local/bin/esptool.py", line 4974, in main esp = esp.run_stub() File "/usr/local/bin/esptool.py", line 946, in run_stub p = self.read() File "/usr/local/bin/esptool.py", line 438, in read return next(self._slip_reader) StopIteration
whoim2
commented
9 months ago /usr/loca.bin/esptool.py: MEM_END_ROM_TIMEOUT = 0.05 set to 0.2
I am using esptool to connect to a Shelly v3 device which uses the ESP8266EX chip. I can connect to the device (firmware id, read back of the firmware but I have not tried yet to change it) but after giving a first command, which completes successfully, I need to reset the hardware by disconnecting and reconnecting the USB2serial dongle. As there is no reset button, I have connected the GPIO0 pin to GND with a wire during operations with esptool.
I have found that giving --no-stub option solves the problem so there might be a problem in the stub code loaded by esptool. As soon as I complete the first command without --no-stub option, I need to power cycle the device to restore the communication