Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wolsty7 opened this issue Feb 3, 2023 · 7 comments
Open

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

wolsty7 opened this issue Feb 3, 2023 · 7 comments
Assignees
Labels
bug Something isn't working internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system lorawan LoraWAN-related issue or pull-request. mw Middleware-related issue or pull-request.

Comments

@wolsty7
Copy link

wolsty7 commented Feb 3, 2023

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
Copy link
Author

wolsty7 commented Feb 3, 2023

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

@RJMSTM RJMSTM added the lorawan LoraWAN-related issue or pull-request. label Mar 30, 2023
@RJMSTM
Copy link
Contributor

RJMSTM commented Mar 30, 2023

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

@ASELSTM
Copy link
Contributor

ASELSTM commented May 17, 2023

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 ASELSTM added the needs clarification Needs clarification or input from user label May 17, 2023
@wolsty7
Copy link
Author

wolsty7 commented May 18, 2023

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

@ASELSTM
Copy link
Contributor

ASELSTM commented Jul 13, 2023

ST Internal Reference: 157211

@ASELSTM ASELSTM added the internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system label Jul 13, 2023
@ASELSTM
Copy link
Contributor

ASELSTM commented Jul 13, 2023

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,

@wolsty7
Copy link
Author

wolsty7 commented Sep 13, 2023

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

@ALABSTM ALABSTM added bug Something isn't working mw Middleware-related issue or pull-request. and removed needs clarification Needs clarification or input from user labels Aug 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system lorawan LoraWAN-related issue or pull-request. mw Middleware-related issue or pull-request.
Projects
None yet
Development

No branches or pull requests

4 participants