LAUNCHXL-CC1310: 程序死机问题

程序概率性死机，死机之后再debug进去暂停，死在以下界面中，个人分析是进入休眠没唤醒，但是我使用的是基于rfWakeOnRadioRx_CC1310_LAUNCHXL_nortos_ccs修改的,主循环中没涉及到sleep相关函数

Simon Huo：

概率性死机指的是同样的程序有时正常运行吗？正常运行时是否有正常输出

,

user6336125：

几个设备一起测试，测试一两天可能会出现一个这样的问题，程序通过433发出来数据都是正常，看门狗也配置好的，目前唯一可能就是休眠没唤醒，因为看门狗在休眠的时候始终停止了，如果是程序正常出错卡死，看门狗应该会复位

,

Albin Zhang：

user6336125 说：可能就是休眠没唤醒，因为看门狗在休眠的时候始终停止了，如果是程序正常出错卡死，看门狗应该会复位

看来您已经找到方向的。

是的，这个芯片的狗是软狗，休眠死了就彻底死了。

几个方向可以排查：

1. VDDR/VDDS的电压可以跟踪一下，如果在休眠下，由于其他电路或者干扰发生了brown out 跌落到工作电压之下, 那么芯片不会reset。就死了。避免的方式就是系统设计啦。电池供电能力，系统里面有没有拉大电流的装置。可以计算一下，看看DCDC的输入电容是否够。

2. crystal的起振条件。 这个你可以po一下规格书我帮你看看。但最基本的你要自查一下CL 和ESR等参数是否满足规格书的要求。

BR. Albin

,

user6336125：

1、麻烦你看看截图的汇编，是不是在休眠出不来？我看卡死的汇编之前是wfi，应该是进入cpu待机之前的操作，wfe是cpu恢复后的操作

2、有没有可能休眠唤醒过程中，晶振失效了？硬件晶振接的24M和32k

,

Albin Zhang：

这个看不出来的。你要从物理上分析一下

BR. Albin

,

user6336125：

有没有类似于linux方法，通过汇编地址可以从汇编文件中反汇编回来函数名称？跑了一天时间又死在这一句上面

,

user6336125：

物理上，通过示波器测量死机的设备，32K晶振确实没有起振；正常设备32K是正常起振的；32K晶振不起振会是自己的应用程序导致的问题吗？还是说是晶振问题导致的硬件问题？

,

Albin Zhang：

前面提到的VDDS休眠下跌落也可能是这现象。所以，除了crystal，还需要排查电源。

BR. Albin

,

user6336125：

死机之后我这边单步调试，发现代码一直在SysCtrlAonUpdate和Power_idleFunc之间切换，硬件32K晶振是正常起振的

//*****************************************************************************
__STATIC_INLINE void
SysCtrlAonUpdate(void)
{// Force a clock cycle on the AON interface to guarantee all registers are// in sync.HWREG(AON_RTC_BASE + AON_RTC_O_SYNC) = 1;HWREG(AON_RTC_BASE + AON_RTC_O_SYNC);
}/**======== Power_idleFunc ========*Function needs to be plugged into the idle loop.*It calls the configured policy function if the*'enablePolicy' flag is set.*/
void Power_idleFunc()
{if (PowerCC26XX_module.enablePolicy) {if (PowerCC26XX_module.policyFxn != NULL) {(*(PowerCC26XX_module.policyFxn))();}}
}

,

Albin Zhang：

那就是没死机？怎么进了debug mode? 

是不是JTAG口被干扰了？芯片进入debug mode，从应用看就像死机了？

BR. Albin

,

user6336125：

我是根据官方debug功能调试里面的防止重启那个继续调试的方法去设置的，等设备死机了再通过jtag，debug进去单步调试的，主函数下断点没反应，下面有几个截图，你看看能不能分析出来问题所在。

,

Albin Zhang：

closed the issue off-line. 

BR. Albin