Major Bug Fixes for Release 13 with Service Pack 1

• Embedded Target for TI C6000 DSP
• MATLAB Compiler
• MATLAB Link for Code Composer Studio
• Model-Based Calibration Toolbox
• Real-Time Workshop
• Real-Time Workshop Embedded Coder
• SimMechanics
• Simulink
• Stateflow

Embedded Target for TI C6000 DSP

All DSP Blockset Blocks Now Have TLC Files and Generate Code Properly

All blocks in the DSP Blockset now include TLC files and you can generate code for them. Note that blocks that do not include TLC files, such as blocks from other block sets, are not supported by Embedded Target for TI C6000 DSP.

FIR_SYM Block Generates Correct Code and Results

Results from FIR_SYM block generated code block are now reliable. Fixes to the variable initialization for the block solved the problem that existed in the earlier release.

FIR_SYM Block Generates Correct Results Under Non-Zero Initial Conditions and Multichannel Input Mode

Earlier versions of the Embedded Target for TI C6000 DSP returned incorrect answers when you used the FIR_SYM block with non-zero ICs and in multichannel input mode. This bug has been fixed in both simulation and code generation.

Special Characters Allowed in Board Names

The following special characters are now allowed in your CCS board name string. Previously, these characters caused various errors during code generation or may have corrupted your model Real-Time Workshop Options.

, = % | ' " ; :

In particular, one board emulator has a comma in its default board name which caused the problems to occur.

To avoid running into the board name problem, Embedded Target for TIC6000 now replaces the special characters in board names with underscores, before it passes the board name to Real-Time Workshop, preventing the code generation or Real-Time Workshop options problems.

The Embedded Target for TI C6000 already handles spaces (a special, special character), which cause a similar problem. Spaces are replaced by underscores.

MATLAB Compiler

Compiling Callback Routines with Mixed Case Names No Longer Gives Run-Time Errors

In MATLAB Compiler 3.0 (Release 13), compiling callback routines with mixed case names on Windows platforms resulted in run-time errors. This issue has been resolved in the MATLAB Compiler for Release 13 with Service Pack 1.

Compiling the toc Function No Longer Produces Run-Time Errors

In some cases, compiling the toc function with MATLAB Compiler 3.0 (Release 13) would result in a run-time error stating "datenummx not found." This issue has been resolved in Release 13 with Service Pack 1.

MATLAB Link for Code Composer Studio

C5000 Processors Now Represent Character Data Types Correctly

C5000 processors now apply the correct data type mappings to character data types. The corrected mappings are:

1. char--now signed char
2. signed char--now signed char
3. unsigned char--unsigned char

Note that the ASCII conversions remain constrained to values from 0 to 127

Code Composer remains in memory after an Rtdx.Open on illegal channel

Normally, if CCS is invisible and you delete all existing links, the CCS task (cc_app.exe) goes away. Trying to open an illegal RTDX channel seems to prevent CCS from closing. This problem occurs if you try to open an unrecogized RTDX channel. For the RTDX open operation to succeed, the channel must exist in the most recently downloaded version of the program file. If you attempt to open an illegal channel, MATLAB generates a normal error message and you do not encounter problems using the link. However, after you close the link, cc_app.exe remains in memory. To avoid this problem, be sure you have loaded the correct program file and avoid attempts to open illegal channels. If you do open an illegal channel by mistake, start the Microsoft Windows Task Manager and end the process cc_app.exe.

Model-Based Calibration Toolbox

Applying design constraints when no constraints are present

The Constraint Manager dialog in the Design Editor will now work correctly when there are no constraints defined. Previously, pressing OK with no constraints caused an error.

CAGE strategy editor appears off-screen

Selecting "Graphical Strategy Editor" from the Feature menu in CAGE will now bring up the strategy editor on-screen. Previously the diagram for editing appeared partly off-screen.

CAGE table auto-renaming

When tables are created as a result of importing a strategy diagram in CAGE, their names are forced to be unique. This is now done so that the names Table, Table_1, Table_2, etc are created. Previously the names Table, Table_1, Table_1_1, etc were created.

Hiding models in multi-model trade off studies

Hiding a model in a multi-model trade off will now correctly hide that model for every available operating point in that trade off. Previously, only the model for a particular operating point was hidden.

Linked models in CAGE can be used in trade off studies

You can now use models that have other models as inputs in trade off studies in CAGE. Previously, attempting to add these models to a trade off view would cause an error.

Model Browser projects save correctly while other windows are open

In previous versions, projects that were saved while a sub-window such as the Design Editor or Stepwise was open would not save any changes that had been made in these windows. The Model Browser now correctly shuts down any sub-windows to ensure that all data is updated before saving.

Name clashes when importing a variable dictionary

When you import a variable dictionary into CAGE, if there are items with the same name in the current variable dictionary and the imported one you are given the option of over-writing the current ones or renaming the new items. Previously the items were imported, resulting in multiple variables with the same name.

NaN's in exported data appear as "65535" in Excel

You can now correctly export data that contains NaN values into Excel. In previous versions these were converted by Excel to be "65535".

Simultaneously closing the Design Editor and Model Browser causes an error

In previous versions, if you closed the Design Editor and immediately closed the Model Browser while the Design Editor was still closing down, an error occurred. This no longer happens.

Updating of variable dictionary list

When a variable is also an input to a formula and its name is edited, the description of the formula in the variable dictionary's list also updates to correctly show the new name. Previously the old name was displayed until a refresh was forced by performing another action.

Variable ranges for multi-model trade offs

The ranges of variables that are created as part of the process of importing models to multi-model trade off are now set up to be the ranges of the source models. Previously the variable ranges were set to [-1 1].

Real-Time Workshop

Altering Execution Order in Subsystem Copies Caused Segmentation Violation

In Version 5.x, when a subsystem was copied and block execution order was altered in the copy or the original, a segmentation fault could result during code generation. This problem, which was associated with subsystem code reuse, has been fixed.

Block I/O Optimization

In previous releases, there was an inefficiency where sometimes block outputs were incorrectly defined as global rather than local. The code ran slower than necessary, but there were no inaccuracies or noticeable flaws as a result. This did not occur every time; it was dependent on the previous state of an internal register. This issue is fixed, resulting in faster code in cases that were previously problematic.

C++ Compatibility for Stateflow and Real-Time Workshop

C++ source files can now be included in Stateflow custom sources. These C++ source files can also be built by the Stateflow's RTW target. Please see the example "sf_cpp" for more details. In addition, you can now code S-functions in C++. See "sfundemos" and double-click "C++" for more details.

Code for Logic Block with Single Input

In Version 5.x, the code generated for a Logic block with a single vectorized input could needlessly occupy a superfluous for loop. This caused redundant (but still correct) computations. This problem has been fixed.

Code Generation Failure for Relational Operator Block

In Version 5.x, code generation can fail under certain conditions for the Relational Operator and MinMax blocks when expression folding is enabled and input to the Relational Operator block comes from a MinMax block. This has been fixed.

Code Generation for Data Store Memory Blocks

In Version 5.0, some models that contained Data Store Memory blocks could generate code that would not compile. This problem has been fixed.

Code Generation for Wide State Input Signals

In certain block configurations, code generation and acceleration failed when wide state signals were emitted to a block. This could happen, for example, when an exported state port from an Integrator block fed into a Relay block. This was a regression in Version 5.0 and has been fixed.

Code Generation from a Block Whose Output Is Connected to a Subsystem Input

Previously, an error occurred when expression folding was on and code was generated from a model that contained a block whose output was connected to a subsystem input. This problem only occurred for blocks that had expression folding switched off in their TLC file, as was the case for the Delay and Data Store Read blocks. This problem has been fixed.

Data Store Read Block Generates Valid Code When Expression Folding Is Enabled

In Real-Time Workshop, the Data Store Read block could generate invalid code when expression folding was enabled. This has been remedied, by disallowing expression folding for that block.

Discrete States in a For/While Subsystem Reset Correctly

When a block with discrete states, such as a Unit Delay block, was placed in a For or While Iterator Subsytem, the Initial Conditions of the states were not being set when the subsystem was called, in code generated by Real-Time Workshop. This is fixed.

Early Termination of Real-Time Workshop or Stateflow S-Function Builds Issue Fixed

Previously, pressing CTRL-C during a Real-Time Workshop build or Stateflow S-function build rendered the status window inoperable. This is now fixed.

Expression Folding and Selector Blocks

In Version 5.0, with Expression folding on, incorrect code could be generated for a Selector block. This has been fixed.

Generated Code for Switch Blocks with Wide Fixed-Point Inputs

In Version 5.0, a bug caused Switch blocks that received wide input signals containing fixed-point data to compute the entire input vector for each element of output vector in the Real-Time Workshop generated code. The output was correctly computed, but assignments were made redundantly. This inefficiency has been eliminated, so that now the input vector is calculated only once.

Include System Hierarchy Numbers in Identifier Option

In Version 5.0, the Include system hierarchy numbers in Identifier option in the General code appearance options pane was having no effect on code appearance. This has been fixed, so that when the option is checked, identifiers include system hierarchy numbers.

Look-Up Table 2-D Generated Incorrect Code for Repeated Zeros in Breakpoints

If the column breakpoints in a Look-Up Table 2-D block had repeated zeros, Real-Time Workshop would generate incorrect code in some circumstances. This has been corrected. A remaining limitation is that the number and position of zeros cannot change when breakpoints are tuned, or incorrect results will be obtained. To avoid this limitation, do not use repeated zeros in lookup tables when the number or position of zeros could change while the real-time code is running.

Missing Storage Type Qualifier in Generated Code for Data Store Memory Block

In Version 5.0, if RTW Storage Class for a Data Store Memory block was specified as non-Auto, and a non-empty Storage Type Qualifier (e.g., volatile) was entered into its block parameter dialog, the generated code would not contain the specified Storage Type Qualifier. The problem has been fixed in Version 5.1. Now the generated code will contain the correct user input of Storage Class and Type Qualifier in all circumstances.

Multi-instanced Stateflow Library Charts Now Generate Correct Code

Starting Release 12.1, when a Stateflow library chart was instanced more than once in a model, and when that chart has multiple function-call output events, sometimes the generated code would not compile. One workaround, in Version 5.x of Real-Time Workshop, was to set the RTW System Code to Function on the subsystem parameters dialog for each of the connected function-call subsystems. This problem has now been fixed and the workaround is no longer necessary.

Multiport Switch Block Generates Correct Code for Wide Inputs

In earlier releases, under certain conditions a Multiport switch with a scalar control port input and wide vector data inputs would cause code generation to fail. This is fixed.

Name Conflicts Between Multiple Models for Constant Parameters

When code generated from multiple models is integrated together, the names of the variables corresponding to constant parameters in the models can conflict. This problem has been fixed by putting constant parameters into a structure that is (by default) named uniquely for each model.

New -w TLC Command Line Flag to Conserve Memory During Lexical Analysis

To save memory when the Target Language Compiler parses large model.rtw files, you can now redirect the lexical analysis phase to a text window. This feature is controlled by the -w flag on the TLC command line. Doing this prevents large files from being read into memory in one piece.

By default, this windowing feature is on. You can turn windowing off (reverting to the old behavior) by passing -w0 (zero) to TLC. The -w1 TLC command flag turns windowing on.

No Name Clashing of Function-call Arguments of Reusable Subsystems and Global Identifiers

In Version 5.0, it was possible for the names of the function-call arguments of reusable subsystems to clash with one another, as well as with global identifiers. Real-Time Workshop now ensures the names of the arguments are unique with respect to one another and do not duplicate global identifiers.

Non-reusable Functions for Subsystem Library Links No Longer Mangle Function Names Unnecessarily

Previously, a library-reference atomic subsystem with code generation options set to "Function" and "Use Subsystem Name" would use the reference name for all instances. This created symbol clashes that Real-Time Workshop would resolve via inconsistent name mangling, which created tracibility problems. Such subsystems now use their instance name.

Presetting RTWOption Values in a Custom System Target File

In Version 5.0, if you attempted to preset the Common RTW options value from a system target file, sometimes errors resulted and sometimes nothing happened. This was a regression from Version 4.1 and has been fixed.

RTW TLC Clear Out Global TLC Variables After Use

RTW TLC files now clear out relevant global TLC variables as they are done being used during the code generation phase. This reduces TLC memory usage which is helpful in reducing overall memory usage of the MATLAB process. This does not affect the C code that is generated from RTW.

Saturation Characteristics No Longer Required in rtw_info_hook M-files

Version 5.01 of Real-Time Workshop derives C-language implementation information for the current target from "hook files" (<target>_rtw_info_hook.m). In that release, it was necessary to specify information on saturation, as seen in the following code snippet:

 case 'cImplementation'
  
  % specify various C-language information

  value.ShiftRightIntArith   = true;
  value.Float2IntSaturates   = false;
  value.IntPlusIntSaturates  = false;
  value.IntTimesIntSaturates = false;

The Saturation information fields are no longer required. You can therefore simplify this code to:

 case 'cImplementation'
  
  % specify various C-language information
  
  value.ShiftRightIntArith = true;

For more information type 'edit example_rtw_info_hook.m' in MATLAB.

Spaces in TLC Pathnames No Longer Abort Code Generation

In Version 5.x, if a TLC directory's pathname includes a space, Real-Time Workshop code generation can fail due to -I flags being parsed incorrectly. This problem has been fixed.

Subsystem Functions with Incompatible Argument Types in Generated Code

Starting in Version 5.0, an inlined atomic subsystem within a reused atomic subsystem that received a discontinuous input signal could generate code with incompatible types in certain cases. This has been corrected in Version 5.1.

Support for N-d (N > 2) Canonical Parameters

In Version 5.x, when Real-Time Workshop generated code for n-d canonical parameters (e.g., N-D Lookup blocks), only the first two dimensions of the parameter were used to calculate the size of the argument to a reusable function. In rare cases this could prevent such functions from being reusable. This has been fixed, so that all of the dimensions are now used to compute the size of the argument.

TLC Builtin Changes to Support Parameter Sharing with Simulink

To support parameter sharing with Simulink, a new builtin (ISSLPRMREF) has been added to TLC. It returns a Boolean value indicating whether its argument is a reference to a Simulink parameter or not. Using this function can save memory and time during code generation. Here is an example of its usage:

%if !ISSLPRMREF(param.Value) 
%assign param.Value = CAST("Real", param.Value) 
%endif 

In addition, the GENERATE_FORMATTED_VALUE builtin has a new optional third argument, which is a Boolean that controls the expansion of parameters into text. If this argument is true, the parameter will be expanded to raw text before being written to disk.

Note that this will use much more memory than the default (which is FALSE) and would only be needed if the parameter text needs to be processed for some reason before being written to disk.

TLC Compiler Memory Now Released After Code Generation

Memory used by the TLC compiler is now released after code generation. Previously, it had maintained memory caches, which had the effect of reducing available memory after the build.

Tunable Parameters with "context-sensitive" Data Type

As part of our effort to unify our handling of floating-point and fixed- point modeling, the way in which parameter data types are handled has been modified:

• All tunable parameters with unspecified data type (i.e., data type is double) will now be treated as “context-sensitive”. That is, the data type used for these parameters will be determined by their usage in the model.

• All tunable parameters that have a non-double data type will be declared using the specified data type, and a run-time type cast will be added in the generated code as necessary.

• All inlined parameters (not tunable) will be treated as “context- sensitive” (no change).

Backwards Compatibility: It is possible that this change may create backwards compatibility problems, although we are not expecting these to be very frequent or significant.

The most likely problem case is where a tunable double parameter is used in a number of different "contexts" throughout a model. This is not permitted and an error message will be issued. However, it is worth noting that if this case were supported it would always result in the downcasting of parameters; the recommended solution would be for users to specify the parameter's data type to be something other than double in these cases regardless of this change.

Unreachable Disable Function Code for Enabled Subsystems

Starting with Version 5.0, Real-Time Workshop was generating unreachable disable function code for enabled subsystems in single-rate parents. This caused the output of the generated code not to match simulation results. The disable function code for such enabled subsystems is now reachable.

Real-Time Workshop Embedded Coder

ASAP2 File Generation Failure When Using Custom Storage Classes

Failures occurred in ASAP2 file generation when custom storage classes were used in the model. This problem has been fixed.

Block+I/O+OptimizationBlock I/O Optimization

In previous releases, there was an inefficiency where sometimes block outputs were incorrectly defined as global rather than local. The code ran slower than necessary, but there were no inaccuracies or noticeable flaws as a result. This did not occur every time; it was dependent on the previous state of an internal register.

This issue is fixed, resulting in faster code in cases that were previously problematic.

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 Generation Failure with Masked Subsystem Parameters of Non-Auto Storage Class

Code generation failures occurred for models containing masked subsystems with fixed-point parameters having either a custom storage class, or any storage class other than Auto. Such failures occurred when generating the parameter tuning API (see "C API for Parameter Tuning" in the Real-Time Workshop documentation). This problem has been fixed.

Delay Block Code Generation with Expression Folding Enabled

With expression folding enabled, it was possible that the code generated for the Delay block could be invalid. This was a regression from Release 12.1 and has been corrected.

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 bug has been fixed.

Generating ERT S-Function with Parameters Having Custom Storage Class

Starting in Release 12.1, generation of S-functions with the ERT target could fail for models containing parameters with Custom storage class. This problem has been fixed.

Improved Code Generation via Auto-Configuring ERT Targets

Users of the ERT target need to supply a hook file (ert_rtw_info_hook.m) that specifies target-specific properties such as word sizes for standard C data types. If this hook file is not supplied, code generation uses host-based default values for these properties. These defaults will produce code that is correct when executed on the host, but which may produce incorrect results when deployed on the target hardware.

To address this issue and make it easier for you to customize a hook file that is optimized for your target hardware, Real-Time Workshop Embedded Coder now provides three variants of the ERT target. These ERT targets are displayed in the System Target File Browser as:

• RTW Embedded Coder (no auto configuration): This target uses host- based default values as described above.
• RTW Embedded Coder (auto configures for optimized fixed-point code): To optimize for fixed-point code generation, select this target. If no hook file is found during the build process, this target displays a warning message and opens an example hook file (ert_rtw_info_hook.m)into the MATLAB editor. You should customize the target word lengths and C language implementation behavior parameters in this file and save this file, as instructed by the warning message. Note that this target passes in the command 'optimized_fixed_point=1' to the build process, via the 'RTW make command' field of the Simulation Parameters dialog box. This in turn invokes the M-file ert_config_opt.m, which auto-configures the model. You can, if desired, customize the option settings in this file.
• RTW Embedded Coder (auto configures for optimized floating-point code): To optimize for floating-point code generation, select this target. If no hook file is found during the build process, this target displays a warning message and opens an example hook file (ert_rtw_info_hook.m)into the MATLAB editor. You should customize the target word lengths and C language implementation behavior parameters in this file and save this file, as instructed by the warning message. Note that this target passes in the command 'optimized_floating_point=1' to the build process, via the 'RTW make command' field of the Simulation Parameters dialog box. This in turn invokes the M-file ert_config_opt.m, which auto-configures the model. You can, if desired, customize the option settings in this file.

Note that comments in the example ert_rtw_info_hook.m file provide appropriate settings for the following CPUs:

• 32-bit floating-point: Motorola PPC, 683XX, Renesas (Hitachi) SH- 2/SH-3, Renesas (Mitsubishi) M32R, Intel x86
• 32-bit fixed-point: TI C28xx, Infineon Tricore, ARM7
• 16-bit fixed-point: Motorola HC12, Infineon C166, TIC24xx, Renesas (Hitachi) H8S
• 8-bit fixed-point: Motorola HC08

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.

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.

Start Function for Reusable Stateflow Charts

Real-Time Workshop Embedded Coder generated an invalid start function for Stateflow charts in reusable subsystems. Library charts have their start code called before the chart Instance code is run to initialize the pointers. This caused null pointer exception segmentation faults. 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

An access method has been added to custom storage classes to return 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.

Use of Global Variables for Block Outputs

Some block outputs that could have been declared as local variables were defined as global, non-reusable storage. This problem is fixed, improving code efficiency.

SimMechanics

Code Generation When Using lcc

An error occurred when using lcc to compile generated code. This bug is now fixed.

Model Reinitialization After Simulation Errors

Restarting a model that had encountered an error during a previous simulation sometimes led SimMechanics to return warnings and zero results. Starting the model a third time reproduced the errors of the first simulation. This bug is now fixed.

Physical Modeling XML Import for Massless Connectors

Previously, the Physical Modeling XML file import command, import_physmod, failed to generate a SimMechanics model from an XML file containing a massless connector Joint. This bug is now fixed.

Update Diagram Option Fix

After successfully simulating a model and adding a new block that was not connected to the original machine, SimMechanics would sometimes crash when you selected Update Diagram. This bug is now fixed.

Simulink

Accumulator Pattern Output in a Discontiguous Wide Signal

In the previous release, updating a model containing a certain type of block diagram pattern could cause a memory access (SEGV) error. Patterns that could cause this error typically consist of an accumulator pattern (e.g., a two-port Sum block with a feedback through a Unit Delay block) connected directly or indirectly along with other inputs to a Mux block whose output is connected to more than one block requiring contiguous signal input (i.e., blocks that require that all elements of an input signal occupy adjacent locations in memory). This release fixes the problem.

Block Output Buffer Reuse

Under certain scenarios, Simulink 4.0 and later versions reused a block output data buffer when it should not have done so, thus corrupting data and resulting in invalid simulation and code generation results. This problem has been fixed.

Changing a Signal Index

Depending on signals visible, there had been a possibility of corrupting a model by changing the index (the port number) of a signal. The new version fixes all known problems associated with changing the port number (index).

Compiling Models with Inline Parameters Enabled

Compiling certain models with Inline Parameters enabled previously caused segment violations. This release fixes the problem.

Counting of Large Numbers of Time Steps

In Release 5.0 and 5.0.1, either continuous or fixed-step models could miscount steps when start time was large and/or step size was small. After around 10e8 steps, major steps could be skipped or the model could freeze due to a limitation of the timing engine. The current fix increases the threshold for this behavior to at least 10e12 major steps or more. A complete fix is planned for a future release of Simulink.

Direct Look-Up Table and n-D Icon

A fix is included for an icon initialization error in the Direct Look-Up Table, n-D block when the block is configured for column extraction from a 2-D table when the table is an input to the block instead of a block parameter. The error prevented correct simulation of models containing blocks configured as described above.

Early Termination of Real-Time Workshop or Stateflow S-Function Builds Issue Fixed

Previously, pressing CTRL-C during a Real-Time Workshop build or Stateflow S-function build rendered the status window inoperable. This is now fixed.

Fixed rate_transition S-Function

Calling the rate_transition s-function from command line to get checksums used to cause a SEGV. This bug has been fixed.

Hitting Ctrl-S Rapidly Twice In Succession

Previously, there was a chance of causing a segmentation violation in the Simulink model editor by hitting the File/Save accelerator key (Ctrl-S) rapidly twice in succession. This has been fixed.

Inappropriate Bus Warning Message Eliminated

In previous releases, for models with not-loaded-not-visible likbrary link self-modifiable subsystems that contained a bus selector block, Simulink may have generated warning messages like "Warning: Selected signal 'DCM' in TopSS/SS/Bus Selector1' originates from an unconnected source signal entering ..." This has been fixed.

Issue Warnings for Initial Output Changes Due to Conditional Execution

When Constant/Initial Condition/Merge with IC not []/Unit Delay/ Discrete Integrator/Integrator is connected to Outport with IC == [], and the Outport is inside a conditionally executed subsystem (e.g., Triggered, Enable, Trigger and Enable, Function Call, Action) and there's at least one block that inherits Execution Context from the subsystem output port (corresponding to Outport), Simulink may produce different results than previous releases. In this case, you can issue an warning if you have

set_param(model, 'CheckInitialOutput','on')

This parameter is a never saved parameter and is off by default.

The warning message is as follows:

"Warning: The initial output of Outport 'mdintg_ic_warn1/Triggered Subsystem/Out1' is set to [], which is undefined and may produce different results than the previous Simulink releases if 'mdintg_ic_warn1/Triggered Subsystem' is not triggered at t = 0. If you want output port 1 of Subsystem 'mdintg_ic_warn1/Triggered Subsystem' to have the same initial value as the Outport source, 'mdintg_ic_warn1/Triggered Subsystem/Discrete- Time Integrator', please explicitly set this initial output value on 'mdintg_ic_warn1/Triggered Subsystem/Out1'."

Logic Block with Underspecified Data Type

Logic block sometimes froze Simulink during model update if its input or output signals had underspecified data types. This bug has been fixed.

Look-Up Table n-D Spline Interpolation with Linear Extrapolation

A sign error resulting in an incorrect slope calculation for below-range linear extrapolations from a spline-interpolated table has been found and fixed. This only affected spline interpolation/extrapolation results and not the flat or linear interpolation/extrapolation results.

Model Refresh When Scroll Bars Disappear

There was a graphics refresh problem when the scroll bars on a model window disappear and simultaneously cause the display to scroll back to the origin. This could happen under many different circumstances, such as:

• Deleting the bottom-right most block in a model while the window is scrolled over to view it.

• Zoom in on a model until the window scroll bars appear, and then enter a subsystem with window reuse set to on.

The previous work-around was to press Ctrl-D (Edit/Update Diagram).

NaN Input No Longer Freezes Binary Search by a Table Look-Up, n-D Block

A NaN input caused a binary search by a Table Look-Up, n-D block to fail to return on some platforms. This caused Simulink and any code generated by Real-Time Workshop to freeze up with certain C compilers. This release alters the binary search algorithm to return properly when NaN is encountered on IEEE-compliant platforms.

Rate Transition Between 0.1 and 0.3

When transitioning from a block sampled at 0.1 to a block sampled at 0.3 using the Rate Transition block, the following error occurs:

Error reported by S-function 'rate_transition' in block 'untitled/Rate Transition': The sample time of the output port 0.3s must be an integer multiple of the input port sample time 0.1s

This error is fixed.

Rate Transition Block with Complex Signals

A problem with the Rate Transition block, when operating on a complex signal, has been fixed.

Prior to this fix, the Rate Transition block could write into the wrong area of memory when operating on a complex signal. This problem could lead to segmentation faults and other errors.

sfun_nddirectlook Block

Previously, calling the sfun_nddirectlook block from the command line caused a SEGV. This bug has been fixed.

Sign Block Behavior Change

If fixed-point logging is turned on, the Sign block does not do zero crossing detection regardless of whether zero-crossing detection is enabled for the block. This change makes the behavior of the Sign block consistant with that of other fixed-point-capable blocks that do zero- crossing detection.

Unified Blocks No Longer Cause Segmentation Violation

Unified blocks might causes segmentation violations if singnals input to these blocks are discontiguous and the discontiguous signals are also fed into other blocks that require contiguous signals. This has been fixed.

Stateflow

Re-enabling Disabled Link Subsystems Containing Link Stateflow Charts

Errors and model corruptions occurred when a library link for a subsystem containing linked Stateflow charts was disabled and later re-enabled. This is now fixed.

Model Corruptions Due to Self-referential (Circular) Link Charts

Copying and pasting a Stateflow chart from a library model into the same model created intra-library link charts. These links would sometimes turn into self-referential (circular) links causing model corruptions. The creation of these intra-library links is now disabled. Copying a library chart and pasting it into the same library model now creates a copy of the original chart instead of a library link to it.

lcc C Compiler Fixed to Handle Large C Files

Stateflow, by default, relies on the lcc C compiler to compile Stateflow- generated code on a Microsoft Windows-based system. lcc version 2.4.1 MathWorks patch 1.29 corrects a bug encountered when compiling very large C files.

This bug caused large Stateflow models to crash during simulation. The bug in lcc was triggered by the number of relocations in the generated object file. While this number is not directly related to the number of states, models exhibiting this problem usually had more than 500 states and generated C files in excess of 1MB.

If you choose not to upgrade your version of lcc, you can use one of these possible workarounds:

1. Configure Stateflow to use a different C compiler. Use mex -setup from the MATLAB command line to choose another C compiler.

2. Disable debugging. From the target menu select Coder Options and uncheck the debugging check box.

3. Split large charts into multiple smaller charts.

Early Termination of Real-Time Workshop or Stateflow S-Function Builds Issue Fixed

Previously, pressing CTRL-C during a Real-Time Workshop build or Stateflow S-function build rendered the status window inoperable. This is now fixed.

Number of Open Truth Table Editors

In prior versions, the allowed number of open Truth Table editors was unlimited. This allowed users to consume an unlimited amount of memory in opening truth tables.

In Stateflow 5.1.1, the maximum number of simultaneously open Truthtable editors is limited to 6. The oldest open editor is recycled when a seventh Truth Table editor is opened.

Data and Events Parented by Charts Copied by Drag and Drop Are Now Accessible to the Stateflow API

Previously, when a Stateflow chart is copied from one model to another using drag and drop, instead of copy and paste with Ctrl-C/Ctrl-V or menu options, all the data and events parented by the new chart became inaccessible to the Stateflow API. This is fixed in Stateflow 5.1.1.

lcc C Compiler No Longer Crashes with Very Large C Files

By default, Stateflow uses the lcc C compiler to compile Stateflow- generated code on a Microsoft Windows-based system. lcc version 2.4.1 MathWorks patch 1.29 corrects a bug encountered when compiling very large C files.

The bug in lcc was triggered by the number of relocations in the generated object. It caused large Stateflow models to crash during simulation. While the number of relocations was not directly related to the number of states, models exhibiting this problem usually had more than 500 states and generated C files in excess of 1MB.

If you choose not to upgrade your version of lcc, you can use one of these possible workarounds:

• Configure Stateflow to use a different C compiler. Use the mex -setup command in MATLAB to choose another C compiler.

• Disable debugging. From the target menu select Coder Options and uncheck the debugging check box.

• Split large charts into multiple smaller charts.

Disabling a Linked Chart While Editing the Library Chart

Previously, if a library link to a chart was disabled while the source chart was open for editing, the chart did not contain the latest contents (for example, port information) from the source library chart. This could cause a segmentation violation when the model is simulated. This is now fixed.

Custom Code for an RTW Target No Longer Included Multiple Times in Generated Code

Previously, custom code entered for an RTW target for a model was included multiple times in the generated code if the model has linked charts from library models. This is fixed in Stateflow Coder 5.1.1.

Initializing Stateflow Data from Workspace Variables of Logical Type

During RTW code generation, an error occurred during initialization of Stateflow data marked "Initialize from workspace", when the workspace data is of logical type. This is now fixed.

Stateflow Code Generation Works on the Network Directories of Windows NT

Previouly, Stateflow code generation failed on the network directories of Windows NT. This was due to the failure of the underlying call to mkdir to create the code-generation directory. This is now fixed in Stateflow 5.1.1

Models With Linked Library Charts No Longer Load Slowly

Previously, models containing linked library Stateflow charts loaded very slowly. In Stateflow 5.1.1 (Release 13SP1) the associated library models containing the source charts are loaded just-in-time for simulation and editing, resulting in faster load times.

Code Generation Speeded Up

Stateflow code generation has been speeded up so that it is faster than the same code generation in Release 12.1.

One of the changes involved turning off the display of code generation messages.