qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority


From: Peter Maydell
Subject: Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
Date: Thu, 16 Sep 2021 19:48:44 +0100

On Thu, 16 Sept 2021 at 19:46, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar
> <abhijeetinamdar3005@gmail.com> wrote:
> > How do I fix it ? it's for cortex-m3 and the below is the gdb trace when I 
> > load ELF.
> >
> > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
> >
> > R00=00000000 R01=00000000 R02=00000000 R03=00000000
> > R04=00000000 R05=00000000 R06=00000000 R07=00000000
> > R08=00000000 R09=00000000 R10=00000000 R11=00000000
> > R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
> > XPSR=40000003 -Z-- A handler
> > FPSCR: 00000000

> This particular case is "we needed to take a HardFault exception,
> but we were already in a HardFault exception". The most common
> cause of this is that your code has crashed hard on startup
> (eg it tries to read from unreadable memory or jumps off into nowhere:
> if this happens before it has set up exception handling for HardFault
> then you get this. This also happens if its attempt to handle
> HardFaults is buggy and crashes.)

Oh, and note that the PC is zero and the Thumb bit is not set:
this means that your guest code did something that caused the
CPU to try to take an exception, but your ELF file didn't
provide an exception vector table, and so the vector table
entry for the exception was 0. That means that the CPU will
attempt to execute from address 0 with the Thumb bit clear,
which provokes an immediate UsageFault exception, usually leading
to the exception-in-an-exception Lockup case above.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]