Whitepaper - ARMv8-M Architecture Technical Overview

The next generation of ARM® Cortex®-M processors will be powered by a new architecture version called ARMv8-M architecture. This document provides a technical overview of various enhancements in the new architecture, as well as an introduction to the security technology, called TrustZone® for ARMv8-M. This document also introduces AMBA® 5 AHB5 which enables security management at a system level, and covers various use cases of the new technology.

ARMv8-M TrustZone small.jpg

ARMv8-M Architecture

Information on ARMv8-M and TrustZone

Cortex-M23 and Cortex-M33 processors information

Resources for software developers




  to the ARMv8‑M Architecture Version 1.1


  technology for ARMv8‑M Architecture Version 1.1

ARM C Language Extension (ACLE)

  Extensions for ARMv8‑M Version 1.0

Secure software

  software guidelines for ARMv8‑M based platforms Version 1.0

Exceptions and Interrupts

  Exception Handling Version 1.0

Fault exception

  Handling and Detection Version 1.1

Power management and sleep modes

  processor power management secure state protection Version 1.0


  Processor Debug Version 1.0


  Protection Unit for ARMv8‑M based platforms Version 1.1


  design considerations for ARMv8‑M based platforms Version 1.1

ARMv8-M software development with ARM Compiler 6

  9 : Building Secure and Non-secure Images Using ARMv8-M Security Extensions

Security extension details for compiler vendors

  Security Extension: Requirements on Development Tools

Resources for silicon designers

Whitepaper - ARMv8-M Architecture Technical Overview.pdf
  • Great new enhancements. Esp. the new MPU feature.

    But again something missing: Why add the stack limit register only to the secure side. Any RTOS/Application would benefit from such also in the normal world.

    The MPU is no option here.

    So hopefully ARMv8.1-M will add this ...

  • This is very helpful document.

    I have a question.

    Is  the XOM area configured by MPU?

  • Hi,

    The ARMv8-M baseline architecture is designed for ultra low power and area constrainted designs, with a certain low power target. As a result the designer has to make some tradeoff between functionalities and the power/area, and therefore the stack limit is omitted from current architecture definition.  You are correct that this function is useful for Non-Secure RTOS as well, so we will revisit this in the future.

    On the Secure side stack limit check is essential to prevent stack overflow which could end up leaking Secure information into Non-Secure world (depending on layout of memory contents).

    For ARMv8-M mainline stack limit feature is available to both Secure and Non-Secure sides.



  • Hi,

    The XOM technique does not require MPU feature. (Do not confuse it with exeucte never "XN" memory attribute which is configurable by MPU).

    XOM requires the memory interface hardware to ignore data accesses (including debug access). This can be done by filtering out data transfers by checking a bus sideband signal (e.g. HPROT[0] in AHB/AHB5), or in the case for Cortex-M3/M4, connecting XOM only to I-CODE bus.



  • For ARMv8-M mainline stack limit feature is available to both Secure and Non-Secure sides.


  • Hello Joseph Yiu,

    thank you for the explanation.

    But It sounds that XOM will be an implementation matter.

    I would like to know the relationship Between XOM and ARMv8-M.

    I think that XOM is one of ARMv8-M features.

    Are there some registers which specify the XOM address range?

    Best regards,

    Yasuhiko Koumoto.

  • Hi,

    XOM is not exactly an architecture feature. But in ARMv8-M we made it easier to handler XOM in software.

    Previously in ARMv6-M, using XOM technique is inefficient for software because MOVW and MOVT are not available. In ARMv8-M these two instructions are available for both Mainline and Baseline, so the same firmware protection techniques can be used.

    The address range for XOM is defined by chip designers.



  • Hello Joeph Yiu,

    thank you very much for the detailed explanation.

    I understood well.

    Best regards,

    Yasuhiko Koumoto.

  • If I understand this right then it is possible for a non-secure side interrupt to interrupt the secure side and then call back to the secure side again. So it is fairly essential that there be a stack limit on the secure side as that could happen multiple times. I can see that happening okay by mistake or if the non-secure side is compromised. Is it envisaged that there will sometimes actually be more than one call from the non-secure side to the secure side outstanding in some circumstances, e.g. if an interrupt needs to check something?

  • Hi,

    Yes, you are right that Secure code can be interrupted by a Non-Secure interrupt. That is a key unique feature of ARMv8-M as it enables very low interrupt latency for peripherals, even when the processor is executing Secure code.

    And yes, it is possible that Non-Secure ISR then call Secure code again, or a Secure interrupt can also trigger during Non-Secure code. Potentially multiple levels of interrupt ISR from Secure and Non-Secure state can nested together and this is perfectly fine for ARMv8-M operations.  Normally we assume that Secure software should allocated enough memory space in the Secure main stack so that it can cope with such interrupt nesting and function calls.  However, there are cases that Secure software developers cannot foreseen and therefore both ARMv8-M baseline and mainline provide stack limit checking on Secure side. If the stack point go over a certain limit (specified by a programmable register), a Secure Usage Fault/HardFault will trigger and Secure software can then handle it properly. Therefore the peripheral ISRs do not require special modifications to include this checking.



  • That's a Really good whitepaper ! Good Job

  • Hello Joseph Yiu,

    I am re-reading the ARMv8-M Architecture Technical Overview and became to have question. Can you help me?
    In the document, the context stacking of FPU is described only one case.
    That is,

    In the case that Secure software does use the FPU and Non-Secure interrupt handler does not use FPU, the stacking and unstacking of FPU registers are skipped to provide a faster interrupt handling sequence.

    How about the following cases.
    1) Secure software & Non-Secure interrupt DOES use FPU.
    2) Non-ecure software & Non-Secure interrupt DOES use FPU.
    3) Secure software & Secure interrupt DOES use FPU.
    4) Non-ecure software & Secure interrupt DOES use FPU.

    Regarding 1), does the lazy stacking occur?
    If it does, how are the Secure contexts protected?
    Regarding 2), 3) and 4), I think there would be no problems if the lazy stacking will occur.

    Thank you and best regards,
    Yasuhiko Koumoto.

  • That statement in the Overview is more a description about the intent and effect rather than anything about the mechanism. The ARMv8-M Architecture Reference Manual goes into more detail - and the bits about what happens to the floating point registers with lazy stacking do not make for easy reading.

    As far as I can make out and assuming the secure state has used floating point then on a non-secure interrupt with lazy stacking enabled:-

    Space is left on the secure stack for all the floating point registers, not just s0-s15 and a lazy saving state bit is set and  a bit saying the floating point has been used cleared.

    The interrupt routine is entered

    If the interrupt routine does not use floating point then on return the floating point registers need never have been saved and they are certainly not restored - the bits will be set saying lazy saving not in use and floating point registers have been used just like it was before the interrupt.

    if the interrupt routine uses floating point then the processor will ensure that all the registers are saved on the secure stack and the lazy saving state ended and mark that floating point registers have been used. All the floating point registers will be zeroed before first use in the interrupt.. On return it will see that floating point has been used and will restore the floating point registers from the stack.

    The strong imperative they had was to ensure floating point use in secure state does not slow down interrupts which don't use floating point What they came up with should be easy to use and ensure security by not leaking floating point register values - it is most certainly not trivial though and I bet they've had to really sweat over checking it all out..

  • Hello daith ,

    thank you for your detailed reply.

    I understood your comments as that the FPU lazy stacking was always enabled, and the stacking (if needed) would be done as the normal general registers. Also in the case of change from Secure to Non-Secure world, all the regsisters would be cleared.

    Is my understanding correct?

    Best regards,

    Yasuhiko Koumoto.

  • I am not exactly sure what you mean. The state of the stack after an exception for various combinations of secure and non-secure state or floating point are shown in section B4.20 of the ARMv8-M Architecture Reference manual

    Lazy stacking only applies to the floating point registers. If an exception occurs in secure state taking it to a non-secure state then all the general registers are saved and zeroed, and then restored on return to secure state.