CubeMx 4.22.1 bug?

[ax0018]

Posted on September 16, 2017 at 03:06

There might be a bug in CubeMx 4.22.1.

Initialization of PLLM division factor for PLL is not included in automatically generated SystemClock_Config function, that might result in incorrect clock settings. Adding initialization of PLLM manually seems to fix the problems.STM32L4 Nucleo, STM32L4 Cube 1.9.0.

[Imen.D]

Posted on September 28, 2017 at 12:05

Hi

Guta_Ciucur.Vasile

,

All your feedback in this discussion is raised internally to the appropriate team.

Wewill come back to you as soon as possible to inform about the taken actions or explanation if needed.

Best Regards

Imen

[Vasile Guta_Ciucur]

Posted on September 28, 2017 at 12:09

Dave Jones wrote:

...

I, on the other hand, don't agree that ST should not release quick bug fixes between the major releases. This issue was flagged publicly within a week of the release of this version. If they had jumped on it and released a minor rev immediately it not only would have solved it for the people who had already installed the new version, but would have been released before the majority of people had even downloaded the new version at all. The point of having that 3 part version number is that they can release bug fixes.

4.1 should have become 4.2 quickly. We shouldn't have to wait until 4.1

There are even more problems with 4.1, I have problems with the code generated for a Makefile project, target L1 - application crashes or does not run because the code generator omits lines of code for the main clock configuration and probably several peripherals (TIM6 confirmed). All problems are urgent for every one of us but you must admit that it requires time to gather all the problems the new version introduced - I guess is a major rewrite of the code base?

Personally, I don't want a rushed version, I want one that I can count on it. As long as we can fix the code, the waiting won't be so unbearable.

For ST team: The problems in detail at the end of the topic, skip the part with the Linux compilation problems, that was fixed in 4.1, continue reading after that;

https://community.st.com/thread/43473-undefined-reference-to-llrccgetsystemclocksfreq

[Vasile Guta_Ciucur]

Posted on September 28, 2017 at 12:29

buga.d_niel wrote:

...

I don't expect ST to release patches more often, however easy it would sound from out here. But as a workaround it would be nice if we could patch the code with a marker that won't be deleted when re-generating the configuration, like user-placeable /* USER CODE */ tags. Could you please ask the team if this would be possible? It would make our lives easier.

As long as this does not mean that the code generator is absolved of the 'obligatoriness' to generate correct and complete initialization code, then yes. This user zone should be used as a 'message wall' for developer to signal the missing code when they will regenerate the code you archived and sent for examination. As it is right now, I use the user zone number 4 to make my notes regarding the changes or additions to be re-made after a new code regeneration.

[Jeanne Joly · Accepted solution]

Posted on February 06, 2018 at 14:32

Hi all,

Regarding the issue initially raised by

Levch.Alex

(The issue about 'PLLM is no more generated'), it was fixed in the CubeMx version 4.23 asmentioned in the Release note of STM32CubeMX

/external-link.jspa?url=http%3A%2F%2Fwww.st.com%2Fcontent%2Fccc%2Fresource%2Ftechnical%2Fdocument%2Frelease_note%2Fb2%2F02%2F4b%2Fe3%2F81%2F32%2F49%2Fc4%2FDM001076pdf%2Ffiles%2FDM001076pdf%2Fjcr%3Acontent%2Ftranslations%2Fen.DM001076pdf

.

You can upgrade with the latest CubeMX release (version4.24).

Best Regards,

Jeanne

[Steve Melnikoff]

Posted on March 16, 2018 at 17:24

I've just updated to STM32CubeMX v4.25.0, with an STM32L452, and I'm still seeing the PLLM line missing.

Conversely, PLLSAI1M is set to the expected value of PLLM as part of the PLLSAI1 initialisation...except that there is no such value in any register. It does, however, get compared to PLLM, which is how I found this bug in the first place.

As others have said above, it would be very useful to have user code areas in these init functions, so we can safely work around issues like this.

[Dave Jones]

Posted on March 28, 2018 at 04:59

I can confirm what

smelnikoff@sentec.co.uk

says. This problem is NOT fixed in STM32CubeMX v4.0 for the STM32L452 (which happens to be the same part I use in my project)

The line for setting 'RCC_OscInitStruct.PLL.PLLM' is NOT generated in the SystemClock_Config() function.

And there is a line generated that sets 'PeriphClkInit.PLLSAI1.PLLSAI1M', even though according to the clock configuration page in STM32CubeMX for the L452 there is no such register. According to that config page, the PLLM is used as a prescaler for both the PLL and the PLLSAI1.

Please put this back on the list of things to fix in the next release of STM32CubeMX

[Steve Melnikoff]

Posted on March 28, 2018 at 11:54

In the mean time, there is hacky workaround for this which avoids having to edit the non-user code regions.

This line appears in the PLL setup code:

  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_MSI;

In the user code area at the top of the file, add this ♯ define:

  ♯ define PLLSource  PLLM = 1; RCC_OscInitStruct.PLL.PLLSource

This expands the original line into:

  RCC_OscInitStruct.PLL.PLLM = 1; RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_MSI;

It's nasty, but it does the job!

[Imen.D]

Posted on April 04, 2018 at 15:49

Hello

smelnikoff

,

Jones.Dave.002

,

I confirm that PLLM parameter

is no more generate for STM32L4 in the CubeMX

version 4.25

.

T

his bug passed internally to CubeMx team -again- for fix as it seems to be a regression issue after being fixed in version 4.23 and in version 4.25 for L4+ (

asmentioned in the Release note of STM32CubeMX

/external-link.jspa?url=http%3A%2F%2Fwww.st.com%2Fcontent%2Fccc%2Fresource%2Ftechnical%2Fdocument%2Frelease_note%2Fb2%2F02%2F4b%2Fe3%2F81%2F32%2F49%2Fc4%2FDM001076pdf%2Ffiles%2FDM001076pdf%2Fjcr%3Acontent%2Ftranslations%2Fen.DM001076pdf

).

Sorry for such inconvenience.

Best Regards,

Imen

[thz]

Posted on April 10, 2018 at 14:41

Embarrasing! Any patch underway soon?

This is nearly show-stopper for us. We use CubeMX a lot for custom builds for L431 together with different OS profiles.

/Thom

[Coratron]

Posted on April 11, 2018 at 04:18

It is embarrasing. Re-introducing a bug.... I wonder what base they use when they upgrade cubeMX.

What is starting to bother me a bit is all these examples not written with cubeMX, which means the internal teams at ST don't use it. Which means patches takes way longer than if it was their active tool for building such examples and testing things. It is a waste of resources I think.