Inquiry Regarding Indefinite Off State During RTC-Based Intermittent Operation on Verdin iMX8M Mini

Technical Support
, , , ,
1

We are currently developing a system using the Toradex Verdin iMX8M Mini board. In order to reduce power consumption, we have implemented an intermittent operation scheme that utilizes the RTC hardware to power off the device and automatically power it back on after a designated interval—typically around 8minutes.Additionally, in the event of a system error, the RTC is used to reboot the device after approximately 5 minutes.

This intermittent operation is working well under normal conditions. However, we have recently encountered some rare cases where the system fails to restart and remains in an off state.
We are currently investigating the cause, and we suspect the issue might be related to either the RTC hardware or another unknown factor preventing the system from waking up as scheduled.

•Can the issue be reproduced with a rtcwake of less than 480 seconds?
→In our first system deployment,for error reboots, rtcwake was of about 90seconds. since the issue occured, we changed it to 300s. But regardless of rtcwake time, the device was found to be in continuous off state.

•How often does this issue happen? (ie. Once every 10 times, every 1000 times, etc.)
→This is a very rare issue, it happened after 1.5months in the first system we deployed.
so again it happened after 2months in different system deployment. Actually, we never encountered the issue, while testing in our lab. It happened in long run.

We would greatly appreciate your support in answering the following questions regarding the behavior of the Verdin SoM in this context:

  1. Could the system remain in an off state due to a hardware failure in the RTC?
  2. Is there any known case where the RTC fails to wake the system after issuing the rtcwake command, resulting in the system remaining continuously off?
  3. Is it possible that, following a system error or crash, the Verdin SoM shuts down and remains in an off state indefinitely?

For reference, the hardware and software we are using are as follows:

・Carrier Board: Mallow Carrier Board V1.1C
・System on Module: Verdin iMX8M Mini Quad 2GB IT V1.1D
・Operating System: TorizonCore 6.7.0-build.18
・Command used for rtcwake :”sudo rtcwake -d /dev/rtc1 -m off -s 480” (the main program is running on docker while this command is executed from host as needed from the main program)

further, I had also previously posted about different topic related to rtcwake Reboot host from the docker using rtcwake command inside the container

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello! Thank you for your detailed explanation of the issue you’re experiencing with the Verdin iMX8M Mini and the rtcwake-based intermittent operation. I’ll address your specific questions regarding the RTC and system behavior on your setup.

1. Could the system remain in an off state due to a hardware failure in the RTC?

Yes, it is possible for the system to remain in an off state if there is a failure in the RTC hardware, or if the backup power supply (VCC_BACKUP) to the RTC is compromised. The RTC requires a stable VCC_BACKUP supply to maintain time and alarms when the main power is off or the module is in low-power mode. If the battery is depleted, improperly connected, or VCC_BACKUP is otherwise unstable, the RTC may not be able to trigger a wake event as expected, leaving the system off[1].

2. Is there any known case where the RTC fails to wake the system after issuing the rtcwake command, resulting in the system remaining continuously off?

While the RTC subsystem is typically reliable, rare failures can occur, especially if the RTC or backup supply is marginal, if there are timing or signal integrity issues, or if the system enters an unexpected state (e.g., a crash or incomplete power-down sequence). There aren’t widely reported systematic issues, but field conditions like extreme temperatures, voltage drops, or long-term battery depletion can impact RTC wakeups. Verifying correct backup voltage and connection, and monitoring RTC-related logs or registers, might provide further clues[2][3].

3. Is it possible that, following a system error or crash, the Verdin SoM shuts down and remains in an off state indefinitely?

Yes, this is possible. After a critical error or crash, if the shutdown or power management logic fails to properly set the RTC alarm or the system enters an unrecoverable state before setting up the next wake event, it may remain off. Additionally, if the PMIC (Power Management IC) is not reset or some SoC internal logic remains latched after an unclean shutdown, the module may not respond to wake signals until a full power cycle is performed[3:1].

Recommendations

  • Monitor VCC_BACKUP: Ensure that the RTC backup voltage is always present and within specification.
  • Use Kernel Logs: Check for error or warning messages related to RTC operations or power management in the system logs (dmesg).
  • Test in Extreme Conditions: Try to replicate the field conditions in the lab (temperature, voltage fluctuations, etc.).
  • Watchdog Implementation: Consider using a hardware or PMIC watchdog as a secondary mechanism to force a reboot or wake if not already present.

You can find more about system states and troubleshooting power management in the hardware documentation:

Your issue sounds like a rare edge case that could arise from hardware (RTC or power supply), environmental factors, power management circuitry, or software state. Careful long-term logging and monitoring of RTC, backup supply, and power state transitions would be the next best steps in isolating the cause.

If you’d like, I can provide suggestions for further debugging and log collection.

Best regards,
Toradex AI Assistant.

  1. Verdin iMX8M Mini RTC and Power Supply ↩︎

  2. Verdin iMX8M Mini Power States and RTC Wakeup ↩︎

  3. RTC and Module Power Management Documentation ↩︎ ↩︎

3

Dear @makasujan , thanks for reaching out.

One preliminary check to NXP i.MX8M Mini errata and Verdin iMX8M Mini + Mallow issue tracker and errata doesn’t show issues that would describe what you are experiencing here.

Answering your questions 1 and 3, yes, it is possible if the power / watchdog phase of the SOM/Carrier Board malfunctions to experience these issues.

As for question 2, no known similar issues as of today.

My recommendation would be to reduce the rtcwake lower to make issue happen quicker, and to monitor several power lines like the SOM +V3.3_SW and +V1.8_SW, +V_BAT (if you are using a battery) CTRL_SLEEP_MOCI# and CTRL_WAKE1_MICO# (if used for wakeup events) to understand the wakeup process and monitor for possible malfunctions within those signals.

Hope this helps and that we can resolve the issue.

4

Dear @alvaro.tx ,Thank you for the follow up on the issue.

As for the question i asked, I have a questions similar to question 3 but not related to RTC.
4.Is it possible for the shutdown for the system to shutdown and remain in off state due to other factors such as temperature, vibration, system failures etc.

5.We are not using external battery Vcc_Backup for RTC, I think it’s not necessary to use battery unless there is no Vcc. Incase if we do not use +V_Bat ,is there a problem if there is a voltage fluctuation in Vcc. Do you recommend on using Vcc_Backup?

Thank you for the recommendation. we are currently trying to find the cause of the error by reproducing the error quicker by reducing the rtcwake time lower and monitor the above mentioned powerlines.

one more question
6.Do we have inbuilt backup watchdog timer in case of rtcwake failure. for example, if the system doesn’t wakeup after certain minutes it triggers the force device wakeup?

Thank you very much for your time and assistance. We look forward to your insights.

5

Dear @makasujan

Of course, if there is some instability of any kind that affects the supply voltage and the SOM goes outside of the power specification, it might turn off.

You are correct, but yes, I do recommend using Vcc_Backup specially for your use case. Normally it will just keep the time if the power is off but it might also protect in supply instabilities.
If you are relaying in the RTC for critical operation, I think it justifies the use of using it. It might also save the investigation :slightly_smiling_face:

Depending on the application, you might also consider adding a supercapacitor to protect the supply for a few seconds.

The NXP i.MX8M Mini has a watchdog included but it is not enabled by default. AFAIK the watchdog reboots the board in case of not feeding its refresh, so not sure if it is useful in your specific case: I believe it would reboot the board, not wakeup it. Of course, you are more than welcome to check our documentation and further investigate if it helps in your case.

Kind regards,
Alvaro.

6

Dear @alvaro.tx

The recommended battery from Mallow datasheet(BAT1) is CR1025(30mAh), what would be ideal lifespan of the battery coin considering there is always Vcc and also leakage current from the diode? will it last more than five years?

So we can also add supercapacitor instead of coin battery for voltage instabilities! how do we add supercap in the board?

reference: I have gone through this post about rtc increasing battery life
Thank you for the guidance and support :).

7

Dear @makasujan

If you are using a Mallow + Verdin iMX8M Mini, the coin battery directly connects to a RX8130CE that is also powered by standard power, so the battery will only be drained when the power is off.
Checking the RX8130CE datasheet, current consumption is around 300-500 nA.

image

So for a 30mA, it would take around 6.85 years with the module OFF. Again, the battery doesn’t drain when the module is powered on. This is why we add an external RTC to the SOM instead of using the SoC one by default. Ultra low power consumption.

image
image1052×533 33.7 KB

Please note that adding a supercap would require a custom carrier board design, and cannot be implemented in the Mallow. So if you plan to continuing using the Mallow, then it has to be a coin battery.

Also note that coin battery and supercap are not mutually exclusive :slight_smile: They serve different purposes in general, but for small power cuts that would affect the RTC circuit, they both would work (for different reasons) when the power is on (Super cap only lasts a few seconds).

1 Like
8

Thank you very much for the follow-up and assistance :slightly_smiling_face:, @alvaro.tx .
I’ll keep you updated once I reproduce the issue and identify the cause.

1 Like