cancel
Showing results for 
Search instead for 
Did you mean: 

One MCU type, multiple functionalities, one hex file

Stm32_worker
Associate II

In a project there are multiple MCUs of the same type. Each of these must have the same software on it and decide at startup which role they take. Some pin definitions are common for all the MCUs (like clock, identification, communication,...) and others differ completely, hence need to be initialized differently.

It is a requirement that all of these MCUs are having the same software on it for update reasons. And preferrably changes pin definitions could be made in CubeMX.

One option would be to have a CubeMX project for each of the MCU role and copy the generated code by hand to a overall project. This involvels a lot of hands on which is cumbersome and error prone. But since not too many changes are expected certainly doable.

I've looked at nested projects. But since only one .ioc file can be active within one IDE project not really an option.

There is also the option of Project references. But I could not find any documentation on the purpose of these and how it would work.

Is there a good way to handle this situation in CubeIDE?

1 ACCEPTED SOLUTION

Accepted Solutions
Pavel A.
Evangelist III

But since only one .ioc file can be active within one IDE project 

Just use the standalone CubeMX instead of the CubeIDE "plugin". The former lets you have as many .ioc variants as you want, name them as you want and keep them where ever you want. 

 

View solution in original post

5 REPLIES 5

Sounds like a nightmare if you're auto-generating all these individually. Not really designed for hybrid functionality.

Can't you make one project that combines all functionality and merge in the salient portions from the auto-gen'ed pieces. CubeMX disperses rather than centralizes the code. Pin / Peripheral level differences in initialization likely to be in the MSP files.

You could use a loader that selected the appropriate sub-function application.

Then each would need it's own unique address within the FLASH memory space, you'd want the code setting the SCB->VTOR to perhaps do this automatically based on the symbol for the Vector Table, rather than #define in the stm32_system.c / SystemInit() code.

Decent merge tools could make some of this manageable and scripts.

Better would be to rationalize the multiple functionality and dispense with auto-gen nonsense. Decompose the projects so you have the common pieces for the board, and separate source files/directories for the sub-functions

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Stm32_worker
Associate II
Not really designed for hybrid functionality.

That was my suspicion.


Can't you make one project that combines all functionality and merge in the salient portions from the auto-gen'ed pieces.

Shure, that's what I meant with one CubeMX project per role.

Yes, a loader will need to decide which role to execute.

Alright, thanks for the hints, I'll get to work then!

AScha.3
Principal III

>Is there a good way to handle this situation in CubeIDE?

I just can tell, how we do (at work) : 

- if not many variants (maybe 15 ), a dip-switch is there, for info: what to be/do here

- if many , a local mounted eeprom is in every machine, for info...

+

The "basic" program is set in Cube/IDE , make a project with all defined, whats always used.

Then after start cpu reads info (or switches), "who am i " ; now other specific peripherals are set and used then.

This way only one "standard" program to manage, but many even very different use cases possible.

 

If you feel a post has answered your question, please click "Accept as Solution".
Pavel A.
Evangelist III

But since only one .ioc file can be active within one IDE project 

Just use the standalone CubeMX instead of the CubeIDE "plugin". The former lets you have as many .ioc variants as you want, name them as you want and keep them where ever you want. 

 

Stm32_worker
Associate II

Thanks for all the inputs.

There will be one pin which has an array of resistors connected to it. At startup, the analog voltage is read and this defines the role the specific MCU has to take.

I think I'll go for one "main" IDE project with CubeMX "plugin" for the common part (also the stuff described above) and use seperate CubeMX projects for each role, then copy its initialisiation to the "main" project by hand. Not the most automated way, but doable since not too many changes are to be expected on the hardware side.