开箱帖里说"后面更新过程帖"，这篇写调试过程。

中间有两次我都以为硬件坏了。一次是真坏了（板载调试器固件卡死），一次是自己配置写错（FIFO 模式选错）。两次的现象都指向"硬件有问题"，把排查顺序和判断依据写下来，比写结论有用。

现在的进度

项目状态

坑一：ST-LINK 认不出来了

现象

接 CN1（板上印着 ST-LINK 的那个 USB 口），LD1 红灯一直闪，设备管理器里既没有 ST-LINK，也没有它的虚拟串口。板上 5V 指示灯 LD3 时亮时不亮，取决于 JP5 跳线怎么插。

排查顺序

按顺序排掉五件事。

① 插错口。CN1 是 ST-LINK 专用口，CN3 是用户 USB 口，两个都是 Type-C，插错很正常。换到 CN1 之后确实识别过一次，然后就再也不出现了。

这个"识别过一次"很关键：说明电脑口、数据线、板上的 USB 走线都曾经是好的，问题是在某一次下载之后就出现的。

② 电源跳线。JP5 是 10 针、5 个位置的电源选择排针：

• [1-2] 5V_STLK：经 U4（STMPS2151，一颗带使能的负载开关）给 ST-LINK 供电

• [7-8] VBUS_STLK：直接吃 USB 的 VBUS

接 [1-2] 时 LD3 不亮，接 [7-8] 时 LD3 亮。说明 [1-2] 那一路根本没电——也就是 U4 没有导通。

③ USB 线。正反面翻着插、换三根线、拿手机试能传文件。排除线材和电脑口。

④ ESD 保护。CN1 后面是 U2（ECMF02-2AMX6），USB 数据线的共模滤波加 ESD。它要是被打穿，D+/D- 就对地短路。量二极管特性，正常。

⑤ F723 起没起来。板载 ST-LINK 的主控是 STM32F723。量它的 3V3，正常；量 D+/D- 对地的二极管特性，也正常；但 D+ 上没有 1.5k 上拉，实测 0V。

判据

测点正常应该实测说明

全速 USB 设备靠 D+ 上的 1.5k 上拉告诉主机"我插上了"，这个上拉是固件里打开 USB 外设时才生效的。D+ 一直是 0V，说明 F723 的 USB 外设压根没初始化——固件卡在初始化 USB 之前，或者根本没跑起来。

这一步把两件事分开了：板子的硬件是好的，是 ST-LINK 自己的固件死了。而它一死，USB 就不枚举，也就没有 DFU 通道，刷不回去。这是个死锁。

从 D+ 没有上拉这一条看，F723 只有在固件跑到"打开 USB 外设"那一步，D+ 才会有 1.5k 上拉。它一直 0V，说明程序根本没执行到那里——要么没跑起来，要么跑的是别的东西。

而 ST-LINK 想自救，只能靠 USB 的 DFU；USB 又不枚举。自救通道和故障点在同一条线上，闭环死在这里。

供电链还顺带解释了"为什么 LD3 不亮"：5V 是经 U4 进 ST-LINK 的，而 U4 的使能（T_PWR_EN）是 F723 自己给的。F723 死了 → 不置位 T_PWR_EN → U4 不导通 → 接 [1-2] 时整段没电，LD3 不亮。改 [7-8] 绕过 U4 才有电，但 F723 依然不跑。

绕过去

板上 CN2 是 F723 自己的 SWD 口（出厂不焊，引脚：1=3V3_STLK、2=SWCLK、3=GND、4=SWDIO），理论上可以从这里救回来。手上有 J-Link，直接从 CN7 接 H533 的 SWD 更省事：

J-Link 20 针NUCLEO CN7

pin 19（5V 供电）不要接。从此下载和调试全走 J-Link。

教训

• 板载调试器是一颗独立的 MCU，它自己也会挂。挂了以后 USB 不枚举，就没法自救。

• "灯在闪"不等于"起来了"。LD1 闪只说明 F723 的时钟和闪灯任务在跑，USB 可能完全没初始化。

• 判断 USB 设备活没活，看 D+ 上拉比看设备管理器直接。

• 下载前确认目标芯片型号。板上有两颗 MCU（H533 和 F723），选错目标、或者 ST-LINK 自身在升级固件时断电，都会让调试器变砖。

坑二：电机一转，加速度计就读不到数

这个是花时间最长的，因为现象太像干扰了。

现象

静止时采集一切正常，2 秒拿到 3330 个样本，三轴读数稳定。电机一转，同样 2 秒只拿到 31 个样本，正好是 FIFO 深度 32 减一。电机一停，立刻恢复正常。

四次误判

猜测怎么验证结论

第三条那个"直读三次都一样"特别有欺骗性。直读确实绕过了 FIFO，但读到的是 FIFO 弹出来的那批，弹完就空，再读还是残留。所以"三次相同"不是冻结的证据，恰恰是 FIFO 空了以后没东西可读的表现。

真因

LIS3DH 的 FIFO_CTRL_REG（0x2E）里，FMode[7:6] 有四种模式：

FMode模式满了会怎样

0x7E = 0111_1110，FMode = 01，是 FIFO mode。满 32 个就置 OVRN 并停止采样，把里面 31 个读完之后，再也不进新数据。

0x9E = 1001_1110，FMode = 10，才是 Stream（水位数 30）。

改这一行之后，电机转着也是 2 秒 3330 个样本，AC RMS 从静止 39mg 变成运转 195mg，五倍——数据终于有意义了。

为什么这么像干扰

1. 只在电机转的时候出现。因为只有那时采样快、读得慢，FIFO 才有机会被灌满；静止时主循环一直在读，FIFO 从来不满。

2. 读出来是"有数但不更新"。特别像传感器被干扰后数值锁死。

3. 31 这个数字太有特征，但当时没意识到它就是 FIFO 深度减一。

教训

• 先把配置寄存器读回来和手册对一遍，比怀疑硬件快得多。后来我在日志里固定打 CTRL_REG1 / FIFO_CTRL / CTRL_REG5 三个值，出问题一眼就能看出来。

• 现象"只在某个状态出现"，不等于原因是那个状态引入的外部干扰；也可能是那个状态让一个潜伏的配置错误终于被触发。

• 一个 32 深的 FIFO 只读出 31 个，这个数字本身就是线索。

坑三：日志里凭空少了几行

采集的时候发现日志中间断了一截：某类声明 20 条只落下 13 条，而固件的结束标记还写着 drop=0——固件认为每一行都写成功了。

问题不在固件，在主机侧。JLinkRTTLogger 是轮询读的，遇到系统调度抖动会有几十毫秒不读；目标侧连着写，环形缓冲转一圈就把没读走的数据覆盖了。目标侧看到读指针在动（确实在动），所以完全不知道数据已经没了。

改了三处：上行缓冲 8KB → 16KB、每行数据后停 2ms、周期结束把丢弃计数打进日志。

顺带的三个小坑

J-Link 版本太老。Keil 里带的 JLinkARM.dll 是 7.22b（2021 年），不认 H533，报 device unknown。换成 SEGGER 官网的 8.82（2025 年），旧的备份好再替换。

RTT 中文乱码。RTT Viewer 的纯文本通道不按 UTF-8 解析，中文全是方块。索性把调试输出全改成 ASCII 英文——日志是给自己看的，英文反而省掉了 PC 端解析的编码问题。

电机只震不转。四组相序扫下来，两组转、两组颤，说明相序本身是对的（标准双相整步 0x03 → 0x06 → 0x0C → 0x09），问题是直接给 800Hz 起不来，突跳太大导致失步。改成 24 档线性斜坡就好了。28BYJ-48 是 64:1 减速，转子有自己的惯性，不能一步到位。

现在能采到什么

平台通了之后采了一批四类状态（停机 / 低速 / 中速 / 高速）的数据。采集过程不展开，只看结果够不够支撑后面的模型：

指标结果

100% 这个结果反而不太对劲：只用 X 轴 RMS 一个特征就能分出四类，区间互不重叠。说明不是模型厉害，是这四个状态之间差得太远。两个 if 就够了，用不上 DSP，也用不上神经网络。

所以下一步不是急着上模型，而是把类别做难：转速档拉近到 20% 间隔让幅值开始重叠、加故障类（松一颗螺丝、加个配重块、轴承磨损）、换负载和供电电压。等单特征分不开的时候，才轮到频谱特征和分类器上场。