Skip to content

fix: stuck on "Connecting..."#1007

Open
Dzuchun wants to merge 7 commits intoesp-rs:mainfrom
Dzuchun:write-sync-fix
Open

fix: stuck on "Connecting..."#1007
Dzuchun wants to merge 7 commits intoesp-rs:mainfrom
Dzuchun:write-sync-fix

Conversation

@Dzuchun
Copy link

@Dzuchun Dzuchun commented Feb 18, 2026

I've encountered an issue with the same symptoms as #989, except in my case espflash would sometimes start working again after re-plugging the cable.

I reproduced the issue on the main branch, and traced to core reason -- when sending the Sync command, slip-codec's decoder appeared to be stuck reading bytes indefinitely here. Specifically -- byte 0x0a would be read indefinitely, never terminating the loop.

So I've added a byte count bounded variant of Connection::read (Connection::read_bounded), and used it to read the response (right now, the code expects responses of at most 44 bytes, so that was selected as an upper bound).

I also removed the claim that response is read with the timeout -- I am sure I've spent more than 100ms waiting for the Sync command to complete. My guess is that reading 0x0a from the port overrides the timeout, and thus the command itself never times out. This change is questionable, let me know if I should revert it, or...?

The tool works fine for me now -- ELF gets flashed every time.

As you could probably tell, I have little knowledge of what's actually going on. So I would appreciate extra attention to make sure this change doesn't actually break anything.

@Dzuchun Dzuchun changed the title fix: stuck on "Connectting..." fix: stuck on "Connecting..." Feb 18, 2026
@Dzuchun Dzuchun force-pushed the write-sync-fix branch 2 times, most recently from 7fcaad3 to f8f860c Compare February 18, 2026 05:40
@Dzuchun
Copy link
Author

Dzuchun commented Feb 18, 2026

My initial assumption that responses are up to 44 bytes long clearly was incorrect. However, I assume that response cannot be longer than the entire flash memory, so I bounded it by 5Mi now.

@Dzuchun Dzuchun marked this pull request as draft February 18, 2026 06:20
@Dzuchun
Copy link
Author

Dzuchun commented Feb 18, 2026

Using 8MiB as a static upper bound still causes the tool to hang -- apparently, reading 8MiB one-by-one takes a while.

So I've added max response length guessing based of the CommandType:

  • If Sync, expect at most 44 bytes
  • By default, assume 8Mib

Apparently, this is enough to both pass the CI and solve the issue. Please let me know what you think.

@Dzuchun Dzuchun marked this pull request as ready for review February 18, 2026 06:55
Copy link
Member

@SergioGasquez SergioGasquez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good to me, but they introduce major breaking changes. There are two options:

  • Restoring read_response, marking it as deprecated and adding two new functions
  • Waiting for the espflash@v5 development to get this merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants