Major Bug Fixes

This document describes major bug fixes in this release.

Real-Time Workshop 5.1.1

Click on a problem area listed below to read how it has been fixed.

Reusable Code Incorrectly Generated for Subsystems with Logical Operator Blocks
Back Propagation of Signal Labels for Test Point Signals
Building Reusable Subsystems with Scalar Complex Outputs
Code Generated for Stateflow Charts
Code Generation and Simulation for Global Tunable Params in Reused Subsystems
Code Reuse for Identical Atomic Subsystems
Custom Code Blocks Can Be Used in S-Function Targets
Declaring Local Variables in Reusable Functions
Fixed Bug in rsimgetrtp Function
Generating Code with Atomic Subsystems
Generating Code with Tunable Parameters
If and Case Block Code Generation
ImportedExtern Mask Variables
Input Expressions for Blocks Having a Discontiguous Input
Long Description Field in Simulink Object Data During Code Generation
Multi-byte Characters in TLC Files Are Processed Correctly
rtw_info_hook Filename Generation
Simulation and Generated Code Results in the Case of Initial Value Conflict

Reusable Code Incorrectly Generated for Subsystems with Logical Operator Blocks

In previous releases, the Operator parameter of the Logical Operator block was incorrectly allowed to be tunable. This caused the Real-Time Workshop to incorrectly generate reusable code for subsystems containing Logical Operator blocks that were identical except that their Logical Operator blocks implemented different logical operations. This release makes the Operator parameter nontunable, thus fixing the problem.

Back Propagation of Signal Labels for Test Point Signals

If a signal is labeled and the Test Point option selected, an attempt to preserve this signal label in the generated code is made. However, this is only true if all of the memory for this signal is contiguous (not a collection of other signals).

If a signal label mismatch occurs for a given signal, only one of the signal labels will be used in the generated code. Also, if there is more than one signal with the same name, the signal labels will not be preserved in the generated code.

Building Reusable Subsystems with Scalar Complex Outputs

A bug in Release 13 caused Real-Time Workshop to fail to build reusable subsystems that had scalar complex outputs. This has been fixed.

Code Generated for Stateflow Charts

The presence of Stateflow charts in a model could have introduced unnecessary subsystem modes into the model, which caused the code generated by Real-Time Workshop to use unnecessary global memory, and to generate unnecessary code. This bug, which was introduced in Release 13 Service Pack 1, has been fixed.

Code Generation and Simulation for Global Tunable Params in Reused Subsystems

In Release 13 Service Pack 1, this issue was causing incorrect generation of reused code for subsystems which are different from each other. This problem, which involves differences in tunable globals between subsystems, could also manifest itself as a segmentation violation in Simulink. This has been fixed.

Code Reuse for Identical Atomic Subsystems

In Release 13, Real-Time Workshop sometimes failed to reuse the code for groups of identical nonvirtual subsystems when the function option was set to 'Reusable function'. This has been fixed.

Custom Code Blocks Can Be Used in S-Function Targets

A regression in Release 13 prevented S-function targets from being generated for models that included custom code blocks. The S-function target now works with custom code blocks.

Declaring Local Variables in Reusable Functions

In Release 13, some local variables were not declared in functions generated for reusable subsystem when output and update not combined. This has been fixed.

Fixed Bug in rsimgetrtp Function

In Release 13, the utility function rsimgetrtp did not correctly handle models in which the Inline Parameters option set was to on when processing the parameters of non-inlined s-functions. The bug caused rsimgetrtp to error out or generate incorrect parameter values data. This bug has been fixed.

Generating Code with Atomic Subsystems

When generating code for a model in Release 13 or R13 Service Pack 1, a segmentation violation may occur for certain configurations of atomic subsystems. The stack trace is shown below. This has been fixed in this release.

Stack Trace:

                                                              
  [0] simulink.dll:struct slBlock_tag * __cdecl LocateSrcInport(struct 
slBlock_tag *,int)(1, 0, 0x1d2d2f38, 0x1cfbfcf0) + 198 bytes  
  [1] simulink.dll:struct slBlock_tag * __cdecl LocateSrcInport(struct 
slBlock_tag *,int)(1, 0, 4, 0) + 280 bytes
  [2] simulink.dll:struct slErrMsg_tag * __cdecl
GenCanonicalInputIds(struct RTWInfo_tag *)(0x00df6688, 0x00df6688, 0,
0x1596a1d8) + 438 bytes
  [3] simulink.dll:struct slErrMsg_tag * __cdecl sleCreateRTWData(struct
RTWInfo_tag *)(0x00df6688, 0x00df6688, 0, 0x1596a1d8) + 895 bytes
  [4] simulink.dll:struct slErrMsg_tag * __cdecl WriteRTWFile(struct
RTWInfo_tag *)(0x1596a1d8, 0x00df67d0, 2, 0x7a8a74e8) + 158 bytes
  [5] simulink.dll:void __cdecl DoRTWGen(struct RTWInfo_tag *,int,struct
mxArray_tag * * const)(0x00df6688, 2, 0x00df680c, 2) + 600 bytes

Generating Code with Tunable Parameters

When generating code for a model in Releae 13 or R13 Service Pack 1, a segmentation violation may occur for certain configurations of tunable parameters. The stack trace is shown below. This has been fixed in this release.

Stack Trace:

                                                            
   [0] simulink.dll:struct slErrMsg_tag * __cdecl
WriteModelParameters(struct RTWInfo_tag *)(0x00df68e0, 0x00df68e0, 0,
0x3d922348) + 1286 bytes
   [1] simulink.dll:struct slErrMsg_tag * __cdecl WriteRTWFile(struct
RTWInfo_tag *)(0x3d922348, 0x00df6a28 "@já", 2, 0x7a8a74e8) + 794 bytes
   [2] simulink.dll:void __cdecl DoRTWGen(struct RTWInfo_tag *,int,struct
mxArray_tag * * const)(0x00df68e0, 2, 0x00df6a64, 2) + 600 bytes
   [3] simulink.dll:_sleRTWGen(2, 0x00df6a64, 9, 0x00df6b2c) + 140 bytes
   [4] simulink.dll:void __cdecl slFullRTWGen(int,struct mxArray_tag * *
const,int,struct mxArray_tag * * const)(2, 0x00df6a64, 9, 0x00df6b2c) + 24
bytes

If and Case Block Code Generation

The If block and Case blocks aborted code generation when the root model has continuous states and has a child subsystem with:

This problem has been fixed.

ImportedExtern Mask Variables

In previous releases, workspace variables that were declared to be 'ImportedExtern' were being inlined into the generated code. This issue arose only in the context of masked blocks in which the mask dialog callback functions were changing the values of mask variables. This has been fixed.

In general, mask dialog callbacks should only be used for changing the visible or enable state of mask dialog fields and should not be employed for changing mask variables.

Input Expressions for Blocks Having a Discontiguous Input

Previously, a block with a discontiguous input could not accept an expression at that input, but would accept expressions at other inports. This led to generating incorrect code in certain rare cases. This problem, which originated in Release 13, has now been fixed, by disallowing a block having any discontiguous input from accepting an expression at any input.

Long Description Field in Simulink Object Data During Code Generation

When a Simulink data object, e.g., Simulink.Parameter or Simulink.Signal, contains very a long string in its description field or user data fields, the Real-Time Workshop code generation process used to trigger a segmentation fault. This problem is now fixed.

Multi-byte Characters in TLC Files Are Processed Correctly

A bug in Release 13 Service Pack 1 caused wrong answers and possibly crashes to occur when multi-byte characters (unicode) were included in TLC scripts. This has been fixed, restoring the correct handling in R13.

rtw_info_hook Filename Generation

In R13SP1, if a user specified additional arguments in the RTW system target file field of the Simulation Parameters dialog, and any of these contained "/" or "\", Real-Time Workshop could derive an incorrect file name. For example, the user input ert.tlc - Isomewhere/somepath caused the incorrect hook file name somepath_rtw_info_hook.m to be generated instead of ert_rtw_info_hook.m. This has been fixed, and arguments for System Target Files may now contain the characters "/" and "\".

Simulation and Generated Code Results in the Case of Initial Value Conflict

The virtual outports of a subsystem could be initialized incorrectly by Release 12 and 13 versions of Real-Time Workshop, causing the initial value of an outport to sometimes be incorrectly overwritten by other operations. This could result in differences between simulation outputs and outputs computed by generated code. This issue has been addressed, and the initial value is no longer being overwritten in cases where it had been previously.

Real-Time Workshop Embedded Coder 3.2.1

Click on a problem area listed below to read how it has been fixed.

Block Reduction for Blocks with Output Signal of Non-Auto Storage Class
Code for the 'Define' Custom Storage Class Now Generated to model_private.h
ERT S-Function Target Supports Logical Tunable Parameters
Fixed Incompatibility Between Block Reduction and Custom Storage Classes
Initial Value of Data Store Memory Is Now Tunable
Parameter Structure Passed In Correctly to Generated Functions
Reduced Blocks That Are Connected to Merge Block Input
Selecting "MAT-file logging" Simultaneously with "External mode" or "Suppress error status"
Subsystem Build When Subsystem I/O Is Fixed-Point and References Simulink.Signal Objects
Type Qualifiers Supported for Data with Custom Storage Class
Warning Message If 'Single output/update function' Is Omitted from System Target File

Block Reduction for Blocks with Output Signal of Non-Auto Storage Class

Block reduction is not performed for blocks that meet the following conditions: (1) the storage class of the output signal is not set to Auto and (2) the width of the signal entering the block's input port at its origin is not equal to the output port width. This fixes a problem where the width of the signal in generated code could differ, depending on whether or not Block reduction was enabled.

Code for the 'Define' Custom Storage Class Now Generated to model_private.h

Previously, the 'Define' Custom Storage Class was generated into model.c, which could lead to uncompilable code. The location is changed to model_private.h to resolve this issue.

ERT S-Function Target Supports Logical Tunable Parameters

Generating an ERT S-function wrapper on a subsystem which contained a tunable parameter of type logical now generates correct code. In R13, code generation for models with tunable parameters of type logical terminated prematurely.

Fixed Incompatibility Between Block Reduction and Custom Storage Classes

Code generation could fail with a segmentation fault when a model simultaneously contained custom storage classes and had the Block reduction option enabled. This problem has been fixed.

Initial Value of Data Store Memory Is Now Tunable

The Initial value parameter of the Data Store Memory block is now a tunable parameter. In previous releases, Initial value was statically initialized and therefore not tunable. This limitation has been removed.

Parameter Structure Passed In Correctly to Generated Functions

The parameter structure was not passed in properly to functions generated by Real-Time Workshop Embedded Coder 3.0. This problem has been fixed.

Reduced Blocks That Are Connected to Merge Block Input

Previously, if a block connected to an input of a Merge block inport is reduced (e.g., removed by Block Reduction optimization), a segmentation fault occurred during code generation. To fix this problem, blocks connected to the inputs of Merge blocks are no longer reduced.

Selecting "MAT-file logging" Simultaneously with "External mode" or "Suppress error status"

Errors could result when the "MAT-file logging" option was selected at the same time as either the "Suppress error status" or "External mode" options. This problem has been fixed.

Subsystem Build When Subsystem I/O Is Fixed-Point and References Simulink.Signal Objects

Code generation could fail when generating code from a subsystem if any of the subsystem's inputs or outputs were if fixed point data type and the signal name referenced a Simulink.Signal object with non-auto storage class. This problem has been fixed.

Type Qualifiers Supported for Data with Custom Storage Class

Compiler warnings could occur when compiling code generated for temporary (local) variables to point to parameters or signals with custom storage class. To fix this problem, an access method was added for custom storage classes that returns the type qualifier (e.g., "const", "volatile" or "const volatile"). This information is used when generating temporary (local) variables to point to parameters or signals that correspond to a particular custom storage class.

This problem has been fixed in Release R13SP1+ but not in release R121pv1.

Warning Message If 'Single output/update function' Is Omitted from System Target File

If the GUI option "Single output/update function" is removed from the system target file of an ERT-based target, the size of the Block I/O data structure can increase significantly in generated code. A warning is now generated if this option is missing. The warning reads as follows:

Warning: Real-Time Workshop: Real-Time Workshop Embedded Coder has detected a malformed system target file: [filename]. The TLC variable CombineOutputUpdateFcns is set to TRUE within the system target file, yet the option 'Single output/update function' is not present in the UI. Without this option present in the UI, non-optimal code is generated. You should correct the system target file to include this important option.

Simulink 5.1.1

Click on a problem area listed below to read how it has been fixed.

Logical Operator Should Not Be Tunable
Alerting Users About Monitoring Unavailable Signals with the Floating Scope
Conditional Branch Optimizations
Dialog Displays Correct Storage Class Setting for Tunable Parameters
Execution Context for For/While Iterator Blocks
Fixed Sorted Order Bug Related to Conditional Execution Context
Function-Call and Action Subsystem Loops
Highlighting a Bus
Inheritance of Execution Context
Masked Subsystems Containing Configurable Subsystems
Multiport Switches
Simulink Debugger No Longer Prints False State Identifiers
Updating Models with Loops
Value Returned for Bus Selector's InputSignals Parameter

Logical Operator Should Not Be Tunable

In previous releases, the Operator parameter of the Logical Operator block is tunable, which violates the semantics of the block and can lead to code generation errors. This release makes the parameter nontunable.

Alerting Users About Monitoring Unavailable Signals with the Floating Scope

A dialog is raised to alert users when signals are unavailable to Floating Scopes and User-Written S-functions. However, the dialog was unwarranted in certain scenarios.

The new behavior is:

Conditional Branch Optimizations

In R13SP1, conditional branch execution optimization was being disabled in subsystems whose RTW System Code was set to Function or Reusable Function. This release enables the optimization for such subsystems.

Dialog Displays Correct Storage Class Setting for Tunable Parameters

In Simulink 5 (R13) and 5.1 (R13SP1), the tunable parameters dialog box sometimes displayed a storage class setting for a tunable parameter that differed from the actual setting. This problem has been fixed.

Execution Context for For/While Iterator Blocks

In R13SP1, execution context propagation may incorrectly change the execution context of a For/While Iterator block. This release fixes the problem.

Fixed Sorted Order Bug Related to Conditional Execution Context

When a block inherits execution context from the input side of a conditionally executed subsystem, if this block's output signal is used by if/case action or function call subsystem, the block was inserted before the subsystem. This bug is fixed; the block is now inserted in front of the if/case or function call subsystem initiator.

Function-Call and Action Subsystem Loops

In the previous release, a loop involving a Function-Call or Action Subsystem and a Merge block resulted in Simulink incorrectly issuing the following warning:

Input data dependency violation due to function-call or action subsystems.

This problem has been fixed.

Highlighting a Bus

In previous releases, highlighting a bus comprising more than 64 signals to its source caused a memory segmentation fault. This problem has been fixed.

Inheritance of Execution Context

In R13SP1, if a source block with constant sample time is connected to a block that has multiple inputs, the latter block can inherit its execution context from other conditionally executed subsystems. For example, if one input port of a Sum block is connected to a Constant block and the other input port is connected to a Triggered Subsystem with Inport IC set to [], the Sum block inherits its execution context from the Triggered Subsystem. This sometimes generated different initial output values than were generated in previous Simulink releases. This has been fixed by not allowing a block connected to a source block with constant sample time to inherit its execution context.

Masked Subsystems Containing Configurable Subsystems

In previous releases, by changing the block choice of a masked system's child configurable subsystem, you could cause a memory segmentation violation. This problem has been fixed.

Multiport Switches

In previous releases, simulating models containing multiport switch blocks having more than 40 input ports could cause memory segmentation faults. This issue has been fixed.

Simulink Debugger No Longer Prints False State Identifiers

In the previous release, the state identifiers in the output of the strace and the state debugger commands were incorrect. This release fixes the problem.

Updating Models with Loops

Some large models with loops and whose datatypes are under-specified could hang during update diagram or simulation during the propagation phase for datatypes. This has been fixed.

Value Returned for Bus Selector's InputSignals Parameter

In R13SP1, the get_param command returned an incorrect value for the Bus Selector's InputSignals parameter for an uncompiled model. This problem has been fixed.

Simulink Performance Tools 1.3.2

Click on a problem area listed below to read how it has been fixed.

Lookup table Coverage
Model Coverage Support for Truth Tables Inside Library Models
Models With RTW-generated S-functions Not in Working Directory Now Can Be Accelerated
Reporting MCDC Coverage for Single Input Logic Blocks
Simulink Accelerator No Longer Fails to Build a Model
Switch Block Coverage and Data Types

Lookup table Coverage

In the previous release, the coverage reported for the ND Lookup table, ND Direct lookup table, and the ND lookup table with prelookup was empty (all zeros) unless decision coverage was also enabled. This problem has been fixed in this release.

Model Coverage Support for Truth Tables Inside Library Models

In previous releases, an error occurred when using the model coverage tool during the simulation of a model that contains library linked Stateflow charts that contain truth tables. This release eliminates the errors and reports coverage correctly.

Models With RTW-generated S-functions Not in Working Directory Now Can Be Accelerated

In previous releases, the accelerator would fail to compile when accelerating a model that contained an RTW-generated S-function if the S- function was not in the pwd. This has been fixed by ensuring that the path for the S-function header file is on the include path for the mex command that controls the accelerator.

Reporting MCDC Coverage for Single Input Logic Blocks

In previous versions of the coverage tool an error was produced whenever a logic block was configured with a single vector input and MCDC coverage was enabled. The new version fixes the problem and correctly reports coverage.

Simulink Accelerator No Longer Fails to Build a Model

Simulink Accelerator failed to build a model and output a error message similar to 'unknown field of struct NonsampledZCs'. This has been fixed.

Switch Block Coverage and Data Types

In earlier versions, the coverage reported for a switch block was not accurate if the switch condition was "u2>thresh" or "u2>=thresh" and the input signal was a data type other than double. In this release the switch block coverage is accurate.

Stateflow 5.1.2

Click on a problem area listed below to read how it has been fixed.

Stateflow Coder License Unnecessarily Checked Out
Data Scaling Property Truncated
Memory Leak No Longer Occurs During Code Generation
Output of Bitwise Operators and mod
Saving Stateflow Models
Stateflow Model Save No Longer Fails When Period (.) Is Part of the Name of the Current Directory Path
Truth Tables Open Properly
Documentation for Nonexistent fixpt and typeof Functions

Stateflow Coder License Unnecessarily Checked Out

In Release 13SP1, simulating a model that contains a Stateflow chart or opening a Stateflow simulation target (sfun) dialog box unnecessarily checks out a Stateflow Coder license. This release fixes the problem.

Data Scaling Property Truncated

In Release 13 and Release 13SP1, Stateflow truncates values entered in the Scaling field of the Data Properties dialog box that have more than 6 significant digits. For example, a Simulink Fixed-Point block computes a slope of 1/204.6 as 0.00488758553275. In Release 13, if you enter 1/204.6 in the Scaling field of Stateflow's Data Properties dialog box, Stateflow computes the value as 0.00488759. If you then attach a Simulink fixed-point signal of slope 1/204.6 to a Stateflow input port that accepts data defined with that slope, you receive a "Data Type Mismatch" error. This release fixes the problem.

Memory Leak No Longer Occurs During Code Generation

Stateflow for R13SP1 introduced a memory leak during code generation. The leak was proportional to the number of data objects in a Stateflow chart (12 bytes per data object).

Output of Bitwise Operators and mod

The bitwise operators (|, ^, &) and mod always produce signed integer outputs even when given unsigned inputs.

An expression (uin32(x) | 1) may produce a negative answer if the top bit of uint32(x) is set even though an unsigned result is expected.

In many cases, an error like this one will be reported at run time during simulation as an overflow error. However, there are situtations in which a negative answer may be obtained and no error reported.

In Real-Time Workshop generated code, assignments of the signed results from a bit operation to unsigned variables will yield the expected unsigned result in the generated code. However, when outputs of bit operations are used in nested expressions, particularly involving relational operators, the results are unpredictable.

This has been fixed.

Saving Stateflow Models

Certain Stateflow charts with several smart transitions caused a fatal MATLAB crash during model save. The model file then became irretrievably corrupted. The crash dump file contained the following stack trace:

Stack Trace:
[0] ntdll.dll:0x77f87e4b(0x30303030, 0x1e49b200 "%s",
0x00df5f1c "10000000000000000000000000000000..", 0x1d8a05b0)
[1] sf.dll:_fprintf_double(0x30303030, 0x30303030, 0x30303030,
0x30303030) + 281 bytes

This bug is now fixed.

Stateflow Model Save No Longer Fails When Period (.) Is Part of the Name of the Current Directory Path

If the path to a model had a directory name that contained a period (.), it was truncated and included only what was before the period when the model was saved. This problem has been fixed.

Truth Tables Open Properly

Stateflow locked an open truth table under different locking conditions, such as simulation. In Stateflow 5.1.1, if the user closed a truth table while it was locked, it was possible for that or another truth table to later open in locked mode outside of locking conditions. Now, whenever a truth table is opened outside of locking conditions, it opens unlocked.

Documentation for Nonexistent fixpt and typeof Functions

Documentation for the nonexistent functions fixpt and typeof had been included in the section on type cast operations. This documentation has been removed.