[参考译文] CC2640R2F：为什么我的 SNV 读取发生了意外失败(即 OSAL_SNV_READ 返回错误状态)？

您好、Keron：

感谢您与我们联系。 您能否提供更多有关如何使用 SNV 的信息？ 读取/写入的频率如何？ 在发现问题之前、您执行的写入/读取总量大约是多少？ 如果 SNV 的内容在损坏后写入、数据是否会保持稳定一段时间？

此致、

1月

大家好、Jan、

感谢您的答复。

读取/写入的频率如何？ 在发现问题之前、您执行的写入/读取总量大约是多少？

我们正在使用 SNV 将一些需要大约每6个月一次的大型组件存储在闪存中。 这些组件使用4个不同的 SNV ID、总共占用大约1KB 的空间。 这些组件在器件的使用寿命期间只能写入一次、但我们依赖于它们可以在任何给定的时间从 SNV 中读取。 我猜测、在我们看到 OSAL_SNV_READ 返回错误状态的问题之前、这些组件仅从 SNV 读取了大约10次。  

如果 SNV 的内容在损坏后写入、数据是否会保持稳定一段时间？

是的、我做了一些 AD hoc 测试、可以确认如果 SNV 在损坏后被写入、数据确实会在一段时间内保持稳定。

我想知道在 SNV 定期压实作业期间是否出现了问题(例如、可能存在某种比赛条件或与功率相关的问题)。 TI 是否曾观察到任何 可能导致 SNV 内容损坏(或擦除)的软编程问题？

谢谢。

克龙

您好、Keron：

您好、感谢您提供更多信息。 这是可能的,这可能是由于软实力,但我发现它有点不太可能,因为它似乎你只写一次,并能够进行几次成功的读取之后。 如果我没有弄错、则会在写入后发生压降。

作为快速测试、您可以加快读取速度吗？ 您能否设置自己的项目、而不是每6个月执行一次？ 我想看看是否能够以更压缩的时间刻度重现该行为。 这将极大地帮助我们进行调试。

此致、

1月

大家好、Jan、

我创建了一些 AD hoc 测试代码、该代码更频繁地调用 osal_SNV_read (每秒一次)、然后我运行该代码12分钟。 这相当于720次读取。 读取 SNV 内容时没有问题。 我将继续让代码隔夜运行、看看是否出现任何问题、但到目前为止还没有问题。

我倾向于认为这个问题与软编程有关、因为 BLE 堆栈在后台执行一些 SNV 写入、无需应用程序级干预。 例如、"最近最少使用"绑定条目、它会在每次对等设备通过 BLE 连接时更新。 也许这些在引擎盖下面发生的 SNV 写入会触发周期性压降、最终失败。 我们是否可以通过任何方式离线上报此问题的调查？ 能够以可靠的方式访问 SNV 内容对于我们的产品的成功运行至关重要。

谢谢。

克龙

您好、Keron：

抱歉、您是对的。 我不知道器件在 SNV 运行的同时进行了键合和连接。 正确、运行时生成的任何绑定都将存储在 NVS 中、这可能会导致随着时间的推移而发生压缩。 您是否估计了债券的制作频率以及随着时间的推移,债券的制作频率如何?

请告诉我隔夜测试的结果。 这可以帮助我们缩小行为的来源。

此致、

1月

大家好、Jan、

您是否估计了债券的制作频率以及随着时间的推移,债券的制作频率如何?

我们每6个月只发行1-2笔债券,并不经常这样做。 但是、即使未形成新的键合、我的理解是、SNV 会在每个 BLE 上编写 重新连接 (例如，要更新最近最少使用的债券索引；请参见  gapBondMgrUpdateLRuBondList())。 因此、考虑到在我们的器件的生命周期内可能发生数百甚至数千次重新连接、一旦达到 SNV 页面结束、这可能会触发定期压降。

请告诉我隔夜测试的结果。 这可以帮助我们缩小行为的来源。

隔夜运行测试后、器件能够读出 SNV 方面没有问题。

是否可以连接到负责维护 SNV/NVS 驱动器的任何人员？   OSAL_SNV.c compactPage()函数中的代码提到了这样一个事实：可能会发生一些错误，使我们的 SNV 项目损坏。 请告知。

谢谢。
克龙

您好、Keron：

您好、感谢您提供更多详细信息。 你是对的,我没有意识到你在那段时间进行不断的重新连接。 我计划提交一份有关此行为的 TT、以提供给研发团队。 我看到您在使用很久以前发布的2.30 SDK。 最新版本是5.30。 在2.30 SDK 和5.30 SDK 的版本中、提供了许多修复、其中一些修复会影响 SNV。 此行为可能不会在较新的 SDK 上出现。 这是我想要尝试实施能够快速可靠地重现此示例的复制方法的主要原因之一。 这样、我们就可以在较新的 SDK 版本上测试它、而不必等待几个月。

您使用2.30 SDK 而不是最新版本、有什么具体原因吗？

此致、

1月

大家好、Jan、

感谢您调查此问题并向研发团队提交请求单。  我刚刚给您发送了一个"请求好友"请求、因为我想通过私人消息与您分享更多详细信息。

谢谢。

克龙