cancel
Showing results for 
Search instead for 
Did you mean: 

CubeMX tool generates dubious declaration for periph init.

onderdelen
Associate II
Posted on September 27, 2015 at 16:07

Hi,

when I generate code for the STM32L0 in CubeMX, my compiler discovers the following problem:

~/projecten/SunnaBat/software/Controller/toepassing/cube/SunnaBat/Src/adc.c:149:47: error: declaration of 'hadc' shadows a global declaration [-Werror=shadow]

 

 void HAL_ADC_MspDeInit(ADC_HandleTypeDef* hadc)

 

                                               ^

 

~/projecten/SunnaBat/software/Controller/toepassing/cube/SunnaBat/Src/adc.c:45:19: note: shadowed declaration is here

 

 ADC_HandleTypeDef hadc;

Same deal with other peripherals like IDWG or I2C.

The generated software has a local variable named exactly the same as a global variable! This is a recipe for confusion or worse.

My compiler is arm-none-eabi-g++ (I won't use gcc, since most of my code is c++)

Has anybody found a way to make the tool generate proper function variable names? I can change them by hand but every time I re-generate from the tool I lose my changes and I need to do it all again.

Perhaps ST could test the code with a c++ compiler, they are much more strict on typechecking and names than a c compiler.

Thanks,

Ewout Boks

4 REPLIES 4
Posted on September 28, 2015 at 17:17

Hi boks.ewout.001,

The issue is reported to dedicated team. As a workaround (maybe you already know it), generate the code without ticking the option ''Generate peripheral initialization as a pair of '.c/.h' files per IP'' in project settings.

-Shahrzad-

onderdelen
Associate II
Posted on October 02, 2015 at 11:36

Hello Sharzad,

thank you for your reply. I mentioned this comment to ST FAE and marketing people at an ST32F7 workshop seminar in Eindhoven, they said they would address the issue as well.

Best regards,

Ewout Boks

AvaTar
Lead
Posted on October 02, 2015 at 12:42

>Perhaps ST could test the code with a c++ compiler, they are much more strict on typechecking and names than a c compiler.

 

I think this is an incorrect assumption. With proper compiler options (like

-Wall

), every average C compiler will warn about this issue.

Judged by the number of issue reports, the CubeMX development team is either lax on testing, or significantly overloaded. I tend to assume the latter.

However, I don't want to act as Beta tester, so I will not consider using the Cube software before it matured significantly. My estimation is about 2 years.

stm32cube-t
Senior III
Posted on October 11, 2015 at 20:15

Dear user,

Which version of STM32CubeMX are you using?

Using latest MX 4.10.1 no such error is encountered as ADC code generation generates for ADC instance 1 the following:

ADC_HandleTypeDef hadc1;

Best regards