[讨论] AVR之X档案——少儿不宜的深夜档节目(转)

gina   2009-11-2 11:06 楼主
by Gorgon Meducer 傻孩子

http://www.ourdev.cn/bbs/bbs_content_all.jsp?bbs_sn=3668848

前言
    这是一些关于人们眼中不可思议的“灵异事件”的调查报告。这些事件中,当事人往往在向当局
提交报告后便杳无音信,因此,这些档案中不乏一些缺乏后文和结论的;有些诡异的现象,甚至再也
没有出现过。
  作为一名好事者,虽然不是偶然,但是接触到这些档案的机会却也是难得,久而久之便也可以凭
空记得一些,余是奋笔疾书,以箪同样好事无聊的读者。


X档案001 需要重新启动才能生效的更新

[目击报告]
    曾经有来自世界各地的目击者声称,在AVR芯片运行自己编写的Bootloader更新程序后,读取
到的内容仍然是更新前的值,但是在复位以后,内容似乎就“生效了”;也有目击者在执行某一个
Bootloader程序后对其内容进行校验失败,但是复位后就能够校验成功。如此种种。因而,有一种
不知来自何方的揣测,认为ATXXX公司与MicroXXXX有某种神秘联系,以至于在芯片级别加入了“重
启后方可生效”的机制;甚至有人认为,这从硬件的角度证明了WinXXXXXP很多无关紧要的软件安
装也要求“重新启动”的必然性——毕竟,物质基础决定上层建筑。

[调查报告]
    根据对来自各地报告案例收集资料的分析,发现以下共同点:
    1、所有的现象都与Bootloader程序有关
    2、当事人都试图在写入某一段内容后对其进行“校验”,即比较写入值与读取值是否相同;
       当然,毫无疑问,他们都得到了一个“校验错误的结果”
  3、事实上,有一些人曾报告,每次在写入之后读取出来的值都有某种不确定性,或者说随机
       性。
    4、根据对内部资料的清查,Flash写入的时候没有所谓的影子存储器的机制。
    5、更进一步的调查显示:几乎所有已经投入使用的Bootloader系统从来没有遇到过这种情况,
       而报告这种神秘现象的人,往往只是编写了一个测试案例: 尝试写入一个值,然后再读取
       出来。

[典型现象]
    当事人在程序的一开始,编写一个检测程序,检测固定位置的flash内容,如果内容与期望值
不符合,则进入Bootloader程序,并写入期望值,同时重新读取该位置的flash内容进行校验,发
现读取到的内容仍然与写入的值不同——即校验失败。但是,在复位以后,检测程序发现指定位置
的flash内容已经与期望值相同。

[官方解释]
    据ATXXXX的多份文件和资料显示,这种现象被认为是没有正确阅读数据手册的结果。当事人忽
略了一个重要的内容,即,对于RWW区域,每次对其进行写入或者擦除操作以后,系统会自动将RWW
区域锁定,从而无法正常读取其中的内容。必须要执行一个指定的RWW度取使能操作,才能恢复对其
操作的能力。这就解释了上述现象。同时,由于复位会自动开启RWW度取使能,所以出现了“需要重
新启动才能生效”的假象。

[事态结果]
    大部分当事人在接到官方报告后便销声匿迹。也有一部分人坚称其现象依旧,而官方则已无法
复现其症状并附带程序若干进行答复。目前,所有当事人均情绪稳定,周围群众纷纷表示不会受其
影响。



X档案002 无法兑现的承诺

[目击报告]
    对于像M88这样的芯片来说,RESET引脚可以通过烧写fuse位的方式关闭RESET引脚的功能
而作为普通引脚使用。官方的说法是,唯一能恢复RESET引脚功能的方法是使用高压编程器。
也就是并行编程的方法。
    有没有想过这样一种情况:为了保护自己的芯片不被破解,某兄将芯片LockBits和Securit
Bits都锁死以后,将M88引脚的RESET功能关闭,同时编写程序一直在该引脚上输出低电平。按
道理来说,使用并行编程器一定能够解除这一状态——执行一个CHIP ERASE。然而,问题就出
在这里,如果你使用的是第三方的并行编程工具,那么是否能成功的解除锁定不得而知。但是
如果你有幸使用官方的STK600,至少在AVR Studio4.16Build638的版本下是无法正常解除的。
至于新版本的AVR Studio是否能解除了这个BUG,就不得而知了。

[典型现象]
    M88 将RESET引脚设置为普通IO,并持续输出低电平,芯片Securit Bit锁死。使用STK600
高压编程模式无法解除以上状况。

[调查报告]
    此系STK600 BUG。在验证过的AVR Studio4 Build638及之前的版本中存在这个问题,在最
新的AVR Studio中是否得到解决,有待验证。其实问题的原因很简单,STK600会检测RESET引脚
的电平,如果其为低电平,则判定为“短路”,因而不允许执行后续的并行编程操作。

[事态结果]
    如果你使用STK600的并行编程模式,请在安装好卡槽和芯片后,将并行编程所需的数据排线
拔下,此时,我们有机会执行CHIP ERASE操作,接下来,请将数据排线插入,再次执行CHIP  
ERASE操作。芯片解锁成功。
    然而,不知道是不是中国人的山寨精神给与了我们的方便,很少听到中国玩家抱怨这个BUG,
因而不了了之。该档案列举在此,以供参考。


X档案003 假死

[目击报告]
    关于官方工具JTAGICE mkII,历来是问题的焦点:破解也罢,克隆也罢,批判仿真器
惯坏了一代工程师也罢,认为仿真器能极大地提高代码调试效率也罢,如此种种,不一而
足,然而有一点毋庸置疑。百分之80的人并能有效地让JTAGICE mkII正常工作。
    档案中,有目击者称,发现使用JTAGICE mkII进行程序仿真时,随机性的程序跑飞,
或者干脆每次都跑飞。

[典型现象]
    1、某中型程序,使用JTAGICE mkII进行仿真时,无法在指定的断点处停止,或者在
某些断点处,每次运行得到的结果都不同。同时,程序下载到芯片中独立运行则一切正常。
    2、程序大小无关,以以下程序为最小示例代码,GCC编译环境:
        void Port_Init()
        {
            ...
        }

        void System_Init(void)
        {
            Port_Init();
            ...
        }

        int main(void)
        {
            System_Init();
            while(1);
        }
      在C语言视图下,直接全速运行,单击暂停,发现PC指针没有停在while(1)处,而是
Flash任意地址。判定程序跑飞。遂使用单步,查找原因,发现每次从System_Init()函数
返回后,PC指针黄色指示消失,程序呈现全速运行状态,单击暂停,发现程序已经跑飞。使
用汇编视图,但步执行,无跑飞症状;返回C视图,再次单步,跑飞。该症状与GCC编译器优
化等级无任何关联。后发现,似乎与使用的编译器也无关联。

[调查报告]
     对于典型现象的第一种,通常是由于用户没有对JTAGICE mkII进行设置所致。JTAGICE
mkII对Mega芯片进行仿真时,要设置目标芯片的工作频率,否则将导致仿真出错。设置的方
法是,首先无条件的进入仿真模式,然后选择Tools->JTAGICE mkII Options,在对话框中
设置所要仿真芯片的实际工作频率。设置后,症状通常解除。

     对于典型现象的第二种,属于当前AVR Studio4.16Build638的一个BUG,随后的4.17版
本是否存在该问题还有待证实。问题实际上发生在,JTAGICE mkII的仿真驱动程序会自动根
据随后要仿真的代码进行某种优化操作,while(1)死循环对应唯一的一句汇编
“rjmp PC+0000” 而这一步操作似乎产生了某些错误导致PC指针出错。从而跑飞。此时,
程序会从跑飞的落脚点开始执行,如果一直碰到0xFFFF将视作nop并继续向后执行,直到
flash的尾部,然后从0x0000开始。

[事态结果]
     对于第一种状况,大部分当事人在得到合理的解释后,纷纷进行尝试,相当一部分解决
了问题,仍有一些当事人因为程序本身的综合原因而继续纠结。对于第二种状况,解决方法
其实很简单,在while(1)里面添加任何语句,比如nop都可以排除这个问题。希望广大群众
能够相信X,相信XX的公信力,对于“假死”的谣言要做到“不相信”、“不传播”。  



X档案004 都市传说

[目击报告]
    “AVR芯片容易破解”,“500大洋立等可取”在远离挪威的中国大陆,这种传闻
几乎已经到了家喻户晓的程度。得到证实的传闻就不再是传闻,当然前提是你真的去
验证过。有多位目击者声称,他们亲自验证过某AVR著名芯片廉价破解的可能性;而且
这些目击者中还不乏一些国内AVR世界中举足轻重的媒体大亨。如同当今的和谐社会,
破解的可能性就如同某些地方性的不和谐事件相对我国欣欣向荣的社会主义现代化建设
的关系一样,在某些层面上,基本上是可以无视的。然而,“破解”是战胜不了英雄的
中国工程师的;就如同微软的windows7是战胜不了英雄的中国红客一样。有不少人声称找
到了防止AVR芯片被破解的方法,例如,有意用随机数字烧坏部分EEPROM来获取唯一的
序列号;使用内部RC校准寄存器的值作为简单的芯片“指纹”。
     愿主保佑这群人吧,你们的努力为ATXXX客观分担了困难,然而正如你们的出发点
是要保护自己的作品一样,ATXXX是不会专程来感谢你们的。
     
     问题似乎集中到了一个很奇怪的地方:究竟是从什么时候开始,大家确信AVR芯片
没有唯一的序列号的呢?官方没有公布过么?没有人真的研究过这个问题么?以讹传讹
么?问题变得有趣起来。

[典型现象]
    很多人认为AVR芯片没有唯一的序列号,从而认为,所有Flash型MCU都可以通过暴力
破解的缺点在AVR芯片上异常突出。

[调查报告]
    根据一份官方早年公开的报告(AVR922),至少可以确定有一个系列的AVR芯片具有
唯一的序列号,他们被保存在Signature Row中,通过读取Signature 特定地址的方式获
取,它们共有10个字节。详细的代码可以在这一系列芯片相关的Application Note公开
代码中找到。然而从这份报告中并不能知晓是否其它芯片业具有同样的特性。
    这些芯片是90USB1287/90USB647。

[事态结果]
    无可奉告。



回复评论 (1)

:P
点赞  2009-11-2 15:46
电子工程世界版权所有 京B2-20211791 京ICP备10001474号-1 京公网安备 11010802033920号
    写回复