Code Definition and Mapping Limitations and Considerations

Limitations

If a data element in a model is unnamed (for example, a signal has no label or a state has no name), you must specify a code identifier for the data element when configuring it for C code generation. Set the code identifier by specifying a value for the storage class property Identifier.
You cannot use code mappings to configure MATLAB^® variables that are used as block parameters. Convert the variables to Simulink.Parameter objects in the model workspace. The resulting data objects appear in the Code Mappings editor as model parameters.
Use code mappings to configure only one discrete state per block in a model.
To map these data categories to a storage class defined in an Embedded Coder Dictionary, you must set the storage class property Data Initialization to Dynamic or None:
- Inport
- Outport
- Signals, states, and internal data
- Shared local data stores
You cannot map data categories External parameters and Global data stores. For referenced models you cannot map data, categories Inports and Outports to storage classes that are defined in an Embedded Coder Dictionary.
You cannot map categories of data to:
- Predefined structure-based storage classes, Struct and BitField
- Package storage classes of type FlatStructure or Other that you create by using the Custom Storage Class Designer
If you configure a model to use a code replacement library that includes a data alignment specification, you cannot configure default code mappings that involve storage classes defined in the Embedded Coder Dictionary for that model. For more information, see Data Alignment for Code Replacement.
If a model contains a tunable, nonfinite parameter, for example, with a value of inf:
- The code generator does not apply a specified default parameter mapping. The parameter appears as a field in the default parameter data structure rtP (see Standard Data Structures in the Generated Code).
- You cannot map an individual element to a storage class defined in an Embedded Coder Dictionary. If you do, the code generator returns an error. Choose one of these workarounds:
  - For the individual nonfinite parameter, set the storage class to a value other than Auto or Model default, as described in Configure Parameters for C Code Generation.
  - If only one block uses the variable or object, instead of using the variable or object, specify the nonfinite value directly in the model, in the block parameter.

Default Code Mapping Constraints

Map parameter categories to storage classes that are defined with the Data Initialization property set to Static or None.
If a model includes a reusable subsystem (a subsystem that has the block parameter Function packaging set to Reusable function) that contains a shared local data store, map the category Shared local data stores to a storage class that is defined in the Embedded Coder Dictionary for that model. For more information, see Generate Reentrant Code from Subsystems.
For top and referenced models configured for multi-instance use, map data categories to storage classes that have the Storage Type property set to Structured. See Generate Reentrant Code from Top Models and Generate Reentrant Code from Simulink Function Blocks.
Default code mappings for categories External parameters and Global data stores must be the same for models throughout the model reference hierarchy.
When a model is configured for compact file packaging, you cannot map a data category to a storage class defined with the Data Scope property set to Exported and the Header File property set to a naming rule other than $N.h.
When evaluating storage class settings for variant control variables, the code generator ignores default code mappings. For more information, see Represent Subsystem and Variant Models in Generated Code.

Unresolved Code Definitions

If someone removes the definition for a storage class, function customization template, or memory section from the Embedded Coder Dictionary associated with a model, the Code Mappings editor identifies the definition as Unresolved. For example, this figure shows that the function customization template for execution entry-point functions was removed from the dictionary associated with the model.

To fix the unresolved code definition, do one of the following:

Select a different definition in the Storage Classes, Function Customization Templates, or Memory Sections column.
If you have Embedded Coder^®, replace or add a definition to the Embedded Coder Dictionary. Then, update the mapping.
Consult with someone, such as the system architect for your project, about adding a definition to the Embedded Coder Dictionary. Then, update the mapping.

Model Editing Operations and Individual Data Element Code Mappings

While editing a model in the context of a coder app, you should be aware of the relationship between Simulink^® model editing tools, such as copy and undo, and code mappings. In the context of a coder app, when you perform copy-and-paste or cut-and-paste editing operations within a model, the coder app preserves the code mappings for individual data elements. For example, within a model, if you copy and paste the source block of a signal that is configured with a specific storage class, the pasted version of the signal port retains the same storage class.

While you can use undo and redo operations for editing actions on model data elements, they are unavailable while configuring code mappings. For example, if you delete a state block, and then click Undo, the block reappears in the model canvas and the code configuration for the state reappears in the code mappings. In the Code Mappings editor, if you change the storage class setting for a state from Auto to Model default, and then click Undo, the storage class does not revert to Auto. In this case, the change pertains to the code mapping, not to the model data element.

Storage Classes and Reentrant, Multi-Instance Models and Components

The code that you generate from a model or component (referenced model or subsystem) is multi-instance code if it allows your application to maintain multiple independent instances of the component during execution. For example, you can generate reentrant, multi-instance code from an entire model by setting the model configuration parameter Code interface packaging to Reusable function. For general information about multi-instance models and components, see Code Reuse.

Under some circumstances, applying storage classes can:

Prevent you from generating multi-instance code.
Cause some data elements to appear in the generated code as singletons, which means that each instance of the model or component directly accesses the same shared, global data, creating dependencies between the instances.

To avoid errors and unexpected generation of single-instance code and singleton data, observe the guidelines and limitations below.

Directly Applied Storage Classes

When you apply a storage class directly to a data element (see C Code Generation Configuration for Model Interface Elements):

To generate multi-instance code, you must apply the storage class only to parameter objects, global data stores, shared local data stores, and root-level I/O.
The storage class yields only singleton data.

Storage Classes Applied by Default

When you apply a default storage class (see C Code Generation Configuration for Model Interface Elements):

For these data categories, you can generate only singleton data:
- Model parameters
- External parameters
- Global data stores
- Shared local data stores
For Internal data, you can generate only instance-specific data, which means each instance of the model or component operates on a separate copy of the data. For this category, you must use the example storage class SignalStruct, which appears after preparing a model for code generation with the Quick Start tool. Alternatively, you can create and use your own structured storage class by using an Embedded Coder Dictionary.

For more information, see What Is Reentrant Code? and Choose Storage Class for Controlling Data Representation in Generated Code.

Copy Code Mappings When Converting Subsystems to Referenced Models

You can copy code mappings when you convert a subsystem to a referenced model.

In the Model Reference Conversion Advisor, select Copy code mapping information to the new converted model.
In the MATLAB command window, use the Simulink.SubSystem.convertToModelReference function with the comma-separated pair consisting of 'CopyCodeMappings' and true.

Documentation