Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

core1 WILL be paused#3159

mcl-uk started this conversation inGeneral
Sep 29, 2025· 3 comments· 1 reply
Discussion options

Hello

At:https://arduino-pico.readthedocs.io/en/latest/multicore.html#core-1-operation

It says: "By default, core1 (the second core) has no non-user written code running on it.
No interrupts, exceptions, or other background processing is done
(but the core is still subject to hardware stalls due to on-die memory resource conflicts).
When flash erase or write operations (i.e. LittleFS or EEPROM) are called from core0, core1 will be paused."

My question is: Is this the case even if I'm running core1's main loop() from ram?

Thanks for your help.

You must be logged in to vote

Replies: 3 comments 1 reply

Comment options

Yes, it will be paused.

You must be logged in to vote
0 replies
Comment options

Thanks for taking the time to answer so quickly.
Is this a fundamental issue or something that could be patched or addressed in a future release?

You must be logged in to vote
1 reply
@earlephilhower
Comment options

In general, there's no way for this core to know it's safe to not freeze the other core. Even as a user, if GCC puts in an intrinsic (i.e. some of the 64b ops like* or/) those will generally be in flash but not "visible" in the actual source. Same for STL or templated operations.

It gets worse with the RP2350 with PSRAM which shares that QSPI bus. Memory accesses to it also need to be frozen while doing flash ops since the bus is taken over. So your code could all be in RAM but if you get passed in apmalloc'd block to work on, boom.

It's not something that will be changed here that I can imagine, sorry. If you really need that then I think you'll need to jump to the bare SDK.

Comment options

Thanks again, good to know. Looks like the solution has to be an external eeprom chip :-(

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
General
Labels
None yet
2 participants
@mcl-uk@earlephilhower
Converted from issue

This discussion was converted from issue #3158 on September 29, 2025 13:52.

[8]ページ先頭
©2009-2025 Movatter.jp