I’ve just seen that GPIO1_IO05 pin is set high at the boot of Torizon OS.
After more or less 2" my firmware on M7 core starts running (from u-boot) and it sets the pin to low.
The problem is that on my carrier board this pin is connect to the enable (EN) signal of a motor driver. And so the motor has a small “jump”.
This is not acceptable.
Why this pin is set to high at the very first stage of the boot/power up sequence?
Is this from some configuration in ATF and/or u-boot?
How can I avoid it?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
The GPIO1_IO05 pin is likely set high during the boot process due to default configurations in the bootloader (u-boot) or the ATF (Arm Trusted Firmware). This behavior is common in embedded systems where GPIO pins may default to a high state unless explicitly configured otherwise. To avoid this, you can:
Modify Bootloader Configuration (u-boot): Adjust the GPIO initialization code in u-boot to explicitly set GPIO1_IO05 to low during the early stages of the boot process. This can typically be done by adding specific commands in the bootloader source code or configuration files.
Adjust ATF Settings: Review and modify the ATF settings to ensure that GPIO1_IO05 is initialized to low during the boot sequence. This may involve changing the default state of the GPIO pin in the ATF source code or configuration files.
Device Tree Overlays: If applicable, use device tree overlays to set the GPIO pin state appropriately during the boot process.
By making these changes, you can ensure that the pin is set low before the motor driver is activated, thus eliminating the unwanted “jump” behavior.
Please, also check if these links can help you solve your problem:
Therefore, if you want to ensure this pin remains low early in the boot process, you will need to configure this either in the ATF or in the u-boot board file for the Verdin iMX8MP.
It would be simpler to try first in u-boot and see if this is enough for your application, and, if not, go to the ATF.
The reset pull-up comes from the i.MX8M Plus SoC itself.
If you look at the i.MX8M Plus Reference Manual, the reset state for the SW_PAD_CTL_PAD_GPIO1_IO05 register is 0x00000146.
This translates into the following pad configuration:
PE: PE_1_PULL_ENABLE (1)
HYS: HYS_0_CMOS (0)
PUE: PUE_1_WEAK_PULL_UP (1)
ODE: ODE_0_OPEN_DRAIN_DISABLE (0)
FSEL: FSEL_0_SLOW_SLEW_RATE (0)
DSE: DSE_X6 (11)
Therefore, this pad has by default a weak pull-up. This value is not specified in terms of a resistance due to manufacturing tolerances.
Hello @bruno.tx
yes, your answer clarifies what happens.
In the whole iMX8M-Plus SoC there are only two pins with a pull-up (and not a pull-down).
One of them is GPIO1_IO05 and the other one is GPIO1_IO02 that it’s not exposed on Verdin connector (if I’m right).
For GPIO1_IO05, the only possibile solution is adding a strong pull-down resistor to the carrier board.
