Major Bug Fixes

• Stateflow
• Stateflow Coder

Stateflow

Assertion Occurred When Address Operator (&) Was Used on Anything Other Than a Single Variable

When the address operator (&) is used on anything other than a single variable, an assertion results during the code generation process. For example, the following transition guard could cause this problem:

[(x>y)&...
&(y>z)]

This error is now detected and results in an error message pointing to the offending transition or state.

Borland 5.6 MEX Compiler Not Supported

Stateflow models do not build if Borland 5.6 is chosen to be the MEX compiler.
You can use Borland Compiler 5.x versions earlier than 5.6 as the MEX compiler for building Stateflow models.

Comment Added to for Loop Resulted in while Loop

When a comment was added to a simple loop that would normally generate a for loop, a while loop resulted.

Errors During RTW Code Generation with Chart Input or Output Data Had "ImportedExternPointer" RTW Storage Class

Stateflow chart input or output data signals now support all different storage class types in RTW code generation.

Fatal Stateflow Model Corruption During Model Save

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.

inf and -inf Were Not Supported as Initial Data Values and in Action Language

Stateflow data can now be initialized using inf or -inf in the Data dialog box or the Model Explorer. In addition, inf and -inf are now supported in Stateflow action language.

Memory Leak Occurred 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).

Memory Leak Occurred During Model Compilation for Models with Library Charts

Using Ctrl-D to compile a Stateflow model without simulating it was causing a memory leak if the model contained any library charts. The size of the leak was proportional to the number of local data in the chart (approximately 4 bytes for every local data contained in the chart + 1 bit per state + 40 bytes overhead).

Multiple Library Charts with New-Line Characters in Their Full Path Name Caused Uncompilable Code for RTW Target

Stateflow models containing multiple instances of library charts whose full path name contained new-line characters caused uncompilable code to be generated for an RTW target.

Out-of-Range Initial Values Were Not Flagged with an Error

Stateflow now checks initial, minimum and maximum values for data to ensure that they will fit in the data type. In addition, chart input data and machine parented data are now checked at run-time for out-of-range violations.

Passing Addresses of Chart Input or Output Data to Custom Code Functions Caused Assertions During RTW Code Generation

The following action langugage statement in a Stateflow transition or state label caused assertions during RTW code generation:

test = sscanf(line_buffer,'S%1x%2x',&type,&length);

where "sscanf" is a custom C-code function and "type" and "length" are chart input data.

Stateflow API Corrupted After Breaking a Library Link.

After breaking a library link in Simulink, the Stateflow API no longer reflected the true hierarhcy of objects in Stateflow.

Stateflow Coder

%% Characters in Stateflow Charts Causes Generation of Uncompilable Code

The character string %% (two successive percent characters)in user comments or in string literals in Stateflow action language caused uncompilable code to be generated for an RTW target. The following example shows both types of possible uses of the character string %% that caused uncompilable code:

/* user comment containing %% */
{
strcpy(str,"a = %%");
}

Calling the abs() Function with a Fixed-Point Argument Produced a Call to the fabs() Function in Generated Code

A call to the abs() function with a fixed-point argument in Stateflow actions produced floating point generated code with a call to the fabs() function for an ert target. This behavior is prohibitive for integer only microcontrollers and is now fixed. For example, the statement

data1=abs(data);

in Stateflow action language, where "data" is sfix16_En3 and "data1" is sfix16_En4, now generates the following code:

data1 = (int16_T)(abs((int32_T)data) << 1);

Former Limitations of RTW Code Reuse Opimization for Stateflow Library Charts

The following limitations were present in Stateflow Version 5.0 for R13 and Stateflow Version 5.1.1 for R13SP1, that are now fixed:

1. Library charts with function call output events did not work
with code reuse.
2. Library charts with data initialized from workspace did not work
with code reuse.
3. Library charts connected to scalar root input ports did not work
with code reuse.

Library charts containing exported graphical functions are not compatible with code reuse because they need to be singly instantiated in order for them to export graphical functions.

Japanese Comments Did Not Propagate Into Generated Code

Japanese comments on state and transition labels now propagate into generated code for the Stateflow diagram.