Explanatory Note for Directive 1.1

Information about the implementation-defined behavior for Embedded Coder is available in Configure Run-Time Environment Options. Compiler documentation is out of scope.

Manage character set encoding by using the SavedCharacterEncoding model parameter. For additional information, see slCharacterEncoding.

Configure the integer division method in the Model Configuration Parameters dialog box, on the Hardware Implementation pane. For additional information, see Configure Run-Time Environment Options

Embedded Coder generates pragmas when you:

In both instances, you are responsible for documenting the intended use of the pragma. For more information, see Control Data and Function Placement in Memory by Inserting Pragmas.

To enable the generation of bitfields:

If your model uses conversion of one datatype to another, Polyspace Bug Finder might report a violation of Directive 1.1.

Explanatory Note for Directive 3.1

You can link requirements model elements. These links are included in the generated C code to provide traceability from a requirements document, to the model elements, and to the generated code. For additional information, see View Requirements Toolbox Links Associated with Model Elements and View and Link Requirements in Simulink (Requirements Toolbox).

Explanatory Note for Directive 4.1

You can use Polyspace Bug Finder to identify run-time errors and Polyspace Code Prover™ to prove the absence of run-time errors. For information, see:

You can use Simulink Design Verifier to detect design errors at the model level. For more information, see Analyze Models for Design Errors (Simulink Design Verifier).

To handle the overflow violations, see Handle Overflows in Simulink Models (Fixed-Point Designer).

Explanatory Note for Directive 4.3

Embedded Coder does not directly call assembly language code. You can add calls to assembly language functions through S-functions, code replacement libraries, Stateflow, and MATLAB^® blocks. These calls are documented as calls to External C Functions. In these cases, you are responsible for encapsulation.

For additional information, see:

Explanatory Note for Directive 4.6

Embedded Coder provides three options that are compatible with Directive 4.6. You can:

With the first and second options, the generated code can contain integers that are not specified-width, such as, int_T or int in a generated main file or Stateflow counter variable. To replace the integers with specified-width integers, use data type replacement.

If you configure the model to generate AUTOSAR code, Embedded Coder generates code that uses only specified-width integer data types.

For more information, see:

Explanatory Note for Directive 4.11

To satisfy the requirements of this directive, you can “Demonstrate statically that the input parameters can never take invalid values”.

You can use Polyspace Code Prover to analyze parameter ranges and prove the absence of run-time errors caused by out-of-range values. For additional information, see Run Polyspace Analysis on Code Generated with Embedded Coder (Polyspace Code Prover).

Explanatory Note for Rule 2.1

Polyspace Bug Finder might report a violation for user-defined functions from the Stateflow.

Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8

Embedded Coder is configurable to limit the number of characters imposed by the implementation. For additional information, see Maximum identifier length.

To ensure unique names for different types of variables ( such as local scope variables, global scope variables, macros, and so on), implement a naming convention. For additional information, see Model Configuration Parameters: Code Generation Symbols.

In case of long identifiers, it is recommended to use shared utilities. For more information, see Generate Shared Utility Code

Explanatory Note for Rule 8.2

The code generated using Send or Receive blocks inside a Model Reference may contain function declarations without argument names. For example:

typedef struct {
  void *host;
  void (*RecvData)(void *, real_T *, int32_T, int32_T *);
} RecvData_real_T;

Explanatory Note for Rule 8.12

Embedded Coder supports the use of enumerated data. The file used to define the enumeration can be either manually or automatically generated. Files defining enumerations generated by Embedded Coder are compliant with MISRA C:2012 Rule 8.12 by design. If you manually create the definition file, you are responsible for ensuring compliance. For additional information, see Use Enumerated Data in Simulink Models.

Explanatory Note for Rule 9.1

Simulink models configured for support packages like Simulink Support Package for Raspberry Pi^® Hardware, C2000™ Microcontroller Blockset, or such configurations may generate noncompliant code.

Explanatory Note for Rule 10.1, 10.3, and 10.4

Usage of functional mockup units (FMUs) version 1.0 may cause noncompliant code.

Explanatory Note for Rule 11.8

If your model uses any storage class with Const or Volatile qualifiers, Polyspace may show violation of Rule 11.8 from the generated code of the model.

Explanatory Note for Rule 12.2

If the simulation diagnostic reports an overflow from the Simulink model, the code generator may not generate MISRA compliant code.

Explanatory Note for Rule 13.2

Use of volatile variables may result in noncompliant code.

Explanatory Note for Rule 17.3 and 21.2

When the model configuration parameter Leverage target hardware instruction set extensions is set to anything other than None, the generated code may violate MISRA C:2012 rules.

Explanatory Note for Rule 21.1

If Polyspace Bug Finder reports a violation of Rule 21.1, run set_param(model, 'DataTypeReplacement', 'CDataTypesFixedWidth').

Explanatory Note for Rule 21.2

If the length of an identifier exceeds the limit set by Maximum identifier length, Embedded Coder does not expand some tokens, which can result in a leading underscore (_). The resulting identifier is treated as a reserved identifier and can violate MISRA C:2012 rules.

MISRA C:2012 Amendment 2 (AMD2) and Amendment 3 (AMD3) Added to Summary Tables

Since R2024b

The summary table includes the compliance status of MISRA C:2012 Amendment 2 (AMD2) and Amendment 3 (AMD3) guidelines.

MISRA C:2012 Summary Tables Include All Mandatory and Required Categories

Since R2023b

The summary table includes the compliance status of all the Mandatory and Required Category guidelines from MISRA C:2012.