Assistance Required for QEMU Hardfault Error with Cortex-M33 on MPS2AN505

Assistance Required for QEMU Hardfault Error with Cortex-M33 on MPS2AN505

[sanjana gogte]

[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]

I hope this message finds you well. I am reaching out to seek your
expertise regarding a persistent issue I have encountered while working
with QEMU, specifically a hardfault error when emulating the MPS2AN505 with
a Cortex-M33 core.

I have been grappling with this issue for some time and am unsure of the
next steps to take. Could you please advise on potential areas to
investigate or adjustments that might resolve this error? I am particularly
curious if the issue lies with the vector table placement or the
configuration in my linker script.

The error I am facing is as follows:
*qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)*

This occurs when I attempt to run my kernel.elf file using the following
QEMU command:




*qemu-system-arm -machine mps2-an505 -cpu cortex-m33 \                -m
16M \                -nographic -serial mon:stdio \                -device
loader,file=kernel.elf*

For your reference, here are the relevant details of my setup:

Startup File (Boot.s)
*.**thumb*
*.section .isr_vector*
*    .long    __StackTop         /* Initial Top of Stack */*
*    .long    Reset_Handler      /* Reset Handler */*

*.text*
*.global Reset_Handler*
*Reset_Handler:  *
*    ldr     R0, = main*
*bx      R0*

Linker Script (Kernel.ld)






















*MEMORY{   NS_CODE (rx)     : ORIGIN = 0x00000000, LENGTH = 512K
 S_CODE_BOOT (rx) : ORIGIN = 0x10000000, LENGTH = 512k   RAM   (rwx) :
ORIGIN = 0x20000000, LENGTH = 512k}/* Entry Point
*/ENTRY(Reset_Handler)SECTIONS{    .text :    {
KEEP(*(.isr_vector))        *(.text)        *(.data)        *(.bss)    } >
S_CODE_BOOT    /* Set stack top to end of S_CODE_BOOT. */    __StackTop =
ORIGIN(S_CODE_BOOT) + LENGTH(S_CODE_BOOT);}*

Toolchain Used:
*arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi*

Compilation Commands to generate my elf file:




*arm-none-eabi-gcc -mcpu=cortex-m33 -g -c boot.s -o boot.oarm-none-eabi-ld
boot.o main.o -T kernel.ld -o kernel.elfarm-none-eabi-objdump -d kernel.elf
> kernel.listarm-none-eabi-objdump -t kernel.elf | sed '1,/SYMBOL TABLE/d;
s/ .* / /; /^$/d' > kernel.symarm-none-eabi-readelf -A kernel.elf*

Main Function (main.c):



*void main(void){    while (1);}*

Output of readelf -wl Command:











*Elf file type is EXEC (Executable file)Entry point 0x10000008There is 1
program header, starting at offset 52Program Headers:  Type
Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align  LOAD
0x001000 0x10000000 0x10000000 0x00016 0x00016 R E 0x1000 Section to
Segment mapping:  Segment Sections...   00     .text*

Guest Errors Observed:
I
*nvalid read at addr 0x10000000, size 4, region '(null)', reason:
rejectedInvalid read at addr 0x10000004, size 4, region '(null)', reason:
rejected*

Your guidance on this matter would be greatly appreciated. I am eager to
understand and resolve this issue, and I believe your expertise could be
invaluable in this context.

Thank you for your time and consideration. I look forward to any insights
or suggestions you might have.

Best regards,
Sanjana Gogte

[-- Attachment #2: Type: text/html, Size: 10942 bytes --]

Re: Assistance Required for QEMU Hardfault Error with Cortex-M33 on MPS2AN505

[Peter Maydell]

On Tue, 16 Jan 2024 at 14:16, sanjana gogte <sanj27272@gmail.com> wrote:
>
> I hope this message finds you well. I am reaching out to seek your expertise regarding a persistent issue I have encountered while working with QEMU, specifically a hardfault error when emulating the MPS2AN505 with a Cortex-M33 core.
>
> I have been grappling with this issue for some time and am unsure of the next steps to take. Could you please advise on potential areas to investigate or adjustments that might resolve this error? I am particularly curious if the issue lies with the vector table placement or the configuration in my linker script.
>
> The error I am facing is as follows:
> qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
>
> This occurs when I attempt to run my kernel.elf file using the following QEMU command:
>
> qemu-system-arm -machine mps2-an505 -cpu cortex-m33 \
>                 -m 16M \
>                 -nographic -serial mon:stdio \
>                 -device loader,file=kernel.elf

(1) Tell us what QEMU version you're using.

(2) Give us the debug logs, by adding
 -D qemu.log -d
in_asm,exec,cpu,int,cpu_reset,unimp,guest_errors,nochain -singlestep

Your guest is probably crashing in early bootup, and the
only way to tell where is to debug it.

Also, your interrupt vector table is too short, because
you've only put in the first two entries (SP and reset PC).
This will result in unhelpfully confusing behaviour if
the CPU ever takes some other kind of exception.

thanks
-- PMM

Re: Assistance Required for QEMU Hardfault Error with Cortex-M33 on MPS2AN505

[sanjana gogte]

[-- Attachment #1: Type: text/plain, Size: 6054 bytes --]

Hi,
1) I am using QEMU Version 7.1.0. I am currently using this version with a
plan to connect the remote port from Xilinx to the mps2an505 board. The
decision to use this specific version is heavily influenced by the fact
that it is the same version utilized by Xilinx's QEMU.

2) Debug Logs :
guest_errors:

Invalid read at addr 0x10000000, size 4, region '(null)', reason: rejected
Invalid read at addr 0x10000004, size 4, region '(null)', reason: rejected
Invalid read at addr 0x10800000, size 2, region '(null)', reason: rejected
qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)

in_asm:

IN:
0x10000008:
OBJD-T: 00480047

----------------
IN:
0x10000008:
OBJD-T: 00480047

----------------
IN:
0x10000010:
OBJD-T: 80b400affee70000000000000000000000000000000000000000000000000000
OBJD-T: 0000000000000000000000000000000000000000000000000000000000000000
OBJD-T: 0000000000000000000000000000000000000000000000000000000000000000
OBJD-T: 0000000000000000000000000000000000000000000000000000000000000000
OBJD-T: 0000000000000000000000000000000000000000000000000000000000000000
OBJD-T: 0000000000000000000000000000000000000000000000000000000000000000
OBJD-T: 0000000000000000000000000000000000000000000000000000000000000000

...goes on infinitely till address 0x107ffc00:

int :

Loaded reset SP 0x0 PC 0x0 from vector table
Loaded reset SP 0x10080000 PC 0x10000008 from vector table
Taking exception 18 [v7M INVSTATE UsageFault] on CPU 0
...taking pending secure exception 3
...loading from element 3 of secure vector table at 0x1000000c
...loaded new PC 0x10000011
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)


exec :
Trace 0: 0x7f2614000100 [0000040a/10000008/00000150/ff008000]
Stopped execution of TB chain before 0x7f2614000100 [10000008]
Trace 0: 0x7f2614000240 [0000040a/10000008/00000150/ff008000]
Trace 0: 0x7f2614000380 [0080040b/10000010/00000170/ff008000]
Trace 0: 0x7f2614000c80 [0080040b/10000400/00000170/ff008000]
goes on infinitely ...

cpu_reset :

CPU Reset (CPU 0)
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=00000000 R14=00000000 R15=00000000
XPSR=40000000 -Z-- A NS priv-thread
CPU Reset (CPU 0)
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=00000000 R14=ffffffff R15=00000000
XPSR=40000000 -Z-- A S priv-thread
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=1007ffe0 R14=fffffff9 R15=10800000
XPSR=41000003 -Z-- T S handler
s00=00000000 s01=00000000 d00=0000000000000000
s02=00000000 s03=00000000 d01=0000000000000000
s04=00000000 s05=00000000 d02=0000000000000000
s06=00000000 s07=00000000 d03=0000000000000000
s08=00000000 s09=00000000 d04=0000000000000000
s10=00000000 s11=00000000 d05=0000000000000000
s12=00000000 s13=00000000 d06=0000000000000000
s14=00000000 s15=00000000 d07=0000000000000000
s16=00000000 s17=00000000 d08=0000000000000000
s18=00000000 s19=00000000 d09=0000000000000000
s20=00000000 s21=00000000 d10=0000000000000000
s22=00000000 s23=00000000 d11=0000000000000000
s24=00000000 s25=00000000 d12=0000000000000000
s26=00000000 s27=00000000 d13=0000000000000000
s28=00000000 s29=00000000 d14=0000000000000000
s30=00000000 s31=00000000 d15=0000000000000000
FPSCR: 00000000

3) You said the vector table is too small so I tried something like this
from your reference files but it gives me the same error:

Boot.s ( Startup file )

.thumb
.syntax unified

.section .isr_vector
    .long __StackTop
    .long Reset_Handler
    .word 0
    .word 0
    .rept 7
    .word 0
    .endr
    .word 0
    .word 0
    .word 0
    .word 0
    .word 0
    .rept 32
    .word 0
    .endr


.text
.global Reset_Handler
Reset_Handler:
    ldr     R0, = main
    bx      R0

Do you think it is  something to do with the version itself or my memory
layout? Please let me know. Any insights on the debug logs would also be of
great help. Thanks!

On Tue, 16 Jan 2024 at 19:52, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Tue, 16 Jan 2024 at 14:16, sanjana gogte <sanj27272@gmail.com> wrote:
> >
> > I hope this message finds you well. I am reaching out to seek your
> expertise regarding a persistent issue I have encountered while working
> with QEMU, specifically a hardfault error when emulating the MPS2AN505 with
> a Cortex-M33 core.
> >
> > I have been grappling with this issue for some time and am unsure of the
> next steps to take. Could you please advise on potential areas to
> investigate or adjustments that might resolve this error? I am particularly
> curious if the issue lies with the vector table placement or the
> configuration in my linker script.
> >
> > The error I am facing is as follows:
> > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
> >
> > This occurs when I attempt to run my kernel.elf file using the following
> QEMU command:
> >
> > qemu-system-arm -machine mps2-an505 -cpu cortex-m33 \
> >                 -m 16M \
> >                 -nographic -serial mon:stdio \
> >                 -device loader,file=kernel.elf
>
> (1) Tell us what QEMU version you're using.
>
> (2) Give us the debug logs, by adding
>  -D qemu.log -d
> in_asm,exec,cpu,int,cpu_reset,unimp,guest_errors,nochain -singlestep
>
> Your guest is probably crashing in early bootup, and the
> only way to tell where is to debug it.
>
> Also, your interrupt vector table is too short, because
> you've only put in the first two entries (SP and reset PC).
> This will result in unhelpfully confusing behaviour if
> the CPU ever takes some other kind of exception.
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 7790 bytes --]

Re: Assistance Required for QEMU Hardfault Error with Cortex-M33 on MPS2AN505

[Peter Maydell]

On Thu, 18 Jan 2024 at 06:30, sanjana gogte <sanj27272@gmail.com> wrote:
>
> Hi,
> 1) I am using QEMU Version 7.1.0. I am currently using this version with a plan to connect the remote port from Xilinx to the mps2an505 board. The decision to use this specific version is heavily influenced by the fact that it is the same version utilized by Xilinx's QEMU.
>
> 2) Debug Logs :
> guest_errors:
>
> Invalid read at addr 0x10000000, size 4, region '(null)', reason: rejected
> Invalid read at addr 0x10000004, size 4, region '(null)', reason: rejected
> Invalid read at addr 0x10800000, size 2, region '(null)', reason: rejected
> qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
>
> in_asm:

>
> IN:
> 0x10000008:
> OBJD-T: 00480047

Whoever built your QEMU didn't do it with libcapstone-dev
installed, so the debug logs have only binary dumps of
instructions, not the actual instructions, which is a pity
(--enable-capstone will force configure to either find the
necessary library or else give you an error message.)

Also, I did not mean "do logs of every -d option separately",
I meant "do a single log, with -d
in_asm,exec,cpu,int,cpu_reset,unimp,guest_errors,nochain"
That way you get the different bits of logging in their
correct sequence relative to each other.

Luckily, this bit is enough to figure out what's going on:

> Loaded reset SP 0x0 PC 0x0 from vector table
> Loaded reset SP 0x10080000 PC 0x10000008 from vector table

We load the PC from the vector table, but it does not
have the low bit set, which is not correct. (All entries
in the vector table must be function pointers in the
usual Thumb convention, where the lowest bit is set to
indicate Thumb mode and clear to indicate Arm mode.)
This means that we will start without the Thumb T bit set...

> Taking exception 18 [v7M INVSTATE UsageFault] on CPU 0

...which on M-profile means we immediately take a fault trying
to execute the first instruction...

> ...taking pending secure exception 3
> ...loading from element 3 of secure vector table at 0x1000000c
> ...loaded new PC 0x10000011

...but because your vector table includes no entry for
the hardfault vector, we instead load a PC value which
doesn't point anywhere useful...

> 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)

...and eventually we execute off the end of the ROM memory,
and then take a bus fault on the instruction fetch. This
is a Lockup because we were already in a HardFault handler
when we took this fault.

> 3) You said the vector table is too small so I tried something like this from your reference files but it gives me the same error:
>
> Boot.s ( Startup file )
>
> .thumb
> .syntax unified
>
> .section .isr_vector
>     .long __StackTop
>     .long Reset_Handler
>     .word 0

Zeroes here aren't very helpful because the CPU will try
to jump to address 0 (and then immediately take another
fault because the Thumb bit isn't set, which will be
a Lockup condition again). If you at least make them point to
branch-to-self instructions it'll be a bit clearer when
you take an exception you weren't expecting, because in
the debugger you'll see execution looping at that insn.

>     .word 0
>     .rept 7
>     .word 0
>     .endr
>     .word 0
>     .word 0
>     .word 0
>     .word 0
>     .word 0
>     .rept 32
>     .word 0
>     .endr
>
>
> .text
> .global Reset_Handler
> Reset_Handler:
>     ldr     R0, = main
>     bx      R0

But really your problem is here. You haven't told the assembler
that "Reset_Handler" is a function entry point, and so it treats
it like a data label. That means that the least significant bit
is not set when you reference it in the vector table.

Something like this will do what you want:
        .type Reset_Handler, function
        .global Reset_Handler
Reset_Handler:

PS: a hint for later: your code here does not do anything
to enable the FPU before it jumps into C code. If your
C compiler is generating code to use the FPU this will
mean it will take an exception. So either make sure the
C compiler is configured not to use the FPU, or else enable
the FPU first.

thanks
-- PMM

Re: Assistance Required for QEMU Hardfault Error with Cortex-M33 on MPS2AN505

[sanjana gogte]

[-- Attachment #1: Type: text/plain, Size: 8643 bytes --]

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:

Remote debugging using: 1234


Reset_Handler () at boot.s:20

20          blx     helper

(gdb) l

15         blx     R0

16

17      .type Reset_Handler, function

18      .global Reset_Handler

19      Reset_Handler:

20          blx     helper

21          bx      lr

22

(gdb) s

Remote connection closed



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.


Please give me your insights on how I can fix this.


Some of my code for your reference:


My startup code :

.syntax unified

.thumb


.section .isr_vector

    .long    __StackTop

    .long    Reset_Handler




.text

.type helper,function

.global helper

helper :

   ldr     R0, = main

   blx     R0


.type Reset_Handler, function

.global Reset_Handler

Reset_Handler:

    blx     helper

    bx      lr



( Like you mentioned  previously , In the .isr_vector section I tried making
the other exception handlers  point to branch-to-self instructions but that
gives me the same error )


My linker code :


/* Linker script to configure memory regions. */

MEMORY

{

   NS_CODE (rx)     : ORIGIN = 0x00000000, LENGTH = 512K

   S_CODE_BOOT (rx) : ORIGIN = 0x10000000, LENGTH = 512K

   RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 512K

}


/* Entry Point */

ENTRY(Reset_Handler)


SECTIONS

{

    .text :

    {

        KEEP(*(.isr_vector))

        *(.text)

        *(.data)

    *(.bss)

    } > S_CODE_BOOT

    /* Set stack top to end of S_CODE_BOOT. */

    __StackTop = ORIGIN(S_CODE_BOOT) + LENGTH(S_CODE_BOOT);




}


kernel.list file :


kernel.elf:     file format elf32-littlearm


Disassembly of section .text:

10000000 <helper-0x8>:
10000000: 10080000 .word 0x10080000
10000004: 1000000d .word 0x1000000d

10000008 <helper>:
10000008: 4802       ldr r0, [pc, #8] @ (10000014 <Reset_Handler+0x8>)
1000000a: 4780       blx r0

1000000c <Reset_Handler>:
1000000c: f7ff fffc bl 10000008 <helper>
10000010: 4770       bx lr
10000012: 0000       .short 0x0000
10000014: 10000019 .word 0x10000019

10000018 <main>:
10000018: b480       push {r7}
1000001a: af00       add r7, sp, #0
1000001c: e7fe       b.n 1000001c <main+0x4>






On Thu, 18 Jan 2024 at 15:34, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Thu, 18 Jan 2024 at 06:30, sanjana gogte <sanj27272@gmail.com> wrote:
> >
> > Hi,
> > 1) I am using QEMU Version 7.1.0. I am currently using this version with
> a plan to connect the remote port from Xilinx to the mps2an505 board. The
> decision to use this specific version is heavily influenced by the fact
> that it is the same version utilized by Xilinx's QEMU.
> >
> > 2) Debug Logs :
> > guest_errors:
> >
> > Invalid read at addr 0x10000000, size 4, region '(null)', reason:
> rejected
> > Invalid read at addr 0x10000004, size 4, region '(null)', reason:
> rejected
> > Invalid read at addr 0x10800000, size 2, region '(null)', reason:
> rejected
> > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
> >
> > in_asm:
>
> >
> > IN:
> > 0x10000008:
> > OBJD-T: 00480047
>
> Whoever built your QEMU didn't do it with libcapstone-dev
> installed, so the debug logs have only binary dumps of
> instructions, not the actual instructions, which is a pity
> (--enable-capstone will force configure to either find the
> necessary library or else give you an error message.)
>
> Also, I did not mean "do logs of every -d option separately",
> I meant "do a single log, with -d
> in_asm,exec,cpu,int,cpu_reset,unimp,guest_errors,nochain"
> That way you get the different bits of logging in their
> correct sequence relative to each other.
>
> Luckily, this bit is enough to figure out what's going on:
>
> > Loaded reset SP 0x0 PC 0x0 from vector table
> > Loaded reset SP 0x10080000 PC 0x10000008 from vector table
>
> We load the PC from the vector table, but it does not
> have the low bit set, which is not correct. (All entries
> in the vector table must be function pointers in the
> usual Thumb convention, where the lowest bit is set to
> indicate Thumb mode and clear to indicate Arm mode.)
> This means that we will start without the Thumb T bit set...
>
> > Taking exception 18 [v7M INVSTATE UsageFault] on CPU 0
>
> ...which on M-profile means we immediately take a fault trying
> to execute the first instruction...
>
> > ...taking pending secure exception 3
> > ...loading from element 3 of secure vector table at 0x1000000c
> > ...loaded new PC 0x10000011
>
> ...but because your vector table includes no entry for
> the hardfault vector, we instead load a PC value which
> doesn't point anywhere useful...
>
> > 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)
>
> ...and eventually we execute off the end of the ROM memory,
> and then take a bus fault on the instruction fetch. This
> is a Lockup because we were already in a HardFault handler
> when we took this fault.
>
> > 3) You said the vector table is too small so I tried something like this
> from your reference files but it gives me the same error:
> >
> > Boot.s ( Startup file )
> >
> > .thumb
> > .syntax unified
> >
> > .section .isr_vector
> >     .long __StackTop
> >     .long Reset_Handler
> >     .word 0
>
> Zeroes here aren't very helpful because the CPU will try
> to jump to address 0 (and then immediately take another
> fault because the Thumb bit isn't set, which will be
> a Lockup condition again). If you at least make them point to
> branch-to-self instructions it'll be a bit clearer when
> you take an exception you weren't expecting, because in
> the debugger you'll see execution looping at that insn.
>
> >     .word 0
> >     .rept 7
> >     .word 0
> >     .endr
> >     .word 0
> >     .word 0
> >     .word 0
> >     .word 0
> >     .word 0
> >     .rept 32
> >     .word 0
> >     .endr
> >
> >
> > .text
> > .global Reset_Handler
> > Reset_Handler:
> >     ldr     R0, = main
> >     bx      R0
>
> But really your problem is here. You haven't told the assembler
> that "Reset_Handler" is a function entry point, and so it treats
> it like a data label. That means that the least significant bit
> is not set when you reference it in the vector table.
>
> Something like this will do what you want:
>         .type Reset_Handler, function
>         .global Reset_Handler
> Reset_Handler:
>
> PS: a hint for later: your code here does not do anything
> to enable the FPU before it jumps into C code. If your
> C compiler is generating code to use the FPU this will
> mean it will take an exception. So either make sure the
> C compiler is configured not to use the FPU, or else enable
> the FPU first.
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 27770 bytes --]

Re: Assistance Required for QEMU Hardfault Error with Cortex-M33 on MPS2AN505

[Peter Maydell]

On Tue, 30 Jan 2024 at 07:48, sanjana gogte <sanj27272@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

Re: Assistance Required for QEMU Hardfault Error with Cortex-M33 on MPS2AN505

[sanjana gogte]

[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

Thank you Peter. I will reach out to someone from Xilinx.
Do you have insights on how I could use a Qemu emulated core ( M profile )
with a Virtual Prototype ( System C IP ) ?

Thank you.

On Tue, 30 Jan 2024 at 15:59, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Tue, 30 Jan 2024 at 07:48, sanjana gogte <sanj27272@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
>

[-- Attachment #2: Type: text/html, Size: 3291 bytes --]