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.

[参考译文] CC1352P7:rfSynchronizedPacket 示例中的状态机和信标

Guru**** 2416110 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1179869/cc1352p7-statemachine-and-semaphores-in-rfsynchronizedpacket-examples

器件型号:CC1352P7

你好!  

我在示例的 StateMachine 源代码中看到此注释-  

    // SEM_WAIT 必须在不禁用中断的情况下运行。 TODO:如果需要,请仔细检查。
    HWIP_RESTORE (之前的 HWISTATE);

我想知道这是否必要、正如评论所要求的那样。  

我提出的原因是、这是因为我修改了此示例、它一次运行数天(或数小时)。  
然后,我似乎随机丢失了 StateMachine 线程上的活动。  
使用 RTOS 对象查看器时、我可以看到该信标上的线程一直处于挂起/阻止状态。  

它看起来不像完全死锁、因为我调用 StateMachine_pend/postEvents 的其他线程仍在运行。  
例如- 
StateMachine_EventMask 事件= StateMachine_pendEvents (&stateMachine、Event_PacketReceived | Event_PacketMissed、STATEMACHINE_Pend_Blocking);

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Mike:

    根据该评论,似乎当时已经有人对其使用提出疑问。 我将检查是否仍然存在这种情况。

    此致、

    Arthur

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗯、我的问题不是死锁。 我仍然在 rfSynchronizedPacket 示例中启用了一些陷阱。
    runCmd (cmdF)和 runCmd (cmdTxProp)捕获到陷阱中。  
    我禁用了这些陷阱并更改为 postCmd(cmdfs),现在我的设备运行了24小时以上。  

    这些陷阱对于示例来说是可以的、但在我的应用固件中不适用。