CubeMX tool generates dubious declaration for periph init.

onderdelen · ‎2015-09-27

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

Nickname5522_O · ‎2015-09-28

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 · ‎2015-10-02

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 · ‎2015-10-02

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 · ‎2015-10-11

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