So the solution would be placing the vector correctly and mapping to the right address for Flash/RAM...?
BR. Abhijeet. On Sun, 5 Dec, 2021, 17:59 Peter Maydell, <peter.mayd...@linaro.org> wrote: > 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 >
