现在负责的一个模块,之前一直生产都比较稳定,但是这次的批次不知道什么原因,发现单片机有复位的情况!
复位啊,问题已经算非常严重了,虽然可以在接收那边增加容错措施,令复位现象看不出来,但是应该把这个问题找出来才对。
整个模块很简单,一个单片机:Atmel Mega32,一个AD芯片:CS5530,一个485通讯芯片,再加上电源,没了。
做最简单的器件替换,把老模块的单片机与新模块的单片机互换,程序相同,本来好的单片机还是好的,本来会复位的单片机还是会复位,基本上这样可以判断是单片机的问题了。就型号多了个“L”,而且好像之前生产的一批也是带“L”的,为什么这次就不行了?
连夜跟供应商、FAE联系,希望能够找到根源然后再解决吧。可惜我对mega32的芯片基本没怎么了解,只能在旁边打打下手,看看他们怎么解决了。
2011年1月18日:经过调试后证实是看门狗复位造成,解决方法:1.关掉看门狗程序;2.修改喂狗的位置。
但是根本问题是,为什么原来的批次没看门狗复位,现在这个批次的看门狗会动作了呢?怎么也要Atmel的设计工程师给个满意答复才行,强硬一点还要索赔了,更改了芯片工艺导致原来的程序现在不正常。再看看后续发展吧。
下午与供应商的工程师沟通,初步判断为该批次的片内RC振荡器周期缩短导致看门狗时间变短所致。
但是后面似乎这两个工程师又想推翻之前的判断,一直想从我们的程序入手,认为是我们程序的错误或漏洞导致的,或者就是用什么离散性、随机性来忽悠我们。但想想就知道,我们之前生产了起码几十k的量,没试过类似这样的问题,这次批量性的问题,只要我们肯定程序的一致性,就肯定是芯片的批次出现问题的。
2011年1月19日:上午跟他们实测了该批次内置RC振荡器的周期,测试了2片,就有一块相差20%,终于堵住他们的嘴了。后续继续关注他们的答复了。
2011年1月27日:前几天Atmel原厂的人来了,因为datasheet上面没有明确写明内部RC的最大误差为多少,所以他们就有借口了,最后给我们的答复是:Mega32芯片内部RC的最大误差可以到达+/- 50%,而且出厂时仅检验看门狗功能,并不检验看门狗的时间是否符合要求。那好,既然这样我们也无话可说,只能敦促他们能够把这个误差以书面形式告于我们,好让我们有个凭据,怕以后再来个60%的,也好跟他算账了。同时在这里也跟每个用到该型号的同志提醒一下:
这边和传开胡佳的单片机小组开发的有区别么?