Hello guys,
I am periodically storing data in a W25Q128 NOR Flash memory. I have tested it without FreeRTOS and it works fine.
Now, I want to use FreeRTOS, and create a task that will be in charge of all the flash operations. While doing it, I am thinking a way to avoid the task been interrupted because an interrupt or a context switching happens while in the middle of a r/w operation.
Would you please give me any advise in how to proceed in this case ?
Thank you
Hi @migmel,
To avoid context switch during operations, you can use vTaskSuspendAll to suspend scheduler, and call xTaskResumeAll to restart it.
You can use taskDISABLE_INTERRUPTS and taskENABLE_INTERRUPTS to disable/enable interrupts.
Please note that it might impact platform’s performance if you suspend scheduler/disable interrupts for long.
Thanks!
Which problem do you want to avoid by disabling context switches ? I don’t think that there is a problem if the rather time consuming flash operations get preempted.
you probably want to wrap your flash write sequences into a critical section shield, possibly even a global disable interrupts, depending on whether concurrent strands of execution (and which) attempt to read from the flash concurrently while you program it.
Thank you for your reply,
I wasn’t actually thinking about concurrent access to the flash, but to what would happen if I am writing data to the flash and the writing is interrupted because another task is started by the scheduler? When the task resume, will it continue writing from where it stopped ? or should it start over? I am not sure about the flash the behavior in this case.
I don’t want to share flash resources with other tasks, but in case I have to, I guess I could use a mutex or similar to avoid concurrent access right?
Thank you, yes I am aware of it; and in my case I think I cannot suspend the scheduler or take similar actions
Hello thank you,
I don’t want to disable context switching. What I want to avoid is loosing data because of it
I do not know about that particular flash architecture, but most flashes I have experience with are time critical when it comes to programming, so I would share your concerns about interrupted write sequences timing out in the flash. The scheduler will ensure that your sequence of instructions will execute exactly as if uninterrupted, but the absolute time elapsed between two assembly instructions is unpredictable in an RTOS environment without interrupts disabled, so your flash may not like that, even without concurrent access issues.
I don’t think you’ll see any issues. Maybe you’ve to ensure some minimum delays, but that’'s not a problem even when getting preempted. Usually the flash tells you its status which is usually polled when programming.
Being slow with getting back to a flash is not a problem when programming. There may be an unlocking sequence that is timing-critical, and that might need to be in a critical section.
Thank you, I will keep this in mind
Thank you, I will isolate this condition for testing
W25Q128 has serial (SPI) access, and so it should be no problem if the driver gets pre-empted. As long as there is only a single user of the SPI-bus. And the SPI-bus should not get over- or under-runs.
You send a few bytes with SPI, you start an operation, and you wait for the status register. The flash handles the time-critical things for you.
One minor remark: if you are worried about getting pre-empted, you could also consider giving the flash-driver the highest priority. But I don’t think that is necessary.
1 Like