This section describes MISRA-C:2012 compliance and deviations for the DFU.
MISRA stands for Motor Industry Software Reliability Association. The MISRA specification covers a set of 10 mandatory rules, 110 required rules and 39 advisory rules that apply to firmware design and has been put together by the Automotive Industry to enhance the quality and robustness of the firmware code embedded in automotive devices.
The MISRA specification defines two categories of deviations (see section 5.4 of the MISRA-C:2012 specification):
Project Deviations - deviations that are applicable for particular class of circumstances.
Specific Deviations - deviations that are applicable for a single instance in a single file.
Project Deviations are documented in current section below.
Specific deviations are documented in the source code, close to the deviation occurrence. For each deviation a special macro identifies the relevant rule or directive number, and reason.
This section provides MISRA compliance analysis environment description.
MISRA-C:2012 Guidelines for the use of the C language in critical systems
MISRA Checking Tool
Coverity Static Analysis Tool
The list of deviated required rules is provided in the table below. Advisory rules deviation is not documented, as not required per MISRA specification.
Description of Deviation(s)
The character sequences /* and // shall not be used within a comment.
Using of the special comment symbols is need for Doxygen comment support, it does not have any impact.
Identifiers shall be distinct from macro names.
This rule applies to ISO:C90 standard. PDL conforms to ISO:C99 that does not require this limitation.
Identifiers that define objects or functions with external linkage shall be unique.
During the code analysis, the same source files are compiled multiple times with device-specific options. All object and function identifiers are actually unique for each specific run.
An identifier with external linkage shall have exactly one external definition
Transport functions in DFU core declared as WEAK to enable flexibility and make design extensible. The usage of the WEAK qualifier guarantees that only one definition is used.