直接现象：每次断网时，通过串口捕捉到串口没有收到wifi模块的AT应答信息，初步论断认为是wifi固件没有回应答导致网络断网。
深入分析：对比上代稳定产品主要增加了刷屏和电源调节的功能，都使用了中断，论断是中断导致的。
理由如下：
1：反馈的现象，我也通过串口补抓到了，但是断网太频繁了，一个小时可能有几次，但是我们其他产品使用相同WIFI固件却没有这种现象，如果是固件的问题很难解释，所以我认为固件出问题的可能性很小。
2：一般分析问题，都是通过现象来推断一些原因，就如上面我们的wifi断网时会出现MCU接受不到wifi固件的应答，先初步分析就是两种情况，要不就是wifi真的没回，要么就是wifi回了，MCU自己没有接受到。根据上面一条分析就可以初步分析出wifi固件没有回的现象可能性比较小，再加上我一直维护wifi固件，做过各种大数据透传压力测试，没有出现过没有回应答的情况，之后让同事做数据压力测试，也没发现wifi没有回应答的情况。
3：那排除了wifi没有回复的情况，那就是MCU没有接受到数据，那什么情况可能导致MCU串口接收不到wifi反馈的信息呢？那只有中断了，为什么这么说呢？是因为我们使用的msp430f149很特别，他在响应中断时，默认是不理睬其他中断，比如我们的串口接收中断，这点很多设计者不太清楚，我当时说出这种情况时，基本没有人听过还有这种情况，都不相信，后来拿资料确认了才恍然大悟，这就要求设计者在设计软件时需要特别考虑中断处理，比如设计的中断处理函数时间尽量短，如果时间太长的话，就会导致很多其他中断无法响应比如串口接收中断无法及时响应就会导致数据接收丢失，还有就是中断响应不要太频繁，你前脚刚退出中断处理函数，就马上进来了，如果太频繁了，给人的感觉就是你好像没有退出过中断处理函数，导致屏蔽了其他中断。现在我们的刷屏以及电源电压调制使用的pwm都需要使用中断，而且很频繁和占用的时间也比之前的中断要长些，这些因素都增大了串口接收失败的概率。
锁定了频繁断网原因就可以定制相应的解决方案：
第一种就是从源头重新设计软件，比如中断处理函数是否占用的时间太长而且太频繁？对于这种情况涉及到硬件电源电路需要修改，因为软件一直频繁调用ADC采集电压来调制电源电压使其温度降低些，如果换了电源电路相应的软件也可以去掉，减少断网的风险。对于刷屏的话，由于相对于ADC采集电压不是特别频繁仅仅是占用一些时间，这块可以在中断处理函数中增加不屏蔽其他中断的功能，我们将ADC采集功能去掉之后，在中断处理函数中增加不屏蔽其他中断的功能，实验后断网次数少了很多。
第二种方法由于wifi只要我们发了数据给它，它就会回复应答，我们可以不根据它的返回值来判断联网，让中断没有机会中断我，直接拿ping网络命令（以前两者都结合用），这个命令失败了会发送三四次，所以回复的应答被中断的概率更小，为什么我们不让发送数据的命令也多发几次呢？这样会导致数据冗余，所以只发送一次，如果要发送要么满足15秒的心跳包，要么就是满足数据上报触发条件，实验测试也可以很好的满足一天基本不断网或者由于中断干扰断网次数最小。
第三种方法直接让wifi模块来实现配网逻辑，让MCU没有机会干扰wifi配网和网络连接状态，MCU只管发送数据给wifi就行，其他的都不需要mcu考虑，测试效率是最高的，此种方法也测试过了，没有出现过断网，目前我们采用的是第三种方法。
以上是我提出来的三种解决办法，通过对比验证采用最可靠的第三种方法。