Running firmware on qemu error - fatal: Lockup: can't escalate 3 to HardFault (current priority -1)

Question

I am trying to compile some c programs and run them on qemu on a 'lm3s6965evb' machine. More specifically, I am compiling c programs from WCET benchmark suite with the following commands:

arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -c program.c -o program.o arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -specs=nosys.specs -o program.elf program.o

and then running the .elf file with qemu: qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -kernel program.elf

The last command gives me the following output:

Timer with period zero, disabling 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=464c4558 R14=fffffff9 R15=00000000 XPSR=40000003 -Z-- A handler FPSCR: 00000000 Aborted (core dumped)

I can't understand what is missing or what to do in order to fix this.

I have also tried converting .elf to binary with: arm-none-eabi-objcopy -O binary program.elf program.bin

or running this command: arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -specs=nosys.specs -Wall -g -O2 -fno-builtin -fomit-frame-pointer -o program.elf program.c

Also, I have used readelf -a adpcm.elf in order to inspect the .elf file but can't see anything wrong.

Answer 1

Your program has crashed very early in startup. In particular it is super suspicious that the reported PC value is 0. Check that:

• your linker script is linking the program to the correct address (i.e. somewhere where the specific board model you are running it on has RAM)
• you have provided a vector table at the right address for that board, and that it has a correct initial PC and SP value in it

You should also look at one of:

• using QEMU's gdbstub to see what the guest program is doing
• using the various debug log output options under the '-d' option to get more information on what the guest program is doing

(Watch out that some of the -d options produce a lot of output and also slow execution a lot, but they're handy for debugging bare metal binary startup. There's a -D option for directing this output to a logfile.)

You also will very likely want to have some sort of assembly startup code -- don't expect to be able to just tell the C compiler "build me a binary" and have it run from startup on a bare metal system. You'll also need to check what the C runtime is expecting (e.g. where does "printf" output go?). That seems to be entirely missing from your setup at the moment.