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.

[参考译文] CC1200:射频模块进入空闲状态、不会恢复。 可能的原因是什么?如何恢复?

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

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1136892/cc1200-the-rf-module-goes-in-idle-state-and-does-not-recover-what-can-be-the-possible-reason-and-how-to-recover-it

器件型号:CC1200

我们已将 CC1200配置为每250ms 定期传输一次、还将其配置为监听模式以接收来自空中的数据包。 在成功运行大约一小时后、在监听模式和 TX 模式之间切换时、射频进入空闲状态、即使在重试2-3次后、射频也不会自行恢复。 我尝试强制将状态更改为空闲、然后再次更改为 TX、但这也不起作用。 因此、我无法接收任何数据包或传输任何数据包。

这种行为的可能原因是什么?如何 防止这种行为? 我观察到唯一的恢复方法是通过下电上电、我还能如何恢复它?

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

    您如何知道它处于空闲状态? 您是否已读取 MARCSTATE 寄存器?

    如果出于某种原因出现 RX 溢出或 TX FIFO 下溢情况、在没有冲洗相关 FIFO 的情况下、您将无法再次进入 RX 或 TX。

    如果不知道寄存器设置以及在 SW 中的 RX 和 TX 之间进行错误处理和切换的确切程度、 就无法准确判断导致这种情况的原因。

    Siri

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

    是的、我读取了 MARCSTATE 寄存器并知道它处于空闲状态。 我也检查了 FIFO 错误情况、而不是这样。

    在 SW 中、我直接在 TX 和 EWOR 之间切换。 RF 始终处于监听模式、并在接收到 RXFIFO_THR_PKT (0x01)中断时接收数据包。 我们在将状态切换为 TX 后每250ms 发送一次、并在 TX 完成后将状态更改为 EWOR

    下面是使用的寄存器设置-  

    静态常量 stRegSettings g_stPreferredSettings[]=

          {CC1200_IOCFG2、           0x29}、//同步检测
          {CC1200_IOCFG0、           0x01}、//RX FIFO 阈值+数据包末尾
          {CC1200_SYNC3、            0xF0}、
          {CC1200_SYNC2、            0xCC}、
          {CC1200_SYNC1、            0xF0}、
          {CC1200_SYNC0、            0xCC}、
          {CC1200_SYNC_CFG1、        0xA8}、
          {CC1200_SYNC_CFG0、        0x13}、
          {CC1200_deviation_M、      0x68}、
          {CC1200_MODCFG_DEV_E、     0x04}、
          {CC1200_DCFILT_CFG、       0x26}、
          {CC1200_PREAMING_CFG0、    0x8A}、
          {CC1200_IQIC、             0x00}、
          {CC1200_CHAN_BW、          0x82}、
          {CC1200_MDMCFG1、          0x42}、
          {CC1200_MDMCFG0、          0x05}、
          {CC1200_symbol_Rate2、     0x7F}、
          {CC1200_symbol_rate1、     0x75}、
          {CC1200_symbol_RATE0、     0x10}、
          {CC1200_AGC_REF、          0x2A}、
          {CC1200_AGC_CS_THR、       0x01}、
          {CC1200_AGC_CFG1、         0x16}、
          {CC1200_Setting_CFG、     0x03}、
          {CC1200_FIFO_CFG、         0x5F}、//FIFO 电平63 -> 0x3F //95 -> 0x5F
          {CC1200_FS_CFG、           0x12}、
          {CC1200_WOR_CFG0、         0x20}、
          {CC1200_WOR_EVENT0_LSB、   0x67}、
          {CC1200_PKT_CFG2、         0x00}、
          {CC1200_PKT_CFG1、         0x00}、
          {CC1200_PKT_CFG0、         0x20}、
          {CC1200_RFEND_CFG0、       0x04}、
          {CC1200_PA_CFG0、          0x55}、
          {CC1200_PKT_LEN、          0xFF}、
          {CC1200_IF_Mix_CFG、       0x18}、
          {CC1200_TOC_CFG、          0x03}、
          {CC1200_MDMCFG2、          0x00}、
          {CC1200_FREQ2、            0x5B}、
          {CC1200_FREQ1、            0x99}、
          {CC1200_FREQ0、            0x99}、
          {CC1200_IF_ADC1、          0xEE}、
          {CC1200_IF_ADC0、          0x10}、
          {CC1200_FS_DIG1、          0x07}、
          {CC1200_FS_DIG0、          0xAB}、
          {CC1200_FS_CAL1、          0x40}、
          {CC1200_FS_CAL0、          0x0E}、
          {CC1200_FS_DIVTWO、        0x03}、
          {CC1200_FS_DSM0、          0x33}、
          {CC1200_FS_DVC0、          0x17}、
          {CC1200_FS_PFD、           0x00}、
          {CC1200_FS_PRE、           0x6E}、
          {CC1200_FS_REG_DIV_CML、   0x1C}、
          {CC1200_FS_SPARE、         0xAC}、
          {CC1200_FS_VCO4、          0x13}、
          {CC1200_FS_VCO2、          0x64}、
          {CC1200_FS_VCO1、          0xAC}、
          {CC1200_FS_VCO0、          0xB5}、
          {CC1200_IFAMP、            0x0D}、
          {CC1200_XOSC5、            0x0E}、
          {CC1200_XOSC1、            0x03}、
    };

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

    我仍然不清楚您的代码是如何发生故障的。  

    您会说" 射频进入空闲状态、即使重试2-3次、它也不会自行恢复。" 这话什么意思?

    在传输数据包后和接收数据包后、对讲机都将进入空闲状态、因此没有任何问题。

    问题是它没有脱离空闲状态吗? 如果是,这种情况是什么时候发生的(当盗取 STC 时,抢刀,在收到数据包后?)

    我需要了解您在代码中所做的工作、看看我是否能理解出什么问题。 我不需要您的整个应用程序代码、但需要了解状态之间的变化方式和时间、以及如何处理传入数据包(您使用的是什么中断、您在 ISR 中执行的操作等)

    Siri

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

    我成功接收数据包并传输数据包的时间约为一小时。

    对于每次传输、我都在向 TX FIFO 填充所需的数据、并通过 strobing STX 将射频状态更改为 TX。 然后、我将检查 MARC 状态是否实际处于 TX 模式。  

    你是对的、我是说、即使在 strobing STX 之后、射频状态也不会改变、并且没有传输。

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

    是否在选通 STX 前检查了 MARCSTATE?

    如果我没有您的代码、我不能说会出现什么问题。  

    我从未听说过与进入 TX 状态相关的问题、除非您来自错误状态、该状态未得到正确处理。

    也就是说、如果您进入了上溢/下溢状态、并且只需选通空闲即可退出该状态而不是清除 FIFO、那么在尝试发送下一个数据包时、FIFO 指针可能会出现问题。

     在尝试发送未发送的数据包之前和之后、TXFIRST、TXLAST、NUM_TXBYTES、FIFO_NUM_TXBYTES 的值是多少?

    Siri

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

    我们在 strobing STX 之后读取 MARCSTATE。

    这是 TX 模式的代码片段。

    第一个箭头是我看到 MARCSTATE 空闲的位置

    第二部分是我一直停留到看门狗复位或下电上电为止的部分。 我认为 TX FIFO 中始终剩余1个字节、这是因为射频状态空闲。

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

    恐怕我不会按照您的代码流程进行操作。

    例如、第3行上的(FailureCount < 3)、这是什么? 评论? 似乎缺少一个运算符。

    此外、您不应在代码中使用所有这些延迟。 当您刚刚发出 STX 选通脉冲时、为什么要等待45 us 才能检查芯片是否处于空闲状态?

     

    当您想转到 TX 时、您的 TX 代码只需执行如下所示的操作。

    在这里、我假设您不知道当您决定进入 TX 时对讲机处于空闲、睡眠或 RX 状态。

    • 选通信号空闲
    • 等待 MARCSTATE 报告空闲
    • 选通信号 SFRX
    • 选通信号 SFTX
      • 此时、您知道对讲机处于空闲状态、FIFO 为空、FIFO 指针正常
    • 将数据包写入 FIFO。
      • 您已将无线电配置为可变数据包长度模式、因此将长度字节写入第一个字节:例如0x05、0x01、0x02、0x03、0x04、 0x05 (长度字节、+ 5个有效载荷字节)
    • 选通 STX
    • 等待 数据包被发送
      • 建议您将其中一个 GPIO 信号编程为 PKT_SYNC_RxTx、以便您只需等待该信号的下降沿、即表示已发送数据包。

    此时、TX FIFO 应为空(如果您正确写入了数据包长度)

    发送数据包后、您可以返回 eWOR

    BR

    Siri

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

    是的、很抱歉、在第3行、我遗漏了&&运算符。 它说:

    while ((((SPIRegAccessResp & 0x1F)!= 0x13)&&(FailureCount < 3))

    填充 TX FIFO 后、我选通 STX 并等待45us (在数据表中、TX 到 Rx 和 viversa 时间被 m提及 为45us、因此我将给出此延迟)。 然后、我将读取该状态以检查它是否报告 TX。 如果没有、我将检查它是否处于空闲状态或任何 FIFO 错误状态

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

    从 RX 到 TX 可能需要35us、但您如何知道自己处于 RX 中。 您也可以处于睡眠状态、处于侦听过程中、以便 FIFO 已开始填满或处于空闲状态(仅接收到数据包)。

    我强烈建议您在状态变化之间强制器件进入空闲状态、并在进入 TX 之前通过清除 FIFO 来处理 FIFO 指针。 选通 TX 后检查错误不是一种方法。

    Siri

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

    我将根据您的建议修改代码。

    如果 RF 不进入 TX 模式并保持在空闲状态、那么可能的恢复时间和方法是什么?  

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

     自从该器件启动以来、我就一直支持该器件、并且从未遇到过它不会从空闲状态进入 TX 的情况。 如果您处于未处理的错误状态、并强制器件进入空闲状态、而不是使用报告的错误刷新 FIFO、我无法说出发生了什么情况。 因此、我建议您按照我之前的帖子中所述进行冲洗。

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

    我遵循了您提到的所有方法、但我仍然面临这一问题。 您能不能再提出任何建议来帮助我们解决这个问题

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

    由于我无法以任何方式重现此错误、而且这是我以前从未听说过的问题、因此我不确定如何继续。

    要想获得更多信息、您必须能够生成一个软件代码、该代码可以在我们的开发套件(CC1120EM + TRXEB)上重现错误、 或者、您需要将一个逻辑分析仪连接到器件、在发生故障时监控所有 SPI 线路和 GPIO 信号、以便我们能够在器件进入此状态之前准确了解正在发生的情况。

    BR

    Siri