我们开发了一个内部引导加载程序、该加载程序在受保护的闪存存储器之外运行、从而使 NVM 程序空间闪烁。
最近、我们使用此引导加载程序例程运行到无法刷写 NVM 的器件中。
我们确定的唯一可能的纠正措施是在擦除闪存 NVM 然后对闪存 NVM 进行编程之前、将系统时钟从80MHz 降低到10MHz。
请确认时钟 频率从80MHz 更改为10MHz 将确保 TM4C123AH6PMI7处理器上的 NVM 成功刷写。
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
我们开发了一个内部引导加载程序、该加载程序在受保护的闪存存储器之外运行、从而使 NVM 程序空间闪烁。
最近、我们使用此引导加载程序例程运行到无法刷写 NVM 的器件中。
我们确定的唯一可能的纠正措施是在擦除闪存 NVM 然后对闪存 NVM 进行编程之前、将系统时钟从80MHz 降低到10MHz。
请确认时钟 频率从80MHz 更改为10MHz 将确保 TM4C123AH6PMI7处理器上的 NVM 成功刷写。
我不清楚为什么在 受保护的闪存空间中执行引导加载例程时,在引用 ROM_FlashEras()和 ROM_FlashProgram()时必须将时钟设置为16MHz, 但在其他时间使用80MHz 时钟是可以的。 在引导加载例程内、只有 ROM_FUNCTION 调用在受保护的闪存空间内执行。 除非 时钟明显降低到16MHz,否则 ROM_FlashEras()函数调用中的引导加载例程会失败。我们将在调用引导加载例程之前禁用所有中断和看门狗计时器。 另一篇文章
建议这可能与取指令/流水线问题有关。 如果出现这种情况是为了确保降低处理器 时钟速率、只需寻找一个可靠的答案即可、这是一个有效的纠正措施。
尊敬的 Mike:
感谢您挖掘相关帖子。 老实说、我在过去几年来为该产品提供板载支持后、没有遇到过这个问题。 我错误地说、FlashErase 和 FlashProgram 应该在闪存之外运行代码的80MHz 频率下工作、而不会意识到过去曾报告过类似的问题。 我认为16MHz 可以工作的原因是 TivaWare 引导加载程序使用 PIOSC 以16MHz 的频率运行。 我没有看到任何报告说它不起作用。 TivaWare 引导加载程序似乎存在几个因数、无法如报告所示运行到问题中。 1)代码以小于40MHz 的16MHz 频率运行;2)在该频率(16MHz)下未启用预取缓冲器;3)程序和擦除代码从 SRAM 运行;4)在引导加载期间不启用中断。 引导加载程序设计恰好避免了这一问题、而是避免了其架构不需要在整个 SYSCLK 上运行。 根据 Amit 在提交帖子时的建议、在对闪存进行编程和擦除时、最好从 SRAM 中运行代码。 请参阅 BL_STARTUP_CCS.s 文件、了解首先将引导加载程序从闪存复制到 SRAM 的引导加载程序代码。