STAR-MC1¶

Introduction¶

STAR-MC1 is an Arm China CPU IP based on Armv8-M Mainline, the architecture profile also used by Cortex-M33. This provides a familiar Armv8-M software model, but does not guarantee that Cortex-M33 firmware can be reused unchanged. Optional architecture extensions, core configuration, SoC peripherals, startup and linker setup, and SDK support can differ. Treat Cortex-M33-targeted software as a porting starting point and validate it on the target device and SDK.

On SF32 devices that use STAR-MC1, SiFli documentation may identify the application CPU as Arm Cortex-M33, Cortex-M33 STAR-MC1, or simply STAR-MC1, depending on context and level of detail. These labels do not, by themselves, confirm optional core features or the exact SoC configuration; check the exact device documentation before selecting a part.

Read this page when you know the Arm Cortex-M family and need to position STAR-MC1 correctly for software, performance, or part selection. It explains what remains familiar, what can differ by SoC implementation, and why STAR-MC1 should not be treated as a fixed Cortex-M7 replacement.

Here, compatibility refers to the shared Armv8-M architectural software model, not to a drop-in firmware image. Check the selected core features, compiler options, startup code, linker layout, interrupt assignments, peripheral drivers and security configuration against the target SoC and SDK before reusing firmware.

Positioning for Developers¶

The most useful mental model is not “a fixed processor between Cortex-M33 and Cortex-M7.” STAR-MC1 is a configurable, Cortex-M33-compatible Armv8-M Mainline CPU IP. Its value is the ability to pair that familiar MCU software model with optional memory-system and acceleration features—such as cache, tightly coupled memory (TCM), DSP instructions, a coprocessor interface, and TrustZone—when the final SoC implements them.

For an SF32 project, select the device for its documented memory, peripherals, and SDK support—not for the STAR-MC1 label alone. The public STAR-MC1 material describes Armv8-M and identifies cache, TCM, DSP, coprocessor interfaces, and TrustZone as possible features. Whether a feature is implemented and enabled in a particular product must be confirmed in the SoC documentation.

Why STAR-MC1 Matters¶

Traditional Cortex-M33 MCUs are excellent for secure, low-power embedded control, but modern connected products often need more than control logic. Wearables, smart displays, Bluetooth audio products, and edge-AI devices may also need responsive user interfaces, larger external memory, signal processing, and frequent movement of graphics or audio data.

STAR-MC1 can address these workloads through optional caches, TCM and custom instructions when the SoC implements them and the software uses them effectively. These features can reduce memory stalls or accelerate selected operations while retaining the MCU development model. Confirm the performance and energy benefit on the finished device with representative workloads; neither follows automatically from the core name.

Cortex-M Family Comparison¶

The following table summarizes where STAR-MC1 fits among common Cortex-M processors. Exact capabilities depend on the final SoC implementation, but the positioning is useful when choosing an architecture for a product.

For compactness, the table uses CM3, CM4, CM33, CM55, and CM7 for the corresponding Cortex-M processors.

* These reference figures come from Arm's Cortex-M comparison table, Version 2020. They are not universal current scores or a direct ranking of finished SoCs: compiler, memory system, cache settings and benchmark configuration affect the result.

† STAR-MC1 uses the CM33 reference figure here because it is CM33-compatible. This is a comparison baseline, not an Arm-published or measured STAR-MC1 result.

‡ This is an architectural positioning guide, not measured silicon data. Actual power depends on process technology, voltage, frequency, memory architecture, enabled features, peripherals, firmware duty cycle, and the final SoC implementation.

The pipeline and bus rows summarize each IP's main execution pipeline and system-memory interface. CM33 and STAR-MC1 share the C-AHB/S-AHB bus arrangement; cache and other optional memory features are separate from that bus interface, and their availability depends on SoC configuration and implementation. These are not a statement of the interfaces enabled on every finished SoC. Debug, trace, coprocessor, and other optional ports are not listed.

Processor-IP references: Arm CM3 datasheet, CM4 documentation, CM33 Technical Reference Manual, CM55 datasheet, CM7 datasheet, and the STAR-MC1 Technical Reference Manual.

Architectural Enhancements¶

STAR-MC1 builds on Cortex-M33 rather than replacing it. The most important additions are implementation-level improvements that help the core spend less time waiting on memory and more time executing useful work.

Instruction and Data Caches¶

Availability and configuration of the instruction cache (I-cache) and data cache (D-cache) depend on the SoC implementation. When implemented and enabled, these caches are especially valuable in systems that execute from external Flash, access PSRAM, or run larger user-interface and middleware stacks.

The main benefits are:

• Faster instruction fetch from non-SRAM memory.
• Lower average data access latency.
• Better performance for graphics, audio, protocol stacks, and UI frameworks.
• Reduced pressure on the memory bus when the same code or data is reused.

For cacheable buffers that hardware does not keep coherent, drivers sharing memory with DMA, display controllers, audio interfaces, or other bus masters must follow the SDK or RTOS cache-maintenance rules. Clean CPU-written data before a peripheral reads it; prepare receive buffers before DMA writes, then invalidate stale cache lines after transfer completion and before CPU reads. The CPU must not access a buffer while DMA owns it. Allocate whole cache lines without sharing them with unrelated data, and follow platform completion checks and memory barriers. Non-cacheable or hardware-coherent buffers still require their platform's synchronization rules. See PSRAM and memory types for buffer ownership and dirty-line hazards.

Armv8-M Custom Datapath Extension¶

At the IP level, Arm defines the CDE instruction encodings, while the SoC designer defines the custom operations and datapaths. CM33 supports optional integer CDE; floating-point CDE depends on the FPU and configuration. The STAR-MC1 TRM describes GPR CDE and FPCDE modules, but this IP-level description does not establish that CDE is available in a particular SF32 device or SDK. The SiFli SDK v2.5.1 release notes record a fix for CDE being enabled by mistake on SF32LB57x; verify support for the exact target and SDK before relying on it. CM55 offers optional CDE from r1 onward, not r0. CP0–CP7 are encoding spaces assigned to coprocessors or CDE; they do not mean eight custom instructions or eight additional accelerators. Confirm the core revision, implemented modules, and compiler/SDK support. See the CM33 datasheet, CM55 CDE revision notes, and STAR-MC1 TRM Chapters B7/B8.

This can be useful for workloads such as:

• Digital signal processing.
• Cryptography.
• Computer vision primitives.
• Machine-learning kernels.
• Sensor-fusion math.

CDE does not automatically accelerate every application. Software must use compiler support, libraries, or vendor-provided SDK components that emit the relevant custom instructions. When supported by the SoC and software stack, however, it provides a clean path for application-specific acceleration without moving the workload to a separate application processor.

Memory-System Optimization¶

Many modern MCU workloads are limited not only by CPU frequency, but also by memory latency and bandwidth. STAR-MC1's memory-system design and any cache features implemented and enabled by the SoC are therefore important for SF32-class devices, where applications may combine internal SRAM, in-package Flash, PSRAM, display buffers, and peripheral DMA.

The largest gains usually appear when:

• Code executes from Flash or external memory instead of tightly coupled SRAM.
• UI frameworks repeatedly access image, font, or layout data.
• Audio, Bluetooth, graphics, and application tasks run concurrently.
• The working set fits well in cache.

Purely CPU-bound loops that already run from fast SRAM may show a smaller improvement.

Performance Characteristics¶

STAR-MC1 should not be described as automatically improving small synthetic CPU benchmark metrics such as CoreMark/MHz or DMIPS/MHz. Those benchmarks primarily measure compact integer workloads and are often small enough to run from fast local memory. In that situation, instruction and data caches may provide little or no visible improvement over a standard Cortex-M33-class implementation.

STAR-MC1 is a Cortex-M33-compatible core with a configurable memory subsystem and optional workload-specific acceleration. These features can help when an application is limited by memory access, external Flash or PSRAM latency, graphics resources, protocol stacks, or repeated access to larger code and data sets. The benefit depends on the implemented features and how the application uses them.

What This Means for SF32 Developers¶

For SF32 firmware development, treat STAR-MC1 as a Cortex-M33-compatible application processor. Evaluate the implemented memory and acceleration features against the application's code, data and timing requirements.

In practice:

• Treat Cortex-M33 firmware as a source-level porting baseline, not a drop-in image; confirm the target configuration and SDK support before reusing it.
• RTOS, interrupt, privilege, TrustZone, and debug concepts remain familiar to Cortex-M developers.
• Performance-sensitive applications should place critical code and data carefully and use the SDK's cache and memory APIs.
• Cacheable DMA buffers need explicit cache maintenance when hardware does not guarantee coherence; all DMA buffers need safe ownership and synchronization.
• Graphics, audio, AI, and connectivity workloads benefit most when the software stack uses the SoC's hardware accelerators and memory hierarchy effectively.

The core is not intended to replace every Cortex-M7 use case. If an application requires maximum single-core throughput at higher power, Cortex-M7-class devices may still be appropriate. For battery-powered connected products, however, STAR-MC1 provides a useful balance of compatibility, performance, and energy efficiency.

Good Application Fits¶

STAR-MC1-based devices are candidates for products that need memory-system or application-specific acceleration while retaining MCU-level power and integration constraints. They are particularly worth evaluating when memory latency matters more than a compact CoreMark/DMIPS score. Select the actual SoC by its implemented features and measured workload performance, not an assumed advantage over every conventional Cortex-M33.

Typical examples include:

• Smartwatches and fitness trackers.
• Bluetooth audio devices.
• Wearable medical and health-monitoring products.
• Smart displays and compact HMI systems.
• Edge-AI sensor devices.
• Products using LVGL or other embedded UI frameworks.
• Devices that execute from large Flash or PSRAM memories.

Key Takeaways¶

• STAR-MC1 is Cortex-M33-compatible, so it preserves the familiar Armv8-M embedded software model.
• When the SoC enables instruction and data caches, they can improve real-world performance, especially when code and data live outside fast internal SRAM.
• CDE provides a path for custom instruction acceleration when supported by the SoC and software stack.
• STAR-MC1 combines a CM33-compatible software model with configurable memory and acceleration features; compare finished SoCs and measured workloads, not core labels alone.
• On SF32 devices that use STAR-MC1, the core and the SoC features implemented alongside it can support richer graphics, audio, AIoT, and wearable applications within an MCU-style development model.

See also: SF32 Family Overview for how STAR-MC1 fits into the broader SF32LB5x chip lineup.

Primary reference: Arm China STAR-MC1 Technical Reference Manual.

Last updated: 2026-10-10