This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] TM4C129ENCPDT:SysCtlClockFreqSet 未正确设置频率

Guru**** 2189475 points
Other Parts Discussed in Thread: TM4C129ENCPDT
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/929483/tm4c129encpdt-sysctlclockfreqset-do-not-set-the-frequency-correctly

器件型号:TM4C129ENCPDT

你好。

在我们的项目中,我们面临以下问题...

我们的14个器件(Tiva 控制器)正在运行长期测试。 这些器件连接到一个电源、该电源周期性地关闭和打开3秒。 每次重启后、都会检查所有器件的状态(它们必须开始通过 Profinet 与 PLC 正确通信)、如果所有器件均正常、则电源将关闭并再次打开。 在系统重新启动数百次(这意味着设备重新启动数千次、因为每次重启14个设备)后、其中一个设备(每次都不同)进入非常奇怪的状态、但会因某种原因而断电。 它看起来大约慢15倍、启动时间更长、LED 闪烁速度更慢、以太网总线(Profinet)上的响应速度更慢。 它似乎是时钟频率的问题。

我们通过以下方式设置时钟频率...
uint32_t 现实频率= MAP_SysCtlClockFreqSet ((SYSCTL_XTAL_25MHz | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480)、120000000);/120MHz
并检查其本身是否正确的返回值。 即使在器件的问题周期内、每次都返回所需的120000000值。  

当我设置8MHz 而不是120MHz 时...
MAP_SysCtlClockFreqSet ((SYSCTL_XTAL_25MHz | SYSCTL_OSC_main | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480)、8000000);//8MHz
然后、器件行为与我们的长期测试中看到的问题类似。

我正在阅读错误数据文档、我发现错误 sysctl#22更改为 PLL 时钟分频器可能会导致系统时钟超出规格。
我认为这也可能是我们的问题、但我发现我们使用的是 TivaWare_C_Series-2.1.4.178_DRL、它应该包含该错误的修复。

我的问题...

1) 1)您对此问题没有任何解释? 控制器中是否没有其他可能导致类似行为的"频率"问题?

2) 2)当 SYSCTL#22中描述的问题发生时、结果是什么、这意味着"导致系统时钟超出规格"? 设置了哪个频率? 它是否会导致与我们的器件类似的行为?

3) 3)如何验证120MHz 频率是否设置正确? 请问您能提供一段代码来处理它吗?

提前感谢您的任何帮助。

Zdenek Krejsa

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我以前听说过这种情况、但这种行为的发生率很低、因此很难进行调试。 我怀疑在上电后如何初始化 PLL 输出上的分频器仍然存在问题。 您可以对分频器进行写操作并回读写的内容、但该值绝不会传播到实际的分频电路。 可以为我尝试一次测试吗? 添加对 SysCtlClockFreqSet()的调用,该调用将 PLL 时钟设置为60MHz,然后再次调用它,将时钟设置为120MHz。 您是否能够再次运行测试并报告结果?

    MAP_SysCtlClockFreqSet ((SYSCTL_XTAL_25MHz | SYSCTL_OSC_main | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480)、60000000);
    RealFrequency = MAP_SysCtlClockFreq1200Set (((SYSCTL_XTAL_25MHz | SYSCL_480_UST_SCL_UST_SCL_IN)| SYSCSCSCCTL 

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢您的快速响应。

    那么、我是否正确地理解、无法验证时钟频率是否设置正确?

    我将在我们的 FW 中添加建议的变通办法、并在下周进行测试。

    此致、

    Zdenek Krejsa

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    很抱歉、我没有回答您的那部分问题。 是的、有几种方法可以验证 PLL 是否正常工作。 它们可能不是非常精确、但对于此故障模式、正确操作和不当操作之间的差异将在 PSYSDIV 寄存器中至少得到一个计数。 在 TivaWare 和更高版本中、PLL 使用240MHz VCO 和2的 PSYSDIV 来实现120MHz 运行。 (函数调用使用 SYSCTL_CFG_VCO_480与早期版本兼容、但实际上是240MHz。) PLL 频率最小可关闭时、PSYSDIV 等于3、从而提供80MHz 的系统时钟。 在本例中、您看到的差异要大得多。

    检查 PLL 频率的一种简单方法是使系统定时器脱离 PIOSC 运行(始终为16MHz)、并在系统时间递减至零时进行软件循环计数。 根据您希望检查的精确度以及您愿意为此启动检查花费的时间、为系统计时器选择初始计数值。 将软件循环计数与 PLL 正确启动时获得的值进行比较、并使用一个允许同步的小+/-窗口。 这必须在您启用任何中断之前完成。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    下面是一段简单的代码、它使用从 PIOSC 运行的 Timer0来检查 PLL 是否正常运行。 当 PLL 工作正常时、通过运行代码并查看计数来找到值1711。 该值可能会随不同的编译器版本和不同的优化级别而变化。 在本例中、我使用了 TI 编译器版本18.12.6和优化级别2、速度与大小设置为1。

    int main (void)
    {
    uint32_t ui32SysClock;
    uint32_t 计数;
    
    //
    //从 PLL 以120MHz 运行。
    //
    ui32SysClock = SysCtlClockFreqSet ((SYSCTL_XTAL_25MHz |
    SYSCTL_OSC_MAIN |
    SYSCTL_USE_PLL |
    SYSCTL_CFG_VCO_480)、120000000);
    
    //
    //启用并等待计时器准备好访问
    //
    SysCtlPeripheralEnable (SYSCTL_Periph_TIMER0);
    while (!SysCtlPeripheralReady (SYSCTL_Periph_TIMER0))
    {
    }
    TimerClockSourceSet (TIMER0_BASE、TIMER_CLOCK _PIOSC);
    TimerConfigure (TIMER0_BASE、TIMER_CFG_ONE_SHOT);
    TimerLoadSet (TIMER0_BASE、TIMER_A、16000000 / 5000);// 200uS
    TimerIntClear (TIMER0_BASE、TIMER_TINA_TIMEOUT);
    计数= 0;
    TimerEnable (TIMER0_BASE、TIMER_A);
    while (TimerIntStatus (TIMER0_BASE、false)!= TIMER_TINA_TIMEOUT)
    {
    count++;
    }
    if ((count >(1711 + 17))||(count <(1711 - 17)))
    {
    for (;;);//失败
    }
    }
    

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我们测试了建议的简单修复... "添加对 SysCtlClockFreqSet()的调用,该调用将 PLL 时钟设置为60MHz,然后再次调用它,将时钟设置为120MHz。"

    结果... 我们有一个包含14个具有 Tiva 控制器的器件的网络。 通过固件中的修复、我们成功地关闭和打开了电源10000次、并且每次都正确启动所有器件! 因此、这意味着控制器的14.000正确恢复、修复有效。

    现在我们将在固件中使用"魔法"修复程序。

    您 将进一步采取哪些步骤? 您是否会为 ERR 数据添加新的点并对 Tivaware 库应用类似的修复?

    此致、

    Zdenek Krejsa

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢您的反馈。 我将与团队讨论后续步骤。 它可能是对勘误文档的短期更新、并在 TivaWare 下一个 TivaWare 版本中进行修复。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    有几个问题...

    -当120 MHz 频率之前的60 MHz 设置解决了问题时,您能估计是什么原因导致了问题?

    -我们对包含相同类型控制器(TM4C129ENCPDT)的其他类型的器件进行了类似的测试、但我们无法重现问题。 您是否有任何想法可以增加问题的可能性... 温度、电源曲线?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我们认为这个问题与 PLL 的输出级分频器有关。 该寄存器实际上是双缓冲的、具有逻辑、当分频寄存器被写入相同的值时、会阻止更新第二个缓冲区、也就是说、您用之前的值重新写入分频寄存器。 我们怀疑在某些器件上、该逻辑未正确复位。 逻辑需要看到分频寄存器的变化。 通过将 PLL 时钟设置为60MHz、分频寄存器设置为2、然后在120MHz 时设置为1。 这个序列清零逻辑、第二次写入有效。  

    我怀疑问题与流程有关。 我不知道它是否与工艺角或局部失配相关。 内核电压(1.2V 电源)和温度的变化可能会影响此问题。 如果可能、您能否提供显示问题的测试设备的日期代码、以及测试产品上未显示问题的设备的日期代码。 这可能有助于我们更好地理解问题。