电子研发低成本方案导致的灾难性后果

作为电子研发的老兵，面对各种纷繁复杂的问题，加班加点是家常便饭，绞尽脑汁甚至抓狂是常态。经常发现当项目进展到你想砸掉设备的时候，再坚持一步你就成功了。但是有一个项目却因为坚持，到现在每每想起我都心痛郁闷不已。

2006年，我在上海中磐信息科技有限公司从事动态令牌的研发生产工作。公司是一家纯软件公司，在我入职前没有硬件部门。作为硬件部经理，负责创建团队、样机研发和后续大规模生产。工作压力很大，但是工作氛围很好，同事们相处很愉快。

当时这个动态令牌的技术正在快速在各行业推广应用，开始主要是用于保障跨国企业的网络登陆安全，2002年就是通过NS的FAE首次接触到这个东西，该技术的先行者是RSA，当时NS就是RSA定制的。后来随着银行的账户密码经常被盗，各大银行也开始推广动态密码器；那几年网络游戏超级火爆，随之而来的是游戏账号安全问题，并因盗号而发生过几起比较轰动的诉讼，网游公司开始陆续采用动态令牌来保障游戏账号的安全。

当时国内从事动态密码器研发生产的公司并不多，而能拥有自主知识产权的公司更少。公司创始人是剑桥大学毕业归国的海归，拥有基于SHA256算法的动态密码的核心专利技术，而SHA256在当时比其他的公司的技术整整领先一代；公司的投资人是美国IDG和5173。

我当时的主要工作就是采用合适的单片机，实现基于SHA256算法的动态密码器。SHA256算法相当复杂，有大量的矩阵和回归迭代运算，对于单片机实现基于时间的动态令牌来说存在以下难点：

1、 较大RAM空间；

2、 高速计算能力；

3、 超低功耗；

4、 超高可靠性；

5、 超低价格；

由于以上各项之间存在冲突，同时满足这些相互矛盾的需求其实非常困难。

我先在PC机上用C语言编程实现算法，仿真后发现RAM的需求最精简最少也超过2KB，如果移植到单片机上加上各种初始化和控制代码，RAM的需求接近3KB，2006年的时候能有3KB的RAM的单片机极为稀少而且价格极高。不得已，我选择用汇编语言编程，综合运用很多编程技巧，如采用程序空间换RAM空间，多次迭代的RAM动态分配回收等，最终花费了一周时间，将RAM需求降到409Byte，因当时已经有不少单片机的RAM空间达到512Byte，彻底解决了RAM空间不足的问题。

硬件上采用激光焊接锂电池以及晶振匹配和整体固定，软件上由于采用的是汇编语言，计算效率和可靠性远超C语言编程；采用了深度睡眠等技术平均功耗降到3.4uA，一块CR2032的电池可以工作超过3年，达到了超低功耗的要求。

当时有三款满足技术要求的单片机，分别是TI和***某公司的8位机、富士通的16位机，由于超低价格的要求，我们选择了***的单片机。

很快样机出来了，功能和性能测试OK，1K的样品生产出来了功能和性能都OK，但是经过一段时间后发现存在一定比例的样机功耗很大，电池很快就没有电了。拆开测试，未见异常，换装电池后功能正常；期间怀疑过晶振停振、电池松动、静电干扰、电路板异常、软件跑飞、芯片不良等；多次请供应商及代理商的技术人员一起分析，甚至寄实物到***请原厂分析，结论均是未见异常。

在测试分析和不懈坚持中，我又分别将代码成功移植到TI和富士通的单片机，但是这时国内做动态密码器的厂商开始多起来，他们采用的都是上一代简单的加密算法，虽然安全性不够，但对单片机要求很低，而且外观上看不出任何差异。在成本的压力之下，新的单片机导入工作在公司层面一直未能真正进行，生产订单开始源源不断，又掩膜定制50K的Dice片。

坚持了很久，通过对500套样品的排查，终于发现是因为该单片机的内在BUG，P64管脚IO口寄存器配置会在休眠期间发生反转，高低电平一旦反转后就开始快速放电。

问题查清了，但是对公司来说损失已经非常巨大，包括客户流失和口碑等。这是我工作以来遇到的最难复现、最难模拟、最难分析的问题，也是对公司造成影响最巨大的问题。

教训主要有以下几点：

1、样机开发阶段过于考虑低成本方案往往会导致灾难性后果，优先选择口碑好的大品牌产品完成技术验证和生产销售，然后逐步降本；

2、如果硬件问题没有得到解决，一段时间后还没有进展需要及时止损，切换不同方案，这时一味的坚持往往付出更加惨痛的代价；

3、表面上的硬件问题有时其实是软件配置导致，但深层次原因可能还是硬件不良，遇到这种极难复现的问题尤其要当心；

4、不要迷信芯片公司，所谓原厂的技术支持其实是有限的，所谓的分析报告有时无非是一个免责的托词，而且这种深层次的问题很难追责。