[参考译文] 编译器：从上的内部闪存运行应用程序并初始化闪存控制寄存器：

Pat，

InitFlash()函数应该从RAM执行，而不是从flash执行。 原因是，此代码启用闪存管道并配置等待状态。 随着闪存等待状态控制闪存访问时间，闪存指令提取可能会损坏，从而导致PC丢失。

此致，
Manoj

感谢Manoj的回答，但我的问题有点深。

我从RAM进行了初始化，但在对函数进行汇编代码检查后，初始化闪存寄存器，我发现在返回到闪存执行之前刷新管道所需的8个等待周期未达到(我只有5个)。

实际上，优化级别设置为0，这足以在我的等待循环中删除我使用的递减：

waitCycleNumber =8；

while (waitCycleNumber >0)

｛

waitCycleNumber --

}

我知道TI不建议处理解决方案，但禁止从C函数启动ASM代码。

我有一个解决方案，就是宣布waitCycleNumber为volatile，在这种情况下 ，我有8个wat循环。

为了结束代码，当返回到闪存执行时，我检查寄存器配置是否正确，否则我会引发故障并阻止执行。

问题是，在航空过程中，快速修改代码会对所有测试和文件都处于发布状态的工作量产生重大影响。

此外，客户提供新功能的可能性很高，此更正将在稍后完成。

但现在，为了保持头脑清醒， 我想清楚地了解用户反馈中只有5个等待周期而不是8个等待周期的风险是什么？

感谢您的反馈。

我无法跟进您的问题。 但是，我很想知道为什么建议的等待周期为8，而您只希望有5个等待周期。 另外，我不明白你怎么得到5个等待周期？ 为什么不能提高呢？

Manoj

我们以为我们增加了8个循环。

编译器优化已在检查汇编代码时删除decrese计数器。

因此，我们只有5个周期(一个MOV和一个B装配指令)，而不是8个预期周期。

代码更改需要2分钟，但由于此检查是最后一次检查，并且所有的具体化，设计，代码，单元测试，验证测试都已发布，因此此代码更改需要在新版本中再次执行所有操作。

因此，我想确切了解在管道级别发生了什么，以及当程序计数器从RAM转到闪存时到底做了什么。
对细节可能有什么影响。

感谢Manoj关注我的问题。

感谢您对Manoj的回答。

我完全理解德州仪器(TI)的要求，例程是从RAM运行的，需要8个周期来刷新管道。

但是，我还有另一个问题：这是缺失1个周期还是缺失7个周期的相同结果吗？

这是我们配置闪存并在RAM中执行的C函数：

void ATCU_DRVDSP_CONFIG_FLASE(void)

｛

   /*内部数据*/

   UINT16细胞指数；

 

   /*算法开始*/

 

   /*启用Flash管道模式以提高从Flash *执行的代码的性能

   gv _sFlashRegs.FOPT.ENPIPE = 1；

 

   /*设置闪存的页面和随机等待状态*/

   gv _sFlashRegs.FBANKWAIT = C_FBANK_WAIT；

 

   /*设置OTP的等待状态*/

   gv _sFlashRegs.FOTPWAIT.OTPWAIT = C_OTP_WAIT；

 

   /*等待八个周期，让写入指令通过CPU管道传播。 */

   /*这必须在进行return-from函数调用之前完成。 */

   CycleIndex = C_UTIL_pipfil_flush；

   While (cycleIndex > 0U)(周期指数> 0U)

   ｛

       细胞周期指数--；

   }

 

}/*   ATCU_DRVDSP_CONFIG_FLASH */结束

我是否应该考虑从生产线开始需要8个周期：

- GV_sFlashRegs.FBANKWAIT = C_FBANK_WAIT；

或

- GV_sFlashRegs.FOTPWAIT.OTPWAIT = C_OTP_WAIT；

 

感谢您的回答。

Manoj

出现此问题的原因是，如果我们 检查汇编代码以查看 仍在管道中的指令。

 当离开RAM并返回闪存时，只 剩下3个有关OTP等待状态配置的汇编指令。

在  我们的软件中进行此配置后，第一次访问OTP大约需要3000个循环。

是否可以说：

－在寄存器配置后，我们至少有8个周期与闪存(FBANKWAIT)相关  

-我们在寄存器配置(OTPWAIT)后很长时间内访问OTP

或者 ，在任何情况下都需要8个周期，我们必须符合德州文档的最终要求？

很抱歉在这一点上坚持，但对我们的后果目前确实不一样。

谢谢你Manoj。