[参考译文] CCS/CC2652P：程序进入不可预期的 while ()循环

您好、Kimi、

您的 NV 部分可能由于某种原因而损坏。 在测试中、它们是否控制软件的状态、或者它是否在侧面自由运行？

虽然您可能会中断、但在此之后、我无法对 NV 状态进行任何描述、您很可能希望对其进行清理并尝试再次手动恢复(因为它似乎无法根据 while 锁定自行恢复)。  

您好、Kimi、

 在 NV 页压实完成但擦除 PGXSRC 页之前或确定了另一个意外页面状态值后、可能会由于电源位置而发生 NVOCMP_RECORE_ERASE：

#if (NVOCMP_NVPAGES！= NVOCMP_NVONEP)
否则 if (noPgXsrc)
｛
//在压实过程中断电
if (noPgXdst)
｛
操作= NVOCMP_RECORE_COMPACT；
｝
//完成压实操作后、但擦除 PGXSRC 页面之前断电
其他
｛
操作= NVOCMP_RECORE_ERASE；
｝
｝
否则 if (noPgXdst)
｛
操作= NVOCMP_NORY_RESUME；
｝
否则 if (noPgAct || noPgFull)
｛
操作= NVOCMP_RECORE_ERASE；
｝ 

您能否确定以下哪种情况适用？

此致、
Ryan

您好、Ryan、

它首先达到"action = NVOCMP_RECORE_ERASE；"

您好、Kimi、

最近对 NVOCMP 驱动程序进行了一些更改、可以解决此问题、请使用以下 nvocmp.c 文件进行评估：e2e.ti.com/.../nvocmp.c

 您能否在出现问题时提供 NV 闪存捕捉？  这将帮助软件开发团队进一步确定确切的问题。

此致、
Ryan

您好、Ryan、

我能否直接替换 nvocmp.c？

请告诉我如何读取 NV 部分闪存。 谢谢你

您好、Kimi、Ryan、

我已验证新的 nvocmp.c 它看起来工作正常。 下面列出我的测试。

硬件：

一个 CC2652 Launchpad (用 zc_light_CC26x2R1_LAUNCHXL_tirtos_ccs 刷写)
一个 CC1352P-2 launchpad (使用 zed_sw_CC1352P_2_LAUNCHXL_tirtos_ccs 刷写)
还使用一个 CC2531软件狗监听 Zigbee 数据包(带 Ubiqua)

一个电源。

测试步骤：

1.为 CC2652 Launchpad 和 CC13352P-2 Launchpad 加电。
2.让 CC1352P-2加入 CC2652
3.在 CC13352P-2 Launchpad 上、移除 XDS110和 CC1352P 之间的所有跳线。 使用电源连接 CC13352P-2 Launchpad 的3V3、GND。
4.为 CC13352P-2 Launchpad 加电(将电源设置为3V)
5.将电压(每1~2秒0.1V)从3V 缓慢降低至1.9v。 (fron 监听、CC1352P 不发送数据包)
6.等待大约3~5分钟
7.慢慢地将电压从1.9V 增加到大约3V
=>如果发生问题、即使电压高达3V、CC1352P 也无法发送数据包
8.重复5~7

使用旧的 nvocmp.c、问题可能会重现5次。
使用新的 nvocmp.c、我测试了20多次(超过3小时)、但仍然无法重现问题。

Jerry Kuo 由于您可以在 LaunchPad 上重现此问题、因此您能在 问题发生时根据 Ryan Brown1的要求提供 NV 闪存捕捉吗？

这基本上需要在问题发生后读出 NV 闪存区域的存储器、但由于修改后的 nvocmp 文件似乎解决了问题、因此无需进一步调查。

此致、
Ryan

您好、Ryan、

坏消息、替换文件后、我们执行相同的测试。 有时、器件不会重新加入(不发送信标)事件执行 Zstackapi_BdbResetLocalActionReq (它应该在我们的应用中发送信标)。 但 LED 和按钮是否正常工作？ 你有什么建议吗？ BTW。 复位后是否可以保持调试模式？ 谢谢你

您好、Kimi、

从您的描述中可以看到、器件不再被捕获在 while 环路中、但在重新启动时仍然存在 NV 损坏。  此时是否可以进行任何无线电活动？  在此状态期间、您是否能够提供闪存内容？  您可以通过选择 Debug Configuration -> Program -> Load symbols Only inside of CCS 来调试正在运行的目标。

此致、
Ryan

您好、Ryan、

我们在重新启动时不添加应用程序、我们遵循 ZStack。

在我的测试中。 ZED 加入 ZC 时

正常情况：重新启动 ZED，程序输入 zcl_samplesw.c --> zclSampleSw_ProcessCommissioningStatus()--> BDB_TUSIONING_parent_lost

NG 案例：  重新引导后，程序不会输入 zclSampleSw_ProcessCommissioningStatus()--> BDB_Tinationing_parent_lost。 我们尝试 通过 Zstackapi_BdbResetLocalActionReq()使器件"新建"。 复位后，我们使用 Zstackapi_BdbStartCommissioningReq()加入新的 ZC，但我们看不到来自 ZED 的信标

e2e.ti.com/.../8015.20200316_5F00_noRF.zip

感谢您提供器件的存储器内容、我将邀请我们的 NV 驱动程序专家检查是否存在不一致之处。  我假设使用0x52000的默认 FLASH_NV_BASE 和0x4000的 FLASH_NV_SIZE？  该器件是否没有任何无线电活动、是否与您的其他 E2E 帖子相关？   https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/888891 

此致、

Ryan

您好、Ryan、

我们不更改 FLASH_NV_BASE (0x52000)和 FLASH_NV_SIZE (0x4000)。 我在 zcomdef.h 中添加了多个客户 NV 定义(如下所示)

// NV 项目 climax 专有
#define ZCD_NV_factory_reset 0x02FE

//气候定义

#define ZCD_NV_FOL_INPUT_TIME 0x0303
#define ZCD_NV_INPUT_LEVEL 0x0304
#define ZCD_NV_Work_MODE 0x0305
#define ZCD_NV_OUTPUT 电平0x0306
#define ZCD_NV_IAS_CIE_ADDRESS_ID 0x0307

#define ZCD_NV_POLL_CONTRAL_CHECK_IN_INTERVAL 0x0308
#define ZCD_NV_POLL_CONTRAL_LON_POLL_INTERVAL 0x0309
#define ZCD_NV_POLL_CONTRAL_SHORT POLL_INTERVAL 0x030A
#define ZCD_NV_POLL_CONTRAL_FAST_POLL_TIMEOUT 0x012B

关于射频活动、我将在另一篇文章中回复。 也许它们是同一个问题、但我们无法确认。

在这篇文章中、我们看到 NV 贴片后没有射频活动。 但另一篇文章使用旧程序(无 NV 补丁)

您好、Kimi、

我看不到您提供的闪存内容有任何问题。  这是在其断开状态期间导出的、对吧？  另请提供器件工作状态下的存储器导出、以便我们可以对其进行比较。

由于原始问题已得到解决、我认为我们可以继续讨论另一个线程上的射频通信。  如果有任何进一步的 NV 损坏证据、我们将继续此主题。

此致、
Ryan

您好、Ryan、

我为您提供3个文件(新程序、加入网络并正常工作、无射频活动)

e2e.ti.com/.../20200318_5F00_CC1352P-NV.zip

好的、我将在另一篇文章中更新 RF 活动问题。

您好、Ryan、

您是否对我的最后一个闪存文件的存储器导出有任何响应？

您好、Kimi、

软件开发团队正在继续分析/评估、但根据另一个 E2E 主题的调查结果、不存在 NV 损坏的问题。

此致、
Ryan

出现问题时，他们要求提供“NVOCMP_nvHandle”内容。  使用 CCS 调试、您可以从 CCS 的"Expressions"窗口中查看它、否则、您必须找到该变量并从该变量中保存46个字节。

此致、
Ryan

您好、Ryan、

好的、当我获得数据时、我将更新数据。

您好、Ryan、

以供您参考