• 状态 Resolved
  • 已锁定 已锁定
  • 回复 12 回复
  • 订户 0 订户
  • 视图 47 视图
  • 用户 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.

[参考译文] AM625：通过计时器从深度睡眠状态唤醒

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1511669/am625-wakeup-from-deep-sleep-by-timers

器件型号：AM625
主题中讨论的其他器件：SK-AM62B-P1

工具/软件：

您好、

我的客户希望实现以下场景。 为 SDK 版本  10.01.10.04。

场景：
步骤1：当没有活动操作时、系统进入深度睡眠模式。
步骤2：如果一段时间(即3秒)内没有唤醒事件、系统将进入关断模式(关闭模式)。
由于没有从深度睡眠到关断的直接功耗模式转换、因此一旦器件从深度睡眠唤醒、然后进入关断状态。

问题：
Q1)在深度睡眠期间、哪个计时器可以用作唤醒源？
Q2)客户希望尽可能降低深度睡眠模式下的功耗、应将哪个计时器用作唤醒源？
问题3)是否有可用的示例或文档可以将推荐的计时器用作深度睡眠的唤醒源？

谢谢。此致、
田代浩一郎

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

    尊敬的 Tashiro-san：

    user6021594 说：
    q1)在深度睡眠期间、哪些计时器可用作唤醒源？

    Linux SDK 中尚未实现通用计时器(包括主域、MCU 域、WKUP 域计时器)作为唤醒源。 目前还没有启用通用计时器作为唤醒源的计划。

    只有实时时钟(RTC)已实现为唤醒源。

    user6021594 说：
    q3)是否有任何示例或文档可用于将推荐的计时器用作深度睡眠的唤醒源？

    如果应用可以接受 RTC 计时器、请参阅以下链接： https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/10_01_10_04/exports/docs/linux/RTC/RTC/PM_wakeup_sources.html#real-time-clock-rtc Foundational_Components Power_Management

    此致、

    Anshu

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

    尊敬的 Anshu：

    感谢您的快速答复。
    RTC 计时器可接受。

    客户尝试使用 RTC 计时器作为定制电路板上 SuspendToRAM 的唤醒源。
    但唤醒计数器似乎不正确。

    它们测试了3秒(rtcwake -m mem -s 3)和10秒(rtcwake -m mem -s 10)的唤醒时间。
    但它分别花费~9秒和~29秒。 

    [2025-05-09 16:31:36.874] root@pos-periph:~# rtcwake -m mem -s 3
[2025-05-09 16:31:37.136] rtcwake: assuming RTC uses UTC ...
[2025-05-09 16:31:37.136] rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:18:36 1970
[2025-05-09 16:31:46.294] root@pos-periph:~# 
[2025-05-09 16:31:48.096] root@pos-periph:~# 
[2025-05-09 16:31:48.296] root@pos-periph:~# rtcwake -m mem -s 10
[2025-05-09 16:31:51.367] rtcwake: assuming RTC uses UTC ...
[2025-05-09 16:31:51.371] rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:18:49 1970
[2025-05-09 16:32:20.302] root@pos-periph:~#


    谢谢。此致、
    田代浩一郎

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

    尊敬的 Tashiro-san：

    user6021594 说：
    他们测试了3秒(rtcwake -m mem -s 3)和10秒(rtcwake -m mem -s 10)的唤醒时间。
    但它分别花费~9秒和~29秒。

    您能解释一下这是如何测试的吗？ 这是否使用了操作系统时间、秒表设备或其他设备？

    谢谢、

    Anshu

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

    尊敬的 Tashiro-san：

    此外、您能否确认用于此操作的 RTC 模块是 AM62x 上的内部 RTC 还是外部 RTC IC？

    这两个寄存器的输出是什么？

    0x04508058和0x43008600

    这两个寄存器控制 RTC 模块的时钟多路复用、以便我们可以检查正在使用哪个振荡器。

    谢谢、

    Anshu

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

    尊敬的 Anshu：

    Unknown 说：
    您能解释一下这是如何测试的吗？ 这是否使用了操作系统时间、秒表设备或其他设备？

    该时间是使用 OS 时间测量的。
    46.294 - 37.136 =~9秒
    [16 2025年05月09日：31：37.136] rtcwake：使用/dev/rtc0在1970年1月1日星期四00：18：36从"mem"唤醒
    [ROOT 2025年05月09日@pos-perifh：~#
    32：20.302 - 31：51.371 =~29 sec  
    [rtcwake：2025年05月09日16：31：51.371] rtcwake：使用/dev/rtc0在1970年1月1日星期四00：18：49从"mem"唤醒
    [ROOT 2025年05月09日@pos-periph:~#

    Unknown 说：
    此外、您能否确认用于此用途的 RTC 模块是 AM62x 上的内部 RTC 还是外部 RTC IC？

    并使用内部 RTC。

    我将检查这两个寄存器值。

    谢谢。此致、
    田代浩一郎

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

    尊敬的 Anshu：

    Unknown 说：
    这两个寄存器的输出是什么？

    0x04508058 = 0x00000003
    0x43008600 = 0x00000000

    谢谢。此致、
    田代浩一郎

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

    尊敬的 Tashiro-san：

    Anshu 有紧急情况、目前不在办公室。 我不确定 RTC 唤醒延迟、但会在 EVM 上对其进行测试、并告知您。

    首先、检查内核消息时间戳并不能真正反映 RTC 唤醒时间。 rtcwake 命令中的"-s 3"通知 RTC 在3秒内生成唤醒事件、但内核需要更多时间来恢复并到达命令行提示符。

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

    尊敬的 Tashiro-san：

    这是 SK-AM62B-P1上的 SDK10.1测试日志。 第10行是进入暂停模式时的最后一次打印、第11行是恢复时的第一次打印。 两行之间的时间戳差异为3.12秒。 这不是确切的 RTC 唤醒时间、但它给出了一个粗略的想法。 

    [2025-05-15 12:42:47.064] root@am62xx-evm:~# rtcwake -m mem -s 3
[2025-05-15 12:42:54.424] rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:01:19 1970
[2025-05-15 12:42:54.568] [   69.713593] PM: suspend entry (deep)
[2025-05-15 12:42:54.568] [   69.717505] Filesystems sync: 0.000 seconds
[2025-05-15 12:42:54.600] [   69.741226] Freezing user space processes
[2025-05-15 12:42:54.600] [   69.747126] Freezing user space processes completed (elapsed 0.001 seconds)
[2025-05-15 12:42:54.616] [   69.754119] OOM killer disabled.
[2025-05-15 12:42:54.616] [   69.757349] Freezing remaining freezable tasks
[2025-05-15 12:42:54.616] [   69.763236] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[2025-05-15 12:42:54.632] [   69.770682] printk: Suspending console(s) (use no_console_suspend to debug)
[2025-05-15 12:42:57.752] [   69.787368] ti-sci 44043000.system-controller: ti_sci_cmd_set_device_constraint: device: 179: state: 1: ret 0
[2025-05-15 12:42:57.768] [   69.787554] ti-sci 44043000.system-controller: ti_sci_cmd_set_device_constraint: device: 178: state: 1: ret 0
[2025-05-15 12:42:57.784] [   69.788423] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down
[2025-05-15 12:42:57.784] [   69.796739] omap8250 2800000.serial: PM domain pd:146 will not be powered off
[2025-05-15 12:42:57.784] [   69.797323] ti-sci 44043000.system-controller: ti_sci_cmd_set_device_constraint: device: 117: state: 1: ret 0
[2025-05-15 12:42:57.800] [   69.827258] remoteproc remoteproc0: stopped remote processor 5000000.m4fss
[2025-05-15 12:42:57.816] [   69.831337] Disabling non-boot CPUs ...
[2025-05-15 12:42:57.816] [   69.833740] psci: CPU1 killed (polled 0 ms)
[2025-05-15 12:42:57.816] [   69.837370] psci: CPU2 killed (polled 0 ms)
[2025-05-15 12:42:57.816] [   69.841169] psci: CPU3 killed (polled 0 ms)
[2025-05-15 12:42:57.832] [   69.843028] Enabling non-boot CPUs ...
[2025-05-15 12:42:57.832] [   69.843440] Detected VIPT I-cache on CPU1
[2025-05-15 12:42:57.832] [   69.843493] GICv3: CPU1: found redistributor 1 region 0:0x00000000018a0000
[2025-05-15 12:42:57.832] [   69.843557] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[2025-05-15 12:42:57.848] [   69.844762] CPU1 is up
[2025-05-15 12:42:57.848] [   69.845044] Detected VIPT I-cache on CPU2
[2025-05-15 12:42:57.848] [   69.845076] GICv3: CPU2: found redistributor 2 region 0:0x00000000018c0000
[2025-05-15 12:42:57.864] [   69.845119] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[2025-05-15 12:42:57.864] [   69.846045] CPU2 is up
[2025-05-15 12:42:57.864] [   69.846331] Detected VIPT I-cache on CPU3
[2025-05-15 12:42:57.880] [   69.846369] GICv3: CPU3: found redistributor 3 region 0:0x00000000018e0000
[2025-05-15 12:42:57.880] [   69.846423] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[2025-05-15 12:42:57.880] [   69.847575] CPU3 is up
[2025-05-15 12:42:57.880] [   69.848103] ti-sci 44043000.system-controller: ti_sci_resume: wakeup source: 0x50
[2025-05-15 12:42:57.896] [   69.864839] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19
[2025-05-15 12:42:57.896] [   69.874124] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [TI DP83867] (irq=POLL)
[2025-05-15 12:42:57.912] [   69.874149] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-rxid link mode
[2025-05-15 12:42:57.912] [   69.880826] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:01] driver [TI DP83867] (irq=POLL)
[2025-05-15 12:42:57.928] [   69.880839] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii-rxid link mode
[2025-05-15 12:42:57.944] [   70.068153] OOM killer enabled.
[2025-05-15 12:42:57.944] [   70.071297] Restarting tasks ... done.
[2025-05-15 12:42:57.944] [   70.078197] random: crng reseeded on system resumption
[2025-05-15 12:42:57.960] [   70.084290] k3-m4-rproc 5000000.m4fss: Core is off in resume
[2025-05-15 12:42:57.960] [   70.090197] remoteproc remoteproc0: powering up 5000000.m4fss
[2025-05-15 12:42:57.960] [   70.096072] remoteproc remoteproc0: Booting fw image am62-mcu-m4f0_0-fw, size 55100
[2025-05-15 12:42:57.976] [   70.107570] rproc-virtio rproc-virtio.2.auto: assigned reserved memory node m4f-dma-memory@9cb00000
[2025-05-15 12:42:57.992] [   70.118263] virtio_rpmsg_bus virtio1: rpmsg host is online
[2025-05-15 12:42:57.992] [   70.119173] virtio_rpmsg_bus virtio1: creating channel ti.ipc4.ping-pong addr 0xd
[2025-05-15 12:42:58.008] [   70.124294] rproc-virtio rproc-virtio.2.auto: registered virtio1 (type 7)
[2025-05-15 12:42:58.008] [   70.131967] virtio_rpmsg_bus virtio1: creating channel rpmsg_chrdev addr 0xe
[2025-05-15 12:42:58.008] [   70.138593] remoteproc remoteproc0: remote processor 5000000.m4fss is now up
[2025-05-15 12:42:58.040] [   70.164813] PM: suspend exit
[2025-05-15 12:42:58.040] root@am62xx-evm:~# [   72.951689] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

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

    尊敬的 Bin：

    感谢您的答复。
    客户尝试了以下测试。

    1) HFOSC0用作 RTC 时钟源。
    将寄存器配置为 0x04508058至 0x00000001。
    在这种情况下、RTC 似乎正常工作、但无法从 SuspendToRam 唤醒、因为 HFOSC0在 SuspendToRam 期间停止。

    2)使用 RCOSC 作为 RTC 时钟源。
    将寄存器配置为 0x04508058至 0x00000000。
    或  
    将寄存器配置  为0x43008600至 0x00000001。
    在这种情况下、可以从 SuspendToRam 唤醒。
    使用以下命令在3秒内唤醒系统。
    root@pos-periph：/home/user # rtcwake -m mem -s 3.

    所以客户理解；
    a) HFOSC 或 RCOSC 均可用作 RTC 时钟源。
    b)仅当 RCOSC 用作时钟源时、才能通过 RTC 唤醒。
    对吧？

    谢谢。此致、
    田代浩一郎

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

    尊敬的 Tashiro-san：

    user6021594 说：
    因此客户理解；
    a) HFOSC 或 RCOSC 均可用作 RTC 时钟源。
    b)仅当 RCOSC 用作时钟源时、才能通过 RTC 唤醒。
    正确？

    我可以复制行为、但我必须进行研究以了解 HFSOC 源为何不唤醒 RTC。

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

    尊敬的 Tashiro-san：

    我今天没有机会做这件事,但我将在接下来的两个星期外出。 当我回到办公室后,我将继续,除非 Anshu 将回到我的面前,并可以处理这个。

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

    尊敬的 Tashiro-san：

    HFOSC 在深度睡眠暂停序列期间关闭。 请参阅 AM62x TRM 中的6.2.4.10通过器件管理器实现低功耗模式时序： https://www.ti.com/lit/pdf/spruiv7

    此致、

    Anshu