“在某办公区域，所有人盯着日志输出，均紧张的站立，除了两个人……”
这个场景是发生在刚刚过去的2024年，我们项目首次提交转测版本的Deadline前夜。我们的项目有几个团队联合完成，而我的职责是将其它团队设计并验证好的配置数据在系统启动阶段通过寄存器写入的方式，配置到指定外设的配置空间。这个简单的步骤竟然从早上一直忙到第二天凌晨仍然未成功。我们的CTO，研发总监，各团队的负责人悉数到场，核心人员要么在旁边候着，要么在线standby。而那两个坐着的人，一个是我，另一个是软件驱动人员——由他生成数据，由我写入。
我们的数据是先把验证好的配置数据格式化成csv格式，再由软件驱动人员生成二进制数据bin文件，再由我使用MCU读取Flash的bin文件，按照约定的格式，解析成配置数据，然后再通过寄存器写入到外设的配置空间。这个任务说简单也简单，“写-读-写”而已，但也挺复杂的，中间涉及其它团队提交的文件数据是否出错，格式化csv是否出错，生成bin文件是否出错，Flash读取是否出错，写入过程是否成功且生效等等。其实大家心里都没有底，一来第一次实现；二来，其它团队也没有有效的验证手段。大家都只能看压力测试的结果！而压力测试又不是必现的嘛！
重复验证一次又一次，日志打印观察了一遍又一遍。感觉每次都差点的意思！有时候链路不通，有的时候链路又正常，有时候性能有波动！就这样，在一次又一次的尝试中，时间很快就到了深夜。大家也都在猜测，这个大大的bug到底是谁写出来的？
时间过了凌晨，大家都有点沮丧了，Deadline已经到来！时间也很晚了！
转机出现了！
我在和工程师的一次连线中，对方工程师明确说出我的寄存器地址设置为0x300004，中间是4个零。天啊！我居然在整理文档的时候把这个关键的寄存器地址写成了0x3000004，中间是5个零。可能是长时间注视电脑，眼睛已经疲惫不堪吧！
在我修改完成此处bug后，我们的系统终于如预期般运行越来了，性能也达到了转测的要求！大家也放心的回家休息了！
经过这次bug事件，我也带头做了总结，并提出了以下4点防护措施：
- 大量数据下发时，在调试阶段做日志输出。日志输出较多，较慢，也要先把数据梳理，验证；
- 对大量数据进行CRC32校验，保证外部存储中回读时数据全部正确；
- 对输出日志文本进行Text Compare对比，以与原技术文档做对比；
- 后续，对发布版本做错误全局变量标记。当下发文件CRC32校验错误时，做出Error Flag置位，以规避无效的排查；
这次bug事件，相当疯狂了吧！把研发的领导都”请“过来了！也不知道他们如果早知道是我的笔误差点导致了转测推迟，还会不会给我买饮料和牛肉干！嘿嘿！
最后，祝各位21ic的小伙伴们，在2025年这个完全平方年里全部远离bug！远离bug！远离bug！
|
楼主
标题置顶
标题高亮
