Calling iot_button_create() causes RTCWDT_RTC_RESET (IDFGH-3167)

[tuupola]

While testing the button class from esp-iot-solution I noticed every time I call the iot_button_create() it causes the program to crash. Serial console shows these error messages in a loop.

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

...

Full code can be seen at tuupola/esp32-examples/tree/master/007-m5stack-iot-button. Important part of the code below.

#define BUTTON_A_PIN          39
#define BUTTON_ACTIVE_LEVEL   1

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "iot_button.h"
#include "esp_log.h"

static const char* TAG = "main";

static void dummy_task(void* arg)
{
    while (1) {
        ESP_LOGI(TAG, "My name is Mud.");
        vTaskDelay(1000 / portTICK_RATE_MS);
    }
    vTaskDelete(NULL);
}

void app_main()
{
    // If I comment out line below code does not crash
    button_handle_t btn_handle = iot_button_create(BUTTON_A_PIN, BUTTON_ACTIVE_LEVEL);
    xTaskCreatePinnedToCore(dummy_task, "Dummy", 2048, NULL, 1, NULL, 1);
}

I have tried compiling with the system esp-idf which is the latest as of today:

~/esp/esp-idf $  git log -1 --oneline
6c44fc70 Merge branch 'feature/gpio_add_hold_support' into 'master'

PROJECT_NAME := m5stack-iot-button
include $(IDF_PATH)/make/project.mk

I have also tried compiling with the esp-idf which comes as a submodule in esp-iot-solution:

~/esp/esp-iot-solution/submodule/esp-idf $git log -1 --oneline
391c3ff9 Merge branch 'feature/btdm_add_compile_version' into 'master'

PROJECT_NAME :=m5stack-iot-button
#If IOT_SOLUTION_PATH is not defined, use relative path as default value
IOT_SOLUTION_PATH ?= $(abspath $(shell pwd)/../../)
include $(IOT_SOLUTION_PATH)/Makefile
include $(IDF_PATH)/make/project.mk

If I comment out the call to iot_button_create() program starts to work and I get the log output in the serial console.

void app_main()
{
    //button_handle_t btn_handle = iot_button_create(BUTTON_A_PIN, BUTTON_ACTIVE_LEVEL);
    xTaskCreatePinnedToCore(dummy_task, "Dummy", 2048, NULL, 1, NULL, 1);
}

I (90400) main: My name is Mud.
I (91400) main: My name is Mud.
I (92400) main: My name is Mud.

As a sidenote, after flashing with the broken binary the board becomes semi bricked. While the broken binary is still running, approximately 9 our of 10 reflashing attempts fail.

$ make flash
Flashing binaries to serial port /dev/cu.SLAB_USBtoUART (app at offset 0x10000)...
esptool.py v2.3.1
Connecting........__
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0220
Compressed 19696 bytes to 11646...
Wrote 19696 bytes (11646 compressed) at 0x00001000 in 1.0 seconds (effective 153.0 kbit/s)...

A fatal error occurred: Timed out waiting for packet header
make: *** [flash] Error 2

After successfully flashing with working binary which does not contain iot_button_create() call, all subsequent flashing attempts are successful again.

I am not sure whether this is an user error, hardware error or a version mismatch. All testing is done with the grey MPU9250 M5Stack.

[negativekelvin]

If you try a different gpio like 3 does it crash?

[tuupola]

Changing to pin 3 makes it not crash and I get the log output as expected. M5Stack has the buttons wired to 37, 38 and 39. What is the difference between those and number 3 which causes the crash?

#define BUTTON_A_PIN          3

I (135427) main: My name is Mud.
I (136427) main: My name is Mud.
I (137427) main: My name is Mud.

[negativekelvin]

37-39 have no internal pullups and very weak external pullups on m5stack and this button code uses anyedge interrupts so there must be noise causing a flood of interrupts and crash.

[tuupola]

Ah yeah, makes sense. Back to drawing board. Thanks!

[drschlaumeier]

Hallo. I dont understand. Does it mean the m5stack board has to be changed? Other pullups?
Thanks

Is it same here?
Https://github.com/espressif/arduino-esp32/issues/1334
And here?
m5stack/M5Stack#52

[evanevery]

The button works fine if WiFi is not started, so I don't think its an issue with the button/pullups...

(compile/Run one of the Button DEMO sketches if you want proof)

[drschlaumeier]

Dito! Thanks.
Seems to be RTc and/or ADC1 related...

[evanevery]

I posted a minimal sketch here: espressif/arduino-esp32#1334

It just prints the status of Button A. If you comment out the WiFi startup, it works fine. If you enable the WiFi startup, the button becomes unstable...

[drschlaumeier]

@evanevery: Yes, I understand. I have same problem
I'm trying to narrow down the issue for a solution. If ADC1, we could disable ADC1, e.g. adc1_fsm_disable() or similar. Not sure why older ESP32 core works but current master not.

[tuupola]

There is something weird going on. Might be also hardware related. With totally unrelated code I started to get RTCWDT_RTC_RESET messages again. This time I cannot get rid of them anymore. Tried erasing flash. Tried flashing with different firmware (even MicroPython). The error messages do not disappear.

Problem is again with the grey MPU9250 M5Stack. I am able to run the same code with the older Black version without any problems.

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

[evanevery]

This is not going to be particularly encouraging, but...

I had two ESP8266 4-Relay boards that I got into a similar fashion and could never recover them no matter what I tried. After many hours of screwing around I just bought a couple of raw ESP8266 modules for less than $5ea and reflowed them onto the PCB. Boom! Fixed. Never did resolve that. Even the PCB manufacturer was at a loss...

...and yes, I know this is not an option with the M5Stack... Just a datapoint for perspective....

[tuupola]

Erasing flash few times and doing $ make flash fixed the problem again. Not sure why it did not help before.

[evanevery]

I'm sure it was worth the effort on the M5Stack!

After beating my head against the wall for a couple of days, I suddenly realized it would have been far more efficient for me to just replace the $5 ESP8266 module on the boards I had. I already had a reflow station...

[tialm]

So I am having exactly the same problem. I am using an M5 grey unit. You can see with detail what is happening here https://forum.littlevgl.com/t/problems-with-interface-after-connecting-to-network/2130/5
When I turn on the wifi the A button is always being pressed.. If I turn it off it works fine..
M5stack support told me not to use IRQ events. I'll have to test it further.
I wonder if it is a software error or Hardware. And if it is hardware, can it be resolved with another board configuration?
Anyone got any other fix for this issue?

[negativekelvin]

@tialm #4585

[harshalbhav]

I am also facing same issue. Not able to drill down why this logs comes. As my device is running more then 1 month continuously. It's very high priority issue as running products gets pushing this logs continuously.

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fffeba4,len:4
load:0x4009f000,len:3248
entry 0x4009f574
ÀOHAIÀets Jun 8 2016 00:22:57

Thanks