2026-01-27 7:19 PM - last edited on 2026-01-28 4:01 AM by Andrew Neil
2026-01-27 8:23 PM - edited 2026-01-27 8:24 PM
My guess is your application writes to UART1 as well.
Nothing wrong that would explain this in the code you've shown.
2026-01-27 10:20 PM
FLASH APP? It's only in EXTI2_IRQHandler().
But I didn't trigger the interrupt.
2026-01-27 10:48 PM - edited 2026-01-27 10:50 PM
Disable the EXTI interrupt before the jump.
At least on a H7 a lot of de-inits and interrupt disabling is done before jumping.
Maybe before jumping you first de-init / change the GPIO config, and that triggers the EXTI interrupt.
So try to disable EXTI first, the de-init the GPIOs.
2026-01-27 10:57 PM
BTW, so many (and long) for-loops in an ISR are usually not considered good design, unless you have some very specific reason for that.
Why not just set a flag and then "print" in the main loop?
2026-01-28 1:12 AM
It still stuck.
2026-01-28 1:22 AM - edited 2026-01-28 1:45 AM
If I set a flag,it is not timely enough in some condition.For example, more than 2 interrupts occur simultaneously.
"print" in the main loop is DMA or other methods?
2026-01-28 3:08 AM
With "print" I mean any kind of UART output.
You could trigger a DMA UART TX in the ISR, then you don't have to wait there.
2026-01-28 3:12 AM
I'm not sure if I understand you correctly, right now it seems that the jump to the bootloader happens from within the ISR without any de-initialisations?
2026-01-28 3:52 AM
It sure looks like it did. The code in your interrupt is exactly what you show in your screenshot. I would recheck your assumptions here.