工具/软件:
使用 2340 作为节点、使用 2652 作为协调器。 串行端口数据通过上层计算机发送、然后将 64 字节串行端口数据发送给另一方。 执行双向数据传输。 节点另一侧串行端口的上部计算机每两秒发送一次数据、协调器每五秒发送一次数据。
在这个过程中,我发现程序崩溃了。 我怀疑程序重启后在初始化时卡住了。 下面是调试屏幕截图
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.
工具/软件:
使用 2340 作为节点、使用 2652 作为协调器。 串行端口数据通过上层计算机发送、然后将 64 字节串行端口数据发送给另一方。 执行双向数据传输。 节点另一侧串行端口的上部计算机每两秒发送一次数据、协调器每五秒发送一次数据。
在这个过程中,我发现程序崩溃了。 我怀疑程序重启后在初始化时卡住了。 下面是调试屏幕截图
您好、
除非您已执行 连接到正在运行的目标 的必要步骤、否则这些调试映像可能无法反映实际问题。 您能否说明您认为固件自行重新启动(即无需用户干预)的原因、并且您是否能够使用 CCS 调试器在该位置放置一个断点以进一步确定根本原因? 您是否能够 启用日志记录 以确定 Zigbee MAC、OSIF 或应用层正在传输哪些错误或消息?
此致、
Ryan
您好、
RSTSRC_WARMRESET 通常也是看门狗复位、由于 RSTSRC_WAKEUP_FROM_SHUTDOWN 或 RSTSRC_WAKEUP_FROM_TCK_NOISE 在这种情况下没有意义、因此您必须遇到看门狗复位。 您能否在 ZB_INIT 之前检测复位原因/源、并考虑改用完全系统复位 (PMCTLResetSystem) 来确定这是否可以解决问题?
我们尚未确定 为什么会发生看门狗复位。 我之前提到过、 在调试期间将断点置于 ZB_RESET -> PMCTLResetSystem 和 FALATE_ERR(也是 EXCEPTION_HANDlerSpin)中、以确定应用程序是否在永久 while 循环中保持。
此致、
Ryan