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.

[参考译文] MSP430F5438A:从 LPM3唤醒后的 DCO、FLL 设置

Guru**** 2540720 points


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

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/876345/msp430f5438a-dco-fll-settings-after-waking-from-lpm3

器件型号:MSP430F5438A
基本系统操作:系统定期运行对压力和温度传感器采样、然后使用 LPM3模式休眠。 内部 RTC 用于将系统从睡眠模式唤醒。
系统时钟初始化:一个被称为 INIT_Clocks 的定制函数被用来在启动时和 RTC ISR 内初始化系统时钟。 我附加了文件以及时钟初始化过程中使用的所有函数。
问题:我们正在尝试尽量缩短采样周期、以提供高传感器采样率。 由于在 ISR 中使用 init_clocks 例程来确保正确的时钟操作、因此会严重限制我们减少采样周期的能力。 我已经测量了例程运行的~135ms。
问题:每次器件从睡眠状态唤醒时是否需要运行 init_clock()函数? 我认为真正需要做的就是重新启用 FLL (设置 SCG0)、因为它在进入 LPM3时被关闭。 我是对的吗? 还需要做什么吗?

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

    这个问题有两个略有不同的答案:问题、但我认为你的问题的答案是相同的:无论在哪种情况下、问题都是相同的。

    在 ISR 中、FLL (SCG0)被禁用、但如果关闭 SCG0、并且 ISR 非常长、FLL 将稳定。

    如果 ISR 执行唤醒操作、在唤醒前台、FLL 将(已经)启用、如果运行时间足够长、FLL 将稳定。  

    在这两种情况下都不需要采取进一步行动。 如果我正确地猜测 init_clock()中的内容,它不会做任何事情来加快速度。 (不可能)最坏情况下的 FLL 稳定时间为32^2/32768 =~31ms。

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

    感谢您的回复 Bruce。

    是否有要测试的寄存器位来确认 FLL 已稳定?

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

    Bruce、

    从数据表(MSP430F543xA、MSP430F541xA 混合信号微控制器)的第48页可以看出、DCO 开启和稳定时间< 5us。 我假设这包括 FLL 稳定时间、因为它用于稳定 DCO。  

    UCS 模块特有数字锁频环(FLL)硬件、此硬件与一个数字调制器协同工作来稳定
    DCO 频率设置为所选 FLL 基准频率的可编程倍数。 内部 DCO
    μs 快速导通时钟源并可在不到5 μ s 的时间内实现稳定。

    您认为我可以信赖吗?

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

    DCO 启动速度非常快、因为 CPU 在启动前无法运行。 当它启动时、它具有与停止时相同的设置。

    FLL 趋稳(通常)需要更长的时间。 它乘以 DCO 和基准时钟的32个基准时钟节拍(~1ms)、然后(也许)将 UCSCTL0:DCO 调整一个。 如果调整必须运行整个 RSEL 范围(DCO = 0-31)、所需的时间大约为32ms。 [参考用户指南(SLAU208Q)第5.2.7节、最后一段。 另请参阅第5.2.10节]

    实际上、重新启动(DCO)时的 DCO 设置几乎总是正常的、并且 FLL 几乎从不需要运行整个 RSEL 范围。 如果在冬季禁用 FLL 时将设备带到室外、则可能会出现异常。

    我不知道有什么方法可以告诉 FLL 已经稳定。 从某种意义上说、它从未"稳定"、因为它始终在监视并根据需要进行微调。

    [编辑:少量澄清]

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

    很抱歉、Bruce、再澄清一下:

    唤醒时 DCO 时钟的频率误差范围是多少?

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

    供参考

    我的 init_clocks 例程调用 TI 生成的函数 CONFIG_MCLK ()、这会导致138ms 的固定延迟、等待 FLL 稳定:

    init_clocks ()-> config_MCLK ()-> Init_FLL_settle ()

    void Init_FLL_settle (uint16_t fsystem、uint16_t 比率)

      volatile uint16_t x =比率* 32;

      init_FLL (fsystem、比率);

      while (x--){

          _DELAY_CYCLES (30);

      }

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

    DCO 误差在第5.20节的数据表(SLAS655F)表中进行了说明。

    它引用0.1%/°C。 因此,如果您在 DCO 关闭时将温度85C->(-40C)偏移,则会产生(85-(-40)*0.1=12.5%的误差。 然后、8MHz DCO 将以9MHz 的频率运行、并在接下来的32ms 内漂移回8MHz。 这种转变可能会在西伯利亚的汽车发动机舱中发生超过半小时。

    还有一个电压分量(1.9%/V)、但我不知道有什么应用会定期将电源电压转换这么多。

    --------

    我不熟悉这些功能。 您知道"比率"的值是多少吗? 它的编码方式、其明显目的是等待尽可能长的稳定时间。 正如我所建议的那样、这几乎肯定比所需的时间长(很多)、尤其是当 CPU 仅处于睡眠状态100ms 时。

    此外、InitFLL 可能会在 DCO 中设置初始值、实际上会取消 FLL 之前所做的一切。 如果是、这会产生反作用。

    但我所能做的就是假设状态。 您比我更清楚您的设备的预期环境是什么。

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

    谢谢 Bruce