Nordic nRF5系列_开发指南

1 · 文档导读与阅读路径

这份文档面向已经会写 C、但第一次接触 Nordic 生态的嵌入式工程师。它不假定你用过 Zephyr，也不假定你用过 nRF5 SDK；从「买哪块板子」一路写到「怎么过认证、怎么量产烧录」。

1.1 覆盖范围

文档覆盖 Nordic 短距离无线 SoC 的五代产品：nRF51（Cortex-M0，已 NRND）、nRF52（Cortex-M4F，出货量最大的一代）、nRF53（双核 Cortex-M33）、nRF54L（22 nm 低功耗主力）、nRF54H（320 MHz 多核高性能）。软件侧以 nRF Connect SDK（NCS）为主线，同时给出遗留 nRF5 SDK + SoftDevice 的对照与迁移路径。

• 硬件：选型对比、封装与料号命名、电源与时钟架构、GPIO/DPPI/EasyDMA。
• 工具链：nRF Util、nRF Connect for Desktop、nRF Connect for VS Code、west / CMake / Kconfig / Devicetree / sysbuild。
• 驱动：Zephyr 设备模型下的 GPIO、UART、SPI、TWI、PWM、SAADC、RTC。
• 无线：蓝牙 LE（GAP/GATT、广播、连接、安全、PHY、Mesh、LE Audio、Channel Sounding）、Thread / Zigbee / Matter、ESB、NFC。
• 工程化：低功耗设计与 PPK2 实测、安全启动链、DFU/FOTA、调试与测试、量产烧录、认证合规。

1.2 不覆盖什么

• 不覆盖 nRF91 系列（蜂窝 LTE-M / NB-IoT）与 nRF70 系列（Wi-Fi 协同 IC）的完整开发流程，只在需要协同的章节提到接口。
• 不重复 Zephyr RTOS 的通用内核教程（线程、信号量、工作队列等），只在影响 Nordic 开发的地方给出最小必要说明。
• 不给原理图级射频匹配网络的完整计算过程，天线与匹配请查对应 Reference Layout 与产品规范。
• 不提供法律意义上的认证建议，第 18 章只给流程与清单。

1.3 版本标注约定

Nordic 的软件版本迭代很快，文档里出现的版本号按下面约定理解：

1.4 事实来源与免责

文中所有规格数字来自 Nordic 官网产品页与 docs.nordicsemi.com 技术文档（含 nRF Connect SDK、Zephyr、MCUboot、Trusted Firmware-M 文档集）。电流、灵敏度、发射功率等参数随芯片版本与测试条件变化，量产前必须以所用器件的最新《Product Specification》为准。文中给出的命令与 Kconfig 选项在 NCS 3.4.x 上验证，跨版本可能有改名（尤其是 SB_CONFIG_* 前缀与 sysbuild 相关项）。

1.5 五条阅读路径

2 · nRF5 系列全景与选型

Nordic 的短距离无线 SoC 走了五代：nRF51 打开局面，nRF52 出货数十亿，nRF53 首次引入双核，nRF54L 把工艺推到 22 nm，nRF54H 则把性能堆到 320 MHz。这一章把五代放在一张表里对比，并给出选型决策依据。

2.1 五代产品时间线

从架构演进的角度看，Nordic 三十年只做一件事：把「MCU + 射频 + 协议栈」塞进一颗越来越省电的芯片里。每一代的核心变化如下：

来源：Nordic Semiconductor 产品页（nRF51/nRF52/nRF53/nRF54L/nRF54H20）与产品规范摘要。

2.2 nRF51 系列：SoftDevice 思路的起点

nRF51 是 Nordic 打进 BLE 市场的第一代产品，已标记 NRND（Not Recommended for New Designs），但存量极大，维护旧产品时仍会遇到。

nRF51 的硬件特征：Cortex-M0 @16 MHz、10-bit ADC、16 通道 PPI、31 个 GPIO、128-bit AES ECB/CCM/AAR 协处理器、片内 LDO 与 Buck DC/DC 两种稳压模式。射频侧 250 kbps / 1 Mbps / 2 Mbps，发射功率 +4 dBm 起（4 dB 步进可调至 −20 dBm）。

2.3 nRF52 系列：出货量最大的一代

nRF52 全系 Cortex-M4F @64 MHz，外设带 EasyDMA，配 Nordic 的 PPI（可编程外设互连）。差异集中在 Flash/RAM 容量、USB、802.15.4 与 Coded PHY（Long Range）上。

关键提醒：nRF52832 的射频不支持 IEEE 802.15.4，所以跑不了 Thread / Zigbee；而 nRF52811 虽然只有 24 KB RAM，却是少数带 802.15.4 + Coded PHY 的小封装料号。24 KB RAM 跑完整 Zephyr + BLE 非常紧，做 OTA 双分区基本不可能。

2.4 nRF53 系列：双核分离的第一次尝试

nRF5340 把「跑应用的核」和「跑协议栈的核」物理分开，这是 Nordic 应对「应用代码越来越复杂、协议栈必须实时」的架构答案。

其他特征：TrustZone 隔离、Arm CryptoCell-312、USB 2.0、QSPI（支持 XIP 执行外部 Flash）、HS-SPI、105 °C 扩展温区、1.7–5.5 V 供电范围。双核也带来调试复杂度——要调试网络核必须开两个调试会话（详见第 16 章）。

2.5 nRF54L 系列：当前新项目首选

nRF54L 是 nRF52 的官方接班人。相比 nRF52840，官方口径是处理能力翻倍、处理效率三倍，同时把工艺推到 22 nm 低漏电节点。

性能亮点（官方 @3 V 数据）：193 CoreMark/mA、503 CoreMark；射频 RX 3.4 mA、TX @0 dBm 4.8 mA；睡眠电流 0.7 µA 起（System OFF，无 RAM 保持）到 2.9 µA；CSP 封装 +8 dBm / QFN 封装 +7 dBm。

2.6 nRF54H 系列：高性能旗舰

nRF54H20 的目标场景是「原来需要外挂 MCU + 外部 Flash + 无线 SoC」的复杂产品。它把多个 Cortex-M33 和多个 RISC-V 协处理器塞进一颗 4.7×4.3 mm 的 WLCSP。

• 算力：多核 Cortex-M33 最高 320 MHz，多 RISC-V 协处理器；应用核算力是 nRF5340 应用核的两倍。EEMBC ULPMark-CoreMark：效率取向 515 CoreMark / ULPMark-CM 170，性能取向 1290 CoreMark / ULPMark-CM 132。
• 存储：2 MB NVM + 1 MB RAM。
• 射频：第 4 代 2.4 GHz 多协议射频，BLE 1 Mbps 灵敏度 −99 dBm，802.15.4 −104 dBm，TX 最高 +10 dBm，RX 电流低至 1.7 mA（3 V，DC/DC）。
• 接口：高速 USB 480 Mbps、CAN FD 控制器、2× I3C、14-bit ADC、高性能外部存储接口（400 MBps，支持 XIP / QSPI / xSPI / HyperBus）。
• 安全：面向 PSA Certified Level 3 设计，IronSide Secure Enclave 隔离安全区、防篡改传感器、抗侧信道加密加速器。

2.7 横向选型速查

选型决定后立刻要面对的三件事：4 · 装环境13 · 做功耗预算18 · 过认证。若是从老项目迁移，先看 19 · 迁移路径。

2.8 料号与封装命名规则

Nordic 的完整料号形如 nRF52840-QIAA-R7，拆开看：

模组方面，Nordic 自己不出模组，但有庞大的第三方模组伙伴网络（ezurio/Laird、Fanstel、Raytac、MinewSemi、MOKO、Panasonic、Insight SiP、Holyiot、KAGA FEI、Lierda、Feasycom、Abluetech、BoBlinker、HJSIP 等），提供 PCB 天线 / 芯片天线 / uFL 座 / trace pin 等多种形态。选模组的直接收益是射频认证可以复用，设计风险与上市周期大幅下降。

3 · 硬件架构与核心子系统

这一章讲所有 nRF5 芯片共有的骨架：CPU、内存、电源、时钟、GPIO、事件互连与 DMA。理解了这套骨架，nRF51 到 nRF54 的外设驱动写法就都能对上号。

3.1 CPU、内存与总线

3.2 电源架构

nRF5 芯片内部有两套稳压方案可选，这是功耗优化的第一道闸门：

外部配套方面，Nordic 提供 nPM 系列 PMIC：nPM1100（超小体积双模 Buck + 电池充电）、nPM1300 / nPM1304（带电量计与系统管理）、nPM2100（超低静态电流，适合纽扣电池）。nRF54L15 DK 上就用 nPM1300 给 SoC 供电，可用 Board Configurator 桌面应用把 VDD 从默认 1.8 V 改成 3.0 V。

&dcdc {
    status = "okay";
};

3.3 时钟系统

GRTC（Global Real-Time Counter）是 nRF54L 系列新增的关键模块。传统 nRF52 进 System OFF 后只有 GPIO 检测能唤醒，时间信息全丢；nRF54L 的 GRTC 在 System OFF 里继续走时，既能做定时唤醒，又能保持系统时间戳连续——这对「长时间深度睡眠 + 周期性上报」的产品是架构级的简化。

3.4 GPIO 与 GPIOTE

nRF5 的 GPIO 端口按 P0.x / P1.x 编号，每个引脚可通过 CONFIG 寄存器自由分配给任意外设（SPI、TWI、UART、PWM、SAADC 等），这是 Nordic 相对很多 MCU 的显著优势——引脚不绑定外设，Layout 自由度极高。

GPIOTE（GPIO Tasks and Events）负责把引脚电平变化变成可被 PPI/DPPI 路由的事件，或反过来让事件直接翻转引脚。典型用法：用 gpiote + dppi 实现「定时器比较匹配 → 自动翻转 LED」，全程 CPU 不参与。

/* Zephyr 侧推荐写法：用 gpio_dt_spec 从设备树拿引脚 */
#include <zephyr/drivers/gpio.h>

static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(DT_ALIAS(led0), gpios);

void main(void)
{
    gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE);
    while (1) {
        gpio_pin_toggle_dt(&led);
        k_msleep(500);
    }
}

3.5 从 PPI 到 DPPI：事件互连的演进

PPI（Programmable Peripheral Interconnect）是 Nordic 的招牌设计——让外设之间直接互相触发，不需要 CPU 中断参与，是低功耗的关键。三代实现如下：

在 Zephyr 侧这些细节被封装成 nrfx_dppi / nrfx_gppi 抽象，应用层通常用 Kconfig 选项（如 CONFIG_NRFX_DPPI）或直接让驱动内部申请通道，无需手写寄存器。

3.6 EasyDMA

nRF5 的数字接口（SPIM、TWIM、UARTE、SAADC、QSPI、I2S、PDM）几乎都带 EasyDMA：驱动只要给一个 RAM 缓冲区地址与长度，硬件自己搬数据，完成后发一个 END 事件。这带来两个约束：

• 缓冲区必须位于 RAM 中。把 const 数组放在 Flash 里直接喂给 EasyDMA 会触发总线错误或静默失败——这是移植代码时极高频的坑。
• 缓冲区不能被编译器优化掉或中途改地址。DMA 传输期间要保证缓冲区有效，Zephyr 驱动通常用异步 API + 回调解决。

3.7 外设清单对照

3.8 UICR 与 OTP：出厂配置信息放在哪

UICR（User Information Configuration Registers）是一块独立于主 Flash 的小区域，用来放不能被普通擦除清掉的信息。典型用途：

• UICR->CUSTOMER[n]：放客户自定义数据，如 OpenThread 的 EUI-64 地址、产品序列号。
• 引脚默认配置：如 NFC 引脚是当 GPIO 还是当 NFC 天线引脚，靠 UICR 决定。
• 引导相关：APPROTECT、SECURE APPROTECT、 bootloader 地址等。

写入方式（以 Thread 的 EUI-64 为例）：

nrfutil device x-write --serial-number <snr> --address 0x10001080 --value 0x11223344
nrfutil device x-write --serial-number <snr> --address 0x10001084 --value 0x55667788
nrfutil device reset --reset-kind=RESET_PIN

4 · 开发环境搭建：nRF Connect SDK 与工具链

Nordic 现在的工具链是「一套 SDK + 三个入口」。这一章把三条安装路线全部走一遍，并给出 CI/服务器场景下的无头安装方案。

4.1 三条安装路线怎么选

4.2 路线一：nRF Connect for VS Code（推荐）

1. 安装 VS Code（1.86 以上）。
2. 在扩展市场搜索 nRF Connect，安装 Nordic 官方扩展包（会连带装 nRF Kconfig、nRF DeviceTree、nRF Terminal、nRF Debug 等子扩展）。
3. 打开扩展侧边栏的 Welcome 面板，点击 Install Toolchain，选择要装的 NCS 版本（新项目选 3.4.0 LTS 或更新的 3.4.x）。
4. 选择安装路径（Windows 建议 C:\ncs\v3.4.0，路径不要有空格与中文）。
5. 等待下载完成——这一步会拉下 SDK 全部仓库 + 工具链 + Python 依赖，国内网络可能需要几十分钟到数小时，建议挂代理或选夜间时段。
6. 装完后点 Open VS Code，扩展会自动设置好 ZEPHYR_BASE、工具链路径等环境变量。

4.3 路线二：nrfutil 命令行（CI 友好）

新版 nrfutil（7.x） 是原生二进制 + 插件架构，与旧版 pip 装的 6.x 完全不兼容。第一件事是装二进制本体，然后按需装子命令：

# 1. 下载 nrfutil 放到 PATH（Windows 建议 C:\Nordic\nrfutil\）
nrfutil --version

# 2. 安装需要的子命令
nrfutil install device          # 烧录 / 擦除 / 复位 / 调试
nrfutil install toolchain-manager  # SDK 与工具链管理

# 3. 列出并安装 SDK 工具链
nrfutil toolchain-manager list
nrfutil toolchain-manager install --install-dir <路径> --ncs-版本号 v3.4.0

# 4. 进入该工具链环境后即可 west build / west flash
nrfutil toolchain-manager launch --ncs-version v3.4.0 -- west build -b nrf54l15dk/nrf54l15/cpuapp

4.4 路线三：手动 west（做 SDK 开发时用）

# 1. 建工作区
mkdir ncs && cd ncs
python3 -m venv .venv && source .venv/bin/activate
pip install west

# 2. 拉 manifest 仓库（sdk-nrf 就是 manifest repo）
west init -m https://github.com/nrfconnect/sdk-nrf --mr v3.4.0
west update            # 拉取 zephyr / mcuboot / tfm / mbedtls / nrfxlib 等全部模块
west zephyr-export     # 导出 ZEPHYR_BASE 与 CMake 包

# 3. 装 Python 依赖
pip install -r zephyr/scripts/requirements.txt
pip install -r nrf/scripts/requirements.txt
pip install -r bootloader/mcuboot/scripts/requirements.txt

4.5 驱动与权限

$ nrfutil device list
004400012345  SEGGER J-LINK  nRF54L15-DK  /dev/ttyACM0

4.6 目录结构与磁盘占用

NCS 工作区由 west 管理的多个 Git 仓库组成，完整安装（含工具链）通常占用 20 ~ 35 GB，多版本并存时按版本数线性增长。核心目录：

4.7 验证：从零编译并烧录

1. 进入任一示例目录，如 nrf/samples/hello_world（Zephyr 侧为 zephyr/samples/hello_world）。
2. 编译：west build -b nrf54l15dk/nrf54l15/cpuapp
3. 烧录：west flash（或 nrfutil device program --firmware build/zephyr/zephyr.hex --traits jlink）
4. 看输出：串口 115200-8-N-1，或在 VS Code 里开 nRF Terminal。

5 · 工程结构与构建系统

NCS 的构建系统叠了五层：west 管仓库、CMake 管编译、Kconfig 管配置、Devicetree 管硬件、sysbuild 管多镜像。这五层的关系搞清楚，编译报错就有一半能自己定位。

5.1 一个最小工程的目录结构

my_app/
├── CMakeLists.txt          # 工程入口，至少 3 行
├── prj.conf                # Kconfig 配置（主）
├── Kconfig                 # 可选：自定义 Kconfig 选项
├── src/
│   └── main.c
├── boards/
│   ├── nrf54l15dk_nrf54l15_cpuapp.overlay   # 板级设备树覆盖
│   └── nrf52840dk_nrf52840.conf             # 板级专属配置
├── sysbuild.conf           # 多镜像构建配置（MCUboot / NSIB 等）
├── VERSION                 # 应用版本号（DFU 用）
└── build/                  # 构建产物（west build 生成）

最小 CMakeLists.txt：

cmake_minimum_required(VERSION 3.20.0)
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(my_app)

target_sources(app PRIVATE src/main.c)

5.2 Kconfig：功能开关

Kconfig 决定「编译哪些代码进去」。三个层级，优先级从低到高：板级默认 defconfig → 应用 prj.conf → 命令行 -DCONFIG_XXX=y。

# prj.conf 示例：开启蓝牙 + 日志 + RTT 后端
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="MyDevice"
CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_USE_SEGGER_RTT=y

改配置的三种方式：

5.3 Devicetree：硬件描述

Devicetree（DTS）描述「板子上有什么硬件、接在哪个引脚」。Zephyr 用它替代传统的 #define PIN_X 12 写法，应用通过 DT_ALIAS / DT_NODELABEL 拿句柄。

/* boards/nrf54l15dk_nrf54l15_cpuapp.overlay —— 给板子加一个 I2C 传感器 */
&i2c1 {
    status = "okay";
    bme280@76 {
        compatible = "bosch,bme280";
        reg = <0x76>;
    };
};

/* 打开 DC/DC（功耗优化必做） */
&dcdc {
    status = "okay";
};

5.4 sysbuild 与 Partition Manager：多镜像时代

现代 nRF 产品很少只有一份固件：至少会有 bootloader + 应用，双核芯片还有 网络核镜像，nRF54H 还有 Secure Domain / System Controller 固件。sysbuild 负责把这些镜像一起构建，Partition Manager 负责把它们摆进 Flash。

# sysbuild.conf —— 打开 MCUboot
SB_CONFIG_BOOTLOADER_MCUBOOT=y

# 或打开 nRF Secure Immutable Bootloader（NSIB）
SB_CONFIG_SECURE_BOOT_APPCORE=y

# 或两者串联：NSIB 做不可变根，MCUboot 做可升级二级
SB_CONFIG_SECURE_BOOT_APPCORE=y
SB_CONFIG_BOOTLOADER_MCUBOOT=y

5.5 构建产物都在哪

build/
├── zephyr/
│   ├── zephyr.hex          # 烧录用（最常用）
│   ├── zephyr.elf          # 调试用（含符号）
│   ├── zephyr.bin
│   ├── .config             # 最终生效的 Kconfig 全量
│   └── zephyr.dts          # 最终展开的设备树
├── my_app/
│   └── zephyr/
│       ├── zephyr.signed.bin     # MCUboot 签名镜像（DFU 用）
│       └── app_update.bin        # DFU 传输用
├── mcuboot/
│   └── zephyr/zephyr.hex         # MCUboot 自身镜像
├── merged.hex                    # 合并后的完整镜像
├── partitions.yml                # 分区布局
└── build.ninja

5.6 常用命令速查