[参考译文] MSPM0G3107：MSPM0G3107SDGS20 闪存问题

尊敬的 Daniel：

如果在 ECC 区域中读取了具有不正确 ECC 代码的代码、则会发生 FLASH_DED。 SysCtl->DEDERRADDR 将返回发生错误的内存地址。 如果地址在 MAIN 区域中、请检查存储器在代码中的写入位置。

我收到的文件仅是 SysConfig 配置文件、这里不应该有问题、因为没有闪存写入（bootconfig 文件除外、但如果 NONMAIN 错误，您会遇到其他问题）。

您是否在这些闪存操作期间使用 DMA？ 在 MSPM0G31xx 器件上、它是单组器件、因此您需要使用其中包含 RAM 的闪存函数、因为这些函数将通过 RAM 执行。

在您的器件中唯一不同的区域是 Factory Constants 部分。 Factory Constants 在器件中具有校准数据。

在我们的电路板上添加观察内容、这在可正常工作的电路板和不可正常工作的电路板上都很常见：
在查看原理图时、我们发现 HFXT 晶体上的负载电容感觉很低、需要一个 18pF 范围内的负载电容、此类负载电容由晶体定义。 我们尝试更改为 18pF、当电路板未n´t 甚至开始时。 与其他设计相比、实际测量 CLK_OUT（使用<1pF FET 探头）会显示出相当差的波形。
 HFXTRSEL 的设置目前对我来说不清楚、但应该是 1h 或 2h。  错误的设置是否会导致此结果？ 在这里还有其他的好东西可以钓鱼吗？ 并导致错误的闪光时间?

上传的文件中有更多的照片…
BR/Fredrik

0x1 或 0x2 会改变 MCU 的驱动强度、您处于 2 之间的边界、我想说这取决于电容。

对于您的晶体、负载是多少？  https://www.ti.com/lit/slaa322 是一份介绍晶体注意事项的不错文档；尽管该文档适用于低频晶体和 MSP430 器件、但这些技术是与 MCU 和晶体无关的。 您将在遍布整个行业的不同文档中看到类似的公式、唯一的区别是它们描述寄生电容的方式。  

您通常希望负载电容是晶体数据表中规格值的两倍 (2pF)。 电容器的微小差异会改变晶体的频率。

这是一个 12pF 晶体。 因此预计为 18pF 或 22pF 负载电容。  但这真的会影响我们的 Flash 体验吗?  

您是使用 HFXT 通过 SYSPLL 更改为更高的频率、还是使用外部晶体直接连接到 MCLK？

有 需要根据频率设置的闪存等待状态、如果 HFXT 未稳定或设置正确、您可能会遇到问题。 您可以使用其中一个单元并注释掉时钟配置、看看使用 SYSOSC 是否解决了问题。 如果是这样、您就知道 HFXT 是原因。

它是否可以在出现闪存 DED 错误的其中一个单元上轻松重复？

我也上传了 syscfg 文件、是的、我们使用 SYSPLL 更改为更高的频率。 希望将 syscfg 文件更新为它会映射到  我们昨天上传的生成的 ti_msp_dl_config.c 文件。 我将尝试更 改为使用 SYSOSC。

更改 sysPLLRef 以使用 DL_SYSCTL_SYSPLL_REF_SYSOSC 时   存在同样的问题（并将 pDiv 从 DL_SYSCTL_SYSPLLPDIV_2 更新到 DL_SYSCTL_SYSPLL_PDIV_4、因为 SYSOSC 是 32MHz、我们的外部振荡器在 16MHz 上运行）。

SYSPLL 使用 80MHz 为系统的其余部分计时。

你（们）好 因此、HFXT 似乎不是根本原因、因为问题仍然是使用内部振荡器后的何处。

我们现在还试图降低 SYSPLL 到 40Mhz ( ULP 到 20Mhz ), 2 个等待状态上的闪存,仍然遇到这个问题。

我们上传了有关闪存更新过程和发生的 ECC 错误的详细说明。
请回顾！

现在、我们的想法已经过时了。
这仍然是非常奇怪,我们生产了几千之前的电路板日期码 W40/41 甚至重大问题 W43。
我们是否可以将电路日期代码再次上载到当前 SharePoint？  

如果我理解正确、裸片上的唯一更改/更新是在从 “X"样“样片进行的。 这是什么时候?

尊敬的 Fredrik：

我已在内部与团队分享了包含 W27、W40/41 生产日期代码的设备映像、无需上传。

谢谢、

/Wolfgang

尊敬的 Daniel：

您能否测试这个 0.47uF 电容器是否正好放置在这些可疑电路板上的 MCU VCORE 引脚上？ 并检查 VCORE 上的电压是否正常（约为 1.35V）？

还有为了测试此问题是否与 PCB 硬件或 MCU 器件有关（我认为它与软件无关，因为您在以前的产品和当前产品中有相同的软件程序）、您可以进行 A-B-A 测试、看看如果您尝试更换可疑 个人 和“始终正常“ 人员的 MCU、是否存在问题。 这是为了检查问题是出在有问题的 MCU 还是有问题的 PCB 板上。

我相信 Wolfgan 已经向您分享了 MCU 生命周期检查指南、请帮助我们分享相关信息。 此外、您是否还可以检查可疑设备的 MCU TRACE ID（在地址 0x41C40000 中）的值？ 谢谢。  

尊敬的 Daniel：

另一个问题是、对于可疑器件、您是否看到闪存异常区域具有相同的地址、或者地址有时不同？

例如、如果您将程序下载到 MCU 并读回（该程序不应包括闪存操作，以确保闪存内容在编程前后保持不变）。 您会发现、回读内容与您在可疑器件中编写的内容不相等。 您能否检查损坏的区域地址是始终相同、还是它会在不同编程时间发生变化？

嗨、Pengfel、

我们已经检查了 VCORE、它安装了正确的元件 (470nF)、如下所示：

“良好“的电路板  

“坏“板

我们还将在擦除/刷写时检查

布局如下。 红色 470nF 电容器、过孔直接连接到 GND 平面

我们还完成了交换测试。  换用已知“良好“或 已知损坏的电路板、并执行了交换之前和之后更新软件的自动测试周期（200 次）。
MCU 问题很明显。
现在、我们将使用调试器再次测试擦除 MCU 的情况、并重新测试更新软件、以确保闪存被完全擦除。  

其他结果：
似乎在坏的板上,我们有时不能做一个步骤“擦除程序区域“,一旦该区域被写入一次。
我们的擦除功能非常简单、并且在数千个其他电路板上都可以正常工作。

bool EraseSector（Uint32 扇区）
｛
   bool 结果= true；
   DL_FlashCTL_unprotectSector (Cfg_Instance Flash.handle、扇区* 1024、DL_FLASHCTL_REGION_SELECT_MAIN)；
   DL_FLASHCTL_COMMAND_STATUS cmdStatus = DL_FlashCTL_eraseMemoryFromRAM (Cfg_Instance Flash.handle、扇区* 1024、DL_FLASHCTL_COMMAND_SIZE_SECTOR)；
   if（！DL_FlashCTL_waitForCmdDone( Cfg_Instance．handle ))
       结果= false；
   if (cmdStatus ！= DL_FLASHCTL_COMMAND_STATUS_PASS)
       结果= false；
   返回结果；
}

该函数从不报告失败、但使用更简单的函数回读时、它在所有字节中都不会返回为 0xFF。

Bool CheckIntervalIsErased( const AddressInterval* interval )
｛
   bool 结果= true；
   const uint8* pflash =(const uint8*) interval->startAddr;
   const Uint32 length = interval->endAddr - interval->startAddr;
   for (Uint32 i = 0；i < length；i++)
       if ( pflash[i]！= 0xFF )
           结果= false；
   返回结果；
}

当我们信任 EraseSector 函数并尝试写入我们认为是擦除存储器的内容时、我们会收到 ECC 错误、当然、当擦除失败时写入的数据不正确。 调试器似乎能够在大多数时间擦除闪存。

在某些芯片上、Segger 似乎无法擦除某些扇区。 0x2000 位于引导过程中、在使用“擦除芯片“时仍然保留。 使用“擦除扇区“时会将其擦除、但 0x1F300 有时仍会保留。

这时会出现一个问题、那就是擦除 ECC 奇偶校验位是否有某种时序、锁定或确认要求？ 一个假设是奇偶校验位以某种方式最终阻止擦除。

“坏“电路板的 MCU 跟踪 ID 示例：

地址高：37225204 -> 0x23802F4 (0xF4023802)
地址 Lo：733511727 -> 0x2BB8802F (0x2F80B82B)

 地址：37255342
地址：733511727

地址：5381272
地址：733511727

地址：37231734
地址：733511727

带生产周的主板、W43：

地址：37000949
地址：733511727  

地址：37017804
地址：733511727  

地址：37256370
地址：733511727

Fredrik,

良好输入。 尤其值得注意的是、交换测试表明问题出在 MCU 上。

在您的最后一个帖子,“坏“板是清楚的,但 W43 板是什么 — 那些也“坏“或“好“?

如果上述所有代码都“错误“、您能否分享几个“正常“电路板 MCU 跟踪 ID？

谢谢、

/Wolfgang

尊敬的 Fredrik：

感谢您的重要更新。

发现一些闪存地址不能通过擦除芯片或擦除扇区很好地擦除、这一点很好。 如果我们将数据写入未擦除状态的闪存区域、然后将其读出、则会触发 ECC 错误。 您需要帮助检查以下两项：

• 您是否在 NONMAIN 中配置任何静态写保护？
• Uniflash 是否可以通过批量擦除来擦除闪存区域（如 0x2000 和 0x1F300）？ 您是否找到任何其他不能擦除的地址区域？

 您能否 按照 TI 驱动程序中“MSPM0 Check Lifecycle Steps.pdf“的指导分享 bootcfg 和生命周期寄存器的价值、它需要一个 XDS110 调试器、如果您在这些步骤中遇到任何问题、可以直接在此处连接我。

嗨、Pengfei、

我们已经锁定了在电路板生产过程中填充的第 1 扇区、该领域没有任何问题。

有时、坏芯片最终会进入 Segger 无法回读或擦除闪存的状态、只有 TI 调试器才能恢复闪存。
我们已经在上述地址上观察到未擦除的扇区。 我们已经开始编写压力测试程序来尝试写入、擦除和检查闪存的扇区和段、然后返回结果。

尊敬的 Daniel：

在测试之前、您能否先获取可疑设备的生命周期信息？ 谢谢你。

今天上午、我们通过我们的 EMS 合作伙伴从 TI 得到信息、即 SysPLL 问题_ MSPM0Gxxx 产品存在问题。 由于这就是 TI 的“选择性披露“、我会将此信息更新到 SharePoint
对我们来说,这似乎是相对的?
在这里讨论是可以的吗？

尊敬的 Fredrik：

SYSPLL 问题与 SYSPLL 时钟的频率不正确以及发生的速率非常微小有关。  

由于您通过禁用所有时钟配置并使用 SYSOSC 保持 MCU 运行进行了测试、我认为您所遇到的问题与此 SYSPLL 问题无关。

您能否 按照 SharePoint 中“MSPM0 Check Lifecycle Steps.pdf“中的指南为我获取 bootcfg 和生命周期寄存器值？ 谢谢你。

只是 Segger 调试器没有将 0x2000 擦除到 0x9100 的情况。 已尝试过两次。 使用“擦除扇区“时、闪存也被擦除。
我认为、当我们使用 JTAG 接口时、不应该有任何东西会干扰我们如何设置时钟或通过编程方式设置任何其他内容？ 无论之前设置的软件是什么、MCU 肯定应该使用某种预定义的时钟速度、接口速度等？ 此芯片上没有锁定扇区。

我不是 JTAG 接口方面的专家、但我希望调试器能够发出“批量擦除“、并让 MCU 完全完成。 即使使用调试器（而不仅仅是我们的软件）、这种麻烦的 MCU 也很难擦除、这表明闪存存在异常情况、并且内部擦除命令（如果发生了这种情况）无法每次都执行其操作。 这些操作也必须使用某种时钟？ 还是由调试器硬件计时？

我得到了一块电路板、它无法更新应用程序、并得到了这些值。 都会使用更多的电路板进行测试。
CFGAP_BOOTDIAG = 0x00000007
CFGAP_Lifecycle = 0x00000096

Daniel、

闪存操作在闪存引擎内部计时和管理、不应取决于 JTAG 接口时钟或时序。 一旦由 JTAG 命令启动、闪存操作就是自主操作。

我记得您提到过 Segger 使用目标 VCC、即 3.0V。 连接时、TI XDS110 调试器可提供 3.3V 目标电源、使用调试探针进行刷写时更成功？

您能否尝试使用 Segger 探头像上所述的相同操作、但将 VCC 升高到 3.3V、然后使用（如果有这种影响）？

谢谢、

/Wolfgang

尊敬的 Daniel：

是当 JLink 或 XDS110 等调试器下载固件时、闪存操作程序以默认时钟设置工作、使用 SYSOSC 进行 CPU 操作。 作为替代测试、您是否可以尝试是否为异常器件批量擦除 XDS110 + Uniflash、如下方所示。 请注意、需要在 XDS110 和 MCU 之间连接 NRST 引脚。

对于以下擦除命令、您能否尝试始终应用 DL_FlashCTL_executeClearStatus (..) 在执行任何闪存操作之前？

bool EraseSector ( Uint32 sector )
｛
   bool 结果= true；
   DL_FlashCTL_unprotectSector (Cfg_Instance Flash.handle、扇区* 1024、DL_FLASHCTL_REGION_SELECT_MAIN)；
   DL_FLASHCTL_COMMAND_STATUS cmdStatus = DL_FlashCTL_eraseMemoryFromRAM (Cfg_Instance Flash.handle、扇区* 1024、DL_FLASHCTL_COMMAND_SIZE_SECTOR)；
   if（！DL_FlashCTL_waitForCmdDone( Cfg_Instance．handle ))
       结果= false；
   if (cmdStatus ！= DL_FLASHCTL_COMMAND_STATUS_PASS)
       结果= false；
   返回结果；
}

我们仍然使用 PLL、但由 SYSOSC 而不是晶体提供时钟。 我们是否应该也仅使用 SYSOSC 进行测试？ 可能需要对 CAN 进行一些调优、才能使其正常工作。

尊敬的 Daniel：

该值是否来自异常器件？ 您显示的值表示 MCU 处于正常状态。 如果其他可疑器件也具有相同的 bootdiag 和生命周期值、我认为我们可以更多地关注此问题的硬件或软件配置。

已尝试 在 DL_FlashCTL_unprotectSector 之前添加 DL_FlashCTL_executeClearStatus 命令、但仍然没有成功:-(

我尝试了几个无法更新的电路板、它们都具有相同的生命周期值。
CFGAP_BOOTDIAG = 0x00000007
CFGAP_Lifecycle = 0x00000096

已将批处理代码列表上载到 SharePoint

我们发现、如果重复擦除“有故障“的扇区、则无法擦除闪存的器件可能会成功。 我们遇到很多问题的某个器件在重试 22 次擦除扇区 124 (0x0001F000-0x0001F3FF) 后成功擦除...

尊敬的 Daniel：

并且、您已经在执行闪存擦除操作之前禁用了所有中断、但在此测试中仍然看不到擦除扇区中的所有字节？

尊敬的 Daniel：

您知道单次擦除操作的擦除时间吗？ 例如、我们可以通过在 ERASE 命令之前和之后切换 GPIO 来测量这个时间。  

您好、  
我想总结一下上述问题、以及擦除阶段的 VCC。
n´t 在擦除过程中看到任何骤降。 黄色表示 3.0V、绿色表示 Vcore

感谢您的更新。

当擦除失败时、您能帮助获得以下信息吗？

1.进入异常器件调试模式,尝试对 “故障“扇区执行擦除命令。 API 完成后、检查 flashctl 模式  STATPCNT 、 STATCMD 和 STATADDR 擦除失败时寄存器。

2.给我们 两个屏幕截图 在闪存擦除前后的“故障“闪存扇区上。 我们需要检查 擦除失败的情况。  您的测试程序始终低于代码吗？ EraseSector 返回成功结果、CheckIntervallsErased 返回失败。

bool EraseSector（Uint32 扇区）
｛
   bool 结果= true；
   DL_FlashCTL_unprotectSector (Cfg_Instance Flash.handle、扇区* 1024、DL_FLASHCTL_REGION_SELECT_MAIN)；
   DL_FLASHCTL_COMMAND_STATUS cmdStatus = DL_FlashCTL_eraseMemoryFromRAM (Cfg_Instance Flash.handle、扇区* 1024、DL_FLASHCTL_COMMAND_SIZE_SECTOR)；
   if（！DL_FlashCTL_waitForCmdDone( Cfg_Instance．handle ))
       结果= false；
   if (cmdStatus ！= DL_FLASHCTL_COMMAND_STATUS_PASS)
       结果= false；
   返回结果；
}

Bool CheckIntervalIsErased( const AddressInterval* interval )
｛
   bool 结果= true；
   const uint8* pflash =(const uint8*) interval->startAddr;
   const Uint32 length = interval->endAddr - interval->startAddr;
   for (Uint32 i = 0；i < length；i++)
       if ( pflash[i]！= 0xFF )
           结果= false；
   返回结果；
}

尊敬的 Daniel 和 Fredrik：

抱歉、还有一个问题：

1.除固件更新外,您是否会擦除或编程应用程序中的闪存以进行数据存储?

2.是否认为在执行擦除操作后暂时使用闪存 BLANKVERIFY 命令 (DL_FlashCTL_blankVerifyFromRAM() API ) 检查扇区空白状态是可以接受的、并确保闪存内容在进行进一步编程之前被良好擦除？ 它提供了另一个步骤来验证闪存擦除结果、但会使“有故障“区域的擦除需要更多时间。   

嗨、Pengfei、

这里有两个屏幕截图。 我已更新为 改用 DL_FlashCTL_blankVerifyFromRAM 操作、但仍然存在相同的问题。

在屏幕截图中还为 ECC 校正数据、未校正数据和 ECC 校验和添加了内存监视。

擦除前：

擦除后：

来回答您的第二个问题。 是的、我们也使用两个扇区进行设置。 但我们还没有看到这些部门的问题。 但我们很少在生产后更新这些设置。

尊敬的 Daniel：

非常感谢您的更新。 很抱歉请求更多测试、让我们澄清一下我们需要分析的测试或数据：

1. STATPCNT、 STATCMD 和 STATADDR   擦除后的寄存器值 : 至于你显示的“擦除后“的屏幕截图,你能给一个图片  flashctl  模式  STATPCNT 、  STATCMD  和  STATADDR  在执行“ERASE"命令“命令之后（对于失败擦除情况）？ 对于当前图像、由于应用了 blankverify、因此这些寄存器与 blankverify 命令相关。 （也请告诉我在这种情况下需要多少次擦除才能成功擦除）谢谢。  

2. 失败情况下的擦除时间：  在这种故障情况下（例如，通过启用计时器或切换 GPIO 来测量时间）、您是否可以帮助获得单次擦除的时间消耗（最好测量成功擦除之前的每个擦除时间）？

3. 返回结果  DL_FlashCTL_readVerifyFromRAM64 () API、用于闪存损坏区域 。 （我们看到 ERASE 命令会返回 PASS 结果，空白验证会返回您的上一个测试错误的结果？）。

对于我之前提到的空白验证建议、我的想法之一是采用以下擦除过程：

1. 设置闪存字索引  flashWordIdx = 0 。
2. 对闪存扇区进行擦除。
3. 从闪存字中进行空白验证  flashWordIdx  存储在这个擦除的扇区内。 如果通过空白验证、闪存字索引会增加 1。
4. 如果此扇区中的所有闪存字都通过了空白验证 ( flashWordIdx >= 128 )、然后成功擦除此扇区。 如果是闪存字  flashWordIdx  未通过空白验证、然后返回步骤 2。

这会增加扇区擦除的时间、但请检查它是否是可接受的临时 权变措施。 我们已要求您的团队获取一些故障单元进行分析、但希望检查此方法是否适用于现有产品。

Christer 具有测量的擦除时序：

我们已经使用 TEST 引脚和示波器测量了擦除闪存程序区域的时序。 屏幕截图已添加到共享文件夹。

针对每个扇区运行的代码：

提升销
DL_FlashCTL_unprotectSector
DL_FlashCTL_eraseMemoryFromRAM
DL_FlashCTL_waitForCmdDone( Cfg_Instance．handle )
下部引脚

对于除一个扇区以外的空扇区、擦除一个扇区需要 53.8us。 似乎是一致的。

对于除一个扇区以外的空扇区、擦除整个 ProgramArea、在环路前升高引脚、在环路后降低
-良好的芯片: 8.88 毫秒
-坏芯片: 9.32 毫秒,当写入到闪存中的地址,在芯片上工作
-坏的芯片: 约 5 毫秒,当写入闪存中的地址,不能在芯片上工作

在任何情况下,我们都不会提前退出循环,因此在地址错误的坏芯片上,芯片似乎只是出于什么原因停止擦除?

对于一些填充的扇区、需要进行计算  
-良好的芯片: 194 毫秒,每个扇区 4 毫秒,

在一个好的芯片上擦除时,最后会发生某种我不知道的情况
在坏的芯片上看不到。
不知道该期待什么或寻找什么。

嗨、Pengfei、

我想我找到了一些东西,对不起断点处理:-)

擦除包含数据的扇区时、 在完成时将 STATPCNT 设置为 1、如果不需要擦除任何内容、则将其设置为 0。

但当我进入扇区 124 时、 即使该扇区未被擦除、STATPCNT 也会返回 0。 在上面的屏幕截图中、重试了 13 次、直到它被擦除、此时 STATPCNT 返回 1。 STATPCNT 寄存器的用途是什么？

在下面、您可以看到其中一次重试、其中闪存未被擦除、但  STATPCNT 设置为 0（因为它已经被擦除）。

尊敬的 Daniel：

只是想仔细检查、对于 124 个扇区、前 12 次尝试 STATPCNT 返回 0、内容未被很好地擦除、第 13 次尝试 STATPCNT 返回 1、内容被擦除？

此寄存器表示闪存控制器发送用于擦除的擦除脉冲数。  

正确

谢谢你的信任。

对于 1-12 擦除尝试、实际上您可以看到其他内容擦除、预期为 0x1F300 正确？  

Luke Ledbetter 和 Pongfei Xie 

我 根据 Pengfeis 的建议上传了一个更新的闪存驱动程序 Flash_updated.c。 请看一下这个。

我现在上传了一些图片和视频、如果您需要其他内容、请告诉我们、“MSBT6 media.zip“。
Setup.jpg — 使用调试器和 CAN 加密狗的设置的图像。
磁性电路板 back.jpg — 我们的磁传感器板
磁性电路板 front.jpg — 我们的磁传感器板
Flash layout.mp4 — 闪存布局的说明
Clocktree.mp4 - Theia 工程和时钟树
EraseCommand_53_retries.mp4 — 在闪存扇区被擦除之前需要 53 次重试的调试视频...

尊敬的 Emanuel：

SYSPLL 验证看起来 不错。 我预计会有其他一些函数会执行 SYSPLL 的实际设置？

Luke Ledbetter 

我上传了最新的闪存驱动程序、其中包含一些调试器件、用于捕获 EraseSectorInterval 操作“Flash_2025_12_04_with_retries_debug.c"中“中的重试次数。

  您是否希望我们检查 flashctl->GEN.STATCMD 中的 FLASHCTL_STATCMD_CMDINPROGRESS_MASK？

尊敬的 Daniel：

是的、这就是我希望您检查的内容、我的理论是命令没有得到处理、我们可以检查此项、以便验证我的假设是否正确。

对时钟设置执行一些测试。  所有测试均以共享 Theia 工程为基础。  

每次测试包括 针对不同时钟速度的 100 个写入/擦除周期 (PDIV：4、QDIV：32 - 40)：

具有类似结果的其他测试组合：

- 将 HFCLK 更改为 SYSOSC 作为 PLL 输入-> OK

- SYSPLL0 使用 UDIV:1 时钟向下到 40MHz -> NOK（如果设置 UDIV:2 且 ULPCLK 处于 20MHz -> 更稳定）

-从 SYSPLL0 更改为 SYSPLL2X ->不正常

如前所述、调试器似乎在更高的时钟速度下变得更加不稳定。 SEGGER 变得更加不稳定、还观察到 Theia 中存在连接问题。

附件的图像是仅使用德州仪器 (TI) 调试器时获得的、该电路板上未使用 SEGGER。 在最坏的情况下、需要擦除才能回到正轨！


在数据表中、PD0 似乎同时用于 FLASHCTL/调试。


在我们这边 、似乎不稳定性与 PD0 有关。 有什么方法可以证实这一理论？