[参考译文] CC2652R：如果存在16个或更多间接待处理消息、则信标响应将消失

尊敬的 Martin：

很遗憾您的问题仍未得到解决。  您是否尝试过在中增加 MAC_SRCMATCH 条目数 \source\ti\ti\ti154stack\low_level\cc13xx\mac_autopend.h？  同时、我将提醒 TI 15.4-Stack 软件开发人员这种行为、并收集他们的建议。

此致、
Ryan

您好、Ryan、

感谢您的答复。 我现已尝试增加 MAC_SRCMATCH 定义：

MAC_SRCMATCH_SHORT_ENTRY_SIZE       4 -> 24
MAC_SRCMATCH_EXT_ENTRY_SIZE         8 -> 38
MAC_SRCMATCH_SHORT_MAX_NUM_ENTRIES  5 -> 25
MAC_SRCMATCH_EXT_MAX_NUM_ENTRIES    5 -> 25

不幸的是、如果不成功、问题仍然与位于15个单元的断点相同。

期待开发人员的建议。 ：)

此致、
Martin

软件团队反馈：

macCfg_t macCfg =
｛
MAC_CFG_TX_DATA_MAX、
MAC_CFG_TX_MAX、
MAC_CFG_RX_MAX、
MAC_CFG_DATA_IND_OFFSET
MAX_DEVICE_TABLE_ENTRIES、
MAX_KEY_DEVICE_TABLE_ENTRIES、
max_key_table_entries、
max_node_key_entries、
Max_key_ID_lookup_entries、
MAC_CFG_APP_PUNLDING_QUEUE、
MAC_MAX_FRAME_SIZE
}；
MAC_CFG_TX_MAX 控制 TX 队列中的数据包数量(直接数据包+定向数据包)。
根据客户配置、MAC_CFG_TX_MAX 15 =>这意味着 TX 数据包的最大数量是15。
如果客户希望增加队列中的间接数据包、则可以将 MAC_CFG_TX_MAX 增大到较大的值。 这将需要更多 RAM。

您似乎已经尝试过类似的尝试、因此我将继续推送它们以获取更多信息。

此致、
Ryan

谢谢 Ryan。

是的、我必须将 MAC_CFG_TX_MAX 15增加到255、但没有成功。

期待他们的回应。

此致、

Martin

"我认为用户不能将 MAC_CFG_TX_MAX 设置为255。  您能让他们检查 ApiMac_mcpsDataReq API 的返回状态吗？ 他们很可能会看到无资源代码(0x1A)或事务溢出(0xF1)。"

我建议将 MAC_CFG_TX_MAX 更改为一个更合理的值、例如63或127。

此致、
Ryan

感谢您的答复 Ryan、

我已尝试减少设置：

MAC_CFG_TX_DATA_MAX=63
MAC_CFG_TX_MAX=127
MAC_CFG_RX_MAX=128

也降至

MAC_CFG_TX_DATA_MAX=16
MAC_CFG_TX_MAX=32
MAC_CFG_RX_MAX=4

问题仍然存在、限制仍然为15。

ApiMac_mcpsDataReq ()每次我发布到间接队列时都会返回0x00 (ApiMac_STATUS_SUCCESS ),即使对于第16个数据包也是如此。

还有其他建议吗？ 鉴于增加 MAC_CFG 设置需要更大的 RAM、我是否需要增加存储器分配来容纳更大的队列？

此致、

Martin

尊敬的 Martin：

感谢您的更新。

我是 Ryan 的同事、将在他不在办公室时维护他的线程。

我现在正在与开发团队核实、并将在我收到回复后(或在4个工作日内办理登机手续)向您更新。

谢谢！
Toby

感谢 Toby、

期待响应。

此致、

Martin

尊敬的 Toby：

我是 Martin 的同事、当他不在办公室时、我将接替他。

等待您的回复。

此致、

Christian

您好！

我们收到了有关该问题的一些新意见。 我们将打开另一个问题、但 Martin 意识到他们可能是相互关联的。

首先是关于这个线程前提的修正。 信标响应确实会被发送、但它已损坏、这使我们认为它已与我们看到的另一个错误相连。

有12个与协调器关联的器件、以及一个进入每个器件队列的间接待处理消息。  
在某些情况下、由于当前未知以及另一个器件正在发送信标请求、因此信标响应被损坏。  

正确的信标响应：

信标响应损坏：

信标有效载荷是在应用程序中创建的：

typedef struct Beacon_
{
    uint8_t pairing_and_version;
    uint32_t channel_mask;
    uint8_t security_mode;
} Beacon;
 
Beacon beacon =
{
    .pairing_and_version = 0,
    .channel_mask = 0,
    .security_mode = 0
};
 
static void updateBeacon( bool is_pairing_enabled )
{
    uint8_t pairing_enabled = 0;
    if ( is_pairing_enabled )
    {
        pairing_enabled = 0x80;
    }
    RadioParParameterUnion value;
    RadioParSecurityMode securityMode;
    RadioParRssiThreshold rssiThreshold;
    paramGet( VERSION, &value );
    beacon.pairing_and_version = pairing_enabled | ( 0x7fu & value.version );
    paramGet( CHANNELMASK, &value );
    beacon.channel_mask = hton32( value.chMask );
    paramGet( SECURITY_MODE, &value );
    securityMode = value.securityMode;
    paramGet( RSSI_THRESHOLD, (RadioParParameterUnion *)&rssiThreshold );
    if ( securityMode > SECMODE_RESERVED2 )
    {
        securityMode = SECMODE_UNDEFINED1;
    }
    beacon.security_mode = ( securityMode << 4 ) & 0xf0;
    print(Diags_INFO,
            "beacon: pairing: %d, version: %d, secmode: 0x%x, chmask 0x%x(nb) rssiThreshold %d",
            is_pairing_enabled,
            0x7fu & beacon.pairing_and_version,
            beacon.security_mode,
            beacon.channel_mask,
            rssiThreshold);
    ApiMac_mlmeSetReqUint8( ApiMac_attribute_beaconPayloadLength, sizeof( beacon ) );
    ApiMac_mlmeSetReqArray( ApiMac_attribute_beaconPayload, (uint8_t*) &beacon );
    ApiMac_mlmeSetReqBool( ApiMac_attribute_associatePermit, true );
    ApiMac_mlmeSetReqUint8( ApiMac_attribute_rssiThreshold, (uint8_t)rssiThreshold);
}

不知何故、所有相关器件的短地址(0x1000 - 0x100B)最终在应用的有效载荷之前出现在信标响应中。  
造成这种情况的原因是什么、更重要的是、如何将短地址保留在信标响应有效载荷之外？

请将此更新转发给团队、因为这可能会限制问题的范围。

此致、

Christian

尊敬的 Christian 和 Martin：

我还在等待 rnd 团队的回应。

Ryan 或我将在4个工作日内再次更新。

谢谢！
Toby

我收到了以下反馈：

请尝试：

MAC_CFG_TX_DATA_MAX=24

MAC_CFG_TX_MAX=32

仍然是相同的行为可悲。

感谢更新的 Christian。  您的应用是否在修改信标有效载荷？  这  对于 TI 15.4-Stack 而言不是典型情况。  您是否评估了使用默认收集器示例时的行为差异？

此致、
Ryan

您好、Christian：

损坏的信标响应很有意思、因为"待处理地址规范"字段为0x0C、 因此信标尝试包含12个待处理地址、但允许的最大值应为7。  0x0C = 1100b、bit 0至 bit 2是待处理的短地址数、在损坏的信标响应映像中为100b、其中 bit 3保留、不应为1。

感谢您的报告、R&D 团队将对此进一步调查。

此致、
Ryan

我们有一个自定义信标有效载荷、我们通过您的 API (分别为6字节和8字节)进行了设置、如下所示。 否则、我们不对有效负载执行任何其他操作、所以我真的看不到它为什么会导致此问题的原因。

您只能在使用自定义信标有效载荷时看到错误行为、或者也可以使用默认 TI 代码将其复制吗？  这将帮助研发团队确定在哪里找到问题、或者是否需要进一步调查自定义代码。

此致、
Ryan

我目前正在研究如何测试这一点。

同时、我也做出了更多的发现、尽管我不确定自己使用的设置、因此我会再多挖掘一点。

但我看到了以下内容：

• 具有不同挂起短地址的非损坏信标(2和7)
• 损坏 具有不同挂起短地址的信标
• 具有一个挂起长地址(是四个成对短地址的组合)的信标损坏
• 没有挂起地址的信标损坏

当"待定地址规范"字段太大或与地址列表的大小无关时、数据被损坏、这是有道理的。

我将进一步测试一下、看看我是否能够在没有定制有效载荷的情况下设法重现该情况、但运行默认 TI 代码对我来说可能有点棘手。

此致、

Christian

在使用自定义有效载荷(也不使用)进行进一步测试后、我想知道是否 在内部正确处理了"待处理地址规范"字段、我想  macBuildBeaconNotifyInd()吗？

在我的测试中、"待处理地址规范"字段似乎始终等于待处理消息的数量、即使该字段大于0x07、也会添加到信标长度中。 您可以在下面的两个捕获中看到这一点、5个待处理 vs 13个待处理将提供16个字节。

感谢您使用监听器日志屏幕截图补充您的观察结果。  如果您复制了未使用自定义有效载荷的这些结果、则这是 TI 15.4-Stack R&D 报告并正在调查的行为

此致、
Ryan

您好、Ryan、是否有任何链接或请求允许我们跟踪该问题？ 我们必须知道何时修复此错误。

Andrzej

您好、Ryan、有任何更新吗？

尊敬的 Andrzej：

感谢您的登记。  15.4堆栈研发团队上周发现了一个问题并提出了解决方案。  但是、它涉及对源代码的更改、而发行版 SDK 中无法访问这些更改、这意味着该解决方案将 仅在下一个 SDK 更新(可能是2024年第3季度的 v8.30)中可用。

此致、
Ryan

我懂了
谢谢 Ryan