This is obviously a difficult one, judging by the echoes in here (hello anyone?) My best guess now is that the reason we get stuck in the loop above is because we have a deadlock caused when the other core is tied up waiting for the core that ftell is called from (in my case by esp_ipc_call_blocking...

By way of update, I still haven't solved this, but my current best guess is that the culprit may be around cache_utils.c:141 while (!s_flash_op_can_start) { // Busy loop and wait for spi_flash_op_block_func to disable cache // on the other CPU } I get to this by way of the following call stack: 0x40...

I repeatedly write a bit to an SPIFFS file and then call ftell on it. After doing this a few times (less than 100) in quick succession, ftell fairly consistently just hangs, doesn't return and uses all the CPU, causing a task WDT to report errors. Which source should I look at to start investigating...

That makes sense. I guess the thing to do is to increase the timeout while debugging memory problems and then bring it back again once everything is stable to catch any interrupt problems.

I haven't been able to reproduce this in an empty project yet and probably won't have time to do so for a while but thought I'd post anyway and see if anyone else has seen `heap_caps_dump(MALLOC_CAP_8BIT)` cause the interrupt WDT to panic? I get it every time from my complex project, both from the m...

This seems a long time ago now, but just stumbled on my old post - for anyone else who needs the same I reimplemented this in the end based on https://github.com/espressif/esp-serial-flasher.

Hi @PeterR, do make sure you post here if you ever get permission for this. Also, could you explain your comment about the clock circuit?

cheers, Nathan