nabucasa / esp-web-flasher Goto Github PK

Adopt use of compress in this function

since it is already supported in Arduino ESP32 git branch https://github.com/espressif/arduino-esp32/tree/esp32-s3-support
and a official release for will be soon done.

Users often report issues w/ certain devices not working correctly and blame the firmware. Could we when detecting flash try and read towards the end of flash and actually verify that the flash isn't a 2mb chip reporting it's a 4mb chip? It would help immensely on the amount of support. Those cruddy chips often report "success" when writing, but error on reading past 2mb.

• adafruit#22
  • Improves the stubgen.py to automatically download and parse esptool.py for the stubs
  • Updates the stubs to the latest versions
  • Organizes the Chip differences in one place to make adding new chips easier
  • Fixed writeRegister()
  • Added some new features such as runSpiflashCommand() and compressed flashing
    • Note: we already had compress flashing, and it's similar. Let's adopt their approach to make it easier to keep in sync.
  • rename sendCommand to command() to be more inline with esptool.py
  • Fixes an issue with debugging where debug messages were not showing properly
    • Note: we have a different debug set up right now. Maybe we should sync up again?

JavaScript can detect when a tab is no longer active. In that case the event loop is throttled and so parsing responses take longer to parse, hitting timeouts. We should handle that.

https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API

Greetings developers & contributors.

Header patching was removed(598c556) as it was perceived to be useless for ESP32 boards but ESP8266 boards like LoLin NodeMCU V3 uses 26MHz crystal(Including latest ones) and so without header patching the flashing results in reset loop when using esp-web-tools.

Allowing user to set the right flashing mode is perhaps the correct way to go regarding this, But for that to happen esp-web-flasher needs to accept the parameters and execute the patching as it was in version 4.0.0 and prior. Then esp-web-tools could possibly call esp-web-flasher with the correct flashing mode(esphome/esp-web-tools#186) from user input.

Considering ESP8266 continues to be most accessible and affordable development board and its likely to remain that way for next few years due to semiconductor shortage & shipping issues; I think accepting flashing mode from user would be a valuable addition.

Maybe i missed that but there is no possibility to set Flash Mode (QIO, QOUT, DIO and DOUT)
nor the MCU clock frequency.

ESP8266: UART_DATE_REG_ADDR = 0x60000078
ESP32: UART_DATE_REG_ADDR = 0x60000080
ESP32C3: UART_DATE_REG_ADDR = 0x6000007c

Source latest dev version of esptool.py

The c3 support seems is never tested. It would be great to get it going!

Looks like other chips can be detected too https://github.com/espressif/esptool/blob/master/esptool.py#L351

ESP Web Flasher alsways change the fourth byte in the bootloader image to 0x20 (dio, 40 MHz).
It is probably fine for Arduino-ESP32 V1.0.x/esp-idf 3.3 based firmware.
But apparently Arduino-ESP32 V2.0.2/esp-idf 4.4 based firmware do not accept this change and can not be executed.
If it is already based on bootloader that has 0x20, then nothing is changed by ESP Web Flasher during flashing process and it works fine. But if it has in original bootloader for example 0x2f (dio, 80 MHz), then ESP Web Flasher changes it during flashing process to 0x20 and the frimware cannot be started, it stays in endless Watchdog reset loop.

esphome/esp-web-tools#151

Flashing an ESP32-C3 (Adafruit QT Py ESP32-C3) with the web flasher results in a bootloop:

...
17:44:04.903 -> ESP-ROM:esp32c3-api1-20210207
17:44:04.903 -> Build:Feb  7 2021
17:44:04.903 -> rst:0x3 (RTC_SW_SYS_RST),boot:0xf (SPI_FAST_FLASH_BOOT)
17:44:04.903 -> Saved PC:0x403d0f62
17:44:04.903 -> SPIWP:0xee
17:44:04.903 -> mode:DIO, clock div:1
17:44:04.941 -> load:0x3fcd6100,len:0x438
17:44:04.941 -> load:0x403ce000,len:0x90c
17:44:04.941 -> load:0x403d0000,len:0x2358
17:44:04.941 -> entry 0x403ce000
...

The offsets used by the Web Uploader are the following (and correspond to https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/releases/download/1.0.0-beta.39/wippersnapper.qtpy_esp32c3.littlefs.1.0.0-beta.39.zip):

          "0xe000": "wippersnapper.qtpy_esp32c3.littlefs.VERSION.boot_app0.bin",
          "0x0": "wippersnapper.qtpy_esp32c3.littlefs.VERSION.bootloader.bin",
          "0x10000": "wippersnapper.qtpy_esp32c3.littlefs.VERSION.bin",
          "0x8000": "wippersnapper.qtpy_esp32c3.littlefs.VERSION.partitions.bin"

The same bootloop appears when using the Wippersnapper firmware uploader tool (https://adafruit.github.io/WipperSnapper_Firmware_Uploader/) and also by manually uploading each file to the Esp-Web-Flasher and using the offsets (below).

What Works:

• Flashing with esptool.py (v3.1) and the offsets above
• Uploading the sketch using Arduino IDE
• As suggested by @TD-er in esphome/esp-web-tools#260 - Flashing with esptool.py (v3.1) -> Using esptool.py to read_flash (4mb) into a compiled binary -> re-upload the contents using web-tools at 0x0

Similar to esphome/esp-web-tools#260
cc @balloob and @makermelissa