Nordic nRF52810 OTA升级踩坑记：烧录后程序不运行？手把手教你生成bootloader_setting.hex

NordicnRF52810OTADFU

|难度：普通|阅读约 16 分钟

Nordic nRF52810 OTA升级实战：从Bootloader Settings解析到完整解决方案

第一次在nRF52810上尝试OTA升级时，我遇到了一个令人抓狂的问题——按照官方文档烧录了bootloader、softdevice和application后，设备死活不进应用程序，而是不断循环在bootloader模式。经过整整两天的调试和查阅资料，终于发现问题的核心在于那个容易被忽略的bootloader_settings.hex文件。本文将分享这个问题的完整解决路径，从内存布局解析到实际操作命令，帮助开发者避开这个经典陷阱。

1. 问题现象与根源分析

当你按照Nordic官方文档的步骤，使用nRF Connect或命令行工具依次烧录了以下三个文件后：

s112_nrf52_7.2.0_softdevice.hex
bootloader.hex
application.hex

理论上设备应该直接运行你的应用程序，但实际情况却是：

设备重启后LED指示灯呈现DFU模式特有的呼吸灯效果
串口输出显示设备停留在bootloader状态
无法通过常规方式进入应用程序

根本原因在于nRF52系列芯片的启动流程设计。芯片上电后的执行顺序如下：

code复制MBR → Bootloader → Bootloader检查Settings → 跳转Application

当bootloader_settings区域不存在或数据无效时，bootloader会认为没有可用的应用程序，从而保持在DFU模式等待升级。这与我们直接烧录.hex文件的操作方式有直接关系：

操作方式	Bootloader Settings生成机制
OTA升级	Bootloader自动生成和维护
直接烧录	需要手动生成并烧录

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. nRF52810内存布局深度解读

要彻底理解这个问题，必须掌握nRF52810的内存映射特性。这款芯片的Flash总共192KB，其分配方式与其他nRF52系列有所不同：

code复制0x00000000 ┌───────────────┐
           │     MBR      │ (4KB)
0x00001000 ├───────────────┤
           │  SoftDevice  │ (96KB)
0x00019000 ├───────────────┤
           │ Application  │ (60KB)
0x00028000 ├───────────────┤
           │  Bootloader  │ (24KB)
0x0002E000 ├───────────────┤
           │ MBR Params   │ (4KB)
0x0002F000 ├───────────────┤
           │ Bootloader   │ (4KB)
           │  Settings    │
0x00030000 └───────────────┘

关键区域说明：

MBR (Master Boot Record)：芯片启动后最先运行的代码，负责跳转到SoftDevice或Bootloader
Bootloader Settings：存储应用程序的CRC、大小、版本等元数据
Application区域：实际应用程序代码存放位置

特别需要注意的是nRF52810的存储容量限制：

最大Application大小：60KB (0x19000-0x28000)
Bootloader Settings地址：0x0002F000-0x00030000

3. 生成bootloader_settings.hex的完整流程

解决这个问题的核心是正确生成bootloader_settings.hex文件。以下是经过验证的操作步骤：

首先确保已安装nrfutil工具（推荐版本6.1+）：
```
bash复制pip install nrfutil
```

使用以下命令生成设置文件：

bash复制nrfutil settings generate \
  --family NRF52810 \
  --application your_app.hex \
  --application-version 1 \
  --bootloader-version 1 \
  --bl-settings-version 2 \
  bootloader_settings.hex

参数详解：

--family：必须指定为NRF52810，不同芯片内存布局不同
--application：指向你的应用程序hex文件路径
--application-version：与应用版本号一致，用于版本校验
--bl-settings-version：设置版本，通常用2（最新）

完整烧录顺序：

bash复制nrfjprog --program s112_nrf52_7.2.0_softdevice.hex --sectorerase
nrfjprog --program bootloader.hex --sectorerase
nrfjprog --program application.hex --sectorerase
nrfjprog --program bootloader_settings.hex --sectorerase
nrfjprog --reset

重要提示：每次更新application.hex后都需要重新生成bootloader_settings.hex，因为应用程序的CRC校验值会改变。

4. 高级调试技巧与常见问题排查

即使按照上述步骤操作，仍可能遇到各种意外情况。以下是几个实战中总结的排查方法：

现象1：生成settings文件时报错"Invalid application hex file"

检查hex文件是否完整，尝试用hex编辑器查看
确认芯片家族参数是否正确（常见错误是误用NRF52832）

现象2：烧录后设备立即进入DFU模式

使用nRF Connect读取0x2F000-0x30000区域，验证settings是否烧录成功
检查应用程序是否超出允许的内存范围

现象3：OTA升级后应用程序不运行

对比Bank0和Bank1的内容差异：

bash复制nrfjprog --readcode --addr 0x19000 --n 0xF000 bank0.bin
nrfjprog --readcode --addr 0x28000 --n 0x6000 bank1.bin

内存验证命令：

bash复制# 读取Bootloader Settings区域内容
nrfjprog --readcode --addr 0x2F000 --n 0x1000 settings.bin

# 使用hexdump查看关键数据
hexdump -C settings.bin | head -n 20

典型正确的settings文件应包含以下特征数据：

偏移0x000：0x01 0x00 (版本标记)
偏移0x200：应用程序的CRC32值
偏移0x204：应用程序大小

5. 自动化构建集成方案

对于需要频繁调试的项目，建议将settings生成步骤集成到构建系统中。以下是几种常见方案：

Makefile集成示例：

makefile复制DFU_SETTINGS = bootloader_settings.hex

$(DFU_SETTINGS): $(APPLICATION_HEX)
	nrfutil settings generate --family NRF52810 \
		--application $(APPLICATION_HEX) \
		--application-version $(APP_VERSION) \
		--bootloader-version $(BL_VERSION) \
		--bl-settings-version 2 \
		$@

flash: $(DFU_SETTINGS)
	nrfjprog --program $(SOFTDEVICE_HEX) --sectorerase
	nrfjprog --program $(BOOTLOADER_HEX) --sectorerase
	nrfjprog --program $(APPLICATION_HEX) --sectorerase
	nrfjprog --program $(DFU_SETTINGS) --sectorerase
	nrfjprog --reset

PlatformIO集成方案：
在platformio.ini中添加自定义目标：

ini复制[env:nrf52810]
platform = nordicnrf52
board = nrf52810_dk
extra_scripts = 
    pre:scripts/generate_settings.py

对应的Python脚本：

python复制Import("env")
import subprocess

def generate_settings(source, target, env):
    app_hex = env.subst("$BUILD_DIR/${PROGNAME}.hex")
    cmd = [
        "nrfutil", "settings", "generate",
        "--family", "NRF52810",
        "--application", app_hex,
        "--application-version", "1",
        "--bootloader-version", "1",
        "--bl-settings-version", "2",
        "bootloader_settings.hex"
    ]
    subprocess.run(cmd, check=True)

env.AddPreAction("buildprog", generate_settings)

6. 不同开发场景下的应对策略

根据不同的开发阶段和需求，处理bootloader settings的策略也应有所调整：

开发调试阶段：

在IDE中配置post-build命令自动生成settings
使用J-Link Commander脚本一键烧录全部组件
保留串口日志输出，实时监控bootloader决策过程

量产编程方案：

将softdevice、bootloader、application和settings合并为单个hex

使用nrfutil生成包含所有组件的完整镜像：

bash复制nrfutil pkg generate --hw-version 52 \
  --application-version 1 \
  --application app.hex \
  --bootloader bootloader.hex \
  --softdevice softdevice.hex \
  --sd-req 0x0103 \
  --key-file private.pem \
  full_image.zip

OTA升级注意事项：

确保bootloader settings区域在DFU过程中不被意外擦除
对于双Bank升级，需要特别处理Bank切换时的settings更新
在应用程序中添加自检逻辑，验证settings的完整性

经过多个项目的实践验证，正确处理bootloader settings是确保nRF52810 OTA功能稳定运行的关键。特别是在产品量产前的测试阶段，建议建立完整的settings验证流程，避免因配置错误导致设备变砖。