Hi guys I’m getting a wdt error on the esp32. I basically have a boot loop.
The error message is the following:
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
mode:DIO, clock div:2
E (2224) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (2224) task_wdt: - loopTask (CPU 1)
E (2224) task_wdt: Tasks currently running:
E (2224) task_wdt: CPU 0: IDLE0
E (2224) task_wdt: CPU 1: IDLE1
E (2224) task_wdt: Aborting.
abort() was called at PC 0x400d6de3 on core 0
Backtrace: 0x4008b998:0x3ffbe170 0x4008bbc5:0x3ffbe190 0x400d6de3:0x3ffbe1b0 0x40084a25:0x3ffbe1d0 0x400f005b:0x3ffbbff0 0x400d7573:0x3ffbc010 0x40089b3e:0x3ffbc030 0x4008864d:0x3ffbc050
You can check out the full code here:
I work with a lot of interrupts. Maybe I run into wdt timeouts because none of my inputs have actually buttons on there but I have all of them pulled up with a 4k7 ohm resistor so that shouldn’t be a problem. The esp is mounted on a custom pcb, I can share the schematics if requested. But I get the Boot Loop no matter if the esp is mounted on the pcb or completely by itself.
I’m just clueless, if anyone of you can point me in the right direction I would be very thankful.
Hm I’ve downloaded the code and uploaded it to my ESP32 and after the bootup messages, there is absolutely nothing displayed, also no crash message. The ESP32 dev board has no other hardware attached though, like like buttons or displays. When I insert a
Serial.println("loop"); at the end of
loop() I do see that it is continously being printed out without every crashing.
Is that also the behavior you get when you run it on an ESP32 withot anything attached?
If yes, the the crash probably only occurs when it does “something” or reacts to something. It could be that a library function is internally failing or waiting for something without calling
delay(), thus triggering the watchdog. Try removing some input stimuli to the module and see if it still crashes.
Of course if you have a JTAG debugger you could debug the program in a more efficient way and see in which exact function a task is at the moment the watchdog triggers the reset (see e.g. this article). But you should also be able to narrow it down if you put
Serial.println() statments before and after every subtask that is done in loop.
You will be able to decode this to human readabdle form if you add the
build_type = debug
monitor_filters = esp32_exception_decoder
(see docs and docs) But that will just show the backtrace leading to
abort() and probably not the cause of the issue. But it will help you in case there is actual crash somewhere (in the future). Note that with
build_type = debug the code will be compiled to a less optimized version and will run slower, so it should be removed before doing a release build.
Thank you for your reply. I’ll do some more testing and report back to you
Alright I don‘t get the Boot Loop when the esp is by itself, but when connected to my custom pcb I do get a Boot Loop. Do you want to take a look at my schematics? Maybe I messed something up when designing it
But does it have input signals attached to it with stuff happening on those lines? A regular blinky sketch does not bootloop, right?
I fixed it, I read somewhere that you can‘t have gpio12 high on boot otherwise it will get stuck. I use gpio12 as an input and is pulled high all the time. So yeah now it works. Thank you for your help