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.

[john doe]

Posted on September 16, 2017 at 03:40

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

[Dave Jones]

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.

[Imen.D]

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

[danielbuga9]

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]

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.

[Dave Jones]

Posted on September 27, 2017 at 23:56

While I agree that it's bad that bugs like this get through, I also think it's unrealistic to think that more testing can catch them all. This bug still generates valid code that compiles and runs just fine. It just doesn't end up running at full speed. And apparently only affects one of the various series of parts.

While I like the idea of being able to add user generated 'protected code' tags, Gabriel's point is valid, that when the bug is fixed your own fix code remains.

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.22.1 should have become 4.22.2 quickly. We shouldn't have to wait until 4.23.1

[Coratron]

Posted on September 28, 2017 at 02:39

I agree, ST should be able to release quick fixes. If the software used a sort of modular approach where the packages are subdivided in modules, any fix would just affect that module and leave the rest untouched, reducing the amount of downloaded files (just the ones affected would be updated).

Flow of the idea:

1) Bug issue detected by user and submitted.

2) Bug registered in ST database waiting for inspection. The higher the number of users that report it, the higher the priority.

3) Bug validated by ST tech.

4) Push-Update of module that contains the bug and update message shown on CubeMX for those who were using it (other users wouldn't even need to be notified)

5) Happy Days

Easier said than done of course, but I can't see why it could not be implemented.

[danielbuga9]

Posted on September 28, 2017 at 09:49

Dave Jones wrote:

This bug still generates valid code that compiles and runs just fine.

Yes, this one does, but an other issue I have generates code that does not compile.

Dave Jones wrote:

While I like the idea of being able to add user generated 'protected code' tags, Gabriel's point is valid, that when the bug is fixed your own fix code remains.

Issues like this could be solved with version dependent tags or something else. What I suggested or suggest here isn't a complete solution but a possible way that could become a viable workaround if designed and implemented properly. Of course quick and drity ideas like this can contain hidden problems, like the one Gabriel points at, but those problems can be solved.

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.22.1 should have become 4.22.2 quickly. We shouldn't have to wait until 4.23.1

A 'release often' (in this case, without the usual 'release early' part) would be really helpful. Especially considering that the CubeMX ecosystem supports patch releases so users don't have to redownload hundreds of megabytes of example code.

Quick fixes should not take 2 months to reach the users.

[Vasile Guta_Ciucur]

Posted on September 28, 2017 at 11:52

Hopefully, also mine is raised internally...