i.MX8 Mini GPIO1_IO09 is automatically driven high after power-on/reset

[eik3]

Hi,

I am working on a project using the i.MX8 Mini and we are having an issue regarding the GPIO1_IO09 behavior after power-on and reset.

Specifically, right after powering-on or resetting the i.MX8M, this GPIO stays high for ~1.8 seconds before it finally goes down because we have enabled the internal pull-down. The GPIO is setup as output and there are not any external pull-up or pull-down.

Why is this GPIO going high during ~1.8 seconds?
Is it possible somehow to configure it to be always low after power-on and reset?

Thanks in advance.

Héctor

iMX8MMINI

[Chavira]

Hi @eik3!

Thank you for contacting NXP Support!

That is not a normal behavior.

By default that pin has configured a pull-down resistor.

Could you share how are connecting the GPIO?

Are connected to another device?

Are you using a evk board?

Best Regards!

Chavira

[eik3]

Hi @Chavira!

Please, find attached the part of the schematic showing how the GPIO1_IO09 (a.k.a. AT1_09_MDM_PWR_ON) is connected to the PWRKEY signal of a 4G module. We are not using an EVK board.

Do you see anything suspicious?

Best regards.

[Chavira]

Hi @eik3!

You could have the same problem in the next post:

https://community.nxp.com/t5/i-MX-Processors/GPIO-glitch-during-the-bootup-or-power-on-in-IMX8M/m-p/...

I recommend removing R1603 and R1607 and trying to do the measurement at the Test point.

The ground of the 1v8_4g is the same as the imx8m?

If the problem persists please let me know.

Best Regards!

Chavira

[eik3]

Hi @Chavira,

I have removed R1603 and the result is the same (see in the attached picture the measurement at Test Point TP1603).

I confirm you that the ground of the 1v8_4g is the same as the i.MX8M.

Best regards.

[Chavira]

Hi @eik3!

- What is the exact software stack are you using?

You are using the typical U-Boot + Linux?
In that case, is the board still in U-Boot during those 1.8s or is it already booting the Kernel? In fact, when are those 1.8s relative to the reset moment? Can you put simultaneously on the scope both the RESET signal and TP1603 with R1603 still disconnected?

Can you share with us the device tree for U-Boot and for the Kernel that you are using?

Best Regards!

Chavira

[eik3]

Hi @Chavira,

We are using U-boot + Linux.

Apparently, U-boot starts after those 1.8 seconds (the typical "Hit any key to stop autoboot:" countdown appears right after the end of the high-level pulse).

I have attached 3 pictures of the same measurement with different cursors:

• SDS00003.png --> cursors measuring the 1.892s high-level pulse.
• SDS00004.png --> cursors measuring the time between the power-on of the board and the end of the high-level pulse.
• SDS00005.png --> cursors measuring the time between the power-on of the board and the start of the high-level pulse.

Finally, I have also attached our U-boot device tree files:

• atlas-imx8mm.dtsi
• atlas-imx8mm-pulsar-phoenix.dts

Thanks in advance.

Best regards,

Héctor

[Chavira]

Hi @eik3!

I think you forgot to attach the two device tree files. Could you please send them?

Thanks,

Chavira

[Chavira]

Hi @eik3!

I think you forgot to attach the two device tree files. Could you please send them?

Thanks,

Chavira

[eik3]

Sorry, my mistake.

[Chavira]

Hi @eik3!

How did they enable the internal pull-down resistor? 

In the pad configuration the internal resistor does not seem to be enable:

MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9      0x1      /* MODEM PWR_KEY*/

Please try with this configuration instead:

MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9      0x116      /* MODEM PWR_KEY*/

[eik3]

Hi @Chavira,

I've tried your configuration and the result is the same.

I think the issue happens before entering on U-boot. Is there a way to force the internal pull-down resistor earlier?

Best regards,

Héctor

[Chavira]

Hi @eik3!

I've tried to reproduce this on our EVK, using your device tree, but I don't get the same behavior. The pin stays low while U-Boot boots.

Are you sure that no other connection to that pin is the culprit for pulling the pin high? One way to investigate is to completely remove the pin from the device tree, so it stays default (input).

On the customer's board, is this IO bank supplied with 3V3 or 1V8? In case of 3V3, the GPIO does not support internal pull-up or pull-down resistor. So, an external pull-down resistor is mandatory.

Best Regards!

Chavira

[Chavira]

Hi @eik3!

Please try to add the “u-boot,dm-spl;” property into the iomuxc node.

Since SPL runs from OCRAM (limited size), the device tree is filtered to remove unnecessary nodes. All nodes that do not have "u-boot,dm-spl;" will be removed and your pad configuration will not be taken into account by SPL.

[eik3]

Hi @Chavira,

Adding "u-boot,dm-spl;" as follows does not make any difference:

(...)
&iomuxc {
	u-boot,dm-spl;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_hog>;

	pinctrl_hog: hoggrp {
		fsl,pins = <
			MX8MM_IOMUXC_SD2_WP_GPIO2_IO20		0x101	/* MODEM nRST_MODEM */
			MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9	0x101	/* MODEM PWR_KEY*/
		>;
	};
(...)