Does the 0x8 (TG1WDT_SYS_RESET) , boot: 0x13( SPI_FAST_FLASH_BOOT)
indicates a specific type of event that transpired and it caused the reboot?
I am facing the same issue.
Debugging TG1WDT_SYS_RESET
Re: What is "ets Jun 8 2016 00:22:57"
Attaching the crashing log
- Attachments
-
- crash.png (30.24 KiB) Viewed 31323 times
-
- Posts: 9764
- Joined: Thu Nov 26, 2015 4:08 am
Re: What is "ets Jun 8 2016 00:22:57"
Literally what it says somewhat below: the watchdog timer reset the CPU. Given where your program stops executing: are you sure your hardware has a good enough power supply?
Re: What is "ets Jun 8 2016 00:22:57"
I will continue on this thread to discuss my TG1WDT_SYS_RESET issue given that someone has joined with the same problem.
I have now moved on from using Mongoose OS and using ESP-ID as my layer.
When happens / Observation:
I will leave the system on overnight (with a console open showing logs from ESP32 Things Board) and will find a reset.
Tasks running:
1. A LED blink loop
2. xSemaphoreTake waiting with max delay (nothing will feed the semaphore overnight)
Also, event loop to reconnect WiFi
My understanding so far:
Reading through the other forum posts regarding this reset my understanding is that it is Interrupt watchdog (Timer Group 1)
"The interrupt watchdog makes sure the FreeRTOS task switching interrupt isn’t blocked for a long time"
As mentioned in:
https://esp-idf.readthedocs.io/en/lates ... /wdts.html
Hence I mentioned the tasks.
What I have done:
I have now enabled GBD stub on the panic handler.
Now let's see what happens ....
@ESP_Sprite: Given that my understanding is the reset is by Interrupt watchdog, I am curious why you suggested looking at power.
I have now moved on from using Mongoose OS and using ESP-ID as my layer.
When happens / Observation:
I will leave the system on overnight (with a console open showing logs from ESP32 Things Board) and will find a reset.
Tasks running:
1. A LED blink loop
2. xSemaphoreTake waiting with max delay (nothing will feed the semaphore overnight)
Also, event loop to reconnect WiFi
My understanding so far:
Reading through the other forum posts regarding this reset my understanding is that it is Interrupt watchdog (Timer Group 1)
"The interrupt watchdog makes sure the FreeRTOS task switching interrupt isn’t blocked for a long time"
As mentioned in:
https://esp-idf.readthedocs.io/en/lates ... /wdts.html
Hence I mentioned the tasks.
What I have done:
I have now enabled GBD stub on the panic handler.
Now let's see what happens ....
@ESP_Sprite: Given that my understanding is the reset is by Interrupt watchdog, I am curious why you suggested looking at power.
Re: Debugging TG1WDT_SYS_RESET
I've split this discussion to a new thread to make it easier to find.
What version of ESP-IDF are you each using? For WiFi stack, a bug causing interrupt WDT resets was recently fixed.
If you have any sample code you can please post, this may help narrow it down.
What version of ESP-IDF are you each using? For WiFi stack, a bug causing interrupt WDT resets was recently fixed.
If you have any sample code you can please post, this may help narrow it down.
-
- Posts: 9764
- Joined: Thu Nov 26, 2015 4:08 am
Re: Debugging TG1WDT_SYS_RESET
@mobhuyan: I'm saying it because from experience, a bad power supply can lead to lots of unexpected weirdnesses in the startup procedure (where sumesh's problem was) and is very easy to check (just use a different USB cable and a powered hub, or an external power supply or something). It stops people from chasing a red herring later.
Re: Debugging TG1WDT_SYS_RESET
@ESP_Angus
$ git describe
v3.2-dev-141-ga3c43251
Does that mean I have the Wifi fixes you are referring to?
$ git describe
v3.2-dev-141-ga3c43251
Does that mean I have the Wifi fixes you are referring to?
-
- Posts: 1
- Joined: Sun Feb 12, 2023 11:38 am
Re: Debugging TG1WDT_SYS_RESET
I had this issue, and in my case was that I was setting GPIO 8 as a Digital Input.
Who is online
Users browsing this forum: Gaston1980 and 199 guests