Skip to main content
danielbuga9
danielbuga9
Associate III
May 17, 2017
Question

CubeMX F0 1.8 issues

  • May 17, 2017
  • 8 replies
  • 1199 views
Posted on May 17, 2017 at 09:58

Hi!

For me, the new 1.8 version of CubeF0 is completely broken. Using the HAL RCC driver, it tries to

a) enable USART2 that I don't use, and it fails because it can't set its clock source

b) enables HSI oscillator (which I don't use) without setting the calibration value. If I use HSI for something, calibration value is set.

Using the LL RCC driver the above issues are not present, but the PWR module clock isn't enabled and I can't write the backup domain (LL_PWR_EnableBkUpAccess in SystemClock_Config has no effect because the registers don't have clock). Because of this, initializing the RTC fails with a timeout and my controller gets stuck in the error handler.

Now these issues are easily worked around but it was very frustrating to debug.

#ll-bug #stm32cube-bug #hal-bug
This topic has been closed for replies.

8 replies

Khouloud GARSI
Khouloud GARSI
ST Employee
May 17, 2017
Posted on May 17, 2017 at 10:37

Hi

Buga.D_niel

‌,

Could you please share your ioc file.

Khouloud.

danielbuga9
danielbuga9Author
Associate III
May 17, 2017
Posted on May 17, 2017 at 11:01

Attached is the ioc file. That is currently being used. It uses the LL driver which needed the less amount of workarounds on my end.

One more thing I've found:

Although the release manual states that the RTC backup domain is not reset at system reset, the firmware resets is automatically. RTC uses a magic value to check for reinitialization, but it is reset by the LL RCC driver at startup, making it useless. Also, setting the initial date and time is NOT done in the section that is executed conditionally, but instead it is executed at any reset event, making the RTC somewhat useless.

Please note that I was able to work around my issues, these are merely places where I think the current drivers can be improved.

________________

Attachments :

Project.ioc.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hyf9&d=%2Fa%2F0X0000000bAh%2FQElliS16WfCiXd4Nb3AkqeGCGnrMORi_cDeWO5Vj2oY&asPdf=false
Khouloud GARSI
Khouloud GARSI
ST Employee
May 18, 2017
Posted on May 18, 2017 at 14:49

Hi

Buga.D_niel

‌,

a) enable USART2 that I don't use, and it fails because it can't set its clock source

I'm not able toreproduce this even with the ioc file you have attached. Is this the ioc file where the issue occurs?

For further debug, could you please send us the STM32CubeMX.log file (found under your user directory in the .stm32cubemx folder).

b) enables HSI oscillator (which I don't use)

You're using the HSI as a clock source for the USART1 peripheral.This is the reason why HSI oscillator is enabled.

0690X00000606ndQAA.png

  • About the issues encountered with the RTC peripheral, I advise you to refer to the ''RTC_Calendar'' example found under the path below: ''STM32Cube_FW_F0_V1.8.0\Projects\STM32091C_EVAL\Examples\RTC''

This may help you to correctly configure this peripheral.

Please note that I was able to work around my issues

Could you please share this workaround to better verify the issue.

Thanks and regards,

Khouloud.

danielbuga9
danielbuga9Author
Associate III
May 18, 2017
Posted on May 18, 2017 at 15:20

Khouloud G wrote:

Hi

Buga.D_niel

,

a) enable USART2 that I don't use, and it fails because it can't set its clock source

I'm not able toreproduce this even with the ioc file you have attached. Is this the ioc file where the issue occurs?

For further debug, could you please send us the STM32CubeMX.log file (found under your user directory in the .stm32cubemx folder).

b) enables HSI oscillator (which I don't use)

You're using the HSI as a clock source for the USART1 peripheral.This is the reason why HSI oscillator is enabled.

After changing the code generation back to HAL I'm also unable to reproduce my own issues. But to explain: my issue was that HSI was enabled, but calibration was not set by RCC, even when I did not set UART1 to use it. But again, it was solved by selecting, and then deselecting HSI as clock source, the code that enabled it was correctly removed at next generation.

The RTC example is made with HAL and my problems are with LL. With the RCC code generated for LL, the following code is generated in SystemClock_Config:

LL_PWR_EnableBkUpAccess();

LL_RCC_ForceBackupDomainReset();

LL_RCC_ReleaseBackupDomainReset();

This is obviously incorrect as I wouldn't want my backup domain to reset, and also, PWR does not have its clock enabled. My solution is to check the backup register for the value set in MX_RTC_Init. So the change in SystemClock_Config is the following:

if (RTC->BKP0R != 0x32F2) {

LL_RCC_ForceBackupDomainReset();

LL_RCC_ReleaseBackupDomainReset();

LL_RCC_SetRTCClockSource(LL_RCC_RTC_CLKSOURCE_HSE_DIV32);

}

RTC HAL is also incorrect. The example is useful, but in my case (CubeMX code generation) it is irrelevant because the code generation is broken. In MX_RTC_Init the magic value is checked/set after the calendar and time is reset, like this:

...

if (HAL_RTC_SetTime(&hrtc, &sTime, RTC_FORMAT_BCD) != HAL_OK) {

_Error_Handler(__FILE__, __LINE__);

}

...

if (HAL_RTC_SetDate(&hrtc, &sDate, RTC_FORMAT_BCD) != HAL_OK) {

_Error_Handler(__FILE__, __LINE__);

}

if (HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR0) != 0x32F2) {

HAL_RTCEx_BKUPWrite(&hrtc, RTC_BKP_DR0, 0x32F2);

}

Moving the check to before SetTime, the calendar/clock is no longer reset.

Unfortunately I don't have the log file because it was overwritten since then.

Oliver Sedlacek
Oliver Sedlacek
Senior
May 18, 2017
Posted on May 18, 2017 at 10:25

I've also found lots of problems going between versions. Key advice is to keep hold of the installer for every version so that you can go back to something that's stable for your project. If it's a team effort you need to decide on a version and then make sure everyone sticks to it.

Khouloud GARSI
Khouloud GARSI
ST Employee
May 18, 2017
Posted on May 18, 2017 at 15:18

Hi

Sedlacek.Oliver

‌,

Good advice. However, it's always recommended to use the latest version as it contains

some enhancements and bug fixes.

Khouloud.

Cyril FENARD
Cyril FENARD
ST Employee
September 28, 2017
Posted on September 28, 2017 at 13:51

Hi

Buga.D_niel

,

Thank you for posting the problem.

The correction is provided in the next CubeMx v4.0.

(RCC_OscInitStruct.HSIState is not set to RCC_HSI_ON if OscillatorType is other than the HSI case).

Regards.

Cyril

Terms & ConditionsAccessibility statement