关注 点赞 收藏 不错过精彩内容

大家好，我是硬核王同学

今天给大家分享下，经过三个多月解决的Gsensor加速度传感器数据异常及概率性卡死的问题。

数据异常

故事的开始是来自一位客户的投诉，说机器放在桌面上不去动它，语音就会播报“触发碰撞”。

拿到log后，发现某时间段内gsensor数据出现异常，突然增大了3倍左右。

我们就怀疑可能是高温导致的，所以拿同样的机器去做高温测试，但并没有发现异常。

这种问题就很麻烦了，没有办法复现，很难定位到真正的问题点。

这个问题就暂时被搁置了几天，正好后来有一位同事，拿测试的机器做开关机实验时，发现突然异常播报“触发碰撞”，马上把log抓下来看，也是同样的问题，数据出现异常，突然增大了3倍。

这就很奇怪，极有可能是一个概率性问题，无法从现有的log定位到问题点。

所以我们立马排查Gsensor附近的代码，发现有很多问题，比如通过IIC读取Gsnesor数据没有出错处理、没有IIC内部出错的打印、部分打印只能打到串口上等等。

再次进行开关机测试，还是有概率发生数据出现异常，并且增大了3倍！

这时不得不怀疑，是不是Gsensor传感器的某个寄存器的值发生了改变，不然为什么数据会突然增大3倍？

所以又增加了针对Gsensor传感器寄存器的打印，再次复测。

果然，排查到问题点！负责测量加速度计量程范围的寄存器的值突然发生改变！从0x02变成0x40！

并且是在开机的某一个时间段内经常复现，后来看代码才知道，是某个同事添加了部分代码，导致Gsensor初始化了两遍！

优化代码后复测，果然没有类似的情况发生了

但你以为事情结束了？没那么简单。

传感器卡死

再经过多次复测后，又出现个大bug，这次连读取的Gsensor数据居然都没了？

这个bug异常严重，直接会导致我们的碰撞上报功能无法使用！

不过还好我之前留了一手，把各种出错的log都加到代码里了，一看log，居然是IIC读失败?

这个问题也是概率性的，而且概率极低，既然发现了这个问题，我们先添加个出错处理，让机器重启，看看会不会恢复。

但再次测试后，只有1台机器重启恢复，剩下3台机器都没有恢复。

这就很难办，如果无法恢复，机器是无法正常使用的！

后来还是经验丰富的领导分析，是我们的gsensor传感器在重启时没有下电导致的概率性卡死，只有在关机时，才会将芯片的电源完全关闭。

后来测试，果然关机后就可以解决这样的问题。

但出错的原因还是没有排查出来呀！

所以我们又来来回回又做了两个月的测试，期间不仅去掉各种线程、不同的碰撞算法、读取IIC的频率等等。

最终发现，会上传碰撞视频和数据的斑马算法比普通碰撞算法更容易触发IIC读失败！

针对这一点查看log，我们又发现是在上传碰撞视频时更容易触发IIC读失败！

所以，我们把代码改为在上传视频时，停止读取Gsensor传感器。

测试下来果然是这里的问题，只要在这时间段内停止读取IIC，IIC读失败的概率就大大降低！

但这个问题也很奇怪，为什么上传视频时，就会导致IIC读失败呢？难道是在上传时，CPU使用不够了吗？

带着这个疑问，计算了一下CPU的空闲率，大概在48%，很明显是够用的。

为什么呢？

这时还是经验丰富的领导分析，很有可能是优先级的问题。

1. 在IIC通信失败的问题上，在相同优先级的任务中，视频上传过程会额外占用约15%的CPU资源。

2. 鉴于我们的系统基于实时操作系统（RTOS），它对线程的时间分配管理有严格的规定。这可能导致分配给IIC通信的时间片不足，进而引起通信时序错误，最终导致数据读取失败。

在实时操作系统（RTOS）中，CPU资源的分配和管理是通过时间片和优先级来实现的。时间片是操作系统分配给每个任务的一段CPU使用时间。RTOS系统会根据任务的优先级和时间片来动态分配CPU资源，以确保所有任务都能在规定的时间内得到处理。

当系统中有多个任务运行在同一优先级时，RTOS会尝试平等地分配时间片给这些任务。然而，如果某个任务（如视频上传）占用了较多的CPU资源，那么留给其他任务（如IIC通信）的时间片就会减少。这可能导致IIC通信任务无法在有限的时间内完成数据传输，从而引发通信时序错误。

在RTOS系统中，每个线程的时间片和栈空间大小都是预先分配好的，以确保系统的实时性和稳定性。如果某个线程的时间片不足以支持其正常运行，就可能导致任务执行不完整或超时，进而影响整个系统的稳定性和性能。

最后，我们将IIC读取Gsensor传感器的线程优先级提高，复测再也没有IIC读失败了！这个问题终于完美地解决了！

作 者 ：硬核王同学

------ END ------