审查AI辅助生成的MCU驱动：寄存器、时序与失败路径

作者LIU, ZHUOHUI

使用AI辅助编写MCU驱动时，审查边界应落在硬件寄存器上，而不只是编译器。一段看似合理的函数，仍可能误用寄存器语义、无限等待，或在故障后返回旧数据。真正有用的交付物，是能够针对某一款确切器件核对假设、失败路径和验收证据的小范围补丁。

本文采用虚构的采集外设，并专门构造有缺陷及经过审查的“生成式代码”示例。没有为此示例实际运行AI工具，也没有报告硬件测试或时序测量。代码仅用于教学，不能作为可直接上板的模板。

1. 准备能够约束初稿的输入资料

先明确完整的MCU订货型号、芯片版本、板卡版本、参考手册版本、勘误表，以及确切的SDK或设备头文件提交版本。提供相关寄存器页面，而不只是产品系列名称。同一系列的不同型号可能具有名称相近、清除规则不同的标志位。不能让模型凭相近器件的记忆填补这种空白。

补充板卡实际选择的时钟树、允许的传输速率、外设复位状态、引脚映射和电源模式限制。说明调用发生在任务还是中断中、是否使用DMA、谁拥有外设，以及如何取消操作。在请求代码前，先定义成功、超时、硬件故障和参数错误的返回结果。如果资料缺失，应要求起草助手列出不确定项，并保留有名称的占位符。

合适的任务范围应当很小：使用提供的寄存器定义，起草一次有时间上限的采集操作；指出所有来自手册的假设；不要臆造地址、复位值或勘误规避措施。另行要求不确定项清单和测试建议。受许可限制的资料与保密原理图，应始终遵守项目批准的信息共享安排。

MCU驱动审查流程：从确切器件输入到寄存器检查、有界状态转换及验收证据。
建议采用的审查流程，不代表已经进行硬件执行或取得测量结果。

2. 把有缺陷的初稿当作一组待验证的断言

/* Invented teaching peripheral: deliberately flawed */
ACQ->STATUS |= DONE;
ACQ->DIV = 48000000 / requested_hz;
ACQ->CTRL |= START;
while (!(ACQ->STATUS & DONE)) { }
return ACQ->DATA;

第一行是最重要的审查对象。假设这个虚构STATUS寄存器中的完成位和故障位均为写一清零。读改写操作可能把其他待处理事件中的一重新写回，从而清除它们，因此普通内存变量的更新方式并不适用。Arm的CMSIS-SVD寄存器描述明确区分访问属性、特殊写入行为和读取副作用。SVD文件是有用的审查输入，但仍需核对具体器件的手册与勘误表。

写死的48 MHz隐含断言外设时钟是固定频率。除法隐含断言某种分频编码及舍入规则。这些都尚未得到确认。请求速率为零时会除零；请求过高时可能得到非法分频值。即使数值本身有效，也可能超过传感器允许的时钟频率，或不满足采集稳定时间。

循环没有截止时间，也没有故障分支。外设断开、时钟停止或未处理的溢出都可能使调用方永久挂起。函数没有独立的状态结果，因此也无法区分合法数据值与各种错误。它还假定中断或第二个任务不会确认同一个标志。即使所有标识符都能通过编译，这些仍是行为缺陷。

3. 先审查修正逻辑，再映射到寄存器

/* Review pseudocode, not a device implementation. */
require(exclusive_owner && output != NULL);
require(valid_clock_and_divider(clock_hz, requested_hz));
require(timer_runs_during_wait && budget_within_wrap_limit);

prepare_idle_device_or_fail();   // bounded, device-specific
ack_owned_stale_flags();        // exact manual-defined write
configure_validated_divider();
start = monotonic_ticks();
start_one_transfer();
for (;;) {
    s = read_non_destructive_status();
    if (s & FAULTS) {
        capture_fault(s);
        return abort_and_quiesce_or_mark_unusable(IO_ERROR);
    }
    if (s & DONE) {
        value = read_result_in_required_order();
        acknowledge_owned_completion();
        *output = value;
        return OK;
    }
    if (elapsed_unsigned(start) >= budget_ticks)
        return abort_and_quiesce_or_mark_unusable(TIMEOUT);
}

修正示例有意将策略与器件访问分离。每个辅助函数都需要针对所选芯片实现并审查。对于虚构的写一清零寄存器，确认事件意味着只写入文档规定且由当前代码负责的掩码，不能先读取再回写。这条规则不能直接套用到读清零寄存器，也不能套用到要求按特定顺序读取状态和数据的器件。

示例假设只有一个所有者、同一时刻只有一个事务，并且状态读取没有副作用。当同时观察到故障与完成时，优先处理故障，因为这个教学API不允许可疑数据作为成功结果返回。其他产品可能采用不同策略，但必须明确选择。超时后必须使外设回到空闲状态，或将它标记为不可用，直到有时间上限的复位流程成功。若DMA仍向已释放缓冲区写入，仅返回错误并不构成安全恢复。

使用在相关电源状态和中断状态下行为明确的单调时钟。无符号差值计算只有在明确的时间区间与观察模型内，才能正确处理计数器回绕。应规定最大等待预算，并确保计时器持续前进。如果轮询代码阻止维护系统滴答的中断执行，以该滴答计时的超时机制就可能失效。

4. 分别审查时序、并发和错误处理责任

根据手册建立寄存器访问清单：访问位宽、对齐、保留位要求、写保护、复位值、标志清除顺序，以及时钟与复位的前置条件。标明每次寄存器访问的原因。不要因为内存屏障看起来谨慎就随意添加；应使用架构和器件要求，说明具体需要保证哪种顺序。

时序审查中，应根据选定时钟、实际分频编码与舍入选择计算最终速率，再与外设限制及应用允许误差比较。还应纳入转换时间、适用时的片选建立与保持时间，以及故障恢复所需时间。这些是建议进行的计算，并非已经测得的性能。

并发方面，应为事务状态和完成处理选择唯一所有者。根据选用的RTOS API核对中断优先级、共享数据、取消逻辑和回调上下文。volatile变量并不能构成完整的同步设计。对于DMA，应记录缓冲区生命周期、内存可访问性，以及平台特定的缓存维护要求。即使初稿使用熟悉的厂商函数名，也必须审查这些义务。

5. 把审查要求转化为可证伪的测试

  • 寄存器模型测试：模拟写一清零、DONE与FAULT同时置位、旧完成标志和保留位。验收要求是执行确切的预期写入，且不确认无关标志。
  • 边界测试：覆盖零速率、越界速率、最小与最大合法分频值、计时器回绕和时钟不可用。预期结果应是明确拒绝，或在限定时间内失败，不能返回虚假的成功值。
  • 所有权测试：在每个状态转换点注入取消和第二个调用方。方案应证明硬件仍拥有缓冲区时该缓冲区不能被复用，并且完成通知最多发出一次。
  • 台架测试：在选定板卡上采集相关时钟、数据和控制信号，重复冷启动，并覆盖支持的供电与温度条件。应将实测时序与预先约定的限制比较，不能把“看到了波形”当作通过。
  • 恢复测试：安全地移除外设响应，或注入支持的故障。确认超时状态、恢复耗时和后续事务行为，包括复位失败时明确进入不可用状态。

记录固件提交、编译选项、板卡身份、测试配置、预期限制、实际观察结果和原始波形位置。仿真证明的是模型条件下的软件行为；台架波形证明的是被测组件在所述条件下的行为。二者都不能支持无限制的可靠性结论。

6. 整理经过人工审查的结果

审查记录应把每处改动的寄存器访问关联到资料来源，把每个失败分支关联到测试，把每项未解决假设分配给责任人。若原始有缺陷初稿有助于解释修正，可以保留，但只接受经过审查的差异补丁。第二次AI审查可以提出有用问题，却不能通过“意见一致”来认证第一份初稿。

在产品项目中，可通过欧蓓特固件与BSP诊断服务讨论相关工程需求。STM32数据采集项目提供了相关采集与应用集成背景。该项目链接并不表示上述虚构驱动曾在该交付中使用、由AI生成或接受过测试。

类似文章