[参考译文] RTOS/EK-TM4C1294XL：MCU#39像圣诞灯一样燃烧

在过去的一周(可能甚至更长)、(近)记录(和持续)的低温大幅降低了我们良好加热(美国中西部)家庭/办公室的湿度(内部)。    因此、尽管您有"免责声明"(并未采取任何措施)、ESD 仍会"堵塞警察队伍"、如"主要嫌疑人"。   您所在城镇的新闻标题"多个非动画对象(LPad)-"自行投影"-从高高的悬崖上"-证明不能错过！

在家里-我注意到(偶然/轻微)"猫狗"接触期间 -"发生了冲击！"   (从未记录过！)   在办公室-如果我们没有"签入"(我们的 ESD 腕带)-"NUM Lock"(在键盘上)将熄灭。

我会更倾向于称"ESD"-而不是(任何) RTOS 作为"原因代理！"     请确认 MCU 唤醒的日期/时间。   鲜花(通过 FTD)是"在翅膀上！"   (缓慢的 Willow 似乎(最合适的)...)

而且——应该是一棵“昏暗”(甚至没有灯光)的树——下一个圣诞节——太令人沮丧了…… 您可能会转而选择"蜡烛"(长期(过去)受雇)-并且可能在"极端" ESD 下生存(甚至) -您(又名：无人)经常会产生但令人失望的结果。     对于对自己(非常有兴趣)的"ESD 抗干扰"蜡烛感兴趣的人：    e2e.ti.com/.../653117

Honeywell 大容量熔炉加湿器放置的气流使所有房间保持36%的相对湿度。  在玻璃上形成的水滴会在玻璃上保持在隔间的静电。 然而、另一个 LaunchPad 同样失败 了、去年 夏天报告了此论坛、并且接近相同的 RTOS 闪存和稍后 删除的 RTOS。   在其他几个论坛中、当时没有什么大的神秘、LP 失败也没有得到解答。

奇怪的是两 个问题的 LaunchPad (同一批次) MCU 内部温度传感器 检测到52-54*C 、10-11% CPU 使用率(NoRTOS)。  之前的批次 报告 45-48*C 温度范围 24% CPU 使用率(NoRTOS)。  

请注意  、54*C MCU 中的 CPU 使用率下降、报告10-11%表示 PLL 的运行速度可能比480MHz 快得多、SYSCLK 远高于120Mhz。 因此 、RTOS Clock_tick 的运行速度远高于1000us、并使用(IF)指令中止任务。

这一天的引用：“欺骗我，一次给你丢脸，两次给我丢脸。”   

这些 MCU 芯片(RA2)似乎  勉强与之配合使用、并且加载 RTOS 以某种方式将其推向边缘。

对于 MCU 提取 替代方、BYORP "带上您自己的回流焊膏" LOL。

很久以前-著名的"技术烹饪手册作者" Don Lancaster 建议-"首先责怪自己-最后责怪 IC！"   公司/我早就发现了这个事实！

如果您(实际上)希望通过(更正确的、"独立于 MCU 的方法")监测 MCU 的温度、则小型温度传感器可能会在 MCU 顶部"热粘合"。 (并通过单独的方式进行监控)

如您所知，它证明(总是"不明智")，"利用 DUT*进行/提供其(自己)的测量----总是怀疑测量。

* DUT (被测器件)

您是否可以使用"DUT"来"制作和报告"关键发现、回应"他(自己)的律师-为客户提供了"傻瓜"？"

我“祈祷”——但(不知为何)——“忘记了这些话。”   Lancaster 先生的-(非常)正确的"技术"指南-可能需要进一步(即一些)考虑...

BTW -我的圣诞树灯(那些尚未被避难所狗/猫狗摧毁的灯)-继续"亮光"-显然"不受"英国石油公司的不幸...

更认真地了解 TI 如何或是否有任何计划在芯片级处理勘误表 SYSCTL #22？ 否则、连接严重超频点后、开始想知道外部120MHz OSC 和旁路 PLL 如何产生25MHz 以供 EMAC0使用。

去年7月装回盒中的一个 MCU LaunchPad 仍然有效。 由于 MCU 温度快速达到60*C，PLL 将不再分频(/2)，因此需要散热器来防止其散热。 如果这不能描述超频 PLL、我的圣诞树灯(全部700个)也不需要壁式开关调光器。

什么 是内核利用、它也会影响具有 ARM 处理器的器件。 不是超频 PLL、但同样有趣。   

https://www.digitaltrends.com/computing/intel-cpus-suffer-bug-requiring-performance-reducing-fix/?utm_content=bufferac5da&utm_medium=socialm&utm_source=facebook.com&utm_campaign=DT-FB

尊敬的 Bob：

假设是 Todd 或另一位 TI 工程师这个论坛最近说过、SYSCTRL#22在所有 RA2 MCU 中并不一致。 MOSC 函数在早期调用效应 Tivaware 2.1.2、但后来的库似乎仍然影响部分但并非所有 RA2 MCU。 再次检查 SYSCTRL#22是特定于库版本的勘误表、ROM 加载不会影响 PLL。

2.16.1.14 PLL 之前的早期 RTOS 版本未被2分频、而是在 RTOS 中配置为进行分频。 在(main.c)中添加第二个 SysCtlClockFreqSet()之前、PLL 分频器实际上是在 BIOS_start 指令之前进行编程的。 此外、应用在 RTOS 和无 RTOS 项目中都有 MAP_SysCtlClockFreqSet()。

这两个 RA2 Launch Pad 似乎正在运行随机节流 PLL 开箱即用、PLL 似乎松动了锁、然后同步重新锁定。 MCU 温度通常比其它两个 LaunchPad (相隔8个月)高出10*C 或更高(全部4个 LaunchPad RA2芯片)。 运行 RTOS 分析器 CPU 负载监控器并看到 CPU 负载反弹20%-90%构建曲折型负载曲线图最终导致总线故障精确0x3后、两个 MCU 的(可识别的)故障开始。 确认调试寄存器 SYSCTL PLL/2确实被编程。 在加载 RTOS 并重新编程 MOSC 之后、在发出 BIOS 启动命令之前、怀疑某些 MCU PLL 中的 RA2芯片会更损坏。

[引用 user="Bob Crosby"]在使用新函数后，没有听说过"超频"的报告，但确实有"欠频"的有效情况。 [/报价]

       如果在调用 SysCtlClkFreqSet()后 VCO 设置为480MHz 并且 PLL 未被4分频、 我们 是否不会以240Mhz SYSCLK 结束？  

奇怪的是   、在 (main.c)检查的调试 寄存器= PLL/2中刷写 RTOS 并设置 SysCtlClkFreqSet()之后、 在 hind sight 中、不  会产生 240Mhz SYSCLK？  仅在加载 RTOS 调试 ROV 后、才通过计时 MCU 获悉 PLL 未启用。  然而 、由于  应用 配置了 MOSC (main.c)、而不是 RTOS、调试寄存器 PLL 为/2似乎正常。  我只知道 PLL 没有在 RTOS 中被启用 、然后注意到 PLL/2没有 评估它应该是 PLL/4。

[引用 user="Bob Crosby"]f (sys)= f (VCO)/(PSYSDIV+1)
120MHz = 240MHz (1+1)[/quot]

一个人怀疑(底部)线路(预期)：  120MHz = 240MHz /(1+1)

为什么 BP101有如此多的奇怪问题？

尊敬的 Bob：

好的、我们将查看并使用 Tivaware 2.1.1.71驱动程序库来配置 MOSC 函数。 RTOS 配置页面有点误导。

在上述帖子中、您似乎正确：表5-7 25MHz XTAL 显示480MHz VCO (N=0x4)、(图5-5) VCO/N SO 240/2 =120MHz SYSCLK (如果 PLL/2)。 如果 PLL 已经在主时钟树中被2分频、则表5-7 (N=0x4)不正确。 可以回想 一下、N 是 实际 数字除数的寄存器十六进制值。
 
在这两个应用领域中、我也看到 PLL 在应用运行时似乎随机松开锁相。 CPU 使用中的循环突然2倍速度突发、PWMCLK 节拍、然后 SYSCLK 返回到正常速度。 即使在运行相对于环境室的典型预期温度的多个 RA2 MCU 中、PLL 的行为似乎也是如此。 RTOS 分析器 CPU 负载监视器显示重复的循环线图20%-90%、并可能指向我在该论坛上发布的无法解释的 PWM 突发捕获。  
据我所知、(main.c)代码不可重入 MOSC 不会在周期中重新配置。 否则、无论写入何种嵌入式代码、ARM 存储器地址指针都会跳转0x0以阻止重新进入发生。

我记录了 POR 后几个小时内的时间线 IOT 服务器温度上升情况。 尽管如此、Bob 的解释似乎适合这两个 Lpad 的(一致的) 2X CPU 使用显示。

在复制粘贴上查找一行、PLL/2.5实际上是该页面高级部分中的 SYSCLK。 显示 PLL/2.5混淆了我的看法、认为除数应该是4而不是2.5、而调试寄存器是 PLL/2、当所有寄存器看起来运行良好时。

尊敬的 Bob：

除了您对 PHYSDIV 位分频进行出色的检测工作  外、在快速火灾 PLL 配置中还可能存在其他类型的应用。  

观察 SysCtlClokFreqSet() 、PLL 有可能 跳出 锁定状态。  代码缺失 、无法测试 PLL 锁定状态的 任何时间长度  、以确认 是否保持锁定状态。 代码假定 PLL 进入一 个锁定状态、调用一个针对超时 中断环路的一遍寄存器读取(SYSCTL_PllStat_Lock)= 1。  谈论对奇迹的信任、或许 解释了 PLL 可能实际上是逐步进入和退出锁定状态的原因。

另一个代码 gotcha 期望(！=)逻辑 (NOT)将 HWREG 二进制值与已知值进行比较、通常会导致 不正确的匹配 、尤其是涉及(&)。 在这种情况下、WA 是对寄存器二进制读取值使用(&~)按位(不)。 这可能是一个 C++问题、但事实证明、它可以修复代码、这些代码可能工作不多或完全正常。

其他可疑代码：

//如果 PLL 没有变化、则不强制 PLL 锁定
//写入 PLL 设置。
if ((HWREG (SYSCTL_PLLFREQ1)！=
G_pppui32XTALtoVCO[i32VCOIdx][i32XtalIdx][1])||
(HWREG (SYSCTL_PLLFREQ0)！=
(G_pppui32XTALtoVCO[i32VCOIdx][i32XtalIdx][0]|
SYSCTL_PLLFREQ0_PLLPWR))))
｛
bNewPLL = true；
｝
其他
｛
bNewPLL = false；
｝