Updated to fix a issue where CCLoader hangs with no response after a cold USB reconnect - #4
Updated to fix a issue where CCLoader hangs with no response after a cold USB reconnect#4randy197 wants to merge 3 commits into
Conversation
Added timestamp functions and improved error handling for RS232 communication.
Added a known issue regarding CCLoader hanging after USB reconnect and provided a workaround using esptool for ESP8266/NodeMCU boards.
📝 WalkthroughWalkthroughThe Arduino loader now clears stale serial input, validates chip identification, handles block checksum and verification failures, and resumes programming requests after successful blocks. The Linux loader adds reset settling, serial flushing, timed SBEGIN retries, and retry exhaustion handling. The README documents a cold-reconnect workaround. ChangesSerial programming flow
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant LinuxLoader
participant CCLoader
participant Flash
LinuxLoader->>CCLoader: Send SBEGIN
CCLoader->>CCLoader: Drain stale input and validate handshake
CCLoader->>Flash: Read chip ID and erase
LinuxLoader->>CCLoader: Send data block
CCLoader->>Flash: Write and optionally verify block
CCLoader-->>LinuxLoader: Send ERRO or request next block
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CCLoader/src/CCLoader.ino`:
- Around line 546-550: Update the Serial handshake parsing around the
available-byte check so rejecting an unexpected command consumes only the single
unexpected byte, preserving subsequent bytes such as SBEGIN and verify for the
next iteration. Ensure the receive buffer remains intact after noise and the
valid handshake can still be parsed without waiting indefinitely.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 52381901-258a-480e-bef6-06bd0517e606
📒 Files selected for processing (3)
CCLoader/src/CCLoader.inoREADME.mdSourceCode/Linux/main.c
| if(Serial.available()>=2) // was strictly ==2: a single stray byte | ||
| // ahead of the real handshake could make | ||
| // this condition never trigger, hanging | ||
| // forever. | ||
| { |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Do not discard the byte following an unexpected command.
With RX data [noise, SBEGIN, verify], Line 558 consumes SBEGIN after rejecting noise, leaving only verify; the next iteration waits forever for two bytes. Discard only the unexpected byte so the next iteration can parse the intact handshake.
Proposed fix
if(Serial.read() == SBEGIN)
{
Verify = Serial.read();
Continue = 1;
}
- else
- {
- Serial.read(); // Clear RX buffer
- }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if(Serial.available()>=2) // was strictly ==2: a single stray byte | |
| // ahead of the real handshake could make | |
| // this condition never trigger, hanging | |
| // forever. | |
| { | |
| if(Serial.available()>=2) // was strictly ==2: a single stray byte | |
| // ahead of the real handshake could make | |
| // this condition never trigger, hanging | |
| // forever. | |
| { | |
| if(Serial.read() == SBEGIN) | |
| { | |
| Verify = Serial.read(); | |
| Continue = 1; | |
| } | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@CCLoader/src/CCLoader.ino` around lines 546 - 550, Update the Serial
handshake parsing around the available-byte check so rejecting an unexpected
command consumes only the single unexpected byte, preserving subsequent bytes
such as SBEGIN and verify for the next iteration. Ensure the receive buffer
remains intact after noise and the valid handshake can still be parsed without
waiting indefinitely.
1 participant
This took me a few hours an many AI token to work out what was happening, but I finally got it flashing. I've added a note in the readme to explain what users will need to do if they have issues programming.
Not sure how this would effect windows or MacOS as I have only tested on Linux.
Basically without doing a esptool reset after a cold plug in of the 8266 it wouldn't communicate with CCLoader. I (ie. Claude) have added a few changes to the firmware to solve a couple of bugs and along with the esptool reset I was able to get this to work.
Summary by CodeRabbit
Bug Fixes
Documentation