[参考译文] CC2652R：TX 运行完成、无 TxDone 事件

更新。 我 现在看到 RFC_CMD_IEEE_TX_t 命令的 pop->status 已设置为0x2802、即 IEEE-ERROR_NO_FS。

这怎么可能呢？ 有什么关于如何处理此错误的建议吗？

尊敬的 Toby：

感谢您的答复！ 这种行为是否在某处有记录？

在我的 radio_callback 函数中或 pErrCb 中放置权变措施的正确位置是什么？

以及关于 pErrCb。 在 RF_Params 的注释中表明 pErrCb 已被弃用。 在如何处理 RFC 报告的错误方面是否有任何文档/指南？

BR Henrik

Henrik、您好、

Unknown 说：

感谢您的回复！ 此行为是否在某处记录？[/QUOT]

有关详细信息、请 访问：https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/proprietary-rf/proprietary-rf-users-guide/rf-core/radio-operation-commands.html?highlight=terminationreason#error-cases

Unknown 说：

在我的 radio_callback 函数或 pErrCb 中放置变通办法的正确位置是什么？

要在 radio_callback 中处理该错误、您可能必须订阅该错误代码(类似于您期望执行回调的其他状态)。

pErrCb 具体由 rf_fsmActiveState (在文件中 /source/ti/drivers/rf/RFCC26X2_multiMode.c)。

两者都可以用于实现相同的功能。

Unknown 说：

以及关于 pErrCb. 在 RF_Params 的注释中表明 pErrCb 已被弃用。 在如何处理 RFC 报告的错误方面是否有任何文档/指导？

您在使用哪种 SDK？ 至少对于我已安装的 simplelink_cc13xx_cc26xx_sdk_7_40_00_77、射频驱动程序仍包含它。

 关于如何处理射频误差、我会参考同一 RFCC26X2_MODEL.c。 您是否担心其他特定射频误差？ 我可以尝试帮助解决这些问题。

谢谢！
Toby

[/quote]

尊敬的 Toby：

目前我正在使用 SDK 7.10.01.24、pErrCb 已经存在、但在注释中"已标记"为弃用。 但是、如果这无关紧要、我将在 radio_callback 函数中处理。

目前、我的方法是：在 radio_callback 中的所有事件上检查 Op 命令状态、如果状态为 IEEE-ERROR_NO_FS、则会向我的无线电线程发布一条消息(我运行 TI-RTOS)。 在处理消息时、无线电线程将执行此操作：

        // Cancel any RF commands in the queue
        uint8_t stopMode = 0; //1: Stop gracefully, 0: abort abruptly
        RF_cancelCmd(rfHandle, RF_CMDHANDLE_FLUSH_ALL, stopMode);

        // Post a new CMD_FS
        RF_postCmd(rfHandle, (RF_Op *)&RF_cmdFs_ieee154_0, RF_PriorityNormal, 
                    radio_callback, RF_EventLastCmdDone);

您是否能够在调试器中检查该命令的状态？ (CMD_IEEE_RX.STATUS)

这可能是 RX 命令处于活动状态、但并未接收到数据包...  这就依赖于预期传输数据包的器件。 由于 FS 需要花费一定的时间才能完成、RX 命令可能是在预期的 TX 已经发生之后才启动的。

您是否能够尝试以固定的间隔(与系统时序无关)持续发送预期的数据包？

请注意、对于 rf_cancelCmd、您可能需要将 stopMode 与 RF_ABORT_FLUSH_ALL 进行按位或运算 (以匹配 RF_CMDHANDLE_FLUSH_ALL)。

Unknown 说：

no_fs 由 您发布的链接中的 rf_yield 处理、我该怎么办？

RF_Yield 将关闭无线电(但保持指针、例如在下一次加电期间运行的 FS 命令)。 这是一个可行的选择。

Unknown 说：

此外、这是非常繁琐的工作、因为这种情况是如此罕见的、您是否 知道是否有可能以某种方式引起该行为更加频繁地发生？

FS 基于 PLL。 尝试引发更多 FS 错误的问题是、即使实现了正确的处理(在无线电应用程序中)、人为挑起 FS PLL/PLL 错误的条件也会发生、即使在正确的处理后也是如此(例如在第一个 FS 错误和条件持续存在后、正确的错误处理、然后以下 FS cmd 也会出错)。

通常、对于这些类型的问题、我们会运行测试 X 个时间(其中 X 足以导致问题发生、在这种情况下、测试时间似乎是几个小时)。 在此期间、收集尽可能多的日志、同时最大程度地降低对系统性能的影响。

您是否能够在调试器中检查该命令的状态？ (CMD_IEEE_RX.STATUS)

不、很遗憾没有。 我有三个器件并发、其中一个器件上可能随机发生此错误。 在这种情况下、我可能必须同时调试全部三项内容(不过还不错、我想我会这样做并看看我可以学到什么)。

这可能是 RX 命令处于活动状态、但并未接收到数据包...  这就依赖于预期传输数据包的器件。 由于 FS 需要花费一定的时间才能完成、RX 命令可能是在预期的 TX 已经发生之后才启动的。

您是否能够尝试以固定的间隔(与系统时序无关)持续发送预期的数据包？

忘记提及的是、RX 命令具有相对于 StartTime 的 EndTime、而 endTrigger 设置为 TRIG_REL_START、即  即使是 TX、我也希望获得 RF_EventLastFGCmdDone 事件。

我会研究这个问题的！

如你所说,日志记录似乎是一种方式,这就是 我到目前为止所采用的方法。

非常感谢您的帮助！  

您好、又是 Toby。

不幸的是、这个问题仍然困扰着我们。 我转而在回调中执行 RF_Yield (正如 docs 中建议的那样)并向我的射频任务发布一条消息、该任务将新 RX 发布到 RFC 并尝试使所有内容都恢复正常。 它几乎如我所希望的那样工作、但我仍然遇到一些奇怪的问题。

我记录所有调用到 radio_callback、以下是围绕 no_fs 状态发生的事件：

 IDX:  CORE_MASK   DRIVER_MASK    TIMESTAMP   pOp                    pOp Status             RadioState   Delta time (us)   MASK_BITS                     
...
 18:   00800000     00000000    538832149   rfCmdRxSample          ACTIVE                   00000005      23624.0   RF_EventRxEntryDone,          
 19:   00000000     40000000    538833897   rfCmdRxSample          IEEE_DONE_STOPPED        00000005        437.0   , RF_EventCmdStopped          
 20:   0000001C     00000000    538881850   rfCmdTx1Sample         IEEE_DONE_OK             00000005     11988.25   RF_EventFGCmdDone | RF_EventLastFGCmdDone | RF_EventTxDone, 
 21:   00800000     00000000    539029399   rfCmdRxSample          ACTIVE                   00000005     36887.25   RF_EventRxEntryDone,          
 22:   00000000     40000000    539031400   rfCmdRxSample          IEEE_DONE_STOPPED        00000005       500.25   , RF_EventCmdStopped          
 23:   0000001C     00000000    539080117   rfCmdTx1Sample         IEEE_DONE_OK             00000005     12179.25   RF_EventFGCmdDone | RF_EventLastFGCmdDone | RF_EventTxDone, 
 24:   0000001C     00000000    539134275   rfCmdTx2Sample         IEEE_DONE_OK             00000005      13539.5   RF_EventFGCmdDone | RF_EventLastFGCmdDone | RF_EventTxDone, 
 25:   00000003     00000000    539260137   rfCmdRxSample          IEEE_DONE_OK             00000005      31465.5   RF_EventCmdDone | RF_EventLastCmdDone, 
 26:   0000001C     00000000    539282307   rfCmdTx1Sample         IEEE_DONE_OK             00000005       5542.5   RF_EventFGCmdDone | RF_EventLastFGCmdDone | RF_EventTxDone, 
 27:   0000001C     00000000    539332451   rfCmdTx2Sample         IEEE_DONE_OK             00000005      12536.0   RF_EventFGCmdDone | RF_EventLastFGCmdDone | RF_EventTxDone, 
 28:   00000003     00000000    539423007   rfCmdRxSample          IEEE_ERROR_NO_FS         00000005      22639.0   RF_EventCmdDone | RF_EventLastCmdDone, 
 29:   00800000     00000000    539822442   rfCmdRxSample          ACTIVE                   00000005     99858.75   RF_EventRxEntryDone,          
 30:   00000000     10000000    539824053   rfCmdTx1Sample         IEEE_DONE_OK             00000005       402.75   , RF_EventCmdCancelled        
 31:   00000003     00000000    539855180   rfCmdRxSample          IEEE_DONE_OK             00000005      7781.75   RF_EventCmdDone | RF_EventLastCmdDone, 

我们所看到的内容的描述：

第18行、我们收到一条信标消息。 当我们收到数据包时、我们取消 RX、调度应发送到时隙的数据并传输它、之后我们将收到 TxDone 事件(第20行)。 下一个大型机也是如此、第21-24行。

在第25行、我们无法接收到信标消息(RX 操作在未收到 RxEntryDone 事件的情况下完成)、但我们仍假设我们应在特定时隙中调度数据(使用 postCmd 并在特定时间触发 Tx、我们不使用链接、因此我们会对每个 Tx 执行新的发布)、因此我们这样做并传输数据(26和27)。 这有时会发生、并且是我们应用中的正常错误处理案例。 也就是说、这可能会正常发生并发生延迟、而不会发生 NO_FS。

当下一个 RX 操作完成时、其状态为 ERROR_NO_FS (第28行)。 这里我们执行一个 RF_Yield 并向我们的射频任务发布一条消息。 射频任务休眠一段时间(2ms)、然后在我们预计收到信标消息时发布新的 RX。

在第29行、我们收到信标消息、代码对 Rx 命令执行 RF_CancelCmd (与第18行和第21行相同)、但出于一些奇怪的原因、我们在 Tx 命令上收到了 CmdCanceled 事件(尚未发布)、而不是 Rx 命令上的预期 CmdStopped 事件。

对此有何建议？ 这是否必须是我自己的问题、或者这是否可能是驱动程序/RFC 中的问题？

BR Henrik

PS。 我显然渴望将这一问题标记为已解决、我们应该"不解决"它吗？

Henrik、您好、

Unknown 说：

并且它几乎像我所希望的那样运行、但我仍然遇到一些奇怪的问题。

器件/系统是否能在合理时间内从这些奇怪的问题中恢复？

在第29行、我们收到信标消息、代码对 Rx 命令执行 RF_CancelCmd (与第18行和第21行相同)、但出于一些奇怪的原因、我们在 Tx 命令上收到了 CmdCanceled 事件(尚未发布)、而不是 Rx 命令上的预期 CmdStopped 事件。

对此有何建议？ 这是否必须是我自己的问题、或者这是否可能是驱动程序/RFC 中的问题？

RF_EventCmdCanceled 表示命令在启动之前被取消(RFCC26X2.h)。 如果 TX cmd 传递给 RF_CancelCmd (与预期的 RX 相比)、则此状态有意义。

是否可能将错误的 RF_CmdHandle (TX)传递给了 RF_cancelCmd？

Unknown 说：

ps。 我显然渴望将这个问题标记为已解决、我们是否应该"解决"它？

当然、这可能会更准确地反映 此帖子的状态。

谢谢！
Toby