Why the value of HAL_TIM_ReadCapturedValue lower after LPM enabled

[Charles_Li]

  case PWR_KEY_Pin:
    if (HAL_GPIO_ReadPin(PWR_KEY_GPIO_Port, PWR_KEY_Pin) == GPIO_PIN_RESET)
    {
      HAL_TIM_IC_Start_IT(&htim16, TIM_CHANNEL_1);
      captureStart = HAL_TIM_ReadCapturedValue(&htim16, TIM_CHANNEL_1);
      UTIL_LPM_SetStopMode(1 << CFG_LPM_HTIM16, UTIL_LPM_DISABLE);
    }
    else
    {
      HAL_TIM_IC_Stop_IT(&htim16, TIM_CHANNEL_1);
      captureEnd = HAL_TIM_ReadCapturedValue(&htim16, TIM_CHANNEL_1);
      pressDuration = captureEnd - captureStart;
      UTIL_LPM_SetStopMode(1 << CFG_LPM_HTIM16, UTIL_LPM_ENABLE);

After LPM enabled

#define CFG_LPM_SUPPORTED    1

Long press the button for 5 secs, pressDuration will output ~2000 only.

The application was base on BLE_p2pServer and I'm sure PWR_EnterStopMode was not called by add "UTIL_LPM_SetStopMode(1 << CFG_LPM_HTIM16, UTIL_LPM_DISABLE);" 

[Imen.D]

Hello @Charles_Li ,

The behavior is mainly due to the latency APB to kernel clock, as said in the reference Manual sections "Register update" in LPTIM chapter:

"The LPTIM APB interface and the LPTIM kernel logic use different clocks, so there is some latency between the APB write and the moment when these values are available to the counter comparator"

Additionally, the issue might be related to the initialization phase of the LPTIM when using an external clock source:

"Since the signal injected on the LPTIM external Input1 is also used to clock the LPTIM kernel logic, there is some initial latency (after the LPTIM is enabled) before the counter is incremented".

[Charles_Li]

@Imen.D 

I'm using HTIM16, not LPTIM, and I found the issue might be related to the application entering/exiting OFF mode before the below line blocks the mode. It seems something is wrong after returning from OFF mode, so the count number is less than expected.

438 UTIL_LPM_SetOffMode(1 << CFG_LPM_APP_BLE, UTIL_LPM_DISABLE); in APP_BLE_Init()

Does OFFMODE = Shutdown mode?