Multi Core: locking execution on the other core
Posted: Wed Oct 30, 2024 12:11 pm
Hi,
I'm currently using ChibiOS/RT on an RP2040 in Multi Core / SMP mode. If I understood the code correctly, when I call chSysLock() on one core to enter a critical section, the other core is blocked from also entering a critical section. But unless it also tries to get into a critical section with one of the lock functions it will continue to run normally. Correct?
Is there an easy way to ensure that the other core is also prevented from executing code at all? Could for example chSysNotifyInstance() somehow be used for this?
What I'm trying to do is to write to the flash IC connected to the RP2040. Usually code runs from the flash via XIP. But this is not possible while writing to the flash. So I have to disable XIP, write to the flash, re-enable XIP. The functions that deal with disabling XIP, writing and re-enabling XIP must all be executed from RAM.
I successfully moved them into the ".ram0_init" section and can run them from there. But this is all happening on one core while the other core still tries to use XIP and fails. So I have to ensure that the other core is stalled on some function in RAM and only proceed with my code when this is ensured.
I'm also not sure what is the best way to move the ChibiOS core functions that the locked core should busy-loop on into a specific linker object section. I guess I'd have to add something like " __attribute__((section(".ram0_init.")))" to their code. But this would be a patch to core ChibiOS code which I'd prefer to keep unmodified. Or do you see an easy way to force the other core into a function of mine that I could then easily move into RAM?
Thanks.
I'm currently using ChibiOS/RT on an RP2040 in Multi Core / SMP mode. If I understood the code correctly, when I call chSysLock() on one core to enter a critical section, the other core is blocked from also entering a critical section. But unless it also tries to get into a critical section with one of the lock functions it will continue to run normally. Correct?
Is there an easy way to ensure that the other core is also prevented from executing code at all? Could for example chSysNotifyInstance() somehow be used for this?
What I'm trying to do is to write to the flash IC connected to the RP2040. Usually code runs from the flash via XIP. But this is not possible while writing to the flash. So I have to disable XIP, write to the flash, re-enable XIP. The functions that deal with disabling XIP, writing and re-enabling XIP must all be executed from RAM.
I successfully moved them into the ".ram0_init" section and can run them from there. But this is all happening on one core while the other core still tries to use XIP and fails. So I have to ensure that the other core is stalled on some function in RAM and only proceed with my code when this is ensured.
I'm also not sure what is the best way to move the ChibiOS core functions that the locked core should busy-loop on into a specific linker object section. I guess I'd have to add something like " __attribute__((section(".ram0_init.")))" to their code. But this would be a patch to core ChibiOS code which I'd prefer to keep unmodified. Or do you see an easy way to force the other core into a function of mine that I could then easily move into RAM?
Thanks.