Common codebase, different HSE. Any solution when using STM32CubeMx and IDE?

[kimtommy]

So I'm kinda out of ideas on a simple solution on this.

System:

The project is using a common code/binary for two slightly different hardwares. Runtime detection is used (through IO's) to detect what hardware the software is running on. On the current prosject the HSE input is different between the two. You could discuss the logic of this, but here we are, and there are some clear benefits to it as well.

Issue:

Clock configuration needs to be different even if working with one CubeMX file. This is easily handled with selecting "Do not generate system call" in CubeMx and simply duplicating the SystemConfig_Clock() function and keeping one the main. Its not every day clock config is changed.

The issue is however that the compiler define HSE_VALUE is also updated by CubeMx. And it seems to be done so by a script replacing all instances. This value is used in the system file for returning system clock to other peripherals.

Is there any clean and good way to do this?

Could HSE_VALUE somehow be made dynamic? I dont mind changing system_stm32xxx.c but I guess CubeMx will replace it as soon as it gets the chance.

BR

K. Tommy

[TDK]

Within CubeMX generated files, HSE_VALUE is only set if it's not already defined. All definitions look similar to this:

#if !defined  (HSE_VALUE) 
  #define HSE_VALUE    ((uint32_t)25000000) /*!< Default value of the External oscillator in Hz */
#endif /* HSE_VALUE */

So if you #defined HSE_VALUE with something that was evaluated at runtime such as a call to a function, it would work. Just need to make sure the definition exists before you #include the first HAL file.

[kimtommy]

Thanks for the answer TDK.

So in my understanding defines are handled in the preprosessor. Your suggestion would therefore be to define HSE_VALUE to a global variable which is set during runtime? Notice that HSE_VALUE is set as a compiler flag by CubeMX.

This would mean I would have to make sure the global variable is available/included in all files using HSE_VALUE. That might be doable (only using LL not HAL). But would still suffer from CubeMX overwriting. I will do some tests and come back to this. So far my understanding is that the only way I can do it is to unset the define and redefine it to the global variable somewhere it gets included in all hal files.

[TDK]

> Your suggestion would therefore be to define HSE_VALUE to a global variable which is set during runtime?

Yep. Or a function call, which is evaluated at runtime. Presumably your code has some manner in telling what the correct value is for that board. You could even estimate it at runtime by comparing it against HSI or LSI (or LSE if present).

> Notice that HSE_VALUE is set as a compiler flag by CubeMX.

Not unless you've added it as one. It's typically first defined in stm32xxxx_hal_conf.h, but only if it's not already defined, as outlined in my reply above.

[kimtommy]

Evaluation is covered, no issues there.

>HSE_VALUE

>Not unless you've added it as one. It's typically first defined in stm32xxxx_hal_conf.h, but only if it's not already defined, as outlined in my reply above.

I promise I didn't. As soon as you enable HSE and set the frequency in clock configuration it adds it. Or do you mean I should not define this in CubeMX?

Example of defines done for one a project for STM32G4 by CubeMX with CubeIDE as Toolchain/IDE.

 

[TDK]

Huh, well there it is. Hard to argue with that. My screen looks very different from yours for a project generated for an STM32H7 (and STM32F4, literally just tested it). Wonder if it's because you're using LL drivers?

Edit: I can't duplicate what you're seeing, regardless of what I do. HSE enabled, LL enabled, still nothing else shows up under defines. Maybe you've converted an old project and these have carried forward?

 

[kimtommy]

Wow. That's a big difference. Must be HAL vs LL because I just tested with a new project.

I was able to redefine HAL_VALUE to be dynamic, but it means an #include add to stm32g4xx...