[参考译文] TMS320F280034：无法在引导加载程序后擦除闪存

您好！

空白检查似乎失败。 扇区未正确擦除。

您能否分享  oFlashStatusWord 中的值？

谢谢、此致、

Rajeshwary

尊敬的 Rajeshwary：

请检查以下数据：

你(们)好

您是否 仅擦除扇区6 (0x96000)？

在您的共享屏幕截图中、我看到  Fapi_doBlankCheck 在地址0x97000 (即下一个扇区(扇区7)的开头)发生故障。 扇区8KB_u16长度是多少？

谢谢、此致、

Rajeshwary

尊敬的 Rajeshwary：

应用使用0x90000~0x97FFF。 它们在引导升级失败后执行逐扇区擦除操作。
此故障只是 擦除0x97000扇区故障、因为该扇区只有升级后的剩余数据。
我们将扇区大小设置为0x1000、不正确的扇区大小设置应该没有问题。 这是一种大规模生产的过程。

在测试期间、它们擦除扇区 0x96000。 他们批量生产了1000多个器件、发现10个器件出现了此问题。

尊敬的  Rajeshwary：

对此有何建议？

尊敬的 Angela：

我检查您发布的代码片段、认为是正确的。  我看到 示例函数放在 RAM 中、不确定 API 库是否放在 RAM 中。

您能否确认 闪存 API 是否从 RAM 执行？ 您能否共享链接器命令文件以供查看？  

谢谢、此致、

Rajeshwary

尊敬的 Rajeshwary：

所讨论的那样构建一个完整的模型。 以下是客户重现问题的步骤：

1.禁用 Uniflash 中的自动 ECC 功能。  

2.使用 Uniflash 将数据写入目标扇区

3.使用引导加载程序模拟和使用 Erasing 功能,会出现错误。

提示：  

Erroe 函数: Fapi_doBlankCheck()

客户可以轻松地在 EVM 上重现此问题。 仅当启用自动 ECC 时、才会出现1~2%故障率。  

引导加载程序位于0x88000~0x8FFFF 中、APP 数据位于0x90000~0x97000中。

客户建议的以下 TI 擦除和写入功能如下所示：

#pragma CODE_SECTION (3054 Flash_Erase、".TI.ramfunc")；
静态 bool Flash_Erase (uint32_t 扇区地址)
｛
Fapi_Status 3044返回检查；
Fapi_Flash 4.70类型 oFlashStatus;
Fapi_Flash 4.70 WordType oFlashStatusWord;

oReturnCheck = Fapi_issueAsyncCommandWithAddress (Fapi_Erase 3872、(UINT32 *) SectorAddr)；

while ( Fapi_checkFsmForReady() Fapi_Status_Fsm );

if ( oReturnCheck != Fapi_Status_Success )
｛
返回 false；
}

oFlashStatus = Fapi_getFsmStatus ()；
if (oFlashStatus !=0)
｛
返回 false；
}

BR、

Jiaqi Wang

尊敬的 Jaiqi：

感谢重现问题的详细步骤、我需要一些时间来审查并回复您。

谢谢！

Rajeshwary

尊敬的 Rajeshwary：

您是否有关于此案例的一些更新？  

BR、

Jiaqi.

尊敬的 Jiaqi：

我今天将检查这一点并向您通报最新情况。 我正在处理一些紧急问题。

此致、

Rajeshwary

尊敬的 Jiaqi：

在客户代码中、 PAGE_SIZE 设置为0x1000 (扇区中的字节)、输入以空白检查 API、长度如下所示。 由于空白检查函数使用32位长度、因此用户应提供0x800作为扇区大小。 这样可以解决该问题。

oReturnCheck = Fapi_doBlankCheck ((UINT32 *) SectorAddr、PAGE_SIZE、&oFlashStatusWord)；

客户 正在按扇区擦除 IT 扇区、并在每个扇区后执行空白检查。 但是为空白检查提供的长度超过了扇区大小。

谢谢、此致、

Rajeshwary

你好、Angela、Jiaqi、有任何更新吗？