Verdin AM62 issues with wake up

Hello,

I need to use the CTRL_PWR_BTN_MICO in a Verdin AM62 V1.2A module the same way a smart phone button works, like mentioned in the Verdin family spec Section 5.3.

After configuring logind’s “HandlePowerKey” with “hibernate”, short presses of the CTRL_PWR_BTN_MICO now put the module into sleep. According to the spec, the CTRL_PWR_BTN_MICO should be be able to wake the module up, the problem is that only CTRL_WAKE1_MICO can do it.

Is it possible to configure CTRL_PWR_BTN_MICO also as a wake up source? I tried to put “ti,power-button” in the PMIC’s device tree node with an overlay but the module did not stop rebooting after that.

I also tried shorting CTRL_PWR_BTN_MICO and CTRL_WAKE1_MICO together but the device would only boot up again after the PMIC’s shutdown if I removed the power source and waited until the LEDs were off.

I’m using a Verdin AM62 Dual WB IT V1.2A and a Mallow carrier board V1.1C. The BSP version is 7.4.0-devel-20250905163604-build.0.

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:


Based on the Verdin AM62 V1.2 datasheet and power management specifications, I can help clarify the power button functionality and wake-up configuration.

CTRL_PWR_BTN_MICO# Power Button Behavior

According to the Verdin Family Specification, the CTRL_PWR_BTN_MICO# signal functions as follows (1)(2):

  • Short pressing (< 5 seconds): Powers up the system from “Module OFF” state or wakes the system from sleep state
  • Long pressing (> 5 seconds): Shuts down the system immediately without software interaction
  • When the module is running, short pressing generates a software interrupt that can trigger shutdown or open a power menu

Wake-Up Sources Configuration

The Verdin AM62 V1.2 has dedicated wake-up capabilities through specific pins (3):

  • CTRL_WAKE1_MICO#: This is the dedicated wake-capable pin for resuming from sleep mode (1)(2)
  • CTRL_PWR_BTN_MICO#: While this can wake from “Module OFF” state, its behavior during sleep states depends on the power management configuration

Device Tree Customization Approach

For configuring power button wake-up functionality, you should use Device Tree Overlays rather than modifying the base device tree (4). Device Tree Overlays provide a flexible way to customize hardware configuration without rebuilding the entire system.

Pin Configuration Details

Looking at the Verdin AM62 V1.2 datasheet, the power management signals are defined as (3):

  • CTRL_PWR_BTN_MICO# is an open-drain input with 100k pull-up resistor to the 1.8V RTC rail
  • CTRL_WAKE1_MICO# has no pull resistors on the module and can be left floating if wake feature is disabled in software

Recommendations

  1. Use CTRL_WAKE1_MICO# as the primary wake-up source, as it’s specifically designed for this purpose
  2. Configure the PMIC properly through device tree overlays rather than direct modifications
  3. Check power management sequences to ensure proper sleep/wake transitions

The rebooting issue you experienced when adding “ti,power-button” suggests a configuration conflict. Instead of shorting the pins together, consider using CTRL_WAKE1_MICO# as your dedicated wake-up source while keeping CTRL_PWR_BTN_MICO# for power management functions.

For detailed pin assignments and alternate functions, refer to the Interface Description section of the Verdin AM62 V1.2 datasheet (3).

Best regards, Toradex AI Assistant.

As per product requirement, I cannot have a dedicated button to wake the device up. So, it’s not possible to use CTRL_WAKE1_MICO as the wake up source.

The modification to the PMIC’s node was done via device tree overlay.

Is it possible to configure the CTRL_PWR_BTN_MICO pin so that it can trigger a software sleep and also wake the module up as shown in the flowchart in the Verdin family specification Section 5.3 (Figure 11)?

Hi @rodolfo_silva!

Sorry for the delayed response.

According to the flowchart you referenced, the sleep mode is triggered by software. Then, the CTRL_PWR_BTN_MICO is used to wake the system. Therefore, I’m not sure if it is possible to activate the sleep mode with the CTRL_PWR_BTN_MICO.

I’ll try to test in the next days and also talk to the R&D team to check if this behavior is expected or not.

Feel free to ask if you have any doubts.

Best regards.

I configured the software trigger via logind with a drop-in file. As is, it is possible to both suspend and shut down with the CTRL_PWR_BTN_MICO.

At the moment I can’t use the CTRL_PWR_BTN_MICO pin as wake up from the suspended state, whereas I can do it with the CTRL_WAKE1_MICO pin.

If needed, here’s the drop-in I’m using:

[Login]
HandlePowerKey=suspend
HandlePowerKeyLongPress=poweroff

Hello @rodolfo_silva !

I hope you’re doing well.

I noticed it has been a while since the last update on this topic, and I’d like to kindly check if you were able to make any progress regarding this issue.

Best regards,
Daniel Morais

It took a long time to come back to this topic, but I tested more configurations using device tree overlays with no success.

I configured the CTRL_WAKE1_MICO# as a power pin, but as expected it wasn’t able to power the verdin on, although it can shutdown and enter sleep.

I also tried configuring the PMIC as a wake up source but it did not work.

The current BSP version I’m using is the 7.6.0-devel

Hi Rodolfo!

Welcome back!

I’m excited to help you with this use case! While I’m testing this functionality on my end, could you please share details about what you’ve tried since your last conversation with our support team?

Best regards,

  1. To test the CTRL_WAKE1_MICO, I added the following device tree node:
&verdin_key_wakeup {
	linux,code = <KEY_POWER>;
};

With it, the Verdin suspends with a short press and shuts down with a long press of the CTRL_WAKE1_MICO. It can also wake up from suspend, but can’t turn on after the shutdown. That was kind of expected.

  1. To test the CTRL_PWR_BTN_MICO again, I modified the PMIC’s node , but with the following overlay:
&main_i2c0 {
	pmic@30 {
		wakeup-source;
	};
};

With it, the Verdin suspends with a short press and shuts down with a long press of the CTRL_PWR_BTN_MICO. It can power on from shutdown with a press of the CTRL_PWR_BTN_MICO, but it can’t wake up from suspend.

  1. I saw on the TPS65219 datasheet that there is a standby state that depends on the MODE/STBY polarity, but I did not see any way that it would be possible to use the same Verdin input as a power on signal and wake up source.

Hi Rodolfo,

I checked internally with our specialists, including Daniel that you just talked about this topic, and here what I got:

What you’re seeing is expected due to hardware constraints:

  • CTRL_PWR_BTN_MICO# is connected directly to the PMIC, not the SoC, so it cannot be used as a GPIO or wake source in Linux (no DT configuration possible).

  • CTRL_WAKE1_MICO# is a MAIN domain GPIO, so it can wake from Standby, but not from DeepSleep (MAIN domain is powered off there).

What you can do:

  • If Standby is acceptable → use CTRL_WAKE1_MICO# as your wake source via gpio-keys.

  • If you need DeepSleep → you must use a WKUP-domain GPIO for wake.

  • For a single button design, the typical approach is:

    • Keep CTRL_PWR_BTN_MICO# for PMIC control (on/off)

    • You can also route the same button (via proper isolation) to a wake-capable GPIO

Best regards,

Connecting both pins to the same button and using the default device tree from the verdin am62 and mallow seems to work, but:

  • When using HandlePowerKeyLongPress=poweroff: the module powers off but doesn’t turn back on again if I don’t wait until the Mallow’s LEDs 3 and 4 are off;
  • When using HandlePowerKeyLongPress=ignore: the module powers off quicker and doesn’t turn back on again if I don’t wait until the Mallow’s LEDs 3 and 4 are off.

Is there any configuration to prevent it from powering off until the PMIC commands it to?

Hello Rodolfo,

This behavior is expected and it’s not something you can fix with a Linux/systemd configuration. HandlePowerKeyLongPress only changes what userspace does after receiving a power-key event; it does not control the PMIC state machine, rail discharge time, or when the platform is ready to accept a new power-on.

If you press the button again before the power-off sequence has fully completed (your observation that it only works after Mallow LEDs 3/4 are off is a good indicator), the PMIC may still be transitioning or rails may still be discharging/residual/backfed, and a new power-up can fail. The solution is to ensure a clean OFF state before reapplying power-on (and, if needed for your product, add button lockout/conditioning or investigate backfeeding paths), rather than trying to delay shutdown in software.

If you want a more controlled solution, I think the use of CTRL_WAKE1_MICO approach should be better.

Hello @rodolfo_silva2,

Is this solution was helpful to you?

Best regards,

Thanks for all the info, Diego.

Still haven’t decided which route to follow, but it explains the observed behavior.