[参考译文] TM4C1294KCPDT：擦除闪存块是否会影响在后台运行的计时器？

Deepak 您好！

通常、FlashErase 过程应从 SRAM 执行、因此如果计时器未设置为从 SRAM 运行、则程序将无法执行它。 此外、您还必须确保定时器不受闪存擦除和重新编程的影响。 对于您的器件、一次擦除16 KB 块、因此必须小心以避免销毁可能正在执行的任何代码。

为了更好地确认从 SRAM 执行是您问题的核心、我需要查看有关计时器配置方式以及您正在执行的闪存擦除过程的代码。 另外、获取.cmd 或.map 文件以了解存储器映射也会很有帮助。

e2e.ti.com/.../ti_5F00_forum.txtHiRalph、

我附加了一个文本文件、其中包含用于计时器初始化以及闪存擦除和重写的代码。 它还包括我尝试写入的结构。

我注意到、当它第一次擦除块时、计时器不受影响、但每次之后、我的时间都会受到影响。

此外、您能告诉我在项目中的哪个位置可以找到.cmd 和.map 来与您共享它吗？

此致、

Deepak Rai

Deepak 您好！

在 Code Composer Studio 中、.cmd 文件将位于您的主项目目录中、而.map 文件将位于 Debug 文件夹中。

e2e.ti.com/.../project_5F00_css_5F00_map.txte2e.ti.com/.../project1_5F00_cmd.txt

您好、Ralph、

我已附加这些文件。 您是否通过代码获得了有关该问题的任何信息？

我让计时器4在后台运行、我使用 Timer1写入和擦除闪存。 这两个器件都以1ms 的时间运行。 定时器4具有最高优先级、 我将禁用定时器1、然后进入函数进行擦除和写入、在完成该函数后、我将再次启用定时器1。因此、我希望定时器4始终运行、而不管有什么其他情况。

此致、

Deepak

从闪存组中任何已擦除块的位置读取将使 CPU 处于停滞状态、直到擦除完成。 该 STALL 甚至可以防止中断被服务。

尊敬的 Bob：
正如您在我之前的帖子中看到的、存储器正在被擦除时、有时不会调用 timer4中断例程。 我希望 timer4始终保持运行。 是否有任何可能的解决方案？

Timer4中断例程未从被擦除的存储器中读取。

此致、
Deepak

根据您发布的内容、您正在擦除0x6C000处的块。 TM4C1294的主闪存由四组组成、分为较低和较高的区域、两组交错。 这实际上为您提供了两个要使用的区域：0x0-0x3FFFF 和0x40000-0x7FFFF。 查看您提供的.map 文件、我看到您正在使用位置0x0-0x4012F。 在块擦除过程中访问上部区域中的第一个0x130位置将使 CPU 停顿。 但是、这些位置用于.cinit 段、该段仅应在启动期间读取。 因此，我看不出你为什么要拖延。

您可以更改优化级别并减小代码大小吗？ 如果您的程序能够放入低256KB 闪存中、则很有意思、看看问题是否消失。 您是否在闪存上运行任何定期校验和或 CRC？

我的当前代码使用位置0x0-0x4012F。 我是否应该尝试将其安装在0x0-0x3FFFF 中？

关于校验和、在这个 FlashErase 函数之前、我将使用 FlashPBSave 函数来保存参数块。 我相信此函数会计算校验和、但这仅用于保存参数块。 我不认为它是周期性的、因为只有当我从用户那里获取数据时、我才会逐一保存这两个数据。 首先保存参数块、然后保存另一个数据块。

此致、
Deepak

是的、请尝试将优化级别设置为4、将速度/大小设置为0、以查看我们是否可以将代码设置为0x-0x3FFFF。

我仍在努力寻找一种更好的方法来确定真正的问题。

e2e.ti.com/.../3438.project_5F00_css_5F00_map.txt

尊敬的 Bob：

我作出了你要求的屠杀。 但是，(Opt4和 speed 0)给了我太多错误，所以我(Opt2 speed 0)也减小了低于0x3FFFF 的大小。 当前使用的存储器是0x0-0x2b938。  但计时器仍然存在问题。 我仍然不明白为什么第一次擦除时不会发生这种情况。

我已附加.map 文件以供您验证。

抱歉-未使用此'129 MCU 系列-我无法将 "特定于此 MCU"的用途添加到"特定"用途中。   (但我非常赞赏"文件大小链接"以及后续观察/测试。)

Fire/i -尝试  通过来淘汰(隐藏) MCU 机制

• 创建极小的新代码文件
• 这些新文件经过精心设计-和 (两者) "精心且战略性地放置"-具有闪存( 根据供应商 Bob 的指南-在这里访问-早期)

我认为、这里的目标是"非常不想"将 MCU"折弯成"希望的"适应/合规性"-已经开发的大型复杂计划！    这个现有程序-已经失败-(可能)由于其大尺寸和多种功能-很可能会创建"询问错误"(或条件)、这将"发现并延迟"发现"错误导致机制！"  

相反-始终是超级有效的'kiss'-会寻求 '复制 该确切(计时器失败)问题'- 但 通过最低限度的代码和 (必要)附件/外设操作。   我建议 "先排空沼泽"(然后才慢慢地)有条理地重建，这样做(很明显)会有好处！   (创建"水上乐园"-相反！)

供应商的"Bob"提供了"非常必要的"设计限制-这是我们的工作-以最好 地"利用、正确指导和部署" 他的正确指导。

此类(小得多)项目使(可能的)故障机制更容易识别(如此之多的暴露)！    (在   任何"覆盖范围过广" 的代码框架工作中、"kiss"[战略和系统]的"SS"部分证明实施起来非常困难。    (即几乎任何现有代码(无法预期)都可以"做好 准备、从而预见" 此类不必要的问题！)    

同样、"基本"(最小)实施-设计用于简化 、"逻辑序列化/探测测试/验证"- 在流程中的每个步骤进行测量和确认-"长期经验证" 为"最佳工作！"    (这样、不同代码元素的数量和大小就大大减少了、从而避免 了大多数"询问错误"-只 需"邀请"-由"太大的现有程序"-始终"接受"、例如(建议和告知) "错误探测/检测"焦点！)

一旦确定了故障的原因-可以正确检查原始/现有代码(仅在那时)-然后按顺序添加(然后始终-"逐件测试")。   通过这种"严格的方法" 、"有害的比特/碎片"(更快速/更容易地表面) 无疑 有助于识别、理解、然后 移除。

Deepak、您好！

想知道您的代码在写入用户参数块之前是否首先调用 FlashPBInit()？

是的。 我在代码开始时调用 FlashPBInit()。 它在开始时只调用一次。  

这会影响计时器吗？  

Deepak、您好！

在 Johns POST 读取后、它会产生 SysTick 计时器存在于 NVIC 级别、看起来计时器 INT 不会停止。 否则、RTOS BIOS/其他操作系统要求 SysTick 始终保持节拍。 因此、如果 CPU 在闪存写入期间突然停止重新加载倒计数寄存器、那么它似乎无法再处理 C++闪存擦除指令。 另一个提示是 SysTick INT 源由 NVIC 自动清除、这是另一个提示、它可能不会成为闪存块写入的受害者。