stm32l4 System Power Management issue

[ivonalo]

I am using the system PM on the stm32l4 board because I want to use the pm_power_state_set function to put the stm32l4 into stop2_mode but only after certain conditions are fulfilled. So, the idea is that after turning on, the stm32l4 is in active state (PM_STATE_ACTIVE) and stays in active state. Only when certain conditions are fulfilled, I want to call the pm_power_state_set function to put in some other PM state.

As I understood, when CONFIG_PM is enabled I can implement my own power management policy, and my policy would be when turned on go to PM_STATE_ACTIVE and stay there as long as I don't tell you to go to some other state.

In prj.conf I have enabled following things:
CONFIG_PM=y
CONFIG_SOC_LOG_LEVEL_DBG=y
CONFIG_PM_LOG_LEVEL_DBG=y
CONFIG_IDLE_STACK_SIZE=8192
CONFIG_PM_POLICY_APP=y

My policy handler is very simple:

struct pm_state_info pm_policy_next_state(int ticks)
{
	LL_LPM_DisableSleepOnExit();

	return (struct pm_state_info){ PM_STATE_ACTIVE, 0, 0 };
}

The problem I have, is that after turning on, my stm32l4 after few seconds just stops working, I don't get anything on the serial output anymore and it seems like it is in some deep sleep mode because it is totally unresponsive. In my main.cpp i have forbidden any other state then PM_STATE_ACTIVE, so I don't understand how this can happen:

static int disable_ds_1(const struct device *dev) {
  ARG_UNUSED(dev);

  pm_constraint_set(PM_STATE_STANDBY);
  pm_constraint_set(PM_STATE_SOFT_OFF);
  pm_constraint_set(PM_STATE_SUSPEND_TO_IDLE);
  pm_constraint_set(PM_STATE_RUNTIME_IDLE);
  pm_constraint_set(PM_STATE_SUSPEND_TO_DISK);
  pm_constraint_set(PM_STATE_SUSPEND_TO_RAM);

  return 0;
}

SYS_INIT(disable_ds_1, PRE_KERNEL_2, 0);

What I also don't understand is that after debugging I see that once I tell the smt32l4 to go to PM_STATE_ACTIVE it still continuously enters the pm_system_suspend function, like in a while loop, even though in my main.cpp application it is executing some other functions so it should not go into Idle Thread.

Also, I have tried to use the other two power management policies: Residency and Dummy and it didn't work for me.

Am I missing something or am I totally on the wrong track here?
My SHA1 ID: afb7394

[erwango]

@ivonalo It's hard to answer in detail when we don't have the complete view on application implementation (as well as on potential patches in the code tree).

Anyway, would you mind providing the SHA1 you're using ? There are some on going changes on pm subsystem and it can have impact on what you're seeing.

Also, did you have a try to enable CONFIG_DEBUG? It should help in debugging your case.

[ivonalo]

@ivonalo It's hard to answer in detail when we don't have the complete view on application implementation (as well as on potential patches in the code tree).

Anyway, would you mind providing the SHA1 you're using ? There are some on going changes on pm subsystem and it can have impact on what you're seeing.

Also, did you have a try to enable CONFIG_DEBUG? It should help in debugging your case.

My SHA1 ID: afb7394

I'm not sure what do you mean under CONFIG_DEBUG? I have enabled CONFIG_SOC_LOG_LEVEL_DBG=y and CONFIG_PM_LOG_LEVEL_DBG=y, so I am able to see the dbg logs of the power.c files.. Or did you mean something else?

[erwango]

I'm not sure what do you mean under CONFIG_DEBUG? I have enabled CONFIG_SOC_LOG_LEVEL_DBG=y and CONFIG_PM_LOG_LEVEL_DBG=y, so I am able to see the dbg logs of the power.c files.. Or did you mean something else?

By its implementation in L4 power.c file, CONFIG_DEBUG will have the effect of enabling debug module in STOP mode.
So for debug purpose, it may help in investigating faulty behavior in your binary.

[filip-primozic]

@erwango, let me jump in into your discussion. I have taken over the task from @ivonalo, and would like to ask you some further question regarding the CONFIG_PM stuff.

As @ivonalo mentioned, our goal is to be able to put stm32l4 MCU into low power modes (stop0, stop1, stop2), and to be able to call the function pm_power_state_set, CONFIG_PM must be defined in prj.conf file. This is where the problems arise: all things remaining the same in prj.conf file, when I change CONFIG_PM=n to CONFIG_PM=y in prj.conf file, MCU enters into some state (don't know which one, don't know how, i.e. what is the order of code execution) out of which I am unable to recover it, and absolutely no LOGs are being printed.

I would appreciate very much you assistance as to what to change and how to debug the problem. I tried the following so far:

1. In idle.c file, there is a void idle(void *unused1, void *unused2, void *unused3) definition. To prevent it from sending MCU to low power states, I replaced the original code with the following (didn't help):

 while (true) {
     k_busy_wait(100);  
     k_yield();
}

2. In subsys/pm/power.c file, there is a function pm_system_suspend, I tried commenting out the code which is wrapped into #if CONFIG_PM_DEVICE, to prevent it from being executed when CONFIG_PM=y is set. Didn't help.

In both cases, I tried with both CONFIG_PM=n to CONFIG_PM=y. In case when CONFIG_PM=n is set, everything works ok (system boots normally), and as soon as CONFIG_PM=y is set, nothing happens, its like everything is frozen.

I also looked at the power management policy, but I don't think this is an issues at the moment. This is the code in policy_residency.c file:

static const struct pm_state_info pm_min_residency[] =
	PM_STATE_INFO_DT_ITEMS_LIST(DT_NODELABEL(cpu0));

struct pm_state_info pm_policy_next_state(int32_t ticks)
{
	int i;

	for (i = ARRAY_SIZE(pm_min_residency) - 1; i >= 0; i--) {
		uint32_t min_residency, exit_latency;

		if (!pm_constraint_get(pm_min_residency[i].state)) {
			continue;
		}

		min_residency = k_us_to_ticks_ceil32(
			    pm_min_residency[i].min_residency_us);
		exit_latency = k_us_to_ticks_ceil32(
			    pm_min_residency[i].exit_latency_us);
		__ASSERT(min_residency > exit_latency,
				"min_residency_us < exit_latency_us");

		if ((ticks == K_TICKS_FOREVER) ||
		    (ticks >= (min_residency + exit_latency))) {
			LOG_DBG("Selected power state %d "
				"(ticks: %d, min_residency: %u)",
				pm_min_residency[i].state, ticks,
				pm_min_residency[i].min_residency_us);
			return pm_min_residency[i];
		}
	}

	LOG_DBG("No suitable power state found!");
	return (struct pm_state_info){PM_STATE_ACTIVE, 0, 0};
}

Since I don't have @cpu0 defined in device tree, this should just skip the for loop and return PM_STATE_ACTIVE. But I believe this is not even reached, as I was putting logs in this function and they were never printed.

As they are potentially many things to explore, as the very first step, I would like to have CONFIG_PM=y being set in prj.conf file, and simple main.c code as following:

int main{
 printk("Inside of main\n");
 k_msleep(1000);
}

Currently, I can't even get that to work, which means the code doesn't even reach int main, rather it is stuck somewehere in the kernel/initialization.

Your help is greatly appreciated.

I am on the latest official release (v2.7.0-rc1).

[erwango]

I didn't mean that CONFIG_DEBUG=y would solve your issue.
Though, it should allow you to debug (using west debug for instance) and see where the program is blocked, either is it in an endless loop, a deep sleep state ....
This will give a piece of advice on the problem you're facing

[filip-primozic]

Ah, I see. I will do so and get back to you with the findings. Thanks.

[filip-primozic]

@erwango, I am using VS code, and have cortex-debug extension. From using it, when I enable CONFIG_PM, system is stuck in the following function:

The call stack is as follows:

Does this tell you anything? To me, this call stack says it is stuck due to the low power timer initialization. As for the moment, I do not have lptimer defined in device tree. Should I? I will keep exploring this, but I wanted to share what I found out with you first, since you know a lot more about these stuff than I do, and with that knowledge, maybe you will know right off the bat what needs to be changed/defined.

[filip-primozic]

Some further info. So, LSE is external oscillator. Part of the sys_clock_driver_init is the following code snippet:

	/* enable LSE clock */
	LL_RCC_LSE_DisableBypass();
	LL_RCC_LSE_Enable();
	while (!LL_RCC_LSE_IsReady()) {
		/* Wait for LSE ready */
	}

And line LL_RCC_LSE_Enable(); clearly enables that oscillator:

If we do not have the external oscillator connected to that pin on the MCU (if I didn't mention, we are using STM32L462VE), does that mean this bit will never be set?

[filip-primozic]

And one more question please. Also part of the above function is the following piece of code:

#if defined(LL_APB1_GRP1_PERIPH_PWR)
	/* Enable the power interface clock */
	LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_PWR);
#endif /* LL_APB1_GRP1_PERIPH_PWR */

	/* enable backup domain */
	LL_PWR_EnableBkUpAccess();

	/* enable LSE clock */
	LL_RCC_LSE_DisableBypass();
	LL_RCC_LSE_Enable();
	while (!LL_RCC_LSE_IsReady()) {
		/* Wait for LSE ready */
	}

I couldn't find anywhere, and don't know where is LL_APB1_GRP1_PERIPH_PWR defined? Do you know maybe? Is it defined explicitly or implicitly, is it defined through prj.conf or somethere else? Thanks.

[erwango]

As for the moment, I do not have lptimer defined in device tree. Should I?

Yes, you should. Anyway, at least it seems to be enabled.
And for sure, to use LSE, you need to have an external oscillator available.
If this is not the case, then, you should select LSI. This can be done by adding the following in your board's Kconfig.defconfig file:

choice STM32_LPTIM_CLOCK
	default STM32_LPTIM_CLOCK_LSI
	depends on STM32_LPTIM_TIMER
endchoice

Also, from what I understand you're trying to implement your worn version of power management on unknown hardware (to me at least).
It will really be difficult to provide you support in these conditions.
So I'd suggest to get back to a known state, and first try to reproduce known working sample on first one of the PM enabled hardware.
Then try to get the same working on your hardware.
And finally try to make your own adaptation of PM.
First things first ;-)

LL_APB1_GRP1_PERIPH_PWR is defined in hal_stm32 module.

[filip-primozic]

choice STM32_LPTIM_CLOCK
	default STM32_LPTIM_CLOCK_LSI
	depends on STM32_LPTIM_TIMER
endchoice

This part did the trick. Now the system boots in the same way as when CONFIG_PM=n. That is the key change, now we can continue working on pm_power_state_set functionality, and PM policies.

As for the hardware, yes, the hardware is custom board, but we do not want to use custom version of power management. I think Zephyr codebase contains all what we need for the MCU low power functionality.

Anyway, if I get stuck again in this low power mode, I might get back to this thread, otherwise thanks a lot for your help and for the push in solving the issue.