简介：艾克姆科技飞宇团队编写的《nRF52832 开发指南》上册，以 IK-52832DK 开发套件为硬件平台，基于 Nordic 官方 SDK15.2，面向刚接触蓝牙低功耗（BLE 5.0）与 2.4GHz 无线 SoC 的中初级嵌入式开发者，帮助他们从最简单的裸机工程起步，逐步建立对外设与软件框架的整体认知。压缩包内含 1 个 PDF 文件，约 18.57MB，单文件结构便于离线通读、打印和随查随用。正文先做开发板硬件描述，逐项解析 nRF52832 的 Cortex-M4 内核与外设资源、电源与低功耗模式、指示灯与轻触/触摸按键、蜂鸣器、电位器检测、红外接收、USB 转 UART、I2S 音频与显示模块接口、WiFi 与 NFC 天线、温湿度与 PM2.5 及运动传感器接口、TF 卡座和调试接口；再讲解开发工具与各外设实验，每个例子都注明基于哪个工程修改、需新增哪些文件、头文件如何引用和包含，目录按模块分层，便于对照硬件原理同步实践。目前已有 2514 人学习。

1. 一块 52832 板子到手先别插 USB：版本对不上，后面全是白工

上周又有人拿着一块 nRF52832 开发板来问，说 MDK 明明编译通过了，下载死活连不上芯片。查了半天，问题不在板子，也不在代码，而是他电脑上同时存在两份 J-Link 驱动，MDK5.23 调用的是旧的那份 DLL，被新版覆盖之后版本对不上，于是每次下载都卡在“连接目标”这一步。这类事我见得太多。nRF52832 是 BLE 5.0 和 2.4GHz 私有协议里被选得最多的一颗 SoC，Nordic 的 SDK15.2 又是大多数人入门的第一个版本，这两样凑在一起，对环境版本异常敏感：MDK 版本、Device Family Pack、J-Link 驱动、SDK 目录结构，任何一个环节错位，表现都是同一句话——编译通过，下载失败。这篇按我自己装机的顺序走一遍，从空白系统装到 LED 能闪，新手能照着做，重装老环境的人也能对上号。

2. 装什么、装哪个版本：SDK15.2 环境清单与六件套安装顺序

装 Nordic 这套环境，最忌讳“先把能下的都下下来”。nRF52832 的坑几乎全在版本搭配上，装错版本不是报错那么简单，而是报一个跟真实原因完全无关的错，让你在错误的方向上排查一整天。所以这一章先把清单和顺序定死，再动手。

2.1 为什么把 MDK 锁在 5.23，而不是装最新版

SDK15.2 是 2018 年前后发布的，它自带的示例工程用的是 Arm Compiler 5（也就是常说的 AC5），工程文件是.uvprojx格式，用 MDK5.23 打开最顺。如果你图省事装了 MDK5.37 之后的版本，第一件遇到的事就是打开工程直接弹窗：目标使用的编译器版本 5 不可用。因为从 5.37 开始，Keil 安装包默认不再附带 AC5，只带 AC6。

这时候有两条路：一条是去单独下载 Arm Compiler 5 并挂到 Keil 里，另一条是硬着头皮用 AC6 编 SDK15.2。第二条路的血泪经验是：__weak、内联汇编、__align这些写法在 AC6 下会刷出几百条告警，部分还会直接变成错误，新手很容易陷在里面出不来。所以常规做法是：新机器直接装 MDK5.23，跟 SDK15.2 同期的工具链，省掉所有兼容性折腾。

反过来说，MDK 也不能太老。5.14 之前的版本对 nRF52 系列的 pack 支持不完整，器件列表里根本选不到 nRF52832。5.23 这个点，是这套环境里我验证过最稳的。

2.2 六个组件版本对照表，以及装错各是什么表现

把要装的东西列成一张表，装完一项划掉一项。表里最后一列比版本号更有用，它告诉你装错之后会看到什么，方便你反查。

这里特别说一下 pack。Nordic 的 pack 名字叫 nRF_DeviceFamilyPack，装完之后你在 Keil 的 Pack Installer 里能看到 nRF52 Series 那一栏变成绿色。版本不必追求最新，跟 SDK15.2 同期发布的 8.x 就够用，新版 pack 有时候反而会把老工程的下载算法换掉。

2.3 路径规划：中文、空格、同步盘是三个隐形炸弹

在装任何东西之前，先把目录定下来。这套工具链对路径的容忍度很低，我踩过的坑集中在三类：路径里有中文、路径里有空格、工程放在 OneDrive 或某个自动同步目录里。

中文路径的问题出在编译器和 J-Link 之间的临时文件传递上，表现是编译能过、下载时提示找不到某个.axf或者hex文件。空格的问题更隐蔽，某些版本的下载算法解析路径时会把空格当分隔符，于是你的工程目录被截成两半。同步盘的问题是编译过程中文件被实时上传锁定，随机出现“无法写入输出文件”。

我的习惯是固定一个盘的根目录建nrf文件夹，SDK、工程、工具全部放进去，路径全英文、无空格：

# Git Bash 下先把目录骨架建出来，后面所有东西都往里放 mkdir -p /d/nrf/sdk15.2 # SDK 解压后的位置 mkdir -p /d/nrf/project/led_blink # 第一个裸机工程 mkdir -p /d/nrf/tools # 驱动、安装包统一收纳

三行命令没什么技术含量，但它决定了后面两小时你是顺风顺水还是反复怀疑人生。SDK 解压包本身有几百兆，解压前确认目标盘剩余空间够，解压过程中不要中途取消，半截的 SDK 目录会导致头文件缺失，而且报错信息完全指不到根因。

2.4 按顺序装：串口驱动 → MDK5.23 → pack → nRFgo Studio → J-Link

顺序是有讲究的。串口驱动先装，是因为后面无论哪一步出问题，你都需要一个能看日志的通道；nRFgo Studio 排在独立 J-Link 驱动之前，是因为它自带一份 J-Link 驱动，先装它、后装新版，才能让新版覆盖旧版；MDK 排在 pack 之前，是因为 pack 要通过 Keil 的 Pack Installer 安装。

第一步，串口驱动。插上板子的 USB 线，打开 PowerShell 看设备状态：

# 列出所有串口类设备，重点看有没有带感叹号或者显示未知设备 Get-PnpDevice -Class Ports | Format-Table -AutoSize

正常情况下你会看到一个USB-SERIAL CH340 (COM3)或者Silicon Labs CP210x (COM4)之类的条目。如果显示未知设备，就把厂商驱动装上，装完重新插拔一次 USB。这一步没做通的直接后果是：后面程序跑起来了，你却看不到任何串口输出，会误判成程序没跑。

第二步，MDK5.23。安装路径保持默认或者用C:\Keil_v5，不要带空格。装完之后先打开一次，让它把 Pack 根目录初始化出来。这里提一句 license：评估版有 32KB 代码限制，nRF52832 的裸机例程通常够用，但一旦加上 BLE 协议栈，很容易超。正式项目请走正版授权，不要在这上面找偏门，后面出问题排查成本更高。

第三步，pack。两种装法：联网的话在 Keil 里打开 Pack Installer，等它拉完索引，在 Nordic Semiconductor 下面找 nRF52 Series，点 Install；离线的话直接双击下载到的.pack文件。装完验证一下：

# Keil 的 pack 默认落在这个位置，能看到 nRF_DeviceFamilyPack 目录就对了 ls "$HOME/AppData/Local/Arm/Packs/NordicSemiconductor"

第四步，nRFgo Studio。这个工具现在看有点老，但它的价值在于能把 SoftDevice 和应用分开烧，还能一键全片擦除。装的时候如果系统提示缺少运行库，把对应的 VC 运行库补上再重装一次，不要跳过。

第五步，J-Link 驱动。安装过程中会弹窗问你是否要更新 Keil 目录下的 J-Link DLL，选“是”。这一步是前面提到的那个经典翻车的根本解药：Keil 5.23 自带的 J-Link DLL 很旧，跟新硬件固件通信会失败，必须让 SEGGER 的安装程序把它替换掉。装完打开 J-Link Commander，启动横幅第一行会打印版本号，跟你在安装包里看到的对一下，一致就说明覆盖成功。

2.5 手机端工具与固件版本：把 BLE 5.0 的验证链路一次补齐

裸机阶段用不到手机，但既然目标是 BLE 5.0，建议这一步顺手装好。手机端装一个通用的 BLE 调试 App（nRF Connect 这一类），作用是后面烧了广播例程之后，你能立刻在手机上看设备有没有真的发出来，而不用先去写手机端代码。这一步看着跟装环境无关，实际上是给自己留一条独立于 PC 的验证通道：当 PC 端串口、J-Link、MDK 全都在互相甩锅的时候，手机能扫到广播，就说明芯片和协议栈都是好的，问题一定在 PC 侧。

另外，J-Link 的固件版本如果和驱动不匹配，Commander 会提示升级，跟着提示点确认就行。但要注意，量产的板子上不要随手升固件，升坏了恢复起来麻烦，开发板随便折腾。

3. 新建裸机工程：四个选项卡填错一个就编译不过

环境装完不等于能跑。SDK15.2 不带“一键新建工程”的功能，它给的是示例工程，而示例工程里塞了大量你当前用不到的文件。我一般不从示例复制，而是从空目录新建，这样每一份加进来的文件你都知道它为什么在这。这个过程麻烦一点，但后面出问题时你能定位。

3.1 工程目录规划与库文件拷贝

先明确要拷什么。SDK15.2 的目录里，components是外设驱动和库，modules/nrfx是 nrfx 底层硬件抽象层，integration/nrfx是 nrfx 与 SDK 之间的适配层，external/segger_rtt是 RTT 调试输出。启动文件和系统文件在modules/nrfx/mdk下。

cd /d/nrf/project/led_blink # 1. 拷驱动库与硬件抽象层，这四个目录是裸机工程的最小集合 cp -r /d/nrf/sdk15.2/components ./ cp -r /d/nrf/sdk15.2/modules/nrfx ./ cp -r /d/nrf/sdk15.2/integration/nrfx ./ cp -r /d/nrf/sdk15.2/external/segger_rtt ./ # 2. 拷 ARM 汇编启动文件和系统初始化文件，注意芯片型号要对上 52832 cp /d/nrf/sdk15.2/modules/nrfx/mdk/arm_startup_nrf52832.s ./ cp /d/nrf/sdk15.2/modules/nrfx/mdk/system_nrf52832.c ./

第一条命令里的四个目录，各自承担不同角色。components里放着boards、libraries/util这些公共件，nrf_delay这类基础函数就在里面找。modules/nrfx里是nrf_gpio.h、nrf_uarte.h这一层，直接操作寄存器。integration/nrfx是胶水层，缺了它会出现一堆undefined symbol，而且报错指向的文件你根本没引用过，非常迷惑人。

第二条命令里的两个文件必须成对出现：arm_startup_nrf52832.s定义中断向量表，system_nrf52832.c负责时钟初始化。文件名里的52832不能写错，SDK 里同时有 52810、52840 的版本，拷错了编译能过，跑起来行为不对。

3.2 新建工程与分组

打开 MDK，Project → New μVision Project，保存到led_blink目录，器件选nRF52832_xxAA。随后弹出的 Manage Run-Time Environment 窗口直接取消，不要在这里勾组件——这一步勾了会自动引入 CMSIS 的启动文件，跟你刚拷进来的汇编启动文件冲突，链接阶段会报重复定义。

工程建好后右键 Target 新建分组，我一般分五个：Application（放 main.c）、Startup（放启动文件和 system 文件）、nrfx（放modules/nrfx里的驱动源文件）、SDK（放components里用到的库）、RTT（放 segger_rtt 的源文件，用于调试打印）。分组本身不影响编译，但出问题时你能一眼看出是哪个层次的代码在报错。

3.3 Target 与 Output 选项卡：地址、晶振、输出目录

Target 选项卡里改三项。第一项是晶振，nRF52832 的外部高速晶振填 32MHz，低速填 32768Hz，这跟板子上焊的晶振一致，填错了 BLE 起不来。第二项是 ROM 和 RAM 区域，裸机工程按芯片实际容量填：

如果后面要烧带协议栈的 BLE 程序，IROM1 的起始地址要改成 0x00026000，这是 S132 6.1.x 占用完之后的应用程序起始位置，大小相应改成 0x5A000。RAM 的起始地址也要往后挪，具体值以 SDK 里的说明为准，不要凭记忆填，这是烧完跑飞的常见原因。

Output 选项卡勾上 Create HEX File，并把输出目录单独指定成build。这么做有两个好处：一是生成的 hex 文件路径固定，后面用 J-Flash 或 nRFgo Studio 烧的时候不用满目录找；二是编译产物集中，想全清的时候直接删目录，干净利落。

3.4 C/C++ 选项卡：宏定义与头文件路径

这一页是最容易漏的。Define 里必须写NRF52832_XXAA，它的作用是让nrf.h走对分支，找到正确的寄存器定义和中断号。不写的话，第一条报错就是编译期直接抛出“设备未定义”，新手看到这句话往往一头雾水，因为它跟“宏”没有字面关联。

头文件路径逐条加进去：

.\components .\components\boards .\components\libraries\util .\modules\nrfx .\modules\nrfx\hal .\modules\nrfx\mdk .\integration\nrfx .\integration\nrfx\legacy .\external\segger_rtt

这九条路径对应的是刚才拷进来的目录结构。少一条的典型表现是：能编过 90% 的文件，最后在某个驱动的.c文件里报找不到头文件，而那个头文件明明就在工程目录里躺着。这时候别慌，把报错里的头文件名在工程目录搜一下，看它所在的目录是否在列表里，大概率就是漏了一条。

3.5 Debug 选项卡与 Flash 下载算法

Debug 页选J-LINK / J-TRACE Cortex，点右边的 Settings，Port 选 SW，Max Clock 先手动压到 1MHz。速度这块有个玄学现象：同样的板子，2MHz 能连上，4MHz 就报连接失败，而失败原因显示的是“找不到设备”，让人以为是接线问题。降速是成本最低的排除手段。

再进 Flash Download 页，确认三件事：Programming Algorithm 里有nRF52xxx系列算法且起始地址 0x00000000；勾上 Erase Sectors、Program、Verify；RAM for Algorithm 填 0x20000000，大小 0x4000。算法这一栏没加载上，下载时会直接报 Cannot Load Flash Programming Algorithm，这个错跟代码一点关系都没有。

3.6 main.c 与第一次编译

新建main.c加进 Application 分组，写一个最小可跑的版本：

#include <stdbool.h> #include "nrf.h" #include "nrf_gpio.h" #include "nrf_delay.h" #define LED_PIN 17 /* 换成你板子上 LED 实际连接的引脚，以原理图为准 */ int main(void) { nrf_gpio_cfg_output(LED_PIN); /* 配成推挽输出，默认输出低电平 */ while (true) { nrf_gpio_pin_toggle(LED_PIN); /* 翻转电平，实现亮灭交替 */ nrf_delay_ms(500); /* 500ms 一次，肉眼可见的闪烁频率 */ } }

nrf_gpio_cfg_output内部做两件事：把方向寄存器对应位置成输出，同时把输出电平清成低，所以上电后灯是灭的，第一次进循环才点亮。nrf_delay_ms是忙等延时，不占用定时器，用来做第一个实验最合适。注意它的源文件（nrf_delay.c）要加进工程，否则编译报 undefined symbol；不同 SDK 小版本里这个文件的位置略有差别，直接在 SDK 目录搜文件名最快。

编译。如果报了一堆 undefined symbol，先回头查 3.1 里integration/nrfx有没有拷全；如果报“设备未定义”，回到 3.4 看宏；如果nrf_gpio.h找不到，就是头文件路径漏了modules/nrfx/hal。这三种情况的报错信息完全不同，按报错对号入座即可。

4. 程序下载：MDK、J-Flash、nRFgo Studio 三条路怎么走

编译出 hex 只是第一步，能不能进芯片是另一回事。这条链路上有三段：PC 侧的驱动、下载器、芯片的读写保护状态。三条下载路径的差别，本质上就是这三段由谁来管。

4.1 MDK 直接下载：裸机和 BLE 程序是两种打法

裸机程序最简单。工程配置好之后直接点下载按钮，看 Build Output 窗口打出 Programming Done 和 Verify OK 就结束。如果这里就失败，先去看第 5 章的排查条目，不要继续往下试。

BLE 程序不一样，它分两段：协议栈（SoftDevice）和应用。协议栈是一个独立的 hex，地址从 0x00000000 开始，长度约 0x26000；应用从 0x00026000 开始。常规做法是先烧协议栈，再烧应用，两次之间不要全片擦除，否则协议栈就没了。在 MDK 里烧协议栈，可以把协议栈的 hex 单独建一个工程，或者更省事：用 J-Flash 或 nRFgo Studio 烧协议栈，应用继续用 MDK 下载，两者互不干扰。

4.2 J-Flash：独立于 MDK 的下载通道

J-Flash 是单独的程序，不依赖 Keil 的工程配置。打开之后新建工程，器件选 nRF52832_xxAA，接口 SW，速度 1000kHz，然后在 Hex 文件里指定你要烧的那个文件。

它的最大价值是判断故障边界。当 MDK 下载失败、你怀疑是代码问题时，用 J-Flash 烧一个最简 hex 进去。如果 J-Flash 也烧不进去，说明问题在硬件连接或芯片状态，跟你的代码完全无关，能省掉大量无意义的排查。

# J-Flash 里的典型操作顺序 Target -> Connect 连接目标，成功会显示芯片型号和 Flash 大小 Target -> Erase Sectors 擦除要用的扇区 Target -> Program & Verify 烧写并校验 Target -> Start Application 让程序跑起来

擦除这一步不要省。很多“烧进去了但不跑”的情况，根源是上一版程序留下的扇区数据没清干净，尤其是改过链接地址之后。

4.3 nRFgo Studio：协议栈和应用分开烧的正规做法

nRFgo Studio 的 Program 选项卡下有两个区：Program SoftDevice 和 Program Application。先在前者里选 S132 的 hex 烧进去，再在后者里选你的应用 hex。它的好处是界面上明确区分这两段，不容易搞混地址。

这个工具还能看芯片信息，包括 Flash 大小、是否开启了读保护。当你怀疑芯片被锁的时候，先进这里看一眼状态，比盲试快得多。老版本的 nRFgo Studio 对 nRF52 支持不完整，装 1.21 以上的版本，否则 nRF52 相关页面可能直接灰掉。

4.4 全片擦除与读保护：芯片连不上时的后悔药

nRF52 系列有一个读保护机制，一旦被打开，J-Link 就连不上芯片，读 ID 都会失败，表现跟“芯片烧坏了”一模一样。触发原因很多：烧了一个带保护位的程序、用别的工具误操作、甚至某些下载失败的重试。

解药是全片擦除。三种途径按顺手程度排：nRFgo Studio 里的 Erase all、J-Link Commander 里执行erase、或者装一份 nRF Command Line Tools 用nrfjprog --recover。最后这条最彻底，它会连保护位一起清掉，代价是芯片里所有内容全部丢失，包括协议栈。所以平时开发时我不会随手开保护，只在出货前处理。

5. 排查避坑：编译和下载阶段最常见的五个翻车现场

这一章按“现象 → 原因 → 解决”整理，都是我在自己机器和别人的机器上反复见到的。遇到问题先在这里对一遍，能省掉大量时间。

5.1 现象：No Cortex-M device found in JTAG chain

现象是点下载后右上角进度条走两下就报这句，MDK 里连设备都识别不到。

原因通常有三个层次。最外层是接线，SWDIO、SWCLK、GND 三根线少一根或者接反；中间层是供电，板子靠 USB 供电但电流不够，或者 J-Link 没有共地；最里层是芯片处于读保护状态，直接拒绝调试访问。

解决顺序是：先换一根确定能传数据的 USB 线（很多线只供电不传数据，这是最容易忽略的一条），再确认 J-Link 和板子共地，然后在 Debug 设置里把 Max Clock 降到 100kHz 试一次。三步都不行，就按 4.4 做全片擦除恢复。

5.2 现象：Cannot Load Flash Programming Algorithm

这句报错看着吓人，其实跟算法文件关系最大，跟代码没关系。

原因一般是 Debug 页的 Flash Download 里没有加载 nRF52xxx 的算法，或者加载了但起始地址不对。还有一种情况是 pack 装的是别的系列，算法文件路径指向的目录不存在。

解决：进 Flash Download 页，把列表里的算法全部移除，重新 Add，选 nRF52xxx 系列，起始地址确认是 0x00000000。如果列表里根本找不到这个算法，回 2.4 重装 pack。改完记得点 OK 保存，直接关窗口不生效。

5.3 现象：Error: Flash Download failed - Target DLL has been cancelled

这是 J-Link 驱动版本冲突的招牌报错，几乎百分百出在 DLL 上。

原因是 Keil 目录下的JLinkARM.dll和 SEGGER 安装目录下的版本不一致。常见于先装了新版 J-Link 驱动、后来又重装了 Keil，Keil 把自己带的旧 DLL 又覆盖回去了。

解决：重新跑一遍 J-Link 驱动的安装程序，在弹窗问是否更新 Keil 的 DLL 时选是。装完打开 J-Link Commander 记下版本号，再去 Keil 安装目录下看JLinkARM.dll的文件版本，两个对不上就手动从 SEGGER 目录复制过去覆盖。这一步做完最好重启一次 Keil，DLL 被占用时覆盖会失败但界面不报错。

5.4 现象：编译报设备未定义，或者一堆 undefined symbol

这两类报错经常一起出现，让人以为工程彻底坏了。

“设备未定义”对应的是 C/C++ 里缺NRF52832_XXAA宏。“undefined symbol”分两种：符号名是nrf_delay_ms、nrf_gpio_cfg_output这类，说明对应的.c文件没加进工程；符号名是nrfx_xxx这类带 nrfx 前缀的，通常是integration/nrfx目录没拷或者路径没加。

解决：先补宏，再从头文件路径列表逐条核对，最后看 Build Output 里第一个报错的文件名，从那个文件往上追它引用的头文件。不要从最后一条报错往回看，链接期的报错顺序跟真实原因经常是反的。

5.5 现象：下载成功但 LED 不亮，或者只闪一下就停

下载日志全绿，程序就是不按预期跑，这类问题最消耗耐心。

三种常见原因。一是引脚号写错了，LED_PIN是照抄例程的，跟自己板子的原理图对不上；二是链接地址不对，烧的是裸机程序但 IROM1 还停留在 0x00026000，程序被放到了错误的位置，芯片从 0 地址启动后执行的是空白区；三是程序进了 HardFault，在某个初始化里死循环，表现就是灯不闪。

解决：先核对原理图确认引脚，再核对 Target 页的 IROM1 起始地址，最后单步调试看能不能走到while循环里。如果连main都进不去，基本就是地址问题或者启动文件拷错了型号。

6. 装完怎么验证：三个判据把一个 LED 工程跑成基准

环境装完之后，你需要一个可复现的“基准状态”。我的做法是先不碰业务代码，用一个最简 LED 工程把整条链路跑通，跑通之后所有后续问题都可以拿它做对照。

第一个判据是编译产物。Output 目录下要能看到.axf和.hex两个文件，hex 的大小在几 KB 量级。如果 hex 是 0 字节或者只有几十字节，说明链接阶段出了问题，先回去看 5.4。

第二个判据是下载日志。Build Output 里应该依次出现 Erase Done、Programming Done、Verify OK 三行。注意 Verify OK 这一行，很多人只看 Programming Done 就以为成功了，实际上校验失败往往意味着芯片里的内容和 hex 不一致，可能是算法地址错了，也可能是芯片有坏块。

第三个判据是现象本身。LED 以 500ms 的间隔稳定闪烁，不间断、不加速、不熄灭。这时候用示波器或者逻辑分析仪量一下引脚，方波周期应该是 1 秒，占空比 50%。如果周期明显偏移，说明系统时钟配置有问题，回去看 Target 页的晶振设置。

最后补一条：拔掉 USB 重新插上，程序应该照常运行，不需要重新下载。这一步验证的是程序真的写进了 Flash，而不是只停留在调试器的缓存里。如果重上电就不跑，问题多半在启动文件或者向量表偏移。

从那以后我每次重装这套环境，都会强制先跑一遍这个 LED 工程，确认三个判据全部通过，再去碰 SDK 里那些外设例程。基准状态有了，后面遇到 UART 没输出、定时器不触发、BLE 起不来，你都能确定是那一层的配置问题，而不是环境本身在作怪。这套流程不复杂，麻烦的是每次都坚持走完。希望帮到你。

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