[参考译文] MSPM0G1507：EEPROM 仿真类型 B 问题

Steffen、您好！

所以这个问题只会在您对器件执行重置时发生。 有时您需要在一两天内运行该示例、然后执行重置、您发现会发生这种情况？

我看到您提到、应用代码在启动后不会触及 EEPROM 仿真区域。 您的应用是否执行任何其他闪存写入/擦除操作、以及地址是否可能刚刚出错？

您还提到闪存复位为默认值->是否要确保 EEPROM 仿真地址(和 ECC 值、如果适用于您的区域)全部为0xFF？ 只需要确保什么操作可以更改这里的值。

我还想知道何时首次将 EEPROM 值写入 EEPROM 仿真区域。 首次刷写器件时、放置在这里的原始值是否已完成？ 或者、当您执行上述步骤时、它们是否在启动时被应用程序写入、然后被覆盖(或擦除)？

尊敬的 Dylan：

附加信息：

EEPROM 仿真的 INIT 函数会检查是否存在有效的组、如果是这样、则会将其重定位到另一个闪存地址。 我认为这是因为磨损均衡。 所以每次重启时都会进行写入和擦除。 也许有我的问题吗？！

尊敬的 Dylan：

我在´ve 启动后将闪存的 EEPROM 部分附加到了您的之后。 如果将其与 EEPROM 仿真的文档进行比较的话。

您可以清楚地看到组标头、后跟4个数据项。

我不n`t 的是、数据项 A 作为写入标志结束、数据标识符、然后是实际数据进行排序。 但附加的读数更像是 数据标识符、写入结束标志、然后是实际数据。 文档是错误的还是实现的？

我接下来要做的事情：

我在´ve 启动时读出 EEPROM 闪存部分。 在今天和一天结束时、我要让器件保持正常运行、并再次阅读和比较这部分内容。 可能还有其他内容是写入闪存部分并损坏它。

谢谢！

此致

Steffen

e2e.ti.com/.../StartUpOk.zip

第一天：在6h 运行时、EEPROM 闪存部分无变化

未经请求：您是否考虑过 慢速功率斜升和/或 RST 引脚反弹的影响？ 多年来,我已经变得不可逆转的任何事情(非幂等)在第一(比如说)第二次或之后启动。 如果不执行其他操作、在获得 MCU 的控制权并重新启动程序之前、调试器使程序运行(短暂地)的情况并不少见。

快速(？) 实验可能是在 main ()的开头插入任意延迟、然后重复启动。 可能从1秒开始、然后将其减少到可管理的水平。

关于闪存地址、我要确保当您在应用程序代码中与 EEPROM 仿真区域进行交互时、始终确保您具有正确的地址。 我看到您附加的链接器、存储器转储等 我的问题基本上只是、您要检查以确保数据写入预期位置、并且在使用擦除命令时擦除正确的地址。 这只是一件要检查的简单事情。

至于闪存的内容、我看到您的观点是4字节为零、就我所知、EEPROM 仿真区域似乎已正确初始化。 关于在启动时将数据复制到新扇区的问题-这里可能会发生错误、但默认库具有错误检查功能、如果其中一个操作失败、应该会返回错误。因此、您应该能够判断是否发生这种情况、只要您监控错误标志并将其保存在某个位置、停止执行或其他地方。

要完全清楚-复位后应该发生的情况是器件会检查 EEPROM 仿真区域并将数据复制到新的 EEPROM 仿真区域、这样数据就不会丢失、而应该只是放在新位置、除非数据已损坏。 您会再次看到某种错误。

为了了解数据项中的信息顺序-您是否考虑闪存采用小端字节序？ 这些文档应该与数据一致。

您可能还需要在错误检查的内部添加一些断点或 while (1)循环、这样、如果您检测到错误、就会卡住、而不用调试器查看它

尊敬的 Dylan：

我´ve 了发生错误时会发生什么情况：

EEPROM_TypeB_init ()返回0 -> check_one_active_Group、但第一次读取某个值时返回错误。 gEEPROMTypeBSearchFlag 为零、n´t 能够找到值。 我´ve 两次阅读。 ´ll、如果第一个失败、我再试一次。

关于文档：抱歉、您是对的！ ARM 是小端字节序。

`ve：我复查了所有内容：链接器和设置->相同的地址。 我´m 使用占位符阵列来检查 EEPROM 仿真是否适合指定的".eeprom_data"部分、情况如何？

您能检查一下地址吗？

谢谢！

此致

Steffen

另请注意：

为什么 EEPROM 仿真使用 dl_flashctl API 擦除和写入闪存内容、但不用于读取闪存内容？

读取裸指针时、使用 dl_flashctl 中的 readverfiy。 有任何具体原因吗？

Bruce、您好！

感谢您的建议。 试一试。 如果闪存已就绪、我可能可以轮询标志吗？

n`t 我反复重启器件(1关闭10打开)、不会出现 μ s 错误、这是多么奇怪。 仅当我运行设备几个小时。

好吧 checkFormat() API 的 check_one_active_Group 值看起来是正确的、这意味着它检测到一个具有有效数据的组处于活动状态。 这很好。

另外、为了明确第一次读取值时返回错误-当您尝试读取给定的数据项而它返回错误时、我假设您也要去检查存储器以查看是否确实存在该数据项？ 如果没有、那么下次调试器看看您是否可以在初始化函数前停止、并逐步检查该函数、看看值在复制时是否损坏、或者在初始化函数前是否出错。

关于数组、 看起来您正在预初始化2*1*1024字节、即2kB。 我还可以看到、您已在链接器中保留了2kB、我觉得这没问题。 使用您的头文件和链接器匹配后、地址也没有问题。

我不确定为什么使用指针而不是重新验证、这两者都应该会导致 ECC 由器件自动检查。 我不怀疑这是问题的根源。 如果您愿意、欢迎您将其切换到 readVerify

我看到您关于重启的评论导致了这个问题、另一件我很好奇的事情是：您是否全天运行设备、在断电前检查闪存内容、然后在第二天观察错误情况？ 您是否曾经整天都运行它、检查它、关闭它、然后再次检查它？ 基本而言、我要问的是、器件是否需要断电几个小时？ 我怀疑它没有,但…… 好奇。  

我主要怀疑闪存数据在一开始的启动时损坏、但我仍然认为初始化序列中的某件事是擦除这些值。 与此相关的是我在回复中提到的第一个测试。 您可以尝试在初始化序列中放置一个__BKPT (0)；这样、在连接调试器之前、代码不会在该行之外执行。

关于您的问题：

当我第一次读取一个值时(在 EEPROM 初始化之后)、我只检查 EEPROM API 中的 searchflag。 我如何使用调试器连接到目标、而不对其内容重新编程。 已经问过这个问题： https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1470125/mspm0g1507-attach-to-running-target-with-ccs20-aka-theia/5645662#5645662 ->正在等待答案。

我现在做的是通过 UART 打印调试信息。 我可以读取整个 EEPROM 部分并通过 UART 打印出来。 我可以在 INIT 和读取之前执行此操作。

是的、我全天运行设备并在断电前读取其内容。 然后将其与开始内容进行比较。 到目前为止没有变化。 我在´ll 立即重新上电后也遇到了此问题。 因此、启动时会发生一些事情。 n`t 还对我的电源进行了编程、以关闭器件一秒钟、然后将其打开10秒、但在一个小时后、问题并未发生...

谢谢！

Steffen

您应该能够通过使用指南中显示的步骤(Diego 已链接)附加到正在运行的目标。 我最后试了一下、结果还是很成功的。  

我是通过右键点击目标配置并选择启动无工程调试、然后展开线程选项卡、右键点击 Cortex_M0P 并选择进行连接来完成该操作的。 之后我使用了"Run"->"Load"->"Load Symbols"、然后在显示的对话框中、点击"Browse"、选择工程的.out 文件。 现在、我可以单步调试我的代码。 在另一个线程中、您是否是指找不到符号/.out 文件？ 对我来说、这些步骤看起来是有效的。

无论如何、如果您能够在初始化和读取之前通过 UART 读取闪存、那很好、听起来您应该能够进行相同的测试。 只需确保在初始化和读取之前有一些断点或暂停、以便查看数据何时损坏。

整天都在工作之后才知道发生了什么、断电后立即重新上电。 似乎是在启动时出现了问题。 此处有有趣的说明。 可能在您填充组/复制组一次或多次后出现此问题。

谢谢。 我´ve 了 UART 打印、它运行良好。 ´m、我等待它再次发生。

尊敬的 Dylan：

到目前为止没有。 I`ve 更改了以下内容：

1. SYSCFG_DL_init ()之后的1ms 启动延迟

2.在仿真初始化之前和之后打印 EEPROM 闪存内容

3.未连接调试器

1和2会导致较高的启动延迟。 所以可能Bruce McKenney 是正确的、或者连接的调试器导致了这个问题。

I´ve 2并将报告。  我`m 逐个收回更改。

此致

Steffen

尊敬的 Dylan：

另一个问题：

当我在 sysconf 中将 BOR 级别从0更改为3时、会出现一条提示、说明：

设置掉电复位(BOR)阈值电平。 BOR0违例将强制重新启动、这是允许的最小阈值。 BOR1-BOR3违例会生成中断。

如果我理解正确的话、BOR3电平将只生成中断、而不是 POR。 因此、我必须对此采取行动。 我该怎么做呢？ 没有这种情况的示例。

谢谢！

此致

Steffen

Steffen、您好！  

在我看来、根本原因评估很合理、如果您在闪存操作期间复位、则闪存数据可能会损坏。 当电源电压仍在升高并略高于 BOR 阈值时、闪存操作开始、器件会消耗额外的电流并可能将电压拉低一位。

如果电源电压非常接近最低工作电压、将 BOR 阈值设置得更高应有助于确保不执行任何闪存操作。 延迟某个位也有助于确保在执行代码之前电压已经上升。

至于您关于 BOR 级别1-3时应采取什么措施的问题：您正确的是、BOR3只会生成中断、而不会生成复位。 在中断中、您需要定义系统所需的行为。 根据此处讨论的内容、听起来您应该检查闪存控制器的状态以确保没有正在进行的操作。 通过跳转到中断处理程序、您还将停止向控制器发出的下一条闪存命令。  

在编写中断处理程序时、需要考虑两种可能的情况：

1)电源恢复到安全操作水平。 在这里、您可能只是想延迟下一个闪存操作、直到电压恢复。 清除中断标志、如果您发现需要中断标志、再等待一段时间、然后从处理程序返回。 如果电压再次下降、您应该再次跳回处理程序。

2)电源无法恢复到安全操作水平。 在此、您要确保不会请求任何新的闪存操作、以便在电源电压超过最小阈值时没有新的闪存操作执行。 一旦正在进行的操作完成(如果有的话)、您的闪存应该可以进入断电状态。 除此之外、您希望如何平稳地断电也取决于您。

尊敬的 Dylan：

感谢您提供信息。

我所做的´ve：

1.添加了 EEPROM_INIT ()-> 10ms 之前的10ms 启动延迟比上述所有突降都长

2.将 BOR 电平改为3并添加 BOR 中断如下：

void NMI_Handler (void)｛

   switch (DL_SYSCTL_getPendingNonMaskableInterrupt ()){

       案例 DL_SYSCTL_NMI_BORLVL：
           DL_SYSCTL_resetDevice (DL_SYSCTL_RESET_POR)；
           休息；

       默认值：中断；
   }
}

是这样吗？ 或者、如果 im 高于或低于 BOR 电平、我必须以某种方式检查中断吗？

我还´ve 了另一个主题

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1472223/mspm0g1107-using-eeprom-emulation-type-b-if-the-device-browns-out-during-a-flash-write-we-lose-several-data-items/5657280?tisearch=e2e-sitesearch&keymatch=mspm0%20brown%20out#5657280

存在同样的问题、根本原因是 EEPROM 在启动时的重新分组行为。 您的同事已经分析过此问题、并将在以后的 SDK 更新中修复。

谢谢！

此致！

Steffen

我唯一的评论是2)你定义 NMI 处理程序、然后检查复位原因、如果原因是 BOR、那么你断言 POR -这不是我预期的那样、你对此有理由吗？ 这意味着、无论何时超过 BOR 阈值(任何级别)、都将经历一个 POR。 这会导致与之前类似的问题。

在处理程序内部、您可能只需要继续清除 BOR 标志并再次对其进行轮询、以检查是否仍低于 BOR 阈值。 如果电源重新上升、该标志将不会重新置位、并且您可以退出中断处理程序。 如果电源保持在 BOR0至 BORx 区域(其中 x 是您配置的 BOR 电平)、则您会永远轮询标志。 您可能需要为此找出不同的行为。 如果器件降至 BOR0以下、则它会自动复位、您无需使用软件使复位生效。

我之前提到的其他功能是轮询闪存控制器状态寄存器以获得命令完成信号、然后等待(可能使用上面的清除和轮询循环)、这将完成正在进行的闪存命令、然后等待电源再次恢复。

我的目的是在复位后将 EEPROM 初始化调用延迟10ms。 这是我´ve 看到的最长的时间、直到电压达到3、3V。 因此、如果此时 BOR 有效、则调用中断、器件重新启动。 然后10ms 将从开始再次运行。 因此、器件基本上会重新启动、直到电压高于 BOR3电平、然后当10ms 启动时、调用 EEPROM INIT。

这是一个错误的假设吗？

还有一个问题：

我`s 启用 NMI 复位还是因为它不可屏蔽而一直启用？

谢谢！

此致

Steffen