Regarding RTC or SRTC alarm use of imx8dxl

[hojames2025]

Hello NXP experts,

We are using RTC alarm as wakeup source on imx8dxl SoC,
with SCU (imx-scfw-porting-kit-1.18.0) and IMX-ATF (lf-6.1.1-1.0.0).

Working use case (for reference)

1, call sc_timer_set_rtc_alarm()
2, call sc_irq_enable(, SC_IRQ_GROUP_RTC,..)
3, put SoC in suspend mode via ATF
4, when alarm occurs, the system wakes up and jumps to expected entry point.
 

Problematic use case (with System Reset)

1, call sc_timer_set_rtc_alarm()
2, do system reset via ATF or reset caused by watch dog timeout, then SoC resets
3, call sc_irq_enable(, SC_IRQ_GROUP_RTC,..)
4, put SoC in suspend mode via ATF
5, Alarm does not trigger (system stays suspended).
(we configured other pad wakeup source, it can wake up if the pad event occurs.)

Observation:
- Date setting (via `sc_timer_set_rtc_time()` in ATF) is preserved after reset.
- But alarm setting seems lost after reset.

Questions
1. Does RTC Alarm setting persist across **SoC resets**? If yes, what prerequisites are needed?
2. For the failed flow above, is there a missing step (e.g., explicit RTC/SRTC sync) before reset?

From below page:
<https://community.nxp.com/t5/i-MX-Processors/i-MX8-SRTC-API-access-from-M4/m-p/1405915>
We understand the SCU handles all RTC and SRTC sync.
SCU will transfer any pending alarms from the RTC to the SRTC.
The SCU keeps RTC and SRTC synchronized so that the RTC date and alarms are kept during low power states.

Looking forward to your replies.
Thank you.

Best regards, 

[Zhiming_Liu]

Hi @hojames2025 

1. Does RTC Alarm setting persist across **SoC resets**? If yes, what prerequisites are needed?

-->sc_timer_set_rtc_alarm() configures the RTC managed by the SCU/SCFW (high-power domain). After power-up, watchdog reset, or software reset, the RTC time is synchronized back from the SRTC in the SNVS, but the alarm configuration is not automatically restored. Therefore, the alarm must be configured during the early software phase following a reset(After reset, read and reset the RTC alarm in the early stages of ATF before entering suspend).

2. For the failed flow above, is there a missing step (e.g., explicit RTC/SRTC sync) before reset?

-->The “RTC→SRTC alarm transfer” in SCFW is triggered only when entering low-power mode; reset does not trigger this transfer. After reset, sc_irq_enable(..., SC_IRQ_GROUP_RTC, ...) must be re-executed, and the alarm must be set again.


Best Regards,
Zhiming

[hojames2025]

Hi Zhiming,

Thanks for the explanation!
We have a few follow-up questions based on your response:

1. Explicit RTC/SRTC Alarm Transfer API
You mentioned that the "RTC/SRTC alarm transfer" in SCFW is only triggered during low-power mode entry, and reset does not initiate this transfer. And the alarm configuration is not automatically restored. 

- Are there any SCU APIs available to explicitly trigger this alarm transfer at other times (e.g., before a reset)?

- If no such API exists, would modifying the SCU firmware be feasible to enable automatic alarm restoration after a reset? If yes, could you point us to the relevant sections of the SCU firmware code we should review?

2. Accessing SNVS for Alarm Configuration
We assume the alarm setting remains in SNVS after a reset.

- Are there SCU APIs (or any other methods) to read values from SNVS (specifically, the alarm configuration stored there)?

- Our use case requires setting the alarm before a reset, and then relying on that pre-reset alarm to wake the system after reset.

If the alarm cannot be restored after reset, we have to save the alarm setting in some eMMC before reset, then after reset, read the setting from eMMC and do the alarm configuration. 

But storing the alarm in eMMC is not ideal for reliability, so retrieving the value directly from SNVS would be much more feasible. Could you advise on how to achieve this?

Looking forward to your insights!

Best regards,

[Zhiming_Liu · Accepted solution]

Hi @hojames2025 

For Q1, there is no open souce for SNVS in SCFW, the functions are compiled in fsl_snvs.o, so modifing the function behavior is not possible in SCFW.

For Q2, please refer 3.9 SNVS and SECO in sc_fw_port.pdf, you could consider write/read LPGPR2 and  LPGPR3.

Best Regards,
Zhiming