Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regular crash on async_tcp during updating labels #321

Open
CrashOverride2 opened this issue Dec 8, 2024 · 10 comments
Open

Regular crash on async_tcp during updating labels #321

CrashOverride2 opened this issue Dec 8, 2024 · 10 comments

Comments

@CrashOverride2
Copy link

Describe the bug
If I use ESPUI in my project, I get regular crashes on async_tcp. I tried many things, like monitor stack sizes and heap space. Change task priorities and play with ASYNC_TCP settings like queue size, priority and ack time. I even used another async_tcp and AsyncWebserver lib and change ESPUI to work with that. But it is always the same.

I narrowed it down to my Update function which updates labels with values of my variables. I updated my code so it will update only five labels at one time and the uptime will be much longer, about an hour instead of minutes or seconds, but it crashes anyway.

I think it has to do with the websocket connection, if there is a label update during a transmission or something.

How can I proper update a lot of labels without crashing the ESP32 with using ESPUI?

ESPUI specific program part: https://git.bit-cloud.de/Crash_Override/NIU_CAN_BatteryChecker/src/branch/main/src/web_ui.cpp

To Reproduce
Steps to reproduce the behavior:

  1. Clone my project https://git.bit-cloud.de/Crash_Override/NIU_CAN_BatteryChecker
  2. Flash it to an ESP32 board
  3. Go into its Wifi ap and connect it to your wifi
  4. Look at the pages, actual about an hour and it will crash

Expected behavior
Not crashing if ESPUI will be used.

0 days 00:03:59
129236
[239396][I][MycilaTaskMonitor.cpp:50] log(): [MONITOR] loopTask   (p=1) 6016 bytes
[239409][I][MycilaTaskMonitor.cpp:50] log(): [MONITOR] async_tcp  (p=1) 63160 bytes
[239416][I][MycilaTaskMonitor.cpp:50] log(): [MONITOR] CANTask    (p=10) 2132 bytes
[239424][I][MycilaTaskMonitor.cpp:50] log(): [MONITOR] ControlTas (p=10) 2060 bytes
Guru Meditation Error: Core  1 panic'ed (Unhandled debug exception). 
Debug exception reason: Stack canary watchpoint triggered (async_tcp) 
Core  1 register dump:
PC      : 0x400e36a5  PS      : 0x00060536  A0      : 0x800e3e12  A1      : 0x3ffe46e0  
A2      : 0x0000ffff  A3      : 0x3fff4390  A4      : 0x00000020  A5      : 0x0000ff00  
A6      : 0x00ff0000  A7      : 0xff000000  A8      : 0x0000ffff  A9      : 0x3ffe46c0  
A10     : 0x00000000  A11     : 0x0000ffff  A12     : 0x3ffe49ac  A13     : 0x3fff4390  
A14     : 0x3fff4390  A15     : 0x3fff7834  SAR     : 0x00000016  EXCCAUSE: 0x00000001  
EXCVADDR: 0x00000000  LBEG    : 0x4008a0b5  LEND    : 0x4008a0c5  LCOUNT  : 0xfffffffe  
@MartinMueller2003
Copy link
Collaborator

I have another large project that I maintain. I have removed the websocket functionality due to stability issues. The ESP implementation of the TCP stacks is not stable. On the other project I still get occasional WD timeouts in the TCP stack processing.

@CrashOverride2
Copy link
Author

Oh ok I thought TCP is stable because the ESP controller exist for some years :-)

Thanks, I will try your fork of the lib.

@dazz100
Copy link

dazz100 commented Dec 8, 2024

Hi
I have a project in the planning phase. I intended to use ESP with ESPUI to connect to the internet via wifi. I need a stable and reliable TCP connection.

Google tells me this problem was identified as far back as 2015.
I found this TCP/IP adapter that appears to be a patch for the unstable stack. https://docs.espressif.com/projects/esp-idf/en/v3.3.2/api-reference/network/tcpip_adapter.html Has this been tried?

If this adapter doesn't work, would it be feasible to migrate ESPUI to another MCU family? How much code is likely to need changing? My coding experience is shallow.

@MartinMueller2003
Copy link
Collaborator

It needs to be ported to the Arduino lib to be useful

@dazz100
Copy link

dazz100 commented Dec 9, 2024

Hi
Has anyone tried the TCP/IP adapter?
I found this link to code.
https://esp32developer.com/programming-in-c-c/tcp-ip/tcp-server

@CrashOverride2
Copy link
Author

CrashOverride2 commented Dec 9, 2024 via email

@dazz100
Copy link

dazz100 commented Dec 10, 2024

It appears the esp adapter has been replaced with ESP-NETIF.
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_netif.html

@zajac-grzegorz
Copy link

zajac-grzegorz commented Dec 10, 2024

I can see you are using Mathieu's AsyncTCP implementation and the priority you have set in platformio.ini for CONFIG_ASYNC_TCP_PRIORITY is 1. The author recommends the priority = 10.

@CrashOverride2
Copy link
Author

CrashOverride2 commented Dec 10, 2024 via email

@haertelalexander
Copy link

haertelalexander commented Jan 28, 2025

I used to get a lot of of those same crashes but then I figured out that UI element callbacks are called from the async-tcp task. This will quickly get you into multithreading trouble. I now queue my callback functions to be processed in the same task I access my other ESPUI elements and experienced no crashes so far. Maybe this was the issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants