STM32CubeWL icon indicating copy to clipboard operation
STM32CubeWL copied to clipboard

HAL_GetTick() running 1.024x fast (v1.3.0)

Open wolsty7 opened this issue 2 years ago • 7 comments

Describe the set-up

Board: MB1389D (Nucleo-WL55JC1)

Describe the bug

HAL_GetTick() and by extension TIMER_IF_GetTimerValue() run at exactly 1.024x speed (2.4% inaccurate) compared SysTimeGet()

How to reproduce the bug

  1. locate the LoRaWAN_End_Node project (or likely any other)
  2. add the following lines below to lora_app.c at the start of SendTxData():
APP_LOG(TS_ON, VLEVEL_ALWAYS, "HAL_GetTick()=%u\r\n",HAL_GetTick());
SysTime_t curtime = SysTimeGet();
APP_LOG(TS_ON, VLEVEL_ALWAYS, "SysTimeGet()=%u\r\n",curtime.Seconds*1000+curtime.SubSeconds);
  1. Build and program
  2. Open a serial terminal emulator like HTERM
  3. compute ( <HAL_GetTick() t1> - <HAL_GetTick() tn> ) / ( <SysTimeGet() t1> - <SysTimeGet() tn> ) and you will get 1.024
  4. Verify SysTimeGet() is accurate by using Hterms timediff feature after selecting all the serial output between <SysTimeGet() t1> and <SysTimeGet() tn> and comparing to (<SysTimeGet() t1> - <SysTimeGet() tn>) (off by -62ppm in my case)

fix In uint32_t HAL_GetTick(void) in sys_app.c replace TIMER_IF_GetTimerValue() with SysTimeGet(). Note: my testing SysTimeGet() takes 4-5us to compute, not a big deal, but maybe there is a more efficient way to do this

uint32_t HAL_GetTick(void)
{
  uint32_t ret = 0;
  /* TIMER_IF can be based on other counter the SysTick e.g. RTC */
  /* USER CODE BEGIN HAL_GetTick_1 */

  /* USER CODE END HAL_GetTick_1 */
//  if (SYS_TimerInitialisedFlag == 0)
//  {
//    /* TIMER_IF_GetTimerValue should be used only once UTIL_TIMER_Init() is initialized */
//    /* If HAL_Delay or a TIMEOUT countdown is necessary during initialization phase */
//    /* please use temporarily another timebase source (SysTick or TIMx), which implies also */
//    /* to rework the above function HAL_InitTick() and to call HAL_IncTick() on the timebase IRQ */
//    /* Note: when TIMER_IF is based on RTC, stm32wlxx_hal_rtc.c calls this function before TimeServer is functional */
//    /* RTC TIMEOUT will not expire, i.e. if RTC has an hw problem it will keep looping in the RTC_Init function */
//    /* USER CODE BEGIN HAL_GetTick_EarlyCall */
//
//    /* USER CODE END HAL_GetTick_EarlyCall */
//  }
//  else
//  {
//    ret = TIMER_IF_GetTimerValue();
//  }
  /* USER CODE BEGIN HAL_GetTick_2 */
  SysTime_t curtime = SysTimeGet(); //TIMER_IF_GetTimerValue() is 1.024x fast
  ret=curtime.Seconds*1000+curtime.SubSeconds;
  /* USER CODE END HAL_GetTick_2 */
  return ret;
}

wolsty7 avatar Feb 03 '23 01:02 wolsty7

Just tested v1.0.0 and exact same issue. This issue also affects I-CUBE-LRWAN based firmware

wolsty7 avatar Feb 03 '23 01:02 wolsty7

Hello @wolsty7,

Thank you for this report. We will get back to you as soon as we analyze it further. This may take some time. Thank you for your comprehension.

With regards, Rania

RJMSTM avatar Mar 30 '23 13:03 RJMSTM

Hi @wolsty7,

Would you please try to check with the latest version of the STM32CubeWL and check if you are still having the same issue.

With regards,

ASELSTM avatar May 17 '23 07:05 ASELSTM

Hi @wolsty7,

Would you please try to check with the latest version of the STM32CubeWL and check if you are still having the same issue.

With regards,

Hello, This issue affects the latest version 1.3.0. I also tested 1.0.0 so I presume it affects all versions

wolsty7 avatar May 18 '23 00:05 wolsty7

ST Internal Reference: 157211

ASELSTM avatar Jul 13 '23 10:07 ASELSTM

Hi @wolsty7,

This issue has been logged into an internal bug tracker at the attention of our development teams. I'll keep you informed. Thank you again for your report.

With regards,

ASELSTM avatar Jul 13 '23 10:07 ASELSTM

Hello @ASELSTM it has been 7 months since this issue was posted (and many others), is STM working on this?

wolsty7 avatar Sep 13 '23 06:09 wolsty7