For now I'm getting around this with

#undef CFG_TUSB_OS
#define CFG_TUSB_OS OPT_OS_NONE

in tusb_config.h, which disables the spinlocks in tud_task() on RP2350 but lets atomics remain fully functional. Not sure what a proper upstream fix would look like which handles all multicore TinyUSB use cases

Seems like it's probably tud_task() in TinyUSB that needs a fix, then, given how we're meant to use it. If it can be modded to not use the software spinlock to guard its event queue then this issue should go away. Other use cases that cause spurious wakes are more benign

Nope, no difference (and using acq_rel results in the same generated instructions as seq_cst).

The original reason I hit this was that tud_task() locks and unlocks a pico-sdk spinlock when it reads the event queue. For rp2350, the spinlocks are implemented with ldaexb/strexb.

pico_extexclall_inhibits_wfe.c GitHub Gist: instantly share code, notes, and snippets.

Here's a small standalone pico sdk reproducer that shows (via UART and LED, and the power draw increasing significantly) the change in behaviour when an atomic is incremented within the loop and EXTEXCLALL is left enabled.

I ran into a reason to disable EXTEXCLALL today (which led me here). Leaving it enabled turns every ldrex/strex into a SEV, which means the common pattern of "while (!condition) { tud_task(); __wfe(); }" is a spinloop on RP2350.