-
-
Notifications
You must be signed in to change notification settings - Fork 512
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
Crash when loading app.js #1705
Comments
The interesting part comes before:
And it seems that it crashes in the I also tested it with my Olimex board and an NRF24... Works perfectly without problems. |
There is nothing "before" this. I repeated the Now that I've loaded my config using WIFI, the log only shows additional lines for TX and missing RX. (I think because it's dark outside):
Now I've also tried a brand-new Olimex board that I had lying around with nothing connected (no NRF24). The error is the same. Maybe I've messed up something when compiling it myself? Is there maybe a binary that I can try? I have to say that: This project is really great work 🥇. I know so many people using it and I became really addicted analyzing graphs generated from the data. |
I am just using the pre-compiled binary from github (generic_esp32.bin) and the device profile called Please see this manual |
Same happens with my Olimex ESP32 POE board (CMT connected to GPIO 3/4/32/33/34/35 with multi uF capacitor in supplies) using generic v24.1.26 pre-compiled binary. As it is a little bit tricky to reach, I cannot connect directly to it - so no access to HW console |
I struggled with the same issue. It turned out the image got corrupted during flashing. Tested self compiled image as well as the released ones. What caused it? My guess is a noise USB Connection. |
I have to revise my last answer. In the past two weeks I tinkered a lot with OpenDTU and an Olimex ESP32-POE with WROVER module and managed to reproduce the exact same issue. Aside from this, there are two versions of the Olimex ESP32-PoE, one with ESP32 WROOM chip and one with ESP32 WROVER chip. The later one uses a slightly different pin-out, GPIO16 and GPIO17 are used internally for the PSRAM. GPIO0 will enable the ethernet chip. This can be fixed in the pin_mapping.json with clk_mode = 1 in the eth section. I will see if I manage to get JTAG debugging working and then share further details. |
I ran into this issue today as well. Accessing the webpage over any device using wifi works fine, no crashes. (ie, laptop, phone) My crash logs look the same as the one in the original report.
edit: |
It took longer then expected, but I traced the reset of the device to the watchdog timer. Only when generating a large response with 100KB+ data, the reset occurs. I am not familiar with the scheduler framework for the ESP32s realtime os, but is it possible to wrap the webapi ressource handler into a scheduler tasks so it will get interrupted near the end of the watchdog? |
Based on that research I've found a potential solution.
For me, I am no longer getting any crashing when visiting the page. This still doesn't explain why there is a 100kb limit, and why it only happens when using strictly ethernet (as in both esp board AND pc are on the same eth network) That said, the limit exists in AsyncTCP. So at best my recommendation for this repo would be to implement chunking to keep files under 100kb. As a tangent, but something that didn't help me, You can turn off async_tcp's watchdog by passing in this build flag But that just means that when async_tcp crashes, there is no rebooting. I was still getting the same problem, but would have to manually reset the board. |
If there would be a limit of 100kb, why is it then working here without any problems on all modules (olimex, wt32-eth01, TTGO T-Internet-POE and T-ETH-Lite) |
There is no hardcoded 100kb limit. It was just a rough limit I noticed during testing, 100kb still worked, 150kb crashed. Could be somewhere in the middle. I did some further testing and tinkering, it crashes above 125kb (130kb is crashing). Another point i noticed, it happens independently of the esp32's clock frequency. Tested with 240MHz, 80MHz and 10MHz. With 10MHz, it already crashes during boot with a watchdog timeout in the wifi setup routines. But that does not affect us. With 80 or 240Mz the size limit remains the same. That points to me, that the watchdog is directly tied to the cpu clock and not some external RTC clock. For debugging I used a custom board profile for my olimex esp32 poe wrvoer model and set the core debug level to its highest value.
The professional way to debug the ESP32 would be by using the JTAG interface. You can even use a raspberry pi as jtag adapter. I found a guide for this here: https://blog.wokwi.com/gdb-debugging-esp32-using-raspberry-pi/ But unfortunately the Olimex ESP32 PoE boards are using one of the necessary pins to enable the ethernet chip. It would require a small modification to "fix" this. Currently I'm digging through the AsyncTCP implementation, as the original watchdog timeout results from here. But that code is not so easy to understand than the WebApi code. To me it is still a mystery why it works on some boards, but not on others. Your WT32-ETH01 and TTGO T-Internet-POE use the same network chip as the Olimex board. So it uses the same driver and network code too. |
Just wanted to tell that I also ran into this issue. |
I am able to use the WebUI on my Android/iOS Phones (connected to LAN via WiFi AP) without any issues, but always end up with a DTU crash/restart when trying to access the WebUI on my Linux PC with wired LAN connection - OpenDTU is directly connected to wired LAN. Update: Becoming even more interesting when using a Linux Laptop. When connected via WiFi, everything works fine. When (same device, even same browser tab) connected via wired LAN, OpenDTU crashes when WebUI is forced reloaded. Further analysis of captured network traffic will be done later. |
@vaterlangen: Thanks for your analysis. I can confirm this. Once I have my DTU connected to the same Gigabit Ethernet Switch as my workstation (Linux) I have these crashes when connecting to the DTU via Firefox browser. But if I connect from my mobile phone via WIFI it actually works. Tested with v24.3.22. |
Could you try this? me-no-dev/AsyncTCP#121 |
Awesome that fix appears to work for me on latest master branch! My platformio pulls in the esphome fork of AsyncTCP https://github.com/esphome/AsyncTCP |
That sounds promising! Will implement a patch which will automatically applied before compiling. Can maybe someone else verify that this change is working? (I cannot reproduce this with my ethernet boards) |
I can confirm this fix works for my Olimex ESP32-PoE Wrover Board too. Tested this with the currently pulled in esphome fork of AsyncTCP. @vaterlangen Thank you for your in depth analysis. I would never thought about looking at the packet size itself. |
Can confirm fix in v24.4.12 for my setup. Thanks, @tbnobody ! Now the request was served successfully via wired LAN in less than 200ms: |
Looks like the issue is present again with v24.4.24. I see daily reboots as my Cerbo GX keeps pinging the DTU constantly all the time. With version v24.4.12 I had a runtime of 12 days without reset until the update to v24.4.24. |
Are you using the generic or the generic_esp32 firmware? |
I'm using generic (honestly I don't understand the difference to generic_esp32). |
But you are using the precompiled version right?
Did you read the documentation? https://www.opendtu.solar/firmware/howto/migrate_generic/ |
In the latest update which updates the ESPAsyncWebServer version. This fork has the new patch applied downstream, but with a slightly different variable name Basically OpenDTU shouldn't need to patch, just need to change: |
Thats what I did in the provided generic.bin mentioned above. Just want to doublecheck that its really working again But @evanjarrett if you can confirm that this change fixes the problem I will include it in the next release. |
I'm having a hard time recreating this, I see the code changes, and my initial comment seems like the answer, but I can't recreate. For me, the code runs fine using ESPAsyncWebServer 2.9.3 and 2.9.4 with the patch_apply and the the old I've full cleaned each time before rebuilding, and even tried wiping the flash on the olimex poe. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns. |
What happened?
I have an olimex esp32 poe board. When I access the websites over ethernet, the board crashes.
Accessing the web-interface with a browser only shows the title "OpenDTU" in the browser-tab and an empty page. Further investigation with firefox debugging tools shows me that the html is downloaded but the request to
app.js
times out.To Reproduce Bug
env:olimex_esp32_poe
curl --output - http://[ETHERNET_IP]/js/app.js
What I see is some binary output (what i do not expect). The device reboots and later on the connection times out:
curl: (56) Recv failure: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
Expected Behavior
I would expect the device to show the webinterface also when accessed via Ethernet.
Install Method
Self-Compiled
What git-hash/version of OpenDTU?
21ec72f
Relevant log/trace output
Anything else?
The text was updated successfully, but these errors were encountered: