[参考译文] MSP430FR2675：DriverLib 时钟初始化

您好、Ryan、

您认为 driverlib 中的错误是什么？ 就我所见、第二个参数只是延迟函数的返回、所以振荡器故障在时钟稳定前不会触发。  

您的上述陈述令我感到困惑。  CS_initFLLCalculateTrim 中 有两个代码等待的位置。 1) 1)确保振荡器故障清零2)等待特定的延迟、然后再重新启用 中断。 是否卡在1)中？ 3000/34和3000/35将影响2)、但不应影响1)。  

您能否查看 driverlib 示例 cs_ex1_DCO1MHzSWTrim 并查看您的代码与示例之间是否有任何差异？  

您是如何针对第二个参数来到3000/34的？ 该示例使用30。

此致、

Evan

抱歉、我获取了错误的函数名称、它实际上卡在 privateCSComputeDCOFTrim 的 do-while 循环中。   

我认为、如果它从未击中设定的目标、而不是在 X 个周期或某种情况后从环路中踢动、那么它可能会在这段时间内卡住。  为了进行测试、我添加了一个计数、并在24个周期后从该执行中启动它、它似乎在我当前测试的一个单元上运行良好。   

我来到了3000/34号； 最初我使用的是3000/33、因为我知道比率为目标 kHz/FLL kHz (32.768kHz)、所以我对 kHz 取整并将代码设置为允许时钟速度调整 为1个数字、然后进行数学运算、而不是将其除以代码之外。   

转至/34是在之前与 FAE 讨论 过相同的事情后进行的、这是建议 的解决方法。   

我的其余时钟设置与该示例非常匹配。   

Ryan  

您是否知道 privateCSCompteDCOFTrim (..)中的位置 您的应用程序被卡住了吗？ 代码在两个位置等待该函数内的标志。

您尝试锁定的频率是多少？  

此外、请确保查看 《MSP430FR2xx/FR4xx DCO+FLL 应用指南 》第4节、其中专门讨论了如何快速锁定 FLL。  

此致、

Evan

它会卡在第二个 do-while 中、在这里它会检查不同的 DCO 抽头以找到适合的方法。 我前面没有行号、但它从未完全落在范围内、因此它会继续循环、而不是选择"最佳"匹配并继续。   

我尝试锁定到3MHz。   

我已经很仔细地看了这个指南。  我将再次查看它、看看我是否遗漏了任何东西。  

感谢 Ryan 的最新消息。

我仍在尝试了解您刚才所说的内容：  

更改此^值只会影响  调用 privateCSCompteDCOFTrim()后的等待时间。 我不知道更改此值会如何影响您是否陷入 privateCSCompteDCOFTrim ()。

您如何确认您卡在  privateCSCompteDCOFTrim ()中？

Evan

我向调试器确认了代码被卡住的位置、并使用 LED 打开/关闭来在锁定时向其所在的函数发出信号。  

我同意这一点看起来并不重要、但 在使用比率的 privateCSComputeDCOFTrim 调用中设置的寄存 器之一必须影响通过该循环进行注册的可行性。   

明白。 感谢您的确认、我明天将再次与您会面。

我还想指出一点、这似乎是零件问题的一部分。  我们的板中有很大一部分在当前设置下工作正常。  在给定此设置的情况下、我们会看到20%范围内的一些故障。   

Evan、

非常好、很高兴听到我们在想同样的事情。  我将在下一周左右继续测试其他器件、以验证这是否解决了问题、并在我完成测试后将其标记为已解决(如果它确实清除了多个器件上的此问题)。  

请注意、我认为这应该整合到库中、以便即使在中间频率下也能按预期工作。  这是否是 TI 将在未来发布时考虑的内容？   

谢谢、  

Ryan  

听起来不错。

我将向我们的软件团队提交一个 TT。 但是、我不知道发布时间线会是什么。

此致、

Evan

好的、听起来不错。  我认为这是一个很好的补充。   

下周将向您报告好消息或坏消息。   

感谢您的帮助、

Ryan  

您好 Evan、  

我已经在更多电路板上测试了此更改、并发现它运行良好。  

我最后的修复方法是向驱动程序库添加附加条件、因为这允许代码保持大致相同、然后我在更新时测试了以前工作的板时钟速度与新的时钟速度、并且时钟速度没有变化。   

感谢您的帮助、我已经标记了解决此问题的答案。  

Ryan