The interrupt keeps re-firing. The peripheral's pending flag stays set, so the moment the ISR returns, the NVIC sees the still-asserted request and immediately re-enters the handler, an infinite loop of ISR executions that starves the main program and any lower-priority interrupts, effectively hanging the device (it looks "stuck" even though the CPU is running flat-out in the handler). Clearing the source is therefore mandatory and must be done correctly: many flags are write-1-to-clear, so you write a 1 to that specific bit (not a read-modify-write of the whole status register, which could clear other pending flags). Some peripherals clear the flag as a side effect of reading or writing their data register instead. The subtle version of this bug is clearing the wrong flag, or clearing it after re-enabling something, leaving a race, so you acknowledge the exact source early in the handler. This is one of the most common "my board freezes as soon as the interrupt fires" bugs.
Embedded Systems Fundamentals · Interview question
What happens if an ISR doesn't clear its interrupt flag?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Interrupts & ISRs
Let hardware tap the CPU on the shoulder instead of polling: the NVIC, the vector table, interrupt latency, and the hard rules for writing a correct ISR.