[参考译文] CC2652R：NV 写入时间歇性重新启动

尊敬的 Grant：

我记得您5个月前的主题： https://e2e.ti.com/f/1/t/1233083 

如何知道在 调用 SysCtrlSystemReset 之前器件已复位？  您能否在意外使用期间调试器件、以便在器件复位之前进一步确定调用堆栈？  您甚至可以使用打印日志来进一步证明应用程序状态 以及不使用看门狗。  请在这两条命令之间插入一个延迟、基本上是 NV 写入和系统复位、因为故意连续执行这两个操作是危险的。  这就是为什么 bdb_resetLocalAction 在将 NV 复位为出厂新内容后延迟500ms 的原因。  您还应该能够使用 osal_nv_write 或 nv 驱动程序函数指针 (即 NVINTF_nvFuncts_t * pfnZdlNV)来代替  zclport_writeNV、鉴于 v4.20 SDK 的使用寿命、很难记住。

此致、
瑞安

Ryan Brown1 -我是格兰特的同事,也参与了这个问题。  格兰特本周正在旅行、回复速度将较慢。  一个观察结果、然后我有一个问题。   

观察结果是、NV 写入与测试授权正在运行中的系统复位之间存在固有延迟-在 NV 写入尝试设置新通道值后、由基于云的控制器应用程序发送系统复位。  我们将检查其时间安排、这是一个很好的提醒、但通常情况下它不是彼此重叠进行。  其他方面也在发生。

这会引出我的问题。  我们的看门狗计时器间隔相对较短、用于保持系统交互和数据流动(45秒)。  在 ZStack 文档中、我读到了 NV 写入如何工作、偶尔需要在对新位置进行写入时"收回"未使用的位置、而更改了 ID 方案使用的指针。  这似乎偶尔,人们会看到"压缩"的事情。  这种内部重组通常需要多长时间、它是否会导致 NV 写入调用的时间发生变化？  在其他论坛帖子中似乎只是对此略有提示、其中闪存操作在时间上可能会有很大差异。  我们试图制定更多可以测试和排除的条件。  提前感谢您可能有任何建议。   

马克·马德森

华泰克株式会社

尊敬的 Mark：

您可以在 osal_nv.c 中找到 compactPage 和 compact_page_cleanup 的用法、然后使用进一步调试或打印日志来跟踪使用情况并确定它是否与看门狗冲突。  为了进行测试、您还应该尝试在写入 NV 之前立即重启看门狗定时器、或通常增加看门狗间隔。  功能注释中详述的压实故障存在明显的风险、如果您可以验证您的系统是否发生了这种情况、则必须对其进行进一步调查。

/******************************************************************************
 * @fn      compactPage
 *
 * @brief   Compacts the page specified.
 *
 * @param   srcPg - Valid NV page to erase.
 * @param   skipId - Item Id to not compact.
 *
 * @return  TRUE if valid items from 'srcPg' are successully compacted onto the 'pgRes';
 *          FALSE otherwise.
 *          Note that on a failure, this could loop, re-erasing the 'pgRes' and re-compacting with
 *          the risk of infinitely looping on HAL flash failure.
 *          Worst case scenario: HAL flash starts failing in general, perhaps low Vdd?
 *          All page compactions will fail which will cause all osal_nv_write() calls to return
 *          NV_OPER_FAILED.
 *          Eventually, all pages in use may also be in the state of "pending compaction" where
 *          the page header member OSAL_NV_PG_XFER is zeroed out.
 *          During this "HAL flash brown-out", the code will run and OTA should work (until low Vdd
 *          causes an actual chip brown-out, of course.) Although no new NV items will be created
 *          or written, the last value written with a return value of SUCCESS can continue to be
 *          read successfully.
 *          If eventually HAL flash starts working again, all of the pages marked as
 *          "pending compaction" may or may not be eventually compacted. But, initNV() will
 *          deterministically clean-up one page pending compaction per power-cycle
 *          (if HAL flash is working.) Nevertheless, one erased reserve page will be maintained
 *          through such a scenario.
 */

此致、
瑞安