Deadlock with LittleFs #1357
Replies: 3 comments 4 replies
-
As written here, noInterrupts() is applied only to the calling core, so I think an interrupt should occur on the Core1 side... |
Beta Was this translation helpful? Give feedback.
-
The ARM littlefs filesystem, and the Arduino wrapper library LittleFS, are NOT multicore or multhread safe. If you have 2 threads doing file IO, then you need to use a FreeRTOS mutex to ensure only one works at a time or else really bad things will happen. Only 1 task should use them. The task-suspend-disable code you hilighted (which is actually pretty old) is absolutely necessary because without it the freezing task could be swapped out with the other core frozen causing the FreeRTOS task processing to break. If you check the If you're not doing multiple thread access to LittleFS, could you make an MCVE (small, 1-screen long program) that causes the failure? That would let us take a look at it and see if there's some other race condition we haven't caught. |
Beta Was this translation helpful? Give feedback.
-
I've created a small sample code where the deadlock reproduces.
When I run it, it deadlocks after saving a few times.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi
I am using Rp2040 with platformio.
I'm trying to write a file internally using LittleFs in a FreeRTOS environment, but a recent git pull has caused a deadlock at idleOtherCore().
It used to work fine in previous versions, but now it seems that both cores hang.
Old version that worked:
SHA-1: a58154b
(05/26/2022 07:13:25)
Originally, I think the purpose of this change was to suppress access from other threads while writing to Flash, but the call to vTaskSuspendAll(); seemed to be gone.
backtrase below
Is it because both Core0 and Core1 call vTaskSuspendAll();?
Multiple tasks are running on the Core1 side, but vTaskSuspendAll(); is reached when vTaskDelay(); is called.
I think that the configuration expects recovery by interrupt processing, but when lfs_flash_prog() and lfs_flash_erase() are called on the Core0 side, noInterrupts(); is executed internally and then rp2040.idleOtherCore(); interrupt processing is also suppressed because of Is there anything wrong with my usage?
By the way, for idleOtherCore()
It has been confirmed that the phenomenon does not occur if the is commented out.
Beta Was this translation helpful? Give feedback.
All reactions