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.

[参考译文] CC2652R:具有 BLE 外设+ Ti15.4协调器的 DMM -在发送置位触发后发送

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1452631/cc2652r-dmm-with-ble-peripheral-ti15-4-coordinator---transmit-on-top-of-transmit-assert-triggered

器件型号:CC2652R

工具与软件:

您好!

我在工作一个 需要同时操作的项目时遇到意外的 TI15.4堆栈错误  蓝牙外设和 Ti15.4协调器 . 当使用蓝牙简单广播(间隔为1)且 TI15.4网络上存在某些流量的情况下较长时间运行该程序时、将触发来自 TI15.4堆栈的置位。 在置位时转储 LR 值我发现错误是在 mac_tx.c 文件内的 macTxFrame 函数中触发的-"Transmit on top of transmit"

MAC_INTERNAL_API void macTxFrame(uint8 txType)
{
  MAC_ASSERT(!macTxActive);            /* transmit on top of transmit */
  MAC_ASSERT(pMacDataTx != NULL);      /* must have data to transmit */

  /* mark transmit as active */
  macTxActive = MAC_TX_ACTIVE_INITIALIZE;

我没有特别的方法可以触发这个断言、它似乎是随机发生的。

我第一次遇到这个问题是在 SDK 版本中:  simplelink_cc13xx_cc26xx_sdk_7_10_01_24
然后、我决定升级到最新的可用 SDK 版本( simplelink_cc13xx_cc26xx_sdk_7_41_00_17 )但问题似乎仍然存在、MCU 随机断言"在发送之上传输"断言。 鉴于这是一个相当低级的 MAC 函数、并且 DMM 在其之上运行、我想假设这样的同步已经存在。

问题:

  1. MAC 层触发此类断言的原因可能是什么?
  2. 怎样做才能防止这种断言? (为尽量减少出现此类错误的可能性、应满足哪些条件)
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Michal、  

    我将进一步调查您的问题、并很快回复您、很抱歉此处出现延迟!

    谢谢!
    Alex F

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

    您好、Michal、

    如果可以触发 MAC_ASSERT (!macTxActive);那么如果 macTxActive 不是 MAC_TX_ACTIVE_NO_ACTIVITY、那么我们应在此处添加调试代码以中断。

    您能否确认这可以通过开箱即用的 DMM 示例复制、以及是否需要连接15.4堆栈终端节点并进行通信(以及需要多少个)?

    谢谢!
    Alex F

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

    您好! 感谢您的快速响应、并对我的 后续行动表示抱歉。 我必须从 QA 团队收集更多信息。

    为您提供更多信息:

    • 只有一个终端设备通过 TI15.4网络与协调器进行通信。 但是、协调器器件(断言的受害者)始终发送特殊的广播消息(每250ms 发送一次)–发送该"广播"消息的机制与任何其他标准消息相同
    • 我还没有尝试将其复制到 DMM 样片中、因为我认为示例代码中的 TI15.4网络操作并不会真正复制我们产品中的应用代码

    这个问题似乎很难重现。 我无法通过任何已知的方式触发这种情况–看起来相当随机。 产生此线程的主要原因是、我希望您能在可能触发此类断言的情况下(例如 DMM 和/或 ti15.4栈可能无法正确调度消息的情况)向我提供一些见解。 那么我可能能够产生一种可靠的方法来重现它。

    我想到的一件事可以帮助我们做到最底层:
    我正在处理的器件使用广播消息来评估当前所选信道是否繁忙(可将其视为持续监控信道可用性的活动 CCA)。 每当无法发送预定义数量的广播消息时、通道更改过程便会启动、因此中央设备会执行 ApiMac_scantype_energyDetect 类型的扫描。

    更改的通道、蓝牙广播和发送 TI15.4消息之间是否会出现不良的交互?