busy_wait_us() in ISR causes crash with breakpoints

[romain145]

To debug a DMA ISR I use busy_wait_us() to toggle a GPIO which is connected to a logic analyser.

The content of the DMA ISR is:

void dma_handler() {
    gpio_put(SIG_MCU_DBG0, 1);
    
    if (dma_channel_get_irq0_status(adc_dma_chan1)) {
        dma_channel_acknowledge_irq0(adc_dma_chan1);
        adc_status.dma_chan1_complete = true;
        adc_status.dma_overrun = adc_status.dma_chan2_complete;

        busy_wait_us(5);
        gpio_put(SIG_MCU_DBG0, 0);
    }
    else if (dma_channel_get_irq0_status(adc_dma_chan2)) {
        dma_channel_acknowledge_irq0(adc_dma_chan2);
        adc_status.dma_chan2_complete = true;
        adc_status.dma_overrun = adc_status.dma_chan1_complete;
        busy_wait_us(10);
        gpio_put(SIG_MCU_DBG0, 0);
    }
    else
    {
        adc_status.dma_error = true;
        busy_wait_us(100);
        gpio_put(SIG_MCU_DBG0, 0);
    }
}

The ADC DMA works well and I'm very happy with it.
However, after stopping on a breakpoint, the execution will not resume when clicking "Continue".
The debug console shows the message:

Could not read registers; remote failure reply 'E0E'

The RP2040 seems locked-up in the ISR, specifically in the busy_wait as shown on the logic analyser capture, since the signal goes high but is never cleared:

The button Continue is clicked at the red arrow.

Can busy_wait_us() be used in an ISR?
May be related to #108

[peterharperuk]

Busy wait should be ok. It shouldn't have anything to do with sleep. I can try with the examples. Are you loading the program via gdb?

[romain145]

Yes, sorry I forgot to add context.
I'm using the Pico SDK 2.1.0 with VS Code and the Pico Extension on Windows 11.
The debug probe is a Pico 1 with the latest debugprobe firmware https://github.com/raspberrypi/debugprobe/releases/tag/debugprobe-v2.2.1

[lurch]

Might be another instance of #2132 ?