fix(esp32c5): fix boot failure after USB-Serial-JTAG download (ESPTOOL-1230)

[leeebo]

This commit resolves an issue where ESP32-C5 would fail to boot properly after firmware download via USB-Serial-JTAG interface, resulting in error rst:0x7 (TG0_WDT_HPSYS),boot:0x18 (SPI_FAST_FLASH_BOOT).

This change fixes the following bug(s):

Using IDF command idf.py flash monitor download then restart esp32-c5 through USB-Serial-JTAG, sometimes, the chip reboot in loop with

"rst:0x7 (TG0_WDT_HPSYS),boot:0x18 (SPI_FAST_FLASH_BOOT)"

The commit 1059ec7 try to fix this issue, But this fix did not fully work as intended.

I test with ESP32C5 ECO2 and ECO3, The self.uses_usb_jtag_serial() always return 176 when donwload through USB-Serial-JTAG, return 36 when using UART. which means the self.uses_usb_jtag_serial() is always False and the patch not work as normal

I have tested this change with the following hardware & software combinations:

• ESP32-C5 ECO2
• ESP32-C5 ECO3
• esptool v5.1.0

I believe this fix needs to be backported to other branches that support esp32-c5.

I have run the esptool automated integration tests with this change and the above hardware:

[github-actions]

Warnings

⚠️

Some issues found for the commit messages in this PR: the commit message "Apply automatic fixes from pre-commit hooks": summary looks empty type/action looks empty Please fix these commit messages - here are some basic tips: follow Conventional Commits style correct format of commit message should be: <type/action>(<scope/component>): <summary>, for example fix(esp32): Fixed startup timeout issue allowed types are: change,ci,docs,feat,fix,refactor,remove,revert,test sufficiently descriptive message summary should be between 20 to 72 characters and start with upper case letter avoid Jira references in commit messages (unavailable/irrelevant for our customers) TIP: Install pre-commit hooks and run this check when committing (uses the Conventional Precommit Linter).

👋 Hello leeebo, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

This GitHub project is public mirror of our internal git repository

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved, we synchronize it into our internal git repository.
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the default branch.
5. On next sync from the internal git repository merged change will appear in this public GitHub repository.

Generated by 🚫 dangerJS against aa6df4b

[leeebo]

I realy not sure if the address of UARTDEV_BUF_NO is correct

[radimkarnis]

Hello @leeebo,
thanks for opening this PR. I can reproduce the issue, it really seems like the UARTDEV_BUF_NO offset is wrong. UARTDEV_BUF_NO_USB_JTAG_SERIAL has to be 3, not 176.

I only have ECO2 with functional USB-Serial/JTAG mode. Testing with that, changing the UARTDEV_BUF_NO to 0x4085f514 solves the issue. Could you please help me verify this with the ECO3? Thank you

[leeebo]

Hi @radimkarnis , changing the UARTDEV_BUF_NO to 0x4085f514 works as expected on ESP32-C5 ECO3.

Could you please help us verify the UARTDEV_BUF_NO address of ESP32-C61? Because we have reproduced the same issue on ESP32-C61.

By the way, regarding the BSS address — will it remain unchanged after a ROM ECO? If not, do we need to locate the address based on the specific ECO version of the chip?

[radimkarnis]

@leeebo

Could you please help us verify the UARTDEV_BUF_NO address of ESP32-C61

Please try and verify 0x4084f5ec for ECO2 and 0x4084f5e4 for ECO3.

By the way, regarding the BSS address — will it remain unchanged after a ROM ECO? If not, do we need to locate the address based on the specific ECO version of the chip?

No, as you can see, we cannot guarantee the address won't change with new ECO versions.

If you verify the C61, I can do a quick fix and release a dev version that would propagate into IDF.