[参考译文] CCS/LPSTK-CC1352R：目标 CPU 停止时出现问题

您好 Jo、

有关-2062错误的更多详细信息、请参阅以下链接：

https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html#device-hung

[引用用户="Jo Geli"]

一切都可以正常运行几分钟、但在某个时候、我的电路板会在调用函数 RF_runScheduleCmd 时冻结(我从我的调试日志消息中知道它)

但是、此时、由于读取寄存器/异常/和错误指令、我无法停止处理器。

[/报价]

由于该问题发生在应用程序的特定点、因此应用程序本身可能存在一些问题。 我将把这个主题移至器件论坛。 那里的专家可以提供有关如何调试问题的更多建议。

谢谢

Ki

你(们)好

我从 DMM_wsnnode_ble_sp_app_CC1352R1_LAUNCHXL_tirtos_ccs 示例开始。

然后、我通过自己的协议删除任何 wsnnode 引用。

无线接入冲突是否是根本原因？

此外、我的代码不会动态分配任何内存。 但是、它看起来像是 TI 远程协议调用。

是否有任何方法可以跟踪/增加 RPC 堆？

此致、

嘿、Jo、

我不会认为无线电访问冲突会导致观察到的行为。  您是否已经完成了所有 DMM SLA？   https://dev.ti.com/tirex/explore/node?node=AIS9yiev7fig2l.r-sVAPQ__pTTHBmu__LATEST 

DMM 用户指南 ：https://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_4_20_00_35/docs/dmm/dmm_user_guide/html/tirtos/dmm-memory_management.html 中介绍了堆栈/堆分配/跟踪 

您如何处理 HW/SW 断言(尽管这些断言可以调试)？  您是否曾考虑过使用看门狗监控操作并在必要时复位？

此致、
Ryan

你好、Jo、

您是否在应用中的任何位置使用看门狗？

通常、当发生这种情况时、是由于某些意外复位导致的、您会发现"pause"按钮使我们在 CCS 中的状态变为灰色、指示调试器已断开连接。 通常、您可以转到"Debug"面板、右键单击器件并选择"connect"以再次访问该器件。 如果器件由于复位等原因而停止、您可以通过读取以下寄存器值来从该状态读取复位问题(假设您"在引导时停止")：

AON_PMCTL -> RESETCTL -> RESET_SRC

您好！  

我不使用 Watchog。

但是、我实现了低于1GHz 的发送功能、如下所示：

void tx_sings(uint8_t *数据，uint16_t data_len){

rf_CmdlHandle handle = rf_Open (..)；

...
RF_Close (handle)； 
｝ 

我注意到、如果我不为每个 Tx 调用 RF_open、崩溃就会消失。

我只是注意到、在您的所有示例中、RF_OPEN 只被调用一次。

此外、从 DMM 映射中：

#define RF_OPEN DMMSch_rfOpen
#define RF_postCmd DMMSch_rfPostCmd
#define RF_runCmd DMMSch_rfRunCmd
#define RF_scheduleCmd DMMSch_rfScheduleCmd
#define RF_runScheduleCmd DMMSch_rfRunScheduleCmd
#define RF_CancelCmd DMMSch_rfCancelCmd
#define RF_flushCmd DMMSch_rfFlushCmd
#define RF_runImmediateCmd DMMSch_rfRunImmediateCmd
#define RF_runDirectCmd DMMSch_rfRunDirectCmd
#define RF_requestAccess DMMSch_rfRequestAccess 

由于在启用 DMM 时 RF_Close 是唯一未替换的函数、因此 RF_Close 可能会产生预期的结果。 请确认吗？

如果我只调用 RF_open 一次、一切都正常！

感谢您的支持。