[参考译文] TM4C129DNCPDT：系统时钟值 isn#39；t meet 寄存器。 它可能是 Errata sysctl#22

它们使用的是哪个版本的函数 SysCtlClockFreqSet()？

区别在于 TM4C129DNCPDT 上增加了安全硬件加速器。

尊敬的 Bob：

他们使用的最新 Tiveware 版本是2.1.4.178。 我不确定此问题与驱动程序库或硬件有关。 此问题是随机的、我花了4小时来重复此问题。 客户对 TM4C129D 的开/关功能进行了应力测试。 请检查问题吗？ 谢谢！   

您好 Lisa、

[引用 user="Lisa Ding]他们以前在 TM4C129DNCDPT 上遇到 SYSCLK 问题、并尝试在使用 TM4C1294NCPDT的 Launchpad 上重复出现问题。 他们不能重复问题，[/报价]

应用勘误表#22 后、是否可以解决 PHYSDIV 问题？  也许 加电复位时序或其他电源总线问题会导致 MCU 中止 PHYSDIV 的 MOSC 程序？

在定制 PCB 上、LaunchPad 克服了某种硬件问题、这似乎更有可能。  有几个因素会影响 MCU 性能、例如回流温度过高或与记录的斜坡均热曲线不一致、回流之前 MCU 的相对湿度以及许多其他因素、很难精确确定任何一 个原因。  消除过程是客户发现 Launch Pad 和定制 PCB 之间有何不同的唯一方法。

我建议客户首先  比较 VDD 上电上升时间(MCU 复位)和3V3 LDO 、以确保它们与 LaunchPad 相似或优于 LaunchPad。

您好 BP101：

感谢您的回复。 我们实际上在连接 TM4C129的 Launchpad 上重复了此问题。 客户添加了3.3V PMOS 并使用 GPIO 控制 PMOS 开/关。 它们将 TM4C1294NCPDT 更改为 TM4C129DNCPDT。 它们还为我提供3.3V 波形。 请参见下图。  

[引用 user="BP101]22勘误表 后解决问题的方法是否不是 PHYSDIV？  也许 加电复位时序或其他电源总线问题会导致 MCU 中止 PHYSDIV 的 MOSC 程序？[/报价]

我们如何知道这个问题与复位时序 或电源总线问题有关？ 我们如何知道 MCU 中止 PHYSDIV 的 MOSC 程序？ 实际上、此问题将触发硬故障、客户的代码被困在 FAULTISR 中。 请参阅故障状态寄存器图片。 谢谢。  

客户提供的 PQ4 (DIVSCLK)波形、第一个时钟资源是内部振荡器、频率为16MHz、第二个时钟频率为25MHz、我想这是外部晶体频率。 客户使用 MOSC 作为 PLL 输入资源。 第三个是7.5Mhz、这是不正确的 DIVSCLK。 它应该是12MHz。  

 DIVSCLK 波形

3.3V 波形

NVIC_FAULT_STAT/NVIC_HFAULT_STAT

 

[引用用户="Lisa Ding]感谢您的回复。 我们实际上在连接 TM4C129的 Launchpad 上重复了此问题。

好的、与之前 的评论非常不同、 可能是 PMOS 开关有问题。 那么、PMOS 开关的 GPIO 控制源于 Arduino 焊盘吗？

[引用 user="Lisa Ding"]我们如何才能知道此问题与重置时序 或电源总线问题有关？

复位上升时间的捕捉必须与3V3电源上升时间重合 、每个时间都是稳定的、 您的捕捉会忽略 复位脉冲。 请注意 ，复位期间的 LDO 接通纹波 (请查看 LDO 数据表负载瞬态响应图)可能会有一些布局连接 ，而 PMOS 开关为 LDO 供电时会产生不必要的电流 ，以及哪种开关？ 是否具有 GPIO 使能引脚？ 3V3 LDO 从定制 PCB 或 LP 启动捕获、它们是否具有相同的启动纹波？      

[引用 user="Lisa Ding"]我们如何知道 MCU 中止了 PHYSDIV 的 MOSC 程序？

客户添加的电路 似乎已得到证实、甚至导致 了问题、并且堆栈在 POR 期间损坏、从而导致总线故障、从而导致硬故障、因此 PHYSDIV 位永远不会被置位。   控制系统 (负载开关)的方框图原理图也有助于阐明 GPIO 控制方法。  

[引用 user="BP101]OK 与之前 的注释大不相同、 可能是 PMOS 开关可疑。 因此、PMOS 开关的 GPIO 控制源于 Arduino 焊盘？[/QUERPIT]

[Lisa ]是的。 它们使用 Arduino EVM 来控制 PMOS 开/关

[引用 user="BP101]What kind of switch?(什么类型的交换机？) 是否具有 GPIO 使能引脚？ 3V3 LDO 从定制 PCB 或 LP 启动捕获、它们是否具有相同的启动纹波？  [/报价]

[LISA]：PMOS：

https://www.digikey.tw/products/zh?keywords=NDT452AP

 客户将 PMOS 连接到3.3V、并使用 GPIO 连接到 PMOS 栅极。   从 Launchpad 进行3.3V LDO 启动捕获。  

[引用 user="BP101"]客户似乎 已证明或甚至导致 问题[/引用]

[LISA]：客户在自己的电路板上面临此问题、并在 Launchpad 上重复此问题。

BP101 说：

堆栈在 POR 期间损坏、导致总线故障导致硬故障、因此 PHYSDIV 位永远不会被置位。

[LISA]：您是指在设置 PHYSDIV 部件之前系统触发硬故障吗？ 客户使用 Tivaware 引导加载程序示例并添加 GPIO/SYSCTRL 延迟代码。 如果堆栈损坏、则意味着这是软件问题。 我们如何证明堆栈已损坏并触发总线故障？ 我们是否可以使用闪烁代码、这是最简单的代码。 它不应导致堆栈损坏。  谢谢

[引用 user="BP101"]  控制系统 (负载开关)的方框图原理图也有助于阐明 GPIO 控制方法。  [/报价]

[LISA]：请参见  下图

 

您好 Lisa、

这些因素的结合可能会导致崩溃、从而无法通过添加更多硬件来排除使主要问题复杂化的问题。 首先、我建议客户查看数据表第223-224页、并验证当 RST 在适当的时间内复位时模拟 LDO 是否稳定、如表27-14 图27-11所示。 这正是我建议  客户 在3V3上电的同时添加 RST 引脚捕获的令人恼火的原因。  甚至可以检查 RESC 寄存     器、检查 BOR 是否在 PHYSDIV 值未设置时发生 LDO 电源下降事件。 BTW LaunchPad 违反了数据表中的 RST 引脚建议。

与 实际 负载开关相比、添加 PMOS 开关可能不是最佳 方法。 推荐客户查看 TI 负载开关研讨会(非常好！) 并查看数据表 TPS22969或其他 PMOS 负载开关。 也就是说、如果他们真正需要对 实验进行控制、则必须消除   添加子系统时导致的所有异常情况。

[引用 user="Lisa Ding"][LISA ]：您是指设置 PHYSDIV 部件之前系统触发硬故障吗？ 客户使用 Tivaware 引导加载程序示例并添加 GPIO/SYSCTRL 延迟代码。 如果堆栈损坏、则意味着这是软件问题  

好的、串行引导加载程序会在实验中添加一个完整的其他蠕虫 CAN、因为它会将闪存 存储的应用程序的副本瓶胚到 SRAM 中执行。  MOSC 通常 会再次 被应用程序配置(main()) 、 也许在  主系统中重新配置 MOSC 后添加1秒的 SYS 延迟。  这应该 会阻止  随后执行将闪存应用程序复制到 SRAM 后可能出现的任何竞争条件。

也许明智的做法是客户只关注 在  配置 MOSC 后通过输入 while (1)循环来设置 PHYSDIV 值的问题。 闪存中没有其他代码 、并且完全擦除串行引导加载程序的闪存存储 器、从而启动 PHYSDIV 测试应用程序@0x0。 这样 、它将确认或消除软件是 PHYSDIV 问题的原因。  

您好 BP101：
感谢您的回复。 我想知道、如果 MCU 在 MOSC 设置之前中止。 为什么在我连接 TM4C129并重写 PSYDIV 值后时钟变为正确？ 重新写入 PSYDIV 后、MCU 应仍处于故障状态？

[引用 user="BP101]CPU 处于硬故障状态时、不确定如何将 PHYSDIV 位重写到控制寄存  器中、更不用说它如何在不首先清除硬故障的情况下读取寄存器。  [/报价]

我只需使用仿真器、然后使用 CCS 连接到 TM4C129。 我首先启动目标配置、然后连接到目标。 在此步骤中、我可以访问 TM4C129寄存器并对其重新编写。

此外、如果 TM4C129退出硬故障状态、我 不应该在寄存器中看到硬故障标志。 但是、我确实在 寄存器中看到了故障标志。 这也是一个奇怪的部分。  

我检查了显示 MOSC 故障复位的数据表。 如果 MOSC 配置不正确，MCU 是否会生成 MOSC 故障复位？ 如果它将生成复位、则 MCU 不应陷入故障状态。

[引用 user="Lisa Ding"]我首先启动了目标配置，然后连接到目标可能 ICDI 正在连接时重置目标？ 您可以验证  是否在调试属性中设置了用于在连接时重置目标的复选框。

[引用用户="Lisa Ding"]在此步骤中，我可以访问 TM4C129寄存器并重新编写它。

您实际上看到 DIVSCLK 输出改变频率了吗？

[引用用户="Lisa Ding]此外、如果 TM4C129退出硬故障状态、我 不应该在寄存器中看到硬故障标志。 但是、我确实在 寄存器中看到了故障标志。 这也是一个奇怪的部分。  [/报价]

这 似乎 是一个相当好的迹象、表明 CPU 未在连接时复位 或未 点击调试寄存器持续刷新按钮。  也许您会看到上次调试的缓存结果、尤其是  在当前调试连接期间发生硬件故障时、刷新不会更新寄存器视图。

[引用 user="Lisa Ding]我已查看显示 MOSC 故障复位的数据表。 如果 MOSC 配置不正确，MCU 是否会生成 MOSC 故障复位？[/QUEST]看门狗计时器可能会在发生故障时重置 MCU，而您不 会意识到发生故障，尤其是 在应用程序中没有闪烁的 LED 指示灯时。 检查您的 MCU 的勘误表、它可能会报告 MOSC 故障。 这当然会推断出这种失败确实在发生。

您是否已从应用程序固件中删除引导加载程序？  

您好、BP1、

[引用 user="BP101]ICDI 可能会在连接时重置目标？ 您可以验证  是否在调试属性中设置了用于在连接时重置目标的复选框。

我 认为 ICDI 不会复位器件。 因为我连接 TM4C129、寄存器设置不是默认值。 这是客户的代码设置。 [引用 user="BP101"]您实际上会看到 DIVSCLK 输出更改频率？

是的。 我在第一个帖子中提供波形。 当我重新写入 PSYDIV 时、DIVSCLK 频率会恢复正常。

在客户设置中、TM4C129不会运行整个项目、因为客户将在执行引导加载程序之前重置 TM4C129。 谢谢！

#include "inc/hw_gpio.h"
#include "inc/hw_memmap.h"
#include "inc/hw_sysctl.h"
#include "inc/hw_types.h"
#include "driverlib/sysctl.h"
#include "driverlib/gpio.h"

#define system_delay_ms (120000/3)


SysCtlPeripheralEnable (SYSCTL_Periph_GPIOQ)；

GPIOPinConfigure (GPIO_PQ4_DIVSCLK)；

GPIOPadConfigSet (GPIO_PORTQ_BASE、GPIO_PIN_4、GPIO_Strength _2mA、GPIO_PIN_TYPE_STD)；

GPIODirModeSet (GPIO_PORTQ_BASE、GPIO_PIN_4、GPIO_DIR_MODE_HW)；

SysCtlClockOutConfig (SYSCTL_CLKOUT_EN | SYSCTL_CLKOUT_SYSCLK、100)；


SysCtlClockFreqSet ((SYSCTL_XTAL_25MHz |
SYSCTL_OSC_MAIN |
SYSCTL_USE_PLL |
SYSCTL_CFG_VCO_480)、PLL_FREQ)；
SysCtlDelay (10*system_delay_ms)；//延迟10ms

SysCtlPeripheralEnable (SYSCTL_Periph_GPIOE)；

GPIOPinTypeGPIOOutput (GPIO_Porte _BASE、GPIO_PIN_5)；
GPIOPinWrite (GPIO_Porte _BASE、GPIO_PIN_5、GPIO_PIN_5)；

您好 Lisa、

[引用用户="Lisa Ding"]在客户设置中，TM4C129不会运行整个项目，因为客户将在执行引导加载程序之前重置 TM4C129

不正确的东西 是引导加载程序、您首先描述  的是 POR 之后的执行、这将在每次执行时推断。 稍后发布 Lisa 提示 (ROM)类型的引导加载程序只执行一次。  

您好 BP101：
感谢您的回复。 但是、如果闪存具有代码、TM4C129将不会执行引导加载程序。 它应该直接跳转到 main。
我想知道为什么我重新连接到 TM4C129并重新写入 PSYSDIV 值。 DIVSCLK 变为1.2MHz 时钟、这是正确的。

[引用用户="Lisa Ding]感谢您的回复。 但是、如果闪存具有代码、TM4C129将不会执行引导加载程序。 它应该直接跳转到 main。 [/报价]

这似乎与   加载引导加载程序的先前几个帖子有所不同。  我们 必须假设您 推测 (闪存)、因为您没有加 载(ROM)引导加载程序、并且 ROM 仅在   闪存(完全)擦除后加载应用程序、 为什么要启动 引导加载程序？

所有博文 都必须非常小心 地描述  此论坛中的引导过程、因为 存在两个唯一版本的引导加载程序。   此外、我还记得 有人评论 说、在 MOSC 之后会出现1秒的延迟、而不是 像这样 的污染代码所示的那样100ms。      

现在可以看到应用程序已从一天前发布的内容中清除。 论坛回复功能不允许页面滚动回查看过去的评论(DIS-Like)。

您好 BP101：

[引用 user="BP101]\n 所有帖子 必须非常仔细 地描述  此论坛中的引导进程是 存在两个唯一版本的引导加载程序。  所有这段时间 都认为您使用 的是闪存 引导加载程序、而不是 ROM 引导加载程序、因为您说它是在实验中执行应用程序之前加载的。  显然、一旦应用程序被 ROM 引导加载程序加载、 闪存存储器 不会在每个 POR 周期被擦除。  今天、您重复 了几 个先前的帖子、状态引导加载程序未执行、这可能 会使 所有帮助者对您的原因感到困惑？ 与 ROM 引导加载程序一次性执行不同、闪存嵌入式引导加载程序每次在 POR 之后执行。[/QUERP]

很抱歉让你困惑。 实际上、客户加载了 boot_serial 代码。 引导加载程序将首先执行客户的代码。 感谢您的更正

[引用 user="BP101]*您 的应用程序语法(方法)似乎 随机导致 CPU 硬故障，而不是#22勘误表。  不能 将#include 指令放置在 (main())中、 放置在 C 文件顶部、不是执行应用程序的一部分。   在同一功能中为 DIVSCLK 配置两次 GPIO 端口是 个好主意吗？  此外、我还记得 有人评论 说、MOSC 之后会延迟1秒、而不是 像 这样的 psoed 代码所示的100ms。

我要求客户移出引导加载程序、他们将再次进行实验。 在我们获得结果后将更新。 谢谢

请注意、我在解释串行引导加载程序(SBL)偏移的文章中编辑了几篇文章。 如果 SBL 未被放置在32k 边界上、LM 闪存会对应用程序的地址空间进行写操作、或者更糟糕的情况是将它们合并在一起。 是我在几天前要求客户移除 SBL 的原因。

不确定 TI 为何选择名称(串行)、尽管它在 ROM 之前存在、但两者都提供应用的串行端口负载。 当我多次(闪存) BL 时、您马上就知道它不是 Rom BL。 在我看来、如果有人说 SBL、我从过去的经验中知道、RBL 不存在、但现在两者都存在、并且都是串行加载程序。 也许更好的 TI 弃用了 SBL 名称、将其重命名为 FSBL 是为了让每个人都很理智。

您好 Lisa、

帖子已解决？

您好 BP101：
客户没有获得新的 Launchpad、因此无法进行不使用引导加载程序示例代码的新实验。 谢谢

您好 Lisa、

[报价用户="Lisa Ding"]客户没有获得新的 Launchpad [/报价]

不知道 客户 为什么认为    在(完全)擦除闪存存储 器时需要新的 LaunchPad、从而消除了串行引导加载程序的存在。  

客户 可以使用 LM 闪存编程器进行完全擦除、并 将测试应用程序写入到偏移量0x0000.0000的单一分离位置。

您好 BP101：
因为客户的原始 Launchpad 已损坏。 这就是他们需要新的原因。

您好 Lisa、

[引用用户="Lisa Ding"]因为客户的原始 Launchpad 已损坏。

 曾经想过我 的产品会被损坏、但现在能够   通过 LM 闪存编程器恢复或解锁 DAP。 确实与事故相关、似乎是在最坏的时候发生的。

您好 BP101：

客户已删除测试代码中的引导加载程序部件。 然而，问题仍然存在。

您好 Lisa、

注意到在    GPIO 配置期间、客户测试代码依赖于 PIOSC、然后突然切换到 MOSC 、 随后进行更多配置。

 首先配置 MOSC、然后配置 GPIO、而不依赖于 PIOSC、而只在配置 MOSC 之前、这似乎不是谨慎的？

您好 Lisa、

 我不确定会发生什么情况。 我们内部可能没有得到良好的复位。 您知道该测试期间器件的断电时间吗？ 如果器件断电时间更长、则此问题的发生频率是否会发生变化？ 从您发布的一幅示波器图片中、它看起来像是外部电压降至360mV。 如果断电时间更长、它会下降到更低的水平吗？

[报价用户="Bob Crosby"]您是否知道该测试期间器件断电的时间[/报价]

[LISA]：断电时间为935ms、通电时间为65ms。 请参阅下面的波形

[报价 USER="Bob Crosby"]如果器件断电时间更长，则此问题的发生频率是否会发生变化？

[Lisa：从未这样做过。 您希望延长断电时间的原因是要保持断电时间更低？

[报价用户="Bob Crosby"]如果断电时间更长，它是否会下降[/报价]

[Lisa：是的。 客户表示如果关断时间更长、压降会更低。

我已查看数据表、其中 TM4C129复位下降电压为1.84v、客户的电路板偏移为360mv。 它应该能够生成 POR。

我想知道时钟波形是16MHz -> 25MHz -> 7.5Mhz。  16MHz 看起来像内部 振荡器、25MHz 是外部 振荡器值。 7.5Mhz 为 SYSCLK。  TM4C129在上电时使用内部振荡器、然后由于 客户使用 MOSC 作为 PLL 输入 源、因此更改为外部振荡器。 如果16MHz 更改为25MHz、我认为 129已经复位并运行了代码。  发生问题时、我与129建立了联系。 我已检查寄存器设置、将其更改为客户设置、并将 PSYSDIV 重写为2。 时钟输出发生变化、我将 PSYSDIV 重写为1。 SYSCLK 变为12MHz。 PSYSDIV 似乎没有加载正确的数字。  有一个勘误 SYSCTL#22、它显示"这个寄存器值可能不会被载入物理分频器、导致系统时钟被2分频。"  请帮您验证它吗？ 谢谢。  

您好 Lisa、

也许您可以检查 GPIO PQ4=DIVSCLK (MPU 引脚102)是否与 U4_OC2输出断开。 OC2引脚5保持低电平、每次 DIVSCLK 信号峰值和(可能)导致 LaunchPad 出现故障时、似乎会在 LDO +3V3上出现短路。 表26-6显示 DIVSCLK 仅存在于 PQ4。

周围环境、

  一段时间前尝试在 X11/Booster Pack 接头上获得120MHz DIVSCLK 输出。  奇怪的是、信号是 不稳定的可怕的方波、Amit 给出了一些 DIVSCLK 的测试代码、在信号质量或产生正确的频率方面没有任何区别。  在 U4 OC2信号  保持在低电平状态并影响 PQ4输出时、未调用。

突然意识         到、这个问题可能与我的应用相关、我稍后将通过 GTO 端口监测 PQ4报告 OC、可以是 DIVSCLK、MCU 引脚102。