2017-05-17 12:58 AM
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-bug2017-05-17 01:37 AM
Hi
Buga.D_niel
,Could you please share your ioc file.
Khouloud.
2017-05-17 02:01 AM
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=false2017-05-18 01:25 AM
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.
2017-05-18 07:49 AM
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.
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.
2017-05-18 08:18 AM
Hi
Sedlacek.Oliver
,Good advice. However, it's always recommended to use the latest version as it contains
some enhancements and bug fixes.
Khouloud.
2017-05-18 08:20 AM
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.
2017-05-19 07:50 AM
Hi
Buga.D_niel
,The points listed in your previous comment are reported internally and will be fixed in coming versions.
Thanks a lot for highlighting this and sorry for any inconvenience this may have caused.
Khouloud.
2017-09-28 04:51 AM
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