4. 网络核固件架构与蓝牙LE协议栈部署
在 nRF5340 的双核架构中,应用核(Application Core,CPU0)负责业务逻辑,而网络核(Network Core,CPU1)专职承载蓝牙 LE 协议栈的底层实时任务。理解网络核固件如何组织、SoftDevice Controller 在其中的位置、主机层如何划分,以及镜像如何烧录与版本匹配,是保证无线连接稳定可用的前提。本节围绕这条主线展开。
网络核镜像的构成
网络核上运行的固件通常被称为网络核镜像(Network Core Image)。它并不是一个单一程序,而是由若干可独立寻址、可独立更新的组件拼接而成,典型包括:
- SoftDevice Controller(SDC):Nordic 提供的蓝牙 LE 链路层(Link Layer)实现,负责广播、扫描、连接建立、信道管理、加密引擎调度、射频时序等硬实时工作。
- MPSL(Multi-Protocol Service Layer):多协议服务层,为 SDC 和可能的其他无线协议提供射频资源仲裁、时钟与低功耗管理。
- 网络核应用(Network Core App):用户可选的轻量逻辑,例如在核间通信中做转发、传感器预处理或自定义 HCI 扩展。
- 引导与分区元数据:Bootloader、镜像槽位(slot)描述、版本与校验信息,用于安全启动和固件升级。
这些组件在 Flash 中按固定地址布局,由分区表(Partition Table)描述。应用核通过 IPC(Inter-Processor Communication)与网络核交互,而不是直接访问其内存。因此,网络核镜像的地址、大小和版本必须与应用核侧的配置严格一致,否则会出现“应用核能跑、蓝牙起不来”的典型现象。
SoftDevice Controller 的职责边界
SoftDevice Controller 是网络核上最核心的组件,它实现了蓝牙 LE 的链路层。需要明确的是:SDC 只做控制器(Controller)该做的事,包括广播与扫描的射频调度、连接事件的时间锚点维护、自适应跳频、白名单过滤、链路层加密的 AES-CCM 引擎调用,以及向主机层上报 HCI 事件。它不负责 GATT 属性数据库、不负责配对流程中的密钥分发策略、也不解析业务数据。
这种划分带来两个直接后果。第一,网络核的实时性要求极高:连接间隔(Connection Interval)最小可到 7.5 ms,SDC 必须在每个连接事件前完成射频准备,因此它运行在 MPSL 提供的确定性调度之上,应用核的任何阻塞都不会直接影响射频时序。第二,主机层的实现可以灵活替换——既可以使用 Nordic 的 SoftDevice Controller 配套主机(如 nRF Connect SDK 中的 Bluetooth Host),也可以使用 Zephyr 自带的主机栈,只要 HCI 接口语义一致。
主机层的划分与核间通信
主机层(Host)运行在应用核,典型包含 GAP、GATT、SM(安全管理)、L2CAP 以及 ATT。它与 SDC 之间通过 HCI 交互,而在 nRF5340 上这条 HCI 通道并非物理 UART,而是核间 IPC。nRF Connect SDK 中通常使用 RPMsg 作为传输载体,配合 OpenAMP 框架完成消息传递。
实际部署时,应用核侧需要正确初始化 IPC 实例,并声明与网络核镜像匹配的共享内存区域。一个常见的配置片段如下(示例参数,实际以工程配置为准):
CONFIG_BT=y
CONFIG_BT_HCI=y
CONFIG_BT_HCI_IPC=y
CONFIG_BT_RPMSG=y
CONFIG_BT_RPMSG_NRF53=y
CONFIG_BT_HCI_TX_STACK_SIZE=1024
CONFIG_BT_BUF_CMD_TX_SIZE=255
CONFIG_BT_BUF_EVT_RX_SIZE=255
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_CTLR=n
CONFIG_BT_LL_SOFTDEVICE=y
其中 CONFIG_BT_CTLR=n 表示不在应用核编译链路层,CONFIG_BT_LL_SOFTDEVICE=y 表示使用网络核上的 SDC。若这两项配置错误,会出现主机层找不到控制器、HCI 命令超时或 bt_enable() 返回 -ETIMEDOUT 的现象。
固件烧录与版本匹配
nRF5340 的网络核固件需要单独烧录。使用 nrfjprog 时,网络核镜像通常以 hex 文件形式提供,通过 --coprocessor 参数指定目标核:
nrfjprog --program netcore_image.hex --coprocessor CP_NETWORK --chiperase --verify
nrfjprog --program appcore_image.hex --coprocessor CP_APPLICATION --chiperase --verify
nrfjprog --reset
若使用 nRF Connect SDK 的 west 工具,一条 west flash 通常会自动处理两个核的镜像,但前提是构建产物中包含了网络核镜像。只烧录应用核而遗漏网络核,是初学者最常见的错误之一,表现为应用核正常运行但蓝牙完全无响应。
版本匹配是另一个关键点。SDC 的版本、主机层(Bluetooth Host)的版本、以及分区表中声明的镜像版本必须相互兼容。nRF Connect SDK 通过 west manifest 锁定各组件版本,升级 SDK 时应整体更新,而不是单独替换某一个 hex。若出现 SDC assert 或 HCI command disallowed,应优先检查:网络核镜像是否与当前 SDK 匹配、应用核的 CONFIG_BT_LL_SOFTDEVICE 是否指向正确版本、以及分区表地址是否与网络核镜像的链接地址一致。
BT_HCI_EVT_CMD_COMPLETE 且 bt_enable() 返回 0,说明 IPC 通道与 SDC 均已就绪;若卡在 bt_enable(),则问题多半在网络核镜像或 IPC 配置。部署检查要点
| 检查项 | 正确状态 | 常见错误 |
|---|---|---|
| 网络核镜像 | 已烧录且版本与 SDK 一致 | 只烧应用核,网络核为空 |
| SDC 配置 | CONFIG_BT_LL_SOFTDEVICE=y | 误开 CONFIG_BT_CTLR 导致双控制器冲突 |
| IPC 通道 | RPMsg 初始化成功 | 共享内存地址与分区表不符 |
| HCI 缓冲区 | ACL/EVT 大小与 SDC 匹配 | 缓冲区过小导致大包被丢弃 |
| 版本一致性 | SDC、Host、分区表三者匹配 | 单独替换 hex 造成版本错位 |