Fix ESP32 crash from unconditional esp_task_wdt_reset() call - #31
Open
austinc3030 wants to merge 1 commit into
Open
Fix ESP32 crash from unconditional esp_task_wdt_reset() call#31austinc3030 wants to merge 1 commit into
austinc3030 wants to merge 1 commit into
Conversation
The ESP32 branch of init_pins() calls esp_task_wdt_reset() unconditionally, assuming the Arduino main loop task is auto-registered with the task watchdog. That's true on older ESP32 Arduino cores but not on modern IDF5-based cores (tested against esp32:esp32 3.3.11) -- every call fails with 'task_wdt: esp_task_wdt_reset(707): task not found'. Since init_pins() runs deep inside scan()'s nested pin-permutation loop (up to thousands of times per scan), the failed calls flood the serial log and burn enough time that the real hardware watchdog fires, crash-looping the board instead of ever completing a scan. Confirmed as a firmware bug, not a wiring/target issue -- reproduces identically with no target connected. Removed the call entirely rather than chase the newer core's esp_task_wdt_add() registration API, since this is a bench tool driven interactively and doesn't need automatic watchdog-based crash recovery.
There was a problem hiding this comment.
🟢 Approval recommended
The change is small, directly addresses the reported failure mode, and the only remaining feedback is a minor unused-include cleanup suggestion.
Pull request overview
This PR fixes an ESP32 crash/log-flood issue by removing an unconditional esp_task_wdt_reset() call in init_pins() that fails on newer IDF5-based Arduino-ESP32 cores, especially when invoked repeatedly inside scan loops.
Changes:
- Removed the ESP32-only
esp_task_wdt_reset()call frominit_pins(). - Kept watchdog feeding behavior for ESP8266 (
ESP.wdtFeed()).
File summaries
| File | Description |
|---|---|
| JTAGenum.ino | Removes failing ESP32 watchdog reset call from init_pins() to prevent log flooding and resulting watchdog resets during scans. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+257
to
259
| #if defined(ESP8266) || defined(ESP_H) | ||
| ESP.wdtFeed(); //feed watchdog | ||
| #endif |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
init_pins()'s ESP32 branch callsesp_task_wdt_reset()unconditionally, assuming the main loop task is auto-registered with the watchdog -- true on older cores, not on modern IDF5-based ones (tested againstesp32:esp323.3.11).task_wdt: esp_task_wdt_reset(707): task not found); since it's called deep insidescan()'s pin-permutation loop, thousands of failures per scan flood the log and eventually let the real hardware watchdog fire, crash-looping the board mid-scan.Fix
Removed the call. Confirmed the crash reproduces with no target board connected at all, isolating it as a firmware bug rather than a wiring issue.
Test plan
Ran extensive JTAGenum scans (pattern, IDCODE, bypass) against several real headers on a generic ESP32 DevKitC board with
esp32:esp32core 3.3.11 -- no crashes since the fix, scans complete normally every time.