SDK • [RP2350] atomics causing other core pause?

So, I'm trying to do some high fairly frequency (60kHz) realtime work on core 1, and noticed strange behavior. Even with nothing else running on Core 1 but my 2 interrupts and idle loop, observing the IRQ handlers via toggling GPIOs at the beginning and end shows that intermittently, instead of on the order of single digit microseconds, execution time is not constant, and causes timing misses.

Here is starting my PWM counters, with GPIO12/13 for 2 interrupts, and the rest showing PWM for visualization!In this particular instance, an assertion is triggeered in the GPIO12 interrupt because timing isn't met (too short interval between calls. It can be seen that the actual problem happens in the *previous* interval, that is slightly delayed.In this case, the IRQ on GPIO13 shows no anomalies (it really just updates an index at this point), but previously I have observed that having an _Atomic variable access caused that function to take 10+ us. Removing the _Atomic decl improved the execution time for that IRQ, but clearly wasn't the underlying cause for the other IRQ's jitter. (IRQ setting GPIO12 is also higher priority than 13, and this has been observed to work correctly with debugger breaks)

Does anyone have any idea what gives? I could not so far find docs on what the GCC builtins do, but I have a suspicion that all this has to do with core0 / core1 sync, with IRQs being disabled on core1 for extended periods of time because of something going on on core0. My IRQ that shows the jitter is already at priority 0 (ARM mode), and I cannot find references to other IRQ priorities being used other than 0x80 being the default.

Statistics: Posted by dognotdog — Sun Jan 11, 2026 4:28 am

---