Fix Warning Handling in `_check_if_can_reset` Method (ESPTOOL-894)

[DocKenny]

Description of Change

This change modifies the _check_if_can_reset method to issue a warning instead of raising a SystemExit when the chip is in download mode using GPIO0. This ensures that the method behaves as intended by only issuing a warning without terminating the program.

Bug Fixes

This change fixes the following bug:

• #996

Hardware & Software Combinations Tested

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

• Operating System: Windows 10
• Development Board: ESP32-S2
• Baud Rate: 115200

Automated Integration Tests

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

• Results: 60 tests passed, 29 tests skipped

pytest test_esptool.py --port COM4 --chip esp32s2 --baud 115200

[github-actions[bot]]

	Messages
:book:	🎉 Good Job! All checks are passing!

👋 Hello DocKenny, 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.
- 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 :no_entry_sign: dangerJS against f9f374d8999436be8820988ba0d9765913dbf7bc

[radimkarnis]

Hello @DocKenny, thank you for your contribution! It is always appreciated. I will communicate here, not in the linked issue.

We believe the current behavior is correct. Please see this issue with an explanation: https://github.com/espressif/esptool/issues/912.

Long story short, it is up to the user to configure the --after argument correctly. If a reset is attempted, but cannot be performed, an error is appropriate. Setting --after no_reset in this case will get rid of the error and issue a 0 exit status.

[DocKenny]

Hi @radimkarnis Thank you for reviewing my pull request.

I wanted to share my perspective on the current implementation. From my testing and experience, even though the code gets successfully loaded onto the chip, the raised SystemExit gives the impression that the program has terminated unexpectedly. This can be misleading to users, especially those who may not be familiar with the underlying behavior of the method.

The error message "Failed uploading: uploading error: exit status 1" may give users the impression that the code was not successfully uploaded to the chip, even though it has been.

Thank you for considering this feedback. I am open to further discussions and suggestions on how we can enhance this feature.

[radimkarnis]

Thank you @DocKenny for the feedback!

The Failed uploading: uploading error: exit status 1 is output from Arduino, not esptool (yes, still, this is caused by the 1 exit status from esptool).

I believe this should be fixed on the Arduino side: If ESP32-S2 or ESP32-S3 (or any other future USB-OTG-enabled chip) is selected in Arduino and USB-OTG is used to download the code, Arduino should set the --after no_reset option under the hood to suppress this warning. Correctly configuring the tools should be the job of the SDK.

[me-no-dev]

I believe this should be fixed on the Arduino side: If ESP32-S2 or ESP32-S3 (or any other future USB-OTG-enabled chip) is selected in Arduino and USB-OTG is used to download the code, Arduino should set the --after no_reset option under the hood to suppress this warning.

This warning shows when the board has been put into download mode manually (pressing BOOT and EN). In Arduino we can not detect that the user has manually put the board in Download mode to change flags. IMHO the warning is fine