Closed btsimonh closed 1 month ago
FYI any exception with Reason unknown is likely caused by watchdogs enabled recently in dev branch.
To stop chasing windmills I suggest you disable the watchdog feature and continue with what you want to do.
EDIT: Add this #undef USE_ESP32_WDT
to your user_config_override.h
you are of course correct. adding this to user_config_override.h, and rebuilding for my esp32cam, it's listed 430+ files so far (better than 45). We could probably do with having a configuration to turn it off. There are always going to be odd circumstances which can't be tested for and so be accounted for with calls to tickle the watchdog. At least then we could continue to use the 'current' version whilst a strange issue is mitigated in some other way without a rebuild.
it dies in a different way now.... no crash log on the serial, just hangs with no network access, and serial logs turned themselves off... but then I'm giving it hell, so I'm not surprised.
re-opening - the watchdog triggers in the reproduction above because of listing a very large folder, and so hanging the main loop - which we could solve with some yield(). But with further testing any SD access can cause a main loop hang. I will do some further investigation, and come up with another reproduction; maybe some Berry that will cause it. It seems fine on my S3 board, but not on a 'normal' esp32cam board. I will also re-test dev vs release.
Edit - a self-build release build stalls main loop - first time at first file download. 2nd time after 471 file downloads.
I think a bug in the UFSServe function. Possibly streaming direct from file to socket is not a good idea... After more testing, I'll PR, and include in the PR a fix for listing large folders with Watchdog on (the original reproduction code).
The reason why the WDT is enabled is to find code parts which blocks Tasmota (way too long). Goal is to change long blocking code in "normal" working code.
PROBLEM DESCRIPTION
I was experiencing random crashes on esp32cam writing and reading from SD card.
I found a way to reliably reproduce the crash on esp32cam and esp32s3cam boards.
Further testing on the S3 board only indicates that I did not see a crash with the release version (tasmota32s3.bin | http://ota.tasmota.com/tasmota32/release/tasmota32s3.bin | 1956k | 20240514 16:12)
but does crash reliably with the development version: (tasmota32s3.bin | http://ota.tasmota.com/tasmota32/tasmota32s3.bin | 1973k | 20240522 17:19
Crashes happen on writing files, listing folders and reading files, in unmodified firmware.
I have not done equivalent testing of internal flash.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255
:Backlog Rule1; Rule2; Rule3
:weblog
to 4 and then, when you experience your issue, provide the output of the Console log:Backtracx�x����x����������xx��������x����xx�xx����xx���x������xx�xx�x������x����xx�xx�����x���x�����x�����������xx���x����xx�xx����x�x�x�xx�xx�xx�xx�xxx�xx���x��x�xxx���x�xx��x���������x��x���xx�x���x�x�x��x���x��x��x�xx�x��xx�xx�x�x�x��x�x�xx�x�xx�x��� 00:00:00.252 CMD: Fall back to serial port, no SOF packet detected on USB port 00:00:00.253 HDW: ESP32-S3 v0.1 00:00:00.306 UFS: FlashFS mounted with 4376 kB free 00:00:00.324 CFG: Loaded from File, Count 399