Resolution for past Cortex-M issues

[Kiron Sen]

Hi there,

I'm interested in using QEMU for Cortex-M microcontroller
applications. I found the QEMU support for STM32, Nordic nRF, MPS2/3
and Stellaris platforms with Cortex-M. I have some concerns about the
state of Cortex-M support in QEMU after coming across this thread
from 2016:
https://qemu-devel.nongnu.narkive.com/jL3tKvyB/arm-cortex-m-issues#post2

> Our M profile interrupt code is really badly mismodelled. It was
> written many years ago as a hack based on modifying the A profile
> support and GIC code, but really M profile is different (the
> interrupt and exception model is an integrated part of the CPU)...
> For M profile, NMI is just one of the many interrupt/exceptions; we
> don't really get it right because we're mis-modelling this with
> interrupts in an external interrupt controller and exceptions in the
> CPU model.

This led me to investigate the Pebble QEMU fork
(https://github.com/pebble/qemu) and the issues they ran into in 2015
bringing up an STM32F2:
https://web.archive.org/web/20161207161142/https://developer.pebble.com/blog/2015/01/30/Development-Of-The-Pebble-Emulator/

> The ARM processor has two operating modes (handler mode and thread
> mode) and two different stack pointers it can use (MSP and PSP). In
> handler mode, it always uses the MSP and in thread mode, it can use
> either one, depending on the setting of a bit in one of the control
> registers. It turns out there was a bug in the ARM emulation such
> that the control bit was being used to determine which stack pointer
> to use even when in handler mode.

The Pebble fork is based on QEMU 2.5.0 - I wasn't able to map
Pebble's fixes to the current state of QEMU 7.1.50 (other than the
BASEPRI fix in bug #696094). I was wondering if these problems have
been fixed and what the current state of Cortex-M support looks like.
Thank you!

Best,
Kiron