On Sat, 4 Dec 2021 at 23:06, abhijeet inamdar
<abhijeetinamdar3005@gmail.com> wrote:
> I'm getting this error. There is no hit for this in google as most are on Hardfault. The error is :
>
> "Taking exception 18 [v7M INVSTATE UsageFault]
> ...BusFault with BFSR.STKERR
> ...taking pending nonsecure exception 3
> qemu: fatal: Lockup: can't take terminal derived exception (original exception priority -1)".
This means that you tried to take an exception (UsageFault), but
trying to stack the registers for the exception failed (BusFault
with BFSR.STKERR set), and then on top of that we had another
exception trying to take the busfault that meant we were unable
to take any exception at all (this is what "terminal derived exception"
means). I think that last fault was a vector table fetch failure,
as I don't think QEMU has any other cases of terminal derived
exceptions. The lockup happens when the terminal derived
exception is at the same effective priority (here -1) as the
exception we were trying to take (busfault).
If you look in the execution trace you'll probably find that
the stack pointer is bogus. The SP is initially read from the
vector table, so if the vector table isn't actually readable
then your code will start with a bogus SP value, which then
means that trying to take an exception will take this bus fault.
> I have changed the address of the vectors(target/arm/cpu.c) to be
> placed for a Cortex-M3 machine where I want to place it or is it
> restricted to only "0x0".
The vector table can go wherever your machine/SoC puts it, but you
shouldn't be editing cpu.c to change it. The CPU object has two
QOM properties, init-svtor and init-nsvtor, which the board code
sets to specify the Secure VTOR and the NonSecure VTOR reset values.
(If a CPU doesn't support secure, like the M3, the init-nsvtor is
the only vtor). The machine/SoC code should configure these CPU
properties to match whatever the real hardware has them set to.
> And is there any fixed size for the Flash size for the M3 machine
> (I don't believe but doubt)
This is entirely up to the machine model code -- you need to create
the flash in the right place in the address map and with the right
size corresponding to the hardware you're emulating.
The symptoms described here suggest to me that your machine model
isn't creating RAM/flash in the right places, or that you're
setting the vector table address to the wrong place.
thanks
-- PMM