This bug was fixed in QEMU 2.9 as part of the rewrite of M profile
exception handling.
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1353346
Title:
ARMv7-M software-triggered interrupts-- unexpected behaviour
Status in QEMU:
Fix Released
Bug description:
The handling of the NVIC "Software Triggered Interrupt Register" in
qemu-2.1.0/hw/intc/armv7m_nvic.c:375 isn't quite right. As things
stand, writing a zero to the STIR ends up transferring control to
vector table entry zero, which, on ARMv7-M, holds the reset value of
the stack pointer. That's what I see with lm3s811evb emulation, and
that's not what happens on my STM NUCLEO-F103RB board (Cortex-M3).
Seems like an oversight-- the handler probably wants
armv7m_nvic_set_pending(), not gic_set_pending_private(), and the IRQ
number needs 16 added onto it to get the exception number for the
interrupt.
ARM DUI 0552A (Cortex-M3 Devices: Generic User's Guide), p. 134:
"Interrupt ID of the interrupt to trigger, in the range 0-239. For example,
a value of 0x03 specifies interrupt IRQ3."
Cheers,
Boris
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1353346/+subscriptions
