Imx7: should GPIOs keep their states during system shutdown

Technical Support
, , , , ,
1

Hello everyone!
I am working on a product that uses Colibri iMX7 SoM with a custom carrier board. As for software, we are using Yocto with Toradex BSP and custom meta-layer.
Some time ago, we have updated Yocto and BSP to 5.x.y version (previously we were using LTS 3). Of course we had to adjust our custom recipes but the board work correctly now although I have noticed one misbehavior and I am not sure if it’s intended.

So, we have a LED on the board and by default, pre-boot, when GPIOs are uninitialized, it is turned on, because of a pullup resistor. During the boot process, we initialize one of iMX7’s GPIOs and short the line to ground so the LED is turned off. So far so good.

The potential misbehavior is occurring when executing shutdown -h now command.

  • On the “old” system (LTS 3), 10-20s after executing the command, the LED was being “released” so it was going back to its default state - on.
  • On the “new” system (5.x.y), it looks like the GPIO that controls the LED is being kept in 0 state, so the LED is off.

At first I was thinking, that maybe the shutdown process doesn’t end correctly and hangs somewhere, causing the GPIO to not get “freed” properly but after some investigation, everything seems to be okay.
Following the advice from here, I have created a script file that should be executed as one of the last things during shutdown:

root@colibri-imx7-emmc:~# cat /lib/systemd/system-shutdown/debug.sh                                                                                                           
#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
echo "asd" > /asd.txt
mount -o remount,ro /

So, the script gets executed, so it porbably indicates that the shutdown process ends correctly. According to that webpage, If normal reboot or poweroff never finish even after waiting a few minutes, the above method to create the shutdown log will not help and the log must be obtained using other methods
As for the logs, they look mostly the same between the two versions and they end in the same spot. I am not sure if I can post the whole dmesg so I can show you the endings for now:

shutdown_logs.txt (7.0 KB)

So, my question is - is it possible that the updated system behaves differently and somehow keeps the GPIOs state even after successful shutdown?

The thing is that after executing that shutdown command, we are cutting off iMX7’s power supply, so we would like to make sure that the shutdown is clean, to not get any file corruption etc.

2

Hello smagrian,

which SODIMM PINs or GPIOs is the using for the LEDS.
Are you using a custome device tree?

Best regards,

Matthias Gohlke

3

@matthias.tx Thank for you response!

We are using gpio56 which I believe corresponds to GPIO2_IO24
It is turned off in one of our initialization scripts using sysfs:

echo 56 > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio56/direction
echo "0" > /sys/class/gpio/gpio56/value

Yes, we are using a custom device tree:
imx7d-colibri-emmc-custom.dts (14.5 KB)

4

Hi @smagrian !

I would like to ask you some questions to better understand your use case.

  1. I understood that the LED turning off is unwanted behavior, but could you elaborate on your application or the intended behavior?

  2. Also, have you tried on default BSP 3 reference image to see which behavior you get from the same GPIO? Also, if possible, try the same on BSP 5 with the default reference image.

  3. From BSP 3 to BSP 5 you made changes to your device tree? Could you share both device trees?

  4. You are using a custom carrier board. Could you confirm that from BSP 3 usage to BSP 5 there were no modifications on your carrier board? Also, could you please share the schematics for this specific pin?

Best regards,

5

Hi @henrique.tx, thanks for responding.

  1. The LED being kept off itself is not really an unwanted behavior . It’s just a status LED so it doesn’t really matter whether it is turned on or off during the shutdown. The reason I think it might be important is that it worked differently with the older version of the BSP. So, I think two scenarios are possible here
    a) The new BSP handles GPIOs differently, making them somehow able to preserve their states during/after shutdown
    b) Something with our system got messed up and the device is not shutting down completely.
    I am just looking for ways to confirm whether it’s A or B. If it’s A then there’s nothing wrong and we can accept the LED being switched off. On the other hand, if it’s B, then we have a problem, because after shutdown we turn the power supply of the device off, so if it has not shutdown properly, we might cause for example memory corruption.

  2. I can try it sometime but unfortunately, currently I do not have tools to flash the reference image on the board.

  3. No, we haven’t changed the device tree.

  4. We haven’t changed the hardware as well. And the circuit is below. The pin I am talking about is LED_DEFAULT_DISABLE. As you can see, when it is in it’s default, uninitialized, high-Z state, the MOSFET is turned on so the green LED is also turned on. When the pin is initialized and set to 0, the LED is no longer on.
    You can disregard the I2C controller and assume it’s not used. I am sure it is not responsible for that LED’s described behavior.

led_circuit
led_circuit1228×1002 77 KB