Possible Issue in Cube MX 6.17

[TA1]

Dear all and ST Tech Support,

I am writing to report a concerning inconsistency I encountered while migrating an older project to the latest version of STM32CubeMX (v6.17.0).

Background: I recently reopened a project originally created about two years ago with STM32CubeMX v6.8.1 for the STM32H742VGTx MCU. My goal was to review the Timer 4 settings to use them as a reference for a new design.

The Issue: Upon inspecting the Clock Configuration tab, I noticed that the APB1 Timer Clock was displayed as 120 MHz. Based on my original project notes, this value should have been 240 MHz.

When I calculated the Timer 4 period using the 120 MHz figure, the resulting timing was twice as slow as it should be. While checking the documentation, I confirmed that Timer 4 is connected to the APB1 bus. In the CubeMX interface:

• The D2PPRE1 divider was set to /2, resulting in an bus clock of 120 MHz (which is the limit).

• However, the Timer Multiplier was stuck at x1, leading to an APB1 Timer Clock of 120 MHz.

Observations:

1. The multiplier (x1/x2) is not user-configurable; it is handled automatically by the software.

2. I opened another similar project from the same era, and in that file, the APB1 Timer Clock correctly showed 240 MHz with the x2 multiplier active.

3. I tried to resolve the issue, I manually changed the D2PPRE1 divider from /2 to /1 (which triggered a red error highlight due to frequency limits) and then changed it back to /2. After this "reset," CubeMX correctly recalculated the values, the multiplier automatically jumped to x2, and the Timer Clock returned to the correct 240 MHz.

Concerns: This behavior is quite alarming. If a developer needs to make a minor change and regenerate code for a legacy project, such "silent" shifts in clock calculation could lead to critical timing errors in production code without any explicit warning.

I have attached screenshots showing the state before and after the manual refresh. I kindly request the CubeMX team to investigate why these multipliers occasionally fail to update correctly during project migration or when loading older .ioc files.

Best regards,

[TA1]

While trying to figure out the issue on my own, I realized that the problem might not be caused by the new version of STM32CubeMX, but perhaps by the older version I was previously using.

I backed up the .ioc file generated by STM32CubeMX v6.8.1 and opened the project in the latest version of CubeMX. I applied the method I described earlier to change the multiplier from x1 to x2 and saved the project. Then, I opened the new .ioc file (saved with v6.17) in Notepad and compared the differences between the two files.

In the older version's file, I noticed a line: RCC.Tim1Mul=1, which does not exist in the new file. This specific parameter is not something I can manually change through the GUI. However, this discrepancy exists.

In the old file: RCC.Tim1Mul=1 RCC.Tim1OutputFreq_Value=120000000 RCC.Tim2OutputFreq_Value=240000000

In the new file: RCC.Tim1OutputFreq_Value=240000000 RCC.Tim2OutputFreq_Value=240000000

I’m not entirely sure what the underlying issue is, but everything was correct when I first created the project; the code is still running and there are no functional problems. It seems there was some kind of bug or inconsistency between CubeMX versions during the migration.

[TDK]

If you believe the new version still has a bug, please attach your IOC so it can be investigated.

> It seems there was some kind of bug or inconsistency between CubeMX versions during the migration.

Migrating, especially from a version 2 years ago, is not expected to be flawless. Definitely check things before/after.

[TA1 · Accepted solution]

The problem isn't related to the newer version or immigration issues. There is an issue with an old .ioc file, and I’m not sure why. I believe I originally created the project and the code ran fine. Later, I installed a new version of CubeMX and likely had to open the project. When I opened it, it migrated the file; I checked what I needed to and closed it. However, the relevant setting must have been corrupted at that point without me noticing. I probably didn't request CubeMX to generate C code again after that, which is why I didn't catch the error until now.