cancel
Showing results for 
Search instead for 
Did you mean: 

HW_Timerserver Hangs on STM32WB w/ BLE

HCohe.1
Associate III

Any program that I generate using STM32CubeIDE for the STM32WB with BLE enabled hangs until I comment out the following line. What needs to change in the initialization sequence?

  /**

   * We should never end up in this case

   * However, if due to any bug in the timer server this is the case, the mistake may not impact the user.

   * We could just clean the interrupt flag and get out from this unexpected interrupt

   */

  while(__HAL_RTC_WAKEUPTIMER_GET_FLAG(phrtc, RTC_FLAG_WUTWF) == RESET);

1 ACCEPTED SOLUTION

Accepted Solutions
Remy ISSALYS
ST Employee

Hello,

Indeed, if the Hardware Time Server (HW_TS) is not initialized (via MX_APPE_Init()) quickly enough after the RTC initialization (via MX_RTC_Init()), the code might get stuck in an infinite loop in the HW_TS_RTC_Wakeup_Handler() function.

To avoid this problem there is 2 solutions:

  • Solution 1:

Remove the following code in MX_RTC_Init function in main.c file:

 /** Enable the WakeUp

 */

 if (HAL_RTCEx_SetWakeUpTimer(&hrtc, 0, RTC_WAKEUPCLOCK_RTCCLK_DIV16) != HAL_OK)

 {

  Error_Handler();

 }

You will have to remove it after every new code generation with STM32CubeMX.

  • Solution 2:

To avoid to do modification every new code generation with STM32CubeMX.

> Change Wake Up Counter value:

If you used CubeMX, in RTC configuration change default value by 0xFFFF:

0693W00000KaH2QQAV.pngOr in MX_RTC_Init function in main.c, change the second parameter of this function by replace 0 value:

HAL_RTCEx_SetWakeUpTimer(&hrtc, 0, RTC_WAKEUPCLOCK_RTCCLK_DIV16)

by 0xFFFF:

HAL_RTCEx_SetWakeUpTimer(&hrtc, 0xFFFF, RTC_WAKEUPCLOCK_RTCCLK_DIV16)

> Add the following line in RTC_Init 2 User Code Section (in MX_RTC_Init function in main.c) :

 __HAL_RTC_WAKEUPTIMER_DISABLE(&hrtc);

Best Regards,

View solution in original post

10 REPLIES 10
Remy ISSALYS
ST Employee

Hello,

Indeed, if the Hardware Time Server (HW_TS) is not initialized (via MX_APPE_Init()) quickly enough after the RTC initialization (via MX_RTC_Init()), the code might get stuck in an infinite loop in the HW_TS_RTC_Wakeup_Handler() function.

To avoid this problem there is 2 solutions:

  • Solution 1:

Remove the following code in MX_RTC_Init function in main.c file:

 /** Enable the WakeUp

 */

 if (HAL_RTCEx_SetWakeUpTimer(&hrtc, 0, RTC_WAKEUPCLOCK_RTCCLK_DIV16) != HAL_OK)

 {

  Error_Handler();

 }

You will have to remove it after every new code generation with STM32CubeMX.

  • Solution 2:

To avoid to do modification every new code generation with STM32CubeMX.

> Change Wake Up Counter value:

If you used CubeMX, in RTC configuration change default value by 0xFFFF:

0693W00000KaH2QQAV.pngOr in MX_RTC_Init function in main.c, change the second parameter of this function by replace 0 value:

HAL_RTCEx_SetWakeUpTimer(&hrtc, 0, RTC_WAKEUPCLOCK_RTCCLK_DIV16)

by 0xFFFF:

HAL_RTCEx_SetWakeUpTimer(&hrtc, 0xFFFF, RTC_WAKEUPCLOCK_RTCCLK_DIV16)

> Add the following line in RTC_Init 2 User Code Section (in MX_RTC_Init function in main.c) :

 __HAL_RTC_WAKEUPTIMER_DISABLE(&hrtc);

Best Regards,

HCohe.1
Associate III

How will the Hardware Timer Server continue to work after I apply either of these two solutions? The first solution removes the function that enables the wake-up timer. The second one disables it.

Remy ISSALYS
ST Employee

Hello,

Wake Up Timer is started inside Hardware Timer Server initialization see HW_TS_Init() function.

Regards

I suggest ST to add link to this forum thread inside code's comment

 * Wait for the flag to be back to 0 when the wakeup timer is enabled

    */

   while(__HAL_RTC_WAKEUPTIMER_GET_FLAG(phrtc, RTC_FLAG_WUTWF) == SET);

like

 * Wait for the flag to be back to 0 when the wakeup timer is enabled

    See also https://community.st.com/s/question/0D53W00001K2koYSAR/hwtimerserver-hangs-on-stm32wb-w-ble?t=1645623930307 or https://github.com/STMicroelectronics/STM32CubeWB/issues/52 */

   while(__HAL_RTC_WAKEUPTIMER_GET_FLAG(phrtc, RTC_FLAG_WUTWF) == SET);

Remy ISSALYS
ST Employee

Hello,

Thanks for your proposal, we study internally the best way to correct this problem.

Regards

EKoss.1
Associate II

Hello,

I don't know if this issue is already solved in the later versions of the FW. I have something that seems related to this (not sure if it is). I have setup a project using the Custom P2P server settings. When I add the HW_time server to it the code hangs. I have one project in which the code gets into the infinite loop (when debuggin) and I have setup a project with minimalistic use of these functions which gets stuck in the HardFaultHandler (after subscriping to the BLE notification characteristic (which starts the HW_TS).

The strange thing about this is that I had the minimalistic project running without issues until I've re-generated the CubeMX project (without making any changes).

I think I should open a new issue for this but wanted to share this here as well.

I have made a github repo which can be viewed what I've done:

https://github.com/E-Emiel/TimeServerV1

Regards

dungeonlords789
Senior III

@Remy ISSALYS​ any news?

HCohe.1
Associate III

Yes @Remy ISSALYS​ , I resolved the problem using just the second part of Solution 2 above - to edit MX_RTC_Init() and disable the wakeup timer in the user code section.

  /* USER CODE BEGIN RTC_Init 2 */
  HAL_RTCEx_DeactivateWakeUpTimer(&hrtc);	// Now disable it to prevent interrupts before HW_Timerserver is ready for them.
  /* USER CODE END RTC_Init 2 */

We can close this issue.

Ugilten
Associate III

I just spent the last two days chasing this daemon.

I found the MX_RTC_Init() function was followed by 5 other init functions (generated by CubeMX) before the MX_APPE_Init() function.

This would cause too much time to pass between the two function calls and causes a hard fault because the phrtc pointer would be empty in HW_TS_RTC_Wakeup_Handler().

I decided to tell CubeMX to not generate function calls for these two modules. This allows me to call them inside the USER CODE BEGIN 2 area and keep them close together.

I don't know if there are any disadvantages to this approach, but it seems to work fine.