LAUNCHXL-CC1310: 程序死机问题

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

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

user6336125 said:

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

看来您已经找到方向的。

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

几个方向可以排查：

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

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

BR. Albin

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

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进去单步调试的，主函数下断点没反应，下面有几个截图，你看看能不能分析出来问题所在。