cancel
Showing results for 
Search instead for 
Did you mean: 

Changing over to CubeMX 6.2.1 gives issues in my project with clock settings

EDewi.1
Associate II

I have a working project on STM32H750VBT6 with multibootloader and executing code from external Flash. When changing to CubeMX6.2.1 clock configuration reports issues although nothing has been changed. How to solve?

8 REPLIES 8
TDK
Guru

Need more to work with here. Look at the issues it's reporting and solve them.

If you feel a post has answered your question, please click "Accept as Solution".
EDewi.1
Associate II

Dear,

Thanks for your answer.

The project is a small color display with touch, where I run with TouchGFX a demo on with several pictures. The interface is RGB, for the rest there is an external Flash where the code is executed from. This project works fine till change over to CubeMX6.2.1, no picture anymore, seems like dead.

The project has a multi boatloader with it's own .ioc file. And a main project wit it's own .ioc file. It is the Multibootloader project .ioc file where the clock setting issue is reported. Not sure if this is the root cause of the issue.

I added screenshots of the Clock Config when using CubeMC6.1.1 and 6.2.1. Both opening the same project, nothing changed in code nor settings. You can see the SPI clock of 240 MHz seems to give an issue. Prescaler of both has not been changed and set at 4. When I solve the issue by changing the PLL divider or using other clock like PER_CK, I can generate code, build the project, but my project does not work at all.

Although the SPI is configured I do not use it in my hardware so I think still something else has to be changed in settings.

The project has a multi bootloader with it's own .ioc file.

In migrating top the 6.2.1 I also had to switch in the repository to FW_H7_V1.9.0 (from V1.5.0)

As nothing has been changed in code nor in settings I am puzzled about what to do to solve this.

0693W00000BbKvkQAF.png0693W00000BbKqyQAF.png 

TDK
Guru

Hover over the error to find the cause. In this case, most likely:

0693W00000BbOk1QAF.png 

To fix, change the PLL1Q clock to 200 MHz or under, or choose a different clock for SPI that satisfies the restriction.

If you feel a post has answered your question, please click "Accept as Solution".
EDewi.1
Associate II

Thanks for your fast answer. I did adapt already as you described, strange however I do not get this error with version 6.1.1.

As indicated, I do not use the SPI interface, it looked however strange.

Still my hardware (although nothing changed to code, except going over to the 6.2.1 of CubeMX with same settings and also going to the STM32Cube_FW_H7_V1.9.0 version) even the Xtal does not start....

Any idea what setting could have been altered by the 6.2.1 CubeMX so that my hardware does not start anymore?

Thanks

EDewi.1
Associate II

In attachment you can find the bootloader.

The project has a bootloader and a main application. The bootloader does define the Quadspi so the main application can be loaded into the Quadspi and runs also from this Flash (XIP).

All working with CubeMX6.1.1, when only adapting bootloader to 6.2.1 (after clock settings adapted so no errors as you decribed) and main application left untouched .ioc file created with 6.1.1 the system does not start anymore. (No code changed)

TDK
Guru

> As indicated, I do not use the SPI interface, it looked however strange.

Your project includes an spi.c file. Clearly, SPI is being used, or at least initialized.

I would focus on the problem directly instead of trying to figure out what changed between 6.1.1 and 6.2.1.

"does not start" isn't very helpful. What happens when you debug the code? Where is it stuck?

If you feel a post has answered your question, please click "Accept as Solution".
EDewi.1
Associate II

Dear TDK,

Thanks for your answer.

Indeed SPI is initialized, however not used (copy paste project)

The project was working on my hardware. Code untouched, just changing over to CubeMX 6.2.1, project does not work

Does not work means: the Xtal oscillator does not even start.

Seen no changes have been applied to the code do you think it makes sense to still debug the code?

Seen the Xtal oscillator does not start how to debug the code as nothing is running?

Regards

If something is not working, that is even more reason to debug. That's what debugging is for.
The chip boots up using the internal HSI as the clock. It does not require a crystal to start up or debug.
If you feel a post has answered your question, please click "Accept as Solution".