Page 1 of 1

wdt reset at startup

Posted: Sat Sep 04, 2021 11:24 am
by NIXIE_123
Hi

Please help me to seek where the problem is. It mostly happens when the logging is ON.
When I disconnect the uart the code works for months!
It happens when esp connects to wifi

Re: wdt reset at startup

Posted: Mon Sep 06, 2021 2:10 am
by username
odd are your starving the CPU. In other words you probably either need a delay somewhere, or some piece of your code is taking to long to complete. Start commenting out lines of your code one by one until the issue goes away, then you will know what line is causing the problem.

Re: wdt reset at startup

Posted: Mon Sep 06, 2021 2:27 am
by ESP_Sprite
I doubt it's a CPU starving issue... that would usually not lead to a reset in the panic printchar handler.

NIXIE_123, do you have logging from before the bit that you just posted? As in, more of the ESP32 log leading up to the yellow text?

Re: wdt reset at startup

Posted: Mon Sep 06, 2021 8:08 am
by NIXIE_123
No, I dont have more information in logging. When It happens, the esp restarts and runs in low level logging

It works when;

-I connect logging and comment out section from esp_wifi_start() to esp_wifi_stop()
-I disconnect logging. The program works fine for days and nothing wrong happens, it connects to wifi and disconnects every hour

When it breaks it needs couple of restarts with disconnected logging to repair. Some times it does not repair and i have to wait longer with disconnected 3V3

Re: wdt reset at startup

Posted: Mon Sep 06, 2021 11:42 am
by NIXIE_123
i have this:

It says MAC address was invalid. I was flashing .bin from 0 to 0x400000

Re: wdt reset at startup

Posted: Tue Sep 07, 2021 1:01 am
by ESP_Sprite
Hmm... that screendump doesn't really make much sense. The yellow lines are a decoded backtrace, the esp-idf monitor generates those when it finds things it thinks are valid memory addresses in the serial output. However, there's no serial output preceeding those lines that have any serial addresses in them. Also, the timestamp indicates the thing has been running for a long while (17 hours), while the stack trace points at startup code, something that should have run its course the first second.