1. 为什么是这块板

Nordic 的 nRF54LM20 是面向低功耗多协议物联网的 SoC，最大的卖点是把 Bluetooth 6.0 Channel Sounding 做进了标准 BLE 控制器。换句话说，厘米级到亚米级的测距不再需要 UWB 那套额外射频，直接用 2.4 GHz 蓝牙链路就能做。

我拿到的是 nRF54LM20-DK。拆开包装，第一件事是把板子上的资源摸清楚，因为后面所有实验都建立在这些资源上。

【图片1：nRF54LM20-DK 实物正面】

2. 硬件清单与关键规格

这里有两个容易踩的点：

1. DK 上实际焊的是 LM20B，不是 LM20A。 官方文档里 LM20A 是"模拟目标"。构建目标要写 nrf54lm20dk/nrf54lm20b/cpuapp，写成 A 虽然也能编，但用不到 B 的 NPU。

2. 板子没有加速度计/陀螺仪。 活动文案里提到的"板载加速度计"在这块 DK 上不存在。要做振动类应用，要么外接 I2C 传感器，要么用第二块带 IMU 的板子（我选了 XIAO nRF54L15 Sense）

【图片2：XIAO nRF54L15 Sense 实物】

【图片3：nRF54LM20-DK 接口标注】

3. 一个现实问题：Intel Mac 装不了新 SDK

我的开发机是 2015 款 MacBook Pro（Intel i7-4770HQ，macOS 15.8.1）。nRF Connect SDK 从 3.4 开始，工具链只提供 macOS ARM64 版本：

• Zephyr SDK 0.17.0 及以前：有 macos-x86_64 资产

• Zephyr SDK 1.0.0 及以后：只有 macos-aarch64

而 NCS 3.4 对应的 Zephyr 4.4 要求 SDK 1.0.x。结果就是：Intel Mac 最高只能停在 NCS 3.3.x。

两条路：

我选了后者。编译和烧录本来就是解耦的：远程只需要产出 zephyr.hex，本地只负责烧录和看串口。

4. 远程编译环境

服务器：Ubuntu 24.04 x86_64，20 核，用于编译。选用 NCS v3.4.1（LTS）。

4.1 安装 west

python3 -m venv venv
./venv/bin/pip install -i https://mirrors.aliyun.com/pypi/simple/ west

4.2 初始化工作区

git config --global url."git@github.com:".insteadOf "https://github.com/"
./venv/bin/west init -m git@github.com:nrfconnect/sdk-nrf --mr v3.4.1 ws
cd ws
../venv/bin/west update --narrow -o=--depth=1

这里用 --narrow --depth=1 做浅克隆，能把工作区从 10 GB 压到 2–3 GB，对只做应用层开发足够了。

踩坑记录：实验室网络对 GitHub 的 HTTPS 连接会间歇性 TLS 中断，git ls-remote 时好时坏。改成 SSH 并把所有 https://github.com/ 重写成 git@github.com: 之后稳定很多；另外服务器 DNS 偶尔解析失败，west update 需要包一层重试循环。

4.3 安装 Zephyr SDK

NCS 3.4.1 对应 Zephyr 4.4.2，使用 Zephyr SDK 1.0.1：

wget https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v1.0.1/zephyr-sdk-1.0.1_linux-x86_64_gnu.tar.xz
tar -xf zephyr-sdk-1.0.1_linux-x86_64_gnu.tar.xz -C ~/
cd ~/zephyr-sdk-1.0.1 && ./setup.sh

踩坑记录：Zephyr SDK 的 hosttools_*.tar.xz 单包其实是 Yocto 的宿主工具安装器，不是完整 SDK；要直接下 *_gnu.tar.xz 完整包（约 2 GB）。

4.4 安装 Python 依赖

./venv/bin/pip install -r ws/zephyr/scripts/requirements.txt 
                      -r ws/nrf/scripts/requirements.txt

【图片4：远程编译与本地烧录流程】

5. 第一个程序：blinky

先用最小的工程确认整条链路是通的。

cd ws
../venv/bin/west build -b nrf54lm20dk/nrf54lm20b/cpuapp 
  zephyr/samples/basic/blinky -d build/blinky

单镜像的 sysbuild 不会生成 merged.hex，实际产物是 build/blinky/blinky/zephyr/zephyr.hex。把它拉回本地：

scp ssh-ohos-new:~/.../build/blinky/blinky/zephyr/zephyr.hex ./firmware/

本次编译结果：

FLASH:  32056 B / 2036 KB (1.54%)
RAM:     6024 B /  511 KB (1.15%)

烧录（本地用 J-Link）：

./tools/flash_local.sh firmware/blinky_zephyr.hex

也可以打开 nRF Connect for Desktop 的 Programmer，选 zephyr.hex，点 Erase & write。

烧完观察板子：LED1 应该大约每秒闪烁一次。

6. 串口日志怎么看

DK 通过 J-Link OB 提供两路虚拟串口，macOS 下通常枚举成：

/dev/tty.usbmodem0010518965831
/dev/tty.usbmodem0010518965833

用 screen 或 nRF Connect 的 Serial Terminal 连接，波特率 115200：

screen /dev/tty.usbmodem0010518965833 115200

实测结论：控制台在 VCOM1（...833），VCOM0 没有日志输出。DK 的 zephyr,console 指向 uart20，板级 DTS 把 uart20 接到了第二路 VCOM。

还有一点：日志是启动瞬间打印的。如果先烧录、再打开串口，会看不到启动横幅。正确做法是先连串口，再复位开发板。

后面跑信道探测示例时，距离估计值就是从这里输出的。

7. 小结

这一篇做完的事：

• 摸清 DK 的硬件资源和两个坑（LM20B、无 IMU）

• 解释了 Intel Mac 的 SDK 版本上限，并搭好了"远程编译 + 本地烧录"链路

• 用 blinky 验证了整条工具链

下一篇进入 BLE 本身：广播、连接、串口透传，为信道探测打基础。

附：本系列环境版本