search

FYSETC / SdWiFiBrowser

SD WIFI PRO firmware
GNU General Public License v2.0
12 stars 9 forks source link

Browser Page Load Interrupts Print #2

Open IBNobody opened 1 year ago

IBNobody commented 1 year ago

I am running the SD-WIFI-PRO on a Prusa MK3S+. My SD-WIFI-PRO is in AP mode and is connected to my home wifi.

I found that reloading the SD-WIFI-PRO's internal webpage would interrupt my print. (Furthermore, if I had the internal webpage opened, and i restart my browser, the browser reload would interrupt my print.)

This is being caused by the SD-WIFI-PRO not respecting the lock / usage state of the SDCard. The webpage takes precedence over any other SDCard activity and does not release the SDCard back to the printer.

This can be solved in two ways:

IBNobody commented 1 year ago

Would removing this fix it?

https://github.com/FYSETC/SdWiFiBrowser/blob/41a4a1ec33aaf67017c4bf5f3b750018209a3dee/data/index.htm#L68

IBNobody commented 1 year ago

@GerogeFu @gdkidhsq FYI, this is a fire hazard because when my Prusa MK3S+ loses connection with the SDCard, the printer head is still hot and is parked over my print.

PeterMitrano commented 4 months ago

has this been addressed? I'm considering buying one of the FYSETC Wifi SD Cards but not if this is stil an issue. @IBNobody does your proposed fix work?

IBNobody commented 4 months ago

has this been addressed? I'm considering buying one of the FYSETC Wifi SD Cards but not if this is stil an issue. @IBNobody does your proposed fix work?

I was never able to build it since the build instructions are nonexistent.

tiredboffin commented 3 months ago

It builds fine with esp32 v2.0.17 however on serial console I can see that the card reboots sporadically when browser opens index.htm. The situation significantly improves (but not completely) when updateList() is commented out in index.htm as suggested by @IBNobody. I am not sure about the root cause of these watchdog events and I cannot check if they can be reproduced with the original firmware as it does not fit to my 8G card that somehow has only 4M of internal flash and is based on esp32-pico d4 not on v3-02 -- perhaps FYSETC has changed the components recently (?) but I can only guess.

My build with esp32 v3.0.2 works much better, watchdog is now happy however the messages in the log still indicate that something is wrong with the code logic and perhaps suggest the root cause for the watchdog events:

[987711][W][sd_diskio.cpp:175] sdCommand(): no token received
[987817][W][sd_diskio.cpp:175] sdCommand(): no token received
[987922][W][sd_diskio.cpp:175] sdCommand(): no token received
[988026][E][sd_diskio.cpp:200] sdCommand(): Card Failed! cmd: 0x00
[988033][E][esp32-hal-cpu.c:144] removeApbChangeCallback(): not found func=0x400e8ec0 arg=0x3ffbdbf8
[988092][W][AsyncTCP.cpp:949] _poll(): pcb is NULL

Update: the server is still triggering watchdog event even with the latest libraries: 

ontent type: application/javascript
File /js/index.js exist
File /js/index.js Sent
E (22834) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (22834) task_wdt:  - async_tcp (CPU 0/1)
E (22834) task_wdt: Tasks currently running:
E (22834) task_wdt: CPU 0: IDLE0
E (22834) task_wdt: CPU 1: IDLE1
E (22834) task_wdt: Print CPU 0 (current core) backtrace

The only workaround I have found is to reduce the number of parallel http requests by merging all CSS files into a single main.css and by commenting out updateList() in index.htm file. This makes the original firmware more stable.

The root cause of the bug is not clear though -- it perhaps sits somewhere deep within AsyncTCP/ESPAsyncWebSrever logic.

As my card is not usable without the firmware I have crafted a quick http cli (not web) sdwifi app based on a very simple WebServer sketch. It can process only one http request at a time but more is not needed in my use scenario. I use curl as a frontend :) but it should be easy to add a basic web form to the app if one is needed.