Compile old project with newest CubeIDE: flash size increased & application not working

[RAltm]

Hello,

I need to modify an old application which has initially been created with Atollic TrueStudio and was then adapted to an early version of CubeIDE. It's a project from a colleague who has retired.

From what I can see so far is that the projects .ioc file was made with a version 6.5 or older (CubeIDE throws an error about it if I try to open it). However, thanks to the project PDF report I was able to recreate the .ioc file with the original device settings. I copied the application sources without modifications and created the project.

Unfortunately, the application does not work, so I'm trying to figure out what's going wrong. From what I can see so far is that the interrupts seem to be correctly enabled and the handlers are called (currently I could verify this only for SysTick, for the other interrupts I need to create a dedicated test setup).

But the original generated code makes calls to the corresponding peripheral handlers from the interrupt handlers which are either missing in the new generated code (e.g. SysTick, there's no automatically available callback) or it might be that the empty, weak default functions are called instead of the 'strong' handlers - as written above, I can verify this only after the test setup is up and running.

Also, it looks like the way to make the corresponding setting in the CubeMX view has changed (enabling interrupts and enabling the generation of interrupt related code seems to be at other places now).

So, in case of that I've overlooked something, any hints about where I should look at in the .ioc configuration is appreciated.

A second question is about the consumed flash size of the binary. The original one took ~8kByte, the new one takes ~12kByte. Since I didn't modify the application source files and the project doesn't use floats or printf() etc I wonder if this should be expected or if there's a (new) setting within the build options which I'm not aware of. Things like compiler/linker optimization settings, etc are identical between the old and the new project files as far as I can see.

Regards

[AScha.3]

Hi,

Should not be difficult to get it running,

Just look for used INT and priorities in NVIC settings,

For needed callback, enable in Cube -> advanced project settings, the callbacks you want.

And set optimizer level to -O2, that's fine.

Then compile and check size.

[Andrew Neil]

Did you just try opening/building the software project? No need to touch the .ioc to do that.

PS:

Note that it is possible to download old versions of CubeIDE - all the way back to 1.0.0

and CubeMX back to 6.2.0

[Pavel A.]

Which STM32 is this?

CubeIDE should be able to import Atollic project, almost no manual intervention should be needed. But firmware library version used by a modern CubeIDE for your MCU likely have been updated and now you're linking with a different version (with obvious consequences). The ARM compiler & linker have been upgraded as well.

All that does not involve (re)generation of code so compatibility of the .ioc file is a non-issue. If you want to change pinout - try to obtain the standalone CubeMX version 6.5 and load the original .ioc. 

[RAltm · Accepted solution]

@AScha.3 

Tweaking the optimization settings had no (positive) effect. However, by enabling link time opimization for both the compiler and linker seems to solve it and now the needed flash size is ~9kB which is acceptable.

@Andrew Neil 

Good to know that it's possible to get all versions ever released. Would have been my "plan B" if I was not able to get the project up and running. Fortunately, I got it up and running :) Informations below.

@Pavel A. 

The project was migrated from Atollic to an early CubeIDE version, the issue was that the .ioc file couldn't be read by newer versions of CubeIDE and that the created binary initially didn't work.

In the meantime, I was able to get it up and running:

• Regarding the consumed flash size, the link time optimization solved the issue as already mentioned
• I compared the generated configuration file sources and it seems that the PDF report file hasn't been updated with the latest peripheral settings, e.g. pulse width values, etc. Looks like the values have been tweaked directly and on-the-fly in the source codes. Adopting the .ioc configuration to the values used in the old configuration files instead of those from the report file makes the new binary working now.

So, I'll do some further testing if really everything is working as expected, but the main issue is solved. Now I've to check for ways how to make a project for multiple targets, but that's a different topic :)

Thanks to all for helping figuring out what was wrong.

Regards

[Andrew Neil]

---

@RAltm wrote:

Now I've to check for ways how to make a project for multiple targets, but that's a different topic

---

Indeed it is.

But here's how I handled having common code for two (or more) different hardware targets:

https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/same-touchgfx-project-for-multiple-cubemx-files-in-the-same/m-p/672534/highlight/true#M37503

It's two projects (each with its own .ioc file) sharing a 'common' code folder.

[RAltm]

---

@Andrew Neil wrote:
But here's how I handled having common code for two (or more) different hardware targets:

That looks promising, I'll try this approach. Thank you.

Regards