Closed igrr closed 1 year ago
You forgot the step to build bundle.js
causing the JavaScript from ESPLoader to not be loaded.
@balloob thanks for noticing this! I have updated the workflow to run npm run rollup
.
The new version still doesn't work quite as well as the one in gh-pages branch, though.
With this version, connecting to an ESP32-C3:
esptool.js v0.1-dev
Serial port WebSerial VendorID 0x10c4 ProductID 0xea60
Connecting..._connect_attempt default_reset false
Sync
Sync err Error: Timeout
.Sync
538052359
Error: Timeout
With the version in gh-pages:
esptool.js v0.1-dev
Serial port WebSerial VendorID 0x10c4 ProductID 0xea60
Connecting....
Detecting chip type... ESP32-C3
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: 7c:df:a1:b3:8e:b8
Uploading stub...
Running stub...
Stub running...
Changing baudrate to 115200
Changed
@brianignacio5 are you seeing any similar issue in the main
branch, or does it work okay for you?
Hm we just had 2 PRs that made changes to the C3. 813e33a237a6b038a839b3679735de17b402873c and eb5ba6b0e6d5922f7cda8163ea1a4dc44fd02819. One of those might have broken it.
Can you try out with a different board?
@balloob thanks for noticing this! I have updated the workflow to run
npm run rollup
.The new version still doesn't work quite as well as the one in gh-pages branch, though.
With this version, connecting to an ESP32-C3:
esptool.js v0.1-dev Serial port WebSerial VendorID 0x10c4 ProductID 0xea60 Connecting..._connect_attempt default_reset false Sync Sync err Error: Timeout .Sync 538052359 Error: Timeout
With the version in gh-pages:
esptool.js v0.1-dev Serial port WebSerial VendorID 0x10c4 ProductID 0xea60 Connecting.... Detecting chip type... ESP32-C3 Chip is ESP32-C3 (revision 3) Features: Wi-Fi Crystal is 40MHz MAC: 7c:df:a1:b3:8e:b8 Uploading stub... Running stub... Stub running... Changing baudrate to 115200 Changed
@brianignacio5 are you seeing any similar issue in the
main
branch, or does it work okay for you?
I've tried with ESP32-C3 but I couldn't also connect. I suspect is something related with the esploader.ts
's command function on line 215 trying to read the command response and no response is given
I'm getting the same with ESP32 connected over an FT2232-H USB bridge
esptool.js v0.1-dev
Serial port WebSerial VendorID 0x403 ProductID 0x6010
Connecting..._connect_attempt default_reset false
Sync
Sync err Error: Timeout
.Sync
Sync err Error: Timeout
.Sync
1431642130
Error: Timeout
The version in the gh-pages branch works fine for the same board.
Hm we just had 2 PRs that made changes to the C3. https://github.com/espressif/esptool-js/commit/813e33a237a6b038a839b3679735de17b402873c and https://github.com/espressif/esptool-js/commit/eb5ba6b0e6d5922f7cda8163ea1a4dc44fd02819. One of those might have broken it.
I think these PRs look okay, the changes will affect only the flashing stage and not the initial connection/sync stage.
Might be a regression from the typescript rewrite? I guess we need to compare the data set to/from the chip by the version in gh-pages and by the version in main
branch.
I'm trying to find the reason why the TS rewrite fails. I think it's because timeout error handling and MD5 calculation error but it is hard to understand the issue because I don't know about expected data. Can someone help to test to record the data from gh-pages to compare with main branch ?
Since the package is currently in a broken state, can we revert the TypeScript rewrite until the issue is found?
Is there a time line when will be worked on the known bugs? Currently it is completely broken :-(
The issue was calling flush_input()
in connect
function.
In gh-pages
, flush_input
is calling this.transport.readRaw
which is a typo but since it was try/catched, the error didn't show up. In typescript update this was correctly changed to this.transport.rawRead
but it then caused the timeout issue.
I then just removed calling flush_input()
and it worked. Not sure if there is a better way to do it, but this is now basically the same as in gh-pages. Here is a pull request: https://github.com/espressif/esptool-js/pull/62
Seems to work okay now with the fix from @domagojk (thanks again! 🙏 ), so I'll merge this.
There are still a few minor issues compared to the gh-pages branch, like slightly messier logs, but we can fix that in a separate PR.
Similar to https://github.com/espressif/esp-launchpad/pull/4, adds a CI job to deploy the latest version from
main
branch to Github Pages. With this PR, we don't need to maintain gh-pages branch manually.Have tested this workflow in a fork, deployment was successful: https://igrr.github.io/esptool-js/.