ARM Cortex-M & Cortex-A Embedded Development
From Cortex-M0+ bare metal to Cortex-A72 embedded Linux — ARM architecture engineered from the interrupt vector through the MMU to the application.
What We Build on This Platform
Cortex-M Bare Metal
Register-level peripheral control, NVIC configuration, SysTick, startup code, and linker script for Cortex-M0+ through M55.
Cortex-M RTOS
FreeRTOS, Zephyr, and ThreadX on Cortex-M with correct IRQ priority assignment and task stack configuration.
TrustZone-M
Secure and non-secure world partitioning, TF-M trusted firmware, and secure services on Cortex-M23, M33, and M55.
Cortex-M DSP & ML
CMSIS-DSP for signal processing, CMSIS-NN and TFLite Micro for edge AI inference on Cortex-M4 and M55 with Helium.
Cortex-A Linux BSP
Cortex-A Linux kernel configuration, device tree authoring, and kernel driver development for custom hardware.
Cortex-A AMP
Asymmetric multiprocessing with Cortex-M coprocessor alongside Cortex-A Linux host for combined real-time and OS applications.
MPU Configuration
Memory protection unit setup for fault isolation between RTOS tasks and protection against stack overflow into adjacent regions.
ARM Toolchain & Debug
GNU Arm Embedded, LLVM/Clang, JTAG/SWD debug, and CoreSight ETM trace for execution profiling.
How Ankh Uses This Platform
Core Class Selection
Cortex-M for real-time control, RTOS applications, and bare metal firmware. Cortex-A for embedded Linux, high-performance compute, and applications requiring MMU-backed virtual memory. Within Cortex-M: M0+ for cost and power minimisation, M4/M7 for FPU-intensive DSP and control, M33 for TrustZone security, M55 for Helium SIMD ML inference.
NVIC and Interrupt Architecture
Interrupt priority assigned from the real-time response requirement: hardware interrupt latency budget from peripheral event to ISR first instruction; interrupt priority grouping between preempt and sub-priority; interrupt nesting analysis for shared resources between ISRs at different priority levels; SysTick configuration for RTOS tick or precision timing.
CMSIS Driver and HAL
CMSIS-Core peripheral access for register-level driver development. CMSIS-Driver standardised peripheral interface for RTOS middleware compatibility. Vendor HAL evaluated and selectively adopted where the abstraction is acceptable, with direct register access where it is not. DMA configured for zero-copy peripheral transfer without CPU involvement.
TrustZone Architecture
Secure and non-secure memory map partitioned using the SAU and IDAU on M33/M55 targets. TrustZone-M firmware implemented using Trusted Firmware-M as the secure processing environment. Non-secure callable function definitions established for the API between secure and non-secure worlds. Secure key storage in TrustZone-protected memory.
Debug, Trace, and Optimisation
SWD and JTAG debug configured for the specific core. CoreSight ETM trace for execution tracing. ITM printf over SWO for non-intrusive debug. Performance profiling from DWT cycle counter. Code size optimisation for Cortex-M products with constrained flash. Cortex-A performance optimisation using perf and valgrind on embedded Linux.
Deep Technical Capability
NVIC Priority Assignment for Mixed Real-Time Firmware
The Cortex-M NVIC supports up to 240 external interrupt sources with configurable priority levels. The priority assignment for a complex real-time firmware is not arbitrary — it determines which interrupt can preempt which other interrupt, and whether a time-critical hardware event is serviced within its latency budget when other interrupt handlers are executing. A motor control firmware that runs a current control loop at 20kHz from a timer interrupt must not be preempted by the UART receive interrupt from a configuration interface that can tolerate 1ms latency — but must be preempted by the fault input interrupt whose response time determines whether the power electronics are protected within the shoot-through prevention window. Ankh assigns NVIC priorities from a formal interrupt latency budget: each interrupt source's maximum acceptable latency determines its priority level, and the assignment is verified by worst-case interrupt latency analysis before the firmware is deployed on hardware.
Cortex-M7 Cache Configuration for DMA and Cache Coherency
The Cortex-M7's separate instruction and data caches improve execution performance significantly over the cacheless Cortex-M4 — but introduce a cache coherency challenge for DMA operations. When the DMA engine writes to a memory region cached in the Cortex-M7's data cache, the cached copy and the DMA-written memory are inconsistent — and the processor that reads the cached copy reads stale data rather than the DMA-updated value. The correct handling requires either disabling caching for DMA buffer memory regions using the MPU, or explicitly invalidating the cache for the DMA buffer region before reading after a DMA transfer completes. Ankh configures Cortex-M7 cache and MPU regions from the first firmware design, not after discovering cache coherency bugs during system integration testing.
CMSIS-NN and TFLite Micro for Cortex-M Edge Inference
The Cortex-M55's Helium SIMD provides vectorised integer and floating-point operations that accelerate neural network inference by 4–15x compared to scalar Cortex-M4 implementations of the same operations. CMSIS-NN provides optimised convolution, pooling, and fully-connected layer kernels that use SIMD on Cortex-M4 and Helium on Cortex-M55. TFLite Micro delegates to CMSIS-NN for the optimised kernels. The inference performance on a specific model depends on the operator coverage in CMSIS-NN, the activation tensor alignment (CMSIS-NN requires 4-byte aligned tensor addresses for SIMD loads), and the weight tensor memory layout. Ankh characterises edge inference performance on the specific model and target core, identifying the memory layout and quantisation scheme that achieves the inference latency target at the required accuracy level.
Products Built on This Platform
Wearable Electronics
Cortex-M4F with FPU for IMU sensor fusion and BLE stack on Nordic nRF52840.
View ProductPatient Safety
Cortex-M4 for fall detection algorithm and BLE advertising on sub-50µA average current.
View ProductData Loggers
Cortex-M7 for 24-bit multi-channel ADC DMA acquisition with I/D cache coherency configuration.
View ProductStructural Monitoring
Cortex-M7 with hardware timer for GPS PPS sub-100ns edge capture.
View ProductMedical Devices
Cortex-M33 with TrustZone for secure patient data storage and cryptographic key protection.
View ProductRobotics & Drones
Cortex-A72 via Raspberry Pi CM4 running ROS2 alongside Cortex-M4 real-time motor control.
View ProductCMSIS is the architectural foundation, not a convenience library
Firmware that bypasses CMSIS and directly addresses vendor-specific register names produces code tied to one silicon vendor's header files — unmovable to a pin-compatible device without a full register-name search-and-replace across the codebase. CMSIS-Core's architecture-standard peripheral interface and CMSIS-Driver's peripheral abstraction together produce firmware portable at the abstraction boundary: the application layer calls the CMSIS-Driver USART interface regardless of whether the underlying hardware is an STM32 USART or a Nordic UARTE. Ankh builds firmware on CMSIS abstractions from the first driver implementation.
Startup code is not a copy from the vendor template
The Cortex-M startup code that runs before main() initialises the stack pointer, copies the .data section from flash to RAM, zeroes the .bss section, and configures the vector table offset register to point to the application's interrupt vector table. The vendor template startup code does these things correctly for the vendor's evaluation kit, which may have different flash and RAM layout from the custom hardware. A product with external PSRAM requires startup code that initialises the PSRAM controller before .data copy. Ankh writes startup code from the specific memory map of the custom hardware — not from the vendor template targeting the evaluation kit.
Hard fault debugging requires understanding the Cortex-M fault architecture
The hard fault handler that restores normal operation by resetting from a hard fault has solved the symptom but not the cause. The hard fault from a stack overflow into an adjacent task's stack region will recur at unpredictable intervals until the stack overflow is corrected. Ankh implements hard fault handlers that capture the faulting instruction address, the CFSR/HFSR/MMFAR/BFAR fault status registers, and the task context from the stacked exception frame — and reports these in a post-mortem log that identifies the specific cause of every hard fault in production firmware.