"Flashing of firmware is completed" message appears even in case of failure

[vanniaz]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always on a board with CP2014 USB/serial bridge, often on other boards with CP2102 and CH340

Expected behavior

Show the flashing progress in the terminal window, then show the message "flashing complete" after having correctly flashed the firmware

Actual behavior (suspected bug)

After the image compression, the "flashing complete" message appears immediately, but no firmware has been actually written

Error logs or terminal output

esptool.js
Serial port WebSerial VendorID 0x10c4 ProductID 0xea60
Connecting....
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: Wi-Fi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ac:67:b2:77:be:2c
Uploading stub...
Running stub...
Stub running...
Changing baudrate to 921600
Changed
Compressed 1620704 bytes to 922388...

Steps to reproduce the behavior

1. Connect the target device, then click "Connect" in the webpage of ESP Launchpad
2. After a few seconds, the connection is established and the Flash button is enabled
3. Select one of the pre-built examples, such as RainMaker_fan
4. Click Flash
5. Everything works normally until the image compression is completed, then the "flashing complete" message is displayed but nothing has been written (if Reset is clicked, the ESP32 reboots with the previous firmware)

Project release version

Current version on https://espressif.github.io/esp-launchpad/

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

Windows

Operating system version

Windows 10

Shell

CMD

Additional context

I tried with both Chrome and Edge, same behaviour.

EDIT: I tried different baudrates, and when I went down to 115200 it started working. However, with esptool.py the same firmware on the same board is flashed at 460800 or 921600 without any problem (already used hundreds of times)

After further testing, I found that this problem seems to affect ALL boards, although the one with CP2104 exhibits it regularly.
Moreover, I repeated the test using Chrome on a Mac Mini and I saw the same behaviour. Therefore I removed the reference to CP2104 (sorry for the repeated edits).

So there are actually 2 issues:

1. The communication at baud rates higher than 115200 seems unreliable
2. The error is not handled in ESP-Launchpad, and the message "flashing complete" is displayed even when no firmware is flashed.

Anyone else experiencing these problems?

[RushikeshPatange]

Hi @vanniaz,

From the context provided in this issue, it seems that esp-launchpad needs to handle errors propagated from esptool-js more effectively.

To give you some background, esp-launchpad relies on esptool-js for all flashing and monitoring activities. If possible, could you verify this behavior on the web interface powered by esptool-js ?

Additionally, there is a related issue (#15). While it is different, improving error handling might also help resolve that issue.

[vanniaz]

Hi @RushikeshPatange ,

I tried with the web interface of esptool-js, if I choose a baudrate higher than 115200 I get a timeout error after the compression phase:

esptool.js
Serial port WebSerial VendorID 0x10c4 ProductID 0xea60
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD (revision 1)
Features: Wi-Fi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 4c:11:ae:71:36:44
Uploading stub...
Running stub...
Stub running...
Changing baudrate to 230400
Changed
Compressed 407520 bytes to 246922...
Error: No serial data received.

While at 115200 it works normally.

Note that this same board, on the same PC, can be programmed with esptool.py at 921600, so I would exclude a hardware problem.
Moreover, I tried flashing also on a Mac Mini and found the same problem, so I am wondering while this issue is not being reported by others. Did you ever see it?

Let me know if there is some further test that I can do.

EDIT:

I did a test: I "insisted" in clicking the flash button, and after a few failed attempts it started (at 921600) and the flashing procedure completed successfully, so it seems a problem related to the start of flashing phase, once it has started everything runs smoothly:

Serial port WebSerial VendorID 0x10c4 ProductID 0xea60
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD (revision 1)
Features: Wi-Fi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 4c:11:ae:71:36:44
Uploading stub...
Running stub...
Stub running...
Changing baudrate to 921600
Changed
Compressed 407520 bytes to 246922...
Error: No serial data received.
Compressed 407520 bytes to 246922...
Error: No serial data received.
Compressed 407520 bytes to 246922...
Error: No serial data received.
Compressed 407520 bytes to 246922...
Writing at 0x10000... (6%)
Writing at 0x15497... (12%)
Writing at 0x1abb6... (18%)
Writing at 0x1fbfe... (25%)
Writing at 0x25dee... (31%)
Writing at 0x316fd... (37%)
Writing at 0x3c20c... (43%)
Writing at 0x41a18... (50%)
Writing at 0x470f6... (56%)
Writing at 0x4c3f0... (62%)
Writing at 0x517fc... (68%)
Writing at 0x56df2... (75%)
Writing at 0x5d5ea... (81%)
Writing at 0x65e45... (87%)
Writing at 0x6d7b2... (93%)
Writing at 0x73166... (100%)
Wrote 407520 bytes (246922 compressed) at 0x10000 in 3.783 seconds.
Hash of data verified.
Leaving...
Hard resetting via RTS pin...

Thanks

[RushikeshPatange]

Hi @vanniaz,
If the issue is resolved, could you please close it with a relevant comment ?
Otherwise, if it still persists, consider adding it to the esptool-js issues section, as it is more closely related to that repository. This will help track and resolve it more efficiently.

[vanniaz]

Hi @RushikeshPatange, I will open another issue in esptool-js issues section, but in esp-launchpad there is the additional problem that the error is not detected and the "flashing completed successfully" message appears immediately. So I think that this issue should remain open as well

[RushikeshPatange]

Hi @RushikeshPatange, I will open another issue in esptool-js issues section, but in esp-launchpad there is the additional problem that the error is not detected and the "flashing completed successfully" message appears immediately. So I think that this issue should remain open as well

Could you please then change issue title that aligns in that way ?
I will be picking up the error handling enhancement so in that I will mention this issue

[vanniaz]

OK, I edited the issue title.