Uncaught (in promise) TypeError: Cannot read property 'BOOTLOADER_FLASH_OFFSET' of null (ESPTOOL-285)

[seeya]

After selecting a .bin file to flash and clicking Program, the console display this error.

Uncaught (in promise) TypeError: Cannot read property 'BOOTLOADER_FLASH_OFFSET' of null

Any ideas how to fix this?

[adwait-esp]

@seeya is this with the latest deployed version that you observed this issue?

[seeya]

@adwait-esp yes, I cloned the latest version and tested again it's the same. It seems like the board didn't connect properly causing the variable this.chip to be null.

[adwait-esp]

@seeya , are you able to perform other operations - like erase flash or get to the console with the same attached chip?

[seeya]

@adwait-esp yes, using the flasher tool from Espressif Systems (https://www.espressif.com/en/support/download/other-tools), I'm able to flash the firmware.bin file at 0x1000.

Also with PlatformIO there's no issue.

[torntrousers]

Same issue for me. Going to the live demo code at: https://espressif.github.io/esptool-js/. Plugin an ESP32, connect, select a firmware binary, and click program and nothing happens and in the Chrome developer tools console I see:

ESPLoader.js:1288 Uncaught (in promise) TypeError: Cannot read property 'BOOTLOADER_FLASH_OFFSET' of null at ESPLoader._update_image_flash_params (ESPLoader.js:1288) at ESPLoader.write_flash (ESPLoader.js:1358) at HTMLInputElement.programButton.onclick (index.js:279)

[torntrousers]

Its a timing thing. If i put a breakpoint here and just click continue when it stops there then it doesn't get that "Cannot read property" error any more. Still doesn't flash the ESP32 though, when I click program nothing happens and no errors in the Javascript console.

[mikevanis]

Same issue here, on latest Chrome

[a2800276]

What is the state of this project in general? Is main a working branch, or should we be using another one? I don't see how it even CAN work, e.g. connecting causes an infinite loop here

There's no way to ever break out of this loop unless there's a timeout:

while (1) {
            try {
                const res = await this.transport.read({timeout: 1000});
                i += res.length;
                //console.log("Len = " + res.length);
                //var str = new TextDecoder().decode(res);
                //this.log(str);
            } catch (e) {
                if (e === "timeout") {
                    break;
                }
            }
            await this._sleep(50);
        }

unless I'm missing something entirely obvious/subtle, the loop above should read:

while (1) {
            // loop until we read something from the device successfully
            try {
                const res = await this.transport.read({timeout: 1000});
                break; // successful read
            } catch (e) {
                if (e === "timeout") {
                    // caught and (expected) error, will continue to attempt connecting.
                    continue;
                }
                // caught a real error
                throw e
            }
            await this._sleep(50);
        }

[adwait-esp]

This project is being maintained and the branch "gh_pages" which serves the https://espressif.github.io/esptool-js/ has the latest updated code. We have observed intermittent connection issues for some revisions of ESP32 chipsets and we are working to resolve the same. Can you please let us know which ESP32 chipset you are trying to connect to?

[a2800276]

It seems to me that the tool might be able to use some polishing, especially concerning handling of error cases and reporting on progress.

My main intention of writing here is to check whether it would make sense to contribute here, or if there are already people working on these (tbh rather obvious) deficits.

The boards I'm using are about as plain vanilla as it gets, e.g. in front of me is a WROOM Devkit, with a Silicon Labs CP210x Bridge:

Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz

but also on a variety of known good devices and different bridges (at least FTDI), all of which work fine even at high baud rates with the same cable and esptool.py

Out of curiosity, which chipsets/devkits are you using that work?

The connect/sync works sometimes if run at the lowest baud rate. Even when it works, it takes a long time and provides no feedback during connection / sync. And not indication when an error occured. Typically, it's necessary to press Connect twice, because the connect procedure is stuck in the loop described above.

Even in the cases where the connect works, the upload fails. Again with no error indication.

[balloob]

Above issues have been addressed. It now correctly raises if an unsupported chip is passed in (chip == null) and with #33 the latest UI issues has been fixed. Give it a try and please open new issues if you find some.