Skip to main content
cpinkstone
Associate II
June 9, 2009
Question

Firmware Library MISRA Compliance

  • June 9, 2009
  • 5 replies
  • 1726 views
Posted on June 09, 2009 at 05:59

Firmware Library MISRA Compliance

    This topic has been closed for replies.

    5 replies

    16-32micros
    Associate III
    May 17, 2011
    Posted on May 17, 2011 at 12:41

    Dear pinkstone,

    The STM32F10x Firmware Library (FWLib) has been checked for MISRA-C 2004

    compliance using the PC-Lint static checking tool by Gimpel Software. MISRA compliancy applies only to FWLib peripherals driver source file, examples and project files are not MISRA compliant.

    This was done and reported in a list for each MISRA-C Rule weather it is Advisory or Required and indicates how it is checked. For the checking tool three options are available:

    – The static checker: PC-Lint V8.0

    – The compiler: IAR C/C++ Compiler for ARM V4.42

    – Manual Checking (code review)

    However, we have noticed some areas where MISRA-C 2004 rules that are violated frequently in the code and here below and attached the deviation report. :-?

    Cheers,

    STOne-32.

    cpinkstone
    Associate II
    May 17, 2011
    Posted on May 17, 2011 at 12:41

    Dear All,

    I'm using PC-Lint to check MISRA 2004 compliance of the following line from the firmware examples:-

    GPIO_WriteBit(GPIOB, GPIO_Pin_11, Bit_SET);

    I get the following errors:-

    Note 960: Violates MISRA 2004 Required Rule 10.1, Prohibited Implicit Conversion: Signed versus Unsigned

    Note 923: cast from unsigned long to pointer [Encompasses MISRA 2004 Rules 11.1 and 11.3]

    I thought the firmware libraries were compliant? If so, does anyone know what I'm doing wrong?

    Thanks.

    :(

    ngaylard
    Associate III
    May 17, 2011
    Posted on May 17, 2011 at 12:41

    Quote:

    Hello,

    does anybody know a possibility for suppressing these PC-Lint messages only for the files of the ST firmware library? I use PC-Lint as add-on in µVision3 and I do not want to change the FWLib source and header files (excepting stm32f10x_conf.h).

    If I choose Tools - Lint All C-Source Files then the FWLib files are checked too and create a lot of these warnings.

    I do not want to write the according Lint options into stm32f10x_conf.h since it would suppress the messages too in all my own source files which include stm32f10x_conf.h.

    Thanks in advance,

    Norbert

    it is frustrating that the library is claimed to be compliant and then a fair number of warnings are generated. The best that I can suggest is to configure lint to globally suppress the 3 or 4 warnings related to the ST library and then use the lint +e directive in your source files to re-enable them on a file by file basis.

    What I have done is separate the ST library into a different project that is not checked, abstracted all calls to the ST library into 2 files (configuredevice.c) and an STIO.c file (see Ramtex on the net for their Stimuli gateway functions) I then suppress the warnings on these 2 files.

    norbert2
    Associate
    May 17, 2011
    Posted on May 17, 2011 at 12:41

    Quote:

    However, we have noticed some areas where MISRA-C 2004 rules that are violated frequently in the code and here below and attached the deviation report. :-?

    Hello,

    does anybody know a possibility for suppressing these PC-Lint messages only for the files of the ST firmware library? I use PC-Lint as add-on in µVision3 and I do not want to change the FWLib source and header files (excepting stm32f10x_conf.h).

    If I choose Tools - Lint All C-Source Files then the FWLib files are checked too and create a lot of these warnings. :(

    I do not want to write the according Lint options into stm32f10x_conf.h since it would suppress the messages too in all my own source files which include stm32f10x_conf.h.

    Thanks in advance,

    Norbert

    artur2
    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 12:41

    Hi,

    I prefer to use following options:

    +libdir(ypur_st_lib_directory) -wlib(0)

    It allows to avoid touching ''foreign'' files and it does not require to disable any warnings globally.

    Regards,