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

[Peter Maydell]

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

If the CPU goes into Lockup this indicates that something has gone
very badly wrong with your guest code, and the situation is not
recoverable. In real hardware the CPU sits there doing absolutely
nothing forever more[*]. QEMU doesn't actually emulate the CPU being
in Lockup state, so it just treats it as a fatal error. (Check the
M-profile architecture reference for more information on Lockup and
the various kinds of guest bug that can get you there.)

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.)

You should approach this by debugging your guest and looking at
what it is doing before it gets to this point.

[*] Technically there are ways to get yourself out of Lockup
state on a real CPU, such as having an external watchdog that
resets the CPU, or some extremely esoteric tricks used only by
code that's trying to test how Lockup state behaves.

-- PMM