The recovery time from deep sleep of STM32U5 is too slow

[wdx04]

Last year, when I was adding support for NUCLEO-U545RE-Q and NUCLEO-U5A5ZJ-Q boards, there are 3 failed tests (#273). The reason for the failure is that it takes too long to recover from deep sleep mode.

Here is a simplified version of a Greentea LowPowerTimeout test. When running the test on a STM32U5 target, it will print "error try_acquire #2" in the console. To pass the test I have to increase the TEST_LATENCY from 2ms to 10ms.

#include "mbed.h"
#include <atomic>
EventQueue queue;

const chrono::milliseconds TEST_DELAY = 10ms;
const chrono::milliseconds TEST_LATENCY = 2ms;
uint32_t start_time, end_time;
std:: atomic_bool called = false;

void sem_callback(Semaphore *sem)
{
    sem->release();
    called = true;
}

template<typename T>
void test_single_call(void)
{
    Semaphore sem(0, 1);
    T timeout;

    start_time = osKernelGetTickCount();

    timeout.attach(mbed::callback(sem_callback, &sem), TEST_DELAY);

    bool acquired = sem.try_acquire();
    if(acquired) printf("error try_acquire #1\n");

    acquired = sem.try_acquire_for(TEST_DELAY + TEST_LATENCY);
    end_time = osKernelGetTickCount();
    if(!acquired) printf("error try_acquire #2\n");

    acquired = sem.try_acquire_for(TEST_DELAY + TEST_LATENCY);
    if(acquired) printf("error try_acquire #3\n");

    timeout.detach();

    if(called)
    {
        printf("Interval: %lu ms.\n", end_time - start_time);
    }
    else
    {
        printf("sem_callback not called!\n");
    }
}

int main()
{
    printf("Application started!\n");
    test_single_call<LowPowerTimeout>();
    queue.dispatch_forever();
    return 0;
}

But if I comment out the calls to ForceOscOutofDeepSleep() and ForcePeriphOutofDeepSleep() here, the recovery time can be significantly reduced. After this modification, the above test can be passed with TEST_LATENCY = 2ms, and the previously failed 3 Greentea tests are all passable.

mbed-os/targets/TARGET_STM/sleep.c

Lines 265 to 273 in 9ce9f38

	/* We've seen unstable PLL CLK configuration when DEEP SLEEP exits just few µs after being entered
	* So we need to force clock init out of Deep Sleep.
	* This init has been split into 2 separate functions so that the involved structures are not allocated on the stack in parallel.
	* This will reduce the maximum stack usage in case on non-optimized / debug compilers settings.
	*/
	ForceOscOutofDeepSleep();
	ForcePeriphOutofDeepSleep();
	SetSysClock();
	#endif

The question now is whether it is safe to comment out these two function calls, or if there is a better way to solve this problem.

[multiplemonomials]

Hmm.. If you set

"target.deep-sleep-latency": 10

in mbed_app.json, does that allow your test to pass? Theoretically that should tell Mbed that deep sleep takes a long time to exit, so it should stop it from using deep sleep if it knows that the next wakeup is in <=10ms.

Also, maybe check the STM32U5 errata sheet for anything like what that comment is talking about? I'd love to be able to find some more background on what is going on there.

[wdx04]

Yes, setting this will allow the test to pass.

But I think I have found the cause of this problem. STM32L4, STM32L5 and STM32U5 all have a MSI RC oscillator. The usable MSI frequencies are defined as RCC_MSIRANGE_x in stm32xxx_hal_rcc.h for each series.

In the ForceOscOutofDeepSleep function, RCC_MSIRANGE_11 is selected when it's available.

mbed-os/targets/TARGET_STM/sleep.c

Lines 97 to 107 in 9ce9f38

	#if defined (RCC_SYSCLKSOURCE_MSI) /* STM32Lx */
	RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_MSI;
	RCC_OscInitStruct.MSIState = RCC_MSI_ON;
	RCC_OscInitStruct.MSICalibrationValue = RCC_MSICALIBRATION_DEFAULT;
	#if defined RCC_MSIRANGE_11
	RCC_OscInitStruct.MSIClockRange = RCC_MSIRANGE_11; // Highest freq, 48MHz range
	#else
	RCC_OscInitStruct.MSIClockRange = RCC_MSIRANGE_6; // 4MHz range
	#endif
	RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
	#else /* defined RCC_SYSCLKSOURCE_MSI */

Unfortunately, RCC_MSIRANGE_11 has different a meaning in STM32U5 than in STM32L4 and STM32L5. In STM32L4 and STM32L5, RCC_MSIRANGE_11 stands for 48MHz which is the highest MSI frequency. But in STM32U5, RCC_MSIRANGE_11 means just 768KHz, and its highest frequency (also 48MHz) is represented by RCC_MSIRANGE_0. If I select RCC_MSIRANGE_0 for STM32U5, the test can be passed without the deep-sleep-latency setting.

mbed-os/targets/TARGET_STM/TARGET_STM32L4/STM32Cube_FW/STM32L4xx_HAL_Driver/stm32l4xx_hal_rcc.h

Lines 405 to 416 in 9ce9f38

	#define RCC_MSIRANGE_0 RCC_CR_MSIRANGE_0 /*!< MSI = 100 KHz */
	#define RCC_MSIRANGE_1 RCC_CR_MSIRANGE_1 /*!< MSI = 200 KHz */
	#define RCC_MSIRANGE_2 RCC_CR_MSIRANGE_2 /*!< MSI = 400 KHz */
	#define RCC_MSIRANGE_3 RCC_CR_MSIRANGE_3 /*!< MSI = 800 KHz */
	#define RCC_MSIRANGE_4 RCC_CR_MSIRANGE_4 /*!< MSI = 1 MHz */
	#define RCC_MSIRANGE_5 RCC_CR_MSIRANGE_5 /*!< MSI = 2 MHz */
	#define RCC_MSIRANGE_6 RCC_CR_MSIRANGE_6 /*!< MSI = 4 MHz */
	#define RCC_MSIRANGE_7 RCC_CR_MSIRANGE_7 /*!< MSI = 8 MHz */
	#define RCC_MSIRANGE_8 RCC_CR_MSIRANGE_8 /*!< MSI = 16 MHz */
	#define RCC_MSIRANGE_9 RCC_CR_MSIRANGE_9 /*!< MSI = 24 MHz */
	#define RCC_MSIRANGE_10 RCC_CR_MSIRANGE_10 /*!< MSI = 32 MHz */
	#define RCC_MSIRANGE_11 RCC_CR_MSIRANGE_11 /*!< MSI = 48 MHz */

mbed-os/targets/TARGET_STM/TARGET_STM32U5/STM32Cube_FW/STM32U5xx_HAL_Driver/stm32u5xx_hal_rcc.h

Lines 379 to 394 in 9ce9f38

	#define RCC_MSIRANGE_0 0x00000000U /*!< MSI = 48 MHz */
	#define RCC_MSIRANGE_1 RCC_ICSCR1_MSISRANGE_0 /*!< MSI = 24 MHz */
	#define RCC_MSIRANGE_2 RCC_ICSCR1_MSISRANGE_1 /*!< MSI = 16 MHz */
	#define RCC_MSIRANGE_3 (RCC_ICSCR1_MSISRANGE_0 | RCC_ICSCR1_MSISRANGE_1) /*!< MSI = 12 MHz */
	#define RCC_MSIRANGE_4 RCC_ICSCR1_MSISRANGE_2 /*!< MSI = 4 MHz */
	#define RCC_MSIRANGE_5 (RCC_ICSCR1_MSISRANGE_0 | RCC_ICSCR1_MSISRANGE_2) /*!< MSI = 2 MHz */
	#define RCC_MSIRANGE_6 (RCC_ICSCR1_MSISRANGE_1 | RCC_ICSCR1_MSISRANGE_2) /*!< MSI = 1.33 MHz */
	#define RCC_MSIRANGE_7 (RCC_ICSCR1_MSISRANGE_0 | RCC_ICSCR1_MSISRANGE_1 | RCC_ICSCR1_MSISRANGE_2) /*!< MSI = 1 MHz */
	#define RCC_MSIRANGE_8 RCC_ICSCR1_MSISRANGE_3 /*!< MSI = 3.072 MHz */
	#define RCC_MSIRANGE_9 (RCC_ICSCR1_MSISRANGE_0 | RCC_ICSCR1_MSISRANGE_3) /*!< MSI = 1.536 MHz */
	#define RCC_MSIRANGE_10 (RCC_ICSCR1_MSISRANGE_1 | RCC_ICSCR1_MSISRANGE_3) /*!< MSI = 1.024 MHz */
	#define RCC_MSIRANGE_11 (RCC_ICSCR1_MSISRANGE_0 | RCC_ICSCR1_MSISRANGE_1 | RCC_ICSCR1_MSISRANGE_3) /*!< MSI = 768 KHz */
	#define RCC_MSIRANGE_12 (RCC_ICSCR1_MSISRANGE_2 | RCC_ICSCR1_MSISRANGE_3) /*!< MSI = 400 KHz */
	#define RCC_MSIRANGE_13 (RCC_ICSCR1_MSISRANGE_0 | RCC_ICSCR1_MSISRANGE_2 | RCC_ICSCR1_MSISRANGE_3) /*!< MSI = 200 KHz */
	#define RCC_MSIRANGE_14 (RCC_ICSCR1_MSISRANGE_1 | RCC_ICSCR1_MSISRANGE_2 | RCC_ICSCR1_MSISRANGE_3) /*!< MSI = 133 KHz */
	#define RCC_MSIRANGE_15 (RCC_ICSCR1_MSISRANGE_0 | RCC_ICSCR1_MSISRANGE_1| RCC_ICSCR1_MSISRANGE_2 |\

[multiplemonomials]

Wow, awesome find! Submit a PR plz!

[JohnK1987]

#489