grblHAL
ESP32 driver fails when enabling either WebUI, Telnet or Websocket in platformio.ini
Hi! As described in issue #637, I’m experience exactly the same problem but tracked it to the enabling of any of WebUI, Telnet or Websocket. I’m compiling the fw with PlatformIO under Ubuntu 24. Fresh installation following step by step the installation process described for grblHAL. Target board is MKS TinyBee Bee that works fine with files from Web Builder. File partitions_8mb.csv is the same used by Web Builder and sdkconfig.mkstb is just sdkconfig modified to take account of the 8 MB of flash, the partitions_8mb.csv table and 240 MHz. Please help me to find out what brokers the working of the driver making it cycle. my platformio.mkstb.ini is as follows: [platformio] src_dir = main include_dir = main
[wifi_networking] build_flags =
[env:mkstb] platform = espressif32 @ ~4.0.0 framework = espidf board = esp32dev board_build.partitions = partitions_8mb.csv board_build.filesystem = littlefs board_build.embed_files = main/embedded/favicon.ico main/embedded/ap_login.html main/embedded/index.html.gz build_flags = -Wimplicit-fallthrough=1 -Wno-missing-field-initializers -Wno-maybe-uninitialized -Wno-stringop-truncation ${wifi_networking.build_flags} -D SDKCONFIG_DEFAULTS="sdkconfig.mkstb" -D WEB_BUILD -D BOARD_MKS_TINYBEE_V1 -D OVERRIDE_MY_MACHINE=1 -D TMC_STEALTHCHOP=0 -D LWIP_HTTPD_CUSTOM_FILES=0 -D LWIP_HTTPD_DYNAMIC_HEADERS=1 -D LWIP_HTTPD_SUPPORT_V09=0 -D LWIP_HTTPD_SUPPORT_11_KEEPALIVE=1 -D LWIP_HTTPD_SUPPORT_POST=1 -D LWIP_HTTPD_DYNAMIC_FILE_READ=1 -D PROBE_ENABLE=1 -D SDCARD_ENABLE=1 -D WIFI_ENABLE=1 -D WIFI_SOFTAP=1 -D CONFIG_LITTLEFS_MOUNT_ROOT # -D WEBUI_ENABLE=1 # -D TELNET_ENABLE=1 # -D WEBSOCKET_ENABLE=1 -D HTTP_ENABLE=1 -D MDNS_ENABLE=1 -D SSDP_ENABLE=1 -D SPINDLE0_ENABLE=7 -D N_SPINDLE=1
Here is what is seen in the terminal terjeio, Backtrace:0x4008AF4D:0x3FFB1870 0x40086735:0x3FFB1890 0x4000BFED:0x3FFC92E0 0x40090612:0x3FFC92F0 0x4008DD72:0x3FFC9310 0x40126FFF:0x3FFC9350 0x401160B8:0x3FFC9380 0x4011616F:0x3FFC93A0 0x400903A5:0x3FFC93D0
E (1706096) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (1706096) task_wdt: - IDLE (CPU 1) E (1706096) task_wdt: Tasks currently running: E (1706096) task_wdt: CPU 0: IDLE E (1706096) task_wdt: CPU 1: tiT E (1706096) task_wdt: Print CPU 0 (current core) backtrace
Backtrace:0x401810BF:0x3FFB1270 0x40086735:0x3FFB1290 0x4018468B:0x3FFC0AE0 0x40180E3F:0x3FFC0B00 0x4008E549:0x3FFC0B20 0x400903A5:0x3FFC0B40
E (1706096) task_wdt: Print CPU 1 backtrace
Backtrace:0x4008AF4D:0x3FFB1870 0x40086735:0x3FFB1890 0x40116090:0x3FFC9380 0x4011616F:0x3FFC93A0 0x400903A5:0x3FFC93D0
E (1711096) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (1711096) task_wdt: - IDLE (CPU 1) E (1711096) task_wdt: Tasks currently running: E (1711096) task_wdt: CPU 0: IDLE E (1711096) task_wdt: CPU 1: tiT E (1711096) task_wdt: Print CPU 0 (current core) backtrace
Backtrace:0x401810BF:0x3FFB1270 0x40086735:0x3FFB1290 0x4018468B:0x3FFC0AE0 0x40180E3F:0x3FFC0B00 0x4008E549:0x3FFC0B20 0x400903A5:0x3FFC0B40
E (1711096) task_wdt: Print CPU 1 backtrace
Keeps coming endessly. It occurs when fw is compiled with either WebUI, Telnet or Websock enabled. Only WiFiClientSecure enabled doesn’t produce the problem.
You will have to decode the backtrace to see where it fails, but for a watchdog failure that might be in framework code so likely not very helpful.
Earlier I had to add code to run the idle task periodically, this is hooked into the main grbl protocol loop that normally runs at a high frequency. Every 250 ms it forces the idle task to run, can you try to reduce this to e.g. 100ms and see if that helps?
Thanks terjeio. Tryied values 200, 150, 100, 75 and 25 to no avail. The same problem keeps coming. Should you have any ideas please let me know.
Let’s add that in order to be absolutely sure that the Tiny Bee was not a problem, I downloaded today firmware from the Web Builder that uploaded to the TB runs as expected with all the services operating. So the problem is definitively caused by firmware compiled by me.