Re: Program can't exit from the exeception

[Peter Maydell]

On Mon, 20 Jun 2022 at 16:30, l ck <lck2000@outlook.com> wrote:
>
> Hi everyone, when I tried to run a exeception demo in netduino2, it can't 
> exit from the exeception, in which after executing the assembly instruction 
> `br lr`, it can't return back to the normal execution. This is the content 
> after I executed `qemu-system-arm -M netduino2 -kernel demo.elf -d int` in 
> terminal:

> Loaded reset SP 0x0 PC 0x0 from vector table
> Loaded reset SP 0x20001000 PC 0x12b from vector table
> Taking exception 5 [IRQ] on CPU 0
> ...taking pending nonsecure exception 53
> ...loading from element 53 of non-secure vector table at 0xd4
> ...loaded new PC 0x1c1
> Taking exception 8 [QEMU v7M exception exit] on CPU 0
> Exception return: magic PC fffffff9 previous exception 53
> ...tailchaining to pending exception
> ...taking pending nonsecure exception 53
> ...loading from element 53 of non-secure vector table at 0xd4
> ...loaded new PC 0x1c1
> Taking exception 8 [QEMU v7M exception exit] on CPU 0
> Exception return: magic PC fffffff9 previous exception 53
> ...tailchaining to pending exception
> ...taking pending nonsecure exception 53
> ...loading from element 53 of non-secure vector table at 0xd4
> ...loaded new PC 0x1c1

The CPU takes an interrupt because of an external interrupt
from some device, and calls your interrupt handler code. Your
interrupt handler code runs. When that interrupt handler
returns, the CPU sees that the external interrupt is still
pending, and so it calls your interrupt handler again.
This can be caused by several things:

(1) your interrupt handler code is not actually doing what
it needs to do to service the device, ie read the data,
write to device registers, etc, to cause the device to
lower its IRQ line. If the IRQ line is still high when the
interrupt handler routine returns, the CPU will treat the
interrupt as still pending, and will call the handler again.

(2) the device has been programmed to raise interrupts more
quickly than the interrupt handler code can handle them.
For instance, if a timer device is programmed to raise an
interrupt every nanosecond, there is no way the CPU will
run fast enough for the timer interrupt handler to dismiss
the timer interrupt and then return before the next timer
interrupt happens. So the guest code spends all its time in
the timer interrupt handler and no time running anything else.

thanks
-- PMM