ESP32 stops working

[beatname]

I have been working with ESP32 for a long time. I have run many applications. But I have one problem. ESP32 suddenly stuckinglocking up after a while during operation. This duration is not fixed. I checked the RAM usage, there is no problem here. I am using dual core. Even though I set coredump to flash, I can't get any output. There is no output over the UART either. I don't think it's related to deadlock or livelock. I wrote software UART and also play MP3 over DAC with SPIFFS. When I run both processes separately, there is no problem. There is a problem when working together.

What I'm wondering is why does the ESP32 suddenly stop and give no output? In what situations does this happen?

[ESP_Sprite]

That's impossible to say without looking at your code... Is there any way you can attach JTAG, or at least keep serial connected to see if there's anything weird output before the thing stops?

[beatname]

I am sharing the code, but in any case, ESP32 should still output debug, right? At least I would expect an output when it enters the panic handler. I followed the UART output while working, finally it prints NULL characters. A few bytes were sent as 0xf 0xf 0xf. I'll contact JTAG and have a look from there. I also activated watchdog, but ESP32 did not restart. I am attaching the file. As I mentioned before, there is software uart in the project. Also mp3 is played via dac with spiffs.

[ESP_Sprite]

Hm, that's a bit too much code to comb through for anything wrong, I'm afraid. In general, I think it would be useful to see what specifically is going wrong... Are you for instance sure all tasks are locked up, and not that everything is still kinda working but there's just no output to anything because of some sort of deadlock? You could test for this by 1. enabling the task watchdog on both cores and 2. starting a low-prio task that does something super-simple like blinking a LED. If the LED stops blinking, you know the entire RTOS is hung up; the watchdog timer should also output on the serial port where the hangup is. If you get a different combination between led does/does not stop blinking and wdt does/does not print output, we may be able to derive some info from that.

[beatname]

I'm pretty sure nothing is working. Because I am running a Dotmatrix display and at that moment no LEDs are lit on the screen. When I checked on the oscilloscope, I saw that none of the pins were working. The project already has a large number of lowest priority tasks. Although I do watchdog refresh on all tasks, the CPU suddenly stops after a while. Audio process is running in Core 0. Software UART and other routines are running on Core1. There is also a strangeness; When I close the audio process, all other processes are running and there is no lock up. There is no lock up even when the audio process is running alone. But when both are running at the same time, after a few hours the CPU suddenly stops. In the meantime, I lowered CPU CLK and SPI CLK speed and tried it. Result has not changed.Although the coredump uart is active, the uart output consists of a few bytes of meaningless characters.

[ESP_Sprite]

Odd... Do you have any power saving options (auto light sleep / dynamic frequency scaling) turned on?

[beatname]

No, there is no power save mode or dynamic frequency scaling that I specifically activated. The project does not need sleep mode and is not used.

[beatname]

Hello again,

I tried debugging with JTAG openocd to solve the crashing problem I mentioned. I found that the CPU stays in the "esp_pm_impl_waiti()" function when it crashes. This function is as follows;

Code: Select all

void esp_pm_impl_waiti(void)
{
#if CONFIG_FREERTOS_USE_TICKLESS_IDLE
    int core_id = xPortGetCoreID();
    if (s_skipped_light_sleep[core_id]) {
        asm("waiti 0");
        /* Interrupt took the CPU out of waiti and s_rtos_lock_handle[core_id]
         * is now taken. However since we are back to idle task, we can release
         * the lock so that vApplicationSleep can attempt to enter light sleep.
         */
        esp_pm_impl_idle_hook();
        s_skipped_light_sleep[core_id] = false;
    }
#else
    asm("waiti 0");     /***** It stays right here.*****/
#endif // CONFIG_FREERTOS_USE_TICKLESS_IDLE
}

CONFIG_FREERTOS_USE_TICKLESS_IDLE is disabled. I wrote the place where it left off as a comment line on the code.
I am not using any sleep mode or power saving mode. "WAITI" works in IDLE hook as far as I can see. I have defined configUSE_IDLE_HOOK as 0 in the FreeRTOSConfig.h file. I'll leave it to the test for a few days and observe the results. Could this really be the cause of the problem? The processor stays on the "WAITI" command, cannot get out because it cannot receive an interrupt.

[Hamzah Hajeir]

Hi there, I'm having a similar problem, but found a pattern for the issue.

The Serial deactivation comes these events:
- Boot
- Burnout detector, reset
- Starting WiFi

In a case where an input button is connected to GPIO4 or GPIO5.

I'm using ESP32 Arduino 2.0.5 based on ESP-IDF 4.4.2 (https://github.com/espressif/arduino-es ... /tag/2.0.5).

Code: Select all

void connectSTA(const std::string& ssidarg, const std::string& pskarg){ // called with empty strings ("","") to enable the core connect to the registered wifi network.
	WiFi.softAPdisconnect(true); // Do we really need this?
	WiFi.setSleep(false);
	WiFi.setAutoReconnect(true);

	Serial.printf("Connecting to [%s] with psk [%s]\n", ssidarg.c_str(), pskarg.c_str()); // prints "Connecting to [] with psk []"
	WiFi.mode(WIFI_STA);
	if (ssidarg.length())
		WiFi.begin(ssidarg.c_str(), pskarg.c_str());
	else
		WiFi.begin();
}

It doesn't print anything after, and the serial port is locked, even can't upload a new sketch to the esp32 except with power recycle.

However, it's solved by changing the GPIO pin, I don't know why, but I hope this report helps or provides useful input to the issue.

Thanks

[Hamzah Hajeir]

Hi there,
I've submitted a post earlier indicating in was a strapping GPIO pin (4,5) may cause the issue, but it wasn't true.

The main cause in my setup was the supply power, i was powering it from the PC USB, it worked well with the lab's DC Power supply.