[参考译文] SIMPLELINK-CC13X2-26X2-SDK：自 SDK 6.20.00.29起固件不稳定

尊敬的 Koen：

我已经查看了 Z-Stack 源代码、发现 v6.10和 v6.20 SDK 之间没有什么明显变化、因为您已经注意到、已在更改日志中有所反映。  我也没有观察到其他使用较新 SDK 的客户的类似报告。  v6.20 SDK 版本说明 反映了影响 Z-Stack 的许多全局更改：

• 删除了对 TI ARM-CGT 编译器示例和库的支持、以支持 TI Clang 编译器
• 弃用并删除了对引脚驱动器的支持、以支持 GPIO++
• 已弃用并删除对 UART 驱动程序的支持、以便在除 BLE5-Stack 的 NPI 之外的所有情况下都支持 UART2。

您在构建 v6.20 Z-Stack 项目时使用了哪些依赖项、如何从 v6.10迁移资源以及有哪些小的更改持续存在？  请注意、 ZNwkTableFull 通常与 MAX_RTG_entry/MAX_RREQ_entry/MAX_RTG_SRC_entries 相关、并回顾 在这些 SDK 期间对默认堆分配进行了更改。

此致、
瑞安

-我怎么能看到这些依赖性? 我使用 CCS 12.4.0编译了工作(6.10)和非工作(6.20)固件

-我已经通过创建一个包含所有更改的修补程序文件将更改从6.10迁移到6.20

-以下是指向此补丁的链接(仅适用于 CC26XR1，但适用于 CC2652RB/CC1352的补丁是相同的)：补丁  。 您可以在此处查看所有 表大小。 除了一些已更改的文件散列值之外，6.10版的修补程序也是相同的。

-我知道  MAX_RTG_entries 和 MAX_RTG_SRC_entries ,但不知道 MAX_RREQ_entries ! 谢谢您的指点。 您还能回顾一下我正在使用的其他表格大小吗？ 您可以在我链接的补丁中的 preinclude.h 中找到它们。  

   -例如,我仍然不确定使用什么值 SRC_RTG_expirate_time/route_expirate_time,我知道255禁用路由删除,但如果表满,会发生什么情况? 另一方面、值10将在10秒内使路由过期、但在表满之前、AFAIK 不会将其删除。 所以我不明白为什么有人会在这里使用255。

-关于缺省堆分配,这已经在6.10中改变了(这很好),所以这不是问题。

- ARM-CGT 编译器也不能导致这个问题,我已经在使用 TI clang 编译器作为我的6.10固件

"Project Properties"->"CCS General"->"Project/Products"选项卡(适用于编译器、SDK 和 SysConfig 依赖项)。  此外还有"CCS Build"->"Environment"选项卡。  我认为  MAX_RREQ_ENTRIES 不会有什么不同、我只是列出了所有可能返回 NWK 表满错误的定义。  您也可以考虑 Conflicted_addr_table_size。  我们已经审查了 修补程序中列出的表大小中的大多数(如果不是全部) ，但由于更改的数量太多，很难进一步跟踪和量化。  确实， 只有在必要时才会删除过期的活动路由，如果禁用了路由删除，则即使表已满，通常也会保留一条过期路由。  这将是开发商的默示决定,无论目的如何。

在 NWK 表已满、无法加入/重新加入新设备以及可能发生崩溃的每个实例中、最常见的通用性是什么？ 是否可以 提供任何监听器日志(突出显示重要数据包)或调试日志？  我会尽量向软件开发团队寻求意见、但如果可以使用简化的 Z-Stack 补丁复制该问题、但仍然会导致该问题、我们将提供最佳的支持。

编辑：软件开发 也不知道 SDK 版本之间有什么明显差异。

此致、
瑞安

我已编译了一个新固件供用户测试、并按照您提到的调整了表大小： Z-Stack_3.x.0 Coordinator 20231111/20231112 feedback Koenk/Z-Stack-firmware·discussion·#483 (github.com)

> 如果禁用了路由删除，则即使表已满，通常已过期的路由也会保留。

如果禁用了路由删除(SRC_RTG_TIMEOUT_TIME = 255)、则表将变满(MAX_RTG_SRC_ENTRIES)并且发现了新的路由、表是否会溢出并导致固件崩溃？ 或者是否不再添加新路线？

因此、具有我用于编译6.20 SDK 的所有依赖项：

您可以考虑使用 v6.20的 Z-Stack 版本说明中列出的依赖项、但我不认为这会对 本主题产生重大影响  

• TI Code Composer Studio： CCS-11.2.0
• TI ARM Clang 编译器工具：  2.1.0.LTS
• XDCTools：  3.62.01.15
•  适用于 IAR IDE 的 SysConfig 独立工具：  1.13.0

如果 满足 MAX_RTG_SRC_ENTRIES、路由层将随着 RTG_SRC_TBL_FULL 退出 、而无需执行进一步的操作。  请让我知道新图像的共识、当它可用时、该图像正在测试中。

此致、
瑞安

您好、Ryan、

用户使用6.20 FW 捕获了崩溃的日志+嗅探、所做的更改极少。

-所有的更改此 FW: diff 补丁 (因为这些更改看起来如此微小和标准我,我认为我们可以排除这是罪魁祸首)

-链接到日志+监听:链接 ,一些吸引我注意的事情:

 -各种 MEM_ERROR (0x10)可以在日志中看到(zigbee - herdsman : adapter:ZStack:ZNP :SRSP <- AF - dataRequest -{"status":16})

 -各种 buffer_full (0x11)可以在日志中看到(zigbe-herdsman : adapter:ZStack:ZNP :SRSP <- AF - dataRequest -{"status":17})

 -在某些时候它完全崩溃(失败(SRSP - AF - dataRequest 后6000ms))

 -我要求提供网络密钥以便可以解密监听

您好、Koen：

瑞安是出来的时刻(假期),我想让你知道,我看了你的链接和你的第二个链接的日志+嗅探(到谷歌驱动器),我们不能打开(不是一个问题在你的终端,我们不能打开该格式)。 您能否在压缩文件中包含您的结果、以便我们一起来看看？ 由于假期、我们可能会延迟、对于给您带来的不便、我深表歉意。  

谢谢。
A·F

您好，Alex

我认为第一个指针是 MEM_ERROR。

- SDK 为什么会产生这个错误?

-可以做什么来防止它?

e2e.ti.com/.../Archive.zip

嘿、Koen、

如果没有足够的堆内存来完成请求、则可以返回 ZMemError、ZBufferFull 可能表示 NWK/MAC 缓冲区暂时被填满。  可在 ZNP 项目中搜索这两个文件。  我在这个 相关的 E2E 回复中 就缓解这些问题的方法提供了一些评论。  很抱歉、如果我们之前没有解决这个问题、或者可能是在最小的补丁中错过了这个问题。

此致、
瑞安   

我们还面临着 SDK 7.10和 cc2652p 的不稳定问题，主要是 ZCL 报告命令 API 无法可靠运行...有时它会工作，有时它会卡在循环的策略错误中。  

尊敬的 Dhanraj：

请根据所有详细信息启动新主题、包括观察结果、堆栈更改、监听器/调试日志以及经过测试的版本。

此致、
瑞安

它花了一些时间,但我终于设法得到一个监听+日志的崩溃。 此用户测试了各种固件：

- 20230922 (= 6.10 SDK +所有我的更改)：此固件工作正常，无崩溃，性能良好

- 20230923 (= 6.20 SDK +所有我的更改):此固件崩溃,执行不良

 -  20231221 (= 6.20 SDK+最少更改):此固件崩溃并执行不良

我的更改链接：

- 所有更改

- 更改最少

为了确保崩溃不是由"我的所有更改"造成的,以下监听+日志是从 20231221,所以一个只有最小更改的固件。

日志+监听： e2e.ti.com/.../nick_5F00_crash_5F00_sniff_5F00_log_5F00_20231221.zip

注：

-我看到网络上有很多路由请求,这可能是导致崩溃的原因?

-协调员发送的最后一条消息是#2992071

-在日志中, ZNP 停止通信"2023-12-23T22:24:00.450Z",(搜索"失败(SRSP - AF - dataRequest after 6000ms)")

-要获得 ZNP 和 Z2M 之间的所有通信,请筛选"zigble-herdsman:adapter:ZStack:ZNP"

E2E 社区成员、您好！

感谢您在 E2E 论坛上提出有关 TI SimpleLink 器件的问题！ 能够最好地回答您的询问的主题专家在假期不在办公室。 1月初返回后、他们将审查您的帖子并在24小时内提供初步回复。

此致、
1月

尊敬的 Koen：  

感谢您提供监听器和主机日志。  发生故障时、有多少设备正在网络上主动通信、活动设备的数量与 ZNP 的稳定性之间是否存在相关性？  这有很多信息需要处理、但它似乎强化了 MTO 路由请求会导致 堆内存溢出的想法。  您是否能够调试 ZNP 崩溃后的活动会话以查看调用堆栈？  器件恢复是否为软复位？  编译器迁移或对较低级别的15.4-Stack MAC 的更改可能会导致堆需求增加。  如果我不记得了、请原谅我、但您还评估过 v7.10吗？  你可以尝试再次增加堆(缓冲区应该在它们当前的大小上是足够的)、然而这将 很快达到一个上限、只有88KB 的 RAM 可用。  一些更新的器件具有更多的 RAM、例如具有144KB RAM 的 CC2652P7、可能值得评估。  还有一些可能尚未考虑的其他注意事项涉及路由和发现时间、 有关详细信息、请参阅 SWRA650的表1。  我知道最大的困难是复制和观察问题、因为需要连接多个器件并进行通信。  是否有具体的原因需要升级 SDK？  6.10版上的 Z-Stack 解决方案是稳定的、较新版本不包含许多需要关注的令人难忘的更新或错误修复。

此致、
瑞安

大家好、Koen 和 Ryan、

新年快乐！

    经过测试、超过30个器件(cc1352p)的 ZNP SDK v4.40网络比 ZNP SDK v6.40.00.13的网络更加稳定。

此致、

大卫

尊敬的 David：

祝大家新年快乐！  您能否分享您的观察  结果、包括堆栈更改和监听器/调试日志、从而得出以上结论？

此致、
瑞安

您好、Ryan、

新年快乐！

我知道有很多变量、但我不希望增加堆会修复。 这个问题也发生在 运行7.10的 CC2652P7上。我想坚持使用6.10、但之后我们无法支持 P7 (因为6.10不支持它)。

鉴于您之前发送给我的6.10与6.20的区别、这些更改中的任何一个都不可能导致此问题。 因此、我预计其中一个较低级别的库会有错误。 是否可以将6.10 15.4 Stack MAC 与6.20配合使用？

我想坚持6.10但我们不能支持 P7 (因为6.10中不支持它)

您能进一步解释一下吗？  对于 v6.10 SDK、CC2652P7列于 发行说明中 、提供 直接支持 CC2652P7的 CC1352P7示例。

是否可以使用6.10 15.4协议栈 MAC with 6.20？

我会向软件开发团队询问此问题、感谢各位专家此刻仍在办公室外的耐心等待。

此致、
瑞安

您好、Ryan、

我对此进行了更深入的研究、并发现它可以使用6.10版中的 libs。 首先、我尝试使用6.10版发布的15.4协议栈。 我通过将"simplelink_cc13xx_cc26xx_sdk_6_20_00_29/source/ti/ti154stack/lib/ticlang/m4F"的内容替换为"simplelink_cc13xx_cc26xx_SDK_6_10_01_01/source/ti/ti154stack/lib/ticlang/M4F"来实现这一点。 此后、固件仍会崩溃。

然后我尝试使用6.10版中的闭源代码 ZStack 库(在"source/ti/ZStack/lib/ticlang/M4F"下)、此后固件不再崩溃！ 所以它似乎 ZStack 的闭源库中的一个变化导致了这个回归。 与6.10相比、这些库有什么变化？

感谢更新 Koen。  我已经相应地通知了研发团队。  您是否能够仅替换 ZStack 源库或是否需要替换这两个源库(即 ZStack 和 ti154stack)？

此致、
瑞安

只有 ZStack 就足够了。 我现在将 针对最新的 SDK (即 7_10_02_23 + 6.10 ZStack 库)测试相同的代码。

您好、Koen：

我已经同意研发团队关于这个问题的观点、并提交了一份错误通知单、以便内部可以进一步探讨这个问题。  但是、我目前无法提供此类调查结果的时间表

此致、
瑞安

尊敬的 Koen：

TI R&D 已请求您  根据 发行说明使用 SimpleLink F2 SDK 7.10.02.23与 TI ARM Clang 编译器 v2.1.2.LTS 复制此问题、并在此过程中确认编译器版本差异(尽管很小)不会导致此问题。

谢谢。
瑞安

您好！

也许你可以在 app.cfg 文件中尝试4.40 SDK 中使用的动态堆配置、而不是在6.10+中使用的静态配置

/*
 * Heap Configuration defines the type of Heap you want to use for the system (application + Stack)
 * Only one Heap buffer will be allocated. This heap will be shared by the system and the stack through
 * one manager (HeapMem, HeapMem+HeapTrack or OSAL)
 * You can still decide to create several heaps if you want, but at least one heap needs to be created.
 * The stack must have a Heap to run.
 * The different Heap manager available are :
 * OSAL HEAP: legacy Heap manager provided with all BLE sdk. By default, this Heap manager is used.
 *  HeapMem:� heap manager provided by TI-RTOS (see TI-RTOS user guide for properties)
 * HeapTrack: module on top of HeapMem allowing an easy debugging of memory allocated through HeapMem.
 *
 * The heap manager to use is selected by setting  HEAPMGR_CONFIG to the corresponding value (see below)
 * 0    = osal Heap manager, size is static.
 * 0x80 = osal Heap manager, with auto-size: The remainning RAM (not used by the system) will be fully assign to the Heap.
 * 1    = HeapMem with Static size
 * 0x81 = HeapMem with auto-size. The remainning RAM (not used by the system) will be fully assign to the Heap.
 * 2    = HeapTrack (with HeapMem) with fixe size
 * 0x82 = HeapTrack (with HeapMem) with auto-size: The remainning RAM (not used by the system) will be fully assign to the Heap.
 *
 * If HEAPMGR_CONFIG is not defined, but the configuration file ble_stack_heap.cfg is used, then the value
 * HEAPMGR_CONFIG = 0x80 is assumed.
 * If HEAPMGR_CONFIG is not defined, and the file ble_stack_heap.cfg is not used, then the value
 * HEAPMGR_CONFIG = 0x80 is assumed and the default Heap size will be 3072
 * unless you define HEAPMGR_SIZE to a different value in the project option (0 meaning auto-size).
 *
 * From the configuration below, two #define will be created that will be used by the application to setup the Heap:
 * #define HEAPMGR_SIZE
 * #define HEAPMGR_CONFIG
 * In order to use those define, this include line needs to be added: #include <xdc/cfg/global.h>
 *
 * In order for the auto-size Heap to work, the following symbol needs to be created by the linker:
 *  heapStart
 *  heapEnd
 */

/*
 * DISCLAIMER: The HeapMem module in ROM can only use a GateMutex module. This means the malloc()
 * function cannot be used in a Hwi/Swi.
 * This means also that other access to the heap, with Icall_alloc for example, can potentially break the Heap...
 * Therefore this solution is most effective when TI-RTOS is located in FLASH, so that a GateHwi can be used.
 * If you try to use it in ROM, a workaround using HeapCallback is used, which will degrade performance.
 */
var Memory = xdc.useModule('xdc.runtime.Memory');
var HEAPMGR_CONFIG = 0x80;
var HEAPMGR_SIZE   = 30000; //only valid if static size is used. This is the size of the buffer allocated for Heap.

if (typeof HEAPMGR_CONFIG === 'undefined' )
{
  var HEAPMGR_CONFIG = 0x80;
}

// The following will create the #define HEAPMGR_CONFIG. It can then be used by include  <xdc/cfg/global.h>
Program.global.HEAPMGR_CONFIG = HEAPMGR_CONFIG;

if (HEAPMGR_CONFIG === 1 || HEAPMGR_CONFIG === 0x81)
{
  var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
  var heapMemParams = new HeapMem.Params();

  if (HEAPMGR_CONFIG === 0x1)
  {
    heapMemParams.size = HEAPMGR_SIZE;
    Program.global.HEAPMGR_SIZE = HEAPMGR_SIZE;
  }
  else
  {
    // if you get an undefined error for the symbol bellow it means that AUTOHEAPSIZE has been defined in the application.
    Program.global.HEAPMGR_SIZE = 0;
    heapMemParams.usePrimaryHeap = true;
    HeapMem.primaryHeapBaseAddr = "&heapStart";
    HeapMem.primaryHeapEndAddr = "&heapEnd";
  }

  Program.global.stackHeap = HeapMem.create(heapMemParams);

  var GateHwi = xdc.useModule('ti.sysbios.gates.GateHwi');
  HeapMem.common$.gate = GateHwi.create();
  Memory.defaultHeapInstance = Program.global.stackHeap;
}
else if (HEAPMGR_CONFIG === 2 || HEAPMGR_CONFIG === 0x82)
{
  var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
  var heapMemParams = new HeapMem.Params();
  if (HEAPMGR_CONFIG === 2)
  {
    heapMemParams.size =  HEAPMGR_SIZE;
    Program.global.HEAPMGR_SIZE = HEAPMGR_SIZE;
  }
  else
  {
    // if you get an undefined error for the symbol bellow it means that AUTOHEAPSIZE has been defined in the application.
    //
    heapMemParams.usePrimaryHeap = true;
    HeapMem.primaryHeapBaseAddr = "&heapStart";
    HeapMem.primaryHeapEndAddr = "&heapEnd";
    Program.global.HEAPMGR_SIZE = 0;
  }

  var tempHeap = HeapMem.create(heapMemParams);

  var GateHwi = xdc.useModule('ti.sysbios.gates.GateHwi');
  HeapMem.common$.gate = GateHwi.create();

  var HeapTrack = xdc.useModule('ti.sysbios.heaps.HeapTrack');
  var heapTrackParams = new HeapTrack.Params();
  heapTrackParams.heap = tempHeap;
  Program.global.stackHeap = HeapTrack.create(heapTrackParams)
  Memory.defaultHeapInstance = Program.global.stackHeap;
}
else if (HEAPMGR_CONFIG === 0 || HEAPMGR_CONFIG === 0x80)
{

  var HeapCallback = xdc.useModule('ti.sysbios.heaps.HeapCallback');
  var params = new HeapCallback.Params();
  params.arg = 1;
  Program.global.heap0 = HeapCallback.create(params);
  HeapCallback.initInstFxn = '&osalHeapInitFxn';              // Call First When BIOS boot. Initialize the Heap Manager.
  HeapCallback.allocInstFxn = '&osalHeapAllocFxn';            // Call for allocating a buffer
  HeapCallback.freeInstFxn = '&osalHeapFreeFxn';              // Call for Freeing a buffer
  HeapCallback.getStatsInstFxn = '&osalHeapGetStatsFxn';      // Return Statistic on the Heap.
  HeapCallback.isBlockingInstFxn = '&osalHeapIsBlockingFxn';  // Return TRUE: This heap is always blocking ('Hwi Gate' like )
  //HeapCallback.createInstFxn = '&osalHeapCreateFxn';        // Not Supported
  //HeapCallback.deleteInstFxn = '&osalHeapDeleteFxn';        // Not supported
  Memory.defaultHeapInstance = Program.global.heap0;

  if (HEAPMGR_CONFIG === 0)
  {
    // the following definition will create the #define HEAPMGR_SIZE ,
    // which is used by thestack to have information about the heap manager size.
    // if set to 0, this imply auto-size heap
    Program.global.HEAPMGR_SIZE = HEAPMGR_SIZE;
  }
  else
  {
    // the following definition will create the #define HEAPMGR_SIZE ,
    // which is used by the stack to have information about the heap manager size.
    // if set to 0, this imply auto-size heap
    // The heap buffer will be created automaticaly by using all the remaiing RAM available at the end of the build/link.
    // For this, 2 symbole needs to be created by teh linker file: heapStart and heapEnd
    Program.global.HEAPMGR_SIZE = 0;
  }
}

谢谢。

阿克希莱什

尊敬的 Koen：

TI 的 Zigbee 测试团队根据您的 细微更改 、  使用43个器件24小时运行网络。  这包括 ZR 的/休眠 ZEDS/非休眠 ZED (每台路由器最多6个子、共4跳)、默认轮询速率和每60秒发送一个具有不同有效负载大小的自定义"大型网络测试"数据包。 ZC (或其他此类器件)从不会崩溃。  在此设置中、您有什么建议可以帮助导致此问题吗？

此致、
瑞安

您好、Ryan、

我现在已经编译了 7.10.02.23 FW + TI ARM Clang 编译器 v2.1.2.LTS + CCS 12.2.0、固件在几小时/几天之间的某处仍会崩溃。 我已经和2个用户验证了这一点。

关于重现性、我仍然不知道是什么触发了崩溃。 鉴于变量很多、我认为这是非常复杂的问题。 如前所述、7.10还能使许多人(包括我)保持稳定。

我之前提到过、为了使6.20 SDK 保持稳定(此 SDK 是首次引入此问题的版本)、可以通过使用6.10 ZStack 库使其保持稳定。 事实证明这不是真的、6.20 SDK 与6.10 ti154库的组合似乎可以实现稳定。 如果情况确实如此、我将对用户进行更多的测试。

一旦这个值被确认(6.20sdk + 6.10 ti154 libs 以使其稳定)、是否有可能深入了解6.10 <->6.20 ti154 libs 之间的变化、我的预期是这个错误仍然存在于7.10 ti154 libs 中。

尊敬的 Koen：

我将使用您的最新反馈更新 TI 软件开发团队、并询问 SDK 6.10版和6.20版之间15.4-stack 库之间的区别

此致、
瑞安

您好、Ryan、

似乎崩溃恰好在`AssocGetWithAddress`调用后发生。 请注意、在崩溃之前对`AssocGetWithAddress`进行了许多调用(3000+)。 此函数是否可能存在内存泄漏？

尊敬的 Koen：

该 API 返回关联表条目、并且多年来没有任何 assoc/neighbor 表更新(尤其是 v6.10 <-> v6.20+左右)。  因此、该问题可能与这些表格具体无关。

此致、
瑞安

您好、Ryan、

我明白了、但  从众多不同的请求中发出请求、它始终与此请求崩溃、这难道不是很可疑吗？ 是否可能是另一种方法将损坏的条目写入此表并在检索时导致崩溃？

接下来、我将从 z2m 中禁用此调用、并查看是否仍然发生崩溃。

我们在没有 assoc GET 调用的情况下尝试运行固件、固件似乎保持更长时间(几天)、但最终仍然崩溃。 您是否对6.10 en 6.20之间的 ti154更改有更深入的了解？

因为目前还不支持新的 P10芯片、所以我仍然很想开始使用7.10 SDK。

 对于不同 SDK 版本之间的 TI 15.4-Stack 更改、无法分享任何见解。  测试团队也无法根据提供的测试条件复制此行为。  您是否无法在 v7.10项目构建中使用6.10 ti154源代码？

此致、
瑞安

来自6.10的 ti154与7.10不兼容(获得了无效参数错误)。  

"无见解可分享"意味着什么？TI 不愿意分享更改以调试此问题、还是没有更改？

很抱歉这么含糊的回应,我的意思是这些代表看不到源代码版本之间的任何差异,这可以解释你观察到的行为。

此致、
瑞安

您能从 听到 Mathew 的调查中受益吗？  研发团队将进一步调查可能导致此问题的 SRC 匹配表变化。

此致、
瑞安

肯定是的！ 尽管我认为它不能解决崩溃的问题。

Ryan、您好、我注意到6.10和6.20 SDK 已经从下载站点中删除： SIMPLELINK-LOWPOWER-F2-SDK 软件开发套件(SDK)| TI.com 

为什么会发生这种情况、能否将它们放回？

您好、Koen、感谢您的报告。  我已经通知了正确的利益相关者、以便他们可以解决此错误。

此致、
瑞安

缺少的版本已恢复到 https://www.ti.com/tool/download/SIMPLELINK-LOWPOWER-F2-SDK 

此致、
瑞安

非常感谢！

与此同时、我们做了更多的测试。 它证明了我之前关于使用6.10 TI154/ZStack 库、与6.20修复了6.20稳定性问题是错误的、遗憾的是、这并不能解决问题。

我们还使用了 UART (而非 UART2驱动程序)进行了6.20测试、这也不能解决问题。

您或研发团队对于下一步的发展方向是否有任何线索？ 我仍然致力于寻找这种情况的根本原因、因为我不想被困在6.10 SDK 上。 我正在 Mac 上编译固件、在发行说明中建议使用 Windows、这可能会导致此问题吗？