相关文章。

先定义系统和验收条件

假设项目采用 MCU 或 DSP、三相逆变器、电流采样和位置反馈，目标是实现工业电机驱动。第一份文档应写清电机类型、母线范围、传感器、负载惯量、通信周期和允许的启动方式。伺服的定位精度、VFD 的速度范围与电流限制不能合并成一句“运行稳定”。

将每项需求改成可观察的判定：在指定母线、负载、温度和指令变化下，记录响应时间、峰值电流、稳态误差或故障关断时间。暂时没有依据的数值标成待确认项。厂商演示工程的电机、采样比例和保护阈值属于示例条件，不能当作新硬件的产品规格。

建立单位明确的信号契约

先画出指令到功率输出的路径：通信接收、命令校验、状态许可、参考值限幅、控制计算、调制和 PWM 生效；再画反馈路径：模拟前端、ADC、偏置校正、工程量换算、角度与速度更新。每个接口都注明单位、正方向、更新时间和失效判定。

例如 current_a 表示安培还是 ADC 计数，speed 表示机械 rpm 还是电气 Hz，必须在接口中固定。中断和后台任务交换数据时，用完整快照或明确的发布协议，避免读到一半新、一半旧的量。volatile 只限制部分编译器优化，不能代替跨上下文一致性设计。

按失效后果拆分执行路径

电流闭环依赖采样与 PWM 更新，适合放在可分析的周期执行路径；通信、参数持久化和较慢诊断另设执行节奏。RTOS 可以组织任务，但是否满足硬实时仍由最坏执行时间、抢占、临界区和硬件时序决定。高优先级任务本身不构成截止时间保证。各条路径应有明确的运行周期和负责人。

快速过流保护应依据功率器件容限配置比较器、驱动器或 PWM 故障输入路径。C2000 的 Trip-Zone 是一种具体实现；输出电平须结合门极驱动有效电平确认。软件故障处理负责锁存原因和限制重启，不能用一条后台告警代替快速关断。

分层带起，而不是一次合上所有环

先在功率输出受控的条件下确认时钟、引脚、安全输出、电流零偏和母线换算，再检查 PWM 极性、死区、ADC 触发点与编码器方向。只有这些证据成立，才进入低能量、限流条件下的角度对齐和电流闭环；随后增加速度环、位置环或应用命令。

每层保存配置版本、测试条件、原始记录与通过标准。闭环振荡先查采样比例、相序、角度和输出延迟，再讨论 PI 参数。单元测试可验证转换和限幅逻辑，台架测试验证真实执行链；二者不能相互替代。跨电机复用时，重新确认参数与保护范围。

验证清单：保留证据与未覆盖边界

验收表应把需求编号连接到测试编号和记录，未执行的工况明确保留为缺口。调试器下的一次成功旋转，只证明当时的局部条件。以下检查应分别给出预期状态、输出行为和证据文件。

• 在指定供电和负载条件下核对电流、速度、位置及调制输出的单位与正方向。
• 用发布构建测量周期路径的最坏延迟，覆盖通信突发、诊断和中断嵌套。
• 通过受控注入检查传感器失效、通信超时、参数非法和硬件保护响应。
• 检查掉电、复位和故障确认后的输出状态，确认未收到新的有效启动命令时不会意外运行。

先画一条完整时间轴

假设使用中心对齐 PWM，每个完整周期执行一次电流控制，比较值通过影子寄存器在指定计数事件装载。应在时间轴上标出 ADC 触发、采样保持、转换完成、中断入口、计算完成、寄存器写入和实际装载。控制结果写完，不代表功率输出已经使用它。

C2000 ePWM 能由计数器零点、周期点或比较事件触发 ADC，并提供不同影子装载选择；具体功能取决于芯片型号。若装载事件每半周期发生一次，计算窗口也可能只有半周期。不要从“PWM 为 20 kHz”直接推导“算法有 50 μs 可用”。

从装载事件倒推截止时间

把 t_sample 定义为采样触发时刻，t_load 定义为计划使用该结果的装载事件。示例预算为：t_load−t_sample 大于采样与转换延迟、中断等待、最坏计算、写入耗时及余量之和。这个不等式需要分别填写测量值或数据手册约束，不能只填平均 ISR 耗时。

例如完整周期为 50 μs，而采样到目标装载仅相隔 25 μs；若采样转换用 2 μs、等待用 3 μs、计算写入用 12 μs、预留 3 μs，余下 5 μs。数字仅用于说明方法。错过装载通常使旧输出继续保留，额外延迟是否为半周期或完整周期，要看配置。

还要单独记录反馈数据的年龄：本次电流和本次角度是否来自同一时刻，速度滤波输出是否滞后几个周期。算法能在截止前完成，只能说明计算及时；若它始终使用过旧的角度，系统依然可能在高速时产生明显误差。预算因此既要检查完成时刻，也要检查数据来源与采样时间戳。

采样窗口必须同时满足电路条件

采样点首先受电流检测拓扑约束。低侧分流和单分流重构有各自有效导通窗口，还要避开开关瞬态，留出放大器建立与 ADC 采样保持时间。把触发固定在周期中点并非对所有占空比都有效；高调制度下窗口不足时，要检测并处理无效样本。

TI 的 F2837xD ADC 接口将采集窗口以 SYSCLK 周期表示，同时要求满足器件规定的最小时间。该单位不能推广给其它 MCU。多通道串行采集还会产生通道间时间偏差；增加滤波虽然能降低噪声，也会增加反馈延迟，应纳入闭环模型。

把调度干扰算进预算

列出可能阻塞周期路径的高优先级 ISR、关中断区间、共享总线、DMA、Flash 等待和缓存变化。禁止在控制 ISR 中执行无界循环、动态分配或阻塞日志。后台发布设定值时采用短而有界的同步方案，持久化操作是否阻塞取指要查具体芯片。更改编译优化、存储布局或数学库后，应重新测量该预算。

FreeRTOS 的 Cortex-M3/M4 类 BASEPRI 移植中，数值更小表示中断优先级更高；高于 configMAX_SYSCALL_INTERRUPT_PRIORITY 许可边界的 ISR 不能调用 FromISR API。寄存器与库函数的优先级表示还可能不同。这是具体移植规则，不能照搬到 Cortex-M0、C28x 或所有 MCU。

验证清单：量出最坏路径

RTOS、平均 CPU 占用率和一条示波器脉宽都不能单独证明实时性。测量应把采样到输出的延迟与 ISR 内部耗时分开，使用最终优化等级、实际存储位置和正常外设负载，并记录超时计数。

• 核对 PWM 计数模式、ADC 触发源、转换结束标志及影子装载事件。
• 用 GPIO 或硬件追踪同时观察采样事件、ISR 边界和 PWM 更新，检查漏装载。
• 覆盖最大通信量、中断嵌套、参数保存和占空比极端条件，保留最长延迟。
• 注入计算超时与无效采样，验证旧输出、停机或降级策略符合设计。

先声明讨论对象和约定

本文以三相平衡 PMSM、转子永磁磁链定向和幅值不变变换为例，讨论固件接口怎样对齐。FOC 不是一组可以随意拼接的公式：相序、电流正方向、坐标旋转方向和调制器输入必须一致。交流感应电机的磁链建立与滑差另有模型，不能直接照搬 PMSM 的角度关系。

在项目中建立约定表：A/B/C 对应哪些端子，电流正方向是否为逆变器流向绕组，机械正转从哪一侧观察，编码器计数正方向是什么，d 轴是否沿转子磁链。变量命名携带单位，避免同一个 angle 在不同模块中有时表示弧度、有时表示一圈归一化值。

用明确公式连接坐标

在 ia+ib+ic=0 的平衡三相假设下，一种幅值不变 Clarke 形式是 iα=ia，iβ=(ia+2ib)/√3。本文采用 id=iα cosθ+iβ sinθ，iq=−iα sinθ+iβ cosθ 的 Park 形式。这样逆变换为 iα=id cosθ−iq sinθ，iβ=id sinθ+iq cosθ。其它约定可以成立，但需整条链一起变更。

若库使用功率不变归一化，d/q 幅值与本文不同，扭矩系数及限幅也必须配套。最简单的静态检查是 θ=0 时 id=iα、iq=iβ；θ=π/2 时 id=iβ、iq=−iα。再做正逆变换回环，检查误差范围，而不是先接电机观察能否旋转。

同样要把电压接口写清：调制器接收伏特、相对母线的比例还是标幺量，输出占空比如何与桥臂对应。电流控制器输出正确的数值，却被另一套比例再次缩放，会改变实际闭环增益。将这些转换集中在清晰的边界处，比在多个模块中零散补系数更容易核对。

电气角度包含方向、极对数与偏置

在上述 PMSM 假设下，电气角度可写作 θe=wrap(p·s·θm+θoffset)，其中 p 是极对数，s 是机械传感器方向映射，偏置由实际磁链对齐关系确定。四极电机是两极对，不能把极数直接当乘数。速度换算也遵循 ωe=p·s·ωm，而 rpm 到 rad/s 还需乘 2π/60。

编码器零点并不天然等于转子磁链零点。对齐过程应限制电流、持续时间与机械运动条件，先确认反馈方向，再确定偏置。存在采样和执行延迟时，控制所需角度可能还涉及预测补偿；应先测量延迟，再按模型处理，不能用随意增加偏置掩盖速度相关误差。检查正负转速和角度回绕附近的连续性，尤其要防止无符号计数相减造成跳变。

d/q物理含义有电机边界

对转子磁链定向的 PMSM，q 轴电流参与电磁转矩，d 轴电流改变定子电流沿磁链方向的分量。在本文幅值约定下，常见模型为 Te=(3/2)p[ψf iq+(Ld−Lq)id iq]。表贴式且 Ld≈Lq 时，正常基速区常采用 id*=0；此时转矩近似随 iq 变化，不能因此宣称所有电机都如此。

内嵌式 PMSM 的凸极性使磁阻转矩项不能忽略，MTPA 可能要求非零 id；高速弱磁还受电压、电流和退磁限制。永磁体提供的磁链并不会因 id=0 消失。用“id 是磁链、iq 是速度”作变量解释会丢掉这些边界；速度通常由外环产生转矩或 iq 请求。

验证清单：先证明约定一致

先在纯软件中验证变换，再在限制能量的台架条件下确认方向和角度。若改接相线、反转编码器方向或替换数学库，应重新执行同一组检查。电压、电流、磁链和扭矩公式必须使用配套归一化。

• 以零角、四分之一圈和完整角度扫描验证正逆变换、幅值及定点溢出。
• 确认极对数、机械/电气速度、rpm/rad·s⁻¹ 和峰值/RMS 的接口转换。
• 在受控低电流条件下检查正 iq 请求对应的转矩方向与反馈方向。
• 检查母线电压降低、限流及弱磁边界下的电压限幅与积分抗饱和。

参数需要生命周期

假设驱动器支持通信设置、电机参数保存和现场故障查询。参数表应包含标识、类型、单位、范围、默认值、写入权限、生效时机和版本。额定电流、电流采样比例、极对数与控制增益属于不同性质；“收到写命令就改变量”不足以保证运行行为可预测。

把配置分为待修改、已验证、当前生效和已持久化几种状态。实时路径读取完整的生效快照；一组关联参数完成整体校验后才发布。需要停机的修改在停机状态生效，允许在线改变的参考值应经过限幅或斜坡。通信回复区分接收成功、校验通过和实际生效。

校验组合关系与存储完整性

单项范围检查之后，还要验证组合：欠压恢复阈值高于欠压触发阈值，过压恢复阈值低于过压触发阈值，软件限流与硬件保护留有合理层级。电流测量量程、母线比例、电机与逆变器限制都要匹配。厂商用户指南给出的阈值依赖示例硬件和电机，不应直接复制到另一台驱动器。

存储记录可携带格式版本、长度、序号和完整性校验，通过双槽或其它提交协议处理掉电中断。校验失败时回到明确定义的安全配置与禁止启动状态，不能悄悄采用可能不适配的默认电机参数。CRC 用于发现损坏，并不证明参数适用于硬件或来自可信写入者。

状态转换要有条件和动作

可将运行流程建模为初始化、待机、准备、运行、停机和故障锁定；这些名称只是设计示例。每条转换写出触发事件、进入条件和执行动作。运行许可应同时检查有效配置、传感器状态、供电条件和无活动故障。收到启动命令并不等于可以立即打开 PWM。

速度降到零、PWM 禁止和机械设备安全停止是不同判据。根据伺服或 VFD 的负载定义减速、制动与失控时的处理方式。状态转换处还需决定积分器、轨迹和命令缓存如何清理，防止再次启动时继承旧输出。普通固件状态机不能自动等同于经过认证的功能安全实现。

分开活动故障、锁存历史和恢复许可

快速保护路径先按硬件要求抑制输出，软件再记录首个原因、时间、状态和关键采样值。较慢异常可以定义滤波、持续时间和迟滞，避免噪声反复触发；短路类快速事件不能为了共用接口而套用慢速去抖。故障码还应区分活动条件、锁存事件和诊断历史。

故障条件消失只说明异常当前不再成立，不必直接允许运行。ST 的六步 SDK 就区分故障正在发生与等待确认的状态，可作为这种分离的实例。清故障应检查允许的恢复条件，回到可控待机；是否允许自动重试、次数和间隔必须由应用明确规定，不能隐藏在清标志函数里。

验证清单：覆盖边界和并发

测试应观察状态、PWM/使能输出、参数版本和故障记录，而不只检查通信返回码。对危险故障使用受控模拟或专用测试条件，先验证注入方式和预期保护路径；不要靠真实短路证明软件逻辑。

• 写入边界值、非法组合和不支持的版本，确认拒绝后旧配置完整保留。
• 在参数提交与保存阶段模拟中断或掉电，确认重启不会使用半条记录。
• 在启动、运行和停机过程中注入故障，并同时发送启动、停机、清故障命令。
• 核对首故障、活动位、历史记录及确认后的状态；验证恢复后启动仍遵循明确的许可条件。

先约定设备端的责任

假设一台 MCU 电机驱动器通过串口接受上位机轮询，提供速度给定、运行状态和参数配置。本文讨论 RTU 设备端，不把它当作高频电流环的调度机制。串行链路由请求方发起事务，设备收到有效请求后处理；广播写请求不返回应答。

Modbus 定义数据模型与操作，RTU 定义串行帧组织和校验，RS-485 是常见电气接口。接线、终端匹配、偏置、隔离和收发方向要另按硬件条件确认。有 RS-485 收发器，不等于已有 Modbus 协议。首先固定站号、波特率、校验位及允许的功能码，再检查电气层。

把完整帧交给解析器

建议让 UART 中断或 DMA 只负责收字节、记时间和报告溢出，由通信任务处理帧。RTU 用静默间隔划分报文：低速时遵守 1.5 与 3.5 字符时间要求；超过 19200 bit/s 时，指南推荐分别采用 750 微秒与 1.750 毫秒。UART 的 IDLE 事件本身不保证满足 RTU 帧间隔。

解析器应先检查最小长度、缓存边界、CRC 和站号，再读取功能字段。CRC 错误和发给其他站的报文不触发参数写入。处理溢出时丢弃当前帧并重新等待合法边界，不能把尾部字节拼成下一条请求。半双工发送结束要依据真正的移位寄存器完成事件释放总线，不能只看 DMA 搬运结束。

寄存器表是一份接口合同

常见文档编号 40001 表示保持寄存器的引用方式；报文内起始地址从零开始，不能把 40001 直接塞进地址字段。设备手册应同时列出功能码、零基地址、数量、类型、单位、缩放、读写权限与默认值。上位机软件的地址显示习惯也要核对，避免在双方各减一次一。

协议寄存器为 16 位。单个寄存器的高字节先传输；跨两个寄存器的 32 位数值如何排列，应在产品接口中明确，不能猜测浮点数与整数字序相同。读运行数据时可先复制一份一致性快照，再编码应答，避免速度高低字来自两个控制周期。

写入需要校验和提交

推荐路径是收帧、验证请求、解码候选值、执行参数检查、提交、生成应答。检查功能支持、地址范围、请求数量和字节数时，应使用不会溢出的范围计算。非法功能、非法地址和报文数据值错误分别有协议异常语义；产品参数超限如何报告，也要明确约定，不应把所有错误都归为 CRC 失败。

通信任务先写暂存区，控制任务在约定边界接收整组参数，尤其是多个相关的限幅和增益。不要在串口中断里写 Flash 或直接改控制环共享量。对于持久化、启动和故障复位等有副作用的命令，要定义重试行为；主站超时重发不应重复触发一次性动作。应答成功表示哪一步完成，也必须写入手册。

验证清单

先在离线解析器上回放固定报文，再连接串口验证时序，最后在受控台架检查参数提交。协议能应答和电机可以安全运行是两项独立验收。

• 回放正常读写、边界地址、零数量、长度不符、CRC 错误、截断帧与接收溢出；确认无越界和意外写入。
• 分别测试站号匹配、其他站号和广播写；广播不产生应答，错误计数仍能解释丢包原因。
• 用已知 16 位与 32 位数值核对地址和字序，检查持续轮询时快照是否一致。
• 测量收发切换、最大响应时间及控制任务负载；验证重试、掉电和通信超时后的产品行为。

在线不是使能

假设正在实现一台 CANopen 伺服或变频驱动器：上位机能读参数，也能看到心跳，但轴不接受给定。最先要做的是记录 CAN 控制器状态、NMT 状态、驱动状态和本地故障，而不是反复发送启动命令。物理总线、通信服务和功率控制有不同的进入条件。

NMT 定义 CANopen 设备的通信行为；CiA 402 定义驱动器的功能行为及运行模式。两套状态机分别回答能否交换某类报文、能否接受某类驱动命令。NMT Operational 不自动表示 CiA 402 Operation enabled，后者也不能替代硬件保护与安全功能的判断。

从对象字典连接通信与应用

对象字典通过索引和子索引组织通信参数、应用参数与过程量。SDO 用于访问字典项，PDO 按映射传递过程数据。设备端应先为每项定义类型、长度、权限、范围、是否可映射以及副作用，再实现读写回调；不要把整个 C 结构体未经约束地暴露为网络接口。

PDO 映射决定字节对应哪个对象，不能只按抓包位置推断变量。SDO 写参数和 PDO 更新可能来自不同执行路径，必须设计共享数据的一致性。建议将网络输入复制到命令快照，由控制任务消费；运行反馈同样以快照发布。锁或临界区需要有明确时长，避免阻塞控制中断。

分别实现两套状态转换

CANopen CC 设备初始化完成后进入 Pre-operational 并发送 boot-up。该状态允许 SDO，PDO 通信则仅在 NMT Operational 中进行。Stopped 仍有 NMT 和错误控制相关行为。因此通信栈收到 NMT 命令时，要按状态启停服务，不能把所有帧统一丢弃，也不能继续使用陈旧 PDO。

CiA 402 以 Controlword 请求转换，以 Statusword 报告状态；常见对象索引分别是 0x6040 与 0x6041。驱动器还可能因内部故障自行改变状态。设备端应按状态表解释控制位，并在本地条件满足后更新状态，不能收到命令就机械回写成功，更不能让一条报文直接绕过功率级准备流程。联调时还应区分状态字中的状态字段、模式相关位和告警，不能把整个数值与一个固定常量比较后就决定驱动状态。

运行模式决定命令如何生效

“支持 CiA 402”不表示支持所有运行模式和可选参数。先列出实际实现的模式，再定义给定单位、限幅、模式切换时机与反馈含义。位置、速度、转矩给定的解释不同，上位机与固件必须用同一份接口定义。调试记录应包含请求模式、实际模式、控制字、状态字和给定序号。

心跳反映网络管理状态，不能单独证明最新控制给定仍在更新。产品需要另行规定 RPDO 超时、CAN bus-off、NMT 停止和故障后的驱动动作及恢复条件。Quick stop 的停机行为与参数和实现有关，不应把名字理解为硬件安全停机。恢复时先消除故障原因，再验证复位与重新使能路径。

验证清单

把通信状态与驱动状态交叉测试，比只验证一条使能序列更有价值。以下是设备固件的验证建议，不构成 CiA 一致性认证。

• 验证上电 boot-up、Pre-operational 的 SDO 与 PDO 边界、Operational 数据交换，以及 Stopped 的服务行为。
• 对每个支持的 CiA 402 转换记录前态、控制字、内部条件与后态，覆盖拒绝转换和内部故障。
• 检查字典类型、权限、PDO 映射和不支持对象的返回；验证并发读写不会产生半更新参数。
• 注入给定停止更新、心跳丢失、总线异常和模式切换；检查受控停机、错误报告与恢复顺序。

从设备应用的边界开始

假设 MCU 或 DSP 通过 EtherCAT Slave Controller 接入网络，通信栈负责状态与邮箱，本地任务负责传感器、控制环和输出。主站能扫描到设备，只说明部分链路与身份读取可用；仍要分别确认启动配置、过程映像和应用更新。先记录产品标识、固件版本、ESI 版本与主站周期。

本文讨论支持 CoE 的设备。CoE 是 CANopen over EtherCAT，可提供对象字典和参数访问，但不是把 CAN 帧搬进 EtherCAT。也不能假定所有 EtherCAT 产品都必须采用 CoE 或 CiA 402。驱动器若采用 CiA 402，驱动状态仍应与 EtherCAT 通信状态分别处理。

状态转换就是配置检查点

Init 尚无邮箱和过程数据通信；Pre-Op 可进行邮箱访问，适合完成参数与过程数据配置；Safe-Op 可交换过程数据并更新输入，输出通常保持设备定义的安全状态；进入 OP 前，主站必须先提供有效输出数据。设备端应在相应转换中检查配置，失败时返回可定位的状态错误。

OP 表示过程通信进入运行状态，不证明电机已经使能、传感器数据有效或控制算法达标。输出处理还需要本地驱动状态、故障和命令有效性共同决定。Safe-Op 也不是功能安全认证：看门狗配置和设备实现会影响具体输出行为，调试时应测量实际输出，不能仅凭主站界面的状态颜色判断。

让字典、ESI和映像一致

CoE 字典项需描述类型、长度、访问权和可否映射到 PDO。邮箱 SDO 适合参数与诊断访问，周期 PDO 承载过程量。ESI、在线字典、PDO 映射及固件复制函数必须一致。动态映射只在设备明确支持时开放；若固件只支持固定布局，应明确拒绝不支持的组合。

建议把过程映像布局写成可核对的表，标明每项偏移、位宽、方向和缩放，并校验总长度。网络收到的输出先组成完整命令快照，控制任务再接收；反馈按同样原则发布。不要依赖编译器结构体填充恰好符合总线布局，也不要让邮箱参数修改在一次控制计算中途改变含义。

同步的是采样与执行时刻

设备可能支持 FreeRun、SyncManager 同步或 Distributed Clocks 同步；是否必须使用 DC，取决于设备与所选运行模式。DC 用于协调本地时钟与事件，并不替代控制任务的执行预算。应先决定采样、命令锁存、计算和输出更新由哪个事件触发，再分析相位和延迟。

对于驱动设备，收到新过程数据的时间不一定就是控制给定生效的时间。建议在本地记录周期计数、命令序号、锁存时间和计算完成时间，定位通信到控制的迟延。断线、过程数据看门狗或同步异常后，输出动作与恢复条件需要明确；不能让重新进入 OP 自动重放失效前的运动给定。

验证清单

先用固定过程映像和低风险输出验证基本链路，再增加动态配置与同步模式。主站日志必须与设备侧计数和时间记录对应。

• 核对身份与 ESI；逐个验证 Init、Pre-Op、Safe-Op、OP 转换及错误原因，保存实际状态和请求状态。
• 读写字典边界、只读项与不支持项；用已知字节模式核对 PDO 方向、偏移、总长度和缩放。
• 在每个支持的同步模式下测量周期、相位、执行完成余量，加入邮箱流量检查控制任务是否受扰。
• 注入断线、主站停止和数据超时；检查输出、驱动使能、故障报告及恢复，确认 OP 不被当作轴使能条件。

先让问题可以被重复描述

假设一台驱动器在通信压力增加后偶发给定跳变。直接让 AI“修复竞争条件”，会把尚未证明的原因写进任务。更合适的输入是现象、预期行为、复现步骤、版本、发生频率和已知限制。给定跳变可能来自字序、快照、超时恢复或共享数据，先保持多个解释。

记录固件提交、工具链、优化选项、板卡版本、参数和报文回放文件。若不能稳定复现，先建立触发条件和统计窗口，报告尝试次数与失败次数。不要因为一次运行正常就判定修复；也不要把不同硬件、不同负载下的结果混成同一组证据。

提供足够且经过处理的上下文

给 AI 的最小材料应包括相关函数、调用顺序、任务或中断关系、共享变量和失败日志。保持数据类型、长度、时间顺序与错误码，删除密钥、设备凭据、客户身份和无关数据。未经授权的敏感代码不上传；可用脱敏片段、接口说明或合成报文表达同一问题。

明确限制：先分析，不能改硬件保护、不能扩大超时掩盖错误、不能改协议接口或重构无关模块。要求每个候选原因注明证据、反证和下一项区分实验。固件任务还应明确实时预算和可用的硬件测试条件。

用实验淘汰假设

让 AI 先找出最靠近异常值产生点的观测位置。例如同时记录收到的原始字节、解码后的给定、控制任务接收的快照及采用的序号。如果报文正确而解码错误，检查映射；如果解码正确但消费值变化，检查共享数据与生命周期。每轮实验应只改变一个关键条件。

日志本身也会改变时序。控制中断里同步打印可能制造或遮蔽问题，建议使用容量受限的事件缓冲、计数器或硬件时间测量，并标明丢记录情况。若问题是版本回归，可用 Git bisect 在已知正常与异常提交之间缩小范围；无法构建或无法判定的版本应跳过，不能强行归为正常。

让修复可以单独审查

证据支持原因后，再要求最小修改：说明改变了哪个条件、为何消除失败路径，以及哪些行为可能受影响。先建立能触发原问题的检查，再运行修改后的同一检查。用 git diff 检查实际改动，剔除无关格式变化；不能把模型的解释当作编译、运行或台架结果。

主机侧测试适合解析器、边界计算和纯状态转换；目标硬件测试用于中断时序、DMA 一致性、控制预算和输出动作。两者都需要保存命令、版本、原始输出和结果。若只完成主机测试，就明确留下硬件验证项。不要允许 AI 为通过测试删除断言、放宽验收范围或修改预期结果而不解释原因。

验证清单

最后的交付应是一条能追溯的链：现象、复现、证据、原因、修改与验证。结论的范围只覆盖实际验证过的条件。

• 确认版本、硬件与参数固定；失败日志仍可定位，复现文件和测试输入可重复使用。
• 逐项核对事实、推断与未知点；每项根因判断能对应原始观测或有效实验。
• 审查差异范围、边界条件、并发与实时影响；检查没有上传秘密或擅自绕过保护。
• 运行原问题、相邻边界与必要回归；记录通过、失败和未测试项，并保留可恢复的原版本。