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**** 2540720 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/604700/cc1200-radio-stops-changing-states

部件号:CC1200

我正在CC1200的应用中处理大量连续数据传输。  一般来说,对讲机工作正常,但我遇到了一个问题,当我们的流量负载很重时,我无法解决。  对讲机运行良好几分钟,然后在我尝试传输数据包后停止更改状态。  我们发送到FIFO的数据包数据显示有效(PLEN字段正确且数据有效负载正常),并且我看不到任何Tx或Rx FIFO错误。

在此应用程序中,我们使用加密,但我已删除传输端的加密部分,问题仍然间歇性发生。  如果我删除了传输并仅接收,我到目前为止还没有看到芯片锁定。  出现问题时,芯片似乎卡在TX或空闲状态。  进一步的命令频闪改变到其他状态不起作用(我检查以确认状态变化,芯片状态永远不会离开它所停留的状态)。  例如,当需要发送下一次传输时,我首先确保对讲机处于空闲状态,但它从未返回到空闲状态,或者当我发出STX频闪灯时,芯片从未离开空闲状态。  CC1200 TXOFF寄存器参数设置为在Tx完成时自动返回Rx状态。

通常,我正在检查CC1200 GPIO线路中的一条以完成传输。  当发生卡在Tx状态的问题时,GPIO线路似乎永远不会高电平。  我也尝试通过SPI检查芯片状态,但问题发生时,它指示TX状态。

我尝试每500毫秒将对讲机置于关闭状态,然后返回到空闲状态(这就在其中一个传输之前),这不能防止问题发生。  我还尝试使用其他自动校准设置以及关闭自动校准和手动校准,但这也不能防止出现问题。

此时,我很不知道还能检查或尝试什么,除了CC1200的硬件重置,这需要花费太多时间才能在我们的应用程序中重新配置。  什么会导致CC1200在传输时像这样锁定?

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

    你好,David

    没有任何已知问题会导致对讲机在TX中挂起。 我能想到的唯一能阻止芯片进入TX的事情是,如果对讲机在发送TX闪灯时处于错误状态(TX_FIFO或RX_FIFO错误)。

    如果对讲机进入TX,唯一可以阻止其退出的是您使用空FIFO敲击STX,而不填充它。 然后对讲机将永久处于TX中,发送前导码。

    要进一步调试,我建议您在每个TX选通之前输入读取MARCSTATE和NUM_TXBYTES的代码。 然后,您应监控所有SPI线路+使用逻辑分析器的GPIO线路,以便能够了解芯片/代码卡住之前发生的情况。

    巴西

    Siri

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

    感谢您的回复,Siri。

    下次我重现问题时,我将尝试捕获此信息。

    在调试过程中,我再次查看了加密过程。  在传输过程中有一个不必要的SFRX命令闪灯,我之前已经用警告标记了它。  在我删除此项后,故障率已大大降低。  我认为我们只是刷新Rx FIFO,以确保我们没有来自中断接收的部分数据。

    我昨天在户外测试运行大约一个小时期间锁定了1次,所以我尝试在调试过程中再次重现该问题。

    仅为了解更多信息,我确定了2种故障模式。  (1) CC1200在发出STX后保持TX模式,即使显式调用侧向闪灯,也不会返回RX或空闲状态;(2) CC1200在发出SRX或STX后立即保持空闲模式。  根据以上发现,我认为它与FIFO刷新有关,可能是在传输或接收期间,而不是实际从状态读取FIFO错误。

    另外,关于NUM_TXBYTES的读取,我之前在加密过程的末尾添加了一个检查项。  我发现,通常(可能是%30次),它会在加密完成后立即报告'0'。  如果我循环/重复写入FIFO和加密,我发现在NUM_TXBYTES值为非零之前,最多可能需要3次尝试。  我们的旧代码没有检查这一点,我发现传输非常可靠(即使NUM_TXBYTES报告0,数据也能正确传输)。  这与NUM_RXBYTES的错误行为有时相结合,使我在软件中不再依赖它们。  我们在传输时必须遵守一定的时间精确度,我不确定重复复制和加密FIFO数据是否会使我们在时间范围内。

    例如,NUM_RXBYTES似乎并不总是至少根据您所在的状态报告FIFO中的正确字节数,而FIFO _NUM_RXBYTES似乎总是可靠地工作,但最大限制为15,因此我必须循环和读取15个字节的块。  同样,这种经历可能都与不必要的FIFO冲刷有关,但这是我在过去一年左右的观察结果。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我今天有一个这样的锁。 系统发出侧向并锁定,等待CC1200报告空闲状态,同时准备将下一个数据包数据发送到CC1200 FIFO。 状态在While循环中检查,并且始终报告Tx状态。

    我注意到FIFO错误检查一次只能处理一个错误。 如果在清除RXFIFO后立即出现TXFIFO,则TXFIFO不会被清除。 我会调整。

    在最后一次尝试STX时:
    MARCSTATE = 0x41
    num_TXBYTES = 0x00

    请注意,在我们发出侧翻闪灯之前,会检查FIFO错误。
    抱歉,我没有SPI跟踪。 发生问题时,我没有触发硬件设置。 仍在处理。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    另一个我偶尔看到的问题是用于确认AES命令完成的GPIO0不会降低。 因此,我们偶尔会陷入GPIO0高的困境,等待AES命令完成。

    有趣的是,在3个板中,我只在其中一个板上遇到了很多麻烦。 也许是时候换用硬件了。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好Siri,

    我发现CC1200锁定的问题几乎只有在多个对讲机(都使用CC1200)大约同时尝试正确传输时才会发生。  它似乎也总是发生在首先开始其传输周期的那个上。  这种情况在低占空比下可能会在发生任何锁定之前反复发生,因此它必须是对讲机状态机之间的竞争状态。

    在此系统中,对讲机不应同时传输,但在这种情况下,由于系统错误,我有3个对讲机同时进入Tx模式。  我已经重新处理了一些事情以避免这种情况,并且正在重新测试。

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

    你好,David

     

    很遗憾,我没有为您提供解决方案,但我对您最近的帖子有一些评论。 请参阅以下内容:

     

    “在调试过程中,我再次查看了加密过程。  在传输过程中有一个不必要的SFRX命令闪灯,我之前已经用警告标记了它。  在我删除此项后,故障率已大大降低。  我认为我们只是刷新Rx FIFO,以确保我们没有来自中断接收的部分数据。”

    请注意,除非您处于空闲状态或FIFO错误状态,否则切勿刷新RX或TX FIFO。 在任何其它状态下刷新FIFO将会使FIFO指针混乱。

    仅为了解更多信息,我确定了2种故障模式。  (1) CC1200在发出STX后保持TX模式,即使显式调用侧向闪灯,也不会返回RX或空闲状态;(2) CC1200在发出SRX或STX后立即保持空闲模式。  根据以上发现,我认为它与FIFO刷新有关,可能是在传输或接收期间,而不是实际从状态读取FIFO错误。

    如前所述,唯一可以使芯片留在TX中的已知功能是发送一个具有空FIFO的STX闪灯命令。

    摆脱FIFO错误状态的唯一有效方法是通过flush命令。 从错误状态发送空闲闪灯将使MARCSTATE报告空闲,但FIFO指针将不会重置,这可能会在尝试再次输入TX或RX时造成混乱。



    我从未见过任何状态字节有任何问题。 我没有使用CC1200上的AES的经验,由于我们不了解导致您出现问题的原因,我强烈建议您尝试在没有AES的情况下启动并运行您的应用程序。 如果此操作正常,则应添加AES。


    巴西

    Siri