Read input value of CTRL_RECOVERY_MICO in user mode

Technical Support
1

Dears,

I’d like to know if on the Verdin AM62 chipset is possible to read in user space the value of the pin CTRL_RECOVERY_MICO, in SODIMM is pin 246. In case, is it possible to define it in an overlay file?

I am looking in the datasheet and related documentation and I cannot find the reference to correctly set it up as input pin like in this example:

&main_pinctrl {
pin246_gpio_state: pin246-gpio-state {
pinctrl-single,pins = <
AM62X_IOPAD(0x0184, PIN_INPUT_PULLUP, 7)
>;
};
};

&main_gpio1 {
pin246-gpio {
gpio-hog;
gpios = <29 GPIO_ACTIVE_LOW>;
input;
pinctrl-names = “default”;
pinctrl-0 = <&pin246_gpio_state>;
line-name = “verdin-pin-246”;
};
};

Thanks,
Andrea

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 Andrea,

Thank you for your question!

The CTRL_RECOVERY_MICO# pin on SODIMM 246 of the Verdin AM62 is a dedicated recovery signal. According to the Verdin AM62 datasheet, this pin is connected internally to a recovery circuit and not directly to any SoC GPIO controller[1].

Key points to consider:

  • No direct GPIO mapping: SODIMM 246 (CTRL_RECOVERY_MICO#) does not have a direct connection to a GPIO controller inside the SoC. Therefore, it cannot be configured as a standard GPIO using device tree overlays.
  • Device tree won’t work: Your example overlay cannot be used for this pin, as there is no corresponding SoC ball for standard pin multiplexing[2].
  • Dedicated function: This pin is reserved for forcing the module into recovery mode when pulled low during power-up and does not appear in the alternate (GPIO) function tables.

What can you do instead?

  • Alternative: Choose a different pin: If your goal is to monitor or control a GPIO in user space, please use another SODIMM pin that offers proper GPIO functionality. The Verdin AM62 has several GPIO-capable pins such as SODIMM 206 (GPIO_1), 208 (GPIO_2), and others[2]. You can configure these as GPIOs using device tree overlays, as shown in the overlays documentation[3].
  • External monitoring (advanced): If you specifically need to observe the recovery pin state in software, you’d need to implement additional circuitry on your carrier board to sense SODIMM 246’s state and route it to a usable GPIO input. This would require hardware design on your side.

In summary, you cannot access CTRL_RECOVERY_MICO# as a GPIO in user space on the Verdin AM62. Please refer to the datasheet pinout section and the device tree overlay guide to select and configure an appropriate GPIO for your application.

Let me know if you need more help selecting or configuring a GPIO pin!

Best regards,
Toradex AI Assistant.

3

Hi @dm-andreapedica ,

Did the answer provided by Toradex AI help you solve the issue?

Also, just to understand better, CTRL_RECOVERY_MICO (SODIMM pin 246) is typically used for triggering recovery mode on boot, and it’s not usually intended to be accessed or configured from user space.

May I ask what’s the purpose of reading this pin from user space? Depending on the use case, we might be able to suggest a safer alternative.

Best regards,

4

Everything mentioned above is correct for Verdin iMX8M modules (where you can’t read the CTRL_RECOVERY_MICO# signal). However, on the Verdin AM62, this is indeed possible. Specifically, the CTRL_RECOVERY_MICO# signal connects directly to ball GPMC0_AD3 (GPIO0_18), and inversely to ball GPMC0_AD4 (GPIO0_19). You can read these signals at runtime, but be aware that pulling down the CTRL_RECOVERY_MICO# line during reset or power-up will prevent the Verdin AM62 module from booting normally and instead trigger recovery mode.

To read the value of GPIO0_18 from user space, proper muxing is required in the device tree. This can be achieved with the following configuration:

  1. Add the pinmux definition as a standalone group within the &main_pmx0 node:
&main_pmx0 {
    my_gpio_ad_pins: gpio-ad-pins-default {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x0048, PIN_INPUT, 7) /* GPMC0_AD3 → GPIO0_18 */
            AM62X_IOPAD(0x004C, PIN_INPUT, 7) /* GPMC0_AD4 → GPIO0_19 */
        >;
    };
};
  1. Explicitly reference this pinmux group within the main GPIO controller node (&main_gpio0):
&main_gpio0 {
    pinctrl-names = "default";
    pinctrl-0 = <&my_gpio_ad_pins>;
    status = "okay";
};

With this configuration, you can reliably access and read the GPIO signals from user space during runtime.

5

Thanks for the suggestion, we will give it a try just to validate it in case of future needs. As a “safe” decision anyway we finally decided to route the signal to another free gpio in parallel.

6

Hello,

yes the AI answer lead us to decide to opt for a safer solution to route the button input to another free GPIO where we can get access in user mode.

To give you more details about the situation: the CTRL_RECOVERY_MICO is linked to a push button that is used in our project for 2 functions:

  • trigger a functional operation
  • enable the recovery mode

So we need to get access in user mode to trigger the related program specific function, but also it is used as recovery mode if kept pressed before power on the system.