[参考译文] CC1312R：中止 RF_cmdRx 以发送 RF_cmdTx 后、RF_cmdRx 无法重新启用

忘记说我们正在使用  
simplelink_cc13x2_26x2_SDK_3_10_01_11

尊敬的 Martin：

很抱歉、响应时间太长。

您能解释一下"RF_cmdPropRx 未重新启动"时会发生什么情况吗？ 链中所有命令的状态是什么？

此致、
尼古拉伊

Nikolaj、您好！
我将尝试获取其他命令的状态。
正如我已经提到的、这是一种罕见的行为、因此需要一些时间才能获得所需的信息。
请耐心等待。

嗯、我在主循环中添加了一个针对  RF_cmdPropRx 上错误/意外状态的检查、以将所有命令的状态代码写入闪存。 因此我可以稍后读取它们。 但现在这种行为不再出现。

尊敬的 Martin：

很难调试这个问题、而无法重现这个问题。

 rfWrite 何时调用？

我不知道如何解决您的问题、但您能否尝试这些更改、看看它是否有帮助：

• 将 RF_flushCmd 函数的模式参数更改为0 (突然中止)
• 将  RF_PendCmd 函数的 bmEvent 参数更改为0。 这将导致 RF_PendCmd 仅在命令完成后返回。

此致、
尼古拉伊  

Nikolaj、您好！

调用 rfWrite 以发送对已发送给电路板的已接收消息的响应。 如果电路板未被寻址、消息将被丢弃。

我将 rf_flushCmd 的模式参数 和 rf_pendCmd 的 bmEvent 更改为0。  

我们在测试环境中对其进行了测试、错误磁性消失了。 现在、我们将软件发送给客户、以便他们可以在环境中测试软件。 我们将等待他们的答复。

希望通过这些更改来修复该误差。

尊敬的 Martin：

是否有关于该问题的任何更新？

此致、

Arthur

尊敬的 Arthur：
很抱歉、响应时间很长。

错误仍然存在。

我们从客户那里收集到的一个新信息。 我们板上有一个 LED 指示超时(未接收到此板的有效数据)。 LED 不会指示超时、因此接收到数据、但不发送响应。 因此错误必须位于 TX 命令中。

此时、我们通过代码搜索一些错误(错误的 RAM 访问、未处理的中断或其他错误)。

尊敬的 Martin：

是否还可以尝试在 RF_cmdPropRx 命令中启用.PastTrig，以及将 RF_cmdPropRx 的 endTrigger 设置为 TRIG_REL_START (0x04)和某个值(例如，1秒)？

我还想了解引脚卡在什么状态、因为器件可能卡在 RX 模式下。 为此、请在程序初始化阶段插入该代码：

//LNA to IOID_6
     IOCPortConfigureSet(IOID_6, IOC_PORT_RFC_GPO0,
                        IOC_IOMODE_NORMAL);
//TX (PA) to IOID_7
IOCPortConfigureSet(IOID_7, IOC_PORT_RFC_GPO3,
                IOC_IOMODE_NORMAL);

参考资料： https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_30_01_03/docs/proprietary-rf/proprietary-rf-users-guide/rf-core/signal-routing.html#routing-doorbell-signals-to-gpio-pins

此致、

Arthur