TI中文支持网Part Number:CC2642ROther Parts Discussed in Thread: UNIFLASH
我们的CC2642R程序由一个自编写的从0x0000从执行的boot程序,默认情况下它会检查一个flash存储的标志,然后跳转到app. 在跳转之前,我们会专门设置一个即将跳转标识,保证jumpToPrgEntry(FIRMWARE_START_MEMORY_ADDRESS)会被执行.
完全相同的程序, (boot+app)现在在3个样品上进行测试,其中一个样品出现概率性jumpToPrgEntry(FIRMWARE_START_MEMORY_ADDRESS)失败并卡死,死机,(测试20次,会有10次左右卡死,无蓝牙信号) 经仔细检查代码,确认该函数一定会被执行,但相同的代码在
(boot+app)在另外2个硬件上并无发现(也同样进行20次以上测试),每次都能正常跳到app
每次执行的测试都是上电测试,无debug线,无其它动作
请问可能是哪种情况导致jumpToPrgEntry()失效并卡死?
Nick Sun：
您好，
我们无法马上判断是软件或者硬件的问题。
请问您是使用了您的客制化PCB板吗？如果是的话您可以去做一个硬件审查（链接）。
您有使用到相应的SDK或者例程吗？可以把相应代码贴上来方便我们查找问题。
,
led share：
PCB样件是我们硬件部门设计的,设计期间,也请了TI支持人员的审查. 我的SDK版本为simplelink_cc13xx_cc26xx_sdk_5_40_00_40,目前,经过长期的开发和测试期间,在官方开发板(cc2652开发板)上也多次出现过,频率不高,在目前有限的样件中,至少2个不同的样件上出现了该
CC2642R: jumpToPrgEntry()概率性卡死的问题,今天上午测试中又出现了一次,特来寻求答案
,
led share：
void jumpToPrgEntry(uint32_t prgEntry){#if defined(__TI_COMPILER_VERSION__) || defined(__clang__) static uint32_t temp; temp = prgEntry; // Reset the stack pointer, temp +=4; asm(" LDR SP, [R0, #0x0] "); ((void (*)(void))(*((uint32_t*)temp)))();#endif}
这是我使用的jump函数,来自官方例程.
,
Nick Sun：
您好，
为更加有效地解决您的问题，我需要询问更了解这款芯片的TI资深工程师，再为您解答，一旦得到回复会立即回复给您。
感谢您的理解。
,
Nick Sun：
您好，
我们还有一些问题需要咨询您：
您测试的三个样品是否使用相同的硬件设计？
重新烧写设备是否真的可以解决问题？
您能把每个单元的内存内容转存出来比较一下吗？ （您可以使用 Uniflash 来执行此操作）
您能否具体说明如何评估是否有蓝牙信号？
在执行the out of the box 的simple_peripheral example时，您是否能可靠地在存在故障单元上获取蓝牙信号？同时，我们需要了解问题发生时发生的情况。例如，您可以在问题发生后连接调试器并验证 SP 的值和调试指南（ debugging guide）中提到的其他元素。
,
led share：
1. 出现该 jumpToPrgEntry(0x8000)死机现象的3个样品中,2个是相同PCB图纸的自己的样件(CC2642R1F),1个是CC2652R1 launchPad开发板
2. 出现该现象时,我的固件都由2部分构成boot代码(0x0000地址开始,大小约为24KB),和 app代码(0x8000地址开始)构成
3. 出现该现象时,要么出现在
a. 只是上电启动(boot代码先执行,然后需要 jumpToPrgEntry(0x8000)到app
b. 执行固件升级命令,需要从app跳转到boot时..这时早期我用的方法为jumpToPrgEntry(0x0000),经常出现该问题,
后来我把跳转到boot改成SysCtrlSystemReset();仅在从boot跳转到app时一处使用 jumpToPrgEntry(0x8000)出现频率降低了,有半个多月左右未再出现死机 问题.(早先我也反馈的过SysCtrlSystemReset()死机的问题),直到A样发布测试时,又在测试人员那里出现了一次app 跳转到boot 时(使用SysCtrlSystemReset())死机问题
4. 我可以把flash的内容读出来,用smartFlash programmer 2,但是读出来之后我不知道如何分析,以及比较什么,和谁比较.比较之后能确认什么
5. 我们发布的boot+app程序中,app是在simple_peripheral example基础上开发的,app基本没有改动simple_peripheral example的内容,仅在其task中添加初始化函数和非阻塞轮询来实现我们的业务功能. 我确定jumpToPrgEntry(0x0000)或SysCtrlSystemReset()死机是通过log日志,在一定会执行它们之前,我会uart输出日志,并在倒数第二个不会被代码覆盖的flash sectors区域写入一个标志. 提示将要做的事. 在程序正常时,蓝牙信号正常,可以用手机读写数据.
6. 问题发生后,没有办法调试了,已经死了,只能重新上电,可以看到,它又跑起来了
希望你们能够帮助分析和解决该问题,已经困扰我1个多月了,注意,该问题是偶发性问题,同一个程序不会一直出现该问题,仅在早期全部使用jumpToPrgEntry()在app和boot之间跳转时,在一个自制样件上出现了高达50%的启动失败率(上电后从boot跳转到app死机频率)
,
Nick Sun：
您好，
帮您同步工程师，有答复后回复您。
感谢您的支持。
,
Nick Sun：
您好，
我们这边工程师还需要问您几个问题：
led share 说：2个是相同PCB图纸的自己的样件(CC2642R1F),1个是CC2652R1 launchPad开发板
一种思路是在工作板和非工作板（working and non-working boards）之间交换 CC26x2 设备，以查看问题是由 IC 引起还是由定制设计引起。led share 说：用smartFlash programmer 2,但是读出来之后我不知道如何分析,以及比较什么,和谁比较.比较之后能确认什么
想让您比较工作单元和非工作单元（working and the non-working units），以查看是否可以发现一些差异。led share 说：问题发生后,没有办法调试了,已经死了,只能重新上电,可以看到,它又跑起来了
您的意思是在问题发生后，您无法按照调试指南中的说明连接调试器吗？您最终是否设法通过附加的调试器重现该问题？
