Zephyr BSP: 44-BSP CI Hardware in the Loop

摘要：本文是 BSP CI/CD 系列的第 44 篇，讲解如何将 CI 从"只编译 BSP"推进到"把固件烧进真实开发板并自动验证"的 Hardware-in-the-Loop（HIL）阶段。文章从 HIL 的定义出发，介绍真实 HIL 测试机的架构、Flash/Reset/UART/Power 四大核心能力，给出最简单的 HIL 流程与 Zephyr Twister 的配合方式，并深入讨论 GPIO/UART 测试、机器可读测试协议、硬件资源调度（Hardware Pool）、Power Control 自恢复等关键问题。最后对比 HIL 与普通 CI 的区别，并给出从第 43 篇到第 44 篇的完整闭环架构图，帮助读者把 BSP 验证真正落到真实硬件上。

BSP CI Hardware-in-the-Loop（HIL）

到了第 44 篇，我们把前面的BSP CI/CD再往前推进一步：
CI 不只是"编译 BSP"，而是真的把固件烧进开发板，让真实硬件跑起来，然后自动验证。
这就是Hardware-in-the-Loop（HIL）。

1. 为什么 BSP CI 最终一定需要 HIL？

前面的 CI 可以做到：

Git Push │ ▼ Build │ ├── Compile ├── Link └── Static Check │ ▼ PASS

但这只能证明：
代码能够被编译。
不能证明：
代码真的能在 SoC 上运行。
例如：

uart_init();clock_init();gpio_init();

编译全部通过，并不代表：

Clock 真打开了 Reset 真释放了 UART 真能发送 GPIO 真能翻转 Interrupt Controller 真工作 Flash 真能启动 Devicetree 配置真的正确 linker memory map 没有实际问题

所以 BSP validation 最终需要：

Software CI │ ▼ Build │ ▼ Flash │ ▼ Real SoC │ ▼ Run Test │ ▼ Collect UART/GPIO/Debug result │ ▼ PASS/FAIL

2. HIL 到底是什么？

HIL 可以简单理解成：

CI Server 控制真实硬件，并把真实硬件当成测试对象。

例如你有：

GitLab/GitHub │ │ Push ▼ CI Runner Server │ west build │ ▼ firmware │ │ USB ▼ ┌──────────────┐ │ Debug Probe │ │ J-Link/ST-LINK│ └──────┬───────┘ │ ▼ ┌──────────────┐ │ Company SoC │ │ Development │ │ Board │ └──────┬───────┘ │ │ UART ▼ Test Result

这就是最基本的 BSP HIL。

3. 一个真正的 BSP HIL 测试机长什么样？

公司通常不会把开发板直接插在开发者电脑上。

而是建立：

CI Server │ Network │ ┌──────────┴──────────┐ │ │ Runner1Runner2│ │ ┌────┴────┐ ┌─────┴─────┐ │ HIL Rack │ │ HIL Rack │ └────┬────┘ └─────┬─────┘ │ │ ┌────┴─────┐ ┌────┴─────┐ │ Board #1│ │ Board #2│ │ SoC-A │ │ SoC-B │ └──────────┘ └──────────┘

例如：

BSP CI Lab Rack01├── Nucleo/Company Board A ├── J-Link ├── USB-UART └── Power Controller Rack02├── Company Board B ├── J-Link ├── USB-UART └── Power Controller Rack03├── Company Board C ├── J-Link ├── USB-UART └── Power Controller

4. HIL 最核心的四个能力

一个真正可用的 HIL，不只是一个开发板。

至少需要：

HIL │ ┌─────────┼─────────┐ │ │ │ Flash Reset UART │ │ │ └─────────┼─────────┘ │ Power

也就是：

① Flash

CI 能够自动：

erase ↓ program ↓ verify

例如：

west flash

或者：

JLinkExe...

② Reset

测试开始前必须保证：

Board=known state

例如：

RESET ↓ Boot ↓ Zephyr ↓ Test

否则上一次测试可能影响下一次测试。

③ UART

这是 BSP HIL 最重要的测试接口之一。

例如 firmware 输出：

===BSP HIL TEST===Clock:OK GPIO:OK UART:OK Timer:OK IRQ:OK TEST PASS

CI Runner 自动读取：

UART │ ▼ log │ ▼ parser │ ├── TEST PASS │ └── TEST FAIL

④ Power Control

这是很多初级 HIL 系统容易忽略的。

如果 firmware 死机：

Board │ └── stuck

你不能永远靠人工：
拔 USB → 插 USB。

所以 HIL 最好能够：

Power OFF ↓ wait ↓ Power ON ↓ Boot

这也是为什么真正的 HIL rack 往往会有：

USB Hub Serial Debug Probe Power Switch

5. 最简单的 HIL 流程

假设 Git push：

git push

CI：

① checkout ② west update ③ west build ④ reserve hardware ⑤ power cycle ⑥ flash ⑦ reset ⑧ run ⑨ capture UART ⑩ analyze result ⑪ release hardware

完整流程：

Git Push │ ▼ Build │ ▼ Build PASS?│ ├── NO → FAIL │ ▼ Reserve Board │ ▼ Power Cycle │ ▼ Flash Firmware │ ▼ Reset │ ▼ Run Test │ ▼ UART Capture │ ▼ PASS?┌─┴─┐ YES NO │ │ ▼ ▼ PASS FAIL

6. Zephyr 本身其实已