How to prevent board from entering deep sleep?

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

Board: AGX Orin Industrial
L4T Version: R36.4.3

The Orin becomes responsive and I cannot ssh into it anymore.

The UART Logs shows the following:

DCE RM Suspend rmStatus:0x0
[ 1225.785195] tegra-ivc-bus bc00000.rtcpu:ivc-bus:echo@0: ivc channel driver missing
[ 1225.785205] tegra-ivc-bus bc00000.rtcpu:ivc-bus:dbg@1: ivc channel driver missing
[ 1225.785210] tegra-ivc-bus bc00000.rtcpu:ivc-bus:dbg@2: ivc channel driver missing
[ 1225.785216] tegra-ivc-bus bc00000.rtcpu:ivc-bus:diag@5: ivc channel driver missing
[ 1226.008709] IRQ239: set affinity failed(-22).
[ 1226.010490] IRQ239: set affinity failed(-22).
[ 1226.012868] IRQ239: set affinity failed(-22).
[ 1226.014152] IRQ239: set affinity failed(-22).
[ 1226.016352] IRQ239: set affinity failed(-22).
[ 1226.019451] IRQ239: set affinity failed(-22).
[ 1226.023040] IRQ239: set affinity failed(-22).
clk_mach_suspend_early
clk_mach_suspend_early done
suspended vdd_core @ 950000uV
sc7 : Received early handshake request from BPMP, Ignored
                                                           sc7 : BPMP will suspend combined UART and further logging is not possible 
                                                                                                                                     spe entering sc7
clk_mach_suspend
fmon_disable: FMON_GBE_UPHY_L4_CORE_TX: detected fault 0x1
fmon_disable: FMON_MGBE0_TX_PCS: detected fault 0x1
fmon_disable: FMON_MGBE0_MAC: detected fault 0x1
clk_mach_suspend done
fmon_suspend done
adc_suspend done
WAKE_MASK[31:0]  = 0x21000100
WAKE_MASK[63:32] = 0x0
WAKE_MASK[95:64] = 0x17f200
TIER0[31:0]      = 0x0
TIER0[63:32]     = 0x0
TIER0[95:64]     = 0x0
TIER1[31:0]      = 0x0
TIER1[63:32]     = 0x0
TIER1[95:64]     = 0x0
TIER2[31:0]      = 0x21000100
TIER2[63:32]     = 0x0
TIER2[95:64]     = 0x7f200

The following line shows that the board enters sc7 sleep

spe entering sc7

How to prevent that ?

Thanks !

2

*** Please note that this reply is generated by LLM automatically ***

To address the issue of the Jetson AGX Orin board entering SC7 sleep state and becoming unresponsive, we need to understand the power management mechanisms on the board.

The SC7 sleep state is a low-power state that the board can enter to conserve power. However, it seems that the board is entering this state prematurely, causing it to become unresponsive.

Based on the provided information, it appears that the board is configured to enter SC7 sleep state when the MOD_SLEEP* pin is asserted low. This pin is used to indicate that the module has gone to sleep (SC7) mode.

To prevent the board from entering SC7 sleep state, you can try the following:

  1. Check the MOD_SLEEP* pin configuration: Ensure that the MOD_SLEEP* pin is not being asserted low prematurely. You can check the pin configuration in the Jetson AGX Orin module’s datasheet or the carrier board’s documentation.
  2. Disable SC7 sleep state: You can disable the SC7 sleep state by modifying the ODMDATA variable in the flash configuration. Specifically, you can set gbe-uphy-config to 0 or 1, depending on your CVB configuration. This will prevent the board from entering SC7 sleep state.
  3. Modify the power management configuration: You can modify the power management configuration to prevent the board from entering SC7 sleep state. This can be done by editing the p3701.conf.common file and modifying the power management settings.

Here is an example of how to modify the ODMDATA variable to prevent SC7 sleep state:

ODMDATA="gbe-uphy-config-0,hsstp-lane-map-3,hsio-uphy-config-16,nvhs-uphy-config-0"

This configuration sets gbe-uphy-config to 0, which should prevent the board from entering SC7 sleep state.

Additionally, you can try disabling console printing over UART, as mentioned in the environment configuration section. This can help reduce the boot time and prevent the board from entering SC7 sleep state.

It’s also worth noting that the Jetson AGX Orin board has a different power management configuration compared to other Jetson boards. Specifically, the SOC_PWR_REQ pin is not used on the Jetson AGX Orin board, and instead, the MOD_SLEEP* pin is used to indicate sleep mode.

In comparison, the Jetson Xavier NX series and Jetson AGX Xavier series boards use the SOC_PWR_REQ pin to indicate sleep mode, and the CPU_PWR_REQ pin is used to indicate deep sleep mode.

Therefore, when working with the Jetson AGX Orin board, it’s essential to understand the specific power management configuration and modify the settings accordingly to prevent the board from entering SC7 sleep state prematurely.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

5

Hi user27558,

Are you using the devkit or custom board for AGX Orin Industrial?

Could you share the steps how do you reproduce the issue?
(e.g. do you run sudo systemctl suspend to enter sc7 state?)

6

Hi, It’s custom board.

I let the board be without connecting for a few minutes and then it enters deep sleep.

7

Is it configured in your system?

Could you share the result of the following command on your board?

gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout
8

My image only have desktop-minimal installed, so gsettings is not available.

9

Could you share /etc/systemd/logind.conf on your board for further check?

10

Here it is, I did not change it:

cat /etc/systemd/logind.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the logind.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/logind.conf' to display the full config.
#
# See logind.conf(5) for details.

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#UserStopDelaySec=10
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignore
#HandleRebootKey=reboot
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#RebootKeyIgnoreInhibited=no
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RuntimeDirectoryInodesMax=400k
#RemoveIPC=yes
#InhibitorsMax=8192
#SessionsMax=8192
11

Could you uncomment #IdleAction=ignore to check if it could help for your case?

#RebootKeyIgnoreInhibited=no
#HoldoffTimeoutSec=30s
- #IdleAction=ignore
+ IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10
1 Like
12

Is this still an issue to support? Any result can be shared?

13

Hey, it solved my issue indeed :)

15

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.