I've stumbled onto another case where the selected log level affects the timing of the ESP-IDF drivers, similar to #1345, but this time in the opposite direction, .i.e. higher log level makes things work.
Background:
I have a custom partition table, as seen here.
At the start of my application, in the main task, I initialize the wear leveling FatFS using
Code: Select all
esp_vfs_fat_spiflash_mount
Later in the application (still in the main task) I read/write entire files using iostreams (note: same behaviour using C-style fopen/fread/fwrite/), full implementation here. (At this point Wifi is also activated (but not using nvs-storage), disabling that seems to make no difference regarding this issue.)
Now, the issue:
As long as as the log level is set to verbose things are working. As soon as I lower the log level to debug, the main task hangs when constructing the iostream (or calling fopen()), at this line, with this being printed:
I've found that if I further delay reading the file until I have started a second task, then things works as expected, but that should not be required.Tasks currently running:
CPU 0: pthread
CPU 1: ipc1
Task watchdog got triggered. The following tasks did not reset the watchdog in time:
- IDLE (CPU 0)
So, my question to you all is: What makes the vfs/fatfs/spiflash drivers so timing sensitive and affected by the log level? Is there a mutex that needs to be captured when reading/writing files?