calling `sleep_ms` inside an interrupt handler causes lockup

[Lard4]

Summary: when you call sleep_ms inside of an interrupt handler, some sort of infinite loop occurs inside of the hardware timer. Specifically, picoprobe/gdb is pointing to the code hanging somewhere in this function:

pico-sdk/src/rp2_common/hardware_timer/include/hardware/timer.h

Line 109 in 26653ea

uint32_t hi_target = target >> 32u;

To reproduce: build/flash https://github.com/Lard4/pico-irq-test then when GP22 goes high (gets the interrupt), it turns off the LED then hangs.

[Wren6991]

Yes, sleep_ functions are interrupt-driven (to save power) and you are using them inside an interrupt. Sleeping in an IRQ is generally unsupported on any platform, and the function description tells you not to do this. Having long delays in an IRQ is also pretty unfriendly to the code being interrupted.

If you do want to insert a long delay in an IRQ, the function to use is busy_wait_us_32() which you will see is also listed as a "see also" under the sleep functions.

[kilograham]

I think nonetheless we should downgrade a sleep in an IRQ handler to a busy_wait_us automatically (by default)

[swetland]

I'd recommend leaving sleep disallowed from IRQ context (as is the case in just about every OS out there), and perhaps instead add an assert(irqs-are-enabled) in sleep in debug builds. The chances of waiting any amount of time in irq context ever being the right thing to do are near zero.

[kilograham]

yeah perhaps i was feeling overly generous

[kilograham]

merged into develop - sleep in an IRQ handler remains disallowed