Tiger 控制板历史审查：任务、通信与状态一致性（2025-09-11）

这是 2025-09-11 的 Tiger 控制板历史审查记录。原文称已阅读当时的核心源码，但未附可重现的完整工程和构建结果。本次整理复核的是这份记录的文字、所示片段与 API 含义，没有重新审查当前固件，也不能据此确认问题仍存在或已经修复。

原记录末尾保留了提交标记 4a5dbc8f6ae3015875fed6731349917cca60c48a，但未给出所属仓库及它与审查版本的关系。截图可读文字为“修复气阀控制相关问题，比较完善，但是开启后，…”及“添加首次添加气阀上位机软件…”，其余内容被截断。这里将线索转为文本，不推断截图中未显示的修复范围。

当时记录的模块划分

模块	原记录中的定位线索
HAL/CMSIS/FreeRTOS 与构建	Core/*、Drivers/*、Middlewares/FreeRTOS/*；CMake 含 stm32cubemx 子工程
伺服通信和状态机	Core/Src/bsp/tigerservo.c、对应 Core/Inc/bsp/tigerservo.h
Modbus 主从站和稀疏表	ModbusMaster/*
从站适配与透传	modbus_slave_adapter.c、modbus_slave_map.c/.h
按钮、气阀	button_control.c/.h、valveControl.c/.h
EEPROM 与配置转换	at24c02c.c/.h、SavedParameters.c/.h
看门狗	watchdog_manager.c
联调工具	tools/HostSimulator/*、tools/modbusServoSimulator/*、tools/hostModbusDebugger/*

这些是历史工程内的文件名，不是本知识库提供的可编译文件。

任务与同步线索

任务	原记录给出的配置	本次复核边界
defaultTask	Normal，空循环	是否忙循环、如何让出 CPU 需看函数体
modbusTask	Normal，标称 50 ms 轮询	周期与一次通信最坏耗时未测定
servoTask	High，标称 10 ms；上电等待 3 秒	原 osDelay(3000/10) 参数实际为内核 ticks
systemTask	Low，标称 20 ms；扫描按钮、喂狗、健康检查	内部阻塞会影响这些职责

原片段还给出 Modbus/伺服任务 .stack_size=1200*4，但没有栈高水位与溢出测试记录。仅看优先级、栈大小和循环延时，不能得出任务配置“合理”的结论。

CMSIS-RTOS2 的 osDelay() 使用 ticks；只有内核频率为 1000 Hz 时，数值才与毫秒对应。osDelay(10) 放在工作之后，也不等于精确 10 ms 的固定周期。CMSIS 等待 API

原文记录创建了 servoMutexHandle、buttonMutexHandle、modbusMutexHandle、globalVarMutexHandle，称后三者分别用于按钮、通信和气阀，未见 servoMutexHandle 实际使用。这应通过所有读写路径和锁调用表重新确认，不能只检查锁是否被创建。

数据流与接口线索

当时的稀疏表容量为 MB_INPUT_ENTRIES=32、MB_HOLD_ENTRIES=64，插入带 O(n) 查找/后移。mb_reg_write() 将插入结果转换成布尔成功值；真正的问题是上层是否检查失败，以及多寄存器更新能否保持一致。

原从站入口为 mb_slave_poll_v2()，记录称 0x03/0x06/0x10 已定制到稀疏表，0x01/0x02/0x0F 未实现。32 位值通过两个 16 位寄存器拼接，再同步到业务缓存；需要确认高低字顺序、一次请求的边界检查与两次表写入之间是否会暴露半更新状态。

适配层 ModbusSlave_AdapterProcess() 按 Holdings→Coils→Inputs 处理。原文称站 2 控制写入会透传到 0xA864/0xA875，随后清零命令寄存器以避免重发。它只提供了 A3Servo_WriteAuto32() 调用及清零片段，没有完整错误路径，因此必须检查“发送失败是否仍清零”“重复写是否会重复动作”“何时向上位机确认”三件事。

A3Servo_SafeModbusCommunication() 的片段用 osMutexAcquire(modbusMutexHandle, 10) 保护一次通信调用。这里的 10 同样是 ticks，且串口锁并不会自动保护整个 g_servoController 或寄存器映射。CMSIS 互斥锁不能从 ISR 调用，超时返回必须处理。CMSIS 互斥 API

气阀片段在 Valve_IsSafeToOperate() 返回假时清零 VALVE_CTRL_CMD_ADDR，并把 VALVE_STATUS_ERROR_INTERLOCK 的高 16 位写入 VALVE_STATUS_ADDR。记录没有展示完整状态写入与异常应答，复核时应检查低字、主机解码与拒绝原因是否保持一致。

风险清单：历史观察与复核方法

原文使用高、中、低风险分级。下表保留其调查顺序，但这些不是经设备风险评估确认的安全等级。

原观察	需要复核的影响	建议验证或调整
急停处理中有两次 osDelay(2000)，与喂狗共处系统任务	若为 1 kHz tick，等待总量约 4 秒，再加操作耗时；是否触发 IWDG 取决于真实超时和喂狗路径	查 tick、IWDG 配置及所有阻塞点，改为有明确超时的分阶段处理
g_servoController 被多个任务直接读写	复合状态可能不一致，单个字段读写也要看实际类型和平台	列出读写者；采用单一所有者或定义一致的同步协议
mb_input_map/mb_hold_map 并发访问、容量失败未处理	插入、移动和 32 位两字更新可能冲突；写失败可能被忽略	检查容量与返回值，设计事务边界，再确定锁或所有者
主机命令直接透传到站 2	本地按钮与远程控制可能走不同条件检查	汇入同一命令处理层，明确拒绝、执行和确认结果
MB_MASTER_TX/RX、MB_SLAVE1_TX/RX 为空	只有硬件需要软件 DE/RE 控制时才构成该故障	对照收发器原理图和示波器波形，不能无条件补 GPIO 翻转
MB_BAUD_RATE=38400 固定	可能与 UART 的波特率和字符格式不一致	用真实串口格式和所采用的 RTU 时序规则核对帧间隔；不能只替换波特率常量
SavedParameters.h 自包含、无保护并含重复实现	若原描述准确，会造成包含或定义问题	对照文件与构建日志，将声明和实现分离
SystemTask 测试代码直接写保持寄存器和 isDataDifferent	调试路径也可能产生竞争或生产副作用	确认生产构建排除条件；保留测试时仍遵守同步规则
modbus_communication_busy 未使用	可能是无效状态，也可能是尚未接入的同步意图	查全部引用后再清理
CMake 多次设置 Release 优化项	实际生效选项可能与预期不同	查看最终编译命令，按性能、尺寸和调试需要选择优化级别
稀疏表 O(n) 插入	32/64 项规模下未必是瓶颈	测量最坏插入时间，避免仅凭复杂度标签重写
输入寄存器“新鲜度”窗口为 5 s	阈值是否过短或过长，取决于信号更新率和故障反应要求	按字段或通信状态定义超时，不能为减少告警而简单放宽

三条建议需要修正

看门狗应监督业务推进

原文建议把喂狗放到高优先级任务或定时器中断中，但如果那里无条件喂狗，业务任务卡死时仍可能持续刷新看门狗。更合适的设计目标是检查关键任务是否在规定窗口内完成有效工作，再决定是否刷新；具体实现及故障后的设备状态需要项目验证。多任务监督与硬件看门狗后备是可以区分的职责，Zephyr 任务看门狗文档提供了这一设计思路，不能直接代替本项目实现。

加锁要同时设计范围与顺序

“给整个控制器加大锁”或“复用串口锁保护所有寄存器”不是完整方案。若持锁期间进行串口等待、延时，或已有路径按相反顺序取得锁，会引入长阻塞或死锁。需要列出临界区、锁顺序、超时处理和任务/中断边界；单一控制任务接收命令、发布状态快照也值得比较。

一条状态判断不能证明机械动作安全

原代码片段检查 bo_zeroSpeed，原文据此称“气阀互锁正确”。这不足以证明夹具、工件和阀门可安全动作：零速字段的有效性、通信是否新鲜、气阀用途、失电状态与急停链路都未给出。远程和本地入口需要一致的操作约束，但具体约束不能仅由这份文字记录推定。

EEPROM 与后续记录

原报告称 AT24C02C 驱动正确处理页写、等待和 CRC，但只展示了伪代码，不能据此确认所有边界。后续整理已发现相关笔记存在 63/60 字节布局冲突，详见EEPROM 参数存储与迁移。这不证明本历史工程一定采用错误布局，而是要求核对其实际版本。

后续2025-09-15 状态同步审查讨论 machine_running 与急停状态的整改，属于不同阶段，应与本篇关联阅读。验证闭环应为每项记录：源码仓库与提交、原始复现、修复差异、构建结果、故障注入结果及验收日期。当前资料尚未提供这些完整证据。