Skip to main content
ax0018
ax0018
Associate III
September 16, 2017
Solved

CubeMx 4.22.1 bug?

  • September 16, 2017
  • 4 replies
  • 3609 views
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.
    This topic has been closed for replies.
    Best answer by Jeanne Joly
    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

    4 replies

    john doe
    john doe
    Senior III
    September 16, 2017
    Posted on September 16, 2017 at 03:40

    seems to be L4 related as f4 and f7 don't omit PLL M.

    Dave Jones
    Dave Jones
    Associate III
    September 16, 2017
    Posted on September 16, 2017 at 22:36

    I just ran into the same issue. I have a project with an STM32L452 and today updated both my compiler and environment as well as CubeMX. After cleaning and rebuilding everything my code was running 10 times slower. When I compared my old code to the newly generated code I noticed that:

    RCC_OscInitStruct.PLL.PLLM = 1;

    was in the old code, but not in the newly generated code, after updating to CubeMX 4.22.1

    Adding it manually fixed the issue and my code now runs at normal speed. But since this is within a section that is not 'user editable code', it will go away the next time I regenerate the code in CubeMX. So this needs to be fixed ASAP.

    I
    Imen.D
    ST Technical Moderator
    September 18, 2017
    Posted on September 18, 2017 at 19:21

    Hello,

    Thank you for your reported issue. This is raised internally to CubeMx team.

    Kind Regards

    Imen

    In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Thanks
    danielbuga9
    danielbuga9
    Associate III
    September 25, 2017
    Posted on September 25, 2017 at 12:31

    Hello,

    Thanks for raising this issue but please allow me to share a short rant about this. 

    I don't really understand how something like this bug can happen. Does ST test their HAL at all? If yes, do they test with actual projects and if they do, how can it be that this trivial bug is not found? These past few months I had a ton of issues, most of them were checks that the built in asserts caught. Those bugs were one-line fixes but the patch to address them took like 2 months or even a bit more.

    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.

    Coratron
    Coratron
    Associate III
    September 26, 2017
    Posted on September 26, 2017 at 07:50

    I totally agree and I wish there was an option for that, like the tags you mentioned, which we could use wherever we needed to. Currently, every time we reconfigure/regenerate the project we have to manually fix the bug, until next time... The problem with the tags is there will be conflicts with generated code once the bugs are fixed, and we forget about our quick fixes. I still think it is a good idea though, if I were ST I would implement it, as no system will be provided bug free. It's wishful thinking.

    Jeanne Joly
    Jeanne JolyBest answer
    Associate
    February 6, 2018
    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
    Steve Melnikoff
    Senior
    March 16, 2018
    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.

    Terms & ConditionsAccessibility statement