Hubris项目中的Gimlet冷启动问题分析与解决方案

问题背景

在Hubris嵌入式操作系统的工具链更新后，出现了一个关键问题：Gimlet设备在冷启动时无法正常进入A2状态，导致风扇高速运转等异常现象。这个问题只在冷启动时出现，而热重启则工作正常。

问题现象分析

通过系统dump分析，发现以下关键现象：

1. gimlet_seq任务死亡：该任务负责系统启动序列，其死亡导致系统无法进入A2状态
2. I2C通信失败：gimlet_seq任务因I2C重试全部失败而终止
3. 网络任务堆栈溢出：net任务在冷启动时出现堆栈溢出

根本原因

经过深入分析，发现问题由多个因素共同导致：

1. 工具链更新导致的堆栈增长：新工具链使net任务消耗更多堆栈空间，原6040字节的堆栈在冷启动路径上刚好不足
2. 堆栈溢出引发连锁反应：
   • net任务崩溃后，jefe任务进行dump操作（耗时约57ms）
   • dump操作恰好在I2C事务中间执行，导致I2C控制器超时
3. I2C控制器复位不彻底：
   • 控制器复位时未充分"抖动"SCL线（只产生单个SCL脉冲）
   • gimlet_seq任务仅重试3次，产生的SCL脉冲不足以完成完整事务
4. SPD重试逻辑缺陷：即使能偶然完成I2C事务，SPD数据也可能损坏

解决方案

针对上述问题，我们实施了以下改进措施：

1. 增加net任务堆栈大小：从6040字节增加到8000字节，确保冷启动路径有足够余量（实测冷启动时最大使用6136字节，剩余1864字节）

2. 改进I2C控制器复位行为：

   • 在控制器复位时执行完整的SCL"抖动"序列
   • 这不仅能解决当前问题，还能更好地处理设备端的各种异常情况

3. 修复SPD重试逻辑：

   • 修正gimlet_seq中的SPD错误处理逻辑
   • 增加重试次数（从3次增加到更合理的数值）

4. 增强诊断能力：

   • 在dump代码中添加时间记录功能
   • 在gimlet_seq中添加I2C操作记录，便于未来调试

技术细节

堆栈使用分析

通过humility stackmargin工具，我们测量了关键任务的实际堆栈使用情况：

• net任务：最大使用6136字节（冷启动路径）
• gimlet_seq任务：使用1488字节（接近1600字节的限制）
• 其他关键任务均有合理余量

I2C总线行为

逻辑分析仪捕获显示：

1. 原始问题中I2C设备持续拉低SCL线（时钟拉伸）
2. 控制器超时（25ms）后，31ms后才看到少量SCL活动
3. 手动发送多个SCL脉冲可以最终释放总线

经验总结

这个案例提供了几个重要的嵌入式系统开发经验：

1. 工具链更新的影响：即使是工具链的"小"更新，也可能显著改变代码的运行时特性（如堆栈使用）

2. 关键路径的堆栈余量：对于启动路径上的任务，需要特别关注堆栈使用情况，并保留足够余量

3. 错误处理的完备性：

   • I2C等总线操作需要考虑各种异常情况
   • 重试机制需要足够健壮，同时避免无限重试

4. 系统级影响：

   • 一个任务的崩溃可能通过共享资源（如I2C总线）影响其他关键功能
   • 需要全面考虑错误传播路径

通过这次问题的分析和解决，Hubris系统在可靠性和可调试性方面都得到了显著提升。