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: Wakeup from Deep Sleep by timers

Part Number: AM625
Other Parts Discussed in Thread: SK-AM62B-P1

Tool/software:

Hi,

My customer wants to implement below scenario. SDK version is 10.01.10.04.

Scenario:
Step#1: When there is no active operation, the system enters Deep Sleep.
Step#2: If there is no wake-up events for a while (i.e. 3 seconds), the system goes to shutdown (OFF mode).
As there is no direct power mode transition from Deep Sleep to OFF, the device once wakes up from Deep Sleep, then enters to OFF.

Questions:
Q1) During Deep Sleep, which timers can be used as wake-up source?
Q2) The customer wants to minimize power consumption in Deep Sleep, which timer should be used as wake-up source?
Q3) Any examples or document available to use the recommended timer as wake-up source from Deep Sleep?

Thanks and regards,
Koichiro Tashiro

  • Hi Tashiro-san,

    Q1) During Deep Sleep, which timers can be used as wake-up source?

    General purpose timers (including Main Domain, MCU Domain, WKUP Domain timers) have not been implemented as wakeup sources in the Linux SDK yet. There is not a plan currently to enable general purpose timers as wakeup sources.

    Only the Real Time Clock (RTC) has been implemented as a wakeup source.

    Q3) Any examples or document available to use the recommended timer as wake-up source from Deep Sleep?

    If the RTC timer is acceptable for the application, refer here: https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/10_01_10_04/exports/docs/linux/Foundational_Components/Power_Management/pm_wakeup_sources.html#real-time-clock-rtc

    Best Regards,

    Anshu

  • Hi Anshu,

    Thanks for your quick reply.
    The RTC timer is acceptable.

    The customer tried to use RTC timer as wake-up source from SuspendToRAM on their custom board.
    But it seems the wake-up counter is not correct.

    They tested 3 seconds (rtcwake -m mem -s 3) and 10 seconds (rtcwake -m mem -s 10) for wakeup time.
    But it took ~9 seconds and ~29 seconds, respectively.

    [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:~# 
    


    Thanks and regards,
    Koichiro Tashiro

  • Hi Tashiro-san,

    They tested 3 seconds (rtcwake -m mem -s 3) and 10 seconds (rtcwake -m mem -s 10) for wakeup time.
    But it took ~9 seconds and ~29 seconds, respectively.

    Can you explain how this was tested? Was this using the OS time, stopwatch device, or something else?

    Thanks,

    Anshu

  • Hi Tashiro-san,

    Additionally, can you confirm if the RTC module used for this is the internal RTC on AM62x or an external RTC IC?

    What is the output of these two registers?

    0x04508058 and 0x43008600

    These two registers control the Clock Muxing into the RTC module so we can check which oscillator is being used.

    Thanks,

    Anshu

  • Hi Anshu,

    Can you explain how this was tested? Was this using the OS time, stopwatch device, or something else?

    The time was measured using OS time.
    46.294 - 37.136 = ~9 sec.
    [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:~#
    32:20.302 - 31:51.371 = ~29 sec. 
    [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:~#

    Additionally, can you confirm if the RTC module used for this is the internal RTC on AM62x or an external RTC IC?

    The internal RTC is used.

    I will check these two registers values.

    Thanks and regards,
    Koichiro Tashiro

  • Hi Anshu,

    What is the output of these two registers?

    0x04508058 = 0x00000003
    0x43008600 = 0x00000000

    Thanks and regards,
    Koichiro Tashiro

  • Hi Tashiro-san,

    Anshu has an emergency and currently is out of office. I am not sure about the RTC wakeup latency, but will test it on the EVM and let you know.

    On top of my head, checking the kernel message timestamps doesn't really reflect the RTC wakeup time. The "-s 3" in rtcwake command tells the RTC to generate wakeup event in 3 seconds, but kernel would take more time to resume and reach to the command line prompt.

  • Hi Tashiro-san,

    Here is my test log of SDK10.1 on SK-AM62B-P1. Line 10 is the last print when entering suspend, and line 11 is the first print when resuming. The timestamp difference between the two lines is 3.12 seconds. It is not the exact rtc wake time, but it gives a rough idea.

    [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

  • Hi Bin,

    Thanks for your reply.
    The customer tried below tests.

    1) Used HFOSC0 as RTC clock source.
    Configure register at 0x04508058 to 0x00000001.
    In this case, RTC seems working, but wake up from SuspendToRam is not possible as HFOSC0 is stopped during SuspendToRam.

    2) Used RCOSC as RTC clock source.
    Configure register at 0x04508058 to 0x00000000.
    or 
    Configure register at 0x43008600 to 0x00000001.
    In this case, wake-up from SuspendToRam is possible.
    The system wakes up in 3 second with below command.
    root@pos-periph:/home/user# rtcwake -m mem -s 3

    So the customer understand;
    a) Either HFOSC or RCOSC can be used as RTC clock source.
    b) Wakeup by RTC is possible only when RCOSC is used as clock source.
    Correct?

    Thanks and regards,
    Koichiro Tashiro

  • Hi Tashiro-san,

    So the customer understand;
    a) Either HFOSC or RCOSC can be used as RTC clock source.
    b) Wakeup by RTC is possible only when RCOSC is used as clock source.
    Correct?

    I can replicate the behavior, but I will have to look into it to understand why HFSOC source doesn't wake up rtc.

  • Hi Tashiro-san,

    I didn't get a chance to work on this today, but I will be out for the next two weeks. I will continue once I am back in office, unless Anshu will be back before me and can work on this.

  • Hi Tashiro-san,

    The HFOSC is turned off during the Deep Sleep Suspend sequence. Refer to 6.2.4.10 Low Power Mode Sequencing with Device Manager in the AM62x TRM: https://www.ti.com/lit/pdf/spruiv7

    Best Regards,

    Anshu