The main problem with the UART IRQ is that it gets very spicy very quickly.

It calls out to mp_irq_handler and it can either be set as a "hard" IRQ which runs the user supplied MicroPython IRQ handler in the interrupt or it will call mp_sched_schedule to schedule the interrupt for the VM to run normally (out of IRQ context) as a soft IRQ.

I don't think it's feasible to move the whole dependency chain into RAM but maybe that call could be deferred during flash writes and handled when the flash write has finished.

The whole concept of a "hard" IRQ seems pretty fraught, and would be antithetical to leaving this particular IRQ enabled. I don't know how we reconcile that. Things also get even more spicy if PSRAM is involved.

Maybe an alternate approach would be to hook the UART to a DMA but I only have a nebulous concept how that might work.

What I do know is that losing data from the UART during flash writes is not ideal- especially when it's used for PPP/networking purposes.

Ideally people would design RP2xxx boards with two SPI flash: one dedicated as memory-mapped "ROM" for code and ROMFS, and another for read/write access.

Hint, hint 😂

I wish!

I am not getting far with efforts to unravel this, though it's notable that CircuitPython does not rely on the SDK's save_and_disable_interrupts() for similar reasons. It's a little heavy handed. Since I didn't want to deal with mystery meat CMSIS functions I just looped through all the available IRQs, checked if they are enabled, added their state to a bitmap and disabled them. Reverse to re-enable. This seems to work just as well as the heavy-handed PRIMASK.... as long as I disable all IRQs 😆

Afaict there's nothing in the UART IRQ I haven't accounted for, and I have taken pains to defer firing of the user code (pushing the IRQ handler into a global var and picking that up by hooking the soft timer interrupt). But no dice. Same bonkers hacks work fine writing to microSD, hard lock writing to flash. I must be missing a trick!