In MicroPython we have a reported issue of sleep_us causing the Pico W to hang, see micropython/micropython#12873

Debugging this issue is difficult because it's very sensitive to the timing and ordering of events, and adding debugging prints changes the behaviour. It looks like the CPU is hanging forever on the WFE in best_effort_wfe_or_timeout(), and the reason for this hang is because the hardware timer target associated with the pairing heap for the default alarm pool is set to a value in the past. The pairing heap is correct, the root node has a correct time in the future, but the hardware timer target is in the past.

I suspect that the pairing heap and its associated hardware timer have at some point got out of sync. And it's possibly in add_alarm_under_lock() that this happens (constructing an invariant for the pairing heap and its timer, that invariant is broken after a call to this function).

In the following part of add_alarm_under_lock():

          if (id == ph_insert_node(pool->heap, id)) {
              bool is_missed = hardware_alarm_set_target(pool->hardware_alarm_num, time);
              if (is_missed && !create_if_past) {
                  ph_remove_and_free_node(pool->heap, id);
              }
              if (missed) *missed = is_missed;
          }   

If is_missed is true and the node is removed, and that node was the head, then I think the hardware timer target needs to be set to the time associated with the new head of the pairing heap (ie the bug is that the timer target is not being updated to reflect the state of the pairing heap in the case is_missed is true).

Sorry that I can't give a reproduction in pure C, but the MicroPython code in this post does reproduce the issue: micropython/micropython#12873 (comment)

Let me know if I can help with giving more details on the bug.