[参考译文] MSPM0G3519：访问导致硬故障的 FACTORY 区域数据。

您好、

您如何访问工厂地区？

马修

我正在使用 DL_SYSCTL_configSYSPLL () 配置 SYSPLL、内部函数调用 可访问.TrimTable 的 DL_FactoryRegion_initTrimTable。  

我会仔细检查您是否跳到了内存中的正确位置

dev.ti.com/.../node

是的我已经检查了寄存器表 ro R1 R2 R3 PC LR xpsr。 我获得的重置处理程序正确。  

一个问题。 如果代码可以在没有引导加载程序时访问出厂区域、 但是,当我把应用程序放在不同的位置和引导加载程序在 0x0000 它进入硬故障. 引导加载程序是 TI 提供的客户安全代码。 以下代码是否会如何启用或禁用限制 FACTORY 区域访问的内容？

您的引导加载程序使用哪个时钟源？

进入该应用时、需要将其设置为 SYSOSC、以避免触发勘误表 FLASH_ERR_01。 [参考勘误表 (SLAZ758B) 第 7 页和 TRM (SLAU846B) 第 2.4.5 节]。

当我在引导加载程序中配置 PLL 并从应用程序代码中删除 PLL 配置时、一切都正常工作。 FACTORY 区域是否只能通过闪存开头加载的代码进行访问？  

我已经添加了这个预防措施。 错误中提到的解决方案我添加了。 保持闪存等待状态 2。  

如果应用程序没有配置 PLL、则（我们想）它不会使用 2 个等待状态引用 FACTORY 区域、因此不会触发 FLASH_ERR_01。

这听起来不像您所想到的结果、但它会起作用。

我想这是一个错误的原因是,通常添加等待状态不会伤害你（只是减慢你一点）,但在这种情况下它确实.

原谅我,但不完全明白。 要解决此问题、我需要具体做些什么？

如果您在引导加载程序 (SYSPLL 或 HFXT) 中使用除 SYSOSC 之外的器件、则应在调用用户程序之前切换回 SYSOSC。 然后该程序可以根据需要设置 MCLK。

我大致记得一个 driverlib 函数、它将 MCLK 设置回 SYSOSC、但这里没有我的材料  

您是否有此方面的文档？ 我是指这个时钟变化如何影响访问某些区域的代码？ 如果引导加载程序在 SYSCOSC 以外的时钟源上运行、以及为什么它需要在跳转到引导加载程序之前切换回 SYSOSC。

TRM 第 2.4.5 节规定、如果使用其中一个高速时钟、则闪存等待状态会设置为 MCLKCFG.FLASHWAIT、该值为=2。 （您可以更改此值，但可能不想更改。）

FLASH_ERR_01 的说明指出读取=2 个等待状态下的出厂区域将触发硬故障。 在禁用 PLL 之前调用 initTrimTable()、因此它仍在运行时钟（以及等待状态）、即从启动（即从引导加载程序继承）。

如果您在引导加载程序中使用高速时钟（例如 PLL） 、我预计您会在调用应用程序入口点之前调用该函数。 或者：不要在引导加载程序中使用高速时钟（与 SYSOSC 保持一致）。

更笼统地说：引导加载程序似乎 应该（尽可能）以类似于复位时的条件调用应用程序、因为应用程序可能期望这样做。