rawsample
commented
2 years ago Hello,
Thank for reporting these issues, I confirm I can reproduce them.
About the nucleo_L152RE, it looks like during the transfer_state() the CPSR register is not properly synchronized within the emulator which leads to an inconsistent state and the bug you see.
$ cat QemuTarget0_err.txt
qemu: fatal: Lockup: can't take terminal derived exception (original exception priority -1)
R00=20000590 R01=20014000 R02=00000001 R03=00000001
R04=00000000 R05=00000000 R06=00000000 R07=080063c7
R08=00000000 R09=00000000 R10=080063e8 R11=080063e8
R12=00000001 R13=20013fe0 R14=0800026f R15=08002cac
XPSR=40000000 -Z-- A priv-thread
FPSCR: 00000000While waiting for a fix, you can replace the QemuTarget with PandaTarget within the example, it should work correctly.
For the u-boot example, the issue seems to be related to the versatilepb board used by the target_runner between versions 4.2 and 5.1. Even vanilla QEMU is affected.
In the meantime we find the exact cause, you can use a different QEMU version < 4.2 for the target_runner by editing the executable path at line 34 but keep avatar-qemu for the QemuTarget.
Hi,
Running the nucleo_l152re example with avatar qemu @branches dev/qemu-6.2 or dev/qemu-5.1 we face a crash issue of qemu. It’s like the registers and ram synchronizations are ok between the board and the qemu. The crash happens just after the synchronization, when doing continue in qemu.
Starting from the trace “terminal derived exception” and debugging a bit we see that there is a call to abort inside do_armv7m_nvic_set_pending resulting from an arm_v7m_cpu_do_interrupt.
Please find attach 2 call stacks obtained from a gdb instance attached to qemu.
It’s like the vector table is not correct (probably an issue with the configurable machine ?). Any clue to fix the issue ?
Has it been validated with the latest qemu versions ?
It ‘s like the latest qemu versions from /dev/qemu-6.2 branch has also some troubles with u-boot example.
qemu_crash.txt qemu_crash1.txt