On Sat, 4 Dec 2021 at 23:06, abhijeet inamdar <abhijeetinamdar3...@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
