Two bugs in CubeMX generated code.

Posted on April 14, 2016 at 11:18

Hello,

Could you please explain your needs about #ifdef statements !

It will be better to attach your .ioc file to confirm the bug ''/**tttttttttt'' in the  stm32f4xx_hal_msp.c

Regards

-ForumSTM32-

Posted on April 15, 2016 at 20:03

Find attached the ioc file that will generate the ttttt line.

As for the mxconstants.h file, what I'm talking about is something called a ''multiple include guard'' which avoids the situation where a header file can be #include-ed multiple times. Using multiple include guards is considered best practice in C (alternatively many compilers use #pragma once) and the lack of multiple include guards is even picked up in some lint programs.

The other .h files generated as a part of the HAL use multiple include guards.

Clear?

Andrei (as seen on the embedded.fm podcast and blog)

________________

Attachments :

test.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Htr2&d=%2Fa%2F0X0000000aXv%2Fu0QNstevU2FcENKSEtqGSab_k0AhedtP5dPlModh9vg&asPdf=false

Posted on April 15, 2016 at 20:23

Also see MISRA 2012 Directive 4.10 (required)

''Precautions shall be taken in order to prevent the contents of a header file being included more than once''

A

Posted on April 18, 2016 at 17:29

Dear user,

This issue will be fixed in 4.15 release.

Although we're working on enhancing CubeMX generated code to be MISRA compliant, so far only STM32Cube HAL drivers from our STM32Cube offer are MISRA compliant .

Best regards

Posted on April 18, 2016 at 18:40

Don't think of it as MISRA compliance, think of it as accepted best practice. 

The MISRA guidelines are just the distillation of decades of experience by huge numbers of companies. If you don't want to use that knowledge, that's fine. That is why they are guidelines.