STM32WB05TZ fails MX_RTC_Init()

[DG_NC]

I have a problem with the RTC initialization on the STM32WB05TZF6TR (BGA package).  When the board is powered on, the MX_RTC_Init() function calls HAL_RTC_Init(), which returns with HAL_ERROR status.

I traced the problem to the stm32wb0x_hal_rtc.c file, inside RTC_EnterInitMode().  It attempts to set the INIT bit, and then waits until the INITF bit changes state to confirm that Initialization Mode has been entered.

However, the INITF bit never changes state, so the while loop times out. 

On my custom board, I have confirmed that this error always occurs when power is applied to the board, but if I manually reset the MCU while power is already applied (by shorting RESET to GND momentarily), then the initialization will complete successfully.

To eliminate anything specific to my board, I generated a very simple test project (attached), which uses the default clock configuration with internal oscillators only, for both High Speed and Low Speed clocks.  The ONLY configuration in the attached project is enabling a single GPIO for debugging output and enabling the RTC peripheral.

Are other people seeing this same problem?

If you flash your board with the attached example project, PB5 will toggle if the RTC initializes successfully, and PB5 will just remain high forever if the RTC initialization times out.  On my board, PB5 is connected to an LED so I can see it blink or illuminate.

HAL_StatusTypeDef RTC_EnterInitMode(RTC_HandleTypeDef *hrtc)
{
  uint32_t tickstart = 0U;
  HAL_StatusTypeDef status = HAL_OK;

  /* Check that Initialization mode is not already set */
  if (READ_BIT(hrtc->Instance->ISR, RTC_ISR_INITF) == 0U)
  {
    /* Set INIT bit to enter Initialization mode */
    SET_BIT(hrtc->Instance->ISR, RTC_ISR_INIT);

    /* Get tick */
    tickstart = HAL_GetTick();

    /* Wait till RTC is in INIT state and if timeout is reached exit */
    while ((READ_BIT(hrtc->Instance->ISR, RTC_ISR_INITF) == 0U) && (status != HAL_ERROR))
    {
      if ((HAL_GetTick() - tickstart) > RTC_TIMEOUT_VALUE)
      {
        /*** Timeout occurs and this causes the function to exit with HAL_ERROR status ***/
        /* Set RTC state */
        hrtc->State = HAL_RTC_STATE_ERROR;
        status = HAL_ERROR;
      }
    }
  }

  return status;
}

[Gyessine]

Hello @DG_NC 
Can you verify if you encounter the same issue using one of our firmware examples.
If no, you can base yourself on it to solve your issue.
BR
Gyessine

[DG_NC]

Thank you, Gyessine.  I can confirm that I am seeing this issue on the Nucleo-WB05KZ board using the example project you provided!

To reproduce this issue:

1) Use STM32CubeIDE to import the RTC_Alarm project that you shared earlier.  Target the Nucleo-WB05KZ board.

2) With the Nucleo board powered by the USB-C cable, build and flash the project onto the board using STM32CubeProgrammer. Press the RESET button or remove/reinsert the USB cable to start the application, and you will see the CORRECT operation: 30 seconds later the blue LD1 turns on, indicating that the RTC alarm has occurred.  You can also observe LD1 status by measuring the voltage of CN4 pin 6.  It will start at 3.3V (LED off) and then drop to 0V (LED on) after 30 seconds.

The RTC initialization succeeds when the MCU is hardware reset by the ST-Link; I see the same successful behavior on my custom board when attached to the ST-Link.

3) Now, to see the INCORRECT operation: Remove the USB-C cable and prepare to power the STM32WB05 directly from 3.3V.  The easiest way to do this is to remove jumper JP2 and connect a 3.3V supply to pin 2.  Probe CN4 pin 6 (LED1) with a multimeter since the LEDs on the lower board will not illuminate when 3.3V is supplied directly.

Turn on the 3.3V power supply.  The LED1 pin will measure 3.3V (LED off) and remain at 3.3V forever.  It will NOT drop to 0V after 30 seconds.  The alarm fails to occur because MX_RTC_Init() fails as described in my original post.

LED3 (CN4 pin 38) is supposed to blink when Error_Handler() is called, but it will not blink because the BSP_LED_Init() function is not called until after MX_RTC_Init(), which fails.

4) To make the RTC initialization succeed again, press the RESET button while the 3.3V supply is active.  This will result in correct operation, and LED1 will drop from 3.3V to 0V after 30 seconds.  Again, this matches the behavior I observed on my custom board.  Manual reset while already powered results in successful RTC initialization, but booting up from power application results in failure.

5) Optional: to confirm the specific failure point, make a few small changes to the code so you can observer LED1, LED2, and LED3 on the CN3 and CN4 headers.

- Call BSP_LED_Init() at the beginning of MX_RTC_Init() to ensure the GPIO signals are initialized before the failure occurs:

- Update stm32wb0x_hal_rtc.c so that LED2 is turned on when the RTC initialization timeout occurs:

- Now build and flash the updated code onto the board, then repeat step 3) above.  Now you will see:

a) LED1 (CN4 pin 6) stays 3.3V and does not drop to 0V after 30 seconds

b) LED2 (CN3 pin 23) briefly goes to 3.3V when power is applied, and then drops to 0V when the timeout occurs

c) LED3 (CN4 pin 38) toggles between 3.3V and 0V, as programmed in the example code Error_Handler()

I believe these results prove the existence of a problem with the STM32Cube FW_WB0 V1.4.0 firmware package or with the STM32WB05 silicon.  Could you please confirm that you can reproduce my results and provide some suggestions to move forward?  For now, I have tried commenting out the while loop inside RTC_EnterInitMode() so I can get past the initialization error, but I haven't thoroughly tested RTC functionality to determine whether everything is still working after skipping the initialization confirmation.

Thank you for any help you can provide,

Dominic

[DG_NC]

Hello @Gyessine,

Could you please acknowledge receipt of my previous reply?  Have you been able to confirm that the problem is reproducible with the v1.4.0 firmware package and the Nucleo-WB05KZ eval board?

What are your recommendations to move forward with this issue?

Thank you,

Dominic

[DG_NC]

Hello again @Gyessine ,

It has been a few weeks, so I'm checking in again.  Have you been able to reproduce the problem?

Any suggestions?

Thank you,

Dominic

[Gyessine]

Hello @DG_NC 
Sorry for the late reply

First, I wanted to mention that your project works fine on my side. I couldn’t reproduce the issue here.
Also, just to clarify: on the Nucleo‑WB05KZ, LED1 is normally mapped to CN3 pin 51, not CN4 pin 6, so I’m not sure if that’s just a typo in your description or if you’re probing a different signal.
It worked for me when i used the pin51 

Regarding the root cause, I strongly suspect this is more related to the clock initialization than to the RTC itself, especially since the problem happens only after a Power‑On Reset (POR) and disappears after a system reset.

According to the product documentation: After a power‑on reset: The backup domain is reset and all low‑speed oscillators (LSE, LSI) are off by default. The RTC and its configuration registers are in their reset state.

So, if the RTC initialization starts while the LSI/LSE is not yet stable or not fully configured as the RTC clock source, entering RTC init mode can fail.

After a system reset (NRST): The backup domain and the RTC clock source are not reset. By the time the CPU runs your code again, LSI/LSE is already running and stable, so the same RTC init code can succeed.

As a first practical test, I would suggest inserting a small delay to give the low‑speed clock more time to stabilize and see if this changes the behavior.
Also, does this issue occur after every power‑on reset even when the board is powered only through the ST‑LINK (USB‑C), or do you see it only when you power it from an external 3.3 V supply?
Also ,I felt like your issue is similair to this thread maybe his solution can help you.
BR
Gyessine

[DG_NC]

Hello @Gyessine thank you for following up! 

Did you test without the USB-C cable plugged in? 

The problem only occurs when powered with external 3.3V supply at JP2 as described in my earlier detailed writeup.

I haven't had a chance to review the other thread you linked, but I did already try adding a delay (I tried at least 10 seconds) before reporting this issue. 

Thanks! 

Dominic