Colibri iMX7 inoperable after power cut-off in suspend mode

Technical Support
, , ,
1

We are currently trying to use suspend mode in Linux but face a weird behaviour: When switching to suspend mode via systemctl suspend, cutting off the supply voltage, waiting a little bit and restoring the power supply, the system won’t boot up again. This is only the case if the backup battery for the module’s RTC is connected to VCC_BAT. Even the reset button does not work anymore, as long as the battery is connected.

The suspend/wakup workflow in general is working, the RTC can be used to wakup the system as expected. We’re using a custom carrier board, but the behaviour can be reproduced using the eval board together with the official reference image, so we assume the problem to be on the SoM.

Used Setup

  • Colibri iMX7D 1 GB V1.1A
  • Col Evaluation V3.2B
  • colibri-imx7-emmc_console-image-tezi_3.0b4.254-20200421.tar

Steps to Reproduce

  1. Flash reference Linux image to Colibri
  2. Populate CR2032 battery and make sure it is connected to VCC_BAT (Jumper JP23 set to INT)
  3. Connect to serial terminal via X27 and boot Linux
  4. log in and transition to suspend mode (systemctl suspend)
  5. Cut-off power supply and wait until buffer capacitors have discharged
  6. Reattach power supply and look at the serial terminal: Linux will not boot, SoM seems to be in an unknown state!

If you repeat the steps without the battery, everything works as expected, means that powercycling the eval board always causes a reset of the SoM.

Does anybody of you guys have similar issues? Any help on this would be really appreciated :slight_smile:
Cheers, Marc

2

Hello Marc,

Yes this is a known issue. Please see https://docs.toradex.com/103543-colibri-imx7-errata.pdf

Best Regards,

Matthias

3

Thanks! This was helpful!

4

Hello Marc.windisch,

we can not reproduce this behavior on the 1GB version.
In the version Colibri iMX7D 1 GB V1.1A this is fixed.
Did you really test it with this version?
Do you have other Colibri iMX7D 1 GB V1.1A modules that behave the same ?

Best Regards,
Matthias Gohlke

5

Hello Matthias,

the behaviour described is reproducible always the same with the iMX7D 1 GB V1.1A module I have on my desk. We have several more modules of this revision, I can test them tomorrow an give an update later on.

Cheers, Marc

6

Hello Marc,

did you test other modules? did you already triggered an RMA case?

Best Regards,

Matthias Gohlke

7

Hello Marc,

we have not received an RMA from you to further research the issue.’

Best Regadrds

Matthias Gohlke

8

Hello Marc,

there are two more sample modules on the way to you.
please send the other ones as RMA for a check as soon as possible.
If needed we can also do a zoom call to check if there are a way to solve the problem and exclude other factors.

Best Regards,

Matthias

9

Hello Marc,

can you please send the other modules in for RMA ?

Best Regards,

Matthias Gohlke

10

Hi @marc.windisch ,

Thank you for your patience.

Toradex launched its first quarterly release of BSP 6. On this version of the BSP the issue is not present anymore, according to our internal tests. You might want to confirm that and consider switching to this new version, if that is an option for you.

Alternatively you can also switch to BSP 5.7 (Upstream) where this issue is also not present. :slight_smile:

Let me know if it worked and if switching to BSP 6 is an option for you

Have a great day.

Best Regards
Kevin

11

Hi Kevin,

during the last days I excessively tested the following versions:

  • BSP 5.7.0
  • BSP 5.7.0 (UPSTREAM)
  • BSP 6.0.0 (UPSTREAM)

BSP 5.7.0 does not work with Colibri V1.1A modules. SoM will stay inoperable (also no recovery mode available) until both, main supply and the RTC backup battery were removed till all buffer capacities have discharged.

BSP 5.7.0 (UPSTREAM) seem to solve the issue. Suspend mode works as expected, a power cut-off during suspend does not mess up the SoM.

BSP 6.0.0 (UPSTREAM) also seems to solve the issue but introduces another one. Suspend mode does not work directly after boot. When trying to enter suspend mode, the FS sync is triggered, but the terminal is still available. Only after ~70s the system enters suspend mode:

root@colibri-imx7-emmc-06807405:~# systemctl suspend

root@colibri-imx7-emmc-06807405:~# [ 27.937518] PM: suspend entry (s2idle)

[ 27.962792] Filesystems sync: 0.020 seconds

root@colibri-imx7-emmc-06807405:~#

root@colibri-imx7-emmc-06807405:~# bla

-sh: bla: not found

root@colibri-imx7-emmc-06807405:~# [ 69.610897] cfg80211: failed to load regulatory.db

[ 69.617330] Freezing user space processes … (elapsed 0.007 seconds) done.

[ 69.632336] OOM killer disabled.

[ 69.635762] Freezing remaining freezable tasks … (elapsed 0.003 seconds) done.

[ 69.646980] printk: Suspending console(s) (use no_console_suspend to debug)

Please see the bold red line. It seems like there is a background task blocking the suspend mode. This is reproducible the case. When I wait until the message, the system goes to suspend mode as expected:

root@colibri-imx7-emmc-06807405:~# [ 69.618326] cfg80211: failed to load regulatory.db

root@colibri-imx7-emmc-06807405:~# systemctl suspend

root@colibri-imx7-emmc-06807405:~# [ 80.647493] PM: suspend entry (s2idle)

[ 80.671756] Filesystems sync: 0.019 seconds

[ 80.682067] Freezing user space processes … (elapsed 0.003 seconds) done.

[ 80.693741] OOM killer disabled.

[ 80.697170] Freezing remaining freezable tasks … (elapsed 0.002 seconds) done.

[ 80.707911] printk: Suspending console(s) (use no_console_suspend to debug)

For us this is a problem due to we are using the wakeup timer heavily. If we setup a timer that would fire within the first 70s before the error message and go to suspend, the device would not wakeup again.

We will nevertheless upgrade to BSP 6.0.0 due to this is at least a massive improvement for the systems using a V1.1A SoM. I’m sure the cfg80211 is a minor thing and can be fixed quickly.

Thanks and best regards,

Marc

12

Hello Marc, we are looking into this and retesting to check if we can replicate this and how to fix this.

Best Regards,

Matthias

13

ok we fixed this in BSP 6.1 so you could try the 6.1 nighty.

Best Regards,

Matthias