简介
书接上文。
先简单回顾一下哈。
我们用 AW31N开发的一款产品，应用场景为当设备充电或放电的时候会自动唤醒，或者按下按键也会唤醒，唤醒是有一个中断信号INT输出给AW31N，AW31N检测到中断INT输入，状态从休眠转换为工作状态，中断INT唤醒信号是上升沿唤醒。设备正常充电或放电的过程中，突然偶发一次AW313N没有唤醒，此时按几下按键就又唤醒了，很奇怪，这个情况很难复现。
这个问题很难复现，要一直使用2-3天才会复现1次，之后又会很难复现。从硬件角度分析了一波，往下走着走着走不下去了，卡住了，今天我们从软件角度去分析一下，看看能否找到新的突破点。
一、打开平台log
遇到这种问题，没什么好方法，打开平台log打印，当问题复现的时候，查看当前的log数据，对比分析寄存器数据，看看有什么异常。
log打开如下图位置：
把AW31N的TX GND通过串口助手工具外接到电脑上，开始测试，经过2天不懈的努力，终于复现到了，满怀欣喜的去查看log信息，复现的那台样机查看打印数据出问题的最后一次打印后前面能正常唤醒的打印是完全一样的，所以目前看起来唤醒的设置是正常的。
这个方法看起来行不通了，于是，我们想到了模拟测试。
二、异常出现的规律
随着异常出现的次数增加，我们总结了规律，大部分出现异常的应用场景有以下两种：
a.充满电之后过一晚上，拔掉静置10分钟左右，再接手机会不亮屏；
b. 放电放空一晚上，接充电器充电，会不亮屏。
于是，我们复测就有了侧重点，重新梳理思路，我们根据这个规律看能否更快的定位问题。
三、模拟异常测试
走到这一步，整机来看目前无法定位问题，那么我们分模块来定位问题。
我们找了一块DEMO板，把样机的中断脚INT单独拉出来，把TX GND接到电脑上打开打印，DEMO板的程序跑起来就是6s自动唤醒一次INT，我们测试了两天总共测试了1万多次，都没有复现，看来此方法行不通，破坏了硬件环境。
好了，能试的方法都试了，我们回归代码本身静态分析一下吧。
四、静态分析软件代码
4.1 修改供电方式配置
根据目前的现象和查看代码改了一些可疑的点：
芯片供电的方式配置的宏原理图是用IOVDD供电，软件也配置成IOVDD供电。供电方式改为IOVDD供电，要用USB重新烧录，OTA不会擦除掉VM里面存的数据，杰理建议是要改的，不然会导致电压检测有问题 ，OTA不会擦除掉VM里面存的数据，VM里面存了挺多东西的 具体你可
以看id的枚举列表大概能看到。
配置成IOVDD供电截图如下：
这个供电方式，杰理的开发线上开发文档里面有专门介绍，如下图：
这时发现VDDIO的电压等级配置的有点低，可以适当调高一些。
原本的等级配置电压是3.2V 3.4V，修改成下图：
4.2 查看休眠函数
AW31N的休眠函数（休眠方式采用软关机方式）是放在定时器里面操作的，如下图：
对于单片机来说休眠函数不要放在中断里面操作，要设置一个标志位，在while循环里面去休眠。于是，我们把控制休眠的函数从硬件定时器中断的函数里面改到主循环里面。
改了之后，经过实测，给样机充电拔掉自己进休眠后会自动唤醒显示188再休眠，这个现象很奇怪，不知道是什么原因。
通过硬件、软件的分析都没定位到问题所在，最终测试发现问题还是会出现。那我们追溯一下软件版本履历，看看这个现象是什么时候开始的。
五、对比修改履历，寻找规律
刚好我们用AW31N做过一款产品，已经走到了量产，但是，但是从来没出现过这种现象，那我们用对比工具对比一下，看看软件上有什么差异？
通过对软件框架的梳理发现，两个项目差异点在RTC上，当前出问题的项目样机使用了RTC外设，AW31N的RTC外设是模拟出来的，思索了一番，发现这个RTC的方案可以优化，把RTC的功能去掉之后，依然不影响整机功能，于是，开始动手改吧。
优化了一版之后，整了12台样机测试，测试了5天都没发现异常，至此，问题是出在这个RTC外设上，虽然问题解决了，但是根本的原因其实还是没有找到，要想找到根本原因，还是得找原厂来分析平台内部的逻辑。
六、总结
有时候分析问题就是这样，要结合软、硬件的思维共同去分析，尤其是没有充足的数据来定性是软件还是硬件问题的时候，有些问题的表象看似软件分析，找到问题背后的规律，最后结论是硬件问题，有些问题的表象看着像硬件问题，最后结果是软件导致。
所以，没有十足把握的数据、信号来判断定性的时候，不要贸然下结论，更不要扯皮，扯皮是最没有意义的，浪费时间。