A Simple Interpretation of Cortex-M23/33 (Part 1)

Click the card below to follow Arm Technology Academy

This article is selected from the Extreme Technology column “Bare Metal Thinking”, authorized to be reprinted from the WeChat public accountBare Metal Thinking. This article will help you better understand the Cortex-M23/33 processors, and this is the first part.

First, a word in advance

Since Arm released two new processors, Cortex-M23 and Cortex-M33, based on the Armv8-M architecture in October 2016, more than three years have passed, and microcontroller products based on these two processors have just emerged.

Many students who have just become familiar with Cortex-M0/M0+/M3/M4 processors through development boards may have a barrage of questions in their minds:

Who the hell told me what this M23 and M33 is?

How did we jump from single digits to double digits all of a sudden!

What happened to the previous ten brothers?

Don’t tell me it has anything to do with M3, does that mean the next generation will be called 2333333?

What comes will come, so how can we simply and brutally understand these two brand new processors? Here is a no-responsibility formula provided exclusively by the silly kids:

Cortex-M23 =

Cortex-M0/M0 + hardware divider + performance improvement +

Dedicated stack overflow hardware detection +

Insignificant little actions in the instruction set +

Security extension (TrustZone for Armv8-M) +

Friendly improvements in the MPU developer model

Cortex-M33 =

Cortex-M3/M4 + performance improvement +

Dedicated stack overflow hardware detection +

Insignificant little actions in the instruction set +

Security extension (TrustZone for Armv8-M) +

Friendly improvements in the MPU developer model

Simply put, it means an invincible enhanced version of “M0/M0+, M3/M4” plus “security extension”. Some say that the main function of Armv8-M is to introduce TrustZone to the Cortex-M family, which seems reasonable.

1.1 Enhanced Cortex-M0/M0+

According to official statements, the Cortex-M23 implements the Baseline sub-architecture of the Armv8-M architecture, which we can understand as the “entry-level” product in mobile phones.

Note: Image from ARM official website

The positioning of Cortex-M23 is also very straightforward: it adds a security extension to Cortex-M0/M0+. Therefore, in fact, all binary codes compiled and generated for Cortex-M0/M0+ can basically run on Cortex-M23/M33 “without modification”—unless your original code used the MPU. In addition, Cortex-M23 surprisingly comes with a hardware divider, which undoubtedly raises the “basic configuration” to another level in the 8-bit/16-bit market originally dominated by Cortex-M0 and Cortex-M0+.

In terms of the instruction set, Cortex-M23 inherits from Armv6-M. In addition to supporting a series of instructions necessary for the “security extension,” this entry-level product also makes an “insignificant little action”—that is, apart from Cortex-M33, Cortex-M23 can also support “eXecute Only Memory (XOM)” with very little cost.

What is dark code? Similar to “dark matter,” which can only be theoretically known to exist but is difficult to detect—“dark code” is a type of program that can only be executed by the processor (fetch instructions) but cannot be read in any form (OPCODE) at all—that is, the so-called XO (eXecute-Only) code. “Dark code” is not implemented by the kernel, but requires the compiler and kernel to work together to support it. This is because XOM is essentially a special area defined by the chip manufacturer in the address space—only the processor can fetch instructions for code execution (Instruction Fetch), and ordinary data access (Data Access) cannot be performed. This means that “dark code” cannot directly store any constants—they must be encoded into the instructions—existing as part of the instruction in the form of immediate numbers.

The instruction set of Armv6-M mostly consists of 16-bit Thumb instructions, and the binary length of the immediate numbers that can be encoded by the 16-bit instructions is understandably quite limited. Armv7-M introduced the 32-bit Thumb2 instruction set, greatly enhancing the ability of instructions to carry immediate numbers. To introduce this capability into the Armv8-M Baseline instruction set, two instructions, MOVT and MOVW, which can carry 32-bit immediate numbers “high and low 16 bits,” were specially added to the instruction set used by Cortex-M23. Considering the strong information security of Armv8-M, the weight of “dark instructions” in protecting firmware is quite significant.

Conclusion: Cortex-M23—this M0+ is not simple.

1.2 Enhanced Cortex-M3/M4

Compared to Cortex-M3/M4, the performance improvement of Cortex-M33 is not surprising at all, so there’s no need to mention it. It’s worth noting that the Cortex-M7, which came from the city, can still “outperform other Cortex-M processors by several streets” in terms of performance—the difference between a 6-stage pipeline and a 3-stage pipeline is not comparable to the gap between a three-cylinder Chery and a six-cylinder BMW! (serious face).

Note: Image from ARM official website

1.3 ARMv8-M is a good student who corrects mistakes

I don’t know how many people have really used the MPU of Armv7-M, which is Cortex-M3/M4—a system-level peripheral that modifies memory attributes on a region basis. The original design was very simple: define a region, set a size (Size), set a base address (Base Address), give it an attribute (Memory Attribute), and enable it, and it works—very simple, very happy. However, due to the optimization of the core area, a limitation was artificially added to the setting of the region address range:

The base address (Base Address) must be aligned with its size (Size), and the size must be a power of 2 (and must be greater than 4).

For example: if a region size is 512K, then the base address must be a multiple of 512K… If you still can’t understand where the painful point of this problem lies, consider how to set a region of arbitrary size, for example, how to handle a 234K sized memory?—what else can be done but combine multiple regions.It is precisely this painful limitation that has led to almost no RTOS being able to use the MPU well, and very few projects around me have applied the MPU as ideally as one would hope.

So what did Armv8-M do? It corrected this painful setting: the setting of the region evolved from “base address + size” to “starting address + ending address”. Apart from the requirement that both addresses must be multiples of 32 bytes, there are no more bizarre restrictions like “the base address must be a multiple of the region size.” Isn’t it suddenly enlightening, and isn’t it like discovering a treasure? The MPU suddenly becomes fun.

Conclusion: The MPU of ARMv8-M is a good comrade, and one should treat him differently after three days.

1.4 How to Simply Understand the Security Extension (Trust Zone for ARMv8-M)?

Stay tuned for the next episode.

Recommended Reading

• Summary of multi-clock domain processing methods in IC design

• Allocation methods of multi-layer caches in CPU

• Factors to consider in IP-based design in SoC

Follow Arm Technology Academy