STM32F732 Wakeup Latency

[Trevor Hsu]

Hi

Our custom board had some issues for STOP mode.

Firstly, please see the following STOP mode code:(using GPIO EXTI to wake up MCU)

HAL_PWREx_EnableFlashPowerDown();
HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);
HAL_PWREx_DisableFlashPowerDown();
SystemClock_Config();
// GPIO Set High

We did an experiment to measure wake-up latency. Using GPIO to generate pulses and measure the pulse width as wakeup latency time. As you can see in the image below, "Resume" is line 5 of the above code.

We have 10 custom boards. 7 of them look normal and the remaining 3 look abnormal.

Each board is measured about 1000 times and the results are converted into a graph.

The following graph is normal case, the horizontal axis represents the number of tests, the vertical axis represents time (100 = 1mS). Regarding the normal case, we could focus on two things, the first one is baseline(around 1.2mS) and the second one is the wakeup time stabilization.

The following graph is abnormal case, you could observe that the baseline is around 1.4mS and the wakeup time is not stable.

We checked the datasheet, regarding the wakeup latency, it requires additional start up delay time:

1. HSI RC startup time
2. Regulator wakeup time from LP mode
3. Flash wakeup time from power-down mode
4. Re-configure the system clock

The above additional startup delay time seems to be related to MCU internal resources. We don't have any idea about this issue, do you have any suggestion for us?

Thanks.

BR

Trevor

[Danish1]

I don't know the F732, so for reference I checked the data-sheet of F767. That says wakeup from stop mode is typically 104 - 113 us; max 107 - 120 us (if we ignore the case where LP regulator is on, which is only circa 20 us).

So the first question is how come you're measuring 10 times longer.

And my suspicion is drawn to your greyed out line SystemClock_Config() - what precisely does that do?

Do wade through the source-code. I find the "bimodal" graph suspicious - it either seems to be 130 or 220 counts, as if the code sets something going, then only checks if it is actually working periodically.

If you have HSE or LSE oscillators, does that start those oscillators and wait for them to stabilise?

HSE has a typical startup time of 2 ms "and it can vary significantly with the crystal manufacturer".

(LSE has a typical startup time of 2 s, so that's unlikely).

Is it possible that those "abnormal" boards have crystals that take longer to start?

[Trevor Hsu]

Hi Danish,

Thanks for your reply,

After the MCU exits STOP mode, it uses HSI as clock, so we need to re-configure our system clock. We do this on SystemClock_Config().

We agree with you that it seems some additional startup delay time in this function.

Regarding the "bimodal" graph suspicious, we use the same code for 10 custom boards and only 3 have this problem. We don't know anything about it.

You could see the source-code below:

/**
  * @brief System Clock Configuration
  * @retval None
  */
void SystemClock_Config(void)
{
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
  RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};
 
  /** Configure the main internal regulator output voltage
  */
  __HAL_RCC_PWR_CLK_ENABLE();
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);
  /** Initializes the RCC Oscillators according to the specified parameters
  * in the RCC_OscInitTypeDef structure.
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE|RCC_OSCILLATORTYPE_LSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.LSEState = RCC_LSE_BYPASS;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 25;
  RCC_OscInitStruct.PLL.PLLN = 384;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV8;
  RCC_OscInitStruct.PLL.PLLQ = 8;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
  /** Activate the Over-Drive mode
  */
  if (HAL_PWREx_EnableOverDrive() != HAL_OK)
  {
    Error_Handler();
  }
  /** Initializes the CPU, AHB and APB buses clocks
  */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
 
  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)
  {
    Error_Handler();
  }
  PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_RTC|RCC_PERIPHCLK_USART1
                              |RCC_PERIPHCLK_USART2|RCC_PERIPHCLK_LPTIM1
                              |RCC_PERIPHCLK_SDMMC1|RCC_PERIPHCLK_CLK48;
  PeriphClkInitStruct.PLLSAI.PLLSAIN = 192;
  PeriphClkInitStruct.PLLSAI.PLLSAIQ = 2;
  PeriphClkInitStruct.PLLSAI.PLLSAIP = RCC_PLLSAIP_DIV4;
  PeriphClkInitStruct.PLLSAIDivQ = 1;
  PeriphClkInitStruct.RTCClockSelection = RCC_RTCCLKSOURCE_LSE;
  PeriphClkInitStruct.Usart1ClockSelection = RCC_USART1CLKSOURCE_PCLK2;
  PeriphClkInitStruct.Usart2ClockSelection = RCC_USART2CLKSOURCE_PCLK1;
  PeriphClkInitStruct.Lptim1ClockSelection = RCC_LPTIM1CLKSOURCE_LSE;
  PeriphClkInitStruct.Clk48ClockSelection = RCC_CLK48SOURCE_PLLSAIP;
  PeriphClkInitStruct.Sdmmc1ClockSelection = RCC_SDMMC1CLKSOURCE_CLK48;
  if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
}

Thanks.

BR

Trevor

[Danish1]

Please try re-ordering the code so you drive the GPIO before configuring the clock. That would show if the delay relates to the startup of clocks or the execution of the Arm core.

[Trevor Hsu]

We need some time to setup the measure environment to check the latency.

Is it possible that those "abnormal" boards have crystals that take longer to start?

>>>>>>>>is there any methods to check this?

Thanks

BR

Trevor