SCU doesn't wake up from "deep sleep" mode

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

SCU doesn't wake up from "deep sleep" mode

654件の閲覧回数
nikolast
Contributor I

System specification:

  • i.MX 8QuadMax (IMX8QMRM) SoC
  • DDR4 RAM: 4GB
  • eMMC Flash: 16GB
  • PMICs PF8200

- We are testing the Deep Sleep mode (Suspend2RAM), but when we're trying to resume the board with appropriate wakeup GPIO IRQ, the board reboots.

- Using light version of it (Susepnd2IDLE), everything works fine. With it, we are sure that our GPIO IRQ is working fine.

- While debugging, we've found out that in the period of resuming, dedicated System Control Unit (SCU) hangs around two seconds after triggering IRQ, and starts the reboot sequence.

- Measuring signals in that phase, using scope, we found out that SCU_WDOG_OUT signal goes to HIGH, and afterwards system reboots.

- SCU controls two PMICs, which SW outputs are power sources for A72 and A53 CPUs, that are a part of suspend-resume sequence. In suspend phase, SCU fw sets aforementioned outputs and some additional ones to LOW and it's expected to put them back to the HIGH in resume, but that's not happening. For that purpose, function "board_set_power_mode" is used, but in resume phase, it's never called.

- We’ve tried to find the trace for that function, and we’ve found that it should be:

Power_up_cpus -> prep_cpu-> pm_force_resource_power_mode-> pm_update_ridx-> ss_trans_power_mode-> sc_ss_ep[ss].ss_trans_power_mode -> ss_trans_power_mode_base->ss_trans_pd soc_trans_pd->board_set_power_mode->board_get_pmic_info-> pmic_init(board.c)

but it seems like that's not the case.

ラベル(1)
0 件の賞賛
4 返答(返信)

601件の閲覧回数
AldoG
NXP TechSupport
NXP TechSupport

Hello,

As specified in this other post:

https://community.nxp.com/t5/i-MX-Processors/SCU-fails-to-wake-up-core-A/m-p/1631026

- Are you using MEK board or your own board?
- If you are using MEK board, can you wakeup Linux by pressing ON_OFF_BUTTON after Linux suspend?
- Do you have following device node in dts:

    sc_pwrkey: sc-powerkey {
        compatible = "fsl,imx8-pwrkey";
        linux,keycode = <KEY_POWER>;
        wakeup-source;
    };

Saludos,
Aldo.

0 件の賞賛

579件の閲覧回数
nikolast
Contributor I

Hello,

We already looked into that issue and it doesn't apply to our situation since we're not using MEK board. We have our own board with specific design (for more details refer to the original question).
When going to suspend ("deep sleep") mode, number of resources are turned off which means that when we want to resume the board all of those resources need to be turned on.
In our case trying while trying to resume, turning on some of those resources fails which leads to SCU hanging and Watchdog asserting to HIGH.

Resource which power change in resume phase causes reboot is "SC_R_SC_MU_1A". To be more specific function "soc_set_sys_if_power_mode" fails and that is happening on the line: soc_set_sys_if_power_mode + 0x15A.
We have no source code for this function, so we cannot be sure if there is some return value that's not correct, or some part is not correct, what's causing the board to reboot and so on.

P.S Our device tree is already checked and everything is in order so no further actions are needed there.

Best regards,
Nikola

0 件の賞賛

554件の閲覧回数
AldoG
NXP TechSupport
NXP TechSupport

Hello,

Got it, could you provide the SCFW version that you are working with?
Also, could you try to check the reset reason using SCFW api and share the result?

Saludos,
Aldo.

0 件の賞賛

530件の閲覧回数
nikolast
Contributor I

Hello,

Our current SCFW version is 1.15.0. Regarding the reset reason we are unable to get it so no additional info there.

Best regards,
Nikola

0 件の賞賛