引子一个 YOLOv8n 茶叶包装识别模型从 PyTorch 训练结束到 STM32N6 裸机 NPU 上稳定跑起来——单帧 160 ms取帧 15 / 预处理 20 / NPU 推理 105 / 后处理 20端到端出结果 0.8 s5 帧 3 票。中间经历了 12 轮调试、4 个平台级 bug。这篇是系列总览Hub。链路图、为什么这么选、四个坑在哪里、性能怎么拆——都在这里单篇深挖见文 2–文 7。一、全链路总图[训练] Ultralytics / PyTorch 训练 YOLOv8n256×2565 类2000 张自采图 ↓ 导出 ONNX固定 1×3×256×256 NCHW不接 NMS [转换] ST Edge AI Core 命令行INT8 量化ONNX QDQ→ Neural-ART 网络代码 / LL_ATON 运行时 ↓ 产物network.c / network.h / 权重 blob2.91 MB [烧录] 权重写外部 octo-FlashXSPI2 内存映射 0x70A00000 [集成] 手动集成 LL_ATON 到 CubeMX HAL CMake FreeRTOS LVGL 工程 ↓ .ioc 重配RAMCFG / RIF、链接脚本内存三段布局FSBL / App / 权重 [部署] 摄像头帧 → 预处理中心裁剪→256²→RGB888→NCHW→ NPU 推理 → 后处理 top-1 ↓ 分级阈值 类别增益 5 帧 3 票 burst 投票 [上线] 看门狗 fail-soft 降级NPU 挂了不拖垮整机二、为什么选 ST Edge AI Core 而不是 X-CUBE-AI详见文 5《抛弃 X-CUBE-AI》。一句话X-CUBE-AI 是黑盒插件内存布局、启动时序、工程结构都由它决定用命令行版 ST Edge AI Core 自己拿回全部掌控权——代价是文档少、坑自己踩四个坑里三个都是这么踩出来的。试过X-CUBE-AI发现跑不通有很多bug而且正点原子提供的相关例程也没走X-CUBE-AI。三、内存三段布局FSBL / App / 权重外部 Flash 上三段不重叠段内容地址示意FSBL第一级引导0x70000000 起App应用固件链接脚本指定权重2.91 MB int8 权重0x70A00000 起FSBL 决定“跳去跑哪个固件”——这也是日后 OTA 双区切换的基础。这里app按照我们的需求我设置了8mb空间。四、四个平台级 bug 概览#Bug主题深挖文1AXISRAM 默认断电 → 无异常卡死电源文 22WFE 低功耗门控冻死 NPU 时钟时钟文 33RISAF 防火墙拦截 NPU 读权重安全文 44CACHEAXI 空 weak 函数致缓存未使能缓存一致性文 5实际调试顺序AXISRAM → RISAF → 时钟门控真·根因→ CACHEAXI。前三个修完仍然卡最后才在时钟上破案——“配置值正常 ≠ 实际在跑”是最贵的一课。五、性能拆解160 ms 花在哪阶段耗时说明取帧15 msDCMIPP 帧同步等待预处理20 ms中心裁剪 缩放 RGB565→888 NCHW 重排单循环整数运算NPU 推理105 msLL_ATON_RT_MainCPU 睡眠等待后处理20 ms1344 框 × 5 类 top-1 阈值/增益合计160 ms5 帧 × 160 0.8 s 端到端瓶颈在 NPU 推理占 66%——不是算力不够是权重从外部 Flash 读XSPI2 内存搬运的开销NPU 峰值 600 GOPS 只是标称。六、可复用清单新平台 RAM 先确认时钟 供电 写读自检多主设备 SoC“CPU 能读 ≠ NPU 能读”RISAF/CID睡眠之前逐个确认谁会被低功耗门控HAL weak 空函数是“假初始化”高发区写完读回验证诊断读“反映实际状态”的寄存器不读配置寄存器文 1 完 · 下一文《STM32N6 NPU“配置值正常≠实际在跑”WFE 低功耗门控冻死 NPU 时钟排查》