作为一个优秀的设计工程师，必须对自己设计的产品了如指掌，产品出现任何异常问题，都要能够解决，或者实在是难以解决的时候，至少，要知道产生异常的原因。
因为如果某个异常你不知道原因，就让它流向市场，来到终端使用者的手上，那么，很有可能会出现更大的异常，这时，异常有多大，带来的麻烦就有多大。
你不要问我是怎么知道的，每一个成熟的工程师应该都碰到过批量退货/召回…………不说了，说多了都是泪…………
这次就碰到一个问题：一款仪表在按键开机的时候，显示不太正常。
先说说病因，可能又是堆栈惹的祸：
现象：
正常的开机状况是：按POWER键开机后，液晶LCD显示和背光灯几乎同时亮起，在2秒钟全屏显示后，显示正常的读值，像图片这样：
LCD全屏显示，背光亮起
LCD显示正常测量值，背光亮起
但是，我实际碰到的情况是：按POWER键开机后，液晶LCD全屏显示，大约2秒钟后背光灯亮起，然后才显示正常的读值，像图片这样：
这个情况虽然不是经常出现，但是试个几百次，偶尔会碰到一次，很难重现，也找不到触发原因。看现象像是MCU复位了。
处理过程：
这还了得！产品就是自己的亲儿子，怎么可能让他出现这种设计之外的情况？！！
二话不说，连上电脑，重新烧录程序进入调试状态：
进行繁重而细致的debug工作。
可惜的是，我忙了整整一上午，再加上中午牺牲午睡时间，实在是难以重现上述情况。
现在有2种可能：
一是问题还存在，但因为很难重现，碰不到，也就抓不到虫子；
二是问题消失了。
第一条先不管它，因为不能无休止地耗时间进去，先看第二条。
一般来说，嵌入式系统在实际使用时发生复位，而在连接PC调试后却不出现复位问题，是由于堆栈溢出造成的。
因为MCU在进行操作处理，复杂算法计算时，如果堆栈尺寸不够，程序就会跑飞。而程序跑飞以后，由于看门狗watchdog发生作用，让MCU复位，程序重新运行。
而使用PC调试的时候，虽然说是仿真，但毕竟是“仿”出来的，不是真的“真实情况”，此时堆栈就不会溢出了。
于是，我打开MCU配置文件，看看堆栈的处理，原来堆栈放的尺寸是0x3FF，也就是1k byte。
这个项目使用的是Freescale公司的HCS08系列中MC9S08LL36的MCU，RAM配置如下：
共有4000bytes的RAM，还是比较充裕的。
再看看RAM使用情况，还有空闲，于是我把堆栈放的尺寸改为0x4FF，也就是比原来增大了256byte的空间，这样比较保险：
改完后，我又测了几百遍，没有发生上面说的异常情况。
结论：
这个问题可能解决了，但也可能没有解决。
我决定放过这个问题，原因如下：
- 这个问题本身很难出现
- 即使出现了，也就是发生了MCU复位，但是这款仪表本身没有记录功能（logger），也没有实时时钟，即使复位了，程序重新运行，对于测量没有影响
- 堆栈改大了以后，很可能已经解决了这个问题。
前面说了，一个优秀的研发工程师应该能够解决问题或是100%清楚病因，今天这个情况，可能说明我并不是一个优秀的工程师…………
认清了事实真相，我心里好苦啊！！！！
感想：
研发工程师真不是好当的，不但前期设计要验证大量的条件/数据，碰到问题时要忍受枯燥的捉虫过程，即使付出这么多，也不能保证问题100%都能解决。真的是好苦啊！！
一个内心充满苦涩的人，只要一丝丝的甜蜜，就能乐开了花。
所以，你们身边如果有研发工程师的话，要对他好一点，比如现在你看到了这篇文章，就请大力点赞吧，哈哈哈~~
希望喜欢我文字的人，去看看这个吧，说说对我的看法，请我吃星星
，谢谢啦~
我的 @ReviewMe 凭证留言板!
Posted using Partiko iOS
This page is synchronized from the post: 一个“优秀”研发工程师的苦——可能又是堆栈惹的祸