[参考译文] CC2340R5：Z-Boss 堆栈在 RNG 初始化中启动期间冻结

尊敬的 Tiago：

首先、请尝试升级您的 TI Arm CLANG 编译器或删除 LTO 并确定这是否可以消除 该行为、请参阅此 E2E 主题 。  我也想知道您是否可以通过将 Power TI 驱动程序 PowerLPF3_getResetReason/PowerLPF3_releaseLatch锁 存器函数置于  main ( void) 或 ti_f3_main.c 中的* main_task_function (void *arg0) 而不是 main () 来缓解这种行为。

这种行为是否会在每台设备上或在少数几台设备上发生、以及有多少百分比的试验显示了该问题？  您正在使用 TI LaunchPad 或定制硬件进行评估？

此致、
Ryan

我们使用定制硬件。 它是一个非常简单的器件、即由电池 CR2032 供电的无线开关。 每个器件上都会出现该行为。  

我使用 30 个器件进行测试。 使用我们完整的固件、问题经常出现。 如果我反复按所有设备上的按钮、在大多数情况下、单击几分钟（可能是几百次点击/重置）后、我会看到问题。  

借助我的最小示例、这些示例没有传输、堆栈初始化后立即进入关闭 状态、什么允许快速循环复位、我可以在我尝试过的每个硬件上在几秒钟内重现此问题（大多数情况下，复位数少于 100 次）。

很遗憾、我没有用于 cc2340 的 LaunchPad 进行测试。 我很好奇 Launch Pad 上是否会出现这种情况。 您不能尝试在硬件中重现它吗？

我不知道是什么原因造成的、但问题主要在于 randon 噪声捕获和 RNG 运行状况检查测试。   即使在我的最小示例中、也可以完全消除该问题的权变措施是在 sysconfig 中禁用 RNG 健康测试：

禁用这两个检查后、即使在我的最小示例中多次单击几分钟、我也无法重现问题。  我知道这不是一个好的解决方案,所以我会尝试你的建议。

我正在使用 TI Arm CLANG v4.0.3、但会尝试 v4.0.4 并禁用 LTO。 我也会尝试将 PowerLPF3_getResetReason 放在 main () 上,但我不会使用它。

我做的另一项测试是在堆栈初始化之前施加 15ms 和 100ms 的 CPU 延迟、以便为随机捕获留出更多时间、但并没有什么帮助。 我可以尝试更改 RNG 完全禁用运行状况检查的参数、但我担心我可能只是在降低锁定的可能性。 由于我们将使用很多设备、即使是百万分之一的锁定概率、也不是很好、因为此问题会导致电池电量完全耗尽。  

我非常担心的一件事是像这种情况下的其他情况使用了连续循环。 在栈内部、任何中止都应调用可由用户自定义的中止函数。 在 ti_f3_main.c 中声明了“void ZB_ti_f3_abort (void)“、但这种情况下不会调用该函数。 我认为我需要实现一个看门狗来避免像这样的锁定。

开发团队应了解这种情况、并尝试避免这种情况（堆栈内的连续循环）。  

只要我有新的结果与你的建议,我发布在这里.

感谢您的帮助。

您使用的是什么 SDK 和 SysConfig 版本？  我认为需要有一种方法来复制 Zigbee 代码运行中的错误、即不仅仅是从 main 持续关闭。  在给定自定义硬件的情况下、我不确定器件在这些情况下的电源会发生什么情况。  我还在输入 main 之前提供了有关解决 Power TI 驱动程序 API 问题的建议、我看不到有证据已经进行了调查。

此致、
Ryan

尊敬的 Tiago：

感谢您提供所有这些信息。  您可以将 simplelink_lowpower_f3_SDK_9_12_00_19\source\ti\drivers\rng\RNGLPF3RF.c 复制到您的本地工作区目录中  、以便进一步调试 RNG_getRandomBits -> RNGLPF3RF_getValidatedNumber、尽管如此、我还是找到了一个与您描述的行为类似的内部错误票证、将在内部进一步查询。

在 PowerLPF3_releaseLatch锁 存器之后使用 PMCTLResetSystem 进行额外的软件复位（即仅在从关断状态唤醒期间复位）是否有助于缓解行为？  这是一个测试、不是推荐的权变措施。

此致、
Ryan

尊敬的 Tiago：

我尝试了,但无法复制的行为。  我使用的是 SimpleLink F3 SDK v9.12.0.19 版本说明中列出的依赖关系

TI Code Composer Studio: CCS 20.1.0
TI ARM Clang Compiler: 4.0.2.LTS
SysConfig: 1.23.01
UniFlash: 9.0.0
IAR Embedded Workbench: 9.60.3

使用默认的 CC2340R5 开/关开关、更改如下。  首先在 ti_f3_main.c 中：

int main(void)
{
  pthread_t           thread;
  pthread_attr_t      attrs;
  struct sched_param  priParam;
  int                 retc;
  int                 detachState;
  
  PowerLPF3_ResetReason resetReason = PowerLPF3_getResetReason();

  if (resetReason == PowerLPF3_RESET_SHUTDOWN_IO)
    PowerLPF3_releaseLatches();

然后在 on_off_switch.c 中：

  else
  {
    // GPIO_setConfig(CONFIG_GPIO_BTN1, GPIO_CFG_IN_PU);
    // GPIO_setConfig(CONFIG_GPIO_BTN2, GPIO_CFG_IN_PU);
    // // if either button 1 or button 2 gets pressed
    // zb_bool_t sideButtonPressed = ((GPIO_read((zb_uint8_t)CONFIG_GPIO_BTN1) == 0U) || (GPIO_read((zb_uint8_t)CONFIG_GPIO_BTN2) == 0U));
    // // then perform a factory reset
    // if (sideButtonPressed)
    // {
    //   perform_factory_reset = ZB_TRUE;
    //   Log_printf(LogModule_Zigbee_App, Log_INFO, "perform factory reset");
    // }

    zb_osif_led_button_init();
#ifndef ZB_COORDINATOR_ROLE
    ZB_SCHEDULE_APP_ALARM(off_network_attention, 0, 1 * ZB_TIME_ONE_SECOND);
#endif /* ZB_COORDINATOR_ROLE */

    zb_osif_led_on(0);

    GPIO_setConfig(CONFIG_GPIO_BTN1, GPIO_CFG_IN_PU | GPIO_CFG_SHUTDOWN_WAKE_LOW);

    Power_shutdown(0, 0);
    
    /* Call the application-specific main loop */
    my_main_loop();

您能帮助我进一步了解我们的设置之间的差异吗？  我建议您使用版本说明中的 SysConfig 和 TI Clang 编译器。

此致、
Ryan

您好：

对我的答复延迟表示歉意。 我花了一些时间进一步调查此问题、并进行了一些重要更新。

以下是我的调查结果：

• 我尝试  按照您的建议在 PowerLPF3_releaseLatchers () 之后添加一个额外的软件重置 (PMCTLResetSystem()、但它没有帮助。

• 通过将  RNGLPF3RF.c 复制 到我的项目中,我成功地隔离了问题,使其独立于 Z-Boss 堆栈。 我能够通过简单地初始化 RNG 来重现冻结,而没有调用  ZB_init ()。 挂起具体发生在内  RNG 健康检测 。 我认为这是导致堆栈初始化失败的原因。

• 在使用不同器件进行调试时、我注意到单位之间存在差异。 在我们的一些器件上、很难触发错误（超过 100 次复位/下电上电）、而在其他器件上、则非常容易触发错误（几个 10s 复位）。 这强烈表明硬件组件导致了此行为。

我们已经审查了我们的硬件设计、没有发现任何明显的问题。 我们的射频部分通常更棘手、在我们的实验室进行了验证、并表现出出色的性能。  CC2340R5 硬件设计比之前的 CC13xx/CC26xx 系列更简单、 我们对此提供了更多的经验。 也许与晶体或振荡器相关的一个微妙问题会影响 RNG 用于种子生成的噪声？ 有什么想法如何验证它?

关键是、  如果我禁用 RNG 运行状况测试、问题将完全消失 系统运行良好。

下面显示了我使用基于开关示例的代码进行测试的一些证据。  我们的器件是使用 cc2340R5 RGE（而不是 RKP）的定制硬件、因此需要修改示例以定制电路板并更改器件封装（在前一篇文章中可以在 SysConfig 文件头文件中看到）。 除此之外、该示例被修改为仅使用 RNG、而无需调用 ZBoss init（附加了代码）。

我还尝试使用空工程示例作为基础来生成一个更简单的工程、但如果不启用 Zigbee 栈、RNG 会产生无法提供的依赖项、这破坏了我的目标。 现在我放弃了这条路。

下面基于开关示例使用代码的证据。

我可以像我之前说的那样通过连接 debug,触发 bug。 如下所示、当错误被触发时、我无法生成随机位、返回错误“-8"，–8，这“这意味、意味着 RNG 子系统未初始化。

它未初始化、因为 RNGLP3RF_conditionNoise 返回错误代码“-32"</s>–32 “

由运行状况测试失败触发、如以下序列所示：

此处定义了错误“-32"：–32：</s>“

所以我可以 很精确地隔离 bug、但我不知道是什么原因导致它。  能否就我可以从固件方面调查的其他内容提供任何指导？ 哪些硬件方面会影响我们应该验证的 RNG 的运行状况测试？

e2e.ti.com/.../ti_5F00_f3_5F00_main.c

谢谢您、

尊敬的 Tiago：

感谢您提供这份详细的报告、这份报告非常有用。

我们已经审查了我们的硬件设计、没有发现任何明显的问题。 我们的射频部分通常更棘手、在我们的实验室进行了验证、并表现出出色的性能。  CC2340R5 硬件设计比之前的 CC13xx/CC26xx 系列更简单、 我们对此提供了更多的经验。 也许与晶体或振荡器相关的一个微妙问题会影响 RNG 用于种子生成的噪声？ 是否知道如何验证？

您是否已将您的硬件设计提交至 SIMPLELINK-2-4GH-DESIGN-REPONS 以供进一步审查？

我们的器件是使用 cc2340R5 RGE（而不是 RKP）的定制硬件、因此有必要将示例修改为定制电路板并更改器件封装（在前一篇文章中，可以在 SysConfig 文件头文件中看到）。 除此之外、此示例被修改为只使用 RNG、而不调用 ZBoss init（附加代码）。

我以前没有发现。  尽管按下了 100 多次按钮、但我仍然无法重现 CC2340R5RKP 的问题、目前没有要测试的 CC2340R5RGE、但我将在下周尝试找到一个。  您是否尝试过在 CC2340R5 RKP LaunchPad 上使用测试固件？  我也对您注意到的器件型号感兴趣。  您能否确认您参考了 使用 RGE QFN24 封装变体指南、 并且使用了我在过去的回复中列出的 F3 SDK 依赖项版本？

我无法生成随机位、返回错误“-8"，–8，这“这意味、意味着 RNG 子系统未初始化。

它未初始化、因为 RNGLP3RF_conditionNoise 返回错误代码“-32"

我会将此信息传递给 SW 和 Radio R&D 以供进一步审查。

此致、
Ryan

嗨、Tiago、

我能够复制您在使用 CC2340R5RGE 器件型号而不是 LPS 上提供的 CC2340R5RKP 时描述的行为。  我将继续在内部与研发团队合作以解决此问题、并在有更新时返回报告。

此致、
Ryan

您好、Ryan、

这是个好消息！ 非常感谢您的更新和复制问题的管理。

这是一个巨大的解脱,知道它是在你的端重复

我们期待着您和研发团队提供的最新信息。

此致、
Tiago