On Tue, 30 Jan 2024 at 07:48, sanjana gogte <sanj27...@gmail.com> wrote: > > I wanted to express my gratitude for your insightful solution concerning the > INVSTATE fault I was encountering. After recompiling my code with the -mthumb > compiler flag, the exception is no longer being raised, which marks a > significant step forward in my project. > > However, I've encountered another challenge while working with a specific > version of QEMU (QEMU emulator version 7.1.0, v2.6.0-55433-g23b643ba16). > While the code runs flawlessly on QEMU version 8.1.50 > (v8.1.0-2375-g516fffc993), the earlier version throws a hard fault, which is > critical to my use case. > > The use case involves attaching a remote port to the MPS2-AN505, and for > this, I need to utilize Xilinx’s fork of QEMU, which is based on version > 7.1.0 (v2.6.0-55433-g23b643ba16). The error I encounter during emulation is > as follows: > > Loaded reset SP 0x0 PC 0x0 from vector table > Loaded reset SP 0x10080000 PC 0x10000009 from vector table > Taking exception 3 [Prefetch Abort] on CPU 0 > ...at fault address 0x10800000 > ...with CFSR.IBUSERR > ...taking pending secure exception 3 > ...loading from element 3 000000c > ...loaded new PC 0x10000011 of secure vector table at 0x1 > Taking exception 3 [Prefetch Abort] on CPU 0 > ...at fault address 0x10800000 > ...with CFSR.IBUSERR > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > Observations: When I trace it using the GDB:
> It goes to prefetch abort as soon as I step into reset handler and the > connection gets closed. > What I do not understand is: > > 1) Why is my PC going to address 0x10800000? > > > 2) When I use Qemu version 8.1.50 (v8.1.0-2375-g516fffc993), the PC goes to > the right address and does not throw a prefetch abort. This strongly suggests you're running into a QEMU issue which we've fixed in some QEMU version after 7.1.0. For bugs in Xilinx's fork of QEMU, you should talk to Xilinx. In terms of why your PC is going to 0x10800000, it is almost certainly executing a lot of NOPs from some point until it runs off the end of the flash memory. If you use the gdb 'si' command to single step single instructions you'll probably find this is less confusing than using the 's' command, which steps an entire C source line. thanks -- PMM
