自研CMSIS-Pack器件支持包：从PDSC到FLM的Keil适配全流程

简介：《Keil5 CMSIS-Pack器件支持包制作教程(中文版)知识》是一份面向嵌入式开发者与芯片支持工程人员的中文PDF教程，系统介绍Keil5中CMSIS-Pack器件支持包（DFP）的核心概念、组成结构和制作方法。教程以虚构的MVCM3器件系列为例，从准备工作目录、复制基础文件，到编辑PDSC描述文件、加入SVD系统视图，再到CMSIS-Driver、Flash编程算法、示例项目与代码模板，完整演示DFP的生成流程。资源共1个文件，单份PDF约788KB，便于阅读和存档；已有1260人学习，适合正在搭建器件支持包或想理解Keil包管理机制的开发者。读者可据此掌握PDSC配置语法和器件定义方法，并能参考MVCM3110、MVCM3120等成员示例，迁移到真实芯片的器件支持包制作。

1. 拿到一颗没有官方DFP的新MCU：CMSIS-Pack器件支持包该自己做还是等官方

项目启动时最怕的不是芯片本身难搞，而是你在 Keil5 的 Device 列表里翻了两遍都找不到型号。国产 M0+ 核、跑着标准外设库、数据手册和寄存器定义都齐，但新建工程没有这个器件、下载算法没有对应选项、调试窗口里外设寄存器一片空白。等原厂补发 CMSIS-Pack 器件支持包？按芯片厂的排期，短则一两个月，长则一个季度，而你的样板打样和固件联调就在本周。这时候自己照着芯片手册做一个 DFP（Device Family Pack）不是炫技，是真正能卡住项目进度的活。

CMSIS-Pack 说白了是一套 Keil MDK 规定的打包规范：把器件型号、Flash 起始地址和大小、RAM 布局、烧录算法、调试用的 SVD 文件、启动文件和头文件，全部按固定目录结构装进一个 zip 里，再用一个 PDSC 描述文件告诉 MDK“这个包属于谁、叫什么、版本号是多少、里面哪些文件对应哪颗芯片”。MDK 的 Pack Installer 拿到这个包之后，会自动完成安装、索引、匹配和关联，新建工程时那颗芯片就会出现在列表里。

这篇笔记就是把整个制作链路拆开讲清楚：先看懂包内结构，再准备物料、写 PDSC、准备 FLM 和 SVD、打包自检、本地安装验证，最后是几个容易卡住人的隐蔽坑。适合需要给非主流芯片做 Keil 支持、或者想把公司内部多个批次芯片统一管理起来的人。新手照着步骤能跑通，熟手可以直接跳到第五章和第六章看参数边界和版本管理方案。

2. 拆开一个.pack看看里面装了什么：PDSC、FLM、SVD三件套的分工

2.1 PDSC是包的“总目录”，整个安装过程都在读它

CMSIS-Pack 的目录结构看着简单，但真正决定包能不能被识别的是根目录下那个.pdsc文件。PDSC 是 XML 格式的包描述文件，里面声明了 vendor（厂商）、name（包名）、version（版本号），以及关键的<devices>节点——它把芯片型号Dname和厂商 ID 绑定到一块，后面还会列出一颗芯片的 IROM1、IRAM1 起始地址和大小，以及烧录算法algorithm指向哪个 FLM 文件。Pack Installer 在安装时先解压到临时目录，然后逐节点解析 PDSC，校验 schema 版本、XML 格式、文件引用路径是否存在。任何一处不合规，整个包都会被拒收，而且不一定会弹明确报错，更多时候是包在列表里消失得无影无踪。

有一件事容易忽略：PDSC 里的<releases>节点不仅记录版本历史，还参与版本匹配逻辑。MDK 检查更新、项目文件记录 pack 版本依赖时，都会读取这个节点。如果releases里最新的版本号跟文件名上的版本号对不上，或者版本号少于三段（正常是1.0.0这种三段式），Pack Installer 会直接把包丢掉。我第一次做包就栽在这上面，文件名写1.0.0但 pdsc 里 release 写的是1.0，折腾了半小时愣是没找到原因。

2.2 烧录算法FLM：下载器能认芯片的关键靠它

FLM 文件不是普通数据文件，它是一个由编译器生成的 Flash 编程算法模块，包含初始化、擦除扇区、写入页、校验等回调函数。调试器（比如 J-Link 或 CMSIS-DAP）在烧录时，会先把 FLM 从主机下载到芯片的 RAM 里，然后调用里面的函数去操作目标 Flash 控制器。这意味着 FLM 里必须写明算法运行需要多大 RAM、用什么加载地址、目标 Flash 的扇区大小和组织方式、编程页大小、芯片 ID 等等。这些信息从芯片手册的 Flash 章节和存储映射表里来，做 DFP 时可以直接拿原厂或同系列兼容芯片的 FLM，但要改掉几个关键参数。

很多人想偷懒，直接在现有工程的 Target 设置里手动填一个下载算法，凑合着把固件烧进去。这在开发初期可行，但一旦换机器、换电脑重装环境，所有手动配置全部丢失，而且遇到多颗不同 Flash 布局的芯片时，手动改来改去极易翻车。把 FLM 放进 DFP，让 MDK 在选定器件后自动把算法加载进 Flash Download 列表，才是一劳永逸的做法。

2.3 SVD文件：调试窗口里寄存器名字的来源

SVD（System View Description）是一份描述 SoC 外设寄存器布局的 XML 文件。进入调试后，MDK 的 Peripherals 窗口里能看到的外设列表、寄存器名、位段定义，全部来自这个文件。芯片能烧录但调试体验差，十有八九是 SVD 没做或者没关联上。SVD 可以从芯片原厂拿，也可以参考同内核、同外设 IP 的兼容芯片改写。它里面的name字段必须跟 PDSC 里<device Dname="...">完全一致，否则调试时 MDK 不知道这份 SVD 该挂到哪颗芯片下，外设窗口就一直是空的。

从定位上说，PDSC、FLM、SVD 这三样的职责是分开的：PDSC 负责让 MDK“认识”这个包和这系列芯片，FLM 负责让下载器“能烧”这颗芯片，SVD 负责让调试器“能看”这颗芯片。三个文件缺一个，包都能装上，但项目体验会分别在选型、烧录、调试三个环节出问题，这也是后续做验证时为什么要按顺序过关的原因。

3. 从零制作DFP：物料准备、PDSC编写与打包校验

3.1 制作前先把“物料”备齐：手册、启动文件、FLM、SVD

动手前第一件事是列清单。每个部分都能从不同渠道拿到，缺了哪样后面就卡在哪一步。

先说最重要的 Flash 存储映射。做 PDSC 时要在<memory>节点里写 IROM1 和 IRAM1 的起始地址和大小，这些数字直接决定 Keil 新建工程时 Target 选项卡里默认显示的 ROM/RAM 范围。写错的话，就算包装上了，编译链接也会在.\Objects目录下报内存超范围错误。更隐蔽的是，如果你把 IROM1 写大了，链接器不会报错，但最后生成的 hex 可能覆盖到并不存在的 Flash 地址，烧录校验直接失败。所以我一般先把手册里的存储映射表摘抄成一张对照表，一个地址一个地址核对，再往里填。

3.2 建立目录结构：一个合法.pack的骨架长什么样

CMSIS-Pack 的目录结构有约定，PDSC 必须在根目录，文件引用路径要跟实际目录一致。下面是我常用的最小骨架：

MyPack/ ├── MyVendor.MyFam.pdsc ├── Flash/ │ └── FlashOS.FLM ├── SVD/ │ └── MyFam.svd ├── Include/ │ ├── MyFam.h │ └── system_MyFam.c ├── Startup/ │ └── startup_MyFam.s └── Documentation/ └── index.html

每个目录不是摆设。Flash目录放 FLM，SVD目录放 SVD 文件，Include目录放芯片头文件和系统初始化文件，Startup放启动汇编文件，Documentation放包的简介页。PDSC 里引用这些文件时，路径是相对 PDSC 所在目录的，比如SVD/MyFam.svd。需要注意两个细节：第一，启动文件和头文件不是必须的，但建议放进去，因为 Keil 新建工程时如果勾选了“自动添加启动文件和系统文件”，MDK 会按 PDSC 里的<components>节点去匹配。第二，Documentation目录在 PackChk 校验时会被检查是否需要存在，没有index.html也能通过，但 Keil 的 Pack Installer 界面里会缺少“Documentation”按钮，看起来不完整。

3.3 手写PDSC：最小可用的XML结构，一个节点都不要漏

PDSC 是整套流程里最容易出问题的文件。下面是一个最小可用的例子，拿自家芯片MyFam103来说明：

<?xml version="1.0" encoding="UTF-8" ?> <package schemaVersion="1.4" xmlns="http://www.keil.com/pack"> <vendor>MyVendor</vendor> <name>MyFam</name> <description>MyVendor MyFam Device Family Pack</description> <url>http://example.com/pack</url> <releases> <release version="1.0.0" date="2025-01-01">First release</release> </releases> <devices> <family Dfamily="MyFam" Dvendor="MyVendor:MyVendor"> <device Dname="MyFam103"> <memory> <memory id="IROM1" start="0x08000000" size="0x10000"/> <memory id="IRAM1" start="0x20000000" size="0x4000"/> </memory> <algorithm name="FlashOS" start="0x08000000" size="0x10000" default="1"/> </device> </family> </devices> <SVD svd="SVD/MyFam.svd"/> </package>

代码的关键点拆开说。<package>的schemaVersion是包格式协议版本，不同版本的 Keil 支持的版本号不一样，最稳妥的办法是拿你电脑上已安装的某个官方 DFP 的 pdsc 文件对比一下，照它的 schemaVersion 写，能避免老版本 Pack Installer 解不了新格式的问题。<vendor>和<name>拼起来会显示在 Pack Installer 的列表里，比如MyVendor::MyFam，所以这两个值要提前想好，发布后尽量不要改，否则已安装的旧包会跟新包并排出现。<url>是包的主页地址，PackChk 校验时会检查 URL 是否可达，内网环境可以填一个能访问的 IP 地址，或者暂时填一个占位网址，后续再替换。

<memory>节点的id必须是IROM1和IRAM1，这是 MDK 在 Target 选项卡里默认读取的名字，写成FLASH之类的名字不会被识别。start和size的单位是字节，十六进制可读性最好。为了让编译链接时的默认逻辑跟器件一致，IROM1的 start 必须等于芯片 Flash 起始地址，IRAM1 同理。<algorithm>节点里name="FlashOS"对应Flash目录下的FlashOS.FLM，这里只写名字不带路径，start和size一定要跟 FLM 实际能覆盖的地址范围一致；写大了，擦除时算法会超出自身定义的 Sector 表，写小了，烧录后面部分芯片直接报“Verify Failed”。

3.4 准备FLM和SVD：没有现成的就改造兼容型号

FLM 是大多数人的拦路虎。手头没有现成 FLM 时，常见做法是拿同内核、同 Flash 控制器的兼容芯片 FLM 来改。如果你有芯片原厂提供的 FLM 工程（有些厂商会直接给 IAR 或 Keil 的 Flash 算法工程模板），那就简单很多。用 MDK 打开 FLM 工程，找到描述 Flash 设备的源文件，里面定义了一个结构体，包含设备名、扇区大小列表、启动地址、页大小、芯片 ID 等字段。比如要把原来 512KB 的芯片改成 128KB，就改扇区列表和 DeviceSize 两个地方，然后重新编译生成新的.FLM文件，替换到包的Flash目录。

SVD 的准备可以走一条省力路线：找同内核同外设 IP 的 SVD 文件，把里面描述芯片型号、外设基地址、寄存器名的 XML 节点复制出来，按目标芯片的数据手册逐一核对基地址。SVD 文件头部的<name>标签必须改成和 PDSC 里Dname一致，否则挂载不上。我自己检查 SVD 对不对，会在 MDK 里进入调试，打开 Peripheral 窗口，逐个外设点开看寄存器地址是否正确，比对着 XML 用眼睛检查快得多。

3.5 用zip打包并用PackChk自检

PDSC、FLM、SVD 都备好后，把整个目录打成.pack文件。.pack本质就是 zip，但打包时有个关键细节：必须以 PDSC 所在目录为基准，直接把里面的文件压进 zip，不能在外面多套一层目录。常见的错误是压缩出来得到一个MyPack/...的顶层文件夹，导致 Keil 解压后找不到根目录的 pdsc。

cd MyPack zip -r ../MyVendor.MyFam.1.0.0.pack . PackChk.exe MyVendor.MyFam.pdsc -i ../MyVendor.MyFam.1.0.0.pack

第一行zip -r把当前目录内容递归打包，目标文件名MyVendor.MyFam.1.0.0.pack里的版本号要跟 PDSC 里 releases 的最新版本完全一致。第二行调用PackChk.exe做校验，这是 Keil 自带的命令行工具，通常位于 MDK 安装目录下，它会检查 XML 格式、schema 版本、文件引用是否存在、URL 是否可达、版本号是否符合规范。校验通过后 PackChk 会打印一行类似“Pack has no errors”的结果；有错误则会列出具体行号。这一步在打包后必须跑，它能把 90% 的格式问题拦在安装之前，省去在 Keil 界面里反复试错的尴尬。

4. 让Keil5认账：本地安装、工程选型与烧录调试验证

4.1 通过Pack Installer导入，或直接放入本地仓库目录

做好.pack文件后，安装方式有几种。最直接的是双击.pack文件，Windows 会把它关联到 Pack Installer，自动导入并安装。也可以打开 Pack Installer，在菜单里选File -> Import，手动浏览到文件所在位置。这两种方式都会把包解压并复制到本地 pack 仓库目录，通常在%LOCALAPPDATA%\Arm\Packs下，同时更新索引文件，让 Keil 在启动时能看到这个包。

还有一种适合批量部署的方式：手动把.pack文件解压后的目录直接放进本地仓库。先看清楚目录结构，把MyVendor/MyFam/1.0.0这样的三层路径建好，再把之前打包前的文件放进去。这种方式绕开了 Pack Installer 的解压流程，适合公司内部用脚本批量给多台电脑部署，但要注意解压后必须保留完整目录，任何一级缺了 Keil 都会找不到。

4.2 新建工程并选中目标器件，验证PDSC关联是否正确

安装完成后，打开 Keil5 新建一个工程，在Select Device对话框的搜索框里输入MyFam103，如果能搜索到这颗芯片，说明 PDSC 的<devices>节点解析成功。选完芯片后，生成的.uvprojx工程文件里会写入器件信息，整个过程 MDK 会自动把跟器件关联的启动文件、系统初始化文件拉进来。

<Device> <Cpu>CM0</Cpu> <Dvendor>MyVendor:MyVendor</Dvendor> <Dname>MyFam103</Dname> </Device>

这段 XML 是.uvprojx里的Device节点。Dvendor的格式是厂商ID:厂商名，对应 PDSC 里<family Dvendor="...">的写法；Dname对应<device Dname="...">。如果选完芯片后保存工程，再打开却发现Ddevice丢失或者变成默认型号，说明 PDSC 的 vendor 命名和工程文件对不上，回 PDSC 里检查大小写和冒号格式。

4.3 烧录验证要过三关：编译、下载、调试窗口

制作完 DFP 后，验证不能只靠“能新建工程”就收工。我会按三个步骤逐项过关。

第一步编一个最简单的空工程，main 函数里什么都不做，直接 Keil 自带的 SystemInit 和 startup 汇编参与链接，确认工程能完整编译，头文件路径能被正确关联。这个步骤可以暴露启动文件或头文件缺失的问题，如果编译时报找不到MyFam.h，说明 PDSC 里没声明对应组件。

第二步连接调试器，在Options for Target -> Debug里选择对应的仿真器，然后在Flash Download选项卡里勾选“Erase Full Chip”或“Erase Sectors”，点 Download 按钮，观察烧录日志。日志里能看到 MDK 实际调用的 FLM 文件路径，如果日志显示Erase Failed或Cannot access target，优先检查 PDSC 里<algorithm>的 start、size 是否跟 FLM 内部定义一致，以及 FLM 是不是为这颗芯片专门编译的。这个阶段出现的问题，多数跟 FLM 的内存窗口配置有关，具体见第五章。

第三步进入调试模式，在Peripherals菜单里打开外设窗口，逐个点开看寄存器值和地址。如果外设窗口是空的，先检查 SVD 里的name是否与Dname匹配，再看 PDSC 里的<SVD>路径是否正确。走到这一步，一个器件支持包才算是真正完工。

5. 器件支持包制作避坑：版本号、编码、Flash算法的五个典型问题

5.1 版本号格式不对：两段式版本号让整个包消失

现象：打包完成、安装时没有报错，但 Pack Installer 的列表里始终看不到MyVendor::MyFam这个包。

原因：PDSC 里<releases>的版本号写成了1.0，而不是三段式的1.0.0。Keil 的包管理逻辑对版本号格式有硬性要求，两段式会被判定为非法版本直接丢弃，而且不弹任何提示。

解决：把发布版本号统一改成1.0.0这种三段式格式，同时保证.pack文件名里的版本号、PDSC 里<release>的version属性、以及本地仓库目录名里的版本号三者完全一致。改完重新打包，用 PackChk 再过一遍，确认没有版本相关告警再安装。

5.2 XML编码问题：ANSI和GB2312让解析器翻车

现象：PackChk 校验时报 XML 解析错误，或者 Pack Installer 里包名和描述全部变成乱码。

原因：PDSC 文件用记事本另存为 ANSI 编码，或者在某处写了中文注释但保存编码不是 UTF-8。CMSIS-Pack 规范要求 PDSC 必须用 UTF-8 编码，有些版本还建议带 BOM 头，因为早期版本的解析器在无 BOM 的情况下会按本地默认编码解析，中文系统默认 GBK，两者不一致就会乱码。

解决：用能控制编码的编辑器（比如 VS Code 或 Notepad++）统一把 PDSC 保存为UTF-8 with BOM，不要用手动编码转换工具反复转码。中文注释能省则省，多语言描述里最稳妥的做法是只保留英文，避免任何编码歧义。

5.3 FLM存储大小与芯片不匹配：烧录到一半报Verify Failed

现象：空工程烧录前 64KB 一切正常，但烧录到后半段时日志报Verify Failed at 0x08010000，或者Erase Failed。

原因：FLM 内部的FlashDevice结构体里定义的扇区表和 DeviceSize，跟 PDSC 里<algorithm>的size不一致。比如芯片实际 128KB Flash，但 FLM 是从一个 512KB 芯片上拿来的，烧录器按 512KB 的算法去擦除和编程，到了芯片不存在的地址校验自然失败。

解决：打开 FLM 工程，找到描述 Flash 设备的结构体定义，把 DeviceSize 改成芯片真实大小，逐项核对扇区表——扇区地址偏移、扇区大小、扇区数量必须跟手册一致，然后重新编译生成 FLM，替换包内文件。PDSC 里的<algorithm size="...">同样改成实际大小，两个地方的数字必须同步，这是最容易忽略的坑。

5.4 SVD文件名称不匹配：Peripheral窗口迟迟不显示外设

现象：进入调试后，Peripheral 菜单里能看到外设分组，但点开一个外设全是空白，寄存器地址全部显示0x00000000。

原因：SVD 文件内部的<name>标签与 PDSC 的<device Dname="...">不匹配，或者 SVD 文件里外设基地址本身写错。MDK 依赖 SVD 内部的名称来关联器件，名称对不上时，调试会话不会加载这份 SVD，外设窗口自然拿不到数据。

解决：把 SVD 文件里的<name>字段改成和目标芯片Dname完全一致，然后逐个核对每个外设的基地址，特别是 GPIO、UART、TIM 这类外设，地址错一位寄存器全乱。改完后用 PackChk 重新校验引用路径，再进调试看 Peripheral 窗口是否恢复正常。

5.5 本地仓库路径含中文或空格：旧版Keil加载失败

现象：手动把包文件拷贝到本地 pack 仓库目录后，重启 Keil 仍然看不到包，但把同样的文件放到默认仓库路径下就正常。

原因：旧版本 Keil 的包加载器在解析仓库路径时对非 ASCII 字符支持不好。本地仓库路径如果带有中文名（例如D:\芯片资料\Arm\Packs），解压和索引过程会静默失败。

解决：把存放 pack 仓库的目录改到纯英文路径下，并在 Keil 的 Options 里清理掉旧的 pack 缓存后重新导入。能放在默认%LOCALAPPDATA%\Arm\Packs下就用默认路径，这是兼容性最好的选择，也为后续公司内部批量部署省掉不少麻烦。

6. 进阶：把DFP纳入版本管理，用脚本一键打包与本地源分发

当器件支持包从一个变成几个、从自己用变成团队共用时，手工打包和手动拷贝的方式就撑不住了。我现在的做法是把整个制作目录放进 Git 仓库，PDSC、FLM 源码、SVD、打包脚本一起管理。每次改动走评审，改动后升版本号再打包发布，这样团队里任何人拿到的都是可追溯的确定版本，不会再出现“你那次是不是改了 FLM 没告诉我”的情况。

发布动作可以完全脚本化。打包脚本的核心逻辑很简单：先清理旧的输出文件，再打包并跑 PackChk，最后把生成的.pack复制到指定的发布目录。脚本在 Windows 下用批处理或 PowerShell 都可以，核心就几句话：

rm -f ../MyVendor.MyFam.1.0.0.pack zip -r ../MyVendor.MyFam.1.0.0.pack . PackChk.exe MyVendor.MyFam.pdsc -i ../MyVendor.MyFam.1.0.0.pack

脚本里我还会顺带做一个版本号检查，用findstr从 PDSC 里提取<release version="...">跟文件名做比对，不一致就让脚本直接失败。这个检查成本极低，但能把上一章 5.1 那种低级错误直接挡在发布门外，值得加到 CI 流程里去。

团队分发方面，最简单的方案是搭建一个本地 HTTP 服务器，把.pack文件放在一个固定目录下，然后在 Pack Installer 的配置里添加这个服务器地址作为 pack 源。这样同事每次刷新就能看到新版本，不用手动接收安装包。内部工具类产物的版本管理做到这一步，基本已经够用了。

最后说一个我自己的教训：有一版支持包改了 Flash 算法，但发布时漏了升版本号，同事机器上一直显示旧版本，烧录新芯片时全军覆没，排查了一整天才发现是缓存里的旧包在作怪。之后我养成了一个习惯——每次改动，哪怕只是改了一行描述，都必须升 Patch 版本号再发布。版本号这个东西，平时看没什么用，出事的时候就是唯一能帮你定位问题的锚点。希望这篇笔记能帮你在做器件支持包时少跑几次冤枉路，一次把包做对。

本文还有配套的精品资源，点击获取