暴躁野蛮的异常分析故事--车载仪表屏&中控屏各类售后问题

前言

        某日，无趣解手摸鱼，出门遇一人，拉至其工位协助分析某厂异常。本为驻足观望，后陆续各种异常件飞天而至，被拉至群中暴打，立下此文，以此明志，劝诫各位莫好奇，少摸鱼。

异常一：仪表屏低温黑屏

        背景：

        用户位于遥远的北方，寒冬时零下10度以下，在车子熄火，静置较长时间后，上电用车仪表屏黑屏重启。

        怀疑点一：电源IC驱动异常，导致系统整体电源异常

         从原理图看，电源从K30L进入后，转接多个DCDC模块以及电源芯片Reset，此处产生怀疑点，低温下电源IC工作异常。

        怀疑点二：MCU复位

         MCU复位可能性较大，涉及模块包括MCU看门狗、软件复位，导致复位原因可能为HardFault异常。

        分析排除：

        Step 1、测量电源

        低温异常下，电源供电5V，3V3正常，Reset控制芯片Reset输出异常。原理图如下：

        

        Step 2、断开Reset芯片做进一步定位

        异常现象继续存在，测量MCU对应Reset脚电平，异常发生时引脚表现为低，可确认Reset控制芯片Reset输出受MCU影响。至此排除电源部分原因。

        Step 3、打印MCU复位寄存器值，确认MCU是否发生了复位以及复位原因。

        在复位前程序运行了一小会，利用这段时间，增加CAN信号外发复位寄存器的值。查看复位原因。此次异常件的MCU是瑞萨RH850的D1M系列，其复位寄存器描述如下。

       

        此处我们只需要打印RESFR寄存器即可，结果发现外发05，为看门狗复位和软件复位。

        

        至此，能确认引起异常的原因是MCU复位，但是造成触发复位继续查找。

        Step 4、进入MCU仿真，查看异常发生时，MCU运行状态

        呕吼，进入osCoreExceptionHandler了！且报告错误为C0，此为数据溢出错误标识。mea为出错程序位置，但是这个值似乎不太准确。。。

       还有osSysShutdownOS，注意这个Shutdown，它是造成后面看门狗复位的元凶。

        

              

        查看源码可知，shutdown进入后，有个死循环，导致喂狗不成功最终造成看门狗复位，这解释了有看门狗复位标志的原因，那么软件复位呢？

        于是，通过关闭看门狗使能，关闭osCoreExceptionHandler跳转，检查软件复位触发位置，异常时进行Debug（当然在一些无法Debug的情况，只能通过一道道屏蔽掉调用位置来确认）。异常发生时，仪表HMI程序Kanzi出错触发了软件复位，至此可以推断软件复位是由Kanzi造成。

        注：关闭osCoreExceptionHandler跳转，需要把这个函数定义跳转到一个空函数，这样就不会再进入死循环了，也不会再触发看门狗了。

        至此，怀疑方向逐渐排除，指向Kanzi程序，但由于其是闭源的，所以我们无法得知具体异常发生原因，只能通过排除Kanzi相关硬件器件来确认。

        Step 5、排查Kanzi相关硬件器件

        Flash、SDRAM、MCU。首先ABA更换Flash，异常存在。。。二ABA更换SDRAM，异常不再复现，且异常现象跟从SDRAM转移。

        结果：

        判定为SDRAM低温异常，导致Kanzi图像加载出错。

异常二：仪表屏低温异常花屏

        背景：

        用户仍然是位于遥远的北方的朋友，寒冬时零下10度以下，在车子熄火，静置较长时间后，上电用车仪表屏偶发性出现显示不全。

        基于该产品已经量产多年，且异常为单体问题，该异常还是得先软件逻辑着手，思考怀疑点排查。

        怀疑点一：保存素材的外扩FLASH低温读写异常

        怀疑点二：刷写素材的外扩SRAM低温读写异常

        怀疑点三：TFT显示模组异常

        分析排除：

        Step 1、从末端看起

        TFT模组先做ABA替换，异常产品的TFT模组替换到正常件上，异常消失，正常件的TFT模组替换到异常件上，异常仍然存在。故障非TFT模组引起。

        Step 2、从数据源头拉起，FLASH是否异常？

        从软件运行逻辑上分析，HMI先从外扩FLASH中读取素材，在校验后再LOAD到外部扩展SRAM供Kanzi用于图形绘制。若校验失败，则会使能软复位导致MCU重启。从现象观察，未出现重启，只是画面显示不全。故可暂时将FLASH读写异常得怀疑点挂起，优先从SRAM处分析。

        Step 2、从SRAM处分析

        查看数据手册，确认SRAM的读写位置，增加对RH850SRAM的读写测试程序。

   固定写：

固定读

读写位置定义

        结果：

结果通过设置断点，在读出现错误时，用GreenHill导出0x40000000开始的64M的数据与显示正常件的数据进行对比，发现异常件的读写出来的数据和正常件的读写数据存在较大差异。于是，ABA替换SRAM，故障排除。

异常三：仪表屏上电黑屏不显示

        背景：

        此次是这批异常件最轻松的一次，因为它是上电就不行的，给了大把的DEBUG机会。

        怀疑点一：电压检测电路异常，仪表的电源状态机进入OFF状态

        怀疑点二：MCU运行进入HardFalut状态，根本就没跑起来

        分析排除：

        Step 1、排查系统电源

        售后的同事已经出了一份详细的测试报告，证明异常件的外部电源是OK的，有图有真相，无法反驳。。。，软件佬开始动摇自信

        Step 1、检查MCU运行状态

        DEBUG发现系统停留在Init之后就不跑了。。。于是尝试打断点osCoreExceptionHandler，发现进入这个函数，但是由于这个时候容易引起看门狗复位造成我们查看异常很不舒服，所以我们另寻出路，Vctor.c文件里的osCoreExceptionHandler跳转处，让它跳到一处空函数，然后在空函数里打断点看stack list，看看是谁在作妖。。。发现一直死在这个Kanzi的位置

于是，屏蔽Kanzi的调用代码，再次运行，其他线程都跑起来了，而且系统也不复位除了没画面。。。

        结果：

Kanzi运行异常，把证据和异常件给对接Kanzi的同事看，后来这个事听说换了外部的SDRAM解决了。。。恩。。。

异常四：中控屏黑屏不显示

        背景：

        这次仪表屏没事，中控台出了问题，这个产品真是多灾多难。。。，观察中控屏的需求，外部控制信号为TI948的LOCK引脚，TP IC的IIC读写

        怀疑点一：TI948的LOCK引脚一直拉低，导致系统无法继续点亮

        怀疑点二：TP IC的IIC读写错误，导致系统走下电

        分析排除：

        Step1、Debug查看串化器的运行状态

        很稳定的读取到拉低，移交电子排查

        Step2、测量TI948的LOCK输出

        发现是1.8V左右，而MCU的电压判断2V以上才是高，确实有点低，于是用3.3V给TI948单独供电，发现功耗达到780mA，而正常的才78mA，板子上的电源才300mA的LEVEL。。。

        结果：

        TI948 IC异常，内部可能存在击穿导致阻抗异常。。。

Contiue。。。