I found a solution, this will do the trick: void RTC_IRAM_ATTR esp_wake_deep_sleep(void) { // Output - set RTC mux SET_PERI_REG_MASK(RTC_IO_XTAL_32K_PAD_REG, BIT(RTC_IO_X32N_MUX_SEL_S)); // Output - clear the HOLD bit CLEAR_PERI_REG_MASK(RTC_IO_XTAL_32K_PAD_REG, BIT(RTC_IO_X32N_HOLD_S)); // Output -...

On a ESP32-D0WD module I am trying to set RTC_GPIO8 (GPIO33) in the esp_wake_deep_sleep() function using the esp-idf framework. This obviously means some REG_WRITE() and REG_READ() register "joggling". So far I have come up with this (which apparently is not enough): // Enable GPIO output REG_WRITE(...

Resolved!! Okay, I found this note in the timer.h header file: /** @brief Take timer spinlock to enter critical protect * * @note Deprecated, the recommended way is to use ISR callbacks instead, see timer_group_example_main * * @param group_num Timer group number, 0 for TIMERG0 or 1 for TIMERG1 * *...

After an update to the ESP-IDF framework release (currently on 4.4.1) I get these two build warnings coming from the timer interrupt routine: timer_spinlock_take' is deprecated timer_spinlock_give' is deprecated I am unsure on what to use instead (what is appreciated) - because not using these spinl...

@WiFive - You are right, that could be it - make sense at least.

Thanks for chipping in.

@ESP_Sprite, thanks for the reply.

It just seemed wired to me - because later on in the code the RX buffer is allocated as: not taking into account that the driver was installed with an RX buffer of size 2048?

In the "uart_async_rxtxtasks_main.c" UART example I came across these two lines of code: uart_driver_install(UART_NUM_1, RX_BUF_SIZE * 2, 0, 0, NULL, 0); xTaskCreate(rx_task, "uart_rx_task", 1024*2, NULL, configMAX_PRIORITIES, NULL); Why use the *2 in these cases, is to "inform" about eg. a 16 bit d...

After debugging this for days now I turned to my ISP, believe it or not he found some issues with my wireless router . Now everything work as expected with no random disconnect on the ESP32.
That just goes to shows you, it's not always a SW issue - HW has issues too.

I have been searching for the same answer, spending a lot of time on a wifi issue it would be nice to know what this warning is about. It shows up randomly and seems not to disturb the wifi connection - maybe this is a wrongly classified debug log entry?

Any comments from the Guru's?

Thanks!

@WiFive - at least nothing that gives any log output. The webserver was supposed to be running but that is dead silent. But something seems to be happening as the 'SysSurveillance' task seems to be running. I have always wondered about what this wifi warning meant: W (1457) wifi:<ba-add>idx:0 (ifx:0...