[参考译文] TM4C1294NCPDT：TM4C1294NCPDT 闪存写入问题

尊敬的 Bob：

由于 CPU 能够"检测"(部分)"问题/麻烦/不合规" (通过将其引导至长时间保持来证明)-而不仅仅是"暂停"-不能  (部分-甚至是轻微的)识别问题-额外提供？  

显然、"没有工作！ (小的“街头游戏”——“使联合游戏变得更加活跃”。) — —也许你可以“上行”——大多数东西都能击败，“被卡住(很长时间)！”  

Fi/I 正在实施这样的"故障识别"-对于100A+ BLDC 控制器-强制在(非常)恶劣的环境中运行。 "确定此类问题"(以便 可以发起现场、对抗的防御)现在是 我们的问题，"第一个问题！"    (我们从未/从未(甚至)考虑过" 长期搁置！")

谢谢，Bob。。。 然而(即使)如果投机性的----"启动到(任何)"暂停/停止预期的活动"----而没有任何，"发出这种事实的信号"----或"试图收集"(并传达)"某些线索"----似乎不是很好，"最好/最聪明的"----它不是吗？

闪存"擦除/写入"是一个复杂的过程-它看起来是"合理的"-(一些)防御和/或识别措施将证明非常有用。   特别是-(任何/全部)"被骗"海报-未通知-和"无助等待"。   同样、"没有你的工作"-但建议 "改进处理" (肯定)优于"等待/提问/祈祷"。

尽管声称(几乎)您的 MCU 没有经验或资质-而这是"闪存擦除/写入"问题-"kiss"可能(再次)引起您的帮助。   (有人希望)

Fire/i (也是)支持 FreeRTOS (主要是 MIT 和亚马逊许可的)-但其使用可能会"引起/促成"您的问题-这是不是吗？   

以下是几项基于 kiss-based 的一般性建议：  

• 您是否可以(暂时)"退出任何 RTOS "-并重复测试。   我们的目的是"尽量减少(可能)影响变量的数量"。
• 您的两个"闪存区域"是否正确拆分为指定(不同)的位置。   我相信、此类闪存"擦除/写入"可以(仅-或者最好)在这类"单独区域"之间运行。
• 在此操作之前(再次临时)、您可能会"降低系统时钟速度"(可能减半)、以查看这是否会影响您的结果。
• 除非 明确禁止、否则在特定"闪存擦除/写入"代码段的关键/关键部分之间插入"延迟"通常是有用的。
• 在启动"闪存写入"之前、您无法"证明"已成功执行"闪存擦除"？   事实证明、这不是有洞察力的吗？

KISS 要求我们： "将问题分解成更小、更合理的测量和分析部件、然后系统地进行进度-"一次一个"。

我提供这一信息是因为供应商的 Bob 注意到他的退货延迟、并且您对此处(或您发现的)信息的恢复很可能会" 快速、轻松和增强" Bob 在退货前的诊断工作(如果未解决)...

我将尝试回答您的问题：

1. 正如我在开始帖子中所说、这个问题对于向项目添加/延迟代码非常明智。 仅在主循环中写入闪存的简单项目不能证明问题。 我刚才添加了 FreeRTOS、因为它在我的'big'项目中使用、因为我的想法是假设 RTOS 使用 SysTick 计时器、并且可能在 FlashWrite 操作期间出现 SysTick 中断、这会导致故障。 即使在这个"简单"项目中、如果您注释掉仅使用1的'CheckResetCose()'函数调用、并且在 FreeRTOS 调度程序启动之前、问题不会出现。
2. 我不知道您对"正确拆分闪存区域"的理解是什么。 它们不是物理拆分的、因为它们都在内部闪存中。 在"大"项目中、我将闪存大小限制为可用内部闪存的一半。 在这个"人"项目中、我没有这样做。
3. 我已经尝试在主函数开始时将时钟速度降低到60MHz"全局"、这可以解决问题。 但我无法确定它确实解决了问题、还是隐藏了它、因为我在代码中做了一些更改。
4. FlashErase 和 FlashWrite 函数来自 TivaWare、它们正在检查其中的闪存忙位。 MAP_FlashErase 和 Write 函数来自 ROM、我不知道它们是如何工作的。

但是、所有建议都没有回答这样一个问题：为什么所有内核寄存器变为相等的值、包括 CTRL_FAULT_BASE_PRI 寄存器、该寄存器不会保存到堆栈中、并且在堆栈溢出时不会损坏。 在屏幕截图中、您可以看到失败后程序的位置。 我认为这不是一个随机地址。 但为什么所有内核寄存器都包含它呢？

大家好、

我有更新。 我设法使我的项目失败、或者不仅仅是通过添加一些 NOP。

看到相同的项目、但我在 main 函数中添加了一些 NOP。 共有26个 NOP。 和闪存操作运行良好。 如果您注释掉最后的第26个 NOP、闪存操作将失败。 然后、如果你从底部注释出下一个 NOP、闪存操作将失败、直到21个 NOP 在代码中、然后继续注释掉 NOP、项目将正常工作、直到11个 NOP 在代码中。 如果您注释第11个 NOP、项目将再次失败。

e2e.ti.com/.../FlashFailureTest2.zip

[引用 user="CB1_MOBIST"]在 特定"闪存擦除/写入"代码段的关键/关键部分之间插入"延迟"(除非明确禁止)通常证明是有用的。

正如先前建议的那样- 您插入 "NOP" -符合 "插入延迟" 建议-正如之前发布的...

我们怀疑、之前 也有人建议、额外的"系统时钟的减慢"将会减少 "所需 NOP"的数量。    

如先前所述、 "降低系统时钟速度" 和 "插入关键延迟"的"组合"应适合您...  (已成功使用我们的 Cortex M7器件和 M4 (来自其他器件))

[引用 USER="Dmitry Govorov">因为我看到 SysTick 中断在 FlashWrite 操作期间发生了几次。 [/报价]

也许，为什么闪存16KB 块之前的 IntMasterDisable()调用可能会停止 不需要的中断，IntMasterEnable()就在之后。  从 SRAM 传输的 UART 数据中也会出现类似的中断、 因此索引指针损坏 了缓冲区阵列。  

[引用 user="Dmitry Govorov"]硬件中是否可能存在错误？ 我在 TM4C123 CPU 中发现了类似的问题

TM4C123硬件可能出现故障

TI E2E 社区

---------------------- 截至2015年2月4日此长线程的摘要：在以下情况下，Tiva TM4C123微处理器中存在严重的错误，可能导致未定义的行为(如堆栈损坏)：- A.

[/引述] TM4C123器 件中的错误记录在勘误表 MEM#14中"从闪存执行期间的闪存写入操作可能导致错误的指令提取"。 查看2017年3月发布的《TivaC 系列 TM4C129x 微控制器芯片版本1、2和3勘误表》SPMZ850G，我看不到 TMC129器件的相应勘误表。

在调查 TM4C123 MEM#14时、TM4C123上失败的示例程序在 TM4C129器件上未失败、据信是因为 TM4C129使用了不同的闪存架构。

但是、根据您对 TM4C129器件上问题的描述、由于更改 NOP 可能会导致问题的发生和发生、因此您怀疑 TM4C129中存在错误。

[引用 user="CB1_MOBIET"]您正确地注意到、关于 TM4C123 MEM#14：" TM4C123上失败的示例程序在 TM4C129器件上未失败、据信是因为 TM4C129使用了不同的闪存架构。" 然而-"违规程序"(正确)是否与 TM4C123 (较小)配合/约束？ (如果您运行该程序-肯定已经正确实施。)[/QUESP]我首先启动了一个在 TM4C123GH6PM 上失败的程序、然后将该程序移植到 TM4C1294NCPDT (未失败)。 很遗憾、我找不到 TM4C1294NCPDT 的程序版本、无法找到我所做的确切更改。

因此、我们将使用 Dmitry 的示例进行研究。

[引用 user="Dmitry Govorov">查看相同的项目，但我在主函数中添加了一些 NOP。 共有26个 NOP。 和闪存操作运行良好。 如果您注释掉最后的第26个 NOP、闪存操作将失败。我可以使用相同版本的 TI 编译器和 TivaWare、但使用 CCS 8.0.0.00016来重复此失败。

测试中使用 了 TM4C129ENCPDT 器件版本3。

到目前为止的测试总结如下：

1) 1)未修改的程序成功运行。

2)使用了 XDS110和 CCS Statistical 函数分析、默认情况下每1024个周期对 PC 采样一次、以捕获成功运行的配置文件。

3) 3)注释了最后第26个 NOP、程序开始失败。 在大多数故障后、调试器无法停止目标。 使用 CCS Statistical 函数 Profiling 捕获失败运行的配置文件。  统计函数分析似乎显示程序卡在 xPortPendSVHandler()函数中，因为跟踪结束时所有采样的 PC 值都是同一地址 0x55ae，它是  xPortPendSVHandler()末尾的 BX r14指令。

4)采用之前的失败程序、如果 在 xPortPendSVHandler 上设置了硬件断点、然后在断点命中时恢复程序、程序将成功运行以完成。 我执行了多次跑步、并且：

a) 在 xPortPendSVHandler 上没有断点时、程序会失败。

b)在 xPortPendSVHandler 上具有断点、并在遇到断点且程序成功完成时恢复。

还不了解根本原因是什么、但如果设置断点、可能会导致问题消失、请怀疑存在一些计时问题。

Chester Gillon 说：

b)在 xPortPendSVHandler 上具有断点、并在断点被命中且程序成功完成时恢复。

对于 TM4C123错误 Mem#14、单步执行的操作也足以防止故障。

Chester 为您展示了精彩的时间/努力-谢谢-非常感谢。

现在(几乎)不明显的是、"插入延迟"-在用户代码的关键/关键部分-肯定会增加"稳健性"-甚至可能导致程序成功？

这种情况下、我们在这里敦促"插入延迟"-过去3天...

根据公司和我的经验、这种"闪存擦除/写入"确实需要"防护带"、即使    他们"看起来"成功也是如此。    这证明了这一点、因为这样的操作肯定会"增加"完全/正确"执行所需的时间-并且这些时间将(仅限)随着器件老化而增加-并且也证明"温度敏感"。

防护带-由延迟提供-提供 "廉价但有效的保险" -并已通过(其他/外来) ARM MCU "证明成功"-以及(现在)与此处的 MCU 一起-也...

[引用 USER="CB1_MOBILE]]现在(几乎)不清楚、 "插入延迟"-在用户代码的关键/关键部分-肯定会增加"稳健性"-甚至可能导致程序成功？[/引述]问题在于确定代码的"关键/关键"部分、在该部分插入延迟以针对潜在原因提供可靠的修复、而不是掩盖原因。

使用 Dmitry 的示例程序、在主函数中插入一个 NOP 而不对闪存进行编程的操作会使故障"消失"。

示例程序将 闪存配置寄存器(FLASHCONF)的默认值保留为零。 如果在加载失败的程序且程序在 main 处停止：

A)如果以闪存配置寄存器的默认值启动运行的程序、程序将失败。

b)如果在  运行程序之前使用调试器将闪存配置寄存器中的 FPFOFF (强制预取关闭)位置位、程序将成功运行。

因此、认为闪存预取缓冲区对问题有一定影响。 在主函数中插入 NOP 时、会导致故障"消失"、从而可能随机播放存储器中其他函数的地址、因此需要查找哪个函数对闪存预取缓冲器的地址对齐敏感。

我想指出、我(之前也是如此)建议使用配备了"双分组闪存"的 MCU (正确)-以及插入密钥/关键"延迟"-具体解决了"闪存预取缓冲器施加的灵敏度"！   

重要的是-同时包含供应商的 MCU -以及 "其他！"的 MCU    这种 (近乎)通用解决方案明显胜过"一个和唯一一个供应商"(解决方案)！

[引用 user="Dmitry Govorov">查看相同的项目，但我在主函数中添加了一些 NOP。 共有26个 NOP。 和闪存操作运行良好。 如果您对最后的第26个 NOP 进行注释、 闪存操作将失败。[/quot]在先前显示故障似乎与与 与 xPortPendSVHandler 函数交互的闪存预取缓冲区相关的测试之后、在 xPortPendSVHandler 函数 w.r.t 中查找了指令的地址。32字节闪存字节预取缓冲区的边界。 对于这些测试、在没有任何断点的情况下运行程序、并且闪存配置寄存器处于其默认值。

这是 对工作程序的 xPortPendSVHandler 的反汇编、其中 main 中有26个 NOP：

xPortPendSVHandler()：
00005554：F3EF8009 夫人 R0、PSP
109ISB
00005558：F3BF8F6F ISB SY
112LDRR3、pxCurrentTCBConst
0000555c：F85F302C LDR.w R3、[PC、#-0x2C]
113LDRR2、[R3]
00005560：681A LDR R2、[R3]
116TST r14、#0x10
00005562：F01E0F10 TST.w LR、#0x10
117它 eq
00005566：BF08 它 EQ
118vstmdbeq r0！、｛S16-S31｝
00005568：ED208A10 vstmdb R0！、｛S16、S17、s18、S19、 S20、S21、S22、S23、S24、 S25、s26、S27、s28、S29、 S30、S31｝
121stmdb r0！、{R4-r11、r14}
0000556c：E9204FF0 stmdb R0！、｛R4、R5、R6、r7、 R8、R9、R10、r11、LR｝
124STR r0、[R2]
00005570：6010 结构 R0、[R2]
126stmdb sp!、｛R3｝
00005572：F84D3D04 结构 r3、[sp、#-0x4]！
127.LDR r0、ulMaxSyscriesInterruptPriorityConst
00005576：F85F0040 LDR.w R0、[PC、#-0x40]
128LDR R1、[r0]
0000557A：6801 LDR R1、[r0]
129MSR basepri、R1
0000557c：F3818811 MSR basepri、R1
130DSB
00005580：F3BF8F4F DSB 第
131号ISB
00005584：F3BF8F6F ISB 第
132章BL vTaskSwitchContext
00005588：F7FBFC46 BL 0xe18
133MOV r0、#0
0000558c：F04F0000 MOV.w R0、#0
134MSR basepri、r0
00005590：F3808811 MSR basepri、r0
135ldmia sp!、｛R3｝
00005594：F85D3B04 LDR r3、[sp]、#4
138LDR R1、[R3]
00005598：6819 LDR R1、[R3]
139LDR r0、[R1]
0000559a：6808 LDR R0、[R1]
142ldmia r0！、｛R4-r11、r14｝
0000559c：E8B04FF0 LDM.w R0！、｛R4、R5、R6、r7、 R8、R9、R10、r11、LR｝
146TST r14、#0x10
000055a0：F01E0F10 TST.w LR、#0x10
147它 eq
000055a4：BF08 它 EQ
148.vldmiaeq r0！、｛S16-S31｝
000055a6：ECB08A10 Vldmia R0！、｛S16、S17、s18、S19、 S20、S21、S22、S23、S24、 S25、s26、S27、s28、S29、 S30、S31｝
150MSR PSP、r0
000055aa：F3808809 MSR PSP、r0
151ISB
000055ae：F3BF8F6F ISB 第
152号BX r14
000055b2：4770 BX LR 

这是 主代码中包含25个 NOP 的故障程序的 xPortPendSVHandler 的反汇编：

xPortPendSVHandler()：
00005550：F3EF8009 夫人 R0、PSP
109ISB
00005554：F3BF8F6F ISB SY
112LDRR3、pxCurrentTCBConst
00005558：F85F302C LDR.w R3、[PC、#-0x2C]
113LDRR2、[R3]
0000555c：681A LDR R2、[R3]
116TST r14、#0x10
0000555e：F01E0F10 TST.w LR、#0x10
117它 eq
00005562：BF08 它 EQ
118vstmdbeq r0！、｛S16-S31｝
00005564：ED208A10 vstmdb R0！、｛S16、S17、s18、S19、 S20、S21、S22、S23、S24、 S25、s26、S27、s28、S29、 S30、S31｝
121stmdb r0！、{R4-r11、r14}
00005568：E9204FF0 stmdb R0！、｛R4、R5、R6、r7、 R8、R9、R10、r11、LR｝
124STR r0、[R2]
0000556c：6010 结构 R0、[R2]
126stmdb sp!、｛R3｝
0000556e：F84D3D04 结构 r3、[sp、#-0x4]！
127.LDR r0、ulMaxSyfrabrost InterruptPriorityConst
00005572：F85F0040 LDR.w R0、[PC、#-0x40]
128LDR R1、[r0]
00005576：6801 LDR R1、[r0]
129MSR basepri、R1
00005578：F3818811 MSR basepri、R1
130DSB
0000557c：F3BF8F4F DSB 第
131号ISB
00005580：F3BF8F6F ISB 第
132章BL vTaskSwitchContext
00005584：F7FBFC48 BL 0xe18
133MOV r0、#0
00005588：F04F0000 MOV.w R0、#0
134MSR basepri、r0
0000558c：F3808811 MSR basepri、r0
135ldmia sp!、｛R3｝
00005590：F85D3B04 LDR r3、[sp]、#4
138LDR R1、[R3]
00005594：6819 LDR R1、[R3]
139LDR r0、[R1]
00005596：6808 LDR R0、[R1]
142ldmia r0！、｛R4-r11、r14｝
00005598：E8B04FF0 LDM.w R0！、｛R4、R5、R6、r7、 R8、R9、R10、r11、LR｝
146TST r14、#0x10
0000559c：F01E0F10 TST.w LR、#0x10
147它 eq
000055a0：BF08 它 EQ
148.vldmiaeq r0！、｛S16-S31｝
000055a2：ECB08A10 Vldmia R0！、｛S16、S17、s18、S19、 S20、S21、S22、S23、S24、 S25、s26、S27、s28、S29、 S30、S31｝
150MSR PSP、r0
000055a6：F3808809 MSR PSP、r0
151ISB
000055aa：F3BF8F6F ISB 第
152号BX r14
000055ae：4770 BX LR 

对于发生故障的程序、 xPortPendSVHandler 中的第1条 ISB 指令位于地址0x5580、这是闪存预取缓冲区边界的开始、而对于工作程序  、xPortPendSVHandler 中的第1条 ISB 指令位于地址0x5584。 ISB 指令的 ARM 文档为：

[引用]ISB 充当指令同步屏障。 它刷新处理器的流水线、以便 ISB  ISB 在指令完成后再次从缓存或存储器中提取所有后面的指令。为了调查 ISB 指令的地址对齐是否对 third_party\freertos\Source\ccs\arm_cm4F\portasm 源文件中的闪存预取缓冲区边界敏感：

a)将 xPortPendSVHandler 和以下 vPortSVCHandler 函数的.align 指令从4字节更改为32字节(闪存预取缓冲区的大小)：

.align 32
xPortPendSVHandler：.asmfunc



.align 32
vPortSVCHandler：.asmfunc

b)在 xPortPendSVHandler 函数中、在 DSB 和 ISB 指令对之间插入越来越多的 NOP。

其作用是控制 xPortPendSVHandler 函数中 ISB 指令相对于闪存预取缓冲区边界的地址对齐。

结果如下(每行3次运行以进行检查、结果始终相同)：

根据上述测试 、当 xPortPendSVHandler 中的第1条 ISB 指令相对于闪存预取缓冲区边界具有0、2、26、28或30字节的地址偏移时、程序将失败。

希望 TI 能够确定当使用闪存预取缓冲器且在闪存中运行的程序正在对闪存扇区进行编程时、此程序是否在 TMC129器件中披露了 ISB 指令的地址位置勘误表。

同时、解决方法可能是确保 为 xPortPendSVHandler 函数提供32字节对齐、以便其 ISB 指令的有问题地址偏移不会因程序的其他更改而发生。

无论您的测试、 "证明原因-还是不"-您的巨大(集中)努力都值得称赞。

也就是说、如果您创建的测试探究(仅或主要)"ISB 指令的地址对齐"-这可能不能确认 、"整个"擦除/写入"过程"已(完全)成功...

如果 您刚才确定的"故障"受到以下因素的影响、它(会)会证明您感兴趣：

• "系统时钟" 减少(例如、降低至60MHz)
• 选择的 MCU 采用" 双组"闪存-并且在每个组之间发生"擦除/写入"
• 扩展数据传输的"大小"

同样、在使用"IAR" IDE 和(其他) ARM Cortex MCU (M4和 M7)以及合规性(如上所示)时、不会出现类似"MCU 闲置"(如正常报告所示)...

这样可能无法确认 、"整个"擦除/写入"过程已(完全)成功...

[引用 USER="CB1_MOBIT]MCU 选择采用" 双组"闪存-并且每个组(/引用)发生"擦除/写入" TM4C1294NCPDT 具有一个512 KB 的低闪存组和一个512 KB 的高闪存组。 示例程序正在从下部存储区运行并擦除/编程上部存储区。

再说一次，"绝不"我的写作被解释为"批评"你的"伟大"努力。    正如这里经常显示的那样-您是"少数人之一"-他们始终努力"帮助他人"。   太棒了！

[引用 user="Chester Gillon">示例程序检查 MAP_FlashEras()和 MAP_FlashProgram()函数的返回结果，这些函数没有报告错误。 当程序失败时、它会崩溃、而不是报告闪存擦除或程序失败

请记住、"错误检查"方法(证明)"不能识别任何错误源"(超越"巧妙"崩溃)-(可能)在任何时候都不能证明是决定性的！    根据(非常)指示灯(即不存在)"错误识别"- "我们如何保证、错误报告 -证明"始终"是完美的？"   (我将此可能性基于明显缺乏 "任何错误识别"(可能)表示"没有灵感"的错误报告方法)。

在您看来-可能(其他)影响影响了" 闪存擦除/写入"目标的可靠性？    包括：

• RTOS 选择...  (FreeRTOS)
• IDE 的选择 ...  (此处为 CCS)
• 优化设置-及其(可能的)对生成的 ASM 的影响-(如果有) ... (未知、此处)

不是 '129或 CCS 的"粉丝"(我们既不使用也不使用)-我无法通过 IAR IDE "删除"这些答案。  我可以报告、"闪存擦除/写入"-当符合"双组"时-和(有时)增加战略延迟(闪存擦除和写入之间) 并 在"IAR"下执行 -在(其他) Cortex M4/M7下实现了"巨大成功"-工作频率@ 180MHz 及更高...

[报价 USER="CB1_MOBIT]*如果 您刚刚发现的"故障"受到以下因素的影响、(会)会证明您感兴趣：

• "系统时钟" 减少(例如、降低至60MHz)

[/报价]我已对哪些因素可以使碰撞发生并转进行了更多调查。 最初的条件是：

• TM4C129ENCPDT 修订版 A2
• 120MHz 的时钟频率。
• 调用 ROM_FlashErase 来擦除闪存。
• 调用 ROM_FlashProgram 对闪存进行编程。
• 具有32字节对齐的闪存中的 xPortPendSVHandler()。
• 使用 TivaWare_C_Series-2.1.4.178。

测试总结：

其中、"crash"表示在擦除/编程3个或4个闪存扇区后、程序停止向 UART 报告进度。 "崩溃"后、无法使用 CCS 调试器对所发生的情况进行事后剖析。 CCS 调试器在"崩溃"后报告的错误根据使用的调试探针而有所不同：

因此、"崩溃"会将 Cortex-M4F 内核置于调试器被锁定的状态。 调试器再次连接之前需要进行复位。

尚未成功确定崩溃的根本原因、但使用 Statistical Function Profiler 每896个时钟对程序计数器进行一次采样显示如下：

a)程序位于 ROM_FlashProgram()中。

b)在 FreeRTOS 上下文切换函数中获取两个样本、这两个样本被认为是 FreeRTOS 使用的定时器中断的结果。

c)所有剩余样本都是相同的程序计数器，用于 xPortPendSVHandler()末尾的“BX lr”。

切斯特、您好！

这是您为解决此问题所做的出色工作。

我只能添加一些有关 b)在 FreeRTOS 上下文切换函数中获取两个样本、这两个样本被认为是 FreeRTOS 使用的定时器中断的结果。
我在运行 MAP_FlashEras()和 MAP_FlashWrite()函数期间看到了2-3个 SysTick 计时器中断。

作为问题的快速解决方案、我做了几件事：

1. 使用从 ROM 运行的 MAP_版本的擦除和写入功能
2. 将 SysTickTimerISR 处理程序移至 RAM
3. 将我在其中调用"擦除和写入函数"的父函数移动到 RAM 中

当然、它不能解决问题的根本原因。 但它可能会为您提供一些想法。

P.S. 您能否解释一下如何从 TivaWare 获取函数以从 SRAM 运行？ 我只想将这些函数的源文件复制到我的文件中、然后在这些函数之前添加'__attribute__((ramfunc)'.

[引用 user="Dmitry Govorov]P.S. 您能否解释一下如何从 TivaWare 获取函数以从 SRAM 运行？ 我只想将这些函数的源文件复制到我的文件中、然后在它们之前添加'__attribute__((ramfunc)'。我编辑了链接器命令文件以手动将 TivaWare FlashErase ()和 FlashProgram ()函数添加到 .TI.ramfunc 部分：

.TI.ramfunc：{*(.text：FlashErase)*(.text：FlashProgram)｝load=flash、run=SRAM、table (BINIT) 

这是因为 TivaWare 库已编译、每个函数都放置在其自己的段中。

[引用 user="Dmitry Govorov"]当然、它不能解决问题的根本原因。 但也许它可以为您带来一些想法。我仍然没有确定根本原因。

MSP432E 器件似乎基于 TM4C129器件、我为 MSP43E401Y 创建了一个等效测试程序、该程序因相同症状而失败-请参阅 MSP432E401Y：如果在闪存编程操作期间发生 FreeRTOS 上下文切换、处理器可能会崩溃

您好 Dmitry、

我们还使用了 TM4C1294NCPDT、并根据要求(由我们的客户)更新应用。 部件。

供参考、对闪存进行更新时没有问题。

或许需要思考的一些要点：

- SYSCLK 设置为120MHz
      /*通过晶振'25MHz'设置 sysClock '120MHz'*/
      SysClock = MAP_SysCtlClockFreqSet ((SYSCTL_XTAL_25MHz |
                                          SYSCTL_OSC_MAIN |
                                          SYSCTL_USE_PLL |
                                          SYSCTL_CFG_VCO_480)、120000000)；

-我们使用前缀为'ROM_'的所有'FLASH'服务函数
 ( ROM_FlashEras()；ROM_FlashProgram())

－'ROM_FlashProgram()’部分(写入长度)为512字节

－在'ROM_FlashProgram()'之后，我们将延迟下一个闪存部分
     /*延迟*/
     ROM_SysCtlDelay( sysClock/100uL )；
     注意：在您的情况下、它可能会更长一点、因为
     同时、我们还从 USB-Memstick 读取数据。

-未使用 WD (仍被禁用)

-未使用 RTOS

也许它会有所帮助。

此致
WJ