关于EEPROM的坑你遇到过几个？

关于EEPROM的坑你遇到过几个？
最近遇到一个关于EEPROM的使用问题，一番调试抓波后，最终发现不是硬件的问题，而是软件的疏忽导致。虽说不是第一次用EEPROM，但是在这方面遇到问题还是第一次，遂由此引发相关思考总结，分享给大家，仅供参考。

事情经过是这样的⬇
在一个风和日丽的下午，刚提交完一篇结项报告的我看向窗外，揉了揉眼睛、转了转脖子，正准备伸个懒腰、松口气…
这时软件同事A突然找到我说：
“有块板的EEPROM读写时出现概率很高的数据错误，而且还跟上下电有关，上电后第一次读写就容易发生数据错误，软件复位后就正常了，能不能帮忙排查一下板子上电时候有没有异常？”
我回答：
“这块板可不是第一次打板调试哦，现在这个板已经是正式版了，之前已经经过了两次打板调试，黑盒、白盒测试报告都出了，也没反馈过有这个问题，不可能是硬件的问题！”
同事A：
“那也不对呀，我的代码也同样经过了几轮测试，之前也没发现过这个问题呀？要不还是一起看看？”
我心想，测试报告里所有电路的功能、节点波形都测的清清楚楚、明明白白，EEPROM的SPI通讯波形也是方方正正，我还专门检查了一下BOM看看有没有贴错器件，一番自查后发现都没有问题。这样的情景是不是熟悉？软件和硬件互掐，谁都认为自己没有问题。谁对谁错当然要用事实和数据说话，拗不过同事的请求，还是跟他一起分析一下吧，到底是什么问题导致，必须一探究竟！
下面是分析过程⬇
第一步：问题复现
同事A给我演示了一遍问题复现过程：
上电➡连接上位机➡给EEPROM写数据➡上位机读取刚才写的数据，发现确实有数据错误了，反复验证了几遍，都是在上电后就很容易出现这个问题，而且电源电压越低越是容易复现。
第二步：问题分析
根据复现过程，从上位机的数据看，有个很显而易见的共性：都是数据段的最后4位发生错误！
到这里我心想，这问题有九成以上的概率是软件问题，所以我建议同事A再排查一下代码，然而他还是来找我说问题还是没解决，然后我就不太情愿地搬着示波器去给他抓波形了。
经过一翻折腾，信号点全部接好，测得波形如下：

可以看到，波形上虽然有些尖峰，但是还不至于导致出现电平逻辑错误。到这里我心里已经排除了硬件问题的可能性。于是叫同事A继续检查代码，没过多久，他跑过来跟我说问题解决了，我问他怎么解决的，他说是代码问题！
第三步：问题结论
数据长度错误！软件给EEPROM写的数据位长度居然是20！很显然，2进制、8进制、16进制都不可能出现20这个数呀！数据长度一般要么8位、要么16位等等。

以下是个人感想⬇
以上说的问题虽然是个低级问题，但为什么我还要专门用一篇文章来说呢，老生常谈了，经历过多个研发项目的朋友们我想都知道，无论软件还是硬件， 实际开发调试工作过程中遇到的大部分的问题往往都是由于忽略细节导致的，真正的技术问题其实没几个！而恰恰是因为这些细节问题，导致浪费大量的时间，严重的会影响到项目的开发进度。
不是每个问题都像上面这个例子一样，都能被快速发现并解决，很多时候一个细节问题，能让你排查到怀疑人生，甚至要花上三天、五天乃至更久的时间，还可能搭上整个团队的时间，我想每个电子工程师也都或多或少经历过那样的“绝望”时刻。
作为一名技术研发人员，我们不仅要攻克技术难题、设计好的技术方案，我们更好做好细节，确保产品质量、把控风险，日常工作过程中尽可能减少低级错误的发生，才能把更多的时间花在关键的事情上面，而不是一天下来好像什么都干了，又好像什么都没干。
无论做什么工作，在做完后一定一定一要做仔细仔细再仔细的自我检查！
这不仅是对自己负责，也是对整个团队负责！
以上就是今天的内容，下期我将给大家分享：硬件工程师怎么做好原理图检查。

更多有趣内容，欢迎点赞+转发+收藏+关注，将持续分享硬件知识干货、职场感悟…