[参考译文] CC1354P10：RF 发送在 CC1354P10中挂起 RF_runScheduleCmd ()

您好、Prasad、

您可以使其在给定时间后的命令超时、如以下所示： https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1201184/cc1352p-radio-command-chain-for-tdma/4530336?tisearch=e2e-sitesearch&keymatch=endTrigger#4530336

此致、

亚瑟

Arthur、您好！   

IEEE 802.15.4传输结构/命令(struct _RFC_struct RFC_CMD_IEEE-TX_s)没有结束时间。  或结束触发器。   

如何实现发送 EEE 802.15.4 命令的超时？

此致

普拉萨德

您好、Prasad、

在这种情况下、我建议您使用 RF_CancelCmd 来中止命令、如下所示： https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1236705/launchxl-cc1310-how-to-reset-cc1310-rf-core-my-program-seems-let-rf-stuck-and-can-t-use-rf_close-to-restart-it/4679445#4679445

此致、

亚瑟

您好、Prasad、

我想知道您是否已经浏览过该主题： https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/980850/launchxl-cc26x2r1-rfpackettx-example-hangs-after-reconfiguration-to-ieee-802-15-4-phy/3645768#3645768

此致、

亚瑟

Arthur、您好！

我只是从这个示例代码中启动了原始代码。  我已经在 IEEE 802.15.4模式下针对 Tx 和 Rx 数据包测试了这段代码一整晚、然后我才说明在我的产品中使用了这段代码。  但现在、当我在我的产品固件中实现此功能时、我感到吃惊。  我尝试了多种方法来解决此问题、但没有取得任何成功。  

1. 我不能使用  RF_cancelCmd ()来取消我在原帖中所说的挂起传送命令。   RF_cancelCmd ()需要 RF_CmdHandle 来取消该特定 命令。  但是 用于传输802.15.4数据包的 RF_runScheduleCmd ()不会返回 RF_CmdHandle。  RF_CmdHandle ()只在回调函数中发送,该函数仅在发送命令成功完成后发生,因为代码挂起于信标挂起。我不知道 RF_CmdHandle 调用 RF_runScheduleCmd   ()

2. 当这个问题发生的时候,我决定在计时器中断中调用 rf_flushCmd ()。  正如你所知道的, 当执行下面的例程时,我的邮件循环在 rf semaphore_pend ()的传输例程中被击中。 我已经  在计时器中断中完成了 RF_flushCmd ()、这是我唯一可以选择的。   请参见屏幕截图、因为上一个命令未完成并等待它完成、所以 flush 命令也已挂起。  这是一个链条。  

RF_EventMask 终止 Reason = RF_runScheduleCmd (
rfHandle、
(RF_Op*)&RF_cmdIeeTx_ieeee154_0、
&rfSchedParams，
rfTxCallback、
0
)；

3. 接下来我想我会做 RF_CLOSE()然后使用 RF_OPEN()重新打开 RF，甚至 RF_CLOSE(0也会挂起，因为它还在等待前一个 TX 完成。

它在 RF_CLOSE (0函数)的注释中提到、如下语句。  第二条语句的意思是什么,谁有权访问 RF_RequestAccess() API?   

* rf_close 在关闭连接之前会挂起命令队列中的所有命令。
*如果客户端通过使用 RF_RequestAccess API 访问对讲机,并且同一客户端调用 RF_CLOSE ,则立即关闭与射频驱动器的连接,而无需等待访问持续时间结束。

4. 我最后尝试的方法是通过下面的方式进行传输, 用100毫秒的结束时间来查看命令是否在100毫秒后退出,在最坏的情况下,如果它挂起。  但这也不会成功。  

rSchedfParams.endType = RF_EndAbs；
rSchedfParams.EndTime = RF_getCurrentTime ()+ RF_convertMsToRatTicks (100)；

RF_EventMask 终止 Reason = RF_runScheduleCmd (
rfHandle、
(RF_Op*)&RF_cmdIeeTx_ieeee154_0、
&rfSchedParams，
rfTxCallback、
0
)；

rSchedfParams.endType = RF_EndNotSpecified；
rSchedfParams.EndTime = 0；

总之、该问题仅在大约30分钟左右传输2000个数据包后才会出现。  

我非常需要一种方法来解决这个问题。  我觉得在运行 大家分享的 IEEE 代码示例时没有遇到这个问题。  我用该代码运行了一整夜、我不记得我看到了这个问题。  在该示例中、我每秒发送1个数据包。  我在这里使用了完全相同的代码、但对我的应用程序而言、这些应用程序 对无线电功能没有任何影响。  

稳压器

普拉萨德  

您好、Prasad、

您可以使用 RF_scheduleCmd 而不是 RF_runScheduleCmd。

这样、在接收命令句柄之前、您不必等待命令完成。 然后、您可以自己触发一个计时器来检查命令的执行是否花费了较长的时间、然后调用 RF_cancelCmd、这将根据给定的参数刷新所有命令。

此致、

亚瑟

Arthur、您好！

使用  rf_scheduleCmd ()改进但尚未完全解决问题 ,让我来 逐步解释。  

1、我的主单环路、每50ms 发送一次传输包、见下面的屏幕截图、在发送之前、我正在取消等待接收射频包的 RX 命令(我没有等待取消操作在这里完成)。 然后发送数据包,等待 transmit 命令完成使用 RF_PendCmd ()使用已发出的 RF_CmdHandle。  在完成该传输数据包之前不会发生新的数据包传输、因为它是单环路、但无线电已处于接收模式、并且可能在我们要发出传输时正在接收数据包。 这就是 我要取消接收命令、然后再将无线电置于 Tx 中的原因。  我稍后将做的一个改进是检查无线电是否处于数据包接收的中间(如果 使用您的库可以接收)、然后我将等待无线电完成接收、然后继续传输、我稍后将执行此部分。  目前、正如您在屏幕截图中看到的那样、只需取消 Rx 命令、然后启动传输。  

2、 我的定时器回调正在检查传输是否挂起超过100毫秒,然后取消传输,但它在这里被击中,以取消 我们通过  RF_scheduleCmd()获得的命令句柄。  它只是在 RFDOorbellSend()库函数中循环。 传输句柄正确。   程序在出现此问题之前运行超过10000个数据包、大约500秒(每50ms 运行一个数据包)。  10000th 数据包是一个延迟超过100毫秒的传输,我试图取消,它击中了这里。  9999个数据包在100ms 内传输,所以我没有 找到取消它们的理由。                                                           

此致

普拉萨德     

您好、Prasad、

您是否说第10000th 个数据包始终无法及时传输？ 如果您每25ms 进行一次传输、它显示出相同的行为吗？

此致、

亚瑟

Arthur、您好！

不、 我只是举个例子。 它并不总是10000th 数据包。  发送数据包在 SENSE 中间歇性地挂起、某些时间是第4000个数据包、某些时间是9922个数据包。  它是随机的。  我能说的是、在它进入挂起状态之前、它对几千个数据包的正常工作。 在这张图片的右侧我的最后一封电子邮件中、如果你看一下 IAR worbench 的第一张图片、会发现传输计数为(RFTransmitCnt) 6523。  因此，这就是 RF_ScheduleCmd ()挂起超过一秒钟的数据包编号，然后我会尝试在计时器中断时取消该命令，并且 RF_cancelCmd ()也会挂起。  我认为 RF_CancelCmd (0直到前一个挂起的  RF_ScheduleCmd () 完成后才会执行。  我不知道驱动程序代码的内部行为,但我所说的是如果 RF_ScheduleCmd () 因任何原因挂起,RF_cancelCmd ()不会取消它。  不确定这里有什么用途？  如果您需要、我可以创建创建此问题的示例代码、以便您可以复制自己。  

此致

普拉萨德  

您好、Prasad、

当然、它可以帮助提供示例代码。

同时、我还记得那个主题： https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1136341/cc1312r-after-aborting-rf_cmdrx-to-send-rf_cmdtx-the-rf_cmdrx-cannot-re-enabled/4449092#4449092

您能尝试一下我针对该主题的最新评论中的操作吗？ 即：

• 在 TX 命令上启用 PastTrig
• 在 GPIO 上输出 PA/LNA 引脚(TX/RX)、以便您可以运行示波器/逻辑捕获故障情况。

此致、

亚瑟

Arthur、您好！

首先、我在 GPIO 上启用了 PA/LNA 引脚以下是结果。  我的第一个代码屏幕截图是在那里捕获的。  这与未启用 pastTrig 但仅在 GPIO 上启用 TX/RX 的代码相同。  在我遇到此问题之前、您可以看到发送和接收的数据包数量(分别为37594和46146)。  您从屏幕截图中可以看到它所点击的位置。 已安排的传输并等待传输完成。

我的计时器回调之所以生效、是因为 TX 等待的时间超过100ms。  我的计时器回调尝试取消命令。  我先尝试了 cancel 命令、然后刷新所有命令。 两者测量的结果相同。  您可以看到下面的注释代码、以前也尝试过。  

2.在上述状态中搜索该代码时，这里是逻辑分析仪的输出。 第一行是 LNA 输出、第二行是 PA 输出

我每250毫秒传输3个数据包。  在同一250毫秒内接收3个数据包。  我的测试中还有一个器件、它会接收该节点传输的每个数据包并重新传输回。  

 让我扩展1个 Tx/Tx Rx 实例、如您所见、从 Rx 切换到 Tx 大约花费了192us

让我们来看看传输被完全击中时所发生的事情的结束。  它在80uSec 内从 Rx 切换到 Tx、然后永久点击。  

我检查了波形时序中的几个实例、用于 RX 到 Tx 开关、所有时间都是192usec、但最后一个实例、我们始终在 TX 中受到冲击、从 RX 切换到 Tx 花费了80us、这是非常奇怪的、可能会解释 为什么 Tx 会被永久命中。  

我将通过电子邮件向您发送捕获信息。  您可以在 Salae 的逻辑软件中打开逻辑分析仪的捕获图、您可以从 Salae 网站免费下载该软件。  

返回到针对 Tx 命令的 pastTrig、我们只有用于启动 Tx 的 pastTrig、对于 endTrigger 则没有。 但我将尝试遵循以下内容、看看这是否有用。  请确保在 Rx 被阻止后将 Tx 延迟一段时间。  让我们看看这是否有用。 。  

1..  在 Rx 中止后使用 Nop 命令启动链命令 Nop --> CS --> Transmit 查看其是否有效。  

 2.如何使用 startTrigger 的 pastTrig ,它到底做什么?

// CMD_IEEE_TX
// IEEE 802.15.4发送命令
RFC_CMD_IEEE_TX_t RF_cmdIeeTx_ieeee154_0 =
{
.commandNo = 0x2C01、
.status = 0x0000、
.pNextOp = 0、
.StartTime = 0x00000000、
.startTrigger.triggerType = 0x0、
.startTrigger.bEnaCmd = 0x0、
.startTrigger.triggerNo = 0x0、
.startTrigger.pastTrig = 0x0、
.condition.rule = 0x1、
.condition.nSkip = 0x0、
.txOpt.bIncludePhyHdr = 0x0、
.txOpt.bIncludeCrc = 0x0、
.txOpt.payloadLenMsb = 0x0、
.payloadLen = 0x1E、
.pPayload = 0、
.timestamp = 0x00000000
}；

此致

普拉萨德  

您好、Prasad、

感谢您提供的数据、我今天要看一下。

在 startTrigger.pastTrig 之前、技术参考手册中包含以下内容：

这就是为什么尝试该选项来看看我们是否看到了堵塞很有趣。

我们可以查看额外的数据点、这是发生阻塞时的 RF_cmdIeeTx_ieeee154_0.status 变量。 它的价值是什么？

此致、

亚瑟

Arthur、您好！

我为 pastTrig 实施的 startTrigger 问题仍然存在

1.从下面的屏幕截图中可以看到、我为调试器选择的代码、在 Tx 启动前添加了200usec、该功能可从逻辑分析仪屏幕截图中使用

2. 之前在 GPI0到 GPO3之间的过渡是200usec 和现在有了这个 pastTrg 加起来它已经变成了500usec

3.逻辑分析仪在 Rx 到 Tx 转换之间也有80usec 输出的时间  

4. 同样、Tx 的结构结束时、RX 到 Tx 的转换产生了30usec 的差异  

5.发生这种情况时 Tx 命令的状态为2. 如右侧的观察窗口所示。  

此致

普拉萨德  

你好,亚瑟从我的另一个观察.  

1. 这是发生问题之前最后一个成功的数据包屏幕截图  GPIO3是 TX 启动、GPIO 是 PA 启用、PA 启用在 Tx 启动激活后激活6usec。  所有成功的传输都是这种情况。  

2.查看问题发生时的屏幕截图 Tx 启动被激活但 PA 从未被激活。  CC1354系列是否存在这一特定问题？

此致

普拉萨德  

您好、Prasad、  

抱歉该线程上的延迟。  

我的一个观察结果是 、似乎您的 cancel 命令使用了异常终止设置、因此如果确实有激活命令卡住、这只会等待命令结束。  

请用最后一个参数0来调用 RF_cancelCmd (),而不是 RF_ABORT_GANLEY 来调用它吗?  

这样您就可以立即取消该命令。

我确实有几个问题：

1.在调试会话中、当进入此 TX 卡滞情况时、请检查寄存器视图。 看到 RFCPEIFG 寄存器的值会很有意思。 这将提供射频内核的命令和数据包引擎的准确状态。 请注意、当您运行代码时、寄存器可能无法读取、但当您遇到断点时、 CCS/IAR 应 显示该值。  

2.在前面的逻辑分析仪图中，PA 似乎卡在高电平？ 在此响应中、逻辑分析仪曲线图似乎表明 PA 信号为高电平。

Unknown 说：

我检查了波形时序中的几个实例，用于 RX 到 Tx 切换，它花费了192usec 的时间，除了最后一个实例，我们在 TX 中被永远击中，从 RX 切换到 Tx 花费了80us，这很奇怪， 可能会解释为什么 Tx 会永远被点击。  [/报价]

但在最新的图中、您提到 有 额外的 GPIO 作为 TX 启动、并说 PA 从不会变为高电平。 请您解释一下在本例中 TX 启动的含义是什么？

3.我还需要确保您只使用 RF_OPEN 一次、并且在整个代码中使用了相同的 RF_Handle。 请您确认这一点。

4.如果 cancelCmd ()即使没有正常的设置也不起作用, 请您尝试使用 postCmd ()而不是 ScheduleCmd (),看看这种行为是否被重现。 如果前面有一个正在运行的命令，postCmd ()不会取代任何命令。

此致、

SID

尊敬的 Sid：

1. 如果你看一下我分享的所有 myscrapets ,我有 treid  rf_cancelCmd () 与0和 f_abort_genally 选项多次确认它。  在这两种情况下 RF_cancelCmd ()永远不会取消挂起的 RF_scheduleCmd ()使用的数据包传输。  在过去2周内、我会尝试这两个选项至少30次。 在 RF_cancelCmd () 与0或 稳定的任意组合中。 还有 RF_flushCmd (rfHandle、RF_CMDHANDLE_FLUSH_ALL、0)； 对于所有挂起的 Cmd 处理、具有0或 RF_ABORT_AUGANY、只是始终挂起。  永不出来。  唯一解决方法就是使用看门狗来重置流程。  两次我做了这个练习多个组合,多次延迟等,没有成功。  

即使我厌倦了使用 startrigger 来执行延迟 Tx 传输等一些事情、但运气不好

// rf_cmdIeeTx_ieee154_0.startTrigg.triggerType = TRIG_ABSTIME；
// rf_cmdIeeeTx_ieee154_0.StartTime = RF_getCurrentTime ()+ RF_convertUsToRatTicks (200)；

我将捕获寄存器并将其发送给您。

发生该问题时、PA 线路(GPO1)从不变为高电平、它保持低电平、但发送起始线路(GPO3)正如预期的那样变为高电平。 在我上次的回复中、我展示了第一个屏幕截图是成功传输、其中 PA 线路(GPO1)为高电平、传输成功。   在发生此问题的第二个屏幕截图中、GPO1 (PA 线路)为低电平、从未变为高电平、但传输起始线路(GPO3)显示为高电平。  无线电电路似乎开始发射、但无法打开 PA、可能会在那里被永久击打。  不确定无线电电路内部发生了什么。  

3.查看我的情节中前3行的名称(第1行- GPO0、第2行- GPO3和第3行- GPO1 )。  忽略第4行、它是我的调试行。  根据您的数据表查看这些行的含义(屏幕截图如下所示)。  GPO0 - LNA 启用、GPO1 - PA 启用、GPO3 -发送开始)。  3个引脚的组合表示它们。

4. 是的、 RF_OPEN 只执行一次、并且在整个测试过程中使用了相同的 RF_Handle 并且 RF_Handle 完好无损。  我确保它不会再次打开、并且 RF 手柄没有损坏或更改。  

5. 我会尝试 postCmd ()而不是 ScheduleCmd () ,让你知道。  

我有两个操作可以执行。  

• 在出现问题后向您发送注册转储。
• postCmd()而不是 ScheduleCmd()

将在星期一发送。

此致

普拉萨德  

尊敬的 Sid：

这是示例代码。  

\CoreThermostat20\HyperBank20_1354路径中存在 HyperBank20_1354.eww。  我使用的 IAR 工作平台9.30.1和 TI SDK   simplelink_cc13xx_cc26xx_sdk_7_10_01_24  

e2e.ti.com/.../CoreThermostat20.zip

在两个 CC1354P10节点中运行此代码。 它们在通道25 IEEE 802.15.4模式下的发送和接收速度都很快。  如果可能的话、将它们全部保留在调试器中、如果不是至少一个保存在 调试器中。  发送数据包时、LED 红色闪烁、接收时、绿色闪烁。  

在 DREV_RF_CC1354.c 文件中的函数 void * mainRFThread (void * arg0)中有两行、为一个板启用一行、为另一个板启用另一行。  无论您保持不变、但您都可以在通道25中监听它们的通道监听器。  看到我的调试器板挂在我之前讲过的地方。  

//unsigned char data[]="ffeeeddddccccbbdbaaa998888777766665555444433332211110000"；
无符号字符数据[]="00009999887777666655554444332211aaaabbbbccddddedeeefffff"；

监听器输出。  

注意 ：- 仅当两个主板都在运行时才会出现问题。  如果您正在调试的主板挂起、请重新启动电源、这样您就可以在调试的主板上看到问题。   这种情况没有时间框架、但很可能在一个小时内发生。  

我想告诉您的另一件事是、如果在代码文件 DRIV_RF_CC1354.c 中启用了行391 - 393、则非常不存在问题。  一天中可能发生一次。   如果启用了这3条线、则法院判决的概率下降了90%。  

/*RF_cmdNop_ieee154_0.StartTime = RF_getCurrentTime ()+ RF_convertUsToRatTicks (50);
RF_CmdHandle nopCmdHandle = RF_postCmd (rfHandle、(RF_Op*)和 RF_cmdNop_ieee154_0、RF_PriorityHigh、NULL、0)；
rf_pendCmd (rfHandle、nopCmdHandle、0)；*/

请给我一些解决办法,在前面,已经很长时间的等待。

此致

普拉萨德  

您好、Prasad、

我已对其进行设置并运行。 我看到绿色和红色 LED 持续闪烁。 出现了非调试器 launchpad 遇到 sruck。 但没有设法使调试器1发生故障、这大约在一个小时内发生了一次。

但是我看到所有 cancel 命令都正常中止。 我假设您已尝试将所有取消切换为突然取消。

2.是否曾尝试使用 postCmd 来布置 TX 命令而不是 scheduleCmd？

此致、

SID

H Sid、

这个问题不是时间基准,我得到这发生在15分钟内以及2小时。 确保两个器件都呈红色闪烁和绿色 LED、如果触发了非调试器(两个 LED 都停止闪烁)、请重新启动。  如果碰巧调试指针、它将处于挂起状态。  

1.是的,我尝试了 cancel()与突然取消(0)也,但正如你看到在我之前的帖子,问题仍然存在。 突然或优雅地取消具有相同的行为。

2. 我没有使用 RF_postCmd ()直到现在, 但今天我看到了你的经验,我开始使用 postCmd ()而不是 RF_scheduleCmd  ()在这个同样的例子中传输数据包,它似乎在过去的6个小时没有任何挂起。  它曾经挂起或三次在两个板  RF_scheduleCmd (),但与 RF_postCmd ()到目前为止似乎运转良好。  我会把它运行过夜,并再次确认你.

txCmdhandle = RF_postCmd (RfHandle，(RF_Op*)与 RF_cmdIeeTx_ieeee154_0，RF_PriorityHigh，0，RF_EventLastFGCmdDone )；

我使用了上面的行,而不是 rfTransmit()中的 rf_scheduleCmd ()。

即使这解决了问题,我仍然想知道为什么原始 RF_scheduleCmd ()是挂起的。  

此致

普拉萨德

您好、Prasad、

您是否再次看到 postCmd ()的崩溃?

我要求使用 postCmd ()对其进行测试的主要原因是使用 postCmd 发布的无线电命令不要优先于正在运行的射频内核命令，而是等待当前命令完成执行。  

您可能有一个竞态条件、但通过从不抢占正在运行的射频内核命令而得以避免。 这不是对情况的准确描述,但可以解释为什么您没有看到 postCmd ()的卡住的应用程序。

此致、

SID

尊敬的 Sid：

我用 postCmd 运行代码24小时,我没有看到崩溃。  

此致

普拉萨德

尊敬的 Sid：

我在启用 CSMA 发送命令时遇到问题。  它根本不传输数据包。 传输回调报告 ERROR_WRONG_BG ("FG 级别命令与运行的 BG 级别命令不兼容")。 我修改了代码以启用 CSMA 传输、而不是之前使用的常规传输。  您能否仔细看下面的代码、并告诉我为什么 CSMA 传输出现错误、不传输。  我 在 SDK 中引用了来自您的源文件的该代码。  它与旧代码相同、但更改很少、可启用 CSMA 发送。  我需要基于 CSMA 的传输以避免数据包丢失。  

您是否能够使用  RF_scheduleCmd ()重现崩溃?  用于解决该问题的任何发现。   现在看来,我已经开始了。 到目前为止没有崩溃。  

此致

普拉萨德

  e2e.ti.com/.../CoreThermostat20_2D00_csma.zip

感谢您对这些问题 Sid 的任何更新。   我正在等待这些问题尽快得到解决

您好、Prasad、

我很抱歉耽误你的时间。 已经发生了很多事情。  

FG 级别命令与运行的 BG 级别命令不兼容。 这使我相信有一条有效的 BG 命令正在运行。 和 CSMA 命令调度失败、因为、这无法与当前运行的 BG 命令并发运行。  

在查看代码时、您似乎将无线电置于接收模式、并且在您尝试计划 CSMA 命令时、BG 中可能存在正在运行的 IEEE RX 命令。 一种查找方法是检查 LNA 信号、并在提交 CSMA 命令之前切换 LED。 然后、我们可以看到无线电是否确实处于 RX 状态。  

请进行此测试。 如果这确实是问题的根本原因、我将与 rnd 核实可以采取什么措施。 您很可能需要中止 RX 并运行 CSMA 命令、然后再次调度 RX。

此致、
SID

尊敬的 Sid：

看一下我共享的、经过我复制的以下内容的示例 CSMA 代码文件、我确定主动 RF 命令已停止、等待它完成。 然后、我只输入 CSMA 发送命令。  是的、我确保 LNA 引脚为低电平、然后仅启动 CSMA TX 启动是通过引脚捕获进行的。  这正是我针对非 CSMA 数据包传输所采取的方法。  但是、CSMA 传输会将无线电带回到侦听模式以在启动传输之前检测能量。 此命令 itslelf 必须将 radi oto rx -->测量能量-->如果自由传输-->退避然后回到 Rx -->等等。   

有源 RX 和 Tx 是 CSMA 命令本身的一部分、TI 库负责处理该命令。 我猜这是库代码方面的问题。 eample 代码供您查看

此致

普拉萨德

如果 ((rxCmdhandle！= RF_ALLOC_ERROR)&&

您好、Prasad、  

我曾和我们的无线电专家谈过 IEEE 命令。  我对上一个答案表示歉意。 这里的问题是、当您运行 CSMA-CA 命令时、 没有有效的 Rx 命令。

该技术参考手册确实提供了可以同时运行的前台命令和后台命令的组合。 如果没有活动的后台命令、则前台的 CSMA-CA 会导致 ERROR_WRONG_BG。 这意味着、如果有活动的 RX 命令在运行、则可以运行 CSMA 命令。 如果未执行此操作、则需要运行 RX 命令或能量检测、然后运行 CSMA 命令。

https://dev.ti.com/tirex/explore/node?node=A__AO0VNcTkm37Mb0AVH5vFDQ__cc13x0_devices__coGQ502__LATEST

请查看本文档的第25.5.4节

此致、
SID

尊敬的 Sid：

我已启用 ED 命令、然后发出 CSMA 发送。  然后开始工作。 当我放置干扰源时、命令传输会按预期停止。   感谢您的投入。  

但我观察到的 i , CSMA 命令只适用于  RF_scheduleCmd ()。  使用  RF_postCmd ()执行 CSMA 命令,然后调用 RF_pendCmd ()来等待用 RF_postCmd ()返回的命令处理程序,只是使 RF_pendCmd ()永远等待。  这可能是由于能量检测命令已在运行。 使用 RF_postCmd ()运行的多个命令不起作用？

我不使用  rf_scheduleCmd ()的担忧是它有时挂起一次,正如你知道的,我们只从这个问题开始这个线程。  您是否曾找到我启动本主题时出现的原始问题的根本原因？ 带有 RF_scheduleCmd()的 CSMA 命令使我们回到最初的挂起问题。  希望找到这个问题的根本原因 RF_scheduleCmd ()与测试代码我很久以前给你提供。  。  

此致

普拉萨德  

您好、Prasad、

您可以发布多个命令。 但如果您看一下 postCmd 源代码、可以看到它只是附加到挂起命令队列、而 scheduleCmd 处理 FG 和 BG 命令。 我认为这是因为在 ScheduleCmd 可以优先于命令并在需要时运行 FG 命令时、postCmd 不会优先于正在运行的命令。  

我将再次设置该计时器并最终运行一个调试会话、以检查 ScheduleCmd 为何真的偶尔会导致崩溃。   

在调度 CSMA 命令时是否看到挂起、还是仅在调度 TX 命令时才看到挂起？  

此致、
SID

尊敬的 Sid：

令人惊讶的是,到目前为止,我没有看到挂起问题的 CSMA 命令调度使用  RF_scheduleCmd ()。  与之前使用 RF_scheduleCmd( )发出 Trasnmit 命令时没有其他命令运行的情况相比,在调度此 CSMA 命令时,只有 ED 命令在运行。

不确定运行 ED 命令是否确实有依赖关系。

此致

普拉萨德