Thread 中讨论的其他器件：UNIFLASH、 SysConfig
OAD Yikes! [SDK 7.40]
这是一个很难的问题。 在 CSS 调试器中调试持久应用程序时、当每个块从应用程序传输到设备时、持久应用程序会在此过程中成功擦除和编程每个2KB 页。 在 hte 下载的末尾设置断点、我可以看到从0x32000到其末尾的主应用程序范围的闪存的正确内容(所有标头和程序数据都完好无损)。 太棒了！
因此、我将 MCU 引导、持久应用和主应用刷写到器件中、然后引导到主应用程序(运行状况良好)中、该应用程序会将器件置于 OAD 状态、使主应用程序 HDR 无效、然后启动持久应用程序 int eh 器件。 移动应用程序会看到持久应用程序、连接并开始 OAD 流程。 验证图像标头后、模块开始从应用移至器件。 这看起来与调试器中一样(对人类来说)。
但是、在 OAD 下载周期结束时、MCU 引导会引导回 OAD 持久应用程序、而不是主应用程序。 事实上、主应用的所有扇区都会被擦除、但不会进行编程。
顺便使用 UNIFLASH、当我们将所有三个代码映像编程到闪存中后、可以导出闪存映像并与完整的闪存映像进行比较。
我们看到的是、如果我们在调试器中启动、刷写过程会起作用、如果通过 MCU 引导在调试器外部、那么我们只会看到已擦除的页面(在两种情况下都激活了相同的持久应用代码)。
现在、显而易见的项目是检查 CCFG 中针对每个组件的设置、它们均设置为相同(CSS 中的默认设置)、需要特别注意 syscfg 中用于 MCU 引导的设置、因为该十六进制文件输出将提供 CCFG。
通过观察调试器/后置调试器中的内容、我们可以看到唯一的区别是、在调试期间和通过 MCU 引导(关闭调试器)引导之后处于活动状态的 CCFG 映像是引导 cfg 记录和引导记录(SP、VT、EP)的指针及其 CRC 值。 这看起来很正常、我们的结论是、运行调试器或正常运行时、我们的闪存保护设置与之相同。
经过多次检查、我们唯一能够想到的是在调试器中运行的情况下、mainapp 的闪存区域已被擦除(将 OUT 文件下载到目标期间)。 当在调试器之外运行时、每个必须擦除的页中都已经编程了实际代码。 不确定该差异是否会因擦除周期中的一些时序差异而影响我们的问题。
希望有人对此问题提供一些意见、这是向我们的生产团队发布新 CC2340R5项目的最后一步、令人有点惊讶的是、通过 CSS 获得的结果与完全耗尽编程闪存的情况不同。
有什么想法？
