• 状态
  • 已锁定 已锁定
  • 回复 10 回复
  • 订户 0 订户
  • 视图 12 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] MSPM0G1507：MCLK 开关和 SYSOSC Sleep1 行为

admin
Guru**** 2964790 points

Other Parts Discussed in Thread: LP-MSPM0G3507

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1657041/mspm0g1507-mclk-switch-and-sysosc-sleep1-behavior

部件号： MSPM0G1507
Thread 中讨论的其他器件： LP-MSPM0G3507

客户正在尝试使用以下配置设置器件：

  1. 在 32MHz 模式下以 MCLK=SYSOSC 开始。
  2. 将 MCLK 转换为 LFCLK（LFXT 已在~30 秒之前启动）。
  3. 将 SYSOSC 设置为 4MHz。
  4. 转到睡眠 1（SYSOSC 在 4MHz 下运行）。

客户和我都使用类似的测序对推进进行了原型设计、但无法获得所需的结果。

    DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK(false);
    DL_SYSCTL_setSYSOSCFreq(DL_SYSCTL_SYSOSC_FREQ_4M);
    __WFI();

当我运行上述顺序时、结果是以下问题：

  1. 从 SYSOSC 切换到 LFCLK 需要~700+微秒时间。 这对客户应用来说太长了、我不明白为什么需要这么多时间。 这通过 GPIO 切换仪表进行验证。
  2. SYSOSC 频率仍为 32MHz（通过将其路由至 CLKOUT 引脚进行验证）。

我已经尝试了各种替代方法、例如在 MCLK 切换之前将 SYSOSC 切换到 4MHz、然后将 DL_SYSCTL_switchMLKfromSYSOSCtoLFCKL () API 替换为 DL_SYSCTL_setPowerPolicyRUN1SLEEP1 ()。 结果始终相同。 如果我们看看~700 微秒的大部分时间用在的位置、看起来它花在了以下循环中：

while ((DL_SYSCTL_getClockStatus() & SYSCTL_CLKSTATUS_CURMCLKSEL_MASK) !=
           DL_SYSCTL_CLK_STATUS_MCLK_SOURCE_LFCLK) {
        ;
    }

为什么 32kHz 晶体已经在运行（前 30 秒）需要很长时间？ 在这个循环中我们需要等待吗？ 如果我们不在循环中等待、会产生什么后果？

此外、如何在将 MCLK 切换到远离它的位置后使 SYSOSC 为 4MHz？

谢谢、

Stuart

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

    您好、Stuart、

    我假设客户和您已经查看过 TRM、但您能否确认遵循了这些步骤并设置了值：

    在更改 SYSOSC 频率之前、还应确保禁用 MDIV。

    DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK(false); 将 SYSOSC 频率设置回基础值：


    此外：

    我很好奇您是如何测量 700us 延迟的？ 我需要与我的团队一起更深入地了解这一点、但一旦我掌握了更多信息、我会尽快回复您。

    此致、

    Owen

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

    Owen、

    感谢您的初始回答。

    1. 客户不使用 SYSPLL 或 HFCLK_IN。 它们可能使用 HFCLK（我可以检查）、但在我重现问题的示例中没有使用或启用 HFCLK。
    2. MCLK 源自 SYSOSC。
    3. 我已经尝试将 SYSOSC 设置为 32MHz 或 4MHz。 它似乎没有任何区别,除了我注意到当设置在 4MHz 时,它移动到 32MHz 开始切换。
    4. DriverLib API 正在执行切换请求、并根据传递的参数使 SYSOSC 保持启用或不启用状态。 客户使用“false“以便 SYSOSC 保持启用状态。

    我知道该序列会将 SYSOSC 设置回 32MHz：

    DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK(false); 将 SYSOSC 频率设置回基础值：

    但是、客户需要在时钟切换后在 4MHz 下运行 SYSOSC。 命令它在切换后切换回 4MHz 似乎不起作用。 这是不可能的? 我认为、由于预计功耗会增加、这是客户的一个严重问题。

    我是通过在 DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK () 调用之前和之后切换 GPIO 来测量~μ V 700MHz。 其中一些时间可能需要几个周期的开销、尤其是在切换之后。 需要几个时钟时间才能“在引脚上“进行更改。 我还在测试用例的某些运行中看到了高达~μ V 的 800MHz。 单个 32kHz 时钟~30us、因此如果翻转引脚需要~4 个时钟等时间、我们可能会看到 GPIO 开销时间减少~100us 至~200us。 假设在时钟切换后翻转引脚需要~200us 的开销、为什么在 32kHz 晶体已经在~30 秒前启动时、切换仍需要~500us 的时间？

    谢谢、

    Stuart

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

    您好、Stuart、

    可以将 SYSOSC 更改为在 4MHz 下运行。 但是、将 MCLK 切换到 LFCLK 源后不应更改它（请参阅我上一次回复底部的屏幕截图）。

    考虑到这一点、我想相信当 MCLK 来自 LFCLK 时、无法在 4MHz 下运行 SYSOSC。

    至于您观察到的延迟、设计团队给出了一个他们期望的 200 μ s 左右的直觉值。 建议在 CLKOUT 引脚上引出 MCLK 频率、以便您可以观察时钟信号何时实际变化、而不是依赖于 SW 时钟周期的不确定性。 在切换到 LFCLK 之前、您仍然可以利用 GPIO 信号来表示“时间戳“。

    此致、

    Owen

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

    Owen、

    如何将 MCLK 输出到 CLKOUT 引脚？ 无论是在 TRM 中还是在 SYSCFG 中、它看起来都不是一个选项。

    谢谢、

    Stuart

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

    您好、Stuart、

    没错、无法从 CLKOUT 输出 MCLK。 我在上一次答复中忽略了这一点。

    我建议分析在 GPIO 切换之间执行代码所需的指令和时钟周期数。

    当我执行自己的测试时、我观察到延迟仅为 ~280us。 我在 LP-MSPM0G3507 上进行了测试、其中、我在 LFCLK 启动时插入了 30 秒的延迟、然后提取 DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK () 函数、其中我在切换 MCLK 之前设置 GPIO 输出、并在 while 循环之后清除 GPIO。

    客户是否观察到晶体稳定？

    此致、

    Owen

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

    客户认为、在开始切换之前、32kHz 晶体是稳定的。 它们会在开始切换之前的 30 秒内启动 32kHz 晶体。 我在重现结果时也是这样做的。

    在时钟切换 API 末尾的 while 循环中、我们观察到总计~700us 的最大分量。 如果我们不在这个延迟循环中等待（提取方法并删除 while 循环）而直接进入 SLEEP (__WFI ())、会产生什么后果？

    谢谢、

    Stuart

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

    您好、Stuart、

    由于我无法重现问题、您能分享您的代码吗？

    如果您不等待延迟循环、我们不确定会产生哪些后果。  通常、当应用程序切换到 LFCLK 时、您必须假设时间无关紧要。 LFCLK 缓慢、因此应用应只期望响应缓慢。  等待时钟切换发生始终是一种很好的做法。 如果您需要切换到 LFCLK、则需要等待 MCLK 真正切换到 LFCLK。

    此致、

    Owen

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

    Owen、

    请参阅随附的内容、根据我的实验、对各行进行了输入/输出注释。

    关于本声明：

    如果您不等待延迟循环、我们不确定会产生哪些后果。  通常、当应用程序切换到 LFCLK 时、您必须假设时间无关紧要。 LFCLK 缓慢、因此应用应只期望响应缓慢。  等待时钟切换发生始终是一种很好的做法。 如果您需要切换到 LFCLK、则需要等待 MCLK 真正切换到 LFCLK。

    如果我理解正确、客户希望在时钟切换后立即进入睡眠模式 (__WFI ())。 他们能否做到这一点、而不会在结束的 while 循环中等待？ 这是否还有其他一些负面后果、我们需要关注。 它们用于计时的外设（硬件计时器）仍从 SYSOSC 计时、不过如果我理解正确、他们希望 SYSOSC 为 4MHz。

    谢谢、

    Stuart

    e2e.ti.com/.../3386.gpio_5F00_toggle_5F00_output_5F00_LP_5F00_MSPM0G3507_5F00_nortos_5F00_ticlang.zip

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

    Owen、

    我还能够确认 GPIO 切换（设置或清除）是反汇编中的一条“STR“指令。 ...假设该指令有 1 个 CPU 周期,在 32kHz 的 CPU 执行时间应该~30.5us。 作为额外的测试、我切换了 GPIO 设置/清除/设置、并在逻辑分析仪上查看了该设置。 它在边沿之间切换 30.5us。

    但是、我注意到、当我删除DL_SYSCTL_setSYSOSCMCLKFreq (DL_SYSCTL_SYSOSC_FREQ_4M) 时、我现在看到 DL_SYSCTL_switchfromtoLFCLK (FALSE) 调用的持续时间约为~330us 至~520us（由 GPIO 指示）。 对于 SYSOSC=4M 的请求似乎没有做任何事情、根据我的 CLOCKOUT 仪器、SYSOSC 保持在 32MHz。

    我想我观察到的额外时间来自 SYSOSC =4M 的请求。 当 MCLK 源为 32kHz 晶体时、我们是否确认 SYSOSC 固定在 32MHz？

    谢谢、

    Stuart

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

    您好、Stuart、

    如我刚才所说、答复你的第一个答复时、我们不知道你在不等待的后果方面可以期望些甚么。 通常、最好等待时钟切换完成。 如果不在 while 循环中等待、则可能会出现未定义的行为。

    要回答您的第二个回复、根据下面屏幕截图中的第 3 点、如果 MCLK 来自 LFCLK、我相信 SYSOSC 不能是基频以外的任何频率：

    我在您的代码中取消了第 48 行的注释、将 SYSOSC 设置为 4MHz、并观察到 4MHz 时钟正常工作。 将 MCLK 切换到 LFCLK、然后将 SYSOSC 频率切换回基频 (32MHz)、我观察到延迟~350-500us。

    我又回来测试我的代码,我实际上看到它在~270-450us 之间变化。

    我将与我的团队进一步联系、讨论这一问题。

    此致、

    Owen