Other Parts Discussed in Thread: CC1310
程序概率性死机,死机之后再debug进去暂停,死在以下界面中,个人分析是进入休眠没唤醒,但是我使用的是基于rfWakeOnRadioRx_CC1310_LAUNCHXL_nortos_ccs修改的,主循环中没涉及到sleep相关函数
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.
程序概率性死机,死机之后再debug进去暂停,死在以下界面中,个人分析是进入休眠没唤醒,但是我使用的是基于rfWakeOnRadioRx_CC1310_LAUNCHXL_nortos_ccs修改的,主循环中没涉及到sleep相关函数
可能就是休眠没唤醒,因为看门狗在休眠的时候始终停止了,如果是程序正常出错卡死,看门狗应该会复位
看来您已经找到方向的。
是的,这个芯片的狗是软狗,休眠死了就彻底死了。
几个方向可以排查:
1. VDDR/VDDS的电压可以跟踪一下,如果在休眠下,由于其他电路或者干扰发生了brown out 跌落到工作电压之下, 那么芯片不会reset。就死了。避免的方式就是系统设计啦。电池供电能力,系统里面有没有拉大电流的装置。可以计算一下,看看DCDC的输入电容是否够。
2. crystal的起振条件。 这个你可以po一下规格书我帮你看看。但最基本的你要自查一下CL 和ESR等参数是否满足规格书的要求。
BR. Albin
1、麻烦你看看截图的汇编,是不是在休眠出不来?我看卡死的汇编之前是wfi,应该是进入cpu待机之前的操作,wfe是cpu恢复后的操作
2、有没有可能休眠唤醒过程中,晶振失效了?硬件晶振接的24M和32k
这个看不出来的。你要从物理上分析一下
BR. Albin
有没有类似于linux方法,通过汇编地址可以从汇编文件中反汇编回来函数名称?跑了一天时间又死在这一句上面
物理上,通过示波器测量死机的设备,32K晶振确实没有起振;正常设备32K是正常起振的;32K晶振不起振会是自己的应用程序导致的问题吗?还是说是晶振问题导致的硬件问题?
前面提到的VDDS休眠下跌落也可能是这现象。所以,除了crystal,还需要排查电源。
BR. Albin
死机之后我这边单步调试,发现代码一直在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))(); } } }
那就是没死机?怎么进了debug mode?
是不是JTAG口被干扰了?芯片进入debug mode,从应用看就像死机了?
BR. Albin
我是根据官方debug功能调试里面的防止重启那个继续调试的方法去设置的,等设备死机了再通过jtag,debug进去单步调试的,主函数下断点没反应,下面有几个截图,你看看能不能分析出来问题所在。
closed the issue off-line.
BR. Albin