[参考译文] AM62A7-Q1：AM62A OSPI NAND 可确保数据可靠性

您好、

请允许我在某个时候提出解释。

谢谢、

Vaibhav

Vaibhav、

还不清楚块中是否有一些数据存储。 但是,何时会出现坏块,此时会发生什么? 像在那个时候数据将丢失或它将复制到下一个良好的块?

您好、

请允许我再向您提供详细的细目。

此致、

Vaibhav

嗨、Kangjia、

在进一步阅读之前、请注意以下事项：

在写入和擦除周期中会发生坏块。 读取操作不会导致错误的块。

在此注意事项中、我假设执行一个过程、其中二进制文件首先写入闪存。 这是通过一个简单的 UART uniflash 过程实现的。

让我们选择 3 种方案：

目标：在偏移 0xOFFSET 处刷写二进制文件。 假设 0xOFFSET 位于块 5、并且 ROM 需要从该刷写的二进制文件中引导。

• 第一个场景：
  块 5 很好、二进制文件正确刷写到同一个块。 现在 ROM 将从块 5 正确引导。
  
  
• 第二个场景：
  块 5 已经很糟糕、因此二进制文件会刷写到下一个良好块（假设块 6 是下一个良好块）。 现在、当 ROM 启动时、它期望二进制文件位于块 5、但由于它知道块 5 损坏、它会选择下一个良好的块来引导、在本例中为块 6。
  
  
• 第三种场景：
  在这种情况下、块 5 正常、但在写入二进制文件时假设块 5 出现故障、则写入操作将失败、因此。

这是否涵盖了客户所需的详细信息？

此致、

Vaibhav

尊敬的 Vaibhav：

感谢您的答复。

今天、客户与 GD 供应商讨论了在异常情况下对 NAND 相关问题的支持。 对于正常情况、它们可以支持不良的块管理。 如果突然断电（由于客户的项目仅支持 K15 电源，并且软件在意外断电期间无法接收相应的信号）、如果之前进行了闪存擦除/写入操作（例如固件升级，EDR 或日志写入）、则可能会导致数据区域中的数据损坏。 GD 提到、这种情况需要系统级软件支持。

因此、客户询问我们是否有此方案的解决方案？ 当前的电路板没有基于电容器的缓冲解决方案。

谢谢、

Kevin

尊敬的 Kevin：

如果突然断电（由于客户的项目仅支持 K15 电源，并且在意外断电期间软件无法接收相应的信号）、如果之前进行了闪存擦除/写入操作（例如固件升级，EDR 或日志写入）、则可能会导致数据区域中的数据损坏。 GD 提到、这种情况需要系统级软件支持。

让我分析一下、稍后再联系您。

此致、

Vaibhav

（如果之前有闪存擦除/写入操作（例如固件升级，EDR 或日志写入）

请告诉我写入过程是通过 TI 提供的 UART Uniflash 脚本执行、还是使用 JTAG、Gang 编程器等外部工具？

尊敬的 Vaibhav：

我首先要详细说明使用场景：这是指设备已安装的场景、在客户的使用过程中、由于写入日志、EDR 或 FOTA 升级时突然断电、会发生逻辑错误块。 系统具有自愈功能来解决这些问题。 这不是涉及手动连接到串行端口或 JTAG 接口的情况。

谢谢、

Kevin

尊敬的 Vaibhav：

从下面的主题最后一句中可以看到、我们为 OSPI/QSPI NAND 提供了片上 ECC 支持。 我是否知道此 ECC 如何工作？它是否可用于解决断电情况的问题？ 您是否认为即使我们支持 ECC、“超级电容器“仍然是必需的吗？

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1467194/am625-enable-gpmc-nand-ecc-and-bad-block-for-gpmc-nand-chip-in-sdkla-v10-01-10-04/5632464?

谢谢、

Kevin

尊敬的 Vaibhav：

我们今天再次与 GD &客户讨论、深入探讨在突然断电的情况下的坏块保护。

GD 提到在突然断电的情况下、页面/块是否被标记为坏块由 SoC 端决定。 因此、GD 和客户需要 TI 提供了一个特定的逻辑来说明我们如何标记坏块。 但是、从我们的常见问题解答中可以看出、我们只根据第一页 128 字节备用区域的值（如果是 oxff）判断块是否为坏块。 我们没有提到如何标记或者在哪种情况下将 0xff 更改为不同的值。

因此、我是否可以知道、当发生坏块时、NAND 闪存硬件本身会将第一页备用区域更改为 0xff 以外的值、SOC 没有正确？

谢谢、

Kevin

[引述 userid=“546457" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1518631/am62a7-q1-am62a-ospi-nand-ensure-data-reliability/5891305 #5891305“]

我们今天再次与 GD &客户讨论、深入探讨在突然断电的情况下的坏块保护。

GD 提到在突然断电的情况下、页面/块是否被标记为坏块由 SoC 端决定。 因此、GD 和客户需要 TI 提供了一个特定的逻辑来说明我们如何标记坏块。 但是、从我们的常见问题解答中可以看出、我们只根据第一页 128 字节备用区域的值（如果是 oxff）判断块是否为坏块。 我们没有提到如何标记或者在哪种情况下将 0xff 更改为不同的值。

因此、我是否可以知道、当发生坏块时、NAND 闪存硬件本身会将第一页备用区域更改为 0xff 以外的值、SOC 没有正确？

[/报价]

尊敬的 Kevin：

请允许我就此发表意见。

此致、

Vaibhav

尊敬的 Vaibhav：

GD Double 通过确定块发生的位翻转超过 ECC 纠错功能、或者无法被擦除或写入来确认我们的 SOC 在操作期间识别了坏块。 在这种情况下、数据块被视为不可靠的数据存储、并被标记为坏块。

因此、客户想知道、如果在 OTA 期间、在块内写入某些页面时发生断电（这意味着写入过程尚未完成）、SOC 会将其标记为坏块吗？

谢谢、

Kevin

尊敬的 Vaibhav：

更具体地说、当我们写入 NAND 闪存时、我们的 SOC 会对块内的每个页面进行 ECC 校验、或者我们只在一个块中写入所有页面后进行 ECC 校验。 问题是当断电情况发生时、我们更有可能正在写入一个页面、块中仍有一些页面尚未写入。 如果我们对我们编写的每个页面进行 ECC 检查、那么我们更有可能将坏块标记为正确的位置？

谢谢、

Kevin

尊敬的 Karan：

感谢您的详细说明、我们现在已经理解了。

根据这些信息,我们知道,当我们正在写入的块变为坏,我们将写入下一个好块,但下一个好块可能已经有一些数据,因此覆盖将发生。

如果理解正确、那么如果客户使用 NAND 闪存并且需要 OTA、则客户可能需要为每个 SW 组件保留额外的备用空间？ 因为如果 NAND 闪存中的两个 SW 组件/映像地址彼此非常接近、那么覆盖的情况可能会影响下一个良好的 SW 映像。

然后、在考虑此情景时、我们是否向客户提供了一些建议？ 与汽车项目一样、通常需要 OTA、我们发现 NAND 闪存更具成本效益、这可以节省 BOM 成本并使我们更有竞争力地赢得该项目。

谢谢、

Kevin

尊敬的 Kevin：

如果理解正确、那么如果客户使用 NAND 闪存并且需要 OTA、客户可能需要为每个软件组件保留额外的备用空间吗？ 因为如果 NAND 闪存中的两个 SW 组件/映像地址彼此非常接近、那么被覆盖的情况可能会影响下一个良好的 SW 映像。

是的,查找下一个要写入的好块的过程不会检查好块是否是空闲的。 因此、系统集成商在设计 NAND 闪存的存储器布局时、需要使用“几个“块（取决于可接受的坏块数量，闪存等级，固件大小要求等）进行填充。

用于查找下一个良好模块的函数： https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/board/flash/ospi/flash_nand_ospi.c#L1634 

此致

Karan

尊敬的 Karan：

感谢您提供这些详细信息、我已与客户讨论过、在大多数情况下、填充少量块将起作用、但可能存在一种特殊情况、这可能仍有一些问题。

良好的抗噪性能

客户重新刷写整个软件映像、例如、软件映像将被写入块 1-10、块 5 是坏块、然后根据我们的坏块管理逻辑、我们将实际写入块 1-4 和 6-11。 然后、如果客户在设计中填充块 11、则不会有任何问题。

阻尼比值

有一个 SW 组件或一些重要数据已经保存在块 1-4 中、在运行时、客户可能只更新部分重要数据、比如重新写入块 3、然后如果发生坏块、根据我们的坏块逻辑、块 4 将被覆盖、这种情况下似乎填充了几个块方法不起作用。

客户与我讨论过,为了解决上述特殊情况,我们可以修改我们的坏块管理逻辑一点,每次我们试图写一个新的好块,我们检查它是否为空,直到我们找到空块。6.

但是、我认为如果我们修改这样的逻辑、它会影响上述“在大多数情况下“结果、因为我们将写入最初写入块 5 的数据的块 11、而块 6 数据将写入块 12。

“你怎么知道的?“

谢谢、

Kevin

尊敬的 Kevin：

阻尼比值

有一个 SW 组件或一些重要数据已经保存在块 1-4 中、在运行时、客户可能只更新部分重要数据、比如重新写入块 3、然后如果发生坏块、根据我们的坏块逻辑、块 4 将被覆盖、这种情况下似乎填充了几个块方法不起作用。

客户与我讨论过,为了解决上述特殊情况,我们可以修改我们的坏块管理逻辑一点,每次我们试图写一个新的好块,我们检查它是否为空,直到我们找到空块。6.

但是、我认为如果我们修改这样的逻辑、它会影响上述“在大多数情况下“结果、因为我们将写入最初写入块 5 的数据的块 11、而块 6 数据将写入块 12。

“你怎么知道的?“

[/报价]

我了解特殊情况/边缘情况。 请允许我在某段时间内再回到这个问题来解释一下。

此致、

Vaibhav

尊敬的 Vaibhav：

有任何进展要分享吗？ 我们将与我们的营销团队此星期三现场客户讨论此问题。

Kevin

尊敬的 Kevin：

当前 SDK 流程如下：

请注意、如何使用对块 3 进行的更新覆盖第 4 个块。 因为块 3 坏了、所以我们写入块 4、因为块 4 好。

目前在 SDK 中、我们不会检查我们要写入的块是否已经刷写了一些二进制文件。 客户应注意这一点。

因此、客户端的实现应该只是添加一个检查下一个块是否良好、并且还没有刷写的二进制文件、因此我们写入它。

此致、

Vaibhav

尊敬的 Vaibhav：

感谢您的答复。

根据上述情况、如果客户添加了检查下一个块是否正常、并且已经没有刷写的二进制文件。 然后、第 4 个出错的块将被写入块 6。 然后、我们写入下一个数据、将其写入块 7 还是块 4？

根据这一理论、如果客户想要重新刷写涵盖块 0 到 99 之间的映像、那么客户必须在刷写新映像之前擦除原始映像？ 如果客户没有执行此操作、那么一旦中间出现了坏块、并且客户执行了 检查下一个块是否良好、并且没有刷写二进制文件、那么新映像不会完全写入原始映像。

谢谢、

Kevin