Qemu: fatal: Lockup: cant escalate 3 to Hardfault (Current Priority -1) error -Core Dumped

I am trying to emulate STM32F407XX controller with cortex M4 processor on QEMU. I wrote the .ld file as below:

ENTRY(_Reset)

MEMORY
{
  FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 512K
  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 128K
  CCMRAM (rw)     : ORIGIN = 0x10000000, LENGTH = 64K
  PERIPHERALS(rw) : ORIGIN = 0x40000000, LENGTH = 128K
}

SECTIONS
{

 .startup . : { stm32.o(.text) } >FLASH
 .text : { *(.text) } 
 .data : { *(.data) } >RAM AT> FLASH
 .bss : { *(.bss COMMON) } >RAM
 . = ALIGN(4);
 . = . + 0x400; /* required amount of stack */
 stack_top = 0x20020000;
}

When i generate the .elf file and run the code, I get the fault

Qemu: fatal: Lockup: cant escalate 3 to Hardfault (Current Priority -1) error.
Aborted (Core Dumped)

I feel its a memory problem. What am I doing wrong? I have allocated the flash, RAM memories according the reference manual requirements for STM32F407.

why does this error come in the first place & How can I resolve this error? Thanks.

You need to reset your ROM after your kernel loading in your machine (after armv7m_load_kernel call). You can use for example:

rom_check_and_register_reset();
qemu_devices_reset();

CPU should start on Reset Handler.

I spend a bit of time struggling with this, and I was surprised I couldn't find a nice resource online, so these are minimum changes I needed to run it. First realise that qemu needs a "machine" and that defines memory layout (-M none, o

Placing the vector table at the correct place solved the issue. I followed all the instructions by @peter Maydell in the comments above. I am adding them here.

You can turn on some of the debug logging options of QEMU with -d ('in_asm,int,exec,cpu,guest_errors,unimp' are probably a good set to start with), which will tell you what your guest code is doing. I would start by checking that your ELF file has a vector table in it at the place where QEMU expects to find it. Otherwise QEMU will hard fault immediately out of reset (which is what the hardware does).

The core dump is expected: QEMU goes into lockup, but we don't emulate lockup correctly (strictly speaking QEMU should just sit there doing nothing like the real hardware does), so we print a register dump and abort(). As I said in my previous comment, your problem is almost certainly that your binary doesn't have a vector table.

The main thing you must have in your vector table is the entries for the initial PC and stack pointer. The interrupt and exception entries are worth putting in but will only be needed if there is an interrupt or exception. If you put in debugging handlers for the other faults you'll at least know when you get a fault due to a bug in the rest of your program, though

[100%] [QEMU] CPU: cortex-m3 QEMU 3.1.0 monitor - type 'help' for more information (qemu) qemu-system-arm: warning: nic lan9118.0 has no peer qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) R00=00000005 R01=00000025 R02=00000000 R03=20001298 R04=00000000 R05=00000007 R06=00000000 R07=2000d8b0 R08=00000002 R09=00000000

Additional information for anyone like me that comes across this trying to fix a qemu hardfault: I got the same hardfault due to an unimplemented instruction.

This happened because I compiled the code with -mcpu=cortex-m4 but ran qemu with -cpu cortex-m3

The tricky thing about this is that it works for most of the code because gcc most often doesn't use one of the "m4-only-instructions" (even depending on the optimization level - it worked with -O1 but failed with -O2)...

Why GitHub? Features →. Code review; Project management; Integrations; Actions; Packages; Security

QEMU is a free processor/machine emulator and virtualizer. axf -monitor none -serial stdio -semihosting -nographic qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) R00=00000000 R01=00000000 R02=00000000 R03=00000000 -nographic-nographic.

[0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: cortex-m3 init ok eth_smsc9220_isr: 0 0 eth_initialize eth_tx eth_tx ***** Booting Zephyr OS zephyr-v1.13.0-1612-ga3345d16c4 ***** [00:00:00.000,000] <err> eth_smsc9220.eth_init: MAC 52:54:00:12:34:56 Hello World! mps2_an385 qemu: fatal: Lockup: can't escalate 3 to HardFault (current

1 What is the most efficient way to install all libraries, such as libgpg-error, libffi, libgcrypt for windows 10? Feb 27 '19 1 Qemu is not configured correctly when custom machine is added Apr 3 '19

Comments
  • Hard fault usually means some pointer or program counter-related bug. Single step and see where it hits? As a side note you should place the stack from 0x20000000 -> 0x2000xxxx. You don't want it to overflow into .bss.
  • You can turn on some of the debug logging options of QEMU with -d ('in_asm,int,exec,cpu,guest_errors,unimp' are probably a good set to start with), which will tell you what your guest code is doing. I would start by checking that your ELF file has a vector table in it at the place where QEMU expects to find it. Otherwise QEMU will hard fault immediately out of reset (which is what the hardware does).
  • The core dump is expected: QEMU goes into lockup, but we don't emulate lockup correctly (strictly speaking QEMU should just sit there doing nothing like the real hardware does), so we print a register dump and abort(). As I said in my previous comment, your problem is almost certainly that your binary doesn't have a vector table.
  • you are right i understand the issue now. I have defined the vector table half( only for the faults and systick but not the GPIOS and other peripherals which the code is expecting. I will define those as well in my .s file and generate the .bin file and check. Thanks Peter.
  • The main thing you must have in your vector table is the entries for the initial PC and stack pointer. The interrupt and exception entries are worth putting in but will only be needed if there is an interrupt or exception. If you put in debugging handlers for the other faults you'll at least know when you get a fault due to a bug in the rest of your program, though.
  • The issue was Reset handler was not being placed where CPU expected it to be. Worked without the ROM reset.