iMX8QXP SCU wakes up once a second during suspend?

[johnernberg]

Hi,

SCFW: 1.2.7.1
Linux BSP: 4.19.35
SoC: iMX8QXP
PMIC: PF8100

When I put the system into suspend (KS1) I can see the PMIC coming out of standby via the SCU disabling SCU_PMIC_STANDBY. The PMIC then turns on all the rails that are STBY_OFF, and then going back to suspend, once a second. These wakeups have quite a negative impact on our power consumption.
The PMIC watchdog is not enabled, and we cannot see any events on the PMIC interrupt pin when this happens. but the SCU_PMIC_STANDBY pin is pulsed at 1Hz (~8ms duty cycle).

Re-configuring the SCU watchdog to set enableWait=false seems to make the wakeups happen every 2 seconds instead. Disabling the watchdog does not seem to have any effect at all, and the wakeups again seem to happen once a second.

Changing enableWait was done like this, in board_init() during BOOT_PHASE_FINAL_INIT:

wdog32_config_t config;
WDOG32_GetDefaultConfig(&config);
config.workMode.enableWait = false;
config.enableUpdate = true;
WDOG32_Init(WDOG_SC, &config);

Disabling/enabling the watchdog was done like this in board_power() as the final steps:

wdog32_config_t config;
WDOG32_GetDefaultConfig(&config);
config.enableUpdate = true;
if (mode < SC_PM_PW_MODE_ON && mode != SC_PM_PW_MODE_OFF)
{
    config.enableWdog32 = false;
}
else if (mode == SC_PM_PW_MODE_ON)
{
    config.enableWdog32 = true;
}
WDOG32_Init(WDOG_SC, &config);

These settings were not tried together.

What could be the reason for these wakeups? Is it a watchdog? How do we avoid it in suspension?

Thank you in advance.

Regards // John

[mandus_borjesso]

An update to give this thread some closure:

It turns out that the 1Hz pulsing we are seeing on the PMIC_STANDBY pin is related to polling of the ON/OFF button as well as servicing the SECO's watchdog. Somehow, the PMIC_STANDBY pin is tied to this routine. It is therefore required to have this pulsing on B0 silicon. C0 apparently has a fix for this, but it requires completely disabling the watchdog during KS1.

We were able to work around this by manually enabling/disabling our PMIC (setting both RUN and STBY mode to ON/OFF) as part of the board_lpm() function in the SCFW. While the pulsing remains, it doesn't cause all power nets to turn on/off along with it.

I hope this helps someone who is having the same issue.

Best regards,
Mandus

[igorpadykov]

Hi John

these settings may be ignored if wdog was previously configured with

write-once bit UPDATE=0 - Updates not allowed, for example in previous

bootloaders, like seco i.MX8 Boot process and creating a bootable image 

One can refer to "UPDATE"  Watchdog Control and Status Register (CS) described in
sect.13.10.4.1.2 Watchdog Control and Status Register (CS) and
sect.13.10.2.3  Configuring the Watchdog

i.MX 8DualXPlus/8QuadXPlus Applications Processor Reference Manual

Also for suspend mode more proper to use
enableStop;  /*!< Enables or disables WDOG32 in stop mode */

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[johnernberg]

Hi Igor,

Thank you for the advice. I looked into the watchdog configuration and I concluded the following:

The defaults for the watchdog config is aligned with the SCU porting guide, so my re-configuration attempt to disable the watchdog in Wait mode, also disabled it in Stop mode.

Additionally, the default configuration set in the watchdog CST register by the SCU is the following: 0x25e2

Which means it's not enabled in Stop mode by default either, and that updates are by default allowed, as far as I can tell.

What else should I be looking at?

Thank you in advance.

Regards // John

[igorpadykov]

Hi John

what bsp and chip revision used in the case.

L4.19.35 is not best for i.MX8QXP, please try L4.14.98_2.3.0

SCFW: 1.3.0

Linux 4.14.98_2.3.0 Documentation

linux-imx - i.MX Linux kernel 

Please review production rev.C0 document

i.MX 8X C0 Migration Guide Migrating from i.MX 8X B0 to i.MX 8X C0

Try to debug using Normal and Secure Debug for i.MX8/8X Family of Applications Processors

Best regards
igor

[mandus_borjesso]

Hello igorpadykov,

We have bumped to the newest release and are still seeing the 1Hz pulse in KS1. We have failed to disable the M4 in the MEK demo, is there a demo image available from NXP where the M4 is disabled? Alternatively, could you help us disable the M4 so that we can try to reproduce the problem on the MEK board?

SCFW: 1.5.0
Linux BSP: 5.4.24
SoC: iMX8QXP
PMIC: PF8100

Best regards
Mandus

[mandus_borjesso]

Adding some further information to the previous comment. We have tried debugging the problem using a Lauterbach debugger. Interestingly, when we connect the debugger and 'attach' to the SCU over JTAG, the SCU_PMIC_STANDBY signal goes low, powering up the PMIC. Connecting the debugger and attaching is not the same thing, connecting just means physically connecting the debug cable and attaching is done in the Lauterbach software. We are unsure exactly what information is transferred when we press 'attach' but it does NOT halt execution. Seeing as this causes the 1Hz signal to stop, we have not been able to debug what exactly is happening.

We were however able to look at some registers in the SCU, we turned our attention to the LPIT peripheral seeing as the pulse is periodic. Registers listed below:

Offset	Field	Value	Comment
0x08	MCR	0x00000004	DOZE_EN = 1
0x10	MIER	0x00000003	TIE0,TIE1 = 1
0x14	SETTEN	0x00000003	SET_T_EN0, SET_T_EN1 = 1
0x20	TVAL0	0x00009C40	40 000 (decimal)
0x28	TCTRL0	0x00000001	T_EN = 1
0x30	TVAL1	0x00013880	80 000 (decimal)
0x38	TCTRL1	0x01000001	TRG_SEL1, T_EN = 1

Without insight in the code it is hard to determine how, if at all, this affects the SCU_PMIC_STANDBY pin. I would speculate that it could be related to the increased period that John saw when setting config.workMode.enableWait = false.

Best regards,
Mandus

[johnernberg]

Hi Igor,

Apologies for delay in response.

I have now tested with SCU 1.3.1, but with Linux 4.19.35 (our board design requires this Linux and I can't backport those features to 4.14, it would take too much time). I didn't see any relevant changes in power management or clk between the 4.14.98 2.3.0 GA and 4.19.35 1.1.0. Hopefully this was a sufficient test.

I can still see the SCU wake up in a 1Hz frequency with the 1.3.1 version of the SCU.

Best regards // John Ernberg

[igorpadykov]

Hi John

one can try to reproduce issue on i.MX8QXP MEK board with

Linux Binary Demo Files - i.MX 8QXPlus MEK

Best regards
igor

[jonas_karlsson]

Hello Igor,

I tried reproducing the behaviour on the MEK board using L4.19.35_1.1.0_images_MX8QXPMEK by flashing imx-image-full-imx8qxpmek.sdcard to an SD card and running it on the MEK board with B0 silicon.

With the tested software, the suspend pin from the SCU does not assert and no voltages go low. I measured the SCU_PMIC_STANDBY and it was never asserted. There was also no voltage change on the supply nets.

I suspended the board from Linux using "systemctl suspend" and could Linux printed the normal suspend loggin over the UART. After Linux suspended and became unresponsive, I could access the M4 reset functionality via the other UART interface.

We have also tested L4.14.98_2.0.0_ga_images_MX8QXPMEK with the same result.

Is there some trick to getting a proper suspension using the demo image?

[igorpadykov]

Hi Jonas

one can try steps in sect.8.1.Low-power mode configuration

i.MX 8QuadXPlus Power Consumption Measurement

echo mem > /sys/power/state

(Note, if you had run M4 image, due to M4 is running the soc will not goto KS1,

so recommended to run image without M4 to test the KS1).

Best regards
igor