Delay TFUc for 2*reset for more reliability

[asasine]

TFUc has been shown to take up to 2s from when it's sent on the bus to when the device is first seen in an app mode. The previous timeout of 1.6s was not always sufficient for this, so I went ahead and doubled the delay to a safe 3.2s. The timeout remains +500ms.

[Copilot]

🟡 Changes recommended

The test currently fails, and the timeout behavior does not match the stated 3.2-second design.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

This PR increases TFUc timing allowances to improve reliability when devices take longer to enter app mode.

Changes:

• Doubles the post-command reset wait.
• Extends the TFUc timeout budget.

File summaries

File	Findings
src/command/mod.rs	Critical (3 votes): Existing test expectation causes cargo test to fail. Moderate (1 vote): The calculation produces a 3.7s timeout, not the stated 3.2s.
src/asynchronous/internal/command.rs	Moderate (2 votes): An unconditional 3.2s sleep prevents successful completion around 2s; mode verification should allow earlier success.

Review details

Suppressed comments (1)

src/command/mod.rs:214

• With RESET_DELAY_MS == 1600 and TFUC_VERIFICATION_SLACK_MS == 500, this expression sets the timeout to 3700 ms, not the 3.2 seconds stated in the PR description. If 3.2 seconds is the intended cap, do not add the existing slack on top of the doubled delay; otherwise update the description and test to document the actual 3.7-second timeout.

            Command::Tfuc => 2 * RESET_DELAY_MS + TFUC_VERIFICATION_SLACK_MS,

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.