[参考译文] CC2340R5：询问具有 HFXT 的 CC2340 中 CKM_01 勘误表和待机处理的重要性 (simplelink_lowpower_f3_SDK_8.40.00.61)

您好、

感谢您联系我们。  9.10 SDK（以及更高版本）中包含了 CKM_01 的修复程序。 请迁移到最新的 SDK、或者至少迁移到 9.10 SDK、以便修复该问题。

除非在非常有限的情况下、否则不应修改 standbyPolicy 功能是正确的。 此处无需修改即可解决错误、仅迁移到 9.10 或更高版本的 SDK。

您能否说明您如何将 HFLOCKCTL 设置为在您身边启用、以及您如何检查 TRACKREFLOSS 和 HFXTFAULT？  TRACKREFLOSS 和 HFXTFAULT 都为高电平有点奇怪、因为这会指示出现问题、但通常如果这些为高电平、则器件会复位。

此致、

1 月

尊敬的 Jan：

感谢您对 CKM_01 错误的支持和说明。

我还有一个关于即使存在外部 48MHz 晶体 (HFXT) 时跟踪变得不可用时可能产生的影响的其他问题：

• 如果器件以 HFXT 运行时跟踪失败（例如，TRACKREFLOSS 置为有效）、则系统运行中的预期问题是什么？
• 具体而言、如果在无线通信期间发生这种情况（例如，正在进行蓝牙连接）、则连接是否会因此而丢失或变得不稳定？
• 跟踪丢失后、在重置或下电上电之前、器件是否可能无法重新连接或启动新的无线连接？
• 是否有任何安全的方法可以从跟踪故障中恢复正常运行而不对器件进行复位/下电上电？

对于此方案的影响、处理或可能的恢复步骤、请提供任何意见或文档参考、我们将非常感激。

再次感谢您的帮助。

此致、

尊敬的 Kei：

让我和我们的硬件专家一起谈谈硬件方面的问题。

此致、

1 月

您好、Jan、

非常感谢您的支持。

请问是否有任何关于您在上一封邮件中提到的硬件专家的答案的更新？
如果可能、您能否提供我预计何时会收到回复的预计时间表？

感谢您的持续帮助。

此致、
Kei

尊敬的 Kei：

我将研究这一点、并在明天为您提供答案。

此致、

按钮

尊敬的 TI 支持部门：

我收到了合并 SDK 9.10 的相关更改以解决 CKM_01 错误的建议、我已经调查了这些差异。
 PowerCC23X0_enterStandby 在 SDK 9.10 中、的实现似乎已更改、这可能是解决该问题的关键更新。

1.  PowerCC23X0_enterStandby() 为了解决 CKM_01 错误、将更新的函数（以及任何相关更改）从 SDK 9.10 反向移植并集成到 SDK 8.40 是否足够？
2. 如果我尝试仅反向移植此函数、是否还应更新 SDK 或依赖项的任何其他部分以确保安全操作？

我已经尝试 PowerCC23X0_enterStandby 将新的集成到我现有的基于 SDK 8.40 的工程中（使用 CCS）、但更改似乎没有生效、生成的十六进制文件保持不变、修改的函数（如） Power_init 似乎也不会对编译输出产生任何影响。

• 您能给出一些步骤来确保此类修改后的函数在编译中实际使用/包含在编译中吗？
• 是否需要进行任何工程或 CCS 配置更改以确保正确构建和链接自定义或反向源代码、而不是原始 SDK 库？

对于有关如何在 CCS 构建环境中应用和验证这些修改的任何指导、以及有关从较新 SDK 选择性回退的任何最佳实践或注意事项、我将不胜感激。

非常感谢您的帮助。

此致、
Kei

此外、我想在基于 FreeRTOS 的软件中确认关于任务暂停和待机进入的一点。

在我的应用中、我在任务中使用以下语句触发系统进入待机模式：

ulTaskNotifyTake( pdFALSE, portMAX_DELAY );

据我所知、当使用此机制且器件转换到待机模式时 PowerCC23X0_enterStandby 、将调用该函数以实际处理 SoC 的待机进入情况。

我的理解是否正确、在 FreeRTOS 项目（使用 SimpleLink SDK）中、像这样通过任务暂停进入待机模式最终会导致调用 PowerCC23X0_enterStandby？
如果有任何其他注意事项或例外情况、请告知我。

尊敬的 Kei：

如果在使用 HFXT 时跟踪失败、则无线电通信将停止、因为它的时钟源自 HFXT。

如勘误表中所示、解决方法在 SDK 9.10 版本中实现。

此致