Wrong tick-timing with STOP0 mode

[govindadas]

Hi!
I'm using an stm32G474 processor with STMCubeIDE 1.16.0 and FreeRTOS (CMSIS_V2) with LPTIM-Tick.
The TicklessIdle mode works as expected when I use "HAL_PWR_EnterSLEEPMode(PWR_MAINREGULATOR_ON, PWR_SLEEPENTRY_WFI);" with a 1ms tick-timing.
But when I switch from HAL_PWR_EnterSLEEPMode to "HAL_PWREx_EnterSTOP0Mode(PWR_STOPENTRY_WFI);" the tick-timing changes somehow to 3ms per tick.
The timing for "osDelay(pdMS_TO_TICKS(100));" is not influenced by this, it will sleep for 100ms. But when I use "HAL_Delay(pdMS_TO_TICKS(100));" the call will take 300ms (not sleeping).

I already tried to change configLPTIM_ENABLE_PRECISION and configTICK_USES_LSI.
Any idea what is causing this behavior?

[Olstyle]

So the OS is working completely as expected but the HAL delay (which to my knowledge should not be used with FreeRTOS defines and best not combined with an OS anyway) breaks?

[govindadas]

Thank you for the response. Yes, when you put it like that, the OS seems to be working correctly. I did not change any code except the call to SLEEP/STOP and assumed the tick timing would remain the same. Do you have any suggestions for a test to ensure that everything works and that I don’t run into problems later?

[Olstyle]

Sorry, I personally don't use the HAL (because I don't like how a lot of interfaces are way too focused on the underlying registers and how intervoven the different parts of it are) , so I have no idea in what instances HAL_Delay should work or not work and what kind of parameter format it expects.
I am just pointing out that it has no idea about FreeRTOS and if you use preemption it might even be interrupted by it.

If you want ms delays while the OS is active, use the vTaskDelay/osDelay, not the HAL.

[govindadas]

OK. I'll try to avoid HAL calls in my project. But it’s not specifically about HAL_Delay(), I just found the discrepancy this way. I just want to make sure that I don’t introduce other side effects by using LPTIM-Tick in my project.

[Olstyle]

You need to make sure that actually all your Peripheral are ready for stop, otherwise the stop mode will break thinks. This is what ulp.c is for in the examples.
I have my own implementation of it which is a bit different, but in general you need to implement configPRE_SLEEP_PROCESSING in a sensible, peripheral aware, way for your system to work with stop mode.

[govindadas]

Thank you for the explanation. I’ll make sure to check the peripherals before entering STOP mode.

[jefftenney]

There are two different system ticks. The FreeRTOS tick and the HAL tick. They are independent and concurrent.

If you are using lptimTick.c, the FreeRTOS tick is provided by an LPTIM timer. If you are not using lptimTick.c, the FreeRTOS tick is provided by the SysTick timer. The FreeRTOS tick rate is set by configTICK_RATE_HZ.

The HAL tick is provided by a timer of your choice. In CubeMX, see Pinout & Configuration -> System Core -> SYS -> Timebase Source. The HAL configures the selected timer to provide a 1000 Hz tick rate.

When you call HAL_Delay(), you are delaying based on the HAL tick. These delays are busy-wait delays -- not OS friendly and not power friendly. When you call osDelay() or vTaskDelay(), you are delaying based on the FreeRTOS tick. These delays are OS friendly and allow low-power sleep and stop modes.

It appears the issue you are facing is the HAL tick changes its frequency after you use stop mode. That's not surprising. Waking from stop causes the system clock configuration to change. In the case of STM32G4, the HSI16 is selected. Your software is responsible to restore the desired clock configuration after waking from stop mode, and your software is (apparently) not doing that. See ulp.c for an example of restoring the clock configuration after stop mode. Note that file is specific to STM32L4.

[govindadas]

Thank you for the detailed explanation. You’re right; I did not reconfigure the HAL tick clock correctly.
Thank you, you have helped me a lot!