CMSIS Part 8: CMSIS-Pack & Software Component Management

Device Support Packs

Device support packs (also called Device Family Packs, or DFPs) are the most fundamental category. Every MCU you target should have an associated DFP installed. The DFP gives your toolchain everything it needs to compile, link, flash, and debug firmware for that specific device family.

SVD Files & Auto-Generated Headers

The SVD (System View Description) file is arguably the most important artifact in a device pack. It is an XML file that precisely describes every peripheral register in the device — its address, bit fields, reset values, and access permissions. SVD files serve two critical purposes.

First, debuggers like OpenOCD, pyOCD, and J-Link use the SVD file to render a live peripheral register view in the IDE — so you can see GPIOA->ODR = 0x0020 instead of a raw hex value at address 0x40020014. Second, the SVD file is the source from which vendor device headers (like stm32f407xx.h) are auto-generated using tools like svd2rust (for Rust) or SVD conversion scripts for C.

/* Fragment of auto-generated stm32f407xx.h — derived from SVD */

/* =========================================================== */
/* ====                       GPIOA                      ==== */
/* =========================================================== */
typedef struct {
  __IOM uint32_t MODER;    /*!< 0x000: GPIO port mode register            */
  __IOM uint32_t OTYPER;   /*!< 0x004: GPIO port output type register     */
  __IOM uint32_t OSPEEDR;  /*!< 0x008: GPIO port output speed register    */
  __IOM uint32_t PUPDR;    /*!< 0x00C: GPIO port pull-up/pull-down reg    */
  __IM  uint32_t IDR;      /*!< 0x010: GPIO port input data register      */
  __IOM uint32_t ODR;      /*!< 0x014: GPIO port output data register     */
  __OM  uint32_t BSRR;     /*!< 0x018: GPIO port bit set/reset register   */
  __IOM uint32_t LCKR;     /*!< 0x01C: GPIO port configuration lock reg   */
  __IOM uint32_t AFR[2];   /*!< 0x020: GPIO alternate function registers  */
} GPIO_TypeDef;

/* Base addresses from SVD <addressBlock> elements */
#define GPIOA_BASE   (AHB1PERIPH_BASE + 0x0000UL)
#define GPIOA        ((GPIO_TypeDef *) GPIOA_BASE)

/* Bit-field macros (position and mask) auto-generated from SVD <field> */
#define GPIO_MODER_MODER5_Pos   (10U)
#define GPIO_MODER_MODER5_Msk   (0x3UL << GPIO_MODER_MODER5_Pos)
#define GPIO_BSRR_BS5_Pos       (5U)
#define GPIO_BSRR_BS5_Msk       (0x1UL << GPIO_BSRR_BS5_Pos)
#define GPIO_BSRR_BS5           GPIO_BSRR_BS5_Msk

Startup Code & Linker Scripts

Device packs also include startup assembly files and linker script templates. The startup file (startup_stm32f407xx.s) contains the vector table, the reset handler that copies .data from flash to RAM and zeroes .bss, and weak default handlers for every interrupt. The linker script defines the memory regions and the section placement rules that the startup file depends on.

These files are provided as templates — you copy them into your project and modify them for your specific memory configuration. The pack manager copies them to your project's source tree when you select the Device:Startup component.

Software Component Categories

CMSIS-Pack defines a standardised taxonomy for software components. Every component is identified by a three-part identifier: Cclass::Cgroup:Csub. The Cclass is the high-level category, Cgroup is the functional group within that class, and the optional Csub identifies a variant.

For example: CMSIS::RTOS2:Keil RTX5 means — the CMSIS class, the RTOS2 group, the Keil RTX5 implementation variant. This taxonomy allows multiple implementations of the same interface to co-exist in the pack ecosystem, with the developer choosing one at project configuration time.

Selecting Components

When you select a software component — either via a tool like Keil MDK's component manager or the command-line cbuild workflow — the pack manager performs three actions. It resolves all dependency declarations from the PDSC, copies any configuration files to your project's RTE/ (Run-Time Environment) directory, and adds the component's source files and include paths to your build system.

Configuration Files

Configuration files are the key conceptual difference between CMSIS-Pack and a simple header-only library. When a component requires configuration — for example, FreeRTOSConfig.h or USBD_Config.h — the pack manager copies a pre-configured template of that file into your project's RTE/ directory. You then edit your local copy. Subsequent pack updates will not overwrite your customised configuration file — only new component additions trigger a fresh template copy.

Dependency Management

One of CMSIS-Pack's most valuable features is automatic dependency resolution. When a software component depends on another — for example, a USB CDC device class requires CMSIS::Driver:USB Device and Device::Startup — the pack manager flags the missing dependencies and optionally resolves them automatically. This prevents the classic embedded project problem of mysterious compile errors because a middleware component was added without its required support layer.

Version Constraints

PDSC files express version constraints using a simple range syntax. A component can require ARM::CMSIS>=5.9.0 or Keil::STM32F4xx_DFP@2.17.1 (exact version pin). When the pack manager resolves the dependency graph, it checks all constraints against installed packs and reports conflicts. The cpackget CLI supports both minimum-version installs and exact-version pins:

# Update the pack index from all registered repositories
cpackget update-index

# Install the latest version of ARM::CMSIS
cpackget add ARM::CMSIS

# Install an exact version (for reproducible builds)
cpackget add ARM::CMSIS@6.1.0

# Install a device pack (vendor::packname)
cpackget add Keil::STM32F4xx_DFP@2.17.1

# Install FreeRTOS with CMSIS-RTOS2 wrapper
cpackget add ARM::CMSIS-FreeRTOS@10.5.1

# List all installed packs
cpackget list

# Remove a pack
cpackget remove Keil::STM32F4xx_DFP

# Show pack details (components, conditions, dependencies)
cpackget pack show Keil::STM32F4xx_DFP.2.17.1.pack

Validation & Conflict Resolution

The cbuild tool (part of the CMSIS-Toolbox) performs a full component validation before invoking the compiler. It checks that every selected component's conditions are satisfied — device match, core type, FPU presence, RTOS dependency. If a condition fails, it reports the specific unsatisfied requirement rather than a cryptic linker error later. This shifts dependency errors left to the configuration phase, saving significant debugging time.

Build Integration with CMake

The modern CMSIS-Toolbox workflow uses YAML-based project description files (.csolution.yml and .cproject.yml) rather than IDE project files. The cbuild tool reads these files, resolves packs, and generates a CMake project that you can build with any standard CMake-compatible toolchain.

cpackget CLI Tool

The complete CMSIS-Toolbox (including cpackget, cbuild, csolution) is available as a standalone binary for Linux, macOS, and Windows. It integrates with VS Code via the Keil Studio extension and runs entirely from the command line for CI/CD pipelines.

# ── CMSIS-Toolbox installation (Linux/macOS) ──────────────────────
# Download from: https://github.com/Open-CMSIS-Pack/cmsis-toolbox/releases
export PATH=$PATH:/opt/cmsis-toolbox/bin

# Initialise a new solution project
csolution create MyProject

# Project directory structure after init
# MyProject/
# ├── MyProject.csolution.yml    # Solution descriptor (top-level)
# ├── MyProject.cproject.yml     # Project descriptor (component selection)
# └── RTE/                       # Run-Time Environment (config files, generated)

# ── MyProject.cproject.yml (example) ─────────────────────────────
# project:
#   packs:
#     - pack: ARM::CMSIS@6.1.0
#     - pack: Keil::STM32F4xx_DFP@2.17.1
#     - pack: ARM::CMSIS-FreeRTOS@10.5.1
#   add-path:
#     - src/
#   components:
#     - component: ARM::CMSIS:Core
#     - component: Device::Startup
#     - component: ARM::CMSIS:RTOS2:Keil RTX5
#     - component: CMSIS::RTOS2:FreeRTOS Heap4
#   groups:
#     - group: App
#       files:
#         - file: src/main.c
#         - file: src/app_tasks.c

# Install all packs declared in the solution
cbuild setup MyProject.csolution.yml --packs

# Generate the CMake project and build
cbuild MyProject.csolution.yml

CMake Integration

For projects that prefer a pure CMake workflow without the CMSIS-Toolbox YAML layer, you can manually wire pack-extracted files into CMake. The key insight is that after running cpackget add, packs are extracted into a local store (typically ~/.local/share/cmsis-pack-root/ on Linux or %LOCALAPPDATA%/Arm/Packs on Windows). CMake can reference these paths directly.

# CMakeLists.txt — consuming CMSIS-Pack contents directly
# This approach is useful for projects migrating from Makefile + manual copy

cmake_minimum_required(VERSION 3.21)
project(myproject C ASM)

# ── Locate pack root (set via env var or CMake cache) ───────────────
# set(CMSIS_PACK_ROOT "$ENV{LOCALAPPDATA}/Arm/Packs"
#                     CACHE PATH "CMSIS pack installation root")

# ARM::CMSIS 6.1.0 — CMSIS-Core includes
# set(CMSIS_CORE_INC
#     "${CMSIS_PACK_ROOT}/ARM/CMSIS/6.1.0/CMSIS/Core/Include")

# Keil::STM32F4xx_DFP 2.17.1 — device header + startup
# set(STM32_DFP_ROOT
#     "${CMSIS_PACK_ROOT}/Keil/STM32F4xx_DFP/2.17.1")

# add_executable(firmware.elf
#     "${STM32_DFP_ROOT}/Source/Templates/startup_stm32f407xx.s"
#     "${STM32_DFP_ROOT}/Source/Templates/system_stm32f4xx.c"
#     src/main.c
# )

# target_include_directories(firmware.elf PRIVATE
#     ${CMSIS_CORE_INC}
#     "${STM32_DFP_ROOT}/Device/Include"
#     src/
# )

# target_compile_options(firmware.elf PRIVATE
#     -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard
#     -O2 -Wall -ffunction-sections -fdata-sections
#     -DSTM32F407xx
# )

# target_link_options(firmware.elf PRIVATE
#     -T${CMAKE_SOURCE_DIR}/STM32F407VGTx_FLASH.ld
#     -Wl,--gc-sections
# )

# mkdir build && cd build
# cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=../arm-none-eabi.cmake ..
# ninja

Exercises

CMSIS-Pack Project Planner

Use this tool to document your project's CMSIS-Pack configuration — which device pack, middleware packs, and software components you are using, along with version constraints and configuration notes. Download as Word, Excel, PDF, or PPTX for team onboarding, architecture reviews, or project documentation.

Conclusion & Next Steps

CMSIS-Pack transforms embedded dependency management from a manual, error-prone process into a reproducible, version-controlled workflow. The key concepts to carry forward:

• A .pack file is a ZIP archive containing a PDSC manifest, device headers auto-generated from SVD, startup code, flash algorithms, and middleware. Understanding its structure means you are never at the mercy of a tool to inspect what was installed.
• The PDSC file is the source of truth — it declares devices, components, dependencies, and conditions. Authoring a minimal PDSC is the first step toward creating reusable internal BSP packages for your organisation.
• Software components follow a standardised taxonomy (Cclass::Cgroup:Csub) that allows multiple implementations of the same interface to coexist, with the developer selecting the active variant at project configuration time.
• Configuration files in RTE/ are your project's. Commit them to version control. Never commit the pack archives themselves — only the version constraints used to obtain them.
• The CMSIS-Toolbox (cpackget + cbuild) is the open-source, IDE-independent way to work with packs from the command line and in CI/CD pipelines.