FreeRTOS on Raspberry Pi Pico: Treat Flash-Safe Execution as a Two-Core Protocol
Disabling interrupts on the calling core does not establish that the other core has stopped reading executable flash. In a FreeRTOS Pico application, safe erase or programming depends on the actual core arrangement and the SDK helper selected by the build.
Review that coordination before investigating data corruption. This article follows Pico SDK 2.3.1 source and focuses on the FreeRTOS integration. It supplies no destructive flash command and reports no executed erase or power-loss test.
Identify the environment the helper can coordinate
The tagged flash API explains that flash access is unavailable while erase or write takes it out of XIP mode. Its safe-execute helper coordinates interrupts and the other core through an environment-specific mechanism. Mixed kernel and non-kernel core arrangements need particular care; the helper cannot simply infer that the unmanaged core is safe.
An “assume core safe” setting is therefore a statement about the application's design, not a switch that makes arbitrary code safe. Establish where that core executes and what data it can read during the operation before making such an assertion.
For a hypothetical data logger, placing the erase callback in RAM is only part of the review. Examine every code and data dependency used while XIP is unavailable, as well as independent execution on the other core. A callback's name or a successful light-load demonstration does not establish that boundary.
Inspect the FreeRTOS-specific entry handshake
The SDK implementation enables its FreeRTOS SMP mechanism for two configured cores and requires core affinity. It creates a task on the other core, raises its priority and uses a handshake before entering the protected operation. The source explicitly distinguishes this from merely entering an SMP critical section.
Task creation can fail, and entry can time out. Those failures belong in the caller's control flow. Do not run the erase or program operation through a fallback path just because coordination failed; that would remove the property the helper was supposed to establish.
Check the chosen configuration against the actual system rather than assuming the helper name guarantees support. A custom helper changes the mechanism and must be reviewed independently.
Distinguish an entry failure from an exit failure
The wrapper calls the supplied function only after successful entry, then returns the exit result. An exit timeout can therefore be reported after the callback has already run. A non-success return alone is not proof that no flash side effect occurred.
That distinction matters for retries. In a hypothetical append operation, blindly repeating the callback after an ambiguous result can write the logical record twice or advance metadata inconsistently. Preserve an application-level indication of whether the callback began and what operation it attempted, using storage that remains suitable for the execution context.
After an uncertain result, reconcile the destination through the product's supported recovery procedure before deciding whether to retry. Design the on-flash format and update protocol for interrupted operations separately; coordination around XIP access does not create transactional storage semantics.
Keep the protected callback narrowly scoped
Prepare parameters and buffers before requesting the safe zone. Avoid adding unrelated logging, allocation or inter-task waits inside the protected callback. Each dependency expands what must remain available while normal execution is constrained.
A useful development test separates three outcomes: entry rejection before the callback, successful callback and exit, and a deliberately exercised error path whose side effects can be determined afterward. Use an expendable flash region and the board's documented recovery method, not production data.
The final review should explain both cores' behavior and the meaning of every return path. Safe flash access, successful programming and durable application state are different conclusions, each requiring its own evidence.
