Bug found and solved inside HAL_RCCEx_GetPeriphCLKFreq(uint32_t PeriphClk), why is this happening?. Additional bugs found too

[VRami.1]

Hi all, how are you?. Yesterday I was unable to make the RTC work on my STM32F103C6, miraculously I've noted that the program was giving an error condition (until that moment I wasn't using the error handler function, now I'm using it) then I found that the error was that the function HAL_RCCEx_GetPeriphCLKFreq(uint32_t PeriphClk) used by HAL_RTC_Init() was returning zero as the frequency for the RTC was consecuently had a result or error initializing the RTC.

The line of HAL_RCCEx_GetPeriphCLKFreq(uint32_t PeriphClk) where the frequency was returned is the 584 ant the code is the following

return (frequency);

The line of HAL_RTC_Init() where the assigning was happening is the 364 and the code is the following

prescaler = HAL_RCCEx_GetPeriphCLKFreq(RCC_PERIPHCLK_RTC);

to solve the problem I had to change the line 584 of HAL_RCCEx_GetPeriphCLKFreq(uint32_t PeriphClk) to the following

return (uint32_t) frequency;

Now the definitions:

The definition of the function to get the frequency on line 387 stm32f1xx_hal_rcc_ex.c is

uint32_t HAL_RCCEx_GetPeriphCLKFreq(uint32_t PeriphClk)

The definition of the "frequency" variable in the line 403 of the same file as before is

uint32_t temp_reg = 0U, frequency = 0U;

and the definition of the "prescaler" variable in the line 277 of stm32f1xx_hal_rtc.c is

uint32_t prescaler = 0U;

as you can see, all is defined as uint32_t so I initially supposed that there must be no problem of truncating the data, then what was happening?, there initially the code was trying to make a casting to nothing by doing return (frequency) or was another thing happening that I don't understand?. Please somene that can clarify this to me.

Another bugs are present in my code like the followings:

1. Every time that I initialize the I2C peripheral (feature needed in mi code) if there is a HAL_Delay() call at any part of my program then the program seems to reset as soon as the code arrives to any peripheral initialization call (as crazy as it sounds it is happening), I haven't found the reason yet.
2. Every time that the alarm interrupt (another feature needed in my code) or the second interrupt of the RTC are enabled then the RTC doesn't count, it simply mantains the same hour, minute and second forever.

all this is happening with HAL libraries so, is any kind of support by ST people with the libraries, where can we report bugs to ST?

Thanks in advance for the help.

[S.Ma]

well there are st moderators and probably clive can point them to your post. HAL functions should enhance clarity level by using parameter and variables with make sense units.

frequency or frequency_Hz? value or value_mV ? Delay or Delay_ms?

temp or temp_DegC_x10 ?......

[TDK]

> Please somene that can clarify this to me.

The lines:

return frequency;
return (frequency);
return (uint32_t) (frequency);
return (uint32_t) frequency;

are identical if frequency is defined as a uint32_t. The error has to be somewhere else.

[VRami.1]

Welll, I taught exactly the same because preciselly all the code is define as uint32_t so comun sense indicates that there couldn't be any case of truncating data or related, but the thing is that it was the change that allowed me start the RTC counting. I haven't change any other line of code to make it work, just that line.

I found that after hours of running the code line by line with the debugger and like I said, because of that the following condition

if (HAL_RTC_Init(&hrtc) != HAL_OK)
  {
    Error_Handler();
  }

starting at line 40 of rtc.c was resulting in a HAL_RTC_STATE_ERROR and consecuently calling the Error_Handler();

[VRami.1 · Accepted solution]

In that function the value variable returned is called frequency, for the USB, the RTC and the I2S at least, in fact, inside HAL_RTC_Init() they wrote a condition exactly for this case starting at line 366 of stm32f1xx_hal_rtc.c wrote as follows:

     /* Check that RTC clock is enabled*/ 
     if (prescaler == 0U)
      {
        /* Should not happen. Frequency is not available*/
        hrtc->State = HAL_RTC_STATE_ERROR;
        return HAL_ERROR;
      }

that was after the line

prescaler = HAL_RCCEx_GetPeriphCLKFreq(RCC_PERIPHCLK_RTC);

that was the condition that returned the error so, if that shouldn't happen then why they did put that condition?. I think they may be knew that it could happen.

[VRami.1]

Hi all, how are you?. I've found and solved the bug with the RTC, is published in the following thread

https://community.st.com/s/question/0D53W00000EFYknSAH/bug-found-and-solved-inside-halrtcexrtcirqhandlerrtchandletypedef-hrtc