Does ARM assume that all Cortex-M microcontrollers are little-endian?

The short answer is yes, ARM does assume that all Cortex-M microcontrollers are little-endian by default. However, Cortex-M CPUs do have configuration options to enable big-endian data accesses if required by the system design.

Introduction to Endianness

Endianness refers to the byte ordering used to represent data in memory and during data transfers. There are two types:

• Little-endian – The least significant byte is stored at the lowest address.
• Big-endian – The most significant byte is stored at the lowest address.

For example, the 32-bit hexadecimal value 0x12345678 would be stored in memory as:

• Little-endian: 0x78 0x56 0x34 0x12
• Big-endian: 0x12 0x34 0x56 0x78

The endianness used by a processor architecture can affect how data is handled in memory and during data transfers. When interfacing components with different endianness, byte swapping may be required.

Cortex-M Microcontrollers are Little-Endian by Default

ARM designed the Cortex-M processor architecture to be little-endian by default for several reasons:

• Simplifies interfacing to little-endian systems and peripherals
• Makes bit endian-swapping unnecessary for bit-band accesses
• Provides consistency for compilers and debuggers
• Matches endianness of AHB/APB bus interfaces

The little-endian memory model better matches the endianness of common peripheral buses like AHB and APB used by Cortex-M microcontrollers. It also aligns with little-endian conventions of most compilers, debuggers, and emulators.

This provides a more seamless out-of-box experience for engineers integrating Cortex-M CPUs without having to worry about endianness mismatches.

Cortex-M Configuration Options

While Cortex-M defaults to little-endian, big-endian accesses can be enabled via configuration options if required:

• Set BIGEND configuration input pin to 1
• Set BIGEND signal to 1 via register interface
• Set big-endian data access at boot time

The processor also has byte-invariant options to handle accesses without any endianness conversion regardless of configuration.

So in summary, ARM assumes Cortex-M uses little-endian by default for maximum compatibility. But options exist to enable big-endian if needed by a particular system architecture.

Benefits of Little-Endian for Cortex-M

Let’s explore some of the benefits of using little-endian as the default byte ordering for Cortex-M CPUs:

Simpler Interface to External Components

Many peripheral buses and external components use little-endian byte ordering. Using little-endian by default on Cortex-M eliminates the need to swap bytes for data transfers.

For example, AHB and ABP buses are natively little-endian. Interfacing external memories, peripherals, and other components is straightforward without endian conversion.

Easier Integration with Tools and Software

Most compiler toolchains, debuggers, and emulators assume little-endian target processors. Little-endian simplifies integration of Cortex-M microcontrollers with these essential tools.

Software developers can compile code without byte swapping data or insert special directives. Debugging and trace capture also works seamlessly out-of-box with little-endian Cortex-M targets.

Consistent Bit Band Memory Accesses

The Cortex-M architecture provides bit band regions that map single bit addresses to full 32-bit words. With little-endian, bit band accesses do not require endian conversion.

Bit banding operates on the byte addresses matching the endianness of the processor. This avoids unnecessary read-modify-write sequences to manipulate bit band mapped memory.

Aligns with ARM A-Profile Architectures

ARM’s A-profile architectures like Cortex-A and Cortex-R assume little-endian operation. While Cortex-M targets different applications, maintaining little-endian aligns the family of ARM processor architectures.

This consistency across product families reduces confusion for engineers learning the ARM ecosystem. Common tools and software can be leveraged across little-endian ARM architectures.

Use Cases Requiring Big-Endian Operation

While Cortex-M microcontrollers operate in little-endian mode by default, big-endian operation may be necessary in some use cases:

Interfacing Big-Endian Components

Some peripheral devices and external memories are natively big-endian. For example, certain image processing components or networking gear designed for big-endian systems.

By configuring the Cortex-M CPU for big-endian accesses, byte-swapping is avoided when interfacing with these components.

Leveraging Existing Big-Endian Software

In some applications, existing firmware may be developed assuming big-endian data. Rather than porting the software, the Cortex-M CPU can be configured for big-endian operation.

This allows re-using proven big-endian firmware stacks. The software runs unchanged without modification or byte-swapping hooks.

Matching Higher-Level Architectures

In advanced multi-core designs, Cortex-M processors may be used alongside big-endian ARM cores. For consistency in the system, the Cortex-M CPU may need to also use big-endian.

This ensures uniform endianness conventions across the different CPU architectures in the system.

Conclusion

In summary, ARM assumes Cortex-M microcontrollers operate in little-endian mode by default for broad hardware and software compatibility. But big-endian data accesses can be enabled via configuration options if required by the target application.

Little-endian mode is selected as the Cortex-M default because it matches common microcontroller bus architectures and toolchain conventions. This simplifies integration out-of-box without endian conversion logic.

However, Cortex-M maintains flexibility to handle big-endian use cases as well. The architecture is designed to support either endianness model based on the requirements of the final system.

So in general, yes ARM assumes Cortex-M is little-endian. But enables big-endian when necessary.