[参考译文] CC2530：重新加入故障捕获分析

您好，Peter，

请提供网络密钥吗？  否则，嗅探器日志中的数据包将被加密，因此很难解密。  哪一个短地址是有问题的Zed节点？  我建议您查看 已知问题并修复E2E帖子 ，因为有些帧计数器问题可能会影响设备的重新加入行为。  否则，请在IDE中进一步调试您的设备，以收集有关问题期间MCU行为的更多线索。

此致，
Ryan

谢谢Ryan，

抱歉。 以下是我在 Wireshark中配置的密钥：

5A：69：67：42：65：65：41：6C：69：61：6E：63：65：30：39

6F：8B：C6：95：74：85：3F：39：B4：9B：DF：AC：CF：7A：9D：7E

关于已知问题...是的，我看到了列表。 这就是为什么我很好奇从拍摄中能否看到它。

调试过程非常复杂，因为它是在几天后随机发生的。

但我在显示屏上打印了一些诊断信息，设备位于 BDB_Commissioning_parent_lost中，状态为 BDB_Commissioning_no_network

设备状态为 dev_nwk_orphan，有时似乎更改为 dev_nwk_disc。

任何暗示都将受到高度赞赏。

谢谢你。

是的。有问题的设备是 0x0B7F。 一件奇怪的事情是，它每小时手动报告一次  

zclStatusPanel_DstAddr.addrMode =(afAddrMode_t) Addr16Bit;
zclStatusPanel_DstAddr.addr.shortAddr =0；
zclStatusPanel_DstAddr.Endpoint=1；

zcl_SendReportCmd (....)

不知怎么的..即使是Zed也不在网络上，也不能接收写命令..协调员能够接收此类报告..

设备可能处于孤立状态，但NV内存中的Nwk材料完好无损，允许将报告发送到硬编码地址。

我真的很困惑...

谢谢，第一个密钥是全局TCLK，第二个密钥是我需要的Nwk密钥。

ZC连续发回状态为成功的重新加入响应，因此ZDEp应收到 ZDO_JoinConfirmCB。  您是否能够在问题发生之前成功重新加入？  然后还可以调试 成功重新加入的bdb_rejoinNwk，并与失败的实例进行比较。

您是如何将应用程序从Z-Stack HA 1.2 迁移到3.0 的？  在使用默认TI示例时，您是否遇到了同样的问题？  您是否能够读取/监控您的NV条目，它们是否在工作状态和中断状态之间发生了变化？

此致，
Ryan

您好，Ryan：

感谢您的提示。 我会尝试逐一解决这些问题。 我最近没有这样做，但在过去我注意到，在成功的重新加入中，协调员以更短的间隔回复了重新加入。 通常，当它失败时，由于某种原因，响应需要一些时间。 我在想，理论上是否有机会Zed在超时后关闭了接收器，但没有抓住它？ 或者Zed是否发送了以下MAC ACK作为响应？ 我可以看到它们具有相同的序列号，因此可能不是这样。 因此，协调员似乎认为设备已加入，但Zed拒绝接受重新加入响应。

我需要尝试强制重新连接以查看健康的过程，这在我的网络中并不容易。

非常感谢您的分析和提示...  

如果我有任何发现，我会回来。

嗯...非常好的建议Ryan 我对问题朝着那个方向发展有一种不好的感觉。 我将进一步调查... 我非常感谢你的支持。  

当我分析更长的嗅探器捕获时。 我可以看到Zed在重新加入请求后通常在2500毫秒左右发送数据请求...这是一种模式... 这很奇怪，因为我在f8wconfig中的设置是：

-DRESPONSE_Poll_RATE=100

-DREJOIN_pol_RATE=440

-DPOLL_RATE=1万

所以...似乎没有一个是与已用值接近的...

在数据请求后，协调员在几毫秒内迅速回复...

有了这种行为， Nwk_REUST_TIMEOUT_EVT的理论 就越来越可能了。

现在我需要从哪里找到一个非常奇怪的民意调查率。

您是否在 已知问题中添加了这些修补程序并修复了E2E帖子 ？

您好，YiKai，

还没有…… 我想先了解一下发生了什么，然后才可能在修复过程中引入额外的意外问题。 但如果我的分析没有发现任何有意义的东西，我会尝试实施修复并采用"试验和错误"方法。

谢谢你。

值得一提的是，即使在设备重新启动后也可以观察到这种情况。因此，它不应该与某些内存泄漏，资源耗尽或类似情况相关。

大家好，调试的第一个结果是我的。 Zed在调试器上运行几个小时后，似乎可以在协调器和路由器之间移动并重新加入网络，而不会出现任何问题。 重新加入轮询速率确实为440ms，也可以在嗅探器中观察到，一切正常。 所以我想知道在使用了几天之后，它怎么会出错。 我将让Zed在调试器上运行，看看是否可以重现该问题。 过去，我总是能在大约3天之后复制它。 现在我想知道...是否可能有东西覆盖内存？ 重写 zgRejoinPollate或NVRAM的某些溢出会受到某种程度的破坏？ 到目前为止，这是一个相当神秘的问题。

启用 OSALMEM_MESTICS可能很有价值，以确保不会出现导致问题的内存泄漏，即使在重置后可以立即观察到该行为。  您也可以尝试监控 ZCD_NV_REUST_POLICT_RATE并在问题发生之前/之后读取NV内存。  您是否能够使用默认的TI示例重现此问题？Zed的电源(电池)和电压级别是多少？   根据描述，可能涉及NV内存损坏。  我怀疑电池的低电压会导致NV内存写入或应用程序执行闪存写入出现问题。

此致，
Ryan

谢谢Ryan，我将继续调查你的所有提示。 一旦我有任何决议，我将立即在这里发表。 如果成功，它将是一个非常好的开放源代码项目。 它显示室内和室外传感器的温度，并由Write cmd在10分钟内更新一次，还显示有关打开的窗口，烟雾报警，洪水等的即时警告图标。 2.9 eink显示屏上的所有内容。 像状态显示，当你离开家的时候，你想检查一下。所有这些都在尼斯SLA打印的定制封装中。如果在这样的问题上失败，那不是一个耻辱...：(

很奇怪。 我让Zed运行，但记录输出稍有变化。 我实施了低电池回调，并在 显示器上打印zgRejoinPollRate的孤立状态。 真是个惊喜。大约3天后，设备仍处于错误状态，无法重新加入。 2500毫秒后再次发送重新加入请求后的数据请求。 但是... 无电池电量不足警告，显示屏将显示440ms，作为 zgRejoinPollate...的值。 我不明白：(这可能是NVRAM值的问题，因为重新启动后问题仍然存在，只有刷新才有帮助。)

BTW..延迟与TOUCHLINK_initiator_REUST_TIMEOUT相同是否是巧合？

我同意这似乎是NV闪存的问题。  是否可以打印其他NV值以确定是否存在预期值之外的任何不一致？  您是否尝试过由YK或我自己推荐的任何已知问题修复？  应用程序是否执行了任何闪存写入操作？  我预计 TOUCHLINK_initiator_REUST_TIMEOUT是巧合，因为如果 未定义BDB_TL_initiator，则不应编译此代码。

此致，
Ryan

感谢Ryan提供的其他建议。 我的应用程序不能直接读取或写入NV。 我基本上只删除了普通应用程序的版本，只添加了电子墨水的处理。 我检查了推荐的修复程序，但没有找到任何修复程序，这似乎可以解决我遇到的问题。 我肯定会在以后实施它们，但我不想引入其他错误或奇怪的行为。 目前我正在尝试在问题发生之前和之后比较NV值...所以希望我会发现一些差异... 我真的很好奇... 感谢您的支持。

您还可以使用OSALMEM_MESTICS跟踪堆，以获得更多调试帮助(很遗憾，如果重置无法解决问题，很可能不是当前的问题)。  由于该问题似乎与 NV写入有关，因此可能会出于 调试目的大幅降低MAX_APS_FRAMECOUNTER_changes的值，从而导致问题的出现速度比当前快得多(即几小时而不是几天)。

此致，
Ryan

您好，Ryan，感谢 您为MAX_APS_FRAMECOUNTER_Changes提供的提示。 我会来看一下的 但刚才我经历了一个非常新的效果。 我实施了一些额外的打印输出，以显示NV值。 但令我震惊的是，现在这个问题在我插入电池后几分钟就出现了。 现在，RejoinRequest和DataRequest之间的延迟大约为2800毫秒。 过去通常是2500毫秒。 到目前为止，显示屏上打印的NV相关值似乎没有改变。 那么... 这没有什么意义 我会说内存，因为我扩展了打印，需要导入其他字体...但重新启动不起作用... 无论如何 ，我会继续调查... 也许我会尝试至少用"XDATA STack"或MAXMEMHEAP. 也许有了e-ink的支持，设备的资源非常有限，在某些情况下会开始这样奇怪的行为。

大家好，我似乎能够再现这种行为。 似乎在代码中定义更多数据，例如字节数组中的字体...会导致这样的奇怪问题...我只使用单个300字节数组作为图形的操作缓冲区，但图标和字体被定义为常量数组。 我希望他们会占用内存中的数据部分...在这种情况下我有点迷失。 我应该考虑哪些限制？ 我是否应该调整有关xdata的任何设置？ 对于我的情景，您会提出哪些建议？ 你是否认为像更大的阵列这样的结构会导致如此不稳定。 我不明白为什么重启不起作用...但设备状态可能需要更多资源才能触发问题...

您好，Peter，

我同意常量应占用闪存，但是300字节缓冲区可能会对RAM产生很大影响，因为XDATA堆栈和INT_HEap_LEN大小在默认情况下是边缘的。  请考虑增加这些代码，以观察这是否会改变行为， 并删除可能影响RAM使用的任何不必要的代码(在 这方面查看SWRA635)。  任何溢出都可能导致意外的设备行为，并且在尝试修改NV闪存区域时，可能是由独特因素组合导致RAM冲突。

此致，
Ryan

您好，Ryan：

我似乎需要学习很多。。。 我发现许多关于类似主题的不同讨论，例如 关于内存模型，优化等，例如https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/9.3583万/help-the-input-param-of-one-function-was-changed-when-running-timac-cc2530-1-3-0</s>2530

但说实话... 我在这方面的知识相当有限，所以我需要追上。 从我到目前为止所看到的情况来看，大常量也可能会引起问题，需要引起注意。在我的情况中，添加更多的const数组(例如与字体相关的内容)似乎会使情况恶化，尽管RAM缓冲区保持不变，我不直接分配更多内存。 所以常量本身似乎有问题。 目前，我不知道我的限制是什么，我应该对项目设置进行哪些更改以优化这些限制。因此，我需要获得一些文档，并更深入地了解这些内容。

大家好，请确认我对闪存和XDATA之间常量映射的理解。 在f8w2530.xcl中，我发现闪存中的常量映射到XDATA，而不是复制它们。 我不确定我是否正确理解这些范围，但在我看来，XDATA (RAM)的4000B是为这些常量保留的？ 如果这是真的，我计算，只有我的方案中的字体和图标在几分钟后失败，大约需要3700 B，我不计算程序中的其他常量。 所以我的假设是正确的，即我的常量可能会在RAM中溢出？ 或者我完全错了吗？ 我是否可以将4000B作为常量的限制？ 或者，如果没有，限制是什么？ 谢谢！

您能否提供您的f8w2530.xcl文件或告诉我它与下面提供的默认文件有何不同？

/**************************************************************************************************
  Filename:       f8w2530.xcl
  Revised:        $Date: 2014-05-17 12:12:11 -0700 (Sat, 17 May 2014) $
  Revision:       $Revision: 38578 $

  Description:    This is a linker command line file for the IAR XLINK tool for the
                  CC2530 SoC and Z-Stack sample applications where the General Options
                  for location for constants and strings is "ROM mapped as data".


  Copyright 2009-2014 Texas Instruments Incorporated. All rights reserved.

  IMPORTANT: Your use of this Software is limited to those specific rights
  granted under the terms of a software license agreement between the user
  who downloaded the software, his/her employer (which must be your employer)
  and Texas Instruments Incorporated (the "License").  You may not use this
  Software unless you agree to abide by the terms of the License. The License
  limits your use, and you acknowledge, that the Software may not be modified,
  copied or distributed unless embedded on a Texas Instruments microcontroller
  or used solely and exclusively in conjunction with a Texas Instruments radio
  frequency transceiver, which is integrated into your product.  Other than for
  the foregoing purpose, you may not use, reproduce, copy, prepare derivative
  works of, modify, distribute, perform, display or sell this Software and/or
  its documentation for any purpose.

  YOU FURTHER ACKNOWLEDGE AND AGREE THAT THE SOFTWARE AND DOCUMENTATION ARE
  PROVIDED “AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
  INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY, TITLE,
  NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL
  TEXAS INSTRUMENTS OR ITS LICENSORS BE LIABLE OR OBLIGATED UNDER CONTRACT,
  NEGLIGENCE, STRICT LIABILITY, CONTRIBUTION, BREACH OF WARRANTY, OR OTHER
  LEGAL EQUITABLE THEORY ANY DIRECT OR INDIRECT DAMAGES OR EXPENSES
  INCLUDING BUT NOT LIMITED TO ANY INCIDENTAL, SPECIAL, INDIRECT, PUNITIVE
  OR CONSEQUENTIAL DAMAGES, LOST PROFITS OR LOST DATA, COST OF PROCUREMENT
  OF SUBSTITUTE GOODS, TECHNOLOGY, SERVICES, OR ANY CLAIMS BY THIRD PARTIES
  (INCLUDING BUT NOT LIMITED TO ANY DEFENSE THEREOF), OR OTHER SIMILAR COSTS.

  Should you have any questions regarding your right to use this Software,
  contact Texas Instruments Incorporated at www.TI.com.

**************************************************************************************************/

////////////////////////////////////////////////////////////////////////////////
//
//
// Segment limits
// --------------
//
//
// XDATA available to the program.
//
// Reserving address 0x0 for NULL.
-D_XDATA_START=0x0001
-D_XDATA_END=0x1EFF
//
//
// The 8052 IDATA is overlayed on the SoC XDATA space from 0x1F00-0x1FFF.
//
-D_IDATA_END=0xFF              // Last address of Idata memory.
//
//
//    CODE
//
-D_CODE_START=0x0000
-D_CODE_END=0x7FFF             // Last address for ROOT bank.
//
-D_FIRST_BANK_ADDR=0x10000
//
//
//
// Special SFRs
// ------------
//
//    Register bank setup
//
-D?REGISTER_BANK=0             // Default register bank (0,1,2,3).
-D_REGISTER_BANK_START=0       // Start address for default register bank (00,08,10,18).
//
//
//    PDATA page setup
//
-D?PBANK_NUMBER=00             // High byte of 16-bit address to the PDATA area.
//
//
//    Virtual register setup
//    ----------------------
//
-D_BREG_START=0x00             // The bit address where the BREG segments starts.
                               // Must be placed on: _BREG_START%8=0 where _BREG_START <= 0x78.
-D?VB=0x20                     // ?VB is used when referencing BREG as whole byte.
                               // Must be placed on: ?VB=0x20+_BREG_START/8.
//
////////////////////////////////////////////////////////////////////////////////



////////////////////////////////////////////////////////////////////////////////
//
// IDATA memory
//

// Setup "bit" segments (only for '__no_init bool' variables).
-Z(BIT)BREG=_BREG_START
-Z(BIT)BIT_N=0-7F

-Z(DATA)REGISTERS+8=_REGISTER_BANK_START
-Z(DATA)BDATA_Z,BDATA_N,BDATA_I=20-2F
-Z(DATA)VREG=08-7F
-Z(DATA)PSP,XSP=08-7F
-Z(DATA)DOVERLAY=08-7F
-Z(DATA)DATA_I,DATA_Z,DATA_N=08-7F

-U(IDATA)0-7F=(DATA)0-7F
-Z(IDATA)IDATA_I,IDATA_Z,IDATA_N=08-_IDATA_END
-Z(IDATA)ISTACK+_IDATA_STACK_SIZE#08-_IDATA_END
-Z(IDATA)IOVERLAY=08-FF

////////////////////////////////////////////////////////////////////////////////
//
// ROM memory
//
//
// The following segments *must* be placed in the root bank. The order of
// placement also matters for these segments, which is why we use the -Z
// placement directive.
//
-Z(CODE)INTVEC=_CODE_START
-Z(CODE)BIT_ID,BDATA_ID,DATA_ID,IDATA_ID,IXDATA_ID,PDATA_ID,XDATA_ID=_CODE_START-_CODE_END
//
// Sleep PCON instruction must be 4-byte aligned.
//
-D_SLEEP_CODE_SPACE_START=(_CODE_END-7)
-D_SLEEP_CODE_SPACE_END=(_CODE_END)
-Z(CODE)SLEEP_CODE=_SLEEP_CODE_SPACE_START-_SLEEP_CODE_SPACE_END
//
// The following segments *must* be placed in the root bank, but the order
// of placement within the root bank is not important, which is why we use the
// -P directive here.
//
-P(CODE)CSTART,BANK_RELAYS,RCODE,DIFUNCT,NEAR_CODE=_CODE_START-_CODE_END
//
// Setup for constants located in code memory:
//
-P(CODE)CODE_C=_CODE_START-_CODE_END
//
// Define segments for const data in flash.
// First the segment with addresses as used by the program (flash mapped as XDATA)
-P(CONST)XDATA_ROM_C=0x8000-0xFFFF
//
// Then the segment with addresses as put in the hex file (flash bank 1)
-P(CODE)XDATA_ROM_C_FLASH=0x18000-0x1FFFF
//
// Finally link these segments (XDATA_ROM_C_FLASH is the initializer segment for XDATA_ROM_C,
// we map the flash in the XDATA address range instead of copying the data to RAM)
-QXDATA_ROM_C=XDATA_ROM_C_FLASH
//
// The directive below ensures that the remaining space in the root bank gets
// filled, then starts filling the banks.
//
-P(CODE)BANKED_CODE=_CODE_START-_CODE_END,0x18000-0x1FFFF,0x28000-0x2FFFF,0x38000-0x3FFFF,\
0x48000-0x4FFFF,0x58000-0x5FFFF,0x68000-0x6FFFF,0x78000-0x7F7FF

////////////////////////////////////////////////////////////////////////////////
//
// XDATA memory
//

-Z(XDATA)XSTACK+_XDATA_STACK_SIZE=_XDATA_START-_XDATA_END
-Z(XDATA)XDATA_Z,XDATA_I=_XDATA_START-_XDATA_END
-P(XDATA)XDATA_N=_XDATA_START-_XDATA_END

-cx51

////////////////////////////////////////////////////////////////////////////////
//
// Texas Instruments device specific
// =================================
//
//
// Layout of CODE banks
// -------------------
//
//-D_BANK0_START=0x08000
//-D_BANK0_END=0x0FFFF
//
//-D_BANK1_START=0x18000
//-D_BANK1_END=0x1FFFF
//
//-D_BANK2_START=0x28000
//-D_BANK2_END=0x2FFFF
//
//-D_BANK3_START=0x38000
//-D_BANK3_END=0x3FFFF
//
//-D_BANK4_START=0x48000
//-D_BANK4_END=0x4FFFF
//
//-D_BANK5_START=0x58000
//-D_BANK5_END=0x5FFFF
//
//-D_BANK6_START=0x68000
//-D_BANK6_END=0x6FFFF
//
//-D_BANK7_START=0x78000
//-D_BANK7_END=0x7FFFF
//
//
// Include these two lines when generating a .hex file for banked code model:
-M(CODE)[(_CODEBANK_START+_FIRST_BANK_ADDR)-(_CODEBANK_END+_FIRST_BANK_ADDR)]*\
_NR_OF_BANKS+_FIRST_BANK_ADDR=0x8000

// When -M is used to build debug output, XLINK gives warning [w69] which is safely ignored.
-ww69=i

//
//
// Internal flash used for NV address space: reserving 6 pages.
// NV memory segment size must coincide with page declarations in "hal_board_cfg.h" file.
//
-D_ZIGNV_ADDRESS_SPACE_START=(((_NR_OF_BANKS+1)*_FIRST_BANK_ADDR)-0x3800)
-D_ZIGNV_ADDRESS_SPACE_END=(_ZIGNV_ADDRESS_SPACE_START+0x2FFF)
-Z(CODE)ZIGNV_ADDRESS_SPACE=_ZIGNV_ADDRESS_SPACE_START-_ZIGNV_ADDRESS_SPACE_END
//
//
//
// The last available page of flash is reserved for special use as follows
// (addressing from the end of the page down):
//   16 bytes  Lock bits
//    8 bytes  IEEE address space (EUI-64)
//   22 bytes  Device Private Key (21 bytes + 1 byte pad to NV word size)
//   22 bytes  CA Public Key (22 bytes)
//   48 bytes  Implicit Certificate (48 bytes)
// 1932 bytes  Reserved for future Z-Stack use (1932 bytes)
//
-D_LOCK_BITS_ADDRESS_SPACE_START=(((_NR_OF_BANKS+1)*_FIRST_BANK_ADDR)-0x10)
-D_LOCK_BITS_ADDRESS_SPACE_END=(_LOCK_BITS_ADDRESS_SPACE_START+0x0F)
-Z(CODE)LOCK_BITS_ADDRESS_SPACE=_LOCK_BITS_ADDRESS_SPACE_START-_LOCK_BITS_ADDRESS_SPACE_END
//
-D_IEEE_ADDRESS_SPACE_START=(_LOCK_BITS_ADDRESS_SPACE_START-0x08)
-D_IEEE_ADDRESS_SPACE_END=(_IEEE_ADDRESS_SPACE_START+0x07)
-Z(CODE)IEEE_ADDRESS_SPACE=_IEEE_ADDRESS_SPACE_START-_IEEE_ADDRESS_SPACE_END
//
-D_DEV_PRIVATE_KEY_ADDRESS_SPACE_START=(_IEEE_ADDRESS_SPACE_START-0x16)
-D_DEV_PRIVATE_KEY_ADDRESS_SPACE_END=(_DEV_PRIVATE_KEY_ADDRESS_SPACE_START+0x15)
-Z(CODE)DEV_PRIVATE_KEY_ADDRESS_SPACE=_DEV_PRIVATE_KEY_ADDRESS_SPACE_START-_DEV_PRIVATE_KEY_ADDRESS_SPACE_END
//
-D_CA_PUBLIC_KEY_ADDRESS_SPACE_START=(_DEV_PRIVATE_KEY_ADDRESS_SPACE_START-0x16)
-D_CA_PUBLIC_KEY_ADDRESS_SPACE_END=(_CA_PUBLIC_KEY_ADDRESS_SPACE_START+0x15)
-Z(CODE)CA_PUBLIC_KEY_ADDRESS_SPACE=_CA_PUBLIC_KEY_ADDRESS_SPACE_START-_CA_PUBLIC_KEY_ADDRESS_SPACE_END
//
-D_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START=(_CA_PUBLIC_KEY_ADDRESS_SPACE_START-0x30)
-D_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_END=(_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START+0x2F)
-Z(CODE)IMPLICIT_CERTIFICATE_ADDRESS_SPACE=_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START-_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_END
//
-D_RESERVED_ADDRESS_SPACE_START=(_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START-0x78C)
-D_RESERVED_ADDRESS_SPACE_END=(_RESERVED_ADDRESS_SPACE_START+0x78B)
-Z(CODE)RESERVED_ADDRESS_SPACE=_RESERVED_ADDRESS_SPACE_START-_RESERVED_ADDRESS_SPACE_END
//
////////////////////////////////////////////////////////////////////////////////

在哪里可以看到4 KB (0x0FFF)限制？  为闪存中的const数据定义了0x8000到0xffff之间的区域， TRM中对此进行了进一步说明：

XDATA的上部32 KB 是一个只读区域，称为XBANK (参见图2-1)。 任何可用的32 KB 闪存库都可以在此处映射。 这使软件可以访问整个闪存。 此区域通常用于存储其他常量数据。

除了我相信您已经知道的信息之外，我没有任何其他文件可供提供。

此致，
Ryan

您好，Ryan：  

我很抱歉。 这显然只是我的误解。 还不错 这个问题似乎有点超出了我的知识和能力。 我不明白到底发生了什么 也许这是真正的堆问题... OSALMEM_MESTICS仍 留待我尝试使用图形缓冲区。 感谢Ryan的大力支持！

Ryan，您好，这种奇怪的行为可能是RAM相关问题的结果。 我完全删除了图形缓冲区，现在图形被直接复制到eink模块RAM，到目前为止我还没有看到这个问题。

但是...

现在我有了新的现象...我不知道应该责怪谁... Ed，路由器或协调员...

有时，当Zed直接轮询协调器时，可能是在将父路由器切换到协调器后发生的情况。

但协调员仍在尝试通过路由器将WriteCommand路由到Zed。 协调员仍然认为Zed在路由器后面，但Zed轮询直接协调员，因此它显然改变了父命令。因此，WriteCommand永远不会发送，因为它被困在路由器上，而且由于路由器从未轮询，所以它永远不会释放消息。 似乎没有参与者愿意对此采取任何行动。 Zed很高兴地对协调员和协调员进行了轮询，但他们仍将命令传送到路由器。 我有一个sucspicon，他可能是协调员有罪了。 它是zigbee2mqtt，带有zzh stick..运行3.x.0 ZStack固件.. 我不知道在这种情况下哪位学员应该开始某种修复。

谢谢你。

您好，Peter，

您能否提供一个能够证明这种新行为的嗅探器日志？  向ZC发送重新加入请求的Zed应触发关联和路由表自动更新，以便消息可以直接发送到Zed作为其子设备。  您是否还知道CC2652R ZNP上的SimpleLink SDK版本？

此致，
Ryan