Summary

Fixes a regression introduced in3af006e (part of#13329), where WFE never blocked inmp_wfe_or_timeout() function and would busy-wait instead. This increases power consumption measurably. Originally found when testing#15345

Root cause is thatmp_wfe_or_timeout() calls soft timer functions that (after the regression) callrecursive_mutex_enter() andrecursive_mutex_exit(). Mutex exit callslock_internal_spin_unlock_with_notify() and the default pico-sdk implementation of this macro issues a SEV which negates the WFE that follows it, meaning the CPU never suspends.

Seehttps://forums.raspberrypi.com/viewtopic.php?p=2233908 for more details.

The fix in this comment adds a custom "nowait" variant mutex that doesn't do WFE/SEV, and uses this one for PendSV. This will use more power when there's contention for the PendSV mutex as the other core will spin, but this shouldn't happen very often.

Additional commit fixes a bug that was masked by this bug, specifically that core1 didn't have any way to resume from WFE (because the soft timer interrupt only triggers on core0).

Testing

Tested on PICO board while measuring USB power consumption. Prior to this fix,time.sleep(1) uses 3-4mA more power than sitting at an idle REPL. After this fix, the power consumption is approximately the same (actually approx 0.3mA higher while sleeping, I assume due to the extra clock or maybe because of USB traffic).

Also ran the full rp2 test suite multiple times. The thread_sleep2 test successfully found the core1 bug mentioned above.

Also connected a PICO-W to a Wi-Fi network.

Trade-offs and Alternatives

This is the third fix I wrote for this issue(!)

• The first version of this PR replaced the soft timer inmp_wfe_or_timeout() with a dedicated hardware timer alarm. This works fine for single core, but in dual core there's potential for both cores to enter this function at the same time meaning this approach is no longer simple.
• I also tried making all the recursive mutexes the "nowait" variety, instead of adding a new variant. This works fine, but it means if there is contention over any mutex then the waiting core will spin. Mostly this probably doesn't matter as there won't be a lot of contention, but there are some pathological cases: For example a program where core1 spends most of its time blocked on a lock or similar.

This approach adds a bit more code size, but it means the low power mutex variant is still used everywhere except for PendSV - and there shouldn't be a lot of lock contention over PendSV.