FAQ STM32MPUs: How to migrate STM32CubeMX project from a previous ecosystem to a new one

[Emmanuel COMBETTE DE RYMON]

Do you have a STM32CubeMX project created for a previous STM32MPU ecosystem release and would like to upgrade your project in a new ecosystem?  If so, you are in the right article.

Step-by-step

To migrate a project from a previous version of STM32CubeMX to a new one, you must follow the following steps:
1. Take your project .ioc and open it with the STM32CubeMX version coming from the new ecosystem.
2. Generate your code files.
3. Copy the code from the user sections of the device tree files of your previous project to the user sections code of the device tree files generated with the STM32CubeMX new version.

Note for step 3: It might be possible that the device tree properties name or new properties happen between two versions of the ecosystem. Make sure you adapt the properties according to the new version when you do step 3. You can verify that with the reference device tree files of the ST board from the new ecosystem.
You can also verify the peripheral device tree usage in the wiki device tree articles (These articles are inline with the code delivery). https://wiki.st.com/stm32mpu/wiki/Category:Device_tree_configuration

The Change_notification article below provides you with a first overview of the evolutions between the ecosystem releases: ST Wiki: OpenSTLinux changes notification
 

Additional resources:

• FAQ: STM32MPUs - How to create a device tree adapted to your design with STM32CubeMX?

[cfilipescu]

both links are broken @Emmanuel COMBETTE DE RYMON 

[debugging]

Thank you for this post. Your articles "FAQ" are extremely valuable. Thank you for writing those.

This also clarifies why we have such a hard time changing to a new kernel.

All release notes before v.5.0.0 are gone from STM's website. Suppose, you have a product running based on ECO V3. (Linux 4.x) If you have a product and  want to update the kernel (v6.1)  because of new features  it is needed to go back to the .ioc for the MPU, regenerate TF-A, SBL's, FIP and U-boot as well as the kernel itself.  The SD/EMMC flash formats and the device tree definitions change without much documentation + even worse this article is pending. https://wiki.st.com/stm32mpu/wiki/How_to_create_your_board_device_tree

This article is currently under complete rework to provide relevant information for the ecosystem release v5.0.0

How to build the images for ECO 5.0.0. which all rely on the device tree ?

Some documentation to build is also confusing . ECO repo files have README's (which are better then the on line wiki's) but provide different information than in the wiki's for u-boot, FIP, TF-A etc..Some steps are sometimes missing.

Would STM employees step by step run the steps in the wiki, readme's and evaluate if anyone that isn't familiar with every bit of the quirks in the ecosystem to be able to build the images, specially for customized boards. ?

 

[Laurids_PETERSEN]

Hi @cfilipescu, the links are now updated. 

Hi @debugging, your feedback has been shared and this article is in the pipeline to be updated soon. 

Best regards, Laurids

[debugging]

The link result in a page with:

This article is currently under complete rework to provide relevant information for the ecosystem release v5.0.0

Hi,

I'm trying to convert a .ioc from Eco 3.1 to Eco 6 following your guide.

- I put the .ioc file alone in a new directory

- I open the .ioc file with CubeMX 6.13, let CubeMX to do the migration, and click to "generate files"

- I compare old and new DTs to import USER SECTION code

but new DTS files does not contain pinctrl settings of peripherals, that are contained in files generated for Eco3.1 with CubeMX 6.4.

These configurations are done in CubeMX, so it is expected that they are in generated dts as well.

How can I remedy to that?
Thanks in advance

Answering to myself, there is a pin conflict on a peripehral: resolving the conflict results in properly generated pinctrls.

 

Conflict was also in the starting .ioc file, but old CubeMX 6.4 generates anyway pinctrls. CubeMX 6.13 does not, don't know if it's a wanted behavior (if yes, why don't generate a helpful message?) or if it is a bug.