This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

28062芯片的烧录与启动问题

我在应用28062芯片时,遇到一个问题:
某一次,使用自己开发的上位机对通过CAN对芯片进行程序升级之后,芯片无法启动。

使用XDS510仿真器在仅连接芯片但不烧录程序的情况下,可以观察芯片flash中的内容,将该内容与烧录的hex文件对比,随意挑选了10多个地址,对比结果显示芯片flash中存储的内容与hex文件对应地址上的数据一致-------可以认为程序升级没问题(因为dsp底层的烧录算法在握手成功后是要先整体擦除flash然后再编程的)

保持xds510的连接但不烧录程序的状态,可以对芯片内的程序单步仿真,发现程序会跑到地址0x3ff6c1~0x3ff6c5之间,然后在这一段之间死循环。

找到一个能正常启动的芯片,用一样的操作方法单步仿真,发现与上面的差异之处:程序跳转到0x3ff4b1处开始执行时,正常的芯片会在0x3ff4b6处跳转到0x3d7cc0处---get_mode()函数---执行,然后跳转到0x3F7FF6处执行,这里就是begin段,可以正常进入应用程序了。

而问题芯片不会这样,是顺序执行到0x3ff4cb处,然后跳转到0x3ff698处再顺序执行,然后就执行到0x3ff6c1~0x3ff6c5之间的死循环了

以上这些位置的代码,都在boot room等用户不可操作的部分,为什么还能出现不一样的运行结果。

对这一段启动过程做深入的调试,有进一步的发现:

通过分析汇编程序,找到了使正常芯片和异常芯片启动过程中跳转路径发生差异的原因是:

        在0x3ff48f处Boot ROM----Bootloader Functions,程序读取地址0xd01PIE Vector处的数据存储起来,用于在地址0x3ff4b1~0x3ff4cbBoot ROM----Bootloader Functions处做判断并跳转到不同的位置,

        其中:当存储的数据为3时,向地址0x3d7cc0Get_mode function跳转,为1时,向0x3ff698Boot ROM----Bootloader Functions跳转。

        而为3时,芯片是正常启动的,为1时,芯片无法启动,会陷入到Boot ROM内的死循环。

 

 

地址0xd00是芯片PIE向量表的起始地址,按道理这段位置的数据是固化的,而我们对比正常的芯片和异常的芯片,两种有很大的差异,如图所示:

55AA 0003----正常芯片

55AA 0001----异常芯片

出现这种情况的芯片当时有2片,其中一片 我用xds510仿真器烧录程序之后就正常了。

请问这种差异是什么原因造成的,与GPIO34等几个管脚的电平有关系吗?与flash内的应用程序有没有关系,上位机升级程序的逻辑中的bug能不能导致这种情况。请解答,谢谢!