2、环境搭建：安装nRF Connect SDK、Zephyr RTOS、TFLite Micro依赖，配置编译工具链与调试器

nRF TFLite Micro部署的起点并非模型本身，而是构建一套完整、可复现且与硬件匹配的嵌入式开发环境。nRF Connect SDK（nCS）并非一个孤立的SDK，它基于Zephyr RTOS构建，而TFLite Micro则作为Zephyr的模块（Module）被集成。本章将深入拆解从零搭建这套环境的完整流程，涵盖nCS版本选择、Zephyr west工作流、TFLite Micro依赖注入、GNU Arm工具链配置以及J-Link调试器对接，并针对Nordic nRF52/nRF53/nRF91系列芯片的差异给出具体操作指引。

主机层 (Ubuntu/WSL2) 工具链层 目标板层 (nRF52/53/91) nRF Connect SDK (nCS) west workspace (.west) Zephyr RTOS 内核 TFLite Micro 模块 GNU Arm GCC J-Link GDB nRF52840 DK nRF5340 DK nRF9160 DK west update west build 烧录/调试 UART/SPI

上图展示了整个部署环境的四层逻辑关系：主机层负责管理源码与构建配置，工具链层完成编译与调试，目标板层是模型推理的物理载体。理解这一分层结构有助于在后续配置中快速定位问题——例如链接错误往往源于工具链版本不匹配，而运行崩溃则可能指向目标板内存布局配置错误。

2.1 核心原理：nCS、Zephyr与TFLite Micro的依赖关系

nRF Connect SDK本质上是一个“元包”，它通过west工具将Zephyr RTOS、Nordic专有驱动、TFLite Micro以及必要的第三方库组织为一个统一的源码树。Zephyr使用Kconfig进行编译时配置，使用设备树（Device Tree）描述硬件资源，而TFLite Micro则作为Zephyr的一个外部模块，通过west.yml清单文件被拉取到modules/lib/tflite-micro目录下。这种设计使得模型推理框架与RTOS内核解耦，但同时也意味着版本兼容性必须严格匹配——例如nCS v2.5.0对应Zephyr v3.5.0，而TFLite Micro的提交哈希则被锁定在nCS的west.yml中。

理解这一依赖链的关键在于：不要单独升级某个组件。如果手动将Zephyr更新到更高版本，很可能导致TFLite Micro的Kconfig选项失效，或者设备树绑定不兼容。正确的做法是始终以nCS的版本发布说明为准，使用west update命令同步所有模块到锁定版本。

2.2 操作流程：从零构建完整开发环境

以下流程以Ubuntu 22.04 LTS（或WSL2）为宿主机，目标板为nRF52840 DK为例。整个过程分为四个阶段，每个阶段都有明确的验证点。

阶段一：安装基础依赖与获取nCS

# 1. 安装系统依赖
sudo apt update
sudo apt install --no-install-recommends git cmake ninja-build gperf \
  ccache dfu-util device-tree-compiler wget \
  python3-dev python3-pip python3-setuptools python3-tk python3-wheel xz-utils file \
  make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1

# 2. 创建nCS目录并获取west
mkdir -p ~/ncs
cd ~/ncs
python3 -m pip install --user west
echo 'export PATH=~/.local/bin:"$PATH"' >> ~/.bashrc
source ~/.bashrc

# 3. 获取nRF Connect SDK v2.5.0（以该版本为例）
west init -m https://github.com/nrfconnect/sdk-nrf --mr v2.5.0
cd nrf
west update

执行west update后，系统会从多个Git仓库拉取Zephyr、TFLite Micro、mcuboot等模块。该过程耗时约10-20分钟，取决于网络状况。验证方法：检查~/ncs/modules/lib/tflite-micro目录是否存在，且其内容非空。

阶段二：安装Zephyr Python依赖与工具链

# 安装Zephyr的Python包
cd ~/ncs
pip3 install --user -r zephyr/scripts/requirements.txt

# 安装GNU Arm嵌入式工具链（版本需与nCS匹配，推荐12.2.rel1）
cd ~
wget https://developer.arm.com/-/media/Files/downloads/gnu/12.2.rel1/binrel/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi.tar.xz
tar xf arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi.tar.xz
echo 'export PATH=~/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi/bin:"$PATH"' >> ~/.bashrc
source ~/.bashrc

# 验证工具链
arm-none-eabi-gcc --version

注意：nCS v2.5.0要求GCC版本不低于10.3，但推荐使用12.2，因为该版本对Cortex-M33（nRF5340）和Cortex-M55（nRF9160）的支持更完善。如果使用nRF52系列（Cortex-M4），10.3版本亦可，但为了统一管理，建议所有项目使用同一工具链。

阶段三：配置TFLite Micro依赖

TFLite Micro在nCS中默认并未启用，需要手动在应用配置中开启。首先，在应用目录下创建west.yml（如果不存在），并添加TFLite Micro模块路径。但更常见的做法是直接使用nCS提供的示例项目作为起点：

# 复制官方TFLite示例
cp -r ~/ncs/nrf/samples/machine_learning/hello_world ~/my_tflite_app
cd ~/my_tflite_app

# 编辑CMakeLists.txt，确保包含以下行
# find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
# project(hello_world)
# target_sources(app PRIVATE src/main.c src/model.cc)

# 编辑prj.conf，添加TFLite Micro配置
echo "CONFIG_TFLITE_MICRO=y" >> prj.conf
echo "CONFIG_TFLITE_MICRO_MSG_PACK=y" >> prj.conf

关键点在于CONFIG_TFLITE_MICRO=y会触发Zephyr的模块构建系统，自动将~/ncs/modules/lib/tflite-micro下的源码编译进固件。同时，需要确保CMakeLists.txt中链接了正确的库：target_link_libraries(app PRIVATE tflite-micro)。

阶段四：编译与烧录

# 编译（指定开发板为nRF52840 DK）
west build -b nrf52840dk_nrf52840

# 烧录（通过J-Link或USB DFU）
west flash

如果编译过程中出现undefined reference to tflite::MicroInterpreter之类的错误，说明TFLite Micro库未正确链接。此时应检查prj.conf中的配置项是否生效，以及CMakeLists.txt中是否显式添加了链接库。

2.3 案例拆解：nRF5340双核环境配置与内存分配

nRF5340是Nordic首款双核Cortex-M33芯片，包含一个高性能应用核（128 MHz）和一个低功耗网络核（64 MHz）。在部署TFLite Micro时，通常将模型推理放在应用核，而网络核负责BLE通信。这一架构对环境搭建提出了特殊要求。

配置项 应用核 (APP) 网络核 (NET)
构建目标 nrf5340dk_nrf5340_cpuapp nrf5340dk_nrf5340_cpunet
Flash起始地址 0x00000000 0x01000000
RAM大小 448 KB 64 KB
TFLite Arena大小 建议 ≤ 200 KB 不适用

在实际项目中，我们曾遇到一个典型的Arena内存溢出问题：模型包含一个1D卷积层和一个全连接层，输入特征长度为128，输出类别为10。初始配置的Arena大小为150 KB，但运行时出现AllocateTensors() failed错误。通过打印arena_used_bytes，发现实际需要约180 KB。解决方案是：

  1. 在prj.conf中增加CONFIG_HEAP_MEM_POOL_SIZE=20480（20 KB额外堆空间）；
  2. 将Arena缓冲区从静态数组改为动态分配，并放置在外部PSRAM（如果板载）；
  3. 使用__attribute__((section(".noinit")))将Arena放在不初始化的RAM段，避免启动时清零开销。

最终，通过调整链接脚本将Arena放置在RAM的低地址区域，并启用Zephyr的CONFIG_MEMORY_POOL_ALLOCATOR，成功将可用Arena扩展到220 KB，模型推理正常。这一案例说明，环境搭建不仅是工具链安装，更涉及内存布局的精细调优。

2.4 常见误区与调试技巧

误区一：盲目使用最新版nCS。最新版nCS可能尚未适配你使用的TFLite Micro版本，或者Nordic的驱动有未公开的变更。建议使用LTS版本（如v2.5.0或v2.6.0），并参考官方sdk-nrf的Release Notes确认兼容性。

误区二：忽略west.yml的锁定作用。如果手动修改了west.yml中的TFLite Micro提交哈希，会导致模块版本漂移。排查问题时，先执行west diff查看是否有未提交的模块变更。

调试技巧：使用west build -t menuconfig可以图形化查看所有Kconfig选项，确认TFLite Micro相关配置是否生效。此外，在main.c中调用tflite::MicroInterpreter::GetTensor前，先打印arena_used_bytes，这是判断内存是否充足的最直接手段。

另一个常见问题是J-Link调试器无法连接。这通常是因为nRF5340的调试接口需要额外配置：

# 在prj.conf中添加
CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_DEBUG_THREAD_INFO=y
# 使用J-Link GDB Server时，选择芯片型号为nRF5340_XXAA

如果连接仍然失败，检查开发板上的SWD跳线是否短路，以及J-Link固件是否更新到最新版本（通过J-Link Commander的firmware update命令）。

2.5 总结复盘：环境验证清单

完成环境搭建后，建议执行以下验证清单，确保所有组件协同工作：

  • 工具链验证：arm-none-eabi-gcc --version输出12.2.rel1；
  • west状态：west status显示所有模块为clean；
  • 编译验证：编译hello_world示例，无警告无错误；
  • 烧录验证：通过west flash烧录后，串口输出Hello World!；
  • TFLite验证：运行hello_world示例，串口周期性输出正弦波预测值。
← 上一章 📖 返回目录 下一章 →