The vector table offset (VTOR) wasn't updated to point at the application's vector table. The bootloader has its own vector table at the start of flash, and the application has a separate one at its own base address higher in flash. When the bootloader jumps to the app, if it doesn't set SCB->VTOR to the application's table address, the NVIC keeps dispatching interrupts through the bootloader's table, so the app's ISRs are never reached (interrupts vector into the bootloader's handlers or defaults), and it looks like the app's interrupts "don't work" even though everything else runs. The correct handoff sets VTOR to the app's table, loads the app's initial stack pointer from the app table's first word, and then jumps to the app's reset handler. Related boot bugs in the same vein: the app being linked at the wrong base address (so its vector table isn't where the bootloader points), interrupts left enabled during the transition causing a fault, or the app expecting clocks/peripherals in reset state that the bootloader changed. But the classic, specific answer is the missing VTOR relocation.
Embedded Systems Fundamentals · Interview question
A bootloader jumps to the application but the app's interrupts don't work. What's the likely cause?
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
Boot Sequence & Startup Code
Everything that runs before main(): the reset vector, copying .data and zeroing .bss, the vector table, and how a bootloader hands off via VTOR.