2022-03-06 09:08 PM
As part of maintaining one repository for the application SW, planning to make HAL separation and build configuration switch to be able to work with one STM32CubeIDE, ioc file.
Controller change expected from the same Architecture. listed as below
Current MCU: STM32F446RET6.
New MCU : STM32F411CCU6TR
Solved! Go to Solution.
2022-03-08 01:48 AM
In principal - assuming you stay on the same mcpu=cortex-m4, you could create a couple of build configurations in CubeIDE to support this.
But. as @Osman SOYKURT points out. The ioc-file does not support MCU per build configuraiton. There is no concept of build targets or build configurations in the ioc-file. --> The same ioc-file will be shared by the F411xE and F446RE in the exactly same configuration.
I assume that this will constrain your development too much...
But, if you intend to use exactly the same ioc-file configuraiton for both F4 devices, then you could just manually add a second startup file and linker script and point them out to be used per build configuration and exclude them from build in the other configuration.
In practice I think most projects are composed of:
If you project looks like this, then I would opt for CDT projects which support setting totally different MCU per build configuration. One build config can target M4, another M0... These CDT project would be empty containers. And then you link in the folders/files you need from the above three bullets.
A bit more cumbersome to setup. But you get more flexibility and maintainability.
2022-03-07 03:51 AM
Hello @Seenu and welcome to the Community :)
To migrate from MCU1 to MCU2 using STM32CubeIDE, please refer to this FAQ:
You can also switch from one STM32 to another using STM32CubeMX:
Hope this may bring you some help!
Imen
2022-03-07 04:12 AM
Hello Seenu,
No it's not possible. If you open your ioc file with notepad, you'll see that this file is dependent to the MCU and its very own configuration. So even 2 same MCU but different configuration will have different ioc file. And 2 different MCU could never have the same ioc.
/Osman
2022-03-07 04:14 AM
Thanks for the response @Imen DAHMEN
The migration from MCU1 to MCU2 already done.
HAL and Build environment for the both MCUs - MCU1 and MCU2 are available.
We want to introduce a MACRO/Configuration switch - DSTM32F411xE or DSTM32F446xx, which can select the required environment (Linker scripts (ld)/ Startup files (s)) to build the software. This way we can maintain the one software repository and able to select the configuration switch depending on the MCU required.
Please let me know if you need more information.
Seenu
2022-03-08 01:31 AM
Hello @Seenu ,
Please check my answer in this thread Changing from STM32F769NIHx to STM32F769BGTx
I hope this helps !
If your issue is solved, please close this post by clicking the "Select as Best" button. This will help other members of the community find this response more quickly :)
Sara.
2022-03-08 01:48 AM
In principal - assuming you stay on the same mcpu=cortex-m4, you could create a couple of build configurations in CubeIDE to support this.
But. as @Osman SOYKURT points out. The ioc-file does not support MCU per build configuraiton. There is no concept of build targets or build configurations in the ioc-file. --> The same ioc-file will be shared by the F411xE and F446RE in the exactly same configuration.
I assume that this will constrain your development too much...
But, if you intend to use exactly the same ioc-file configuraiton for both F4 devices, then you could just manually add a second startup file and linker script and point them out to be used per build configuration and exclude them from build in the other configuration.
In practice I think most projects are composed of:
If you project looks like this, then I would opt for CDT projects which support setting totally different MCU per build configuration. One build config can target M4, another M0... These CDT project would be empty containers. And then you link in the folders/files you need from the above three bullets.
A bit more cumbersome to setup. But you get more flexibility and maintainability.
2022-03-23 09:13 PM
Hello @mattias norlander
Thanks for the suggestion.
Made application code and MX generated code separate in the source repository and updated application code with conditional compilation to support both MCUs.
Also created two different build configurations in the project properties for each MCU, with required MACROS, Startup file and linker script needed at specified locations in the CubeIDE.
Now MX re-generation may cause issue but my complete source code works fine for the both MCUs and only change needed to change the build configuration based on the MCU.
Best regards,
Srinu