CUBEMX: How to supress code generation in stm32f4xx_hal_msp.c

[andywild2]

Hello,

I use CubeMX 6.1.0.

Some peripherals I must initialize by myself for some reasons.

So for example if I use the ADC1, I enable a dummy ADC peripheral in CubeMX AND I supress the code generation in ProjectManager/Advanced settings at the same time.

This action is only to asure the ADC-Hal Files are properly in included and linked.

I don´t expect any ADC related code to be generated form CubeMX in this situation.

However CubeMX DOES generate HAL_ADC_MspInit() !! and does some low level init there.

This is very bad because this funtion is defined _weak within the HAL and because CubeMX generates this function now even though code generation for ADC is disabled, I have to cope with some funny low level initialisations when I call the HAL_ADC_Init() function later.

How can this MSP-code generation be suppressed?

Thanks very much for any help

Andy

[MM..1]

HAL_ADC_MspInit() and HAL_ADC_Init() isnt prepared for call directly, Is used from MX func and this can be disabled to call and you can write own, but your idea is closer to LL drivers...

[Khouloud OTHMAN]

Hi @andywild2​,

The HAL_ADC_MspInit function is created in the stm32f4xx_hal_msp.c file to configure the low-level hardware (GPIO, CLOCK) for ADC peripheral.

Actually what CubeMX assure is the generation of stm32f4xx_hal_msp.c file and not suppressing the code generated in it.

Otherwise, the Advanced Settings Tab in CubeMX interface gives the possibility of choosing not to generate code for some peripherals or middlewares: This automatic initialization code generation can be disabled per peripheral or middleware in the Generate code column:

When the Generate code checkbox is unchecked , void MX_ADC1_Init(void) function will not be generated in main.c file () (or adc.c file will not be generated if the option Generate peripheral initialization as a pair of '.c/.h files per peripheral is checked).

if the Do Not Generate Function Call checkbox is checked, STM32CubeMX does not generate the call to the corresponding MX_ADC1_Init . It is up to the user code to do it.

Hope this answers your question.if this this case, please click on the Select as Best button on my reply . This will help other members of the community find this solution more quickly.

Khouloud.

[andywild2]

Hello Khouloud,

Thank you for your reply.

Im not talking about MX_ADC1_Init. It is easy to supress as you decribed.

But CubeMX is still generating HAL_ADC_MspInit which cannot be supressed.

But this generation takes control over _weak HAL_ADC_MspInit() via the linker afterwards. So I have never a chance to write my own HAL_ADC_MspInit().

This is the problem.

If CubeMX is clearly instructed by the user to generate no ADC code it should just follow this instruction and do note generate ADC-related code elsewhere.

Thank you very much

Andy

[MM..1]

Simply when you dont need set this msp file to exclude from build and create your own msp2.c , this will linked ok

[Khouloud OTHMAN]

Hi @andywild2​ ,

Thanks for your feedback. I can understand your request but what I want to clarify is that this can't be done by CubeMX and what CubeMX ensure is the generation of stm32f4xx_hal_msp.c file, the modifications that can be done in this file should be in the USER CODE sections.

Khouloud.

[andywild2]

Hi Khouloud,

Let me explain in more detail, because I like the CUBEMX generally, maybe this helpes to improve it.

In my project many other peripherals are managed via CubeMX for example USB/Ethernet.

Therefore excluding the msp file like MM..1 suggested is no solution, because I need many parts of it.

I have the general task to manage a peripheral by my own without ANY interference of CubeMX.

ADC1 is just an example for a peripheral.

How to do this?

Solution1:

you do not tell CubeMX about ADC1

then the ADC-HAL-Files are not included (because the whole include process is controlled by CubeMX)

no good solution

Solution2:

You enable ADC1 in CubeMX and uncheck "Generate Code" in Advanced settings

Then CubeMX does the following:

• the global handle ADC_HandleTypeDef hadc1 is not created in main.c --> good
• the function call MX_ADC1_Init() is not created in main.c --> good
• but in stm32f4xx_hal_msp.c the low level HAL_ADC_MspInit() is still created --> not good

This wrong creation has the following consequence:

The generated function void HAL_ADC_MspInit(ADC_HandleTypeDef* hadc) REPLACES the original _WEAK definition within stm32f4xx_hal_adc.c!!

Your mentioned UserCode section within this generated function does not help either: You can fit in a return statement, so the function does not do anything.

But you CANNOT eliminate the function HAL_ADC_MspInit() itself with any of this UserCode action.

This function stays in stm32f4xx_hal_msp.c like a piece of stone! So the user is not free to use the HAL-Library for a peripherial under his control like he did years before CubeMX...

On the other side, life could be so easy:

This function which CubeMX generates (HAL_ADC_MspInit) is completely useless because

• nobody in the CubeMX context uses it
• CubeMX was so smart not to create a handle for the ADC. What is the sense for creating a function that has no resource to work with??

It would be a piece of cake for the developers of CubeMX to supress this generation as well.

I think it would be the desire of the developers of CubeMX to offer a clear situation for a user who needs a mixture of CubeMX controlled peripherals and self controlled peripherals:

--> For self controlled peripherals the only thing that CubeMX does is to make sure the appropriate HAL-Files are linked, nothing else!

That would be really great.

Maybe you can forward this suggestion to the appropriate place

Thanks for your help

Andy

[Khouloud OTHMAN]

Hi @andywild2​ ,

Let me thank you first for your trust and confidence in our tools and let me assure you that our aim is to always improve them in order to satisfy users :)

Thanks also for the detailed prepositions you gave they will be taken into consideration.

Just to add in this same subject, generated project by CubeMX is in coherence with HAL drivers design, you can refer to the STM32F4 HAL and low-layer drivers User Manual for more details about the HAL MSP initialization process.

This may help you.

Khouloud.