[参考译文] TMS320F280049：某些器件上电时出现意外的 PLLCLKEN

您好 Hang、

该专家目前已离职。 请预计回复将延迟到本周晚些时候。

此致、

Allison

更新了该主题。

我们试图找到解决这个问题的方法。  

为了恢复 CAN 通信、我们尝试确保在传输 CAN 之前设置 PLLCLKEN、以确保 CAN 具有正确的波特率。  

PLL 在驱动程序库函数 sysctl_setclock() 中进行初始化、我们发现、如果在调用  sysctl_setclock() 之前将 PLLCLKEN 设置为 1、则在该函数之后将清除 PLLCLKEN。

解决方法很简单,我们刚刚 调用了 SysCtl_setclock () 两次,并且在调用两次该函数后 PLLCLKEN 设置为 1 , CAN 通信也恢复。

这是否会导致意外风险？   

添加一个信息。 客户器件 通过写入 OTP 将引导模式固定为闪存引导。 不确定这是否相关。 但是、这样做阻止了我们 将器件置于等待引导以在 执行任何用户代码之前检查 PLLCLKEN 值。  

挂起、

因为我不在办公室、所以对迟来的答复表示歉意。

您能否确认以下 勘误表 注释是否已被确认为不是问题：

• PLL：第一次尝试锁定时 PLL 可能无法锁定
• LPM：不支持待机低功耗模式
• 系统：多次连续写入 CLKSRCCTL1 可能会导致系统挂起

根据所提议的权变措施、它似乎与 PLL 锁定有关。 在调用  sysctl_setclock() 函数两次之前、我们能否检查 它是否在正确的时间被调用？  您是否参考了示例并已经以相同的方式实现了示例？  

闪存启动正常。  

此致、

Aishwarya

尊敬的 Aishwarya：

这里提到了三个勘误项

PLL：第一次锁定尝试时 PLL 可能无法锁定

对于此项、提到的权变措施“TI 建议使用 C2000Ware SysCtl_setClock () 函数（也包括该权变措施的实现）来设置 PLL 时钟。“ 这听起来像  sysctl_setclock() 已经包含了锁定序列所需的所有内容。  客户  首先已经在使用 SysCtl_setclock() 函数。 调用 sysctl_setclock () 之前需要检查什么?

勘误表还提到了在 PLL 未正确运行时复位器件。 我们尝试了这种方法、只是我们通过查看 PLLCLKEN 位来确定 PLL 状态、而不是通过 DCC、而是通过向看门狗写入不正确的值来重置器件。 它的工作原理是一样的吗？ 如果没有、 我可以查看哪个示例作为使用 DCC 和复位器件的参考？

此外、此项目看起来可能会在所有设备上偶然发生、但是、客户的问题仅发生在某些设备上、但始终 看起来是不同的情况。  

LPM：不支持待机低功耗模式

客户在此阶段不使用低功耗模式。  

系统：多次连续写入 CLKSRCCTL1 可能导致系统挂起

此项目提到“ C2000Ware_3_00_00_00 及更高版本将实施此权变措施“、客户使用的是 5.06 版本的 c2000ware

此致、

挂起

挂起、

感谢您的确认。  我不是根据 PLLCLKEN 值手动复位器件、而是使用 DCC EX #1 或#3 来检查。

重新加载代码、复位+重启等时是否观察到 PLLCLKEN？ 我认为 CCS 闪存插件将 PLL 配置为闪存编程（在（重新）加载代码时）、因此在调试和在 main 停止时、PLLCLKEN 位设置为高电平。 复位时、该位被清除。

此致、

Aishwarya

尊敬的 Aishwarya：

在重新加载代码、复位+重新启动等时是否观察到了 PLLCLKEN？ [/报价]

是的、我们在点击 CCS debug 后观察到了它的设置。 由于 CCS 将绘制 PLL 的图、我要确认我们是否可以在不重新加载代码的情况下观察 PLLCLKEN。

此外、此商品看起来像所有设备上都可能发生的事情、但是、客户的问题仅发生在某些设备上、但始终 看起来是不同的情况。

同时、  勘误表中的项目如何解释这一事实？  

我会使用 DCC EX #1 或#3 进行检查。

我将与 cusotmer 检查这一点。

[/quote]

还有一个问题。

 SysCtl_setclock() 可以单独处理 此勘误项吗？  

• PLL：第一次尝试锁定时 PLL 可能无法锁定

客户已经制造了只使用 SysCtl_setclock () 的产品,如果不是,这可能会在编程的产品中造成风险,他们需要重新编程所有相关产品

挂起、

请告诉我这些测试的结果是什么：

 引导加载程序代码中 SYSPLLSTS[LOCK]的状态是什么？ 错误吗？ 在这些情况下、您能否提供 ClkCfgRegs 的寄存器转储？

2.引导加载程序代码中的 RESC 和 MCDCR.MCLKSTS 是什么？ 错误吗？

3.使用 XTAL 与 X1 作为 SYSPLL 的时钟源时是否存在行为差异？ 它在 setclock 中的哪个位置出现故障？

4.引导代码和应用代码之间是否存在 FW 重叠？

此致、

Aishwarya

尊敬的 Aishwarya：

请查看下图中的 RESC、SYSOKSTS[LOCK]和 MCDCR.MCLKSTS

请注意、 SYSOKSTS[LOCK]= 0、这与勘误表不同

此致、

挂起

挂起、

RESC 的价值是什么？ 我想您可能是对的、这 与勘误表不同。  

如果客户只是运行任何 C2000WARE 示例、他们仍然会看到锁定问题吗？ 如果没有、可参考此处的时钟配置是如何完成的。 您可以 共享时钟 INIT 相关函数代码（包括定义）、以确保其与 C2000WARE 实施相匹配？ 如果尚未使用、ClockTree 工具将帮助简化整个流程。  

如果您要降低 PLLCLK 频率、PLL 是否会锁定、然后放入引导加载程序代码中？

能否参阅以下主题并确认是否是类似问题？ 我怀疑这可能与在整个开发过程中使用不同的编译器+ SDK 有关：  

TMS320F28377S：PLL 从不锁定 InitSysCtrl () 内部  

TMS320F2800156-Q1：SYSPLLCTL1 寄存器

此致、

Aishwarya

正在添加资源

尊敬的 Aishwarya：

我将尝试使用 sysctl_setclk() 并使用我们的一个示例客户。

使用 XTAL 与 X1 作为 SYSPLL 的时钟源时是否存在行为差异？

对于此项目、您能否分享如何切换 XTAL 和 X1？

共享的两个线程的函数

TMS320F28377S：PLL 永远不会锁定在 InitSysCtrl () 内 

此线程 指示  2837xS_Headers_nonBIOS.cmd 将导致编译器错误地定位时钟配置寄存器。  此问题应该会影响所有设备、但是客户只会看到部分设备出现问题。 不过、使用 c2000ware 示例也可以排除这种情况。

TMS320F2800156-Q1：SYSPLLCTL1 Register

该主题介绍了 从 XTAL 切换时钟源到 INTOSC2 时的行为。 由于客户不会切换时钟源、您能否详细介绍一下这是如何相关的、以及如何检查与天气相关的？

同时、当前方向似乎主要关注应适用于所有器件的软件问题、但我们仍然无法解释为什么仅在部分器件上发生这种情况。 尽管我们仍在寻找根本原因的过程中、您能否分享一些关于当前可疑/理论的见解？ 这可以帮助客户估计出厂设备的风险、设备使用两个 initsyspll() 作为解决方法。

此致、

挂起

对该主题进行离线讨论、汇总 E2E 上的发现/解决方案。 我会在平均时间内使 E2E 保持打开状态。  

挂起、

是否有 基于最新实验的更新？

此致、

Aishwarya