[参考译文] CC1312R：Mac 安全

更新：

我发现信标现在正在发送可变长度数据。 我不确定这是什么。 之前、信标仅发送了一个字节、我对此进行了手动编程：

    ApiMac_mlmeSetReqUint8(ApiMac_attribute_beaconPayloadLength, 1); //set the beacon payload length
    ApiMac_mlmeSetReqArray( ApiMac_attribute_beaconPayload, &current_path_cost); // set the beacon payload

有什么想法为什么改变了？

此外、如何关闭待处理的地址？ 我认为我以前没有看到过这种情况、我不需要在信标中传输该数据。

谢谢。

尊敬的 Andrew：  

请详细说明一下、"设备几小时后恢复"是什么意思？ 这些设备是否开始接收您的数据？  

此致、
Siddanth
 

您好！

感谢您的回复。 我仍在努力研究正在发生的事情、并在我的旅途中发现事情。 如果我为协调器加电、则几个设备将重新加入。 网络无法恢复、但在几个小时内、设备似乎最终会重新加入。

请注意、我的网络不符合您的示例应用。 我有一个基于路由器的网络。

无论如何、我已发现信标有问题。 我的所有信标应为1字节、但我收到的信标为17字节或25字节。 我不确定这是从哪里来的。 直到我更新到 SDK 5.30 (从4.30开始)后、我才会看到此问题。

您能告诉我信标有无变化吗？ 正如您在这里看到的、有效载荷为17个字节、我已将其设置为1：

更新：

我已将有效载荷中的字节数从1更改为10。 现在、我每次得到10个字节。 那么、如果有效载荷设置为1、那么堆栈中会出现问题？

我还尝试了更改为4个字节、这是有效的。 除此之外、我已经尝试在代码周围散射信标有效载荷配置、但它不会产生任何影响。 我的协调器始终从正确的信标有效载荷开始、但在大约17秒后、它会更改为其他一些值。 一段时间后、它会恢复到正确的有效载荷和长度、并持续一段时间。 我的路由器似乎没有遇到这种问题。 那么、这个问题是否仅在 PAN 协调器上出现？ 否则、就我所知、这两个应用程序的设置是相同的。

尊敬的 Andrew：

在更改日志中、我看不到会影响/导致此行为的任何内容。 我将对此进行研究。

但请您在此澄清一下主要问题。 我了解的是：仅 当信标负载设置为1字节时、才会将其设置为预期长度、但 当您将其设置为其他长度(10字节、4字节等)时、会将其设置为正确的长度？  

另外、您在观察中看到17秒后信标有效载荷的变化、这种行为是否与任何信标有效载荷长度设置一致？

此致、
Siddanth  

您好！

我刚刚发现、我发现4字节有效载荷存在同样的问题。 我以前没有捕获它、但它就在那里。 因此、它似乎与1字节有效载荷无关。

我在 cllc.c init()中设置有效载荷和长度，而不是在应用程序中再次设置。

可能是我正在做一些会影响存储器的事情、但我不知道是什么。 17节的情况有所不同。 它很容易达到40秒。 知道信标没有任何变化很有用。 我将看到我是否能够识别信标有效载荷在哪个点发生变化。

谢谢、

Andy

我根本无法处理此问题。 我目前正在测试 Mac 队列大小的 mac_cfg.c 设置、因为这似乎有所不同。 我将它们设置为更高的值、如果我将它们返回到默认大小、则网络信标问题似乎会消失。 但我仍在努力证明这一点。

请随时向我们更新您的调查结果、并告知我们您发现的任何具体的不稳定行为、我们可以对此进行调查。

您好！

是的、我会。 我需要确认它是我的代码还是堆栈。

非常感谢、

Andy

/* ------------------------------------------------------------------------------------------------
 *                                           Constants
 * ------------------------------------------------------------------------------------------------
 */

/* maximum number of data frames in transmit queue */
#ifndef MAC_CFG_TX_DATA_MAX
#define MAC_CFG_TX_DATA_MAX         2
#endif

/* maximum number of frames of all types in transmit queue */
#ifndef MAC_CFG_TX_MAX
#define MAC_CFG_TX_MAX              5
#endif

/* maximum number of frames in receive queue */
#ifndef MAC_CFG_RX_MAX
#define MAC_CFG_RX_MAX              2
#endif

似乎、如果我从默认值中更改这些值、那么我会得到非法信标有效负载。 当这些值大于默认值时、我建议覆盖 Mac 使用的存储器。 我只能认为堆栈中有一些预编译的库、这些库使用默认值卡住、而不管 mac_cfg.c 中的这些配置值是什么

我还尝试将定义放入 collector.opts 中、但它没有产生任何影响、仍然存在很多信标有效载荷问题：

-DMAC_CFG_TX_DATA_MAX=24
-DMAC_CFG_TX_MAX=36
-DMAC_CFG_RX_MAX=24

这是 Wireshark 视图。 我已经设置了一个滤波器来捕获任何数据长度大于1的信标。 虽然我不认为这是一个信标问题、但这就是问题本身的表现方式。

这就是我期望其中一个信标看起来的方式：

这在 SDK 4.30中从来不是问题。

您好、Andrew、感谢您提供监听器日志、我将深入了解这一点、看看 SDK 源代码中是否有任何其他可能导致这种情况的更改。

这很可能不是问题、但您能否确认您也在使用相同的工具链和优化设置。

大家好、(我已继续添加此回复、尝试提供尽可能多的信息、很抱歉、现在已经很长时间了)。

非常感谢。 我需要尽快解决这一问题、因为我的客户现在不得不暂停部署。 如果您认为还有其他值得检查的东西、请告诉我。

我将尝试在下面解释我的项目的更改。 如果您认为其中任何一项可能是错误的原因、请进行评论。

我将继续调查我的代码。 我确实看到，如果我没有通过调用 ApiMac_mcpsDataReq()从收集器发出任何消息，那么收集器的信标似乎是可以的。 至少一段时间、我没有彻底测试过这一点、但我的想法是这是 Mac 问题。

我从 v5.30 SDK 中的收集器示例开始、并将该项目转换为我自己的项目、以便设置保持不变。 我还将 IAR 编译器升级到了9.20版(之前在 v4.3 SDK 上为8.50.9版)。 我已经尝试过默认的完全优化、但没有优化、问题仍然存在。

我的项目不同之处在于我启用了堆跟踪。 我已删除 SysConfig 中的 ti_utils_build_linker.cmd.genlibs、并具有一个本地副本、其中注释掉了一行。 请参见下面的。

下面还手动包括了一些其他文件、例如 mac_util.c、osal_port.c 这是按照我之前关于堆跟踪的讨论中的建议进行的：

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/984795/cc1312r-heap-track

这是 ti_utils_build_linker.cmd.genlibs 中注释掉的行：

//"ti/ti154stack/lib/iar/m4f/maclib_osal_tirtos_cc13x2_26x2.a"

您可以看到、我还包含了 api_mac.h、因为我通过添加额外的关联响应枚举对该文件进行了小幅更改：

/*! Associate Response status types */
typedef enum
{
    /*! Success, join allowed */
    ApiMac_assocStatus_success = 0,
    /*! PAN at capacity */
    ApiMac_assocStatus_panAtCapacity = 1,
    /*! PAN access denied */
    ApiMac_assocStatus_panAccessDenied = 2,
    /*! Parent at capacity */ 
    ApiMac_assocStatus_parentAtCapacity = 3
} ApiMac_assocStatus_t;

我必须做很多工作才能从 SDK 4.3进行此迁移、因为在堆栈中构建 configPkg 与在本地构建时存在问题。 我以前没有遇到过这个问题，也许是与这个问题有关的。 这是我之前的帖子、请阅读我发布的最后一条消息：

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1054278/cc1312r-idle-function-and-possible-sysconfig-issue

从 SDK 4.3 CC13X2迁移到合并的 SDK 5.3 CC13XX 由于各种构建问题而变得很困难。 我怀疑在这一过程中出现了问题。 我从未回答为什么将 configPkg 留在要构建的堆栈中。  

我期待您的答复。

Andy

我已根据 SDK v5.3中的示例创建了一个全新的项目。 我可以确认 configPkg 是在 SDK 中构建的、而不是我的项目的本地配置。 您能确认这是正确的吗？ 我知道它在迁移时给我带来了问题。 您可以在此处看到 configPkg 的构建时间是今天：

我已经了解了 SDK v5.30和 SDK v4.3的 collector_CC1312R1_LAUNCHXL_tirtos_IAR.ipcf 文件、它们在 configPkg 的位置方面有所不同：

V4.3

版本5.3

和新下载的 v5.20：

您好！

对此有什么想法吗？

谢谢、

Andy

尊敬的 Andrew：  

很抱歉、我没有关于这方面的更新。 我很期待这件事。

此致、
Siddanth

好的、谢谢大家。 我再次尝试从迁移开始、尽量减少对设置的更改、因此没有堆跟踪、只手动导入一个文件。 没有什么不同，我仍然有同样的问题。 我确信，configPkg 的更改和/或错误位置与问题密切相关。 我的所有 cllc 和收集器文件都是工程的本地文件、因为它们在示例中进行了大量修改。

Andy

您好！

此外、'software_stack'似乎也不是项目的本地文件。 这可能是我的问题所在。

Andy

您好！

我可以将问题简化为两个部分：

1) 1)我在之前版本的 SDK (返回 SDK v4.3)上测试了信标有效载荷问题、但问题仍然存在。 这意味着、信标有效载荷问题对于 SDK v5.30并不是我所认为的唯一问题。 我可以消除信标有效载荷问题的唯一方法是将 MAC_CFG_TX_DATA_MAX、 MAC_CFG_TX_MAX 和 MAC_CFG_RX_MAX 设置为其默认值。

2) 2) SDK v5.30仍然无法从 IAR 示例工作区正确创建。 configPkg 和 software_stack 保留在堆栈中、而不是本地构建。

我希望这对您有所帮助、

Andy

尊敬的 Andrew：

非常感谢您的耐心、我很感激。 这个问题很难解决。 很抱歉耽误你的时间。
我已就 IAR 项目管理和构建流程的问题咨询了一位同事。  
我是明天休假的、因此他将在周一跟进您。  

此致、

Siddanth

尊敬的 Andrew：

只是对此进行了简短的更新。

正如您正确指出的、在最新版本的 SDK 中处理 TI 15.4示例项目的方式发生了一些重大变化。 configPkg 的位置就是其中的一个示例。 但这并不是我唯一看到的不同之处。

例如、在 SDK 5.20等早期版本中、大多数从 SDK 安装文件复制的示例文件都不会被引用。 通过执行此操作、客户只需转到 SDK 示例文件夹、打开模板文件(例如 collector_CC1312R1_LAUNCHXL_tirtos_IAR.template.eww)并使用 IAR 选择项目工作区所在的目录即可打开项目。

目前、我看到适用于以前 SDK 版本的导入过程不适用于 SDK 5.30、因为各种文件的路径不正确、并且无法构建项目。 构建工程的唯一方法是直接通过 IAR 添加(而不是导入)工程(即、在 IAR 中、转到"Project"选项卡并单击"Add Existing Project")。

现在、该过程在工程编译的意义上有效、但在修改本地 SDK 文件的意义上存在问题、这是不建议执行的操作。 这就是您在使用 configPkg 等时看到的内容

我需要询问 Rnd 这一点、因为不同 SDK 版本之间的更改可能有一个逻辑、或者可能是他们没有考虑的。

关于信标有效载荷的原始问题。 请给我一些时间来看看事情是如何工作的、我会再给你回看。

BR、
安德烈斯  

您好！

感谢您对此做出的响应。

现在我已经将信标有效载荷问题与 v5.30中的项目配置分开了(我最初以为它们是链接的)、我认为我已经通过手动编辑 IAR 项目来解决了项目配置问题。 我的所有文件现在都是项目的本地文件、包括 configPkg、并且 SDK 中没有更改任何文件。  

这使得原始信标有效载荷问题对于解决而言最具时间关键性。 如前所述、我可以确认 至少在 v4.30的所有 SDK 版本中都存在此问题。 我已经做了相当多的测试，我可以停止信标有效载荷问题的唯一方法是不调用 ApiMac_mcpsDataReq()。 每次休眠传感器尝试重新加入时、我的收集器都会调用此函数、而重新加入休眠传感器的次数越多、问题出现得越快。 我将使用大约60个传感器进行测试。

将 Mac 队列大小设置为默认值可以解决信标有效负载问题、但我的网络停止工作(因为它会在重新连接到无法使用的点时减慢速度)、因为它取决于 Mac 队列大小(例如16或16)、因为所有传感器都处于休眠状态。

此致、

Andy  

*update：我还尝试将 Mac 队列大小保持在默认值以上，但限制了我调用  ApiMac_mcpsDataReq()的次数，因此排队的 Mac 消息数保持在默认值2内(仅用于测试，这对我的网络不起作用)。 这似乎也会阻止信标有效载荷误差。 从这种情况下、我推断问题似乎是 Tx Mac 队列、而不是 Rx Mac 队列、因为我仍在接收大量消息。

我最初提出的关于更改这些值的问题：

e2e.ti.com/.../cc1312r-ti-15-4-maximum-number-of-mac-rx-and-tx-buffers

尊敬的 Andrew：

首先、如果您的主题在一段时间内未被注意到、我表示歉意。 由于我不是最初指派给它的人员，所以我没有收到任何答复通知。 但这不应该发生，所以我很抱歉。

其次、我希望准确再现您使用基本传感器/收集器示例作为基准点看到的内容、因此我需要确保我只修改足够的示例以观察问题 (线程现在有点长，我不想忘记任何事情)。 如果我出错或忘记添加内容，请更正我的问题。

主要问题： 即使信标有效载荷长度设置为1字节(或任何其他值)、收集器也会发送有效载荷长度可变的信标。

重现问题所需的修改：

1、信标长度最初在 Cllc_init()中通过调用 ApiMac_mlmeSetReqUint8 (ApiMac_attribute_beaconPayloadLength、1)进行设置

注意：有效载荷的默认值为0字节、在 mac_cfg.c 中定义、最大信标有效载荷长度为52。

已  修改队列中最大数据帧数(MAC_CFG_TX_DATA_MAX、MAC_CFG_TX_MAX 和 MAC_CFG_RX_MAX)的常数。 将这些常量恢复为默认值时、问题消失。

我知道您已经做了额外的修改、使网络路由器成为基础、但我猜这些修改是我在尝试重现您所看到的内容时需要考虑的修改。 我是对的吗？

BR、
安德烈斯

您好！

是的、您回答正确。 由于某种原因、信标有效载荷长度通常似乎会变为 length=17。 它实际上并不是该变量。 它是1 (正确)或17。

我已尝试使用 TI 开发板上的标准示例重现此问题。 我无法做到这一点。 我认为这 是因为问题仅在请求收集器发送大量消息时才会出现。 我有60个定制板、并且我自己的终端设备(传感器)应用正在运行。 当我关闭收集器时会发生信标问题。 所有休眠的儿童设备都进入重新加入状态。 也就是说、它们发出信标请求、在收到有效信标时、它们会发送不安全的重新加入请求。 (这是我添加的功能、其工作方式与 ZigBee 类似)。 收集器接收重新加入请求，将设备添加到表中，并使用  ApiMac_mcpsDataReq()发回重新加入响应。

 由于60个节点同时尝试重新加入，因此正在运行的正是这个 ApiMac_mcpsDataReq()。 与 AppiMac_mcpsDataReq()相同，如果我删除，除了将  (MAC_CFG_TX_DATA_MAX, MAC_CFG_TX_MAX 和 MAC_CFG_RX_MAX)保留为默认值外，它是唯一纠正信标有效负载问题的方法。 有趣的是，当 ApiMac_mcpsDataReq()被注释掉时，我没有看到错误，即使接收队列仍然正常工作，且大小不是默认值。

我想更加确信问题不是我的代码。 虽然我不确定这一点、但我花了一些时间尝试注释掉尽可能多的代码。  我在重新加入时删除了闪存写入以及许多其他内容。 如前所述， 除了重新加入时删除 ApiMac_mcpsDataReq()之外，没有什么不同。  

我的下一个步骤是使用标准传感器示例重新编程我的60个传感器、但我不确定如何在不大量修改示例代码的情况下复制重新加入流程。 我已经详细了解了标准示例代码、因此我不确定这是多么容易、但可能是需要的。

总之，我认为问题是 由于在短时间内多次调用 ApiMac_mcpsDataReq()，我怀疑 MAC Tx 队列大小是在库文件中硬编码的，默认队列大小(MAC_CFG_TX_DATA_MAX)， 但在运行时、允许将更改后 的 MAC_CFG_TX_DATA_MAX 值添加到队列中。

感谢您的帮助、

Andy

尊敬的 Andrew：

明白。

如果器件数量是此问题的罪魁祸首，那会很奇怪，因为在这种情况下，我希望调用 ApiMac_mcpsDataReq()将返回错误状态(如 ApiMac_status_noResources 或其他内容)。 您是否可以运行与您运行过的测试相同的测试、但使用的器件较少？ 这样、我们就可以确保设备数量在问题中起着重要作用。

我将检查源代码以查看 ApiMac_mcpsDataReq()是否可以与信标交互并影响其有效载荷长度。  

我还将检查源代码以查看是否发生了这种情况，尽管这种情况会相当奇怪，因为这样问题就会显现出来，而无需多次调用 ApiMac_mcpsDataReq()。

如果您对我如何重现问题有任何其他想法、请告诉我、我很乐意进行测试。

BR、
安德烈斯

您好！

谢谢。 我将使用较少的器件进行测试、并尝试获取错误发生的阈值的数字。  

我还将查看我是否可以使用标准示例重现问题。

同时、如果您能够确认来源正确、那将会非常好。  

此致、

Andy

尊敬的 Andy：

请告诉我您是否可以重现问题。

我一直在检查源代码、但我没有看到任何可以解释您所看到的内容的内容。 尽管我仍然需要检查一些东西。

ApiMac_mcpsDataReq()基本上只是将应用程序数据发送到 MAC 以便在 MAC 数据帧中传输。 但我看不到它如何影响信标等设备的有效载荷长度。

发送信标时、我仍然需要了解如何处理这些问题、因此我会随时向您发送信标。

BR、
安德烈斯

尊敬的 Andy：

您是否有任何更新？

我检查了源代码以了解如何构建包含信标帧的缓冲区、但没有找到任何可以解释您所看到的内容的内容。 它基本上使用基线长度和 MAC PIB 中定义的信标有效载荷长度来计算信标帧的长度(即使用 ApiMac_attribute_beaconPayloadLength 设置的长度)。

我还尝试使用这些示例来查看我是否可以重现问题、但到目前为止、我没有取得太大的成功、因此如果您有任何想法、我很乐意为您提供帮助。

BR、
安德烈斯

安德烈斯、您好！

非常感谢您的帮助、我非常感谢您的帮助。 我目前正在对定制硬件上的示例传感器应用进行编程。 希望我能在星期一结束前报告一些内容。

我最想的是、它与信标有效载荷的构建方式无关、但我看到的是内存泄漏导致数据损坏。 这种损坏的数据恰好显示为不正确的信标有效载荷、但很容易受到影响的任何其他进程、更糟糕的是、我无法看到这种进程。  

此致、

Andy

安德烈斯、您好！

我目前正在配置示例软件以在硬件上运行、以尝试重现问题。 一件突出的事情是使用"Orphan 通知"。 我完全不使用它。 而与 ZigBee 更像、我发出"信标请求"、然后发出"重新加入请求"。 因此、为了让我的设备重新加入网络、潜在的父设备必须发出"信标"。  

所有 TI 示例是否都基于孤立通知？ 如果是、父级(收集器)将不会像我的网络那样发送大量信标。

我想知道您的想法。

此致、

Andy

安德烈斯、您好！

感谢您的回复。 很清楚、我的应用程序不会以任何方式使用孤立扫描或协调器重新调整。 我已大致重写了链接控制器，以便通过  ApiMac_mcpsDataReq()重新加入。 我现在将更改示例以模拟重新加入而不使用孤立功能、以查看是否可以重现此问题。 如果可以、我将向您发送项目代码。

此致、

Andy

安德烈斯、您好！

我现在已经在使用 TI 示例时看到了信标有效载荷错误。

由于所有 TI 示例代码都使用孤立通知、而不是执行活动扫描、因此当终端设备执行重新加入时、您永远不会要求父设备发送信标。 如果您为低于1GHz 的 Zigbee 使用相同的堆栈、那么我希望这对您来说是个问题、因为 ZigBee 也不使用孤立通知。 而是像我所做的那样使用信标。

如何将我所做更改的文件发送给您进行分析？

此致、

Andy

安德烈斯、您好！

感谢您的更新。 有人告诉我 ZigBee 解决方案、该解决方案必须是不正确的信息。 感谢您将其清除。

我认为这是堆栈的问题、或者可能是我使用它的方式的问题、这不是 TI 开发人员想要的。 但是、我认为如果要遵守802.15.4标准、它应该起作用。

我可以使用朋友请求向您发送文件。 现在、下面是我所做更改的概述：

1) 1)我通过更改 handleMaxDataFail ()在 jdlc.c 中禁用了孤立扫描，而是使用我自己的“网络加入”状态调用活动扫描。 此扫描执行信标请求、收集器如果处于联机状态、将使用信标响应该请求。

    else
    {
        /* start orphan scan */
        //switchState(Jdllc_deviceStates_scanOrphan);
        //updateState(Jdllc_states_orphan);
      
        switchState(Jdllc_deviceStates_scanActive);
        updateState(Jdllc_states_network_joining);
      
    }

2) 2)当终端设备扫描完成时，它使用  ApiMac_mcpsDataReq()向收集器发送消息。  

3) 3)收集器使用终端设备接收的 ApiMac_mcpsDataReq()再次响应此消息，然后正常运行。 这些消息实际上并不包含任何有用的内容、因为终端设备不会删除其任何网络数据、它不需要父设备的任何数据即可继续工作。 我已将消息事务放入中、以模拟我自己的网络如何重新加入父级网络。

4)数据和轮询每60秒发生一次：

5) 5) Mac 队列长度大于默认值：

/* maximum number of data frames in transmit queue */
#ifndef MAC_CFG_TX_DATA_MAX
#define MAC_CFG_TX_DATA_MAX         16
#endif

/* maximum number of frames of all types in transmit queue */
#ifndef MAC_CFG_TX_MAX
#define MAC_CFG_TX_MAX              24
#endif

/* maximum number of frames in receive queue */
#ifndef MAC_CFG_RX_MAX
#define MAC_CFG_RX_MAX              16
#endif

6) 6)我增加了收集器中的 Mac 持久性时间：

/* MAC Indirect Persistent Timeout */
//#define INDIRECT_PERSISTENT_TIME (MAX((5 * 1000 * CONFIG_POLLING_INTERVAL / 2), MIN_PERSISTENCE_TIME_USEC)/ \
//                                  (BASE_SUPER_FRAME_DURATION * \
//                                    SYMBOL_DURATION_LRM))

#define INDIRECT_PERSISTENT_TIME ((1000 * CONFIG_POLLING_INTERVAL)/ \
                                  (BASE_SUPER_FRAME_DURATION * \
                                    SYMBOL_DURATION_LRM))
                                    
/* adds 30s onto INDIRECT_PERSISTENT_TIME for margin                    */
/* calculated as:                                                       */
/* SYMBOL_DURATION_LRM * 960 (BASE_SUPER_FRAME_DURATION) = 48ms         */
/* 30s / 48ms => 625                                                    */
#define INDIRECT_PERSISTENT_TIME_MARGIN 625
                                    
                                    

ApiMac_mlmeSetReqUint16(ApiMac_attribute_transactionPersistenceTime,
                            INDIRECT_PERSISTENT_TIME + INDIRECT_PERSISTENT_TIME_MARGIN);

7)并在 collector.c init()中向信标添加有效载荷：

    uint8_t value = 5;
    ApiMac_mlmeSetReqUint8(ApiMac_attribute_beaconPayloadLength, 1); //set the beacon payload length
    ApiMac_mlmeSetReqArray( ApiMac_attribute_beaconPayload, &value); // set the beacon payload

当我关闭收集器并运行超过25个终端设备时、我会得到信标有效载荷问题。 两分钟后、所有终端设备进入信标请求模式。 集电极再次上电后、开始发送信标。 然后、它接收来自重新加入终端设备的消息、并对其做出响应。 重要的是、由于终端设备处于休眠状态、收集器必须保持任何出站消息、直到终端设备发出数据请求。 这会使 Mac 队列在处理大量消息时轻松填满。  当调用 ApiMac_mcpsDataReq()但 Mac 队列已满时，Mac 应返回失败。 我认为这里出现了问题、Mac 消息正在扩散到其他存储器中。 该存储器恰好会影响信标有效载荷。  

我将向您发送一个朋友请求并将文件发送给您。

非常感谢您的帮助、

Andy

尊敬的 Andy：

我已接受朋友的请求。 发送项目文件后、我将查看它们。

此方案实际上包含在堆栈中、因为 MAC 队列已满(我已经对此进行了测试)时、该情况会有特定的状态。 不过、值得一看、看看是否有什么东西可以解释您所描述的内容。

BR、
安德烈斯

您好！

我已通过朋友消息发送了指向这些文件的链接。

我同意 Mac 队列已满可能按预期工作、您已经证明了这一点。 但是、我认为问题是、当我在 mac_cfg.c 中选择较大的值时、Mac 队列的最大大小不会全局更改 相反、Mac 允许按照我修改的 mac_cfg.c 值对更多消息进行排队、但分配的内存保持默认为"2"。

KR、

Andy