Is there any way/s to check where actually is it failing or point which file?
Thank you, Abhijeet. On Thu, Sep 16, 2021 at 8:49 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > On Thu, 16 Sept 2021 at 19:46, Peter Maydell <peter.mayd...@linaro.org> > wrote: > > > > On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar > > <abhijeetinamdar3...@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 >
