dSPACE TargetLinkKnownProblemReport

Known Problem Reports for dSPACE
TargetLink
List of TargetLink Problem Reports - Created at: 2014-03-24
1 / 1260
ID:
KPR.2008.07.22.001
Title:
Missing/wrong table entries in A2L file caused by wrong Data

Dictionary output
Last Update: 08 Aug 2008

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The A2L generator may fail to create COM_AXIS entries for
table blocks with more
than one input. This is caused by missing SourceSignal block
variable references
for the second input of table inside the Data Dictionary
Subsystem area.
Workaround: No workaround available.
ID:
KPR.2008.07.28.001
Title:
Initialization of TargetLink Function block failed after model

upgrade

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a subsystem, in a user library, contain a TargetLink Function

block and it is
referenced from more than one location in a model it may
cause the following
Simulink initialization error after the model upgrade:
"TL_Function block (mask) does not have a parameter named
'flp_block'."
Workaround: Close all user libraries after model upgrade or initialize twice.
2 / 1260
ID:
KPR.2008.07.28.002
Title:
Code generation may fail for TargetLink ports after model

upgrade if they're passing a bus signal

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Aborted code generation
Description: Since TargetLink 2.0, i.e. even before special TargetLink

Busports could be
used, it was possible to generate bus signals inside
TargetLink subsystems and
to lead these buses through normal TargetLink ports into inner
subsystems.
Within the TargetLink Inports and the subsequent blocks, the
bus components had
been treated as vector components while the order of the
signal components had
been preserved.
After upgrading the model to TargetLink 3.0 the MIL
simulation works, but the
code generation aborts with the following warnings and errors:
Warning #03130: Inport block is specified to be a non-bus
port, however, it
passes a bus signal.
Error #20160: Subsystem/Bus Selector Selected signal for
Bus Selector outport
1 not found.
Error #20162: Subsystem/Bus Selector The bus signal at the
Busselector block
Bus Selector could not be resolved.
Workaround: Use TargetLink Busports in the model.
ID:
KPR.2008.07.28.004
Title:
Hexadecimal values could not be used for Stateflow objects

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: It is not possible to define values of Stateflow objects as

hexadecimal values
(e.g. 0x0000). In this case a MIL simulation can be run, but
code generation
failed. Futher is it not possible to perform an model upgrade
for such models,
in this case the error E03212 is generated.
Workaround: Use the hex2dec or hex2num functions to convert the
hexadecimal number to
decimal.
3 / 1260
ID:
KPR.2008.07.29.001
Title:
Model upgrade may lead to Simulink crash

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Model upgrade may fail on MATLAB R2006a+, R2006b,

R2007b if the model contains
- a bus input signal which is defined via bus object and
- this bus contains only one signal and
- this signal is selected in a BusSelector block and
- this selected is used in function called system.
Workaround: Add a dummy signal to the bus, feed it with a ground block
4 / 1260
ID:
KPR.2008.07.29.002
Title:
Variable class with RestartFunctionName and Module entry at

interface of incremental or model referenced systems may
lead to double definition of restart function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Incorrect code/not compilable
Description: A model contains a function-call triggered model referenced

system, or an
enabled system that is specified for incremental code
generation.
In the system's Trigger Port or Enable Port, the property
'States when enabling'
is set to 'reset'.
A variable is specified
- to be an actual parameter of the system's Step function,
- or a global interface variable of the system's step function.
Additionally, in it's variable class
- the Module property is set
- and a RestartFunctionName is specified with a name, that
does not contain $S
or $I.
In this case, the specified restart function is generated twice:
One definition is generated for the incremental/referenced
system, and the other
definition for the referencing system.
This leads to a linker error when trying to compile code for the
whole
application.
Please note, that the Model Referencing Block is supported
since TargetLink 3.0.
Workaround: Specify a RestartFunctionName containing $S or $I. Please
note, that the
variable is still initialized in two restart functions. But the
restart
functions do have different names now.
5 / 1260
ID:
KPR.2008.07.29.003
Title:
Boolean data type at the output of Gain, Sum or Product block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: For blocks of type TL_Gain, TL_Sum or TL_Product it is

possible to set a Boolean
output data type using the TargetLink API. The TargetLink
GUI refuses Boolean
data types for the mentioned block types which is the correct
behaviour. An
erroneous data type specification does not result in an error
message of the
TargetLink code generator, but you might obtain large
differences in simulation
results (MIL compared to SIL).
ID:
KPR.2008.07.29.004
Title:
Mask parameter containing arithmetic operators cannot be

resolved in Simulink version above 7.0

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If one value 'X' inside a masked subsystem is defined as mask

parameter and
another value is defined as '-X', these value cannot be
resolved.
For example:
The TargetLink autoscaling tool will fail in this case: If the
upper limit of an
saturation block inside the masked subsystem is defined as
mask parameter and
the lowerlimit is defind as '-upperlimit', these value cannot be
resolved.
tl_resolve('-upperlimit',gcb) crash with
??? Error using ==> slResolve at 57
Can not resolve upperlimit in <MaskSubsystem>
Workaround: Define the second parameter as a mask parameter as well.
6 / 1260
ID:
KPR.2008.07.29.005
Title:
API command 'ddv' cannot be set as initial value of a Constant

block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If a block output or parameter is linked to a Data Dictionary

variable, the
value of that variable is not syncronized with the block settings
automatically.
Therefore the user can use the ddv command to get the
current active Data
Dictionary variable value and set it at the block. Two writings
are allowed:
ddv
ddv('MyDDVariable')
Since TargetLink 3.0 an input like 'ddv' is automatically
replaced by
'ddv('MyDDVariable')' directly in the dialog after entering the
command.
But in constants blocks an input like 'ddv' is not accepted and
the value before
that input is left as value.
Workaround: - Set 'ddv' using API or Property Manager
-- OR -- Set 'ddv(myVarValue)' in the block dialog
The problem is fixed by using the following patches or later
patches:
TargetLink 3.1p6
TargetLink 3.2p1
7 / 1260
ID:
KPR.2008.07.29.006
Title:
Crash when a model with trigger port at root level should be

prepared for TargetLink

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When
- a model (as opposed to a subsystem) should be prepared for
TargetLink,
- a trigger port resides on the root level of the model,
preparation aborts, and the following error message is
displayed in the Matlab
Command Window:
??? Error using ==> tl_check_system>FcnInitSys at 2070
block_diagram does not have a parameter named
'PortConnectivity'.
Error in ==> tl_check_system>FcnCheckSystem at 1502
[bs,bFail,statStruct] = FcnInitSys(options.system,bs,options);
Error in ==> tl_check_system at 248
[bs,msgStruct,options] = FcnCheckSystem(bs,options);
Preparation aborts before any modifications have been
applied to the model.
However, the model may be in compiled state, which must be
terminated manually
by invoking
>> <modelName>([],[],[],'term')
in the MATLAB command window. Otherwise, the model can
neither be closed, nor
modified.
Preparation can either be started with the System Preparation
dialog, or by
invoking the tl_prepare_system tool.
Workaround: 1) Remove (cut) trigger port block before starting preparation.
2) Have model prepared.
3) Re-insert trigger block.
8 / 1260
ID:
KPR.2008.07.29.007
Title:
Error is issued if a referenced model is open in TargetLink's

stand-alone mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The error message as stated below will occur for the following
situation:
1) Switch to TargetLink stand-alone mode
2) Start a simulation for a root model containing a referenced
model or open a
referenced model
Error message:
*** E00000: SETTING SIMULATION MODE SUPERFLUOUS:
*** No TargetLink subsystems in model '<referenced model
name>'!
Warning: Error evaluating 'PostLoadFcn' callback of
block_diagram '<referenced
model name>'. Index exceeds matrix dimensions.
Workaround: Switch to full-featured mode.
ID:
KPR.2008.07.29.008
Title:
Missing bus signal label at BusOutport after model upgrade

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: In the following situation the label of a bus signal is missing

after model
upgrade to TargetLink 3.0:
1) In TargetLink 2.x a bus signal label is definded at the
incoming line of the
bus inport.
2) In TargetLink 2.x the label of the outgoing line is empty, this
means that
the bus label is propagated
If for this bus outport a structure is generated and the
structure name template
is set to $L$R (default setting) the generated code differs to
previous
TargetLink versions. For root level Bus Outports this situation
leads to an
uninitializable model in SIL mode.
Workaround: Set signal labels manually after upgrade.
9 / 1260
ID:
KPR.2008.07.29.009
Title:
Code generation for Stateflow data with scope 'Data Store

Memory' failes with internal error #10007

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink does not support Stateflow data with scope 'Data
Store Memory'.
Normally a regular error message should be thrown, but
currently the following
internal error appears if such a data is inside a TargetLink
subsystem:
Fatal #10007: Internal error. Error code: SF_LoadData 847.
Contact dSPACE's
technical support team.
Workaround: Delete the Stateflow data with scope 'Data Store Memory' or
give them a
different scope.
ID:
KPR.2008.07.29.010
Title:
Erroneous warning #W02295 during MIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: During MIL simulation the following warning

"W02295: The outport signal '1' of block '<name>' is excluded
from overflow
detection, min/max logging and logging in Mil mode. The
reason is either that
the signal is an input to a merge block or it is excluded by the
black list."
occurs erroneously, if the current block
- is an input of a Merge block and should not be logged
-- OR -- is an input of a Merge block and uses floating point data
types
-- OR -- has 'inherit properties' - flag activated.
10 / 1260
ID:
KPR.2008.07.30.002
Title:
Stateflow machine variables are not logged during SIL

simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Stateflow machine variables are not logged during SIL

simulation. The plot
window appears, but there is no signals inside.
ID:
KPR.2008.07.30.004
Title:
Upgrade changes MIL semantics of Rate Limiter block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The TargetLink 3.0 Rate Limiter block is implemented as a

masked Simulink Rate
Limiter block. During the model upgrade the 2.x Rate Limiter
block is replaced
by the new one with Simulink default options. The defaults for
the Sample time
mode is 'inherited' and a Initial condition of 0. The TargetLink
2.x Rate
Limiter block use Sample time mode 'continuous' where no
Initial condition could
be specified. These changes could cause MIL simulation
differences between
TargetLink 2.x and TargetLink3.0. The SIL simulation
correspond to the
'continuous' behaviour.
Workaround: Change the Simulink Sample time option to 'continuous'.
11 / 1260
ID:
KPR.2008.07.30.005
Title:
Inconsistent matrices after upgrade of a Discrete State-Space

block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In TargetLink 2.x is it possible to define empty matrices for the

Discrete
State-Space block. This make sense to define a matrix gain
block. The empty
matrices are set at the Discrete State-Space block during the
model upgrade. The
TargetLink 3.0 Discrete State-Space block is implemented as
masked Simulink
Discrete State-Space block and the matrices are directly
mapped to the Simulink
block. The Simulink Discrete State-Space block accepts no
empty matrices, they
must be defined as matrices of zeros instead. This cause the
following Simulink
initialization error:
Invalid setting in <block name> for parameter <matrix>.
Workaround: Set the empty matrices according the following rules with the
zeros function.
A must be an n-by-n matrix, where n is the number of states.
B must be an n-by-m matrix, where m is the number of inputs.
C must be an r-by-n matrix, where r is the number of outputs.
D must be an r-by-m matrix.
12 / 1260
ID:
KPR.2008.07.30.006
Title:
Wrong dereference in the code if a Stateflow data with scope

'input' has a variable class with scope ref_param or
value_param and 'createinputvariable' is not active

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Normally all TargetLink settings of a Stateflow data with scope

'input' should
be ignored if 'createinputvariable' (Create variable for SF
Input) flag is
inactive. But if that input has a variable class with scope
ref_param or
value_param that class is taken into account for the
dereference generation.
That lead to wrong not compilable code like this:
Ca1_local = *(Sa1_in1); // Sa1_in1 is a global variable
Workaround: Either activate the createinputvariable flag if an extra input
variable with
that scope shall be generated or select an global variable
class for that
Stateflow input data.
ID:
KPR.2008.07.30.007
Title:
Upgrade of a Bitwise Logical Operator from a user library may

fail

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a model contains a Bitwise Logical Operator block from a

user library and the
model upgrade to TargetLink 3.0 is executed with the option to
upgrade related
libraries the error E02012: ERROR IN HOOK FUNCTION
occurs.
Workaround: Change the sequence and upgrade the user library first.
13 / 1260
ID:
KPR.2008.07.30.008
Title:
Erroneous detection of scaling data or signal size mismatch

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a muxed signal should be logged and one of the mux inports
is unconnected or
driven by a Ground block TargetLink issues an error message
which is not
comprehensible:
*** E02291: SCALING DATA/SIGNAL SIZE MISMATCH:
*** A scaling data/signal size mismatch in block <block path>
has been
detected.
*** The block property <property> is a (<n>,1)-vector, but the
compiled
signal size is (<m>,1).
Workaround: Insert a non-virtual block (e.g. a Gain block) between the
muxed signal and the
block to be logged.
14 / 1260
ID:
KPR.2008.07.31.002
Title:
Incomprehensible message about size mismatch

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The output variable of TargetLink's PreLook-Up Index Search

block (type
TL_IndexSearch) has a fixed variable width of two. In the case
that the output
variable is specified by means of an Data Dictionary variable
object a mismatch
between the required and the actual variable width may occur.
If this happens
the messages issued during code generation do not address
this problem directly
and do not help resolving the problem:
Error #6010: //DD0/Pool/Scalings/MyScaling Size mismatch
between variable
'MyVariable' and property 'Offset'.
Error #6010: //DD0/Pool/Scalings/MyScaling Size mismatch
between variable
'MyVariable' and property 'LSB'.
Error #1236:
TheModel/Subsystem/Subsystem/Subsystem/PreLook-Up
Index Search
During the synchronization of block data and referenced
Data Dictionary objects an inconsistency
was detected. See the error messages above for further
information.
Workaround: Use a suitable Data Dictionary variable object.
15 / 1260
ID:
KPR.2008.07.31.003
Title:
Dialog of Prelookup block cannot be open if a break point data

is specified by the workspace variable that does not exist (is
not loaded in MATLAB workspace)
Last Update: 15 Feb 2010

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The dialog of a Prelookup block cannot be opened if

- the value of the break point data of the Prolookup block is
specified by a
workspace or mask variable variable
-- AND -- the workspace/mask variable does not exist in MATLAB
workspace.
Try to open the dialog yields to an error dialog:
"Error evaluating 'OpenFcn' callback of <block>
Output argument "t" (and maybe others) not assigned during
call to
"%DSPACE_ROOT%\matlab\tl\dlg\tl_<block>_dlg.m
(FcnEvalTable)".
Workaround: The workspace/mask variable used as break point data must
be loaded into MATLAB
workspace.
ID:
KPR.2008.07.31.004
Title:
Data Dictionary Manager could be started if the working

directory of MATLAB contains japanese characters

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the working directory contains japanese characters the Data

Dictionary
Manager cannot be started, e. g. with command 'dsddman'.
An error message is issued:
??? Could not get the current directory
??? DDManager calling convention error!!
Workaround: In Windows Explorer remove the characters from the
directory.
16 / 1260
ID:
KPR.2008.07.31.005
Title:
MATLAB may crash if a context menu is opend in an empty

propty value list of the Data Dictionary Manager

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: MATLAB may crash if a context menu is opend in an empty

propty value list of the
Data Dictionary Manager
Workaround: Avoid pressing right mouse button in Data Dictionary Manager
in an empty
property value list.
ID:
KPR.2008.08.01.001
Title:
Creation of a netlist aborts for a system with an AUTOSAR

Client Port block without an inport

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: For systems with an AUTOSAR Client Port block without an

inport creating the
netlist creation leads to the following fatal error:
*** F00000: ERROR DURING NETLIST CREATION:
*** The block identification while netlist creation failed.
*** ERROR:Index exceeds matrix dimensions.
Workaround: Avoid the use of Client Ports without inports.
17 / 1260
ID:
KPR.2008.08.01.002
Title:
Incorrect signal width at TargetLink Inport if 'Inherit properties'

is used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The TargetLink Inport can inherit it's output properties from the
preceding
block's outport. It can be activated by a checkbox in the
dialog.
If the wrong width is defined at the block, before the checkbox
in the dialog is
set, or
if the block is copied and used in another context,
it results in a Simulink error 'Error in port widths or
dimensions'.
Workaround: Set the Simulink property 'Port dimension' to '-1' or specify the
TargetLink
width property correctly before the checkbox is activated.
ID:
KPR.2008.08.01.003
Title:
Wrong AUTOSAR reference for Client/Server- ComSpec elements after Import

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: After import of a CLIENT-COM-SPEC or SERVER-COM-SPEC element the reference path

of the property "OperationRef" at the Data Dictionary ClientComSpec or
ServerComSpec object is invalid. The following error message E08814 will be
thrown:
Message 8814, Kind Warning
Title: Warning
Message:Validation of DD after import failed.
The message was: The object
'/Pool/Autosar/SoftwareComponents/ComponentTypes/UPiActuator/RteEvents/OP_SET_UP
I' contains an invalid reference property. Property: OperationRef
This only occurs if the import will use "PackageSupport" and the referenced
interface is defined in a different package than the software component.
Workaround: Define the interface and the software component in the same AUTOSAR package or
do not use package support.
ID:
KPR.2008.08.01.004
Title:
Wrong scaled parameter variable after deleting of an improper

Data Dictionary Scaling object from a block dialog
18 / 1260
TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Incorrect code/compilable
Description: For specific parameter variables offset values not equal 0 are
not supported.
Therefore in the block dialog for such variables the offset
value cannot be
specified, the field with the offset value is greyed out. In the
context with
this kind of parameter variables the following problem has
been detected:
If the parameter variable is a vector (or a matrix) and in block
dialog for the
parameter variable a Data Dictionary Scaling object is
specified, which defines
an offset value not equal 0 for the elements of the vector after
the deletion of
the Data Dictionary Scaling object from the block dialog the
following problem
occurs ("Same scaling for all" must not be set for the
parameter):
TargetLink 2.x
In the block dialog for all vector elements of the parameter the
offset value 0
is shown, but in the generated code only the first vector
element is scaled with
the offset value 0. All other vector elements are scaled with
the offset value
as previous defined by the Data Dictionary Scaling object.
TargetLink 3.x
In the block dialog for all vector elements of the parameter the
offset values
as previous defined by the Data Dictionary Scaling object are
shown. In the
generated code the vector elements are scaled with this offset
values. In
TargetLink 3.0 this is not only true for vector and matrices, but
also for
scalar parameter variables.
This problem exits for the parameters of the following blocks:
- Rate Limiter: rising slewrate, falling slewrate
- Discrete Filter: numerator, denominator
- Discrete State Space: a-matrix, b-matrix, c-matrix, d-matrix
- Discrete Transfer Fcn: numerator, denominator
Workaround: After the deletion of the Data Dictionary Scaling object from
the block dialog
set the offset values to 0 for the parameter variable via the
TargetLink command
tl_set.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p5
19 / 1260
ID:
KPR.2008.08.01.005
Title:
Optimization: Pattern of Custom Code block with Vector Input

erroneously moved Into Vector Loop

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the code generator option "EfficientVectorHandling" is "on"

(this is the
default setting), then a vector input variable of a custom code
block may lead
to the following erroneous optimization:
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
Sa2_BlockVar[Aux_S32] = Sa2_PredVar[Aux_S32];
}
/* Custom Code <<output code>> */
{
Sa3_CcOut = Sa2_BlockVar[0] + Sa2_BlockVar[3] +
Sa2_BlockVar[9];
}
is replaced by
{
Sa3_CcOut = Sa2_PredVar[Aux_S32][0] +
Sa2_PredVar[Aux_S32][3] +
Sa2_PredVar[Aux_S32][9];
}
}
instead of
{
Sa3_CcOut = Sa2_PredVar[0] + Sa2_PredVar[3] +
Sa2_PredVar[9];
}
i.e. it looks as if the code pattern of a Custom Code block is
erroneously moved
into a loop of a vector copy.
The pattern is called as many times as the number of vector
elements, instead of
only once, the code is wrong but only can compile in rather
extreme special
cases.
The initial vector copy often is the result of a Data Store Read
or TargetLink
Port (or enhanced Simulink port) or if a custom code input
variable has been
created (due to user variable class or due to the model
situation).
20 / 1260
Workaround: - Set Optimization Level 0.

-- OR -- Set EfficientVectorHandling = "off"
-- OR -- By setting a user variable class without set ERASABLE
optimization property
for the vector input variable in question in the Custom Code
block, there will
be a separate input variable that will not be replaced; this can
lead to
inefficient code.
In some cases it is possible to set the variable class of the
block output
vector driving the input to a non-ERASABLE class instead in
order to get more
efficient code.
Other situations may necessitate the use of judicuous use of
variable classes
that are not ERASABLE but MERGEABLE in order to get
correct and optimal code.
ID:
KPR.2008.08.05.002
Title:
Empty body of an exported graphical Stateflow function
Last Update: 24 Oct 2008

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The exported graphical function has an empty body althought

there should be
operations that are defined in the model.
This error occures when there is only one call of the exported
graphical
function by its defining chart and this call is in a dead branch.
The
optimization deletes the function body.
Workaround: The only possible workaround is to locate the function call in
the chart and to
delete it. This is possible because the function call is in a dead
branch.
ID:
KPR.2008.08.05.003
Title:
Building a production code simulation application fails if the

code coverage is activated via the pre_codegen_hook
function
Last Update: 11 May 2012

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
21 / 1260
Description: Apart from (de-)activating the code coverage by setting the

desired code
coverage level in the TargetLink Main Dialog (Options tab), it
is possible to
use the pre_codegen_hook for this purpose.
In the last case the code coverage level can be set by means
of the code
generator option 'CodeCoverageLevel':
tlcgOptions = { ...
tlcgOptions{:} ...
'CodeCoverageLevel',1, ...
};
This code coverage level setting done within the
pre_code_hook function however
ist not taken into account by the production code simulation
frame generator,
which still uses the setting from the TargetLink Main Dialog.
As a result, compilation of the production code simulation
application fails.
Depending on the used compiler and file name errors similiar
to the following
ones are issued:
COMPILING .\Subsystem.c
COMPILING FAILED. See
.\TLSim\codecov_test\HostPC_MSVC\Subsystem.err for
details
Subsystem.c
Subsystem.c(113) : warning C4013: 'TL_CODE_COVERAGE'
undefined; assuming extern
returning int
Subsystem.c(113) : error C2065: 'a' : undeclared identifier
Another result may be an abort of the simulation frame
generation:
*** E00000: INTERNAL ERROR:
*** Internal error. Please contact dSPACE technical support.
*** Code coverage information missing in code generator's
Data
Dictionary output.
*** Related Subsystem object: 'Subsystem'.
Workaround: Set the desired code coverage level in the TargetLink Main
Dialog.
patches:
TargetLink 3.1p7
22 / 1260
ID:
KPR.2008.08.05.004
Title:
Wrong cast in generated code or wrongly optimized code due

to wrong range calculation for Abs block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A wrong range for the Abs block is calculated if an Abs block
has the following
properties:
- No output saturation for the Abs block is selected
-- AND -- the output type of the Abs block is a signed integer
-- AND -- the output type of the predecessor block of the Abs block is
signed integer
-- AND -- the scalings at the Abs block and at its predecessor block
are equal
-- AND -- the offsets of both scalings are zero.
If all these conditons hold, it may lead to incorrect code, if the
input range
of the Abs block (= output range of its predecessor block)
contains negative
values. Due to the wrong range, wrong casts might be
generated or code is
optimized although this is wrong.
For example, an Abs block with the above described
properties is followed by a
saturation block. Then the saturation code to the upper limit
might be removed
by optimization.
Workaround: Specify the output variable for the Abs block to be global or
static.
-- OR -Specify an unsigned data type for the output of the Abs block.
23 / 1260
ID:
KPR.2008.08.07.001
Title:
Code generation fails if trying to merge an axis af a LookUp-Table block

using a custom look-up script with a variable used in an other block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generatoin fails with error #17299 if a user look-up table axis is
merged
with another parameter variable, for example a Gain block parameter,
although
both have identical values and the option "Adapt table values" is
deactivated
for the Look-Up Table block. A message like the following is issued:
Error #17299: speedmap/Look-Up Table: Name ambiguity of identifier
z_table. The
variable was first declared for 'speedmap/Gain'. The variables have fixed
names
but different initialization values.
Workaround: In the custom look-up table script do not use the given blockData.<..>.value
data but read the exact values directly from the block:
i_SetObjectProperties('s2g_glmap1h_s2pt',blockData,cgData.blockHandle);
...
function i_SetObjectProperties(lookupFunctionName,blockData,hBlock)
...
exactInputValue = evalin('base',tl_get(hBlock, 'input.value'));
...
'Value' ,exactInputValue ...
ID:
KPR.2008.08.07.002
Title:
Arbitrary flag of blocks is not updated when scaling is

specified in Data Dictionary Scaling object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
24 / 1260
Description: When an arbitrary LSB is specified though a Data Dictionary

Scaling object which
is referenced by the block, the "arb" flag in the corresponding
block data is
not set correctly.
Example:
A Data Dictionary Scaling object with a property lsb = 0.1 is
referenced
(directly or indirectly via a Variable or a Typedef/Constraints
object) by a
TargetLink block. Due to the fact that the value 0.1 cannot be
represented as a
power of two (2^n) with an integer value for n, it is expected
that the
TargetLink API command tl_get(<block>, 'output.arb') returns
1. But currently it
returns 0.
One conseqence: The "show scaling" command of the
Autoscaling tool yields
scaling labels like "Int16 2^-3.3219" instead of "Int16 0.1".
In TargetLink 3.0, this problem leads also to a wrong display
of the LSB value
in the block dialog. Instead of the correct LSB value, the
nearest value which
can be represented as power of tweo (2^n) with an integer
value for n is
displayed.
Example:
A scaling of 0.1 ist shown as 2^-3 (0.125) in the dialog.
Getting the LSB value
via API command tl_get(<block>, 'output.lsb') returns still the
correct LSB, so
that the TargetLink code generation is not affected by this
problem.
25 / 1260
Workaround: In TargetLink 2.x, the "arb" flag in the block data can be
corrected by entering
the arbitrary LSB value in the entry, pressing ENTER and then
pressing the block
dialog's "Apply" button.
In TargetLink 3.0, the following steps must be performed to
correct the
arbitrary flag:
- Remove the reference to the affected Data Dictionary
Scaling object (Variable,
Typedef with Constraints or Scaling) temporary
- Set the Arbitrary flag in the block dialog manually: The button
near 'LSB:'
must show 'arb'.
- Restore the references to the affacted Data Dictionary
objects (see above).
The same can be done via API commands (example for a
LSB defined by a Data
Dictionary Variable object):
>> myVar = tl_get(<block>, 'output.variable'); % save old
Variable reference
>> tl_set(<block>, 'output.variable', ''); % Remove reference to
Variable object
>> tl_set(<block>, 'output.arb', 1); % Set correct arbitray
flag manually
>> tl_set(<block>, 'output.variable', myVar); % Restore
reference to Variable
object
ID:
KPR.2008.08.07.003
Title:
Optimization may delete a Stateflow if branch

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
26 / 1260
Description: The example below describes the problem with a simple

model. This model contains
one state (FIRST) and two functions (f, g). When the event
"OneEvent" occurs the
data variable is initalized and then the functions f and g are
called.
_________________
| FIRST |<----o
| on OneEvent: |
| data = 1; |
| f(); |
| g(); |
|_________________|
______________________________
|function f |
||
| [in > 5] {data = 3;} |
| o---------->O------------>O |
|______________________________|
______________________________
|function g |
||
| {out = data;} |
| o------------->O |
|______________________________|
The expected production code is (the functions are inlined):
out = 1.;
if(in > 5){
out = 3.;
}
The generated TargetLink code is:
out = 3.;
The problem occurs when a condition is the first operation
after a function
entry. The function is called from a state which calls it by
reacting on an
event. Additionaly the function is only called once.
Workaround: For a right code add an additional dummy operation before
the if branch.
The dummy operation can look like data = data or an
initialization of a new
variable which is not used in the rest of the model so the
optimization removes
it.
___________________________________________
|function f |
||
| {dummy_op;} [in > 5] {data = 3;} |
| o----------->O---------->O------------>O |
|||
|V|
|O|
|___________________________________________|
27 / 1260
ID:
KPR.2008.08.07.004
Title:
Wrong export of AUTOSAR reference path in REAL-LITERAL

node

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The export of an CONSTANT-SPECIFICATION element with

an REAL-LITERAL node
contains a wrong AUTOSAR reference path. The REALLITERAL references an
FLOAT-TYPE by the node TYPE-TREF. The exported
reference path "/autosar/Float64"
is invalid. The correct value was "/autosar/Double".
Example of a wrong REAL-LITERAL:
<REAL-LITERAL>
<SHORT-NAME>DataSenderComspec_0_1</SHORTNAME>
<TYPE-TREF>/autosar/Float64</TYPE-TREF>
<VALUE>1</VALUE>
<REAL-LITERAL>
ID:
KPR.2008.08.07.005
Title:
Inconsistant struct data type component names lead to error

F10008

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the name of a component of a variable object in the Data

Dictionary and the
name of the corresponding data type component are different,
code generation
fails with a fatal error like the following:
Fatal #10008: picontroller/Kp:
Internal error. Error code: TL_StructSymbolServer 1134.
Contact dSPACE's
Workaround: Use always the same name in variable and type object.
28 / 1260
ID:
KPR.2008.08.08.001
Title:
Error #08812 during AUTOSAR export

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The code generation may fail with an error #08812 like the
following:
*** E08812: ERROR DURING AUTOSAR EXPORT:
*** The DD objects
'/Subsystems/<...>/Ports/OutputA/DataSenderComSpec'
and '/Subsystems/<...>/Ports/OutputsB/DataSenderComSpec'
have the same name,
but different values and will be generated only once.
Difference: Objects
/Subsystems/<...>/Ports/OutputsA/DataSenderComSpec and
/Subsystems/<...>/Ports/OutputsB/DataSenderComSpec
differ:
*** Property DataElementRef'A/DataElements/aa' versus
'B/DataElements/bb'.
Workaround: To fix the problem, define different INIT-VALUES for the
COMSPEC nodes of the
defined R/P-PORTs. This will fix the problem, but is not the
sense of an
INIT-VALUE.
ID:
KPR.2008.09.05.001
Title:
Fatal error F99999 (Access violation) due to header include

and external init function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are fulfilled Code generation

fails with an
access violation:
- a subsystem contains an Addfile block specified to include a
header file
-- AND -- the same subsystem contains a Function block with
- a step function which is set to a non-extern function class
-- AND -- an init function which is set to an extern function class
The stack trace shown in the Matlab Command Window and a
Fatal #99999 is issued
by the dSPACE Message Browser.
Workaround: Select an non-external function class for init function.
29 / 1260
ID:
KPR.2008.09.08.001
Title:
A Data Store Read block shows wrong overflow warnings if

the corresponding Data Store Memory block has a bit-field
data type.

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A TargetLink Data Store Read block shows wrong overflow

warning messages during
MIL simulation if the following conditions hold:
- The global logging of the model is set to "log min/maxvalues" (see TargetLink
Main Dialog).
-- AND -- The base type of the Typedef object which is referenced by
the corresponding
TargetLink Data Store Memory block is "Bitfield".
30 / 1260
ID:
KPR.2008.09.08.002
Title:
Implicit sender-receiver communication only supported for

scalar data elements
Last Update: 23 Jul 2009

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A user can set the communication mode for a sender-receiver

communication is a
Runnable Inport block and/or Runnable Outport block. A
selection is only
possible for a data element of a sender-receiver interface with
data semantics
(unqueued data element) that is referenced from a sender port
or receiver port
of a software component. Possible values for the
communication mode are Implicit
or Explicit.
If the selected data element is of complex type (ARRAY-TYPE
or RECORD-TYPE),
TargetLink successfully generates code for the Explicit
communication mode. For
the Implicit communication mode the following error message
will be thrown
during code generation:
Error #17210: swc_Test/ ... /Rte_Function11/Outport:
The return value of a function must be scalar.
Even in non-AUTOSAR code generation process it's not
possible to generate an
ANSI-C function with a pointer type as return value. This is a
limitation of the
TargetLink Code Generator. See also TargetLink Production
Code Generation Guide
> TargetLink Limitations/Code Generation Limitations.
Workaround: Change the communication mode from Implicit to Explicit,
otherwise there is no
workaround available.
31 / 1260
ID:
KPR.2008.09.09.001
Title:
AUTOSAR import write wrong Data Dictionary property "NameTemplate" to

SHARED-CALPRM variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: For every SHARED-CALPRM variable the TargetLink AUTOSAR import generates
a Data
Dictionary Variable object with the variable class AUTOSAR/SHARED_CALPRM.
The
Data Dictionary NameTemplate property will be set to an incorrect value. The
wrong value is "Rte_CData_$(Component)_$D" as described in the AUTOSAR
Modeling
Guide. The correct value is "Rte_SharedCal_$(Component)_$D". As a result the
TargetLink code generator throws a warning simimilar to the the following during
code generation:
Warning #02908: / ... /Variables/Rte_CData_Controller_SharedCal:
The calibratable parameter
'//DD0/Subsystems/controller/rte_controller/Variables/Rte_CData_Controller_Share
dCal'
has not been correctly defined.
For this parameter no AUTOSAR RTE API access function will be generated.
Workaround: To solve the problem set the NameTemplate property of all SHARED-CALPRM
variables to the right value Rte_SharedCal_$(Component)_$D.
32 / 1260
ID:
KPR.2008.09.09.002
Title:
Data Dictionary validation may fail for a Variable object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In TargetLink it is possible to specify a scaling for a Typedef

object via a
Constraints node. This is very helpful if you want to specify
one scaling for a
set of Variable objects, that reference the same user type.
For instance the Scaling object is defined as follows
Scaling_1.ConversionType = LINEAR
Scaling_1.LSB = 2^-1
Scaling_1.Offset = -40
and the Variable object has Value = "-40".
The Data Dictionary validation throws an error message, if the
Variable object
references the Scaling object /Pool/Scalings/VOID_SCALING.
The Variable object
can also reference another Scaling object defined by the user,
that does have an
Offset value greater than -40 to reproduce the same error
message.
The error message looks like this:
Error #06580: TempValueRaw:
The Value property of the Variable object
/Pool/Variables/TemperatureSensor/IRV/TempValueRaw is
not covered by the
associated scaling range [0 65535].
Note that this error is also thrown when trying to generate
code. It is,
however, possible to continue, and the generated code is
correct.
Workaround: In the Variable object set a Scaling object that corresponds to
the settings of
the Constraints child node of theTypedef object.
33 / 1260
ID:
KPR.2008.09.09.003
Title:
Internal error if initial value of Simulink Outport exceeds

Min/Max values of Typdef constraints
Last Update: 12 Apr 2011

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the following situation code generation may abort with an

internal error:
- A block outport "A" references a Typedef object "B" in the
Data Dictionary.
- The Typedef object "B" has a Constraint object "C" which
specifies Min/Max
values.
- The block outport "A" drives a Simulink Outport "D" which is
an outport of a
conditionally executed subsystem (e.g. an enabled
subsystem).
- The Simulink Outport "D" has specified an initial value which
exceeds the
Min/Max values of the Typedef Constraint object "C".
The error message is like the following:
Fatal #10007:
Internal error. Error code: TlCDfaBusVarPropagator 331.
Contact dSPACE's
Workaround: Ensure that the initial value of the Simulink Outport "D" is
within the Min/Max
values of the Typedef Constraint "C".
34 / 1260
ID:
KPR.2008.09.09.004
Title:
Loop detection of Autoscaling tool fails if an event output of a

Stateflow chart is connected to an event input

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Worst-case range calculation and autoscaling fails for a

subsystem if following
contitions hold:
- The subsystem contains a loop where one ore more
Stateflow charts are
involved.
-- AND -- An event output of one of these Stateflow charts is
connected to an event
input of the same Stateflow chart or another Stateflow chart in
the loop.
The error message is
*** F00000: LOOP DETECTION FAILED:
*** The block tracing while loop detection failed.
Workaround: Use a modeling where the events are not used in the loop,
otherwise there is no
35 / 1260
ID:
KPR.2008.09.09.005
Title:
Code generation aborts on a Stateflow variable with nonconform size property

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The value of the Stateflow data object property "size" can be
any expression
which returns a scalar or vector when it is evaluated. One
limitation of
TargetLink demands that the value can be evaluated directly,
e.g. the expression
does not make use of mask or workspace variables nor it
invokes any function.
Internally TargetLink applies STR2NUM to determine the
value of the expression.
If this limitation is not taken into account TargetLink overwrites
the value of
the property "size" with an empty string as soon as new block
data are stored at
the Stateflow object by means of the TargetLink API or the
Property Manager.
Another consequence of violating the limitation appears only
in a TargetLink 3.0
environment. An attempt to generate code aborts with
following error message:
Error #20963: <model>/Chart.<data object>:
The size/dimension of this Stateflow data object (vector with
size 3) does not
match the size/dimension detected by TargetLink (scalar).
Workaround: Use only numerals as value of property size.
36 / 1260
ID:
KPR.2008.09.09.006
Title:
Upgrade deletes non-conform size of Stateflow data object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The value of a Stateflow data object property "size" can be

any expression which
returns a scalar or vector when it is evaluated. One limitation
of TargetLink
demands that the value can be evaluated directly, e.g. the
expression does not
make use of mask or workspace variables nor it invokes any
function. Internally
TargetLink applies STR2NUM to determine the value of the
expression.
If this limitation is not taken into account TargetLink overwrites
the value of
the property "size" with an empty string during the model
upgrade.
Workaround: Use only numerals as value of property size.
37 / 1260
ID:
KPR.2008.09.09.007
Title:
Size of Stateflow variable cannot be set by TargetLink

Property Manager
Last Update: 09 Sep 2010

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The Property Manager offers to change the value of the size
property of a
Stateflow variable but the new value is not accepted. The
error message reads as
follows:
"TargetLink API error: New value for property 'width' has
wrong size, must be
[]!"
It is a fault that the size property (Stateflow) is visible as width
property
(TargetLink) in the Property Manager, because the property
cannot be set and is
not a TargetLink-specific property. During code generation the
size is
determined straight from Stateflow after model initialization,
therefore it is
not needed to have a TargetLink-specific width property.
Furthermore the TargetLink API will provide the width property
which is a fault
too, because it is not needed (see above).
Workaround: The desired value can be set by means of the Stateflow dialog
which opens by
double clicking the object icon in the block explorer pane.
ID:
KPR.2008.09.09.008
Title:
Error #02950 issued, although Runnable port is correctly

connected to a SWC port

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Although a Runnable port block is correctly connected to a

SWC port, code
generation may fail with following error:
Error #02950:
The block must have a direct connection to a Simulink
inport/outport in
TargetLink's runnable subsystem. Only TargetLink and
Simulink ports are allowed
on this signal line. No signal line branches are allowed.
38 / 1260
ID:
KPR.2008.09.09.010
Title:
Wrong name shortening of access function name which

should have a name of more than 31 chars

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Inefficient code/code style
Description: If the option "Code identifiers max. 31 chars" is selected for

every symbol
which name is longer than 31 chars either warning W19001
will be thrown during
code generation or the symbol name will be shortened to a
name of 31 chars if
the name contains the $R, $S or $C macro (name
changeable).
But for an access function with function class' Macro property
set to "off" the
name is always shortened if it is longer than 31 chars and if
the "Code
identifiers max. 31 chars" is selected.
Note:
$R, $S and $C are not supported for access functions so their
name should be
never shortened.
ID:
KPR.2008.09.09.012
Title:
Use of type "unsigned int" in access function instead of a

TargetLink base type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An access function for a vector signal which use an index

parameter to access
the components of the vector signal have the data type
"unsigned int" for the
index parameter, e.g. "Int16 getGainParam(unsigned int
index)". But it should be
a TargetLink base type, e.g. UInt16.
39 / 1260
ID:
KPR.2008.09.11.001
Title:
Wrongly placed preprocessor #endif statement ylieds to noncompilable code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a function is encapsulated by a preprocessor if/endif

statement and its
function class has got PostDefinition-/Declaration statements
that are not
terminated by a linefeed character, then the #endif statement
is misplaced on
the end of the same line as the PostDefinition-/Declaration
statement. This
leads to non-compilable code.
Workaround: Let the PostDefinition-/Declaration statement in the function
class
specification terminate with a linefeed character.
ID:
KPR.2008.09.11.002
Title:
Preprocessor if encapsulation of shared function may lead to

non-compilable code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Some blocks use helper functions within their code pattern
which can be shared
by several TargetLink subsystems. If such a block resides in a
subsystem which
is called by a Preprocessor IF block and in the TargetLink
Main Dialog option
"Share functions between Targetlink subsystems" is activated,
the resulting
preprocessof #if encapsulation of the helper functions's
definition may not be
valid for each TargetLink subsystem which shares the
function. This will lead to
non-compilable production code.
Blocks which can share helper functions are:
- Look-Up Table
- Look-Up Table (2D)
- PreLoop-Up Index Search
- Interpolation (n-D) using PreLook-Up, if "Apply interpolation"
is activated.
40 / 1260
Workaround: Do not use "Share functions between Targetlink subsystems".

Use "Module
Ownership" instead:
1. If at least one of the concerned blocks is not called by a
Preprocessor IF
block (example for a Look-Up table block):
- Create a function class template for Look-Up functions (see
section "Filter
Criteria for the FunctionClassTemplate Object" in online help).
Enter a module
e.g. "SharedLutFunctionModule".
- Place a TargetLink Function block in the corresponding
TargetLink subsystem
and enter "SharedLutFunctionModule" as owned module in
Incremental tab, list of
modules owned by this function.
2. If the concerned blocks are all called by a Preprocessor IF
block and the
resulting preprocessor #if encapsulations are different in the
concerned
TargetLink subsystems:
- Create an additional TargetLink subsystem which
implements only the OR
combination of the preprocessor #if encapsulations of all
concernd TargetLink
subsystems.
- For the additional TargetLink subsystem specify the module
ownership of the
shared function like described in method 1.
41 / 1260
ID:
KPR.2008.09.16.001
Title:
PreLookup Index Search block or Prelookup block may

produce numerically wrong code for the combination of
floating-point input and parameter data type and integer
output (fraction) data type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Using floating-point breakpoint data and a floating-point input

signal, but
fixed-point output (fraction), for the PreLookup Index Search
block and the
Prelookup block (depending on the MATLAB version) a code
pattern is generated
like the following:
fraction = (UInt8) (((x - x_table[0]) / (x_table[1] - x_table[0])) *
256.F);
The example pattern (x - x_table[0]) / (x_table[1] - x_table[0])
can be 1 if an
x value approaches to x_table[1] and this leads to an overflow
for the whole
pattern. In this example the result of the pattern should be 255
(maximum value
of the integer type UInt8), but the cast leads to a result of zero.
Workaround: For floating-point input signals and floating-point breakpoint
data use a
floating-point data type for output (fraction) too.
42 / 1260
ID:
KPR.2008.09.17.001
Title:
Option 'Inherit properties' and Simulink's scalar expansion

may lead to an endless code generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may run in an infinite loop if a MinMax,

Multiport or Switch
block has the 'Inherit properties' option set and Simulink
performs a scalar
expansion of one and more inputs.
Note that Simulink's scalar expansion of inputs takes place
when a block has
multiple inputs and some the inputs are driven by signals with
width greater
than 1 and at least one input is driven by a scalar signal.
Simulink expands
the scalar signal to the width of the other signals.
Workaround: Avoid using 'Inherit properties' with a MinMax, Multiport or
Switch block if
Simulink applies scalar expansion to one of the blocks input
signals.
patches:
TargetLink 2.3.1p2
ID:
KPR.2008.09.23.001
Title:
Missing rescaling at outport of scaling invariant subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an outport of a scaling invariant subsystem drives an

interface specifying
TargetLink OutPort block (TargetLink version < 3.0) or an
enhanced Simulink
Outport (TargetLink version >= 3.0) a missing rescale
operation can lead to
wrong production code.
Workaround: Place a TargetLink InPort (TargetLink version < 3.0) or a
TargetLink Rescaler
Block (TargetLink version >= 3.0) with "Inherit properties"
activated behind the
outport of the scaling invariant subsystem.
43 / 1260
ID:
KPR.2008.09.29.001
Title:
Clearing a system from TargetLink using the Clear System

Dialog sometimes results in Simulink crash

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: When a Simulink model is cleared from TargetLink using

TargetLink's Clear System
dialog, Simulink sometimes produces an access violation.
Afterwards, MATLAB
becomes unstable and must be closed. However, the system
has been cleared
correctly and can be saved prior to closing MATLAB.
The actual reason for this bug is a flaw in Simulink's API.
Workaround: The crash does not come up when the system is cleared
using the tl_clear_system
tool on the command line, as opposed with the GUI (the Clear
System dialog).
There are no caveat to this workaround.
ID:
KPR.2008.09.29.002
Title:
Wrong non-compilable code or a fatal internal error #10008

may caused by a vector/matrix Stateflow data compared to a
single data in a hasChangedTo/hasChangedFrom command

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a single data is used as comparision for a vectorial/matrix

variable in a
"hasChangedTo" or "hasChangedFrom" Stateflow command
like the following example
hasChangedTo(VectorOrMatrixData, CompareData)
an internal error occurs or the generated code can't be
compile because of
unknown variables.
Workaround: Use a complex expression for the comparision.
Example:
hasChangedTo(VectorOrMatrixData, CompareData+0)
44 / 1260
ID:
KPR.2008.09.29.003
Title:
Wrong range data for Sum block after worst-case autoscaling

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Using the Autoscaling tool for calculation of worst-case ranges

of a Sum block,
the calculated range might be infinite [*-Inf *Inf] instead of
finite addition
of input ranges. This results if the output range is calculated
first e.g. as
input of a Product block with infinite range and afterwards the
input ranges are
calculated. The addition should be overwrite the infinite value,
but currently
it does not.
Workaround: Set range manually.
45 / 1260
ID:
KPR.2008.10.01.001
Title:
Wrong Custom Code block negative overflow detection when

input has Int32 data type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For Custom Code blocks whose inputs are scaled with type =
Int32, lsb = 2^0,
offset = 0.0, input overflow detection produces negative
overflow messages
although the input signal is covered by the scaling range. The
message reads
Warning #02202: example/ ... /Subsystem/Custom Code
Block:
Negative overflow at input 1 of block
'example/Subsystem/Subsystem/Subsystem/Custom Code
Block'!
or similar.
The reason for this bug is that the lower limit is generated into
the S-function
code as a constant "-2147483648", for example
const real_T u_LowerLimit[] = {-2147483648};
Unfortunately, this constant is not evaluated as expected by
the MEX compiler.
MSVC compilers, for example, produce a warning C4146. The
unary minus sign is
not applied, and the floating point constant is set to
2147483648.
Workaround: 1. Ignore the overflow message.
2. Patch the custom code S-function code manually:
- open the block's dialog, switch to Code & Logging page,
- push edit S-function button, S-function source file xxx_flp.c
opens
- replace "-2147483648" with -2147483648.0"
- save file, have S-function rebuilt by pushing the Compile Sfunction button.
46 / 1260
ID:
KPR.2008.10.01.002
Title:
Statement like "a = f(...)" is erroneously removed for unused

"a" if function is side effect free

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The TargetLink's optimization removes unnecessary

computations of the form
a = <expression without seide effects>;
Example:
For
a = f(&b);
where b is written to and f() is siede effect free, this removal
takes place
erroneously.
Moreover, for AUTOSAR in explicit mode, when the status
ports of Runnable ports
are shown and not consumed, necessary parts of the
runnable code are eleminated
by optimization.
In some cases, only the empty body of a runnable remains.
Workaround: Several methods are available:
1. (in case of AUTOSAR): Do not show StatusPorts if you do
not use them
2. (in case of AUTOSAR): Lead the StatusPorts to a Rescaler
or TargetLink
Outport with non-ERASABLE output variable
(otherwise): Consume all unused "return value" outports by a
non-ERASABLE
Rescaler oder TargetLink Outport.
3. Adjust the AUTOSAR/RTE_API_FUNCTION function class
to non-SIDE_EFFECT_FREE
and apply method 2 for Rte_Read and Rte_Call calls with
return value and
call-by-ref arguments.
(otherwise/non-AUTOSAR) use a non-SIDE_EFFECT_FREE
function class where
applicable and apply method 2 where not possible
47 / 1260
ID:
KPR.2008.10.01.003
Title:
Code generation aborts if Runnable Inport block is named

"In1"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation of TargetLink AUTOSAR model faild with

Error #02900: mymodel/ ... /In1: Internal error. Contact
dSPACE Support.
because the runnable port block is named with standard
Simulink port block name
"In1" or "Out1".
Workaround: Rename Runnable Inport block
ID:
KPR.2008.10.02.002
Title:
Different signal names in plots when logging bus components

on a Runnable Outport block
Last Update: 15 Dec 2008

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: When logging bus components on of Runnable Outport block

there are different
plot windows open in MIL and in SIL simulation mode. The
names of the logged
signals do not match. In MIL simulation mode the data
element names are shown,
whereas in SIL simulation mode the signal labels are
displayed.
Workaround: Change signal labels to match the data element names.
48 / 1260
ID:
KPR.2008.10.02.003
Title:
Actual parameter of non-side effect free extern function is not

eliminated if the replacement contains a global variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is following code pattern on optimization level 0

int act_param;
act_param = val;
... /* at least one line of code */
foo(act_param);
where foo() is not side effect free and "val" is a variable that
has
non-function-local scope, then "act_param" is not eliminated.
In TargetLink prior to version 2.3, this inefficiency did not
occur, i.e. the
expected code
...
foo(const_val);
was generated for optimization level > 0.
Note that the "at least one line of code" precondition indeed is
essential. If a
function has at least two parameters, then the actual
parameter update
immediately preceding the function call is optimized but all
prior updates are
not.
Workaround: If feasible or correct with respect to the function involved, use
a function
class with Optimization property set to SIDE_EFFECT_FREE.
This is the case if the extern function involved does not
change any global
variables (unknown to TargetLink) or has only internal states
not changed by any
other functions called in the generated code.
49 / 1260
ID:
KPR.2008.10.07.001
Title:
Endless loop during code generation if Constant block with

zero value drives Discrete-Time Integrator

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation for a Discrete-Time Integrator block may run

in endless loop, if
- the signal input of the Discrete-Time Integrator block is
driven by a Constant
block
-- AND -- the value of the Constant block is 0
-- AND -- the variable class specified at the Constant block is default
Workaround: Do not use "default" variable class in Constant block with a
constant value of
0, if it drives a Discrete-Time Integrator block.
ID:
KPR.2008.10.08.001
Title:
The model cannot get initialized for code generation if a

vectorized Runnable port block is driven by Mux block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Given is a Runnable port block which is driven by a vector

signal build by a Mux
block.
During code generation following error may be issued:
*** E02959: RUNNABLE OUTPORT BLOCK MESSAGES:
*** The bus connected to the block does not comply with the
interface
definition of the referenced data element or operation.
***
In this case the muxed signal is structured like a bus and
therefore interpreted
as a bus signal.
Workaround: Use the Gain block with non-optimizable variable to get a
vector variable
-- OR -Build a bus instead of a vector
-- OR -Set Simulink option "Mux blocks used to create bus signals" to
"error" in
Simulation > Configuration Parameters... > Diagnostics >
Connectivity.
50 / 1260
ID:
KPR.2008.10.10.001
Title:
Scope reduction ignores variable's Module property

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Whenever a variable is specified in the Data Dictionary with

non-empty Module
property and the variable has only accesses in another
module's source file,
then the variable is relocated by scope reduction to the other
module's source
file.
This only concerns variables, but not macros or functions for
which the variable
class Module property is correctly evaluated.
In cases where the variable is used in two (or more)
independent code generator
runs, e.g. for incremental code generation or model
referencing, this can lead
to two (or more) "static global" variables instead of one
"global" variable.
Workaround: Use a variable class for the variable that also has the
respective module entry
or use a variable class which Optimization property is not
SCOPE_REDUCIBLE.
51 / 1260
ID:
KPR.2008.10.10.002
Title:
Entries for SynchronousServerCallPoint may be missing in the

exported AUTOSAR software description file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If the client-server communication is modeled within a

runnable subsystem by
means of Client Port or Runnable Inport resp. Runnable
Outport blocks and these
blocks are residing in the subsystem hierarchy of the runnable
subsystem on the
the second level or deeper (see schema below),
Runnable subsystem
|
| -- <FirstLevelSubsystems>
|
| -- <SecondLevelSubsystems>
the corresponing SYNCHRONOUS-SERVER-CALL-POINT
entries are missing below the
RUNNABLE-ENTITY describing the runnable in the exported
AUTOSAR software
description file.
Workaround: No workaround avaliable.
52 / 1260
ID:
KPR.2008.10.11.001
Title:
Stateflow state resolution algorithm may resolve to the wrong

state if there exists more than one state with the same name
in a chart

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: States and whole paths of states can be used in many places
in the Stateflow
action language, for example to increment a data D located in
the state X:
X.D++;
TargetLink may identify the wrong objects if the name/path
contains states/boxes
or functions which names are not unique within the searched
chart.
Example:
Given is the following state hierarchy:
B <Box>
B2 <Box>
X <State>
X <State>
TargetLink may be identifying the B.B2.X and Stateflow takes
B.X as
destintation.
Workaround: Avoid ambiguous state/box and function names.
53 / 1260
ID:
KPR.2008.10.13.001
Title:
Too large scope of global interface variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the following cases interface variables of a subsystem X

may be defined with
global scope although static global would be sufficient:
Case 1: X is inside of a function called triggered TargetLink
subsystem.
Case 2: X is inside of an incremental function call triggered
subsystem.
Case 3: X is inside of an extern called subsystem.
Workaround: Case 1: Do not let the TargetLink Subsystem itself be a
function call triggered
subsystem. Create a wrapper subsystem around the
TargetLink subsystem and let
the wrapper subsystem be function call triggered.
Case 2: Do not let the incremental subsystem itself be a
subsystem. Create a wrapper subsystem around the
incremental subsystem and let
the wrapper subsystem be function call triggered.
Cases 1, 2 and 3: Specify the scope of the interface variables
explicit (by
variable class, for example STATIC_GLOBAL).
ID:
KPR.2008.10.13.002
Title:
The AUTOSAR SWC-D Merge Explorer plugin in the Data

Dictionary Manager cannot be used with AUTOSAR 2.1 and
newer versions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The SWC-Description Merge explorer is not usable with the

new AUTOSAR versions
(2.1 and 3.0). It is not possible to specify import options like
AUTOSAR version
and package support and the default options currently used by
the plugin are no
longer useful.
Workaround: The dsdd_autosar_browser_if.m must be adapted to work with
AUTOSAR 2.1 and 3.0
files. For detailed information contact dSPACE TargetLink
support.
54 / 1260
ID:
KPR.2008.10.13.003
Title:
Infinite loop during code generation if inter-runable variable

communication applied

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Code generation of an AUTOSAR model results in infinite

loop, if
- Runnable port blocks are used for inter-runnable
communication
-- AND -- Runnable Outport block and Runnable Inport reside in
different subsystems, but
on the same level
-- AND -- the Runnable Outport is directly connected to the Runnable
Inport block (only
Simulink ports are passed).
ID:
KPR.2008.10.16.002
Title:
Code generation aborts with fatal error F99999

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The precondition of this aborted code generation is, that one
procedure call is
in a control flow branch which is deleted during code
optimization. A control
flow branch will be deleted when the branch condition can be
evaluated as a
constant value so that it is allways true or false.
To test if this problem occurs in a model generate code with
optimization level
0 and inlining threshold 0. Look in the generated code if there
is a branch with
a procedure call and the branch condition can be evaluated to
a constant value.
Workaround: When a branch condition can be evaluated to a constant value
and the branch
condition is not true, the branch can be deleted in the model
and only the
resulting branch will be used (if or else for true or false).
55 / 1260
ID:
KPR.2008.10.16.003
Title:
Code file name is written in lower case in the TargetLink file header
comment

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The name of a file (code file name) generated by TargetLink is printed
in the
file header comment, e.g.
/*******************************************************************************
*******************\
***
*** Simulink model : WhileDoWhile
*** TargetLink subsystem : WhileDoWhile/Subsystem
*** Codefile : subsystem.c
***
*** Generated by TargetLink, the dSPACE production quality code
generator
*** Generation date: 2008-10-24 11:42:13
[...]
But the name printed in the file header comment is not correctly if the
name
contains upper cases, because the name in the file header comment
is written
only in lower cases.
56 / 1260
ID:
KPR.2008.10.21.001
Title:
TargetLink issues incorrectly warning #17443 about differing

scalings for user look-up table in reused function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: A subsystem is placed in a library. It contains a Function block

with the
checkbox 'Make function reusable' enabled. In the system is a
Look-Up Table
block, and a script file for a custom look-up function has been
written. One of
the Look-Up Table block's variables has a fix name, and no
Data Dictionary
scaling is specified. The reused system is used several times
in a TargetLink
subsystem.
In this case, TargetLink incorrectly issues warning #17443
during code
generation. It does complain about a mergeable variable with
two different
scalings. This is caused by the internal representation of the
scaling objects,
which are different objects but with the same properties.
Therefore the merge
will work and the warning is superfluous.
Workaround: Specify a Data Dictionary scaling for the variable.
ID:
KPR.2008.10.21.002
Title:
Enhanced Look-Up Table (n-D) block is not recognized as

TargetLink block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a model containing a Lookup Table (n-D) block is prepared

for code generation
the Lookup Table (n-D) blocks is not recognized as a valid
block afterwards
despite the fact that it is enhanced. As a result of this
misbehavior most of
the TargetLink tools (Code Generator, Autoscaler, Property
Manager) do not work
properly.
Workaround: The problem does not occur if 1-D or 2-D Look-Up Table
blocks from TargetLink
library are used. If possible, a Lookup Table (n-D) can be
substituted by the
appropriate library block.
57 / 1260
ID:
KPR.2008.10.21.003
Title:
Compiler errors due to wrongly inserted line breaks, multiply

defined struct components and wrongly inserted comment
fragments

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When variable or struct component definitions carry a long

user comment
exceeding the specified line break limit, the code generator
may wrongly
calculate the break position or even insert random code
fragments leading to
uncompilable code.
Workaround: Increase the property line break limit in Main Dialog to a
sufficient value, so
that no break occurs.
58 / 1260
ID:
KPR.2008.10.21.004
Title:
Mapping scaling inheritance may result in errors during code

generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: TargetLink's output.inheritscaling property specifies that the

scaling
parameters of a block are inherited from the outputs of
foregoing blocks. This
feature is only supported if all foregoing blocks are scaled
identically. If
this is not the case, code generation will fail. Moreover, if any
foregoing
block is a Constant whose output.class property is "default",
the Constant's
output has no scaling parameters according to TargetLink's
semantics, which
renders scaling inheritance unfeasible. However, System
Synchronization (called
up stand-alone or during Model Preparation) maps Simulink's
"Inherit via
internal rule" setting to TargetLink's output.inheritscaling
property. This may
result in models for which no code can be generated. The
mapping takes place
when the output scaling parameters are mapped.
Workaround: Write code into tl_map_output_scaling_config.m which maps
Simulink's inheritance
dependant on the block's context - for example, do not map if
it is connected up
with Constants.
59 / 1260
ID:
KPR.2008.10.21.005
Title:
Wrong mask display for Preprocessor IF block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The icon of the Preprocessor IF block should show which

instructions will be
found in the generated code. The displayed expression in the
block icon is
functionally right but not exactly the same as used in the
generated code. It
shows the Simulink expression and not the TargetLink
expression (e.g. in
TargetLink is a # in front of any expression and in Simulink
not).
Workaround: No woraround available. Only the displayed expression in the
block icon is not
exactly the same as in the generated code.
ID:
KPR.2008.10.21.006
Title:
Local Stateflow variables and inputs and outputs of Graphical

Functions are not synchronized

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Local Stateflow variables and inputs and outputs of Stateflow

Graphical
Functions are not considered when Simulink data are
synchronized with
TargetLink's, and vice versa.
Workaround: Apply properties manually.
60 / 1260
ID:
KPR.2008.10.21.007
Title:
A Stateflow object that resides in a subsystem whose library

link is deactivated is not considered during system
synchronization

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: During system synchronization (i.e. when a system is

prepared for TargetLink,
cleared from Targetlink data, or Simulink data are
synchronized with
Targetlink's), blocks and Stateflow objects that can have
Targetlink data are
processed. Blocks are also processed when they reside in a
library block whose
link is deactivated. However, Stateflow objects that reside in
such subsystems
are ignored.
Workaround: Apply data manually.
ID:
KPR.2008.10.21.009
Title:
Property Manager does not show TargetLink blocks or

Stateflow charts below AUTOSAR Client Port block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: AUTOSAR Client Port blocks are derived from the Client Port
block in
TargetLink's AUTOSAR library tl_autosar_lib. The library link
of instances of
this block is broken, which allows to insert TargetLink blocks
and Stateflow
charts inside the Client Port. However, these blocks and
Stateflow objects are
not displayed in the Property Manager.
Workaround: Use the blocks' dialogs to view and modify properties.
61 / 1260
ID:
KPR.2008.10.21.010
Title:
Reset input of Discrete-Time Integrator block is not connected

after opening a model in Stand-alone mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Given is a model containing a Discrete-Time Integrator block

with external reset
input. The Discrete-Time Integrator has an unknown variable
referenced as sample
time. When the model opens the second signal line is no
longer connected with
the second (= reset) input of the Discrete-Time Integrator
block.
The reason is the missing information about the sample time
variable.
Only MATLAB versions previous to R2007a are affected.
Workaround: Define the variable before opening the model.
ID:
KPR.2008.10.21.011
Title:
TargetLink to Simulink conversion writes a wrong value to the

OutDataTypeMode property on MATLAB R2007b and newer

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The TargetLink to Simulink conversion uses the Simulink

property
"OutDataTypeMode" for transferring the TargetLink
inheritance information to
Simulink.
For the TargetLink blocks MinMax, Switch and Multiport
Switch with deactivated
property "inheritscaling", the model conversion should set the
Simulink
OutDataTypeMode property to the value "Inherit via back
propagation".
But in MATLAB R2007b and newer this property has the value
"Inherit via internal
rule" after conversion.
In previous MATLAB versions the behavior is correct.
patches:
TargetLink 2.3.1p2
62 / 1260
ID:
KPR.2008.10.23.001
Title:
The interface validation for a referenced model fails for base

types when module tl_basetypes has been renamed via
module template

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The Data Dictionary interface validation for a referenced

system fails for base
types when module tl_basetypes has been renamed using a
module template.
An error message like the following is issued:
Error #08906:
Data mismatch found. Property BaseTypeRename of typedef
object
/Subsystems/r_AirflowCalculation/mytypes/Typedefs/UInt16
differs from the origin
in the pool area. Do not edit the subsystems area. If you have
edited the
variable class in the pool, run code generation for the
referenced model
r_AirflowCalculation again.
Workaround: Do not use a module template for tl_basetypes.
ID:
KPR.2008.10.27.002
Title:
Code generation aborts for a Discrete Time Integrator block

with fixed-point input and floating-point external initial value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Discrete Time Integrator block is fed by a fixed-point signal

(e.g. Int16
with or without a scaling) and a floating-point (Float32 or
Float64) signal is
applied as the external initial value, code generation aborts
with a fatal
error.
Workaround: Both, input and initial value, must be either fixed-point or
floating-point.
63 / 1260
ID:
KPR.2008.10.27.003
Title:
An Assignment block with parameter "Output(Y)" set to

"Specify required dimensions" is not correctly handled by
TargetLink

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A Simulink model contains an Assignment block with the

setting "Specify required
dimensions" of parameter "Output (Y)". This setting is not
supported by
TargetLink.
When transferring the Simulink block to TargetLink (using
model conversion in
TargetLink 2.x or model preparation in TargetLink 3.x), this
setting is not
handled correctly by TargetLink.
In TargetLink 2.x, the model conversion results in following
error message:
The model <model name> does not comply with Simulink
rules after conversion.
Simulink error messages: Input port 2 of <block path' is not
connected.
In TargetLink 3.x the code generation for the subsystem
containing the affected
block results in the following error message:
Error #20001: <block path> The number of inports/outports
does not fit the
detected block.
Both error messages don't lead to the real reason of the
problem.
Workaround: Due to the fact that the setting "Specify required dimensions"
for parameter
"Output(Y)" is not supported by TargetLink do not use this
setting in Simulink.
64 / 1260
ID:
KPR.2008.10.27.004
Title:
Output of Discrete-Time Integrator block not saturated in

stand-alone mode if only one limit is infinite

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Output signal of Discrete-Time Integrator block is not

saturated in TargetLink
Blockset stand-alone mode if
- upper limit contains a saturation limit less inifinity and lower
limit is
infinite (-Inf)
-- OR -- lower limit contains a saturation limit greater than minus
infinity and upper
limit is infinite (Inf).
ID:
KPR.2008.10.27.005
Title:
Scaling invariance combined with pointer to struct results in

incorrect production code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are fulfilled an actual output

parameter of a
subsystem gets a wrong scaling which results in wrong
production code:
- A subsystem outport X is mapped to a component of a
CallByReference structure
-- AND -- X is specified to be scaling invariant.
The mistake is that actual output parameter gets the scaling of
the formal
parameter and not the scaling which is defined by the scaling
propagation
function.
For details see the following chapters in the TargetLink
Advanced Practices
Guide:
- Defining the Representation of Buses in the Production Code
- Scaling-invariant Functions
65 / 1260
ID:
KPR.2008.11.06.001
Title:
Code generation aborts with fatal error F10007 issued by

TlCNameMacroAnalysis

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In TargetLink it is allowed to have a TargetLink OutPort not on

the topmost
level of a TargetLink subsystem. For incremental subsystems
this is not allowed.
An appropriate error message is thrown if code is generated
for such an invalid
incremental subsystem if its inside the current. But if code is
generated for
the invalid incremental system itself a fatal internal error is
issued (the
number behind the TlCNameMacroAnalysis may vary):
Fatal #10007:
Internal error. Error code: TlCNameMacroAnalysis 292.
Contact dSPACE's technical
support team.
Workaround: Always use TargetLink OutPorts on the topmost level of
incremental subsystems.
ID:
KPR.2008.11.12.001
Title:
Not compilable code due to missing definition of interface

variable of referenced model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is a variable (e.g. "my_param") at the interface of a

referenced model. It
has global scope and at the same time it is used (implicitly or
explicitly) as
an actual parameter of a nested function's interface (call-byreference or
call-by-value) inside the referenced model. The code
generator wrongly resolves
the name of this actual parameter to "my_param_a" (or
similar). This leads to a
compiler error, because the wrongly resolved variable does
not exist in the
generated code.
Workaround: Avoid reusing a global interface variable of a referenced
model as a parameter
of a call-by-reference or call-by-value interface.
66 / 1260
ID:
KPR.2008.11.12.002
Title:
Spurious warning #03409 at Outport during autoscaling with

simulated ranges

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Since TargetLink 3.0 the TargetLink OutPort block is merged

with the Simulink
Outport block. Therefore the new Outport block does not have
an output anymore,
but simulated ranges are stored at the output structure of the
internal
variable. No output means, that the block itself has no
outgoing signal line,
because connections are done on the subsystem's border one
model hierarchy
above. Although the Outport has not output, the simulation
data is fetched from
connector of the subsystem which corresponds to the Outport
block. The data used
for autoscaling is not handled correctly.
Autoscaling of the Outport block with simulated ranges results
in a warning
#030409 with the information that autoscaling is not possible
for the outport
due to missing ranges, e.g.
Warning #03409: OutPort:
Autoscaling is not possible, because at least one port has no
ranges.
In spite of this warning the outport is scaled correctly via
inheritance, if the
driving block of this Outport was scaled, too. But, if the driving
block was not
handled during autoscaling, the Outport block might also be
unscaled.
Workaround: Make sure that the driving block is also handled during
autoscaling with
simulated ranges. In this case the scalings are propagated to
the Outport by
inheritance.
67 / 1260
ID:
KPR.2008.11.12.003
Title:
Clear system of Bitwise Logical Operator block fails

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: When a model that contains a tlsamples-based Bitwise

Logical Operator blocks
with more than one input port is cleared from TargetLink, the
Bitwise Logical
Operator block is replaced by a Simulink Bitwise Operator
block with one input
port only. Because of the missing input ports, the block is
unconnected.
Beginning with TargetLink 3.1, the Bitwise Operator is natively
supported, thus
this problem cannot come up.
Workaround: Edit the block manually after having cleared the model.
68 / 1260
ID:
KPR.2008.11.12.004
Title:
Subsystem extraction creates a TargetLink subsystem for which code generation is

not possible

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The following conditions must be fulfilled to generate production code for a
referenced model:
1. The referenced model must reside within a TargetLink subsystem
2. The TargetLink subsystem must reside in a Simulinik model containing a
TargetLink Main Dialog, which is called root model in the description below.
The root model as described above can be created automatically for a specified
referenced model by using one of the following methods:
1. The Model Referencing Control Center (File distribution/Export for
integration)
2. The TargetLink API function tl_distribute_refmodel_files
3. The TargetLink API function tl_extract_subsystem
If one of these methods is used, TargetLink creates a new model with one
TargetLink subsystem containing the "ModelReference" block referencing the
required model.
However the names of the created TargetLink subsystem and the
"ModelReference"
blocks are identical. If in the next step a user disables the model reference
an tries to created the production code for the resulting incremental subsystem
an error message similar to this one appears:
*** E02067: TL SUBSYSTEM NAMES/IDS MUST BE UNIQUE:
*** The names of the systems that the production code
*** is to be generated for must be unique.
*** This condition does not apply for the following systems
*** configurated for the incremental code generation or for referenced
models:
***
r_FuelCalculation_Dev/ref_r_FuelCalculation/Subsystem/ref_r_FuelCalculation
(Name: ref_r_FuelCalculation)
***
r_FuelCalculation_Dev/ref_r_FuelCalculation/Subsystem/ref_r_FuelCalculation/ref_
r_FuelCalculation (Name: ref_r_FuelCalculation)
PRODUCTION CODE GENERATION FAILED
Workaround: If you have used Model Referencing Control Center or the TargetLink API function
tl_distribute_refmodel_files to created a root model for the specified
referenced model, make the names of the TargetLink subsystem und
"ModelReference" block residing inside this TargetLink subsystem unique.
If you have used the TargetLink API function tl_extract_subsystem, specify a
different name for the TargetLink subsystem. This can be done via the
tl_extract_subsystem parameter "DestBlock":
>> tl_extract_subsystem('DestBlock' <Destination subsystem path>);
69 / 1260
ID:
KPR.2008.11.13.001
Title:
Wrong code caused by missing update operations after

Assignment blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For the Assignment block wrong code may be generated

caused by missing update
operations after the block code.
The problem occurs in the following situations:
1. Assignment block drives Merge block.
2. Assignment block has variable class with local or static
global scope and
drives an inport of a function call triggered subsystem.
3. Assignment block drives a part of a vectorized block input
for which
optimized vector code is generated.
4. Assignment block drives a Simulink Inport/Outport which is
not in unit with a
TargetLink Inport/Outport (TargetLink versions prior 3.0) or not
enhanced
(TargetLink versions since 3.0).
The missing update operations are the following:
1. Missing update of the Merge block's variable.
2. Missing update of the input variable of the function call
triggered
subsystem.
3. Missing update of an auxiliary variable necessary for the
creation of
optimized vector code.
4. Missing update of the interface variable for the succeeding
Simulink
Inport/Outport.
Workaround: Insert a Gain block with gain factor 1 after Assignment blocks
in situations as
described above.
patches:
TargetLink 2.3.1p1
70 / 1260
ID:
KPR.2008.11.26.001
Title:
In the dialog of the Gain block the option "Scalar" is always

deselected and the option "Scalar expansion" may not be
changed

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The option "Scalar" in the dialog of the Gain block is always
deselected. A
click to select the option won't select the option.
If the Gain tab of the block dialog is visible and the property of
the option
"Scalar" is 0 (gain.scalar = 0) then the first click on the
checkbox sets the
property to 1 (gain.scalar = 1), but the option is still shown as
deselected. If
the property gain.scalar is set to 1, the option "Scalar
expansion" must be
deselected automatically, but this is not the case on the Gain
tab. Therefore
the option "Scalar expansion" seems to be selected, but the
option cannot be
changed anymore.
It is only a problem of the graphical user interface of the block
dialog. The
properties of the block, which can be accessed directly by the
API, can still be
used.
Workaround: To deselect the option "Scalar" use the API function
tl_set(<block>,
'gain.scalar', 0), where <block> is the handle of the Gain
block.
71 / 1260
ID:
KPR.2008.11.26.002
Title:
Warning #31406 about empty range intersection in saturation

optimization might be erroneously issued

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Warning #31406 ("The outport signal of block <Blockpath> is

the inport signal of
block <BlockpathToSaturationBlock> and both are saturated.
The intersection of
their output ranges is empty") is erroneously emitted if
- A Saturation block is used,
- whose upper limit is <= 0.0
-- AND -- no saturation of the lower limit is demanded.
-- AND -- The predecessor of the Saturation block demands either no
saturation at all or
no saturation of the lower limit.
Workaround: This warning can only be avoided by setting of at least one
lower limit for
saturation, which might not be intended, or by setting the
OptimizationLevel to
0. Otherwise ignore the warning if it's issued erroneously.
72 / 1260
ID:
KPR.2008.11.26.003
Title:
Adapting an object name in Data Dictionary Manager may

result in an abort when the related model contains a Custom
Code block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: In the Data Dictionary Navigator pane of the Data Dictionary

Manager exist a
context menu with the two menu entries 'Rename and adapt'
and 'Move and adapt'.
If there is a Custom Code block in the model the underlying
script may fail with
a message similar to the following:
??? Reference to non-existent field 'input'.
Error in ==> tl_adapt_dd_references at 169
for indVecBlockVar = 1:length(blockData.(ddRefField{1})),
Besides to 'input' there are the fields 'output', 'param', 'state',
'work' on
which this problem may occur.
Workaround: There a two solution given:
- Adapt the Data Dictionary reference in the model manually.
- Enter temporally in the Custom Code block values for all
interface variables
for states, parameters and work variables. Adapt the Data
Dictionary object and
remove the temporally entered interface variables afterwards.
Note: You can find Custom Code blocks via find_system e. g.
customCodeBlocks = find_system(tl_get_current_model,
'LookUnderMasks','on',
'MaskType', 'TL_CustomCode');
patches:
TargetLink 3.1p9
73 / 1260
ID:
KPR.2008.11.26.004
Title:
System Checker scales poorly for specific use case

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The System Checker is called up before code is generated,

when a system is
prepared for or cleared from Targetlink, and when Simulink
data are mapped to
TargetLink, or vice versa (System Synchronization).
The System Checker scales poorly for the following use
cases:
- The model or subsystem that should be processed contains
a library subsystem
block whose link is deactivated,
- This subsystem contains many (> 1000) blocks of which
many (> 200) have an
active library link.
The System Checker may need up to several minutes to
process the system. After
the library link has been restored, processing takes in the
range of some
seconds.
Workaround: Avoid deactivated library links.
ID:
KPR.2008.11.26.005
Title:
Incorrect code if a value is assigned to a variable via an

inlined function and via an assignment

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
74 / 1260
Description: Consider this code pattern created for a Stateflow loop

a = 0;
while (cond && (a == 0)) {
...
foo(&a) /* foo() contains "a = 1" */
}
the second part of the while loop continuation condition might
be erroneously
optimized after inlining
a = 0;
while (cond && 1) { /* Or, for newer TL versions, "while (cond)"
*/
...
a = 1;
...
}
This code pattern can be generated directly e.g. by using For
Iterator or While
Iterator subsystems or by modeling a graphical function f() in
Stateflow and can
also come up, if inside a loop modeled in a state chart there is
a transition
segment that
- is executed for different control flow paths
-- AND -- carries an assignment to a local variable; local in this case is
the return
value of a graphical function inside this graphical function or a
variable that
has a TargetLink variable class that makes it effectively local.
In general, the problem described above can always come up,
if
- a variable has a defintion (i.e. a value is assigned to it) using
an inlined
function
-- AND -- an additional assignment (a = 0 in the example above)
-- AND -- the variable has a use (a == 0 in the example above).
In these cases the defintion of the variable via the inlined
function will be
ignored.
That is the reason why the condition (a == 0) is removed in
the example above,
since the only definition left was the initial assignement (a =
0).
If there was no inital assignment, TargetLink would lose the
definition in the
inlined functions as well, but that would mean that TargetLink
would not find a
definition for "a" at all and would use the type range of "a"
which might lead
to inefficient but never to incorrect code.
75 / 1260
Workaround: - Change the scope of the variable in question ("a" in the

example above) to
global or static local scope
- If modeled in Stateflow, do not use shared transition
segments for mutually
exclusive control flow paths
patches:
TargetLink 3.1p2
ID:
KPR.2008.11.26.006
Title:
Compilation of production code application fails if interface

variable is a bit-field with an access function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the interface variable of a root step function is defined as a

bit-field with
access protected by an access function the compilation and
linking of the
production code simulation application for SIL and/or PIL
simulation mode is not
possible, because the compilation of the production code
frame file
<subsystem>_pcf.c fails.
The reason is that in the <subsystem>_pcf.c file an auxiliary
variable with the
unknown data type Bifield is defined.
Workaround: Do not use an access function for a bit-field interface variable
on root step
function. Otherwise no workaround available.
76 / 1260
ID:
KPR.2008.11.26.007
Title:
Wrong overflow warning for a Data Store Read block which

has been copied from another model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For a Data Store Read block which was copied from another
model, the scaling
ranges of the old model's Data Store Memory block are used
during a MIL
simulation instead of the new model's Data Store Memory
block. This leads to
wrong overflow warnings and wrong constraint lines in plots
for the Data Store
Read block.
Workaround: Modify at least one TargetLink property of the Data Store
Read block or the
corresponding Data Store Memory block (e.g. 'blockcomment')
after the Data Store
Read block has been copied to the new model and before a
MIL simulation is
started.
There are two methods:
1. Open the block dialog, change one property and apply the
change. Afterwards
set the old value and apply again. It is necessary to change a
value, because
otherwise the data will not be written to the block data.
2. Use the API, e.g. with the following command:
tl_set(h, 'blockcomment', tl_get(h, 'blockcomment')),
where h is the block path or handle of the Data Store Read
block or the Data
Store Memory block.
ID:
KPR.2008.11.26.008
Title:
Missing description of Stateflow Either Edge output event

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For a Stateflow event output of type Either Edge the

description property
(specified in the Model Explorer or via the TargetLink Property
Manager) is not
printed as a comment in the generated code. In the generated
documentation the
description field of the output variable is empty.
77 / 1260
ID:
KPR.2008.11.26.009
Title:
Communication mode of interrunnable variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: According to the AUTOSAR standard, the communication

mode for an individual
interrunnable variable is fixed. Either all of the accesses to an
individual
interrunnable variable are explicit, or all accesses to the
interrunnable
variable are implicit.
In TargetLink, the communication mode of an interrunnable
variable is specified
at every Runnable Port block that models an access to this
variable. All
Runnable Port blocks that model access to the same
interrunnable variable have
to use the same setting for the communication mode. This has
to be ensured by
the user. If a TargetLink model contains accesses to the same
interrunnable
variable with different communication mode settings, the
resulting production
code cannot be compiled and linked with the RTE on the
ECU, it is not a valid
AUTOSAR application at all.
Workaround: Ensure by (automated) model inspection that all accesses to
an individual
interrunnable variable use the same communication mode.
ID:
KPR.2008.11.26.010
Title:
Merge of look-up table variable with another variable may lead

to name ambiguity error caused by different init values though
the values are identical

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is a model that contains a Look-Up Table block. The

table values are
specified as follows:
- The variable representing the values is specified by the block
dialog, not by
the Data Dictionary.
- The variable's type is set to an integer data type.
- An arbitrary scaling has been specified with an LSB value
that cannot be
represented as a power-of-two scaling, e.g. 0.001.
- A fix variable name has been specified, that means the
78 / 1260
name does not contain

name macros $R or $S.
- A variable class has been specified, where the Optimization
property has
option "MERGEABLE"' selected.
- One or more init values can be represented in the selected
scaling, but not in
a power-of-two scaling (e.g. init values are [-31.24 0.08
31.51]).
The model does contain another block that is not a Look-Up
Table block. It does
have a variable that is specified in exactly the same way as
the Look-Up Table
block's table variable.
In this case, code generation might fail with an error like the
following:
Warning #17428: Subsystem/Data Store Memory
The variable with the name 'MyVar' is involved in a name
ambiguity caused by
different initial values. The initial value is shown below to help
to backtrack
the name ambiguity. Values are represented with 'double'
type, nonnumerical
values as 'NotNum'. Initial Value = { { -31.24 }{ 0.08 }{ 31.51 }
}.
Warning #17428: Subsystem/Interpolation (n-D) using
PreLook-Up
The variable with the name 'MyVar' is involved in a name
ambiguity caused by
different initial values. The initial value is shown below to help
to backtrack
the name ambiguity. Values are represented with 'double'
type, nonnumerical
values as 'NotNum'. Initial Value = { { -31.24 }{ 0.08 }{ 31.51 } }
Error #17299: Subsystem/Interpolation (n-D) using PreLookUp
Name ambiguity of identifier MyVar. The variable was first
declared for
'Subsystem/Data Store Memory'. The variables have fixed
names but different
initialization values.
The error message do complain that the variables above
could be not be merged
because their init values are different. Additionally, both init
values are
displayed, but the messages do show identical init values. The
error is based on
different internal representation of the values, which differs for
the look-up
table block and other blocks. Unfortunately the differences of
the values cannot
be represented in the warning message, because the values
are shown after some
rounding operations due to the display format.
79 / 1260
Workaround: Specify floating-point data types for both variables

-- OR -Specify the variables in the Data Dictionary and select the
Data Dictionary
variable in both block dialogs. If a custom look-up function is
specified for
the Look-Up Table block, the Data Dictionary variable might
be selected in the
custom loo-up script, too.
80 / 1260
ID:
KPR.2008.11.26.011
Title:
Access function is not generated in AUTOSAR initialization

function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The variable class INTER_RUNNABLE_VARIABLE is given to

specify an interrunnable
variable. To initialize a variable the Value property of the Data
Dictionary
Variable object has to be set to the required initial value. To
initialize the
variable in a initialization function the RestartFunctionName
property of the
variable class must be set to "default" and the InitAtDefinition
property must
be set to "off".
Because of the definition of access functions for read and
write access in the
variable class the following code is expected:
void Init_Controller(void)
{
Rte_IrvWrite_InitFunction_LinPos( (SInt16) 0 );
}
But the code generator generates the following source code:
void Init_Controller(void)
{
Rte_Irv_Controller_LinPos = 0 /* 0. */;
}
This is incorrect code.
Workaround: To get initializations of interrunnable variables which are
comform to AUTOSAR
(initializations which use Rte_IrvWrite functions) in an
AUTOSAR initialization
function you have to model the initializations explicitely inside
an ordinary
runnable subsystem. Such a modeling may look like the
following:
- Subsystem runnable, called from outside the TargetLink
subsystem.
- Inside the subsystem runnable: Constant blocks which drive
AUTOSAR outports.
The AUTOSAR outports reference the interrunnable variables
in the Data
Dicionary. Alternatively: Constant blocks which drive Data
Store Write blocks.
The Data Store Memory blocks belonging to the Data Store
Write blocks reference
the interrunnable variables in the Data Dicionary.
81 / 1260
ID:
KPR.2008.12.01.001
Title:
Using of structure components with access via access

function as interface variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: To specify a structure with components, where the access

should be applied via
access function, it is sufficient to specify a suitable variable
class at the
root object of the structure. The components can have still a
default variable
class.
If such structure component is used as an interface variable of
the root step
function than frame generation fails with following error
message:
*** E05040: OBJECT NOT FOUND:
*** The specified object does not exist.
Workaround: Set the same variable class at the structure component as at
the root object of
the structure. See also KPR.2008.11.26.006.
ID:
KPR.2008.12.04.001
Title:
Empty control flow branch may be generated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generator may generate an empty control flow

branch even if no code
coverage or C0 coverage is selected. Such an empty
statement code block should
not be generated.
82 / 1260
ID:
KPR.2008.12.05.001
Title:
String in custom code file may be wrapped erroneous in

production code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A line in a custom code file may be wrapped in production

code, because the line
break limit is less than the characters in the according line
(including the
indentation) in the custom code file.
If the line break limit is reached inside a string constant, then
the line will
be wrapped within the string constant in the generated code,
without the
necessary backslash (except the string does not contain any
whitespace, e.g.
"ERROR_MESSAGE"). This results in code which is not
compilable.
Example:
if( 0 != returnCode)
{
printf("Error %d ... a long error message text which exceeds
the specified
line break limit.", returnCode);
}
will be wrapped in production code like
if( 0 != returnCode)
{
printf("Error %d ... a long error message text which exceeds
the
specified line break limit.", returnCode);
}
which is not compilable.
Workaround: Increase the line break limit.
83 / 1260
ID:
KPR.2008.12.10.001
Title:
Misuse of address operator in look-up table function call

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For the Look-Up Table and the Look-Up Table (2D) block it is
possible to
deactivate the generation of a map structure. Therefore you
have to deselect the
option 'Generate map struct' in the block's dialog. If the option
is deselected
you will find a misuse of the address operator in the generated
code for the the
look-up table function call.
The wrong code looks like this example:
static const Int8 x_table[11] = { ... };
static const Int8 z_table[11] = { ... };
OutPort = (Int16) Tab1DnMS0I2T1563_a(11, &(x_table),
&(z_table), (Int8)
InPort);
An example for correct code looks like this:
static const Int8 x_table[11] = { ... };
static const Int8 z_table[11] = { ... };
OutPort = (Int16) Tab1DnMS0I2T1563_a(11, &(x_table[0]),
&(z_table[0]), (Int8)
InPort);
Trying to compile the wrong code leads to two different
behaviors depending on
the compiler. Some target compilers will abort the compilation
with an error;
others will compile the code and throw a warning.
For example the MSVC compiler throws a warning C4047 like
this:
Subsystem.c(197) : warning C4047: 'function' : 'const Int8 *'
differs in levels
of indirection from 'const Int8 (*)[11]'
Subsystem.c(198) : warning C4047: 'function' : 'const Int8 *'
differs in levels
of indirection from 'const Int8 (*)[11]'
Workaround: Select the option 'Generate map struct'.
patches:
TargetLink 2.3.1p2
84 / 1260
ID:
KPR.2008.12.10.002
Title:
Inlining may Hide Problems with Insufficient Initial Scope of

Variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable has a variable class with Scope = "local" and this
variable is
used outside the function it is defined in, then inlining of this
function (or a
function called by this function) may lead to overall function
local accesses.
If the Inlining threshold is set to zero an error like the following
is issued:
Error #17054
The variable 'V' is implemented with 'function local scope', but
requires
'module local scope'
Similarly, inlining may bring the contents of all functions with
accesses to a
variable with Scope = "global" and Storage = "static" to the
same file even if
initially they resided in different files.
Usually, this is harmless but it becomes a problem in the
following case:
A Stateflow local variable is (erroneously) defined on the level
of the
Stateflow chart itself, but it is only accessed inside a graphical
function of
this chart. This graphical function is then exported:
As a result, code generation succeeds, but the generated
code contains a
variable which is not declared.
Workaround: 1. If assigning a variable a variable class other than "default",
make sure that
Scope and Storage of the variable class are sufficient and, for
Stateflow
charts, that you defined the variable to belong to the right
function. If in
doubt, use a variable class with sufficient scope and set
Optimization property
at least to SCOPE_REDUCIBLE.
2. If you want to make sure that the "initially generated code"
is correct,
generate code once with option Inlining threshold = 0 and
Optimization level =
0.
3. In some cases, for TargetLink versions >= 2.3, setting
"DisableFunctionsAsAnalysisBoundaries" to OFF may yield to
the error as well.
ID:
KPR.2008.12.18.001
85 / 1260
Title:
Merging of look-up table functions fails if a template with more

than one name macro is applied

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Using more than one LookUp-Table block with same settings
normally leads to one
look-up function, but using a LookupFunctionTemplate with a
user specified
look-up function name that contains a name macro like $N
leads to an error
message about not mergeable look-up functions.
Error #17299: <BlockPath>:
Name ambiguity of identifier <LookUpFunctionName>. The
function was first
declared for <BlockPath>. The function with name
<LookUpFunctionName> conflicts
with a function of the same name. Merging functions is not
permitted. Implement
as shared library instead.
There three different behaviors:
1. The LookupFunctionName property of the
LookupFunctionTemplate is set to a
pattern like 'Prefix$(FunctionName)Suffix', only
$(FunctionName) or a fixed name
code generation is possible and the Lookup function will be
reused.
string containing $S, code generation is possible and the lookup function
wouldn't be reused. You can find one function for each block.
LookupFunctionTemplate is set to
Prefix$NSuffix, or only $N$N or $(FunctionName)$N, code
generation isn't
possible and error 17299 occurs.
86 / 1260
Workaround: The code generation is possible and the two look-up functions
are correctly
merged if:
- No LookupFunctionTemplate is active
-- OR -- the LookupFunctionName property of the used
LookupFunctionTemplate is unset
(<n.a.>)
fixed name
'Prefix$(FunctionName)Suffix'
$(FunctionName).
87 / 1260
ID:
KPR.2008.12.18.002
Title:
Superfluous warning about insufficient constant value

representation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If in a Constant block with default variable class a constant

value is specified
and that value allows a deviation/tolerance, TargetLink will not
use this
tolerance for value representation in relational operations.
This can lead to a
superfluous warning 19611 about not being able to represent
the value with the
scaling of the other operand of the relational operation.
Example:
Constant Block
Value: 1.1
Deviation: 20%
Variable Class: default
InPort:
Scaling LSB: 2^0
Scaling Offset: 0.0
DataType: Int16
If the given Constant block and the given InPort block drive a
Relational block,
TargetLink will issue warning 19611 stating that the value 1.1
cannot be
represented with an LSB of 2^0. The value will be changed to
1.0.
This warning is superfluous since the new value (1.0) lies
within the tolerance
range the user allows for the constant value.
88 / 1260
ID:
KPR.2008.12.18.003
Title:
Incorrect code for LookUp Table and LookUp Table (2D) block
with binary search and look-up method 'Interpolation ?
Extrapolation'

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Using a LookUp Table block or a LookUp Table (2D) block

with the interpolation
method 'Interpolation - Extrapolation', with an axis with only
two axis points
and for this Axis the search method is binary search, there is
an endless loop
for all block input signals smaller than the smallest axis point
of the axis
vector.
In the error case you can find in generated look-up function a
while statement
like the following:
while (Aux_U8 < ((UInt8)(Aux_U8_a - 1)));
The cast in this statement leads to the endless loop.
Workaround: Do not use binary search and look-up method 'Interpolation Extrapolation' at
the same time for LookUp Table Blocks with only 2 axis
points.
89 / 1260
ID:
KPR.2008.12.18.004
Title:
Invalid link in HTML documentation for subsystems with

newline in its name

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If an AutoDoc Customization block is placed in a subsystem

which has a newline
in its name, and a new chapter is built up for this subsystem in
the generated
documentation (option 'Add as a new chapter' is selected), the
link to this
chapter in the links frame contains the name of this
subsystem. For TargetLink
2.1 and TargetLink 2.2, however, an empty caption field in the
AutoDoc
Customization block is required to get this behaviour.
Since the newline character in the subsystem's name is not
desired in the link,
it is replaced with the two characters '\n'. This replacement
works for Internet
Explorer up to version 7.0 and Firefox up to, at least, version
1.0.4. However,
the generated link does not work with newer browsers such as
IE 8.0 and Firefox
3.0.
Workaround: Use a different web browser or do not use newlines in
subsystem names.
patches:
TargetLink 2.3.1p3
90 / 1260
ID:
KPR.2008.12.18.005
Title:
Superfluous warning #15202 issed for scaling-invariant

system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If the input of a scaling-invariant subsystem is driven by a

block output
variable with constraints (Min and/or Max value), the min/max
values are not
available in the SII_In structure describing the properties of
the input for the
scaling propagation function. Instead the implemented range
limits of the data
type of the block output variable is provided in the SII_In
structure. If this
min/max values of the SII_In structure are used to calculate
the min/max values
of the output in the scaling propagation function, the computed
min/max may lead
to a problem that the calculated min/max values are outside
the implemented
range interval of the scaling invariant system output. In this
case the
superfluous warning #15202 is thrown.
Example:
A scaling propagation function is implemented such that the
min value of the
input is written to the min value of the output. The input signal
of the scaling
invariant system is of type Int16 and has zero specified as a
lower constraint
limit (Min value). Inside the scaling invariant system the data
type UInt16 is
used for the output. During the code generation the warning
#15202 is thrown:
"The min value (-32768) computed for signal 1 is smaller than
the implemented
ranges' value (0)."
Workaround: For the input of the scaling-invariant system use a data type
with appropriate
implemented ranges instead of specifying constrained ranges.
91 / 1260
ID:
KPR.2008.12.18.007
Title:
TargetLink Code generator option

"TreatSpecificErrorsAsWarnings" wrongly invalidates the
generated code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In general TargetLink aborts code generation if some errors

are detected during
the code generation process. But for some specific errors it's
possible to
handle these errors as warnings. This can be done by
activating the Code
Generator option "TreatSpecificErrorsAsWarnings". Often the
option will be
activated when the code generation process exits as a result
of an cyclic
include. The detected cyclic include will be shown as the
following error
message:
Error #17066:
Cyclic includes detected: a.h, b.h.
To get the opportunity to look inside the code, set the option
"TreatSpecificErrorsAsWarnings".
Currently this concerns only to the error 17066 "Cyclic
includes detected".
But since TargetLink 2.3, activating the Code Generator
option
"TreatSpecificErrorsAsWarnings" always invalidates the code
even if no error
17066 is detected.
92 / 1260
ID:
KPR.2008.12.18.008
Title:
The optimization does not consider global non-erasable

variables used in a Stateflow chart as externally modifiable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Variables which are specified via a variable class as global

and non-erasable
(the Optimization property has ERASABLE unselected) are
generally taken into
account as externally modifiable, e.g. as modifiable in an user
file. For
example initial-value propagation is not allowed for such
variables.
But if a variable class with Scope "global" and unselected
ERASABLE is assigned to a Stateflow data object and if this
data object is only
locally known in a chart from the point of view of the Stateflow
model then
optimization does not consider such a data object as
externally modifiable. The
initial values of such data objects are propagated and used to
determine
constants and dead code. This can lead to incorrect but
compilable code.
Workaround: Set the Info property of the according variable class of such a
Stateflow data
object to "adjustible".
93 / 1260
ID:
KPR.2009.01.05.001
Title:
Merging variables leads to warning #17443 about different

scaling though scalings are identical

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: A Variable object is specified in the Data Dictionary with the

following
settings:
- It has a fixed name, which means that it does not contain
name macros $C, $S
or $R
-- AND -- Its variable class is has Optimization flag "MERGEABLE" set
-- AND -- Its Type property references a user-defined data type. The
type is specified
with constraints whose ScalingRef property does reference a
scaling object.
The variable is referenced in a model.
Additionally, another block variable in the model has the
identical settings as
the Data Dictionary variable but without referencing it.
In this case, the Code Generator issues a warning,
complaining about the
mergeable variable that is associated with two different Data
Dictionary Scaling
objects. The paths to both Scaling objects are shown in this
message.
But both pathes reference the same scaling object.
Workaround: Either use the Data Dictionary variable in both variable
specifications, or do
not use the Data Dictionary variable at all.
94 / 1260
ID:
KPR.2009.01.05.002
Title:
TargetLink AUTOSAR import overwrites the existing Data

Dictionary Template objects

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If in the Data Dictionary project file a user has modified a

predefined Template
object, for example of the AccessFunctions of Modules, these
modification is
reset to default values after an AUTOSAR SWC file has been
imported. The AUTOSAR
import doesn't throw an error message or a warning.
The reason for this behavior is the fact that the AUTOSAR
master template
contains predefined information that may not be changed. So
the AUTOSAR import
always load a new AUTOSAR master template into a
temporary Data Dictionary,
imports the selected AUTOSAR SWC description file and
merges the temporary into
the actual Data Dictionary. The result is the behavior
described above.
Workaround: As a workaround modify the AUTOSAR master template in the
TargetLink
installation folder.
95 / 1260
ID:
KPR.2009.01.05.003
Title:
Different data types of the TargetLink subsystem's output

ports in MIL and SIL/PIL simulation mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If at the root level of the TargetLink subsystem instead of

TargetLink OutPort
blocks and/or Bus Outport blocks, only SWC SenderPort are
used, the data type of
the outgoing signal of the TargetLink subsystem is always
double in SIL/PIL
simulation mode, although in MIL simulation mode other data
types has been
specified.
This may lead to model initialisation error: Data type of output
port <Number>
is invalid.
Workaround: In case the signal passing the SWC SenderPort is a bus,
insert a TargetLink Bus
Outport block between the SWC SenderPort and Simulink
outport.
In case the signal passing the SWC SenderPort is not a bus,
insert a TargetLink
OutPort block between the SWC SenderPort and Simulink
outport.
96 / 1260
ID:
KPR.2009.01.05.004
Title:
Stateflow optimization does not handle value replacements

with initial values correctly if that value is out of the range

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The constant propagation optimization on Stateflow code can

replace the usage of
Stateflow data with their initial value. That initial value can be
outside the
physical or user defined range of the variable which shall be
created for that
data. Normally this wrong specification leads to an error
message like the
following:
"Error #17286: Subsystem/Chart.l1: parameter Ca1_l1 cannot
be initialized with
10 because this value is not covered by the associated scaling
range."
But if the Stateflow optimization replaces that constant
variable with its
value, in this case with the initial value, no error or warning
appears. The
value with it is replaced is wrong.
Examples:
Type is Bool; Initial value is 10: The usages of the data are
repalced with
value 1
Type is Int8; Initial value is 200: The usages of the data are
repalced with
value -56
Type is Int8 with max 100; Initial value is 111: The usages of
the data are
repalced with value 111
Expected would be warnings or error messages like E17286
which give the user a
hint of his wrong specification.
Workaround: Use initial values that are inside the physical and user defined
ranges.
97 / 1260
ID:
KPR.2009.01.06.001
Title:
No warning/error will be emitted if the initial value of a variable

is outside its constrained range

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the inital value of a variable is outside its physical range an

error message
is thrown.
Such a message does not come up if the initial value is
outside the variables
contrained range.
A variable can get a constrained range by specifying Min/Max
values in the
associated block dialog or at a Data Dictionary Variable
object.
A constrained range can also be specifyied using a data type
with constraints.
This can result in wrong code, if TargetLink uses the
constrained range to
optimize the generated code.
ID:
KPR.2009.01.06.002
Title:
Erroneous code for binary bitwise operation in Stateflow with a

constant value as second operand

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For a binary bitwise operation in Stateflow wrong code may be

generated, if the
second operand is a constant value.
In this case the other operand or the result will be cast to the
smallest type
that can hold the constant value.
Workaround: Swap the operands.
98 / 1260
ID:
KPR.2009.01.06.004
Title:
NaN for model parameters is not supported

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If, for example, the constant value of a Constant block is set to
NaN either
wrong code or no code at all will be generated.
TargetLink shows the following erroneous behaviour if a
constant block has a
default variable class and its initial value is NaN:
1. A Constant block drives a block which has a floating-point
type for the
output and/or at least one involved parameters:
TargetLink 2.0 up to TargetLink 2.1.6 will emit the error
message #20003 stating
that the variable specification is invalid.
Since TargetLink 2.2 an assignment like Out = -1.#IND is
generated which cannot
be compiled.
2. A Constant block drives a block which has only fixed-point
(integer) types
for the output and the parameters:
TargetLink 2.0 up to TargetLink 2.1.6 will emit the error
message #20003 stating
that the variable specification is invalid.
TargetLink 2.2, 2.2.1 and 2.3.1 willl generate an assignment
like Out = 0 /*
-1.#IND */ which cannot be compiled.
TargetLink 2.3 and 3.0 will emit an internal error #10007.
If the constant value has a none default class, TargetLink will
omit the
initialization of the resulting variable.
99 / 1260
ID:
KPR.2009.01.06.005
Title:
Propagation of function calls in function call argument may

lead to wrong execution order

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is a model in which you have a subsystem "Func2" with

Function block and
FCN_ARG inputs whose input signals are function return
values from other
function subsystems, "Func1" and "Func3". The function calls
of "Func1" and
"Func3" are generated into the call of "Func2". This means
that the execution
order of "Func1" and "Func3" depends on the compiler.
However, TargetLink also
generates this code pattern if one of the "Func1" and "Func3"
systems depends on
the other, which means that the execution order of those two
functions is
crucial.
Code Example:
c = Func1(a, &b);
d = Func3(b);
e = Func2(c, d);
becomes erroneously
e = Func2(Func1(a, &b), Func3(b));
if "c" has the Optimization flag ERASABLE or default variable
class and Func1()
and Func3() have Optimization flag SIDE_EFFECT_FREE or
analyzed to be
SIDE_EFFECT_FREE.
Note that "b" could also be a global variable.
Workaround: Insert auxiliary TargetLink ports / Rescaler blocks or a Gain
block with gain
value = 1 in front of the inputs of "Func2" and assign to the
respective block
output variable a variable class that has no ERASABLE
Optimization property.
100 / 1260
ID:
KPR.2009.01.06.006
Title:
Upgrade sets block comment at Addfile block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: After an upgrade of an TargetLink model (TargetLink version

2.x to 3.x) the
block comment of an Addfile block may contain the string 'Link
"untitled.c"'.
This happens only if the block comment was empty in the
original model,
non-empty block comments are not overwritten.
Workaround: It is recommended to delete such comments by means of the
Property Manager.
ID:
KPR.2009.01.06.007
Title:
Misleading error message for a vectorial custom code

parameter specified like other vectorial Custom Code interface
variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If a vectorial variable of a Custom Code parameter is specified

like all other
Custom Code variables by using the C notation (e.g. at
Output: u[3] ) the
following error message will occur:
"'<varname>' is a vector, which is not possible for
parameters."
But TargetLink allows a vectorial parameter, if it is specified by
using a
vectorial parameter value.
Workaround: Specify a vectorial custom code parameter by using a
vectorial parameter value.
101 / 1260
ID:
KPR.2009.01.06.008
Title:
Stateflow input variables are implemented with datatype

Float64

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If one or more Stateflow input variables are unintentionally

implemented with
datatype Float64, this might be caused by the TargetLink
upgrade utility. In
such a case the description of the Stateflow input contains the
string '$TL$
createinputvariable=1 $TL$' whereas in the original model the
description of the
same Stateflow input was empty. This missbehavior can be
observed with MATLAB
R2008a only.
Workaround: Simply delete the portion of description enclosed by $TL$.
102 / 1260
ID:
KPR.2009.01.07.001
Title:
Risk of wrong code for Discrete Filter / Discrete Transfer

Function if coefficients are mergeable or calibratable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink changes the signs of coefficients for the

denominator of a Discrete
Filter and a Discrete Transfer Function block, to generate
code patterns like
y = y + coeff * x
Some compilers recognize this as a MAC (multiply
accumulate) expression, if it
is implemented as an instruction in the target hardware, which
makes the code
more efficient.
If the variable class of the coefficients has Optimization flag
"MERGEABLE" set
and the coefficients are used somewhere else in the code
(e.g. in a
initialization function), the switch of sign is not handled
consistently, which
may lead to wrong simulation results.
If the variable class of the coefficients has Info property set to
"readwrite"
(i.e. calibratable), the switch of signs for coefficients in the
code may lead
to erroneous results when using a calibration tool.
Workaround: Set the Code Generator option "KeepDenominatorCoefSign" =
"on".
ID:
KPR.2009.01.08.001
Title:
Code geneneration aborts with fatal error #10007 for Custom

Code block using struct pointer as block input variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A variable of struct type is specified in the Data Dictionary. Its

variable
class has scope 'ref_param'. One of the struct's components
is selected in a
Custom Code block's block dialog as an input variable.
In this case code generation fails with an internal error
#10007.
103 / 1260
ID:
KPR.2009.01.12.001
Title:
Elimination of muxed scalar call-by-reference function output

by vector elements or bus struct members works only for one
element or member

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a function has a scalar call-by-reference output variable and

the function
call argument is replaced by a vector element, then no other
vector element can
be moved past this call. This effectively blocks optimizations:
Example:
a0 = b;
f(&a1);
g(&a2);
h(&a3);
arr[0] = a0;
arr[1] = a1;
arr[2] = a2;
arr[3] = a3;
If a3 is eliminated, then
a0 = b;
f(&a1);
g(&a2);
h(&arr[3]);
arr[0] = a0;
arr[1] = a1;
arr[2] = a2;
cannot be further optimized as TargetLink assumes variable
aliasing of all
elements of "arr" and the parameter of h().
The same holds for struct members. If function inputs work
through
call-by-reference, then the same applies.
Workaround: There is general workaround available.
Instead, the pointer-to-struct feature can be used: The
function inputs and
outputs are set to struct members of a Data Dictionary struct
variable with
Scope = "ref_param" and, if necessary, the struct variable is
added as
additional parameter to the function block of the function that
owns the global
struct variable.
Note that this leads to changed function interfaces which may
not be desired.
104 / 1260
ID:
KPR.2009.01.14.001
Title:
Extremely slow code generation for Stateflow chart with a

subchart containing many states

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Code generation duration may be extremely long for a

Stateflow chart with a
subchart, which contains many states and fulfills one of the
following
conditions:
- It has inner transitions.
-- OR -- It has no inner transitions and only conditional outgoing
transitions.
Workaround: 1. Add a subchart into the subchart and move the states into
the added subchart.
2. (Only for a subchart fulfilling the condition 2 above)
Add an outgoing transition segment with an unsatisfiable
condition (e.g. [0]) to
the subchart, see the figure below.
/---------------------\
| Subchart |
| /* which contains |
| many states */ |
\---------+-----------/
|
|[0]
|
V
O
patches:
TargetLink 3.1p7
105 / 1260
ID:
KPR.2009.01.19.001
Title:
Wrongly message about wrong dimensions when selecting a

Data Dictionary variable for the table in Look-Up Table (2D)
block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If a variable is specified in the Data Dictionary representing a

2D table with
the dimension [n m] the current Width property in Data
Dictionary is also [n m].
Selecting this variable for the table variable of a Look-Up table
(2D) block
results in error message like the following:
Selected variable has a wrong dimension !
z_table.width = [n m]
Workaround: Set the table variable using the Property Manager or the
TargetLink API, e.g.
tl_set(<block>,'table.Variable', 'z_table')
106 / 1260
ID:
KPR.2009.01.19.002
Title:
TargetLink 3.0 code generation fails for AUTOSAR model

created with TargetLink 2.3.1

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an AUTOSAR model was changed or created with

TargetLink 2.3.1, it is still
possible to update this model to TargetLink 3.0. However, if
you try to generate
code, an error message (#17156) is thrown, followed by a
fatal error message
(#99999) and an access violation. The message history looks
like the following:
Error #17156:
/ ... /Typedefs/S16_LinPos:
A TargetLink default file found with the same base name
'rte_type'.
User-specified files and TargetLink default files are not
allowed to have the
same name.
TargetLink default file involved:
- //DD0/Pool/Templates/Modules/MT_tl_basetypes
Fatal #99999:
An exception occurred during code generation. Contact
dSPACE technical support.
Exception: ACCESS_VIOLATION
Fault address: 1D79E9F1 01:0008D9F1
D:\Targetlink\Release\tl_3_0\Matlab\Tl\bin\XcgCV.dll
The reason for this error is a changed module template
"/Pool/Templates/Modules/MT_tl_basetypes". The property
"NameTemplate" was
changed from "tl_basetypes" to "Rte_Type". As a
consequence the code generation
in TargetLink 3.0 throws an error message, because all for
AUTOSAR imported
Typedef objects contains the Module property with the value
"Rte_Type". This
entry conflicts to the default module "Rte_Type" defined at the
module template
"tl_basetypes".
Workaround: Reset the NameTemplate property at the module template
"/Pool/Templates/Modules/MT_tl_basetypes" to the value
"tl_basetypes". As a
result the file "tl_basetypes.h" contains type redefinitions for
AUTOSAR types.
To fix the problem reset the file "tl_basetypes.h" with an empty
header file of
the same file name.
107 / 1260
ID:
KPR.2009.01.19.003
Title:
Model initialization failes due to wrong signal name

propagation in SIL/PIL mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In TargetLink's SIL simulation mode the TargetLink subsystem

is made inactive,
instead an S-function representing the generated code is used
for simulation.
Inherent to this working principle there may occur problems
with propagated
signal names if they are used outside the TargetLink
subsystem, e.g. at Bus
Selector blocks. As a result the model can be initialzed in MIL
mode whereas the
initialization in SIL mode aborts with one of the following error
messages:
Selected signal <signal_identifier> in
<path_of_busselector_block> is not part
of the bus entering the Bus Selector.
The name of the signal from output port <n> on
<path_of_port_block_a> and the
name of the signal from output port <m> on
<path_of_port_block_b> are the same
identifier <signal_identifier>. Signal identifiers have to be
unique.
Multiple conflicting usages of identifier <signal_identifier>:
the name of the signal connected to output port <n> of the
block
<path_of_port_block_a>', and
the name of the signal connected to output port <m> of the
block
<path_of_port_block_b>."
Workaround: If possible, shift the signal name specification out of the
TargetLink
subsystem.
Conflicting signal names can be related to Simulink.Signal
objects and their RTW
settings especially the storage class. If 'ExportedGlobal' was
choosen as
storage class, Simulink reports such errors. Initialization
succeeds if
problematic Simulink.Signal objects are cleared from the base
workspace, or
another storage class is set for the signal object.
108 / 1260
ID:
KPR.2009.01.21.001
Title:
Declaration statements of function and/or variable classes are

not transferred correctly to the subsystems area, leading to
code generation errors for referenced models

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When function and/or variable classes with non-empty

DeclarationStatements
property are used in referenced models, the interface
validation of the
referenced system, which is based on the description of the
referenced system
inside the Data Dictionary's Subsystems area, may fail with
the following
message:
Error #08904:
Data mismatch found. Property DeclarationStatements of
function class <FCNCLASS>
differs from the origin in the pool area.
(...)
The Reason is the incorrect spelling of the respective
declaration statement
keyword inside the Data Dictionary subsystem object.
Workaround: Modify the generated function and/or variable class objects
inside the Data
Dictionary via script just after the code generation using a
post_codegen_hook
function.
patches:
TargetLink 3.1p2
109 / 1260
ID:
KPR.2009.01.26.001
Title:
Building simulation frame fails caused by mergeable extern

variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In a model several block variables are specified with identical

names that do
not contain name macros $R or $S. All variables have
identical properties. They
have a variable class with Storage = "extern", and
Optimization flag "MERGEABLE"
is set.
In this case TargetLink does not merge the variables, but
generates several
variable declarations with identical names instead.
As a result of this error, TargetLink generates faulty
information in the DD's
subsystem area, that leads to an error when trying to build the
simulation
frame.
Workaround: Don't specify the "MERGEABLE" flag in the variable class.
ID:
KPR.2009.02.09.001
Title:
Code generation aborts for Sum/Product/MinMax block with a

vector input and a scalar output in extern system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Sum block, Product block or MinMax block with a vector

input signal and a
scalar output signal is located in an atomic subsystem which
is either specified
for incremental code generation or has a step function with
Storage = "extern"
the code generation aborts with an access violation (F99999).
Workaround: Insert a TargetLink Rescaler block or a TargetLink InPort in
front of the
Sum/Product/MinMax block.
110 / 1260
ID:
KPR.2009.02.09.002
Title:
Annoying warning if more than 1024 table values are used
Last Update: 29 Jan 2013

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If in a Look-Up Table, Look-Up Table (2D), PreLookup Index

Search or
Interpolation (n-D) using PreLookup block more than 1024
values are specified
for any variable, code generation is stopped to throw a
warning:
Overstress Matlab?
The given table and scaling data would result in a table with
about <values>
values. Do you want the table to be calculated nevertheless?
(Note that your
system resources may run low!)
The user has to answer this dialog to resume code
generation.
This is very inconvenient, especially if automatic code
generation is used.
Moreover, the value of 1024 stems from old TargetLink and
MATLAB versions and
nowadays code generation is also possible for higher values.
Note: since TL 3.2 the code generator option
"SuppressPerformanceWarningForTableDataEvaluation" can
be used to switch off the
warning message.
111 / 1260
ID:
KPR.2009.02.09.003
Title:
Call to dsdd_export_a2l_file requires explicit compiler

specification, if an A2L file with address information is to be
generated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When calling the A2L export via the dsdd_export_a2l_file API
function, it is
required to specify the platform that the A2L is to be
generated for.
This is possible either via the options "Board"/"Compiler" or
via the options
"TargetConfig"/"TargetInfo". However, if the second pair of
options has been
used and additional the MAP file has been specified, needed
to obtain the
addresses of the variables described in the generated A2L
file, the warning
#06703 is issued:
*** W06703: NO TARGET COMPILER SPECIFIED:
*** The target compiler has not be specified,
*** thus variable addresses cannot be evaluated.
*** There will be no address information in the A2L file.
The generated A2L file does not contain any address
information in this case.
This is not correct. To obtain the address information from the
MAP, the
compiler must be known, but it is already specified in the
target_info.m file.
Workaround: Call the dsdd_export_a2l_file with the additional option
"Compiler" with value
equal to targetInfo.cc, where targetInfo is the structure
specified in the given
target_info.m file
112 / 1260
ID:
KPR.2009.02.10.001
Title:
Option 'Inherit properties' leads to error #15204 in feedback

loops

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink inherits certain variable properties from the

preceding blocks when a
block has option 'Inherit properties' selected. But if a
preceding block is part
of a feedback loop that leads to the origin block and all blocks
in the feedback
loop have option 'Inherit properties' selected then TargetLink
ignores all this
blocks when searching for valid variable properties.
This may lead to error #15204
'Scaling of signal <signal index> could not be inherited from
the foregoing
source blocks'
if all blocks that are driven by specified signals (i.e. blocks
without 'Inherit
properties') are part of such a feedback loop.
Workaround: Avoid option 'Inherit properties' in feedback loops when
encountering error
#15204.
ID:
KPR.2009.02.11.003
Title:
Superfluous 32 bit cast in Stateflow bitwise operation with

constant value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink introduces a superfluous cast to a 32 bit wide type,

if in a
Stateflow relational operation a binary bitwise operation is
specified, that
- has a constant value as one operand while
- the other operand is a non constant integer with different
TargetLink and
Stateflow data types.
This problem only comes up, if the code generator option
'HandleUnscaledStateflowExpressionsWithTlType' is set to
'on' (which is
default).
Workaround: Set option 'HandleUnscaledStateflowExpressionsWithTlType'
to 'off'.
ID:
KPR.2009.02.18.002
113 / 1260
Title:
Wrong placement of vector log macro for code moved into

conditionally executed branches

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Switch block is driven by a vector condition signal and one

of the data
signal predecessor blocks is logged, then moving the code of
the logged block
into the then branch or else branch of the Switch block's code
leads to a wrong
position of the log macro for TargetLink versions < 2.3 and to
wrong or
inefficient position of the log macro for TargetLink >= 2.3
where wrong and
inefficient depend on whether or not a loop is generated for
the Switch block's
code.
Example:
Given is a Switch block "Switch2" driven by vectors of width 2
for all three
inputs. One of the data inputs is logged. The initially
generated code - that
also can be observed on optimization level = 0 - is similar to
SwitchPred1[0] = ...
SwitchPred1[1] = ...
LOG_VEC(a, _SwitchPred1, 2 /* 2. */, SwitchPred1);
if (Cond2[0] != 0) {
Switch2[0] = SwitchPred1[0];
}
else {
Switch2[0] = In3[0];
}
/* SwitchVectorLogError/Switch2, signal number: 1 */
if (Cond2[1] != 0) {
Switch2[1] = SwitchPred1[1];
}
else {
Switch2[1] = In3[1];
}
This erroneously is optimized into
if (Cond2[0] != 0) {
SwitchPred1[0] = ...;
OutPort[0] = SwitchPred1[0];
}
else {
OutPort[0] = In3[0];
}
if (Cond2[1] != 0) {
SwitchPred1[1] = ...;
OutPort[1] = SwitchPred1[1];
}
114 / 1260
else {
OutPort[1] = In3[1];
}
i.e. SwitchPred1[1] is always wrongly logged. As Cond2[] is a
vector, there is
no right location for the Log Macro.
For TargetLink >= 2.3, a loop can be generated, the resulting
optimized code
then is
if (Cond2[Aux_S32] != 0) {
SwitchPred1[Aux_S32] = ...;
OutPort[Aux_S32] = SwitchPred1[Aux_S32];
}
else {
OutPort[Aux_S32] = In3[Aux_S32];
}
This leads to (LoopWidth-1) uninitialized writes but one full
write of the
vector; this can lead to problematic intermediate values and is
definitely
inefficient. Without single element logging, there is no good
location for the
log macro, either.
Similar situations may be provoked with code stemming from
Stateflow charts.
Workaround: Set the Code Generator option "DoNotMoveIfLogged"; it is
intended for correct
logging of code that otherwise may be moved into
conditionally executed control
flow branches.
ID:
KPR.2009.02.18.003
Title:
Erroneous elimination of vectorial Custom Code inputs with

scalar predecessors

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
115 / 1260
Description: If a Custom Code input variable is a vector and this vector is

essentially a
scalar expansion of a scalar signal (constant, scalar variable,
access to fixed
vector element), then it is possible that this scalar signal
erroneously
replaces the vector input. This may be exacerbated by
replacing the scalar
replacement variable etc.
The generated code will not compile.
Example:
For a model where a vector VectorInput is built within a For
Iterator Subsystem
and then used as Custom Code input, the following "initial
code" (observable for
optimization level = 0) is generated:
Sb2_Selector = In3[Sb2_For_Iterator_it];
for (Aux_S32 = 0; Aux_S32 <= 9; Aux_S32++) {
VectorInput[Aux_S32] = Sb2_Selector;
}
/* Custom code:
Subsystem/for_system/two_signal_sw1/Custom Code Block
<<
output code >> */
{
MyFunctionCall(VectorInput,
...);
}
This is "optimized" to
/* Custom code:
Subsystem/for_system/two_signal_sw1/Custom Code Block
<<
output code >> */
{
MyFunctionCall(In3[Sb2_For_Iterator_it],
...);
}
Workaround: - Protect the Custom Code input variable from elimination by
using a variable
class without Optimization flag "ERASABLE"
-- OR -- Disable optimized vector processing by setting Code
Generator option
"EfficientVectorHandling" = "off"
In some cases, "DisableFunctionsAsAnalysisBoundaries" =
"off" may seemingly help
but this is no reliable workaround.
patches:
TargetLink 2.3.1p2
116 / 1260
ID:
KPR.2009.02.19.001
Title:
Netlist creation fails for model containing Goto Tag Visibility

block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Netlist creation fails for a model, where the TargetLink

subsystem contains
- More than one Goto Tag Visibility block
-- AND -- An unconnected TargetLink block, i.e. Function block.
In this case some error messages are issued in the MATLAB
command window and
MATLAB aborts.
ID:
KPR.2009.02.20.002
Title:
Missing SectionName, TypePrefix, DeclarationStatements for

variable with bit width 1 and a default variable class modified
via a variable class template

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For certain production code targets TargetLink implements the

boolean type with
1 bit. If such a boolean variable has a default variable class
and for the
default variable class via a variable class template a
SectionName, TypePrefix
and/or DeclarationStatements are set for the WidthSpec =
"APPLY_TO_BIT", the
SectionName, TypePrefix and/or DeclarationStatements for
this variable are
missing in the generated code. The SectionName, TypePrefix
and/or
DeclarationStatements are not missing in the generated code
if in the Filter of
the VariableClassTemplate for the WidthSpec all possible
width specifications
are selected.
117 / 1260
ID:
KPR.2009.02.22.001
Title:
Erroneous rescaling of inlined pointer to struct / function reuse

component

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Erroneous rescaling of a struct component may occur, if all

conditions are
fulfilled:
- The struct component is a component of a struct (parent
struct) which is even
a component of a structure (root struct)
-- AND -- The root structure is a function parameter (i.e. used for
function reuse or
pointer to struct)
-- AND -- Components of the parent struct are used in different
functions (i.e. non
virtual subsystems)
-- AND -- Not all components of the parent struct are used in each
function one of them
is used in
-- AND -- The functions where the components are used in are inlined
-- AND -- At least one of the components has a LSB != 1.0 and/or an
Offset != 0.0
Workaround: Disable inlining (set inline threshold = 0) or make the root
structure global.
118 / 1260
ID:
KPR.2009.02.25.001
Title:
AUTOSAR 2.0 Export for PRIMITIVE-TYPES-WITHSEMANTICS creates identifier which is too long

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR export creates an SHORT-NAME identifier

which is greater than 31
characters. The reason for this behavior is the fact, that the
SHORT-NAME value
of the PRIMITIVE-TYPE-WITH-SEMANTICS elements will be
assembled by different
SHORT-NAME entries. The rule for creation is the following:
SHORT-NAME = prefix + PrototypeName + TypedefName;
The prefix will be defined by the dsdd_autosar_config.xml file.
The
PrototypeName equals to the name of the Data Dictionary
DataElement object,
OperationArgument object or Variable objekt (as interrunnable variable). The
TypedefName equals the name of the Typedef object,
referenced by the prototype.
As a result of this behavior the AUTOSAR export with XML
validation set to "on"
throws the following error message:
Title: Warning
Message:XML validation failed: The file DataType_Test.arxml
is invalid: pattern
constraint failed.
The element: '{http://autosar.org}SHORT-NAME' has an
invalid value according to
its data type.
Workaround: The following workarounds are possible:
1. Switch the validation after export to "off".
2. Specify shorter names vor Typedef and Prototype objects.
119 / 1260
ID:
KPR.2009.02.27.001
Title:
Simulation frame generation aborts with error "SourceSignal

not found" when using unspecified Busports in function called
subsystems

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: When using a function called subsystem which has got an

unspecified bus inport
block and/or bus outport block (i.e. not specified by a
TargetLink BusInport
block or TargetLink BusOutport block) with connection to the
TargetLink root
system, the frame generation may fail with the error message
"Source signal
cannot be found". The reason is a wrong signal index in the
corresponding
function's description inside the Data Dictionary.
Workaround: Insert TargetLink Busports at the border of the event triggered
subsystem.
ID:
KPR.2009.03.02.001
Title:
Code generation aborts with fatal error F17107 "error occurred

in processing XSL"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may abort with a fatal error message similiar
to
Fatal #17107:
An error occurred in processing XSL: Problem writing file
xyz.h.Unable to save
character to 'ISO8859-1' encoding.
The reason is a character which cannot be encoded in the
choosen encoding
(default is 'ISO8859-1).
Workaround: Change the CharacterSet property of /Config/General from
"LocalDefault" to
"UTF-8".
120 / 1260
ID:
KPR.2009.03.02.003
Title:
The superfluous warning 17251 may be thrown for a look-up

table function's input parameter

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The superfluous warning 17251 may be thrown for a look-up

table function's input
parameter x (LookUp-Table 1D/2D and Prelookup) and/or for
the look-up table
function's input parameter y (LookUp-Table 2D).
If constraint limits are given at a Data Dictionary data type
object used for an
axis variable (input, breakpoint data, row, column, x-axis or yaxis), this
constraint limits are inherited to the input parameter of the
look-up table
funktion, but the scaling isn't inherited.
This behavior leads to the following warning, because the
ranges are incorrect
for this look-up table function's input parameters.
Warning 17251:
"For the variable 'x' an upper/lower constrained limit was
found that is outside
the implemented range. The implemented limit is being used
instead."
This problem has no effect to the generated code.
Workaround: Don't use constrains at the Data Dictionary's data type object
used for axis
variables. Use the contraint values (min and max) of the block
instead.
121 / 1260
ID:
KPR.2009.03.02.004
Title:
Wrong notation of integer init values after AUTOSAR export

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In AUTOSAR an init value is specified with a CONSTANTSPECIFICATION XML node.

During export of an INTEGER-LITERAL node, that can be a
child node of the
constant specification, the init value may be exported in an
exponential
notation. This is wrong because the value has to be exported
in an integer
notation. Possibly this is problematic for the AUTOSAR import
into other tools.
TargetLink doesn't issue an error message, so the user will be
informed by the
import into another AUTOSAR tool, like SystemDesk.
patches:
TargetLink 2.3.1p2
122 / 1260
ID:
KPR.2009.03.02.005
Title:
Format string of variables and scalings are not taken into

account during A2L file export

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During the A2L file export a Scaling object referenced by a

calibratable or
measurable variable are mapped to an A2L
COMPU_METHOD element.
The Scaling object's Format property however, is not mapped
to the Format
parameter of the COMPU_METHOD. Instead the value of the
COMPU_METHOD's Format
parameter is calculated based on LSB, offset and data type of
the variable the
COMPU_METHOD entry is generated for.
As result for variables referenced to identical Scaling object in
Data
Dictionary different COMPU_METHOD elements (with
different value fo the Format
paramer) are generated.
Note:
The Format property of a Variable object is mapped to the
corresponding Format
parameter of a CHARACTERISTIC, MEASUREMENT or
AXIS_PTS entry.
Workaround: To force an identical display format for all variables
independent on the
display format generated at the COMPU_METHOD set the
Format property at the
corresponing Data Dictionary Variable object.
patches:
TargetLink 2.3.1p3
123 / 1260
ID:
KPR.2009.03.02.006
Title:
Unused variables in code for cascade of Merge blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Merge block X which resides inside a cascade of Merge

blocks has specified
a variable class a variable is created for X but not used.
According to
TargetLink semantics the Merge cascade is mapped to the
variable of the Merge
block which forms the output of the cascade.
The superfluous creation of the unused variable may yield to
odd effects. For
instance if such variable is specified to be displayable, you
won't see any
update of the value during simulation.
Workaround: Use only the output of the Merge cascade to specify the
Merge variable.
ID:
KPR.2009.03.02.007
Title:
Extremely slow code generation for very large Stateflow

arrays

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The duration of code generation may become excessively

long if very large
(several thousand elements) Stateflow arrays are used. The
problem exists for an
array, if it has the following properties:
- Defined at chart level or below,
-- AND -- Scope Local or Output,
-- AND -- Its variable class (if specified) has Const property "off",
-- AND -- If it is of scope Local, there is at least one write access to
one of its
elements.
Workaround: If possible, define arrays of such size at state machine level.
124 / 1260
ID:
KPR.2009.03.02.008
Title:
Stateflow change detection incorrectly reports change at time t

= 0 for state machine data

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When a change detection expression like hasChanged(X) is

evaluated, it will
compare the value of X at the beginning of the current time
step with the value
of X at the beginning of the previous time step. The first time
step is a
special case: TargetLink will use the initial value of X as the
value at the
beginning of the previous time step, which is incorrect if X is a
machine
variable and X is modified in another chart before the chart
containing the
change detection expression is first executed. Thus, a change
is reported for X,
although it is unchanged by definition, because the chart has
not seen X change.
ID:
KPR.2009.03.03.001
Title:
Error message 17277 when using a bit field and global logging
option

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The usage of a bit field variable in a model and the global
logging option 'log
signal histories' or 'log min/max-values' is not possible.
TargetLink stops code
generation with error #17277. The variable name mentioned in
the error message
is wrong.
Workaround: Avoid using bit field variables when using global logging. You
may use the data
type 'Boolean' and variable class 'default' at the affected
blocks and activate
the option 'Use global bitfields for Booleans' in the TargetLink
Main Dialog.
125 / 1260
ID:
KPR.2009.03.23.001
Title:
VariableClass object with non-empty Module property cannot

be selected for Stateflow data objects in Propety Manager

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Stateflow data objects such as Stateflow Outputs, Stateflow

Parameters, etc. can
be edited with TargetLink's Property Manager. For the sf.class
property, a
suitable Data Dictionary VariableClass object can be selected
with the Property
Manager's Property Editor. However, VariableClass objects
whose Module property
is set to a non-empty value are not displayed in the selection
tree.
Workaround: Set sf.class using the Property Manager's Block Explorer.
Note that this allows
to set the property only for one object at a time.
ID:
KPR.2009.03.24.001
Title:
Access violation due to optimized CustomCode output in

combination with Access Functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the output of a custom code block is optimized and replaced

by a variable
with AccessFcn-Template, the Code Generation terminates
with an access
violation.
Workaround: Use a non-ERASABLE variable class for the CustomCode
output, preventing its
optimization.
patches:
TargetLink 2.3.1p2
126 / 1260
ID:
KPR.2009.03.25.001
Title:
Not MATLAB conform expression as Stateflow initial value like

hexadecimal value is not correctly generated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In Stateflow, hexadecimal values are of the form 0x1, 0x2, ...,
0xA, 0xB etc.
If those hexadecimal values are used as initial values for
Stateflow data the
data will be generated with initial value 0 by TargetLink.
In Stateflow non MATLAB conform expressions can be used
as Stateflow initial
value. For instance a hexadecimal value of the form 0x1, 0x2,
..., 0xA, 0xB etc.
or a vector without ?[ ]? like "4 6 9".
If such an expression is used as initial value for Stateflow data
the data will
be generated with initial value 0 by the Code Generator.
Workaround: Make the initial value a MATLAB conform expression, for
example by using a
decimal value instead of hexadecimal or encapsulate vectors
with brackets "[]".
127 / 1260
ID:
KPR.2009.03.25.002
Title:
Erroneous scope reduction of vectors and matrices to

automatic storage duration for definitions with non-constant
index access

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For a situation where the reading accesses of a vector (or

matrix) take place
after the writing accesses but the writing accesses do not
write to a constant
vector element or the whole vector, the vector's storage
duration may be
erroneously reduced to automatic; thus, previously stored
values can get lost or
access to uninitialized memory may take place.
Example:
a[i] = in;
out = a[0] + a[1];
This kind of code usually stems from Stateflow charts or is
forced by merging of
variables.
Workaround: Explicitly define a scope reduction chain involving variable
classes for the
scopes Global, StaticGlobal, StaticLocal where the StaticLocal
class has no
Optimization flag "SCOPE_REDUCIBLE" and the
ScopeReducedClass property of the
Global and StaticGlobal classes reference the respective
lower class. Assign a
sufficient variable class of this chain to the vector or matrix
variable in
question.
ID:
KPR.2009.03.25.003
Title:
Vector variable used in a loop within a loop is erroneously

eliminated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
128 / 1260
Description: An Assignment block

- with option "Source of element indices" = "external"
-- AND -- option "Omit dispensable initializations" is set
-- AND -- located in iterated systems (For Iterator, While Iterator)
may be subject to erroneous optimization if
- the output vector width is identical to the number of iterations
-- AND -- the index source is the iteration variable (with optional
constant offset)
In this case, the output vector of the assignment block may be
erroneously
eliminated.
Example:
Int16 MyAssignment[5] = {0, 0, 0, 0, 0};
for (Sb1_Iterator = 1; Sb1_Iterator <= 5; Sb1_Iterator++) {
...
MyAssignment[Sb1_Iterator - 1] = SomeVariable;
for (Aux_S32 = 0; Aux_S32; <= 4; Aux_S32++) {
MyOut[Aux_S32] = MyAssignment[Aux_S32];
}
}
becomes
for (Sb1_Iterator = 1; Sb1_Iterator <= 5; Sb1_Iterator++) {
...
for (Aux_S32 = 0; Aux_S32; <= 4; Aux_S32++) {
MyOut[Aux_S32] = SomeVariable;
}
}
This can also occur for loops modeled in Stateflow or nested
iterated systems if
the respective loops' iteration range is identical.
129 / 1260
Workaround: While "OptimizationLevel" = 0 and "EfficientVectorHandling" =

"OFF" are viable
workarounds, they are considered undesirable
1. Identify all iterated systems; identify all assignment blocks
with option
"Omit dispensable initializations" set; for these blocks, select a
variable
class with set InitAtDefinition (or non-empty
RestartFunctionName) property and
without ERASABLE Optimization flag.
2. Identify all iterated systems; identify all assignment blocks
with option
"Omit dispensable initializations" set; unset option "Omit
dispensable
initializations"
3. If this situation is provoked using Stateflow charts, identify
the
erroneously eliminated variables and use a variable class
without ERASABLE
Optimization flag.
patches:
TargetLink 2.3.1p2
ID:
KPR.2009.03.25.004
Title:
Atomic system boundaries can be erroneously bypassed due

to optimization and inlining

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
130 / 1260
Description: If a call-by-value actual parameter of a function generated for

an atomic
subsystem is eliminated, i.e.
b = a + g();
f(b);
is replaced by
f(a + g());
then inlining of f() places "a + g()" within the generated code
area reserved
for the former function body and subsequent optimization
places the expression
where the formal parameter has been used prior to inlining.
This violates the
semantics of "atomic" compared to "weak atomic".
Note that this does not lead to incorrect data flow or incorrect
generated code
but that the complex expression is evaluated "too late" with
respect to the
original atomic system boundaries.
Example:
For an enabled subsystem preceded by a complex
computation, it seems that
switching off the code generator option
"TreatAllForcedAtomicSubsystemsAsWeakAtomic" is not
respected if
"DisableFunctionsAsAnalysisBoundaries" is deactivated.
The input of the enabled subsystem without further
specification initially is
realized as call-by-value parameter and replaced by the
complex input prior to
inlining.
Inlining then "transports" the complex expression into the
atomic systems code.
Note that this can also happen if
"DisableFunctionsAsAnalysisBoundaries" is
activated but that there are fewer situations in this case.
Workaround: There are different workarounds
1. Specify the inputs of the respective atomic systems as
global variables; the
variable class Optimization flags "MOVABLE", "ERASABLE"
and "SCOPE_REDUCIBLE"
can be set
2. Set the block output variables of predecessors of affected
atomic subsystems
to a variable class without Optimization flag "ERASABLE" set
and local scope
3. If preservation of atomic semantics is more important than
other
considerations, then
- use OptimizationLevel = 0
-- OR -- use InliningThreshold = 0
-- OR -- override the variable class template "SLFcnInput" with a
variable class
fulfilling the properties described in 1.
131 / 1260
ID:
KPR.2009.03.26.001
Title:
Code generation aborts in context of Switches, Multiport

Switches, Merge blocks and outputs of triggered subsystems

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may abort with an access violation if the

Code Generator option
"DisableFunctionsAsAnalysisBoundaries" is set to "on", which
is the default
setting since TargetLink 2.3.
In addition, one or more of the Code Generator options
"TreatAllForcedAtomicSystemsAsWeakAtomic" and
"AllowInterleavingCodeForAllSubsystems" must be set to "on".
The problem occurs for Switch, Multiport Switch, and Merge
Blocks as well as
Outputs of conditionally executed systems if
- they are the last blocks of a "weak atomic" system that
- is situated within a function call triggered system or a system
with
Function block (so-called function system in the following)
-- AND -- drives the output of this surrounding system
-- AND -- the signal from the function system is consumed only within
an atomic or weak
atomic system that
- is situated within conditionally executed control flow
-- OR -- is an enabled or triggered system
-- AND -- the name of the step function of the function system in the
generated code is
alphanumerically greater than the name of the step function of
the surrounding
system
Workaround: 1. Set "DisableFunctionsAsAnalysisBoundaries" = "off"
2. If 1. has an effect, then one can "interrupt" the block output
variable
driving the output of the function system by
- enhancing the Simulink Outports at the function boundary or
inserting
TargetLink ports before them or by
- inserting a Gain block with gain parameter 1 or a Rescaler
block somewhere on
the line to the Simulink Outports
132 / 1260
ID:
KPR.2009.03.27.001
Title:
Incorrect code may be generated if inherited properties and

Min and/or Max values are used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a block has the "Inherit properties" option set the Code
Generator inherits
(amongst others properties) the Min and Max values from the
preceding blocks.
If a Switch block, Multiport Switch block, MinMax block or
Merge block has the
"Inherit properties" option set and some of its inputs are driven
by signals
with Min and/or Max value and some by signals without Min
and/or Max values, the
Code Generator computes wrong resulting Min and Max
values. Only the given Min
and Max values are combined and the signals without Min and
Max values are
ignored. This leads to too optimistic Min and Max values and
may result in
incorrect code.
Workaround: Deselect the option "Inherit properties" at Switch block,
Multiport Switch
block, MinMax block and Merge block if only few incoming
signals have Min and/or
Max values.
133 / 1260
ID:
KPR.2009.03.30.001
Title:
Code generation may abort with fatal error #10007

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may abort with an internal error message like
Fatal #10007:
Internal error. Error code:
E:\Sandboxes\TL221_M11\Core\XcgIvToCv\Sources\XcgIvToCv\BDiagramToOrderedSequenc
e\RequiredInputCalculation\TlCRequiredInput.cpp_134. Contact dSPACE's technical
support team.
(the message text may vary according to the TargetLink version)
This may happen if following conditions hold:
- There is an iterated subsystem, i.e. an atomic subsystem which contains a For
Iterator block or While Iterator block.
- In the iterator block dialog the option "Show iteration variable" or "Show
iteration number" is set, so the iterator block has an output connector.
- The output of the iterator block is connected to the n-th input of another
block A.
- In the parent subsystem (disregarding virtual subsystems), there is a block B
with the same name as A.
- The number of block B's inputs is less than n.
Minimal sketch:
+-------------------------------+
| +---+ | +----+
| ...-------->| | | | |
| +-----+ | A | | ...--->| B |
| | for |>----------->| | | | |
| +-----+ +---+ | +----+
| MyBlock | MyBlock
+-------------------------------+
For Iterator Subsystem
These conditions are necessary, but not sufficient. The error additionally
depends on internal details.
Workaround: Make sure that for each block that is connected to the output of a For Iterator
or While Iterator block, there is no block with the same name in the
(non-virtual) parent subsystem.
ID:
KPR.2009.04.08.001
Title:
Code generation aborts if Custom Code block inputs are not

connected or driven by a constant with non-default variable
class

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

134 / 1260
Description: If a Custom Code block has an unconnected input and the

respective input
variable is either unspecified or has a fixed initial value, then
there may be a
code generator crash with output similar to the following on
the Matlab command
line:
Fault address: 271A40C8 01:000030C8
D:\TL_2_3_1_installed\MATLAB\tl\Bin\XcgCvTools.dll
Call stack:
Address Frame
271A40C8 00CE37B4 0001:000030C8
D:\TL_2_3_1_installed\MATLAB\tl\Bin\XcgCvTools.dll
259D0931 00CE37FC 0001:0038F931
D:\TL_2_3_1_installed\MATLAB\tl\Bin\XcgCVT.dll
25A35932 00CE3810 0001:003F4932
25A34EBD 00CE387C 0001:003F3EBD
The same can happen if the predecessor is a Constant block
with a user variable
class that allows elimination of the initially generated variable
(due to
Optimization flag "ERASABLE" or because the Code
Generator option
"ExploitRangesIndependentOfErasable" = "on" and the
variable value is considered
immutable by the Code Generator) or if the predecessor
blocks can be evaluated
to a constant expression.
Workaround: 1. Connect all inputs to a TargetLink Inport block
-- OR -2. Generate code only with OptimizationLevel = 0
-- OR -3.1 Unconnected Input: Set a variable class with Scope =
"global", Storage =
"default" or Storage = "extern" and Optimization flag =
"MOVABLE" (not
"ERASABLE", not "SCOPE_REDUCIBLE") for the input
3.2 Connected input, Constant block predecessor, no signal
line split after the
Constant block: Make sure that input and Constant block
parameter have default
variable class
3.3 Connected input, other situation: Set a non-ERASABLE
variable class for the
Custom Code input; Scope and Storage can be arbitrary and
depend only on the
usage of the input within the Custom Code
patches:
TargetLink 2.3.1p2
135 / 1260
ID:
KPR.2009.04.09.001
Title:
Code generation aborts with fatal error on index signals

scaled with very large LSBs

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Scaled index signals are rescaled to LSB = 1. If the rescale

operation requires
a 64 bit operation code generation aborts with a fatal error like
the following:
Internal Fatal #99003: <blockname>
Internal error, error code 99003. Please contact dSPACE
technical support.
Example:
Suppose the control input of a Multiport Switch block is driven
by a signal
which has type Int16 and is scaled with LSB = 2^18. The
result of the rescale
operation (index<<18) requires 16 + 18 = 34 bit. The next
available word width
is 64 bit.
Blocks which use input signals as indices within their code
patterns are:
- Assignment
- Selector (with external index input)
- Multiport Switch
Workaround: Do not use very large LSBs for index signals.
ID:
KPR.2009.04.16.001
Title:
Output of a Look-Up Table is not autoscaled even if axis and

table are completely specified

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Output of a Look-Up Table block is not autoscaled, if

- axis and table are completely specified, i.e. via Data
Dictionary Variable
object
-- AND -- output.width = -1, i.e. the scalar expansion flag is set, when
the dialog is
opened
Workaround: Use the "Scale table" button
136 / 1260
ID:
KPR.2009.04.28.001
Title:
Code generation may abort with fatal error due to special

muxed signal routing and activated vector optimization

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is the following situation:

- The Code Generator option "EfficientVectorHandling" is "on"
-- AND -- some signals are muxed together
-- AND -- this muxed signal does not contain any code generating
blocks and is branched
onto two further Mux blocks
-- AND -- those two further Mux blocks also have other different input
signals
-- AND -- the output signal dimension of those two Mux blocks is
greater or equal than
the LoopUnrollThreshold.
Code generation may abort with one of the following fatal
errors:
- Fatal #10007: Internal error. Error code:
TlCDfaOutPropBlockVisiter 999.
Contact dSPACE's technical support team.
- Fatal #99999: An exception occurred during code
generation. Contact dSPACE
technical support.
Workaround: Set the Code Generator option "EfficientVectorHandling" =
"off".
patches:
TargetLink 2.3.1p5
137 / 1260
ID:
KPR.2009.04.29.001
Title:
Name macro $L expands to the block name instead of the

signal name although the signal has a label set

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The name macro $L in the name of the output variable of the
Outport block or the
name of an input variable of a Stateflow Chart or Custom
Code block is not
correctly evaluated if
- the block input is connected to the output of the Selector
block
-- AND -- the Selector block selects a signal for this port which has a
label set.
Instead to be replaced by the label of the signal selected by
the Selector block
it is replaced by the block name of the Outport block,
Stateflow Chart or Custom
Code block.
Workaround: Place a virtual subsystem with a direct inport outport
connection between the
output of the Selector block and the input of the Outport block,
Stateflow Chart
or Custom Code block.
ID:
KPR.2009.04.29.002
Title:
Preprocessor control flow is not generated for an enabled

subsystem with another enabled subsystem inside

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An enabled or Action Port triggered subsystem X with option

"States when
enabling" or "States when execution is resumed" set to "held"
cannot be called
via preprocessor control flow if inside X there is another
enabled or Action
Port triggered subsystem Y with option "States when enabling"
or "States when
execution is resumed" set to "reset".
Warning #31842 will be issued.
Workaround: - Convert X to a Function Call triggered subsystem.
- Take a State Chart, model the origin enable condition resp. If
condition
inside the State Chart, and let call X by the State Chart with
this condition.
138 / 1260
ID:
KPR.2009.05.07.001
Title:
Code generation aborts or incorrect code may be generated if

a Merge block is behind a reused Stateflow Chart

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow Chart is a reused unity (not part of a reused

subsystem) and one
output in at least one instance of that reused Chart is
connected to a Merge
block, and the Merge block is driven by another block, one of
the following
errors may occur:
- Code generation aborts with
Fatal arror #99999: An exception occurred during code
generation. Contact
dSPACE technical support.
- TargetLink may generate wrong code that may result in
differences between MIL
and SIL.
Workaround: Insert another block (e.g. a Gain block or a Rescaler block)
between the Chart
output and the Merge block.
patches:
TargetLink 2.3.1p2
139 / 1260
ID:
KPR.2009.05.13.001
Title:
The error message "A virtual bus cannot be logged if it was

created within an upstream conditionally executed subsystem
from a nonvirtual bus that was input to the subsystem"
appears during MIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: During MIL simulation the error message

"Unable to log virtual bus at port '1' of block '<Block path>'. A
virtual bus
cannot be logged if it was created within an upstream
conditionally executed
subsystem from a nonvirtual bus that was input to the
subsystem" may appear, if
all of the following conditions are fulfilled:
- The simulation is started in MATLAB >= R2008b AND
- a BusInport block or BusOutport block is logged AND
- at least one member of the bus signal has passed a
conditional subsystem which
is - except of its port blocks - empty.
Note: Simulink cannot log a signal correctly which passes a
conditional
subsystem and which is not changed by any block. The signal
is logged
continuesly without being affected by the condition. In
MATLAB versions prior to
R2008b, this problem didn't lead to an error message.
Since MATLAB >= R2008b, Simulink now stops simulation
with this error message if
this kind of modelling is used and a test point is added to the
affected bus
signal. This case cannot be intercepted by TargetLink.
Workaround: The following solutions are possible to avoid this problem:
- In TMW release R2011a or newer, the alternative Dataset
logging format can be
selected in the Simulink Simulation Configuration. This format
is not affected
by this problem.
- If an additional block (e.g. a Simulink Data Type Conversion
block) is added
to the signal within the empty conditional subsystem, the
problem doesn't appear
anymore. But this may modify the simulation behavior,
therefore it must
becarefully checked, if such a modification is sufficient.
- If changing the model is not desired, the affected bus port
block may not be
logged.
- If the global log setting "log signal histories" is activated and
changing the
model is not desired, the tool tl_create_blacklist can be used
to avoid the
affected bus signal from being logged automatically.
140 / 1260
ID:
KPR.2009.05.18.001
Title:
Name of bus signal gets lost, if a Bus Creator block directly

succeeds an AUTOSAR port (Runnable In/Outport, SWC
Sender/Receiver port)

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Bus Creator block directly succeeds an AUTOSAR port

(Runnable In/Outport,
SWC Sender/Receiver port) and a label exists for the singal
line between the Bus
Creator block and the AUTOSAR port, the signal name gets
lost. This can lead to
the following error during code generation:
Error #20160: Selected signal for Bus Selector outport X not
found.
Workaround: Insert a Gain block with gain factor 1 between the Bus Creator
block and the
AUTOSAR port.
141 / 1260
ID:
KPR.2009.05.19.001
Title:
Erroneous moving of write access into conditionally executed

control flow branch if uses are "hidden" via pointer access

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable A is explicitly used in one conditionally executed

control flow
branch and a variable aliasing A is used in a parallel control
flow branch, then
a writing access to A can be erroneously moved into the
former branch.
Example:
struct SomeType S;
S.A = in;
if (Cond) {
out = S.A + x;
} else {
out = foo(&S);
}
with
foo (struct SomeType* pS) {
return pS->A + y;
}
is incorrectly optimized to
struct SomeType S;
if (Cond) {
S.A = in;
out = S.A + x;
} else {
out = foo(&S);
}
Situations of this kind typically stem from Stateflow Charts
within library
systems subject to function reuse. Pointer-to-struct allows for
the same type of
situations. If A has a variable class with set MERGEABLE
Optimization flag or
Data Store Memory variables are used, then this situation can
also be occur
outside of Stateflow Charts.
Workaround: Assign a variable class with unset MOVABLE Optimization
flag to A.
If the moving should be performed but the extent of moving is
to be limited, use
non-ERASABLE, non-MOVABLE intermediate variables
placed to prevent moving into a
forbidden control flow branch.
142 / 1260
ID:
KPR.2009.05.26.001
Title:
EPS graphics in the RTF documentation generated under

MATLAB R2009a are to small

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: EPS graphics in the RTF documentation generated under

MATLAB R2009a are to
small. This is because the bounding box of the EPS graphics
is wrong calculated.
The zooming into the graphics by means of the EPS viewer
tools, for example
gsview, to show the graphics details is still possible.
Workaround: 1. Use the PNG graphics format in the generated
documentation
For this reason open the script you use to generate the RTF
documentation,
tldoc_rtf by default, and change in the option
"GraphicsFormat" of the tldoc
"Convert" function from eps to png
2. If possible generate the documentation in other MATLAB
version supported by
the currently used TargetLink version.
3. Apply the patch that is provided by The MathWorks, see
http://www.mathworks.com/support/bugreports/597979
ID:
KPR.2009.05.29.001
Title:
Code generation aborts on FIR Filter block with only one

coefficient and consequently for Transport Delay block with 0
delay

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation aborts on an FIR Filter block with a single

(scalar)
coefficient. This is not how the FIR Filter block is used
typically, but the
problem may more likely arise in the context of the Transport
Delay block from
the Sample Blocks (tlsamples) model which is implemeted as
a masked FIR Filter
block. If the parameter "Number of delays" is set to 0 to
temporarily disable
the delay without removing the block, code generation will
abort.
Workaround: - Do not use an FIR Filter block for "direct feedthrough only"
use case
- Only use Transport Delay block for "Number of delays" > 0
143 / 1260
ID:
KPR.2009.06.15.001
Title:
Unspecific fatal error #10007 occurs when using a variable

class with Macro = "on" for data-varianted variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable class with Macro = "on" is used for a datavarianted variable,
code generation aborts with a fatal error #10007.
Example:
Fatal #10007: Internal error. Error code: TL_SymbolServer
283. Contact dSPACE's
Workaround: Do not use a variable class with Macro = "on" for datavarianted variables.
ID:
KPR.2009.06.15.002
Title:
Wrong code may be generated when the state encoding

method "MinimizedOneHotEncoding" is used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
144 / 1260
Description: The code generator option "SfStateEncoding" is used to

choose between the three
state encoding methods: "TL1Compatible" (default),
"MaxMerged" and
"MinimizedOneHotEncoding".
Setting it to "MinimizedOneHotEncoding" specifies that the
state activity flags
will be allocated in such a way that for the substates of a state
with exclusive
decomposition and exactly two substates only one flag is
created, if possible.
For example, if states A and B are the only substates of state
C, code like the
following will normally be generated:
if (C_active) {
if (A_active) {
/* execute A */
} else {
if (B_active) {
/* execute B */
} else {
/* neither A nor B are active */
}
}
}
In most cases the final else branch is unnecessary, because
the activity of C
implies the activity of A or B. In these cases the setting
"MinimizedOneHotEncoding" should eliminate the activity flag
for B:
if (C_active) {
if (A_active) {
/* execute A */
} else {
/* execute B */
}
}
However, the validity of this optimization is not determined
correctly in some
cases. Flags can be erroneously eliminated for example:
- if an event is broadcast in the entry or exit action of C
- if an event is broadcast in the default path of C
- if an event is broadcast in a transition action between A and
B (C is active
and will be executed, A and B are inactive at the same time)
- if C is the chart (A and B being inactive imply that no state
has yet been
entered)
On the other hand, optimization opportunities can be missed if
either A or B is
the target of a default transition.
Workaround: Select "MaxMerged" or "TL1Compatible" for the value of the
"SfStateEncoding"
option.
145 / 1260
ID:
KPR.2009.06.15.003
Title:
Wrong RTE API calls are generated within the subfunctions

called by AUTOSAR runnables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the subfunctions called by an AUTOSAR runnable are

generated into other
module as the runnable, the RTE API calls are not correct.
For example, instead of the operation call
Rte_Call_<port>_<operation>,
Rte_Call_<swc name>_<port>_<operation> is generated.
This happen if the AUTOSAR runnable is modelled as follows:
1. The subsystem where a Runnable block resides in contains
further Simulink
subsystems
2. The subsystems within the Runnable subsystem contain a
TargetLink Function
block
3. In the Function block a module is specified, which is
different to the module
where the runnable has to be generated in
4. In the subsystems within the Runnable subsystem calls to
RTE API are
modelled, for example calls to client-server operation
Note:
Even if the RTI API calls are not correct, the generated
production code can be
compiled and simulated in TargetLink environment, but not in
in AUTOSAR
environment.
Workaround: Specify an identical module for the runnable and the
subfunctions.
146 / 1260
ID:
KPR.2009.06.15.004
Title:
Name of bus signal may not be propagated through

TargetLink subsystem border

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The name of a bus signal at the outport of the TargetLink

subsystem is not
propagated through the TargetLink subsystem border in
SIL/PIL simulation mode if
all of the following conditions hold:
- The TargetLink OutPort block, that specifies the interface in
not placed on
root level
-- AND -- The bus signal name is specified between the interface port
and the Simulink
outport on TargetLink root level.
(Note: this situation especially occurs in AUTOSAR mode, if
the signal name is
specified behind a SWC sender port)
Workaround: Specify a bus signal name infront of the TargetLink outport
that specifies the
interface of the TargetLink subsystem.
ID:
KPR.2009.06.15.005
Title:
Wrong simulation results of PreLook-Up Index Search block

due to faulty TLC script

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: TargetLink's PreLook-Up Index Search block is implemented

as an S-function. To
enable code generation in a prototyping environment or for
model referencing a
TLC script is necessary. However, for the search method
'Binary search' this
leads to wrong simulation results.
Workaround: Don't use the search method 'Binary search' if you want to
generate code for the
PreLook-Up Index Search block in a prototyping environment
or applying model
referencing.
For a solution please contact the dSPACE TargetLink support.
patches:
TargetLink 2.3.1p2
147 / 1260
ID:
KPR.2009.06.15.006
Title:
Code generation aborts on pointer-to-struct component which

is used inside a reused system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a pointer-to-struct component is used inside a reused

system the code
generation may aborts with a fatal error #30016 or an access
violation.
Examples:
Fault address: 2422EA45 01:0002DA45
D:\TargetLink\released\TL3.0\Matlab\Tl\bin\XcgExprDes.dll
Call stack:
Address Frame
2422EA45 00D0BC70 0001:0002DA45
24228289 00D0BCD8 0001:00027289
Fatal #30016: / ... /Variables/MyS:
An internal error occurred during implementation of function
reuse. Contact
dSPACE support. Reason: The variable 'MyS' shall be used in
the subsystem
'Subsystem/ReuseSubsystem1'. But it was created for the
subsystem
'Subsystem/ReuseSubsystem2'. Reuse of this variable is not
possible.
Workaround: Set the name template of the pointer-to-struct root to a fixed
actual parameter
name, e.g. "$D:AP_$D"
148 / 1260
ID:
KPR.2009.06.17.001
Title:
Wrong code if a loop variable of a Stateflow loop is saturated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow variable has the checkmin and/or checkmax

properties set to "on",
every assignment to this variable on the left hand side will be
saturated.
If this variable is used as loop variable of a Stateflow loop one
of the
following results may occur:
- The resulting loop might be endless
-- OR -- The resulting loop will be eleminated
-- OR -- The saturation will be omitted
Workaround: Do not saturate loop variables.
ID:
KPR.2009.06.17.002
Title:
Erroneous optimization of state variable with automatic

storage duration used in relation inside loop

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
149 / 1260
Description: If a state variable is initialized or reset prior to loop execution

and there is
control flow preceding the reading access to the variable, then
TargetLink may
"overlook" the state update inside the loop as influencing the
value of the
state variable. If the state variable is used in a logic or relation
operation,
then it is possible that this operation is replaced based on the
initial value
of the state variable.
Example:
MyState = 1;
for (Sa1_Iterator = 0; Sa1_Iterator < 5; Sa1_Iterator++) {
...
do {
...
} while (...);
...
Sa2_Relation = (MyState != 0);
...
MyState = SomeVal;
}
In this case, "(MyState != 0)" is replaced by "1". Moreover,
subsequent
optimizations may remove the now superfluous assignments
to "MyState".
This kind of situation can occur if an iterated subsystem has
"States when
starting" set to "reset" or for Stateflow Charts.
Note that scope reduction may reduce the storage duration of
a variable from
static to automatic in these settings.
Workaround: 1. Use a variable class with Storage = "static" or Scope =
"global" and unset
Optimization flag "SCOPE_REDUCIBLE" for affected
variables.
This effectively makes the setting "States when starting" =
"reset" useless with
respect to RAM consumption.
2. Use a variable class with Info = "adjustable". This prevents
utilizing range
information.
patches:
TargetLink 2.3.1p2
150 / 1260
ID:
KPR.2009.06.17.003
Title:
Work variable of Custom Code block is implemented with

global scope even if specified as local

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a work variable in the block dialog of a Custom Code block

is specified to
have a variable class with Scope = "local", then during code
generation a
warning like the following is issued:
Warning #17293: Path/To/CcBlock:
The variable class NOPT_LOCAL has the property local,
which would lead to
erroneous code for variable cc_w. The property will be
ignored.
As described by the warning, the work variable is generated
as global. This
creates unnecessary global variables, where only local ones
would suffice.
Workaround: If the variables are used only in one Custom Code section,
then define the
variables in the custom code template file instead.
There are two viable ways for this:
1. Do not add them to the Custom Code interface, i.e. do not
specify them via
the Custom Code block dialog. Due to the emitted braces
around custom code
sections that may contain such variables, there is no
possibility of a name
clash between work variables of the same Custom Code file.
2. Specify a variable class with property Alias = "on" and
Scope = "global".
This leads to proper replacement of the work variable identifier
but no
TargetLink generated variable definition or declaration.
151 / 1260
ID:
KPR.2009.06.18.001
Title:
Wrong access to structure in Data Store Read block or Data

Store Write blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A variable of type 'struct' is specified in the Data Dictionary

and its variable
class has a Scope = "ref_param". One of its components is
referenced in a Data
Store Memory block.
A Data Store Read block or a Data Store Write block is placed
in a different
subsystem than the corresponding Data Store Memory block.
The subsystem is
specified to be "atomic", or it does contain a Function block.
In this case TargetLink generates incorrect code for the Data
Store Read/Write
block. The code is incorrect, because it accesses the struct
component directly
instead of accessing the struct component by a pointer to this
struct.
If TargetLink generates a function for the subsystem
containing the Data Store
Read/Write block, this function does not have a function
parameter of type
pointer to struct.
Workaround: Place the Data Store Memory block in the same subsystem as
the Data Store
Read/Write block.
152 / 1260
ID:
KPR.2009.06.18.003
Title:
Code generator aborts when using an unspecified Stateflow

input in a condition

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may abort with an access violation if the

following conditions
are fulfilled:
- In a Stateflow chart, a condition is used which consists
entirely of a chart's
input variable, for example [A]. More complex constructs like
[!A] are not
affected.
- For TargetLink versions pripor to 3.0: there are no
TargetLink properties
specified for A, for TargetLink 3.0: the TargetLink property
"CreateInputVariable" is not set or set to "off".
- The chart input A is fed by the output of a Constant block.
- In the Constant block dialog, the variable class is set to
"default".
- Optimization is disabled.
Workaround: Specify a variable class in the Constant block (e.g. MACRO)
or replace the
condition by [A != 0].
ID:
KPR.2009.06.18.004
Title:
Wrong code if arithmetic operation with a constant is

cancelled out by rescaling while transfering operand from float
to integer

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
153 / 1260
Description: TargetLink will generate wrong code if the following conditions

hold:
- A floating-point operand is part of a binary operation
-- AND -- The other operand of this operation is a constant value
(Constant block with
default class)
-- AND -- The result of the arithmetic operation is fixed-point
-- AND -- The arithmetic operation is cancelled out by rescaling.
Example 1:
Float32 In;
Int16 GainOut; // LSB = 2
GainValue = 2;
=>
GainOut = In * GainValue / LSB;
=>
GainOut = In * 2 / 2;
=>
GainOut = In;
This is the expected statement, but TargetLink will generate
incorrect code.
Example 2:
Float32 In;
Int16 SumOut; // LSB = 1, Offset = 1
ConstantSummand = 1;
=>
SumOut = (In + ConstantSummand) / LSB - Offset;
=>
SumOut = (In + 1) / 1 - 1;
=>
SumOut = In;
This is the expected statement, but TargetLink will generate
incorrect code.
This can happen
- for multiplications (Gain, Product block), if LSB(Out) /
ConstantValue == 1
- for divisions (Product block), if the second operand is a
constant value and
LSB(Out) * ConstantValue == 1
- for additions (Sum block), if ConstantValue - Offset(Out) == 0
- for subtractions (Sum block), if the second operand is a
constant value and
ConstantValue + Offset(Out) == 0
- for subtractions (Sum block), if the first operand is a constant
value and
ConstantValue - Offset(Out) == 0
patches:
TargetLink 2.3.1p2
154 / 1260
ID:
KPR.2009.06.18.005
Title:
Model Preparation with referenced models might fail when

using the save option

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Model Preparation fails when the following conditions are met:
- referenced models are also prepared (PrepareRefMdls option
is set to "on")
- models are saved after preparation (Save option is set to "on")
- a model is referenced by more than one model block in the
system that should
be prepared
- the $ macro is used to specify a new name for the saved
model (for example,
the prepSystem option is set to "$_tl" (which is default))
In this case, Model Preparation aborts with an error similar to
Enhancing Ref2_tl/Out1 done!??? Index exceeds matrix
dimensions.
Error in ==>
D:\tl_30_install\matlab\tl\tools\tl_prepare_system.p>FcnPrepare
at
683
and preparation remains incomplete.
Workaround: 1. Do not use the save option. Save manually after preparation
using Simulink's
Save as menu.
2. Prepare referenced models individually as opposed to
prepare them with the
referencing model.
ID:
KPR.2009.06.18.007
Title:
Stateflow auxiliary variables are not passed into node

functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
155 / 1260
Description: Complex flow chart graphs are broken into node functions
during code generation.
Local variables that are used in more than one function are
passed by reference.
The mechanism to add the necessary parameters to the
function definitions and
arguments to the function calls, however, works only for
variables defined in
the Stateflow model explorer. It does not work for auxiliary
variables which are
implicitly created by the Code Generator.
If an auxiliary variable is used by more than one function,
each function will
contain its own local version of the variable. The value will not
be passed into
or out of other functions.
Example:
A common situation for the creation of auxiliary variables is a
function call in
a transition condition. Assume that for the junction marked (*)
a node function
is created.
(*) [getValue() < 0]
---->O-------------------->O--->
|
V
O
The TargetLink code generator creates an auxiliary variable to
capture the
return value of the getValue function. The generated code will
look like this:
Int16 AUX = getValue();
Node_Fcn();
...
void Node_Fcn() {
Int16 AUX;
if (AUX < 0) {
...
}
}
Note the obvious problems with this code:
1. The return value of getValue() is not used in the condition.
2. The variable AUX is not initialized before use in Node_Fcn,
so the behavior
is unpredictable.
156 / 1260
Workaround: Manually lift the function call out of the condition. The example
can be
remodeled as
{value=getValue();} (*) [value < 0]
--------------------->O-------------------->O--->
|
V
O
The generated code will then look like this:
value = getValue;
Node_Fcn(&value);
...
void Node_Fcn(Int16 *value)
{
if (*value < 0) {
...
}
}
Otherwise avoid the creation of node functions, if possible.
Flow charts should
be built according to structured programming rules, i.e.
constructs should
usually have a single entry and a single exit. Refer to the
Advanced Practices
Guide > Working with Stateflow > Flowchart Style Guide for
recommended patterns.
157 / 1260
ID:
KPR.2009.06.18.008
Title:
An overflow warning appears although the user constrained

limits (Min, Max) are not visible in the block dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: During a MIL simulation a parameter overflow warning

appears (e.g. for a row
index vector of a Look-Up Table (2D) block). But the
parameter value is not
outside of the the scaling range and the block dialog doesn't
show constrained
limits (Min and Max) for this parameter. The constrained limits
can be seen from
the TargetLink Property Manager.
Rationale:
User constraints for parameters have to be evaluated only if
the variable is
calibratable.
A variable is calibratable if its variable class contains a
reference to a Data
Dictionary VariableClass object with property "Info" =
"readwrite".
This can be e.g. the VariableClass object CAL.
It is correct, that user constraint entries (Min and Max) are
disabled for
non-calibratable parameters in the block dialog.
But it is wrong, that the overflow detection is considering the
(invisible)
constraint values for non-calibratable parameters.
Workaround: - Change the variable class temporary to a calibratable class,
so that user
constraint values for Min and Max are visible
- Remove the constraint values
- Restore the original variable class
158 / 1260
ID:
KPR.2009.06.18.009
Title:
Erroneous warning #17412 about inital value outside

constrained range if the initial value is close to the limits of the
constrained range

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Due to floating-point calculation effects, a warning #17412

about the inital
value of a variable lying outside of associated constrained
range can
erroneously be issued for a variable, if the initial value is the
same or very
close to one of the constrained ranges limits.
Example:
Int16 Var; //with LSB = 0.01, Min = 0.0, Max = 5.1 and Value =
5.1
In this case the initial value (5.1) can easily be represented
using type and
scaling of the variable and the generated code will be correct
containing the
right representation of the value. Although the value clearly
lies within the
given constrained range, the Code Generator might issue a
message saying
that it doesn't. The warning looks like the following:
Warning #17412: Subsystem/OutPort:
Variable signal2 has an initial value 5.1 and a calibratable
range [0 5.1]. Due
to scaling and rounding effects, the scaled initial value 5.1 is
outside the
constrained range.
159 / 1260
ID:
KPR.2009.06.18.010
Title:
Download of application may fail on TSM MPC5554DEMO\GNU

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A download of a target application for PIL simulation may fail with
following
message:
E02240: LOADING APPLICATION FAILED.
This is likely if some functions from the GCC cross-compiler
library, like
__divdi3 (divide two signed quads), are used in Custom Code.
Workaround: Locate explicitly the compiler error handling section .eh_frame in
the
corresponding Linkcmd.lk file, e.g.
%DSPACE_ROOT%\Matlab\Tl\SimFiles\MPC5554DEMO\GNU34
ID:
KPR.2009.06.18.011
Title:
Code generation aborts on reused boolean variable in global

bitfield structure

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation aborts with an access violation if all of the

following
conditions for a boolean variable are fulfilled:
- The variable has a fixed name (no $R, $C oder $S name
macro)
-- AND -- The variable resides in a reused system
-- AND -- The data type is bool and the option "Use global Bitfields for
boolean" is
selected
Workaround: - Select a variable class with Scope = "value_param" or Scope
= "ref_param" for
that variable
-- OR -- Avoid one of the threee conditions that have to be fulfilled,
e.g. unselect
the option "Use global Bitfields for boolean".
patches:
TargetLink 2.3.1p2
160 / 1260
ID:
KPR.2009.06.18.012
Title:
Code generation aborts or yields to incorrect code for Merge

block driven by vector signal only consisting of vector
components

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a vectorized signal consisting of equal vector component

accesses, e.g.
(ExampleVar[4], ExampleVar[4], ExampleVar[4],
ExampleVar[4], ExampleVar[4])
which might be created by a selector block, drives an atomic
subsystem
- which only contains unspecified ports, e.g. Simulink Inport
and Simulink
Outport
-- OR -- where the signal drives an unenhanced Simulink Inport
directly
followed by a Merge block.
In such situation code generation yields to one of the following
results:
1. Fatal error #10020 (leda exception) if the width of the
variable where the
vector components result from (in the example above the
width of ExampleVar) is
smaller than the signal width at the Merge block.
2. Incorrect but compilable code if the width of the variable is
greated or
equal than the signal width at the Merge block.
Example:
for (Aux_ = 0; Aux_ <= 4; Aux_++)
{
/* update of variable(s) associated with Caga1/CABC/IN [0..4]
*/
Merge[Aux_] = ExampleVar[Aux_];
}
The correct statement would be Merge[Aux_] =
ExampleVar[4];
Workaround: Insert a TargetLink block which has an output variable (e.g.
Rescaler,
TargetLink OutPort, Gain etc.) between the Simulink Inport of
the atomic
subsystem and the Merge block.
patches:
TargetLink 2.3.1p2
161 / 1260
ID:
KPR.2009.06.18.013
Title:
Incorrect code due to unary bit operation for scaled variable in

Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink does not support bit operations on scaled or

floating-point operands.
If a binary bit operation with at least one operand being scaled
(LSB != 1.0
and/or Offset != 0.0) is specified by the user, TargetLink will
issue an error
message. Nowever, for the unary bit operator ~ this error
message will not be
issued and incorrect code will be generated.
Workaround: Do not specify unary bit operations on scaled or floating-point
operands.
162 / 1260
ID:
KPR.2009.06.18.014
Title:
Implicit variable merge leads to incompilable code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A subsystem contains a block and a nested subsystem

containing two other blocks.
The names of the blocks' block variables are fixed and
identically. There
specifications differ in the Storage properties of the selected
variable classes
only:
1. In the containing subsystem, the variable has storage
"extern",
2. In the nested subsystem the variable of the block, whose
name is in
alphanumerical order lower than the other block's name, has
storage "default",
3. and in the nested subsystem the variable of the block,
whose name is in
alphanumerical order greater than the other block's name, has
storage "extern".
Additionally, the code of the nested subsystem is to be
generated in a different
file than the code of the containing system.
In this case, TargetLink generates just one variable for those
three blocks. But
the code is not compilable, because there is just a declaration
of the variable,
but no definition.
Workaround: Specify for each block variable the same Variable Class with
storage "default",
and Optimization flag "MERGEABLE".
Or rename the blocks in the nested subsystem, so the
alphanumerical order of the
blocks' names in the nested subsystem reverses.
163 / 1260
ID:
KPR.2009.06.19.001
Title:
Error 10014 without any prior messages

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If not all components of a Data Dictionary struct variable are

used in the model
and if one or more of the unsed components have an invalid
Class property (i.e.
the property points to non-existing variable class), TargetLink
emits
Error #10014: The code generation process failed. Check the
error messages above
for further details.
But there are no error messages above. Any prior warnings
are not related to
#10014.
Workaround: Ensure that the Class properties of the struct component
points to a existing
variable class.
ID:
KPR.2009.06.19.002
Title:
Autoscaling may use incorrect propagated simulation values

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The calculated scaling using simulated ranges may be wrong,

if the blocks output
is connected with one input of a MinMax block, a Multiport
Switch block or a
Switch block and additionally to any other block.
Workaround: Scale the affected block manually and set the autoscaling
mode to "No
autoscaling".
164 / 1260
ID:
KPR.2009.06.19.003
Title:
Incorrect code for index expression of scaled and saturated

Stateflow assignment

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An index expression will be calculated incorrect if all the

hold:
- A Stateflow variable is saturated (properties checkmin and/or
checkman = 1)
and scaled (LSB != 1.0 and/or Offset != 0.0)
-- AND -- This variable is used on the left hand side of an assignment
-- AND -- The assignment contains an index expression that is an
operation
In this case the index expression will be implemented in the
scaling of the left
hand side variable.
Workaround: Introduce an auxiliary variable to hold the index expression.
patches:
TargetLink 2.3.1p2
ID:
KPR.2009.06.19.004
Title:
Error message #17261 during code generation for Stateflow if

a function param variable is created from a Data Dictionary
variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow data object is associated with a Data Dictionary

variable with
variable class Scope ref_param or value_param an fatal error
may occur during
code generation like the following example:
Fatal #17261:
TEST/TEST/TEST_SF.map_data_256 Internal problem with
the variable TABLE
concerning the class property MergeCAL_REF_PARAM
Workaround: Remove the Data Dictionary reference or change the variable
class to one with
Scope global.
165 / 1260
ID:
KPR.2009.06.19.005
Title:
Code Generator writes UUID into Config area of Data

Dictionary

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During code generation for AUTOSAR the Code Generator

writes UUID properties
into the Unit objects stored in the Config area of the Data
Dictionary. This
happens only for those Unit objects that have the write access
right set. If
only read access is allowed the object remains untouched.
In general the UUID of a Unit object is exported during
AUTOSAR export. This is
not possible for a Unit object without write access right,
because there no UUID
can be written by the Code Generator. Hence no UUID is
exported and missing in
the AUTOSAR-XML file.
166 / 1260
ID:
KPR.2009.06.19.006
Title:
Incorrect code for unary minus and saturated destination

variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Incorrect code will be generated if following conditions are met

in a Stateflow
Chart
- The variable/macro on the right hand side of an assignment
has the checkmin
and/or checkmax property set to "on"
-- AND -- The last operation on the right hand side of the assignment
is a unary minus
-- AND -- The result of the unary minus can be represented in the data
type of the left
hand side of the assignment.
Example:
Int16 A; /* checkmin = "on" */
Int32 B;
A = -(B)
In this case the resulting code can be
Int32 Aux_S32;
Aux_S32 = -((Int32) b);
a = C__I32FITI32_SAT(Aux_S32, 2147483647 /*
8191.999996 */)
which does not compile since the macro C__I32FITI32_SAT
does not exist.
Workaround: Disable superfluous saturation (set checkmin/checkmax to
"off").
patches:
TargetLink 2.3.1p2
167 / 1260
ID:
KPR.2009.06.22.001
Title:
Incorrect multiple inlined code if option

"TreatAllForcedAtomicSubsystemsAsWeakAtomic" is enabled

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink provides the option

TreatAllForcedAtomicSubsystemsAsWeakAtomic which
in the context of loop optimization allows the merging of loops
containing the
code of inlined functions.
This can yield to incorrect code if following conditions met:
- The option
"TreatAllForcedAtomicSubsystemsAsWeakAtomic" is set
-- AND -- Inlined functions (subsystems) contain inlined functions
(subsystems)
-- AND -- The inner inlined function allows loop merging but the parent
inlined
subsystem does not allow loop merging.
Criteria for merging loops are:
- both loops must reside in the same control flow branch in the
generated code
- no other code is placed between those loops
- the iteration range is equal
- the loop iteration variables can be shared
- merging the loops does not violate data flow
Workaround: Unselect the option
"TreatAllForcedAtomicSubsystemsAsWeakAtomic" (="off") or
avoid inlining the critical subsystems.
patches:
TargetLink 2.3.1p2
168 / 1260
ID:
KPR.2009.06.22.002
Title:
Messages from Code Generator are removed by messages

issued during compilation of production code and simulation
S-function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If the production code application for SIL/PIL simulation is built

by calling
the API command tl_build_host/tl_build_target or via the
TargetLink Main Dialog
> Build Host/Build Target button, the messages generated
during compilation of
the production code application and the simulation S-Function
(if any) removes
Code Generator messages from the TargetLink Message
Browser and TargetLink
message queue.
As result only these last messages are shown in the
TargetLink Message Browser.
ID:
KPR.2009.06.22.003
Title:
Instance-specific structures (function reuse) are not initialized

in AUTOSAR software component init functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Components of instance-specific structures due to reuse

whose variable classes
have set "RestartFunctionName" to "default" are initialized
inside the main
restart function instead of the AUTOSAR software component
init function of the
AUTOSAR Software Component they belong to.
patches:
TargetLink 2.3.1p3
169 / 1260
ID:
KPR.2009.06.22.004
Title:
Code generation aborts for custom look-up function if one pointer type has a type prefix
and one not but the base type is of same type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Error for more than one Look-Up Table block and/or Stateflow customer specific
function where one is using a pointer type with type prefix and another one is
using a pointer type without a type prefix. This can occur for different custom
look-up functions or for one custom look-up function that is used for more than
one Look-Up Table block and/or Stateflow customer specific functions.
An error similar to the following will be thrown:
Error #30052: User script object UInt16_cPtr of block Interpolate_speed_map,
//DD0/Subsystems/CGTmpData/tlscript_Interpolate_speed_map1/Typedefs/UInt16_cPtr
Two different types with the same name have been specified in custom function
scripts. Make sure that the types match. This message can also come up if a type
has been defined in different template code sections and if these sections
include different files in the first include statement.
Workaround: If you have to use pointer types with the same base type and therefore one with
a type prefix and one without a type prefix, create an additional typedef in the
Data Dictionary's pool area and set the CreateTypedef property to off and the
BaseType property to the base type you want to use.
Now you have to use this new typedef for the custom look-up function at all
places where the pointer with the type prefix is used.
170 / 1260
ID:
KPR.2009.06.22.005
Title:
Compute-through-overflow (CTO) commment in if condition

omitted

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: To support the code analysis tool from Polyspace, TargetLink

offers the Code
Generator option "PolyspaceSupport". If this option is set,
code comments are
inserted whereever TargetLink utilizes compute-throughoverflow.
If TargetLink implements an operation with compute-throughoverflow and this
operation is placed in the condition of an if statement, this
CTO comment will
be omitted.
Operations using compute-through-overflow can be part of an
if condition, if
- they are part of a transition condition in Stateflow
- they originate from a block whose output variable was part of
an if condition
and that was omitted by TargetLink's code optimization
Workaround: Avoid CTO operations in if conditions, i.e. introduce auxiliary
variables or
make omitted block output variables non-erasable.
patches:
TargetLink 2.3.1p2
171 / 1260
ID:
KPR.2009.06.22.006
Title:
The generation of model-linked code view may fail when

specific address qualifiers are used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The generation of model-linked code view may fail when user
or compiler specific
address qualifiers like __rptr, __dptr, etc., specified via
TargetConfig.xml,
are used. In this case warnings like following may appear:
HTML Generator: Parsing Error (1104) while parsing the file:
Subsystem.c.
Syntax error at '__rptr' in line 176.
Please contact dSPACE technical support.
HTML Generator: File .\CodeViewFiles\Subsystem.c.js could
not be written
completely.
*** W04301: CODE VIEW FILE CANNOT BE GENERATED:
*** The HTML code view file for the production code file
*** 'Subsystem.c'
*** could not be generated completely.
Workaround: Do not use such address qualifiers, otherwise no workaround
available.
ID:
KPR.2009.06.22.007
Title:
User defined scaling erroneously qualified as VOID_SCALING

in Data Dictionary's Subsystems area

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: A block variable's scaling that has been specified by the user
inside the block
settings and that has the properties LSB = 1 and Offset = 0,
but a non-empty
Unit is qualified as VOID_SCALING inside the Data
Dictionary's Subsystems area.
As a consequence the user specified information about its
Unit is lost.
Workaround: Specify a Data Dictionary Scaling object and reference this
object inside the
block.
patches:
TargetLink 2.3.1p2
172 / 1260
ID:
KPR.2009.06.24.002
Title:
Wrong spelling of RTE access function name template for AUTOSAR

external calibratable variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the access function name template used for calibratable variables in
an
AUTOSAR model, the FunctionName is set to
"Rte_CalPrm_$(Component)_$v". This is
a wrong spelling, because it has to be "Rte_Calprm_$(Component)_$v"
with Calprm
having a lower-case p. The wrong spelling leads to wrong names of RTE
access
functions.
Workaround: As a workaround, you can set the FunctionName of the relevant template
("/Pool/Templates/AccessFunctions/AUTOSAR/CALPRM/Settings/Read")
to
"Rte_Calprm_$(Component)_$v". However, since TargetLink's
AUTOSAR postprocessing
searches for elements case-sensitively, now the RTE access function is
no longer
found. Please contact the dSPACE TargetLink support for a solution.
ID:
KPR.2009.06.24.003
Title:
Incorrect code for relation operation with scaled operands

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Consider a relational operation x1 >= x2 specified in Simulink

or Stateflow with
both operands being scaled.
The scaled relational operation is calculated as x1 * LSB(x1) +
Offset(x1) >=
x2 * LSB(x2) + Offset(x2)
To implement this operation, there are different ways:
A: x1 * LSB(x1) / LSB(x2) + (Offset(x1) - Offset(x2)) / LSB(x2)
>= x2
B: x1 * LSB(x1) / LSB(x2) >= x2 + (Offset(x2) Offset(x1))/LSB(x2)
C: x1 + (Offset(x1) - Offset(x2)) / LSB(x1) >= x2 * LSB(x2)
/LSB(x1)
For these cases each side of the relational operation has a
worst case range.
Let, for example, Range(A, left) be the worst case range of the
left side of the
relational operation for case A.
Then Range(A, right) is the worst case range of the right side
173 / 1260
of the relational
range for case A.
A similar notation will be used for case B (Range(B, left),
Range(B, right)) and
case C (Range(C, left), Range(C, right)).
Type(A) then is the smallest type needed to represent
Range(A, left) and
Range(A, right).
TargetLink might generate incorrect code, if all following
conditions are met:
Condition 1:
- The relational operation is >= or < and LSB(x1) <= LSB(X2)
-- OR -- The relational operation is <= or > and LSB(x1) > LSB(X2)
Condition 2:
- Width(Type(A)) == Width(Type(B))
-- AND -- Type(A) is signed
Condition 3:
- Width(Type(C)) > Width(Type(B))
-- OR -- Width(Type(C)) == Width(Type(B)) and Signedness(Type(C))
!=
Signedness(Type(B))
Example:
x1: UInt16; Min: 4; Max: 20; LSB: 0.001; Offset: 4
x2: UInt8; Min: 5; Max: 17.75; LSB: 0.05; Offset: 5
x1 >= x2 will be implemented as
((UInt16) (a + 64536)) >= (((UInt16) b) * 50)
which is the same as
((UInt16) (a - 1000)) >= (((UInt16) b) * 50).
Casting the result of the subtraction to unsigned in this case is
incorrect.
Workaround: Do not use Offsets.
174 / 1260
ID:
KPR.2009.07.01.001
Title:
Simulation differences or simulation exception because of

uncalled restart function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: When a model contains root step funtions other than the
function of the
TargetLink subsystem itself and the function of the TargetLink
subsubsystem is
eleminated due to optimization and a restart function is
generated for the
remaining root step function(s), this restart function may
remain uncalled
during simulation. This may lead to simulation differences or a
runtime
exception during simulation (e.g. in case of Data Paging due
to an uninitialized
page pointer).
Workaround: Insert a function block on root level of the TargetLink
subsystem, to avoid
elemination of the root function.
ID:
KPR.2009.07.08.001
Title:
Unit not taken into account on floating-point variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If a variable is specified via a block dialog with floating-point

data type and
a Unit, then the Unit is not taken into account e.g. inside the
generated
documentation.
Workaround: Explicitly specify a Data Dictionary Scaling object carrying the
Unit for the
variable.
ID:
KPR.2009.07.08.003
Title:
Code generation aborts with fatal error #10020 at attempt to

eliminate partial vector slice

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: As of TargetLink 2.3.1, TargetLink eliminates intermediate

175 / 1260
variables that just

build up a vector slice even if the assignments to the variable
are partitioned,
e.g. for a Mux and a full vector driving a Switch that leads to a
TargetLink
outport:
if (cond) {
Switch[0] = in1;
...
Switch[9] = in10;
} else {
Switch[Aux_S32] = in11[Aux_S32];
}
}
Out[Aux_S32] = Switch[Aux_S32];
}
the Switch variable is eliminated, leading to
if (cond) {
Out[0] = in1;
...
Out[9] = in10;
} else {
Out[Aux_S32] = in11[Aux_S32];
}
}
If the outport consumes only a part of the Switch vector (e.g.
Switch[<0..6>]),
then this optimization still is performed if the assignment in the
loop fits
this part, e.g.
} else {
Switch[Aux_S32] = in11[Aux_S32];
}
Switch[Aux_S32+7] = in12[Aux_S32];
}
}
Out[Aux_S32] = Switch[Aux_S32];
}
The error situation leading to abort of the code generation
process via
Fatal #10020:
An internal error (LEDA exception: array::entry index out of
range) has occured.
occurs if the reading access of the variable to be eliminated is
only a part,
let say I1, of the whole vector, there is a preceding definition
of exactly the
176 / 1260
same part I1 of the vector, a preceding definition of a smaller

part, let say
I2, of the vector and a preceding definition that exceeds the
upper boundary of
I1 but accesses a part of I1.
Example:
A Switch1 is driven by the full vector and muxed scalar
signals, another,
Switch2, by the first Switch1 and a vector fitting part I1 of
muxed signal
driving Switch1; Switch2 drives a demux giving I1 to an
outport and other
signals to other outports.
After elimination of Switch1, we arrive at
if (cond2) {
if (cond1) {
Switch2[0] = in1;
....
Switch2[9] = in10;
} else {
Switch2[Aux_S32] = in11[Aux_S32];
}
}
} else {
Switch2[Aux_S32] = in11[Aux_S32];
}
...
}
Out[Aux_S32] = Switch2[Aux_S32];
}
In this situation, the code generation may abort; this depends
on internal
orders.
This can occur for all blocks leading to several parallel control
flow branches
(including Logic and Relation blocks); usually, it occurs if
muxing and demuxing
is used where buses could also be used.
177 / 1260
Workaround: Identification: If the error F10020 is thrown and does not occur
for option
OptimizationLevel is 0, then give a non-ERASABLE variable
class to all candidate
blocks, e.g. using the property manager. Candidates are
especially Switch,
Multiport Switch, and Merge Blocks. If the error still does not
occur, identify
the block leading to the problem.
Workarounds:
1. Assign a variable class without set ERASABLE
Optimization property to the
block variable
-- OR -2. If the "Inherit signal properties" block property is used, use
bus signals
where applicable to partition the signal. This also may lead to
more efficient
code than either 1) or a fix for this problem can create.
patches:
TargetLink 2.3.1p2
178 / 1260
ID:
KPR.2009.07.08.004
Title:
Faulty export of ConstantSpecification elements for complex

prototypes

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: TargetLink supports only scalar CONSTANT-SPECIFICATION

elements during import or
export, like INTEGER-LITERAL, BOOLEAN-LITERAL or
REAL-LITERAL elements.
RECORD-SPECIFICATION or ARRAY-SPECIFICATION
elements are not supported.
If the user references a DataElement object from a
DataReceiverComSpec object
which has a structural DataType/Typedef object, the
CONSTANT-SPECIFICATION
element cannot be exported. If the init value property is set,
the exported
AUTOSAR file contains an invalid description of the init value
reference. The
exported AUTOSAR description looks like the following:
<UNQUEUED-SENDER-COM-SPEC>
<DATA-ELEMENT-IREF>
<DATA-ELEMENT-PROTOTYPE-REF
DEST="DATA-ELEMENTPROTOTYPE">/Interfaces/SRI/Struct_DataElement</DATAELEMENT-P
ROTOTYPE-REF>
</DATA-ELEMENT-IREF>
<CAN-INVALIDATE>false</CAN-INVALIDATE>
<INIT-VALUE-REF DEST="">/Controller</INIT-VALUE-REF>
</UNQUEUED-SENDER-COM-SPEC>
The destination attribute is lost and the AUTOSAR reference
path to the
CONSTANT-SPECIFICATION element is incorrect. The
CONSTANT-SPECIFICATION element
does not exist.
Workaround: Do not specify init values for complex prototypes at
DataReceiverComSpec,
DataSenderComSpec or Variable objects in the Data
Dictionary.
179 / 1260
ID:
KPR.2009.07.08.005
Title:
For combination of a PreLookup Index Search block and an

Interpolation (n-D) using PreLookup block with 4 inputs wrong
MAP description is generated in A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: For a combination of a PreLookup Index Search block and an

Interpolation using
PreLookup (n-D) block with 4 inputs wrong MAP description is
generated in A2L
file. In this case for the X-axis as well as for the Y-axis the
variable
generated for the breakpoint data of the Prelookup block
connected to the first
input of the Interpolation using PreLookup (n-d) block is taken
into account.
Example:
/begin CHARACTERISTIC
MyMap
...
/begin AXIS_DESCR
COM_AXIS
...
AXIS_PTS_REF FirstPrelookupBreakpointData
/end AXIS_DESCR
/begin AXIS_DESCR
COM_AXIS
...
AXIS_PTS_REF FirstPrelookupBreakpointData
/end AXIS_DESCR
/end CHARACTERISTIC
The same variable "FirstPrelookupBreakpointData" is
referenced in both
AXIS_DESCR sections.
180 / 1260
ID:
KPR.2009.07.08.006
Title:
Superfluous warning about function name exeeding 31

characters limit

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Under the following conditions warning #19001 ('Identifier

<name> exceeds ANSI C
limit of 31 characters.') is thrown, even if the respective
function is not
generated:
1. In a TargetLink Function block at least one of the function
names for
restart, init or term function has more than 31 characters after
name macro
expansion and the Code Generator option
LimitVariableNameLength is set to 'on'
(e.g. in TargetLink Main Dialog the option 'Code identifiers
max. 31 chars' is
selected).
2. A subsystem without a TargetLink Function block has a
name, so that the
default names for restart, init and term functions
(RESTART_$S_$B, INIT_$S_$B,
TERM_$S_$B) expand to names longer than 31 characters
and the Code Generator
option LimitVariableNameLength is set to 'on' (e.g. in
the option 'Code identifiers max. 31 chars' is selected).
Workaround: Two workarounds are possible:
1. Append a $R name macro to names longer than 31
characters, or do not specify
names name longer than 31 characters.
2. Shorten the name of the subsystem which causes the
warning.
181 / 1260
ID:
KPR.2009.07.08.007
Title:
Code Generation aborts with error #99003 for saturated

addition in Stateflow with 64-bit wide subexpression

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may abort with error #99003, if

- the operand on the left hand side of an assignment has
property checkmin
and/or checkmax set to on (see variable "out" in the example
below)
- the last operation on the right hand side of an assignment is
an addition or
subtraction (see "'(...) + c" in the example)
- an operand of this addition/subtraction is an operation (like
e.g. again an
addition) (see "a + b" in the example) and
- the range of this operation cannot be represented using 32
bit (see "a + b" =>
Int32 + Int16 needs Int64 in the example)
Example:
Int32 a;
Int16 b;
Int32 c;
Int32 out; // checkmin = 1, checkmax = 1
out = (a + b) + c
Workaround: There are several workaround available:
1. Try using brackets to group intermediate results, e.g. "x = x
+ (y + z);"
2. Split multiple operations into multiple lines with one
operation each, e.g.
"x = x + y; x = x + z;"
3. Switch off saturation
patches:
TargetLink 2.3.1p2
182 / 1260
ID:
KPR.2009.07.09.001
Title:
Problems during SIL/PIL simulation of TargetLink subsystem residing in another Simulink

subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The SIL/PIL simulation of a TargetLink subsystem is not possible if all

following conditions are met:
1. The TargetLink subsystem has been created as a copy of an other TargetLink
subsystem for which a production code simulation S-function has already been
built (e.g. using tl_compile_host, tl_build_host, tl_build_target was called for
this TargetLink subsystem)
2. The TargetLink subsystem does not reside at the root level of the model, but
resides in another Simulink subsystem
Following errors may be reported:
- Symbol Address Determination error (#8152)
- Error in S-function <BlockPath>': S-Function <SfcnName> does not exist.
- Segmentation violation at the end of the simulation
Workaround: In MATLAB command window issue following command:
set_param(<simFramePath>, 'Tag', '')
where <simFramePath> is the path to a subsystem in the simulation frame of the
TargetLink subsystem, e.g.
<model>/<OuterSubsystem_1>/.../<OuterSubsystem_N>/<TLSubsystemName>/Subsystem
183 / 1260
ID:
KPR.2009.07.09.002
Title:
Superfluous cast to floating-point type in boolean expression

originating from Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow a conditional operation is specified that consists

of more than
one boolean operation, than superfluous casts to a floatingpoint type can be
generated, if
- one operand of the topmost boolean operation is a variable
with an integer
type and no scaling (LSB = 1.0, Offset = 0.0) or if
- the conditional operation is assigned to a not-scaled integer
variable.
In these cases boolean operations might be cast to a floatingpoint type if,
- they are operands of logical or bitwise operations and if
- they contain floating-point values (e.g. 0.5 but not 5.0) and if
- the other operand of the parent operation is floating-point
(e.g. Boolean
operation with floating-point operands).
Workaround: Introduce auxiliary variable for subexpressions.
184 / 1260
ID:
KPR.2009.07.13.001
Title:
Data Dictionary Manager "Goto target" menu does not work

with DDIncludeFile.DDPath property
Last Update: 03 Mar 2010

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The "Goto target" context menu item in the Data Dictionary
Manager's Property
Value List allows to find the object that is specified with a
reference
property. The DDPath property of DDIncludeFile objects is a
reference property
that specifies points of inclusion (= objects in which included
Data Dictionary
files should be loaded). However, selecting the "Go to target"
menu item for
this property results in an error message similar to
DD Manager: Unexpected type of referred obect
The DD Manager action failed. The message was: Object
"my_DDIncludeFile":
Reference property "DDPath" must point to a object, however,
it points to a
VariableGroup object.
even if the property actually points to an existing object.
Workaround: Ignore the message. The DDPath property always contains a
complete DD path,
which allows to find the target object by browsing the Data
Dictionary object
tree.
185 / 1260
ID:
KPR.2009.07.13.002
Title:
Data Dictionary MATLAB API SyncType command stops if

Constraints.Min or Constraints.Max are missing

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The Data Dictionary MATLAB API SyncType command allows

to synchronize a Data
Dictionary Variable object with its associated Typedef object.
However, if the
Typdef object has a Constraints child object whose Min or
Max property (both
properties are optional) is missing, the function returns an
error code.
Synchronization remains incomplete.
The syntax of the command is
errorCode = dsdd('SyncType',<objectIdentifier>);
<objectIdentifier> specifies the Variable object (by path, or by
handle).
Workaround: 1. Make sure that all Typedef objects that have a Constraints
child object have
a Constraints.Min and Constraints.Max property. The values
of the properties can
be empty. However, this may result in conflicts with the Min
and Max properties
of Variable objects that refer the Typedef.
2. Alternatively contact the dSPACE TargetLink support for a
solution.
186 / 1260
ID:
KPR.2009.07.30.001
Title:
Prepare system overwrites saved subsystem ID

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is following use case:

- a subsystem with a saved TargetLink subsystem ID is
prepared. This implies
that the subsystem had been cleared from TargetLink data
(since TargetLink 3.0),
or converted back to Simulink (in TargetLink 2.x).
- the TargetLink Main Dialog of the model is open, displaying
the Code
Generation tab (which is the first page).
- the subsystem is prepared for TargetLink
Preparation falsely produces a message that the ID has been
restored, although
it is lost and set to a default value (usually 'a').
An unexpexted TargetLink subsystem ID results in
unexpected code identifiers.
The code might be not compilable when user specifications
depend on the expected
ID.
Workaround: Close Main Dialog before starting preparation.
ID:
KPR.2009.07.30.002
Title:
Namen macro $T, $(Type) and $(Basetype) are wrongly

evaluated for variables based on inherited property

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The replacement for the name macros $T, $(Type) and
$(Basetype) is wrong if the
block for which a variable is created has option "Inherit
properties" set.
Workaround: Do not use these name macros at blocks with option "Inherit
properties" set.
187 / 1260
ID:
KPR.2009.07.30.003
Title:
Code generation aborts at AUTOSAR calibratable parameter

(variable) in lookup table map structure

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For a lookup table a map structure can be created. If this map
structure
contains a variable which shall be realized as an AUTOSAR
calibratable parameter
(variable) where an access function is needed (RTE_CDATA
or RTE_Calprm) an
access violation occurs during code generation:
Fatal #99999: An exception occurred during code generation.
Contact dSPACE
technical support.
Workaround: Do not use the map structure in Lookup-Table blocks if you
want to calibrate
axes in AUTOSAR models or assure that the map structure
gets at function local
scope (for example with setting the optimization level to 2 and
giving the map
structure a variable class with optimization flag
"SCOPE_REDUCIBLE").
188 / 1260
ID:
KPR.2009.07.30.004
Title:
Wrong parameter order for Stateflow graphical functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The parameter of all generated functions are sorted before the
code is written
to a file. This is made to make the code generation stable and
deterministic.
There exist rules for a default order. Furthermore a user can
define explicit an
order which can be specified that at function blocks, Stateflow
charts and
Stateflow graphical functions.
For inputs/outputs of subsystems, charts and graphical
functions the default
order criterium is the port number of their input/output. This
default sort
order for inputs and outputs of graphical functions is unstable
(but
deterministic) and may lead so to an unexpected order of
those parameters.
Since the argument order at all places which call the graphical
function is also
changed, this mostly critical for external functions because the
caller may call
the external graphical function in an different order than it is in
the user
code.
Workaround: Specify the argument order by hand through the
functionarglist property of the
function:
e.g. for graphical functions: $TL$ functionarglist=a,b,c,d; $TL$
This can be set in the Property Manager by using the property
"Function argument
list".
189 / 1260
ID:
KPR.2009.07.30.005
Title:
If a subsystem or chart is reused in terms of an external

function and has different signal and/or parameter widths in
different instances no error message is thrown

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink does not support different widths of signals and/or

parameters in
different instances of the same reused function.
If there are different widths detected for a code generation unit
(e.g.
TargetLink subsystem, subsystem configured for incremental
code generation,
referenced system) an error message should be thrown to
point out that this is
not supported.
Currently no error message is thrown if the reused system is
specified to be
external via its function class.
See also publication PR20080526-01.
Workaround: Use the same width for all instances of a reused system.
190 / 1260
ID:
KPR.2009.07.30.006
Title:
Incorrect code is generated for min/max operation in Stateflow

with more than two parameters

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a min/max operation is called in a Stateflow chart with more

than two
parameters a warning is generated thats says that only the
first two aruments
are used:
Warning #20942: max_val/max:
The max function is a binary function, so only the first two
input parameters
are considered.
In MATLAB versions prior to R14 only the first two parameters
are taken into
account. So a warning and the behaviour of TargetLink were
correct. But since
MATLAB R14 Stateflow and TargetLink behave different
because Stateflow now
considers all parameter.
An error should be thrown or min/max with more than two
arguments should be
supported an no warning/error should be thrown.
Workaround: Change every min/max call with more than two inputs into
recusive calls of
min/max.
For example change
min(a,b,c)
to
min(a,min(b,c))
These can be easily identyfied by the warning #20942.
191 / 1260
ID:
KPR.2009.07.30.007
Title:
Code generation aborts or yields to incompilable code when using an extern C function
in a reused Stateflow chart

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When calling an extern C function from a Stateflow chart that lies inside a
reused system or is itself reused one of the following effects may occur:
1. The Code Generator aborts with a fatal internal error like the following:
"Fatal #10007: Internal error. Error code:
E:\Sandboxes\301dev02\Core\XcgUtils\Sources\XcgUtils\Trace\TlCTraceFallThrough.c
pp_ 271"
2. The code generation completes successfully, but the call of the extern
function has an additional parameter "pISV" for the instance-specific struct.
The code is thus rejected by the compiler.
ID:
KPR.2009.07.30.008
Title:
Autoscaling tool calculates wrong scaling if a Selector block

with zero-based index mode or one-based index mode and
Starting index option is used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The Autoscaling tool calculates wrong scalings for blocks

predecessing a
Selector block if one of the following conditions is fullfilled:
- The Selector block has the index "Zero-based" mode - the
calculation is made
as if the "One-based" mode would be active.
-- OR -- The Selector block uses the index option "Starting index" the calculation is
made only for the starting index.
192 / 1260
ID:
KPR.2009.07.30.010
Title:
Superfluous preprocessor encapsulation of local variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Local variables which are not at the top level of a function
body may be
superfluously encapsulated with preprocessor control flow
although the same
encapsulation is already there higher in hierarchy, for
example:
Void func()
{
...
#ifdef COMPILE_SWITCH
...
{
...
#ifdef COMPILE_SWITCH /* not wrong, but superfluous */
Int16 MyLocalVar;
#endif
...
}
...
}
193 / 1260
ID:
KPR.2009.07.30.011
Title:
Preprocessor macro without module can lead to wrong code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are fulfilled the generated code
may be
wrong:
- A macro is used for a block outport which drives a
preprocessor control flow
generating block
-- AND -- the variable class properties of the macro are "Storage" =
"Extern" and/or
"Alias" = "on"
-- AND -- the macro has no module specified (variable/variable class
attribute)
-- AND -- the encapsulation of the function generated for at least one
of the
preprocessor control flow called subsystems requires complex
logic and is
therefore implemented by using an auxiliary macro (defined in
tl_aux_defines.h).
The mistake is that the macro is used in tl_aux_defines.h
although the
definition header is not known and can therefore not be
included in the file
tl_aux_defines.h.
Explanation:
'preprocessor control flow generating block' means:
- PreprocessorIf block
-- OR -- If block which is driven by a macro which has set variable
class property
"UsePreprocessorIf" = "on"
-- OR -- Enabled subsystem whose Enable port is driven by a macro
which has set
variable class property "UsePreprocessorIf" = "on".
Preprocessor control flow can be generated using Stateflow
chart as well in
terms of using a preprocessor macro in a condition. If auxiliary
macros are
necessary here and one of the macros is specified as
decribed above the problem
can occur as well.
Workaround: Specify a module for macros which are used in preprocessor
control flow
conditions.
194 / 1260
ID:
KPR.2009.07.30.012
Title:
Code generator stops with a crash when using subsystems

specified as external or incremental with same module

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: With the following modeling the code generator stops with a
crash:
There are 2 ... n external or incremental subsystems which
are called via
preprocessor control flow and which have the same module
specified.
"external subsystem" means:
The subsystem has specified a function class which has set
Storage to "extern".
"incremental subsystem" means:
The subsystem is configured for incremental code generation.
Workaround: Specify separate modules for external or incremental
subsystems which are called
via preprocessor control flow.
ID:
KPR.2009.07.30.013
Title:
API function tl_find aborts for referenced model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The API function tl_find can be used to search for TargetLink blocks with
certain property values. If this function is applied to a referenced model it
aborts with following error message:
??? Block does not include any block variable
Error in ==> tl_get>i_TLGet at 165
data =
tl_sync_dd_blockdata(tl_handle_main_data('get',h),'BlockType',blocktype);
Error in ==> tl_get at 130
[PropertyValue{i},errorflag(i),msg{i}] = ...
Error in ==> tl_find at 113
[propval,errFlag] = tl_get(tlblocks(k),properties{i});
195 / 1260
ID:
KPR.2009.08.04.001
Title:
Imported AUTOSAR units are not valid

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The SI exponent values and conversion factor values of

AUTOSAR unit objects will
be imported into the Data Dictionary by a merge mechanism.
This implies that
already existing unit objects will only be merged and not
overwritten. As a
result the information of the unit objects can be invalid after
import of an
AUTOSAR description. The Data Dictionary validation fails.
Workaround: Delete the /Config/Units group object before import of an
AUTOSAR description
that contains unit objects that are already contained in the
Data Dictionary.
ID:
KPR.2009.08.04.002
Title:
Simulink message "The selected signal originating from output

port 1 on <Block Path> cannot be displayed because it is
being merged." appears during MIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: During a MIL simulation the following Simulink error message

appears, even if
the affected TargetLink block is not selected for data logging:
"The selected signal originating from output port 1 on <Block
Path> cannot be
displayed because it is being merged."
This message appears if the block's output signal is
connected to a Merge block
input port via a signal which is passing subsystem levels as a
part of a
multiplexed signal.
Workaround: Exclude the block from logging and overflow detection using a
blacklist.
196 / 1260
ID:
KPR.2009.08.04.003
Title:
Look-up method "Binary search" or "Equidistant with" not

possible for Look-Up Table block after enhancement of
Simulink Lookup Table (n-D)

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: An enhancement of a Simulink Lookup Table (n-D) which is

configured as a 1D
look-up table results in a TargetLink Look-Up Table block.
For such a TargetLink Look-Up Table block it is not possible
to choose the
look-up method "Binary search" or "Equidistant with'. Although
it is possible to
select one of these methods in the dialog, the setting gets lost
after closing
and re-opening the block's dialog. The method is still "Linear
search, start
low".
The problem occurs only in MATLAB R2007b and newer.
Workaround: Use a Simulink Lookup Table block, if you want to model a 1D
look-up table. In
this configuration no problem occurs after enhancement of the
block.
ID:
KPR.2009.08.04.004
Title:
Unconnected line after Simulink to TargetLink conversion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During Simulink to TargetLink conversion, a TargetLink Inport

block is inserted
at an input signal of the subsystem to be converted. In rare
cases, restoring
the signal line after insertion fails, resulting in blocks with
unconnected
ports. The problem comes only up when an input signal has
multiple branches,
which means that the corresponding Simulink Inport block is
connected to several
blocks.
Workaround: Re-connect the blocks manually after conversion.
197 / 1260
ID:
KPR.2009.08.04.006
Title:
Wrong blocktype for 1D/2D Lookup Table blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: From TargetLink's point of view only 1D and 2D look-up table

blocks are
supported by the Code Generator. But in detail a 1D look-up
table block can be
either an enhanced Lookup Table block or a universal Lookup
Table (n-D) block
whose dimension parameter is set to one (a similar approach
applies to 2D
look-up tables). Whereas the information about the original
blocktype in
TargetLink 2.x was only relevant for the reconversion
procedure, since
TargetLink 3.0 the underlying blocktype becomes relevant for
the MIL simulation
behavior. Unfortunally the upgrade routine always utilitizes
simple Lookup Table
blocks although the information about the original blocktype is
availble. Hence
a clear system would result in wrong Simulink blocktypes
compared to the
original Simulink model.
Workaround: Reconvert the model in TargetLink 2.x and carry out a system
preparation under
TargetLink 3.0.
198 / 1260
ID:
KPR.2009.08.04.007
Title:
Code generation may abort with fatal error #10007 for customspecific C functions called with an operation as actual
paramter

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a custom-specific C functions is called from Stateflow and at

least one of
the actual parameters is neither a variable or macro access
nor a constant value
(e.g. "A = custom_function(B+C)"), the code generation may
abort issuing a fatal
error #10007.
Workaround: Introduce an auxiliary variable for the actual parameters that
are neither
constant values not variable or macro accesses (e.g. "temp =
B + C; A =
custom_function(temp)").
patches:
TargetLink 2.3.1p3
ID:
KPR.2009.08.04.008
Title:
Wrong code for saturated assignment with complex

expression in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code that does not compile may be generated for an

assignment in Stateflow, if
- the variable on the left hand side of an assignment has the
properties
checkmin and/or checkmax set to 1
-- AND -- the right hand side of the assignment consists of more than
one operation.
Workaround: Introduce auxiliary variables for subexpressions.
patches:
TargetLink 2.3.1p3
199 / 1260
ID:
KPR.2009.08.04.009
Title:
Incorrect code or abort of code generation for operation with

constant values in saturated assignment

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation process may fail or result in incorrect

code, if an
assignment in Stateflow has
- a variable on the left hand side whose checkmin and/or
checkmax property is
set to 1 (i.e. is saturated)
-- AND -- if the last operation (refered to as operation 1) on the right
hand side of
the assignment is an operation that consist of a constant value
and another
operation (refered to as operation 2)
-- AND -- if operation 2 again consists of an operation (refered to as
operation 3) and
a constant value
Example:
a = b * c * 1 / 9.365;
which means
operation 1 = (...) / 9.365
operation 2 = (...) * 1
operation 3 = b * c
In this example the code for operation 2 will be incorrect but in
general may
also be incorrect for operation 3 or following operations.
The problem will lead to wrong code for TargetLink version
2.3.1 and will lead
to abort of code generation for versions 2.3 and 3.0.
Workaround: Introduce a auxiliary variable for each subexpression or if
possible use
brackets to change the order of execution of dependent
operations.
Example:
Change a = b * c * 1 / 9.365; to a = b * c * (1 / 9.365);
patches:
TargetLink 2.3.1p3
200 / 1260
ID:
KPR.2009.08.07.001
Title:
If a Stateflow data references a user type located in a typedef

group the code generation may fail with error 17257

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow data references a user type located in a typedef

group in the
Data Dictionary the code generation may fail with error 17257.
In the message is
given the name of the auxiliary variable which is generated for
the Stateflow
data. The error message may be followed by an access
violation or fatal internal
error.
Example:
Warning #10601: No Gear TypedefObject was found in the
Data Dictionary.
Error #17257: Test/Test.Gear.y The data type Gear is invalid
for the
variable AUX_CGCA6_y.
Fault address: 245099E4 01:000089E4
D:\dSPACE_2_3_1\matlab\tl\bin\XcgExprDes.dll
Workaround: The mentioned type in such an error message has to be
moved into the root node
of the TypeDef objects in the Data Dictionary
(/Pool/Typedefs).
ID:
KPR.2009.08.10.001
Title:
Missing scaling for constant on the right hand side of a

saturated assignment

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
201 / 1260
Description: Incorrect code is generated for a saturated assignment if the

following
conditions are met:
- The right hand side of a saturated assignment is a constant
value
-- AND -- The scaling of the left hand side is no default scaling (LSB =
1.0 and Offset
= 0.0)
-- AND -- The constant value is greater than the upper
SaturationLimit/OutputLsb or
smaller than the lower SaturationLimit/OutputLsb.
If all these conditions are met, the Code Generator generates
code, where the
saturation limit is taken instead of the constant value
represented in the
scaling of left hand side of the assignment.
A saturated assignment can be modelled either with
TargetLink blocks or in a
Stateflow Chart. See the following examples.
1. Example for modelling with TargetLink blocks:
A Constant block drives a Saturation block. The constant
value of the Constant
block is 320 and the variable class is default, thus there is also
no scaling
specified. The Saturation block has UInt8 as type and LSB =
80. The lower limit
is 0 and the upper limit is 18000.
Now the generated code is Sa1_Saturation = 225 [= upper
limit 18000 / 80]; which
is wrong because the value 320 of the Constant block must be
represented in the
scaling of the Saturation block. So the correct code would be
Sa1_Saturation = 4
/* 320 */; For values <= 225 the generated code is correct. If
saturation is
necessary (e.g. constant value > 225) the code gets wrong.
2. Example for modelling in Stateflow
Assume you have the statement {Var = 320;} in a Stateflow
chart. Var is a
variable having the properties type = UInt8, LSB = 80 and
checkmin and checkmax
properties are both activated (e.g. = 1). Then the generated
code is Var = 255;
which is wrong because the value 320 on the right hand side
must be represented
in the scaling of the result on the left hand side. The correct
code would be
Var = 4.
202 / 1260
Workaround: Force that a variable is created for the constant on the right
hand side of a
saturated assignment by specifing a variable class !=
"default". For example use
the class "OPT_LOCAL" to obtain correct code, allow
optimization to eliminate
the variable and using the correct constant value.
ID:
KPR.2009.08.10.002
Title:
Wrong error message 21173 or 21174 for a Merge block

inside a Merge block cascade

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink supports a cascade of Merge blocks, i.e. situations

where a Merge
block is driven by other Merge blocks and there are only
Simulink ports and/or
routing blocks between those Merge blocks. TargetLink
permits the specification
of the Merge variable only at the last Merge block of the
casacade, i.e. the
Merge block that drives no other Merge block. All other Merge
blocks must have
the "Inherit properties" flag set.
But if a Merge block inside the cascade is driven by signals
with different
datatypes and/or scalings (e.g. one signal with Int16 and the
other with Int32)
than code generation aborts with error E21173 or E21174:
"The merge block's inputs inport <inport1>, <signal1>,
emanating from block
<source1> and inport <inport2>, <signal2>, emanating from
<source2>, have
different <datatype/scalings>. This is not allowed if the block
dialog setting
'Inherit properties' is enabled."
This error message is wrong for a Merge block inside a Merge
block cascade. The
message is only valid for the last Merge block of such a
cascade. The message
implies that you should disable "Inherit properites" at the
affected block. But
this leads only to error E21178.
Workaround: Ensure that the signals at the inputs of a Merge block inside a
Merge block
cascade have the same datatype and scaling.
203 / 1260
ID:
KPR.2009.08.10.003
Title:
Incomplete import/export of RTE events for init and terminate

functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The TargetLink init and terminate function objects will be

modeled in AUTOSAR
context as runnables with a special mode invocation. In this
use case the import
and export process loses information at the RTE event
objects. It is about the
reference from the RTE event objects to the init or terminate
runnable and the
reference to the receiver port of the software component.
Without these data an
error free import of the exported AUTOSAR file into an
architecture tool like
SystemDesk is not possible.
Workaround: No workaround known.
patches:
TargetLink 2.3.1p3
ID:
KPR.2009.08.13.001
Title:
Code generation aborts with error 02900 for a Client Port

block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: A model contains at least a Client Port block which was

upgraded from TargetLink
2.x to TargetLink 3.0 or newer.
Code generation may abort with a message like the following:
"Error #02900: <block>: Internal error. Contact dSPACE
Support.",
where <block> is the block path to a Client Port block.
The error is based on unconnected lines in the implementation
of the Client Port
block. The algorithm which connects the ports below the
Client Port block uses
port names.
Workaround: During upgrade deselect the option "Use port names from
older TargetLink
version".
204 / 1260
ID:
KPR.2009.08.14.001
Title:
Simulink error "Simulink.Bus object '<object name>' is not in

scope from '<bus port block>'." may appear during update
diagram of a model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: A TargetLink (root) model references a model with a bus

interface defined via a
Bus object. If only the root model is open and the diagram is
updated, e.g.via
<CTRL d> or tl_init_model(<model name>, 'init'), the following
Simulink error
message appears:
Error using ==> rtwgen
Simulink.Bus object '<bus object>' is not in scope from '<bus
port block path>'.
This problem exists only in MATLAB R2006a.
Workaround: One possible workaround is to use another MATLAB version
than MATLAB R2006a.
Another workaround is to open the referenced model before
the root model is
updated.
ID:
KPR.2009.08.14.002
Title:
Matlab crash with model referencing

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The following use case sometimes results in access violations

in Simulink's API:
- a TargetLink subsystem contains a Model block
- bus signals run into the Model block
- Matlab version is R2007a and later
- code is generated for the TL subsystem and the model that
is referenced by
the Model block
- the referenced model is not open when code generation
starts
The access violation results in MATLAB command window
output similar to the
following:
[0] libmwsimulink.dll:class slBlock * __cdecl
sluGetGraphicalSourceBlockAndPort(class slBlock const
*,int,int *)(0x2200724e,
159, 0x00d367cc, 0x00d36830) + 47 bytes
205 / 1260
[1] libmwsimulink.dll:class slsvErrMsgQueue * __cdecl

sluGetSignalSrc(class
slBlock const *,int,class slBlock * *,int *,bool
*,bool,bool)(0x2200724e, 159,
0x00d36808, 0x00d36804 "????") + 115 bytes
[2] libmwsimulink.dll:class slBlock * __cdecl
FindBusCreator(class slBlock
*,int,int *)(0x22bd31e0, 0, 0, 0x22bd5fa0) + 107 bytes
BuildPortBusStructArrayFromSLbus(struct SLbus_tag const
*,struct mxArray_tag *
*)(0x229996c0 "? ", 0x6f9a1900, 0x20e3e5c0, 59) + 140
bytes
CreatePortBusStructMxArray(struct slPort_tag *,struct
mxArray_tag *
*)(0x20e3e5c0, 0x00d36880, 0, 0x1a5cdf00) + 293 bytes
[5] libmwsimulink.dll:struct mxArray_tag * __cdecl
GetPortBusStructMxArray(struct slPort_tag *)(0x20e3e5c0,
59, 0x20e3e5c0,
0x17642400 "|o") + 45 bytes
[6] libmwsimulink.dll:protected: virtual struct mxArray_tag *
__thiscall
SLObsoletePrmDesc::getInMx_Impl(void const *,int)const
(0x20e3e5c0, 59,
0x00d3698c "BusStruct", 0) + 413 bytes
[7] libmwsimulink.dll:public: struct mxArray_tag * __thiscall
SLPrmDesc::getValueInMx(void const *,int,bool)const (0, 59,
0, 0x00d3698c
"BusStruct") + 111 bytes
get_param_from_index(void const *,int,char const *,struct
mxArray_tag * *,class
SLPrmDesc * *,unsigned int,bool)(0x20e3e5c0, 59,
0x00d3698c "BusStruct",
0x00d36a9c) + 61 bytes
get_port_object_param(void *,char const *,struct mxArray_tag
* *)(59, 0x00d3698c
"BusStruct", 0x00d36a9c, 0x00d36afc "`y"`a"k") + 225
bytes
get_param_switchyard(void *,char const *,struct mxArray_tag
* *)(0x20e3e5c0,
0x00d3698c "BusStruct", 0x00d36a9c, 0x041b0180) + 213
bytes
etc.
Afterwards, the model might remain in compiled state and
must be terminated
manually with
>> <modelName>([],[],[],'term')
Then, the MATLAB session can be finished.
The crash does not always show up, even if said
preconditions are met.
Workaround: Open referenced models before starting code generation.
206 / 1260
ID:
KPR.2009.08.17.001
Title:
Corrupted plot for virtual port block which is connected to an

outport of a referenced model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A corrupted plot may be shown for a virtual TargetLink port

block if it is
connected to an output port of a referenced model which is
directly connected to
a Stateflow chart outport inside this referenced model. The
problem appears in
MATLAB releases before R2008b only if there is no nonvirtual block between the
port block and the stateflow chart's output. MATLAB R2008b
and newer revisions
are not affected.
Workaround: A non-virtual, e.g. Gain block, block must be placed between
the chart's output
inside the referenced model and the port block outside the
referenced model.
207 / 1260
ID:
KPR.2009.08.17.002
Title:
Plot data seems to be shifted by one time step

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A plot signal is shifted by one time step compared to the

actual simulated and
logged values.
This effect may occur if all of the following conditions are
fulfilled:
- The affected block is a TargetLink OutPort block
-- AND -- the block is driven by a signal which is built by a Mux block
which assembles
the output signals of a D Latch block and a D Flip-Flip block
-- AND -- the sample time is an integer multiple of the plot interval.
The signal is logged correctly which can be checked via Plot
button on
Simulation tab in Main Dialog after the MIL simulation has
been finished.
Only the plot signal corresponding to the output of the D Latch
block appears
shifted during simulation.
Workaround: Set the plot interval to a value greater than the step size of the
simulation
solver.
208 / 1260
ID:
KPR.2009.08.24.002
Title:
Error 02291 for mixed bus and muxed signals

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The width determination for signals, which are mixed from
muxed and bus signals
doesn't work correctly for the TargetLink overflow detection if
MATLAB R2006a is
used. A difference between the signal's width and the block's
width is detected,
if the block is not scalar. This results in an error message
similar to the
following:
Error #02291: <block path>:
A scaling data/signal size mismatch in block '<block path>'
has been detected.
The block property 'lsb' is a (4,1)-vector, but the compiled
signal size is
(8,1).
Workaround: Signals which are mixed by muxed and bus signals must not
be used in TargetLink
3.0 and newer.
209 / 1260
ID:
KPR.2009.08.27.001
Title:
Fatal error #99003 for bitwise operation mixed with other

operation resulting in 64 bit

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation may abort for a bitwise operation in

Stateflow with fatal
error #99003 if at least one of the operands of the bitwise
operation is another
operation whose result does not fit into 32 bit.
This problem only comes up, if at least one of the operands is
unscaled (LSB ==
1.0 and Offset == 0.0) and has a different TargetLink than
Stateflow data type.
Example:
Int32 out;
Int32 in1;
Int32 in2;
out = in1 | (in2 * 2);
Since the result of in2 * 2 generally does not fit into 32 bit, a
64 bit
auxiliary variable has to be introduced.
In combination with the bitwise operation this may lead to an
abort of the code
generation.
Workaround: Separate a bitwise operation from other operations in
Stateflow, e.g. by using
an additional local variable
-- OR -avoid 64 bit calculations by specifying a cast in stateflow, e.g.
out = in1 |
int32(in2 * 2)
-- OR -avoid 64 bit calculation by specifying constraint limits.
210 / 1260
ID:
KPR.2009.08.27.002
Title:
RTE API function providing access to a calibration parameter

has wrong function name

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink generates a wrong RTE API function providing

access to the
calibration parameter defined by an AUTOSAR
CalprmComponentType.
Instead of "Rte_Calprm_<p>_<name>" (with <p> being the
port's name and <name>
the name of the calibration parameter),
"Rte_CalPrm_<p>_<name>" with a capital
letter "P" is generated.
patches:
TargetLink 2.3.1p3
211 / 1260
ID:
KPR.2009.08.28.001
Title:
Code generation aborts with wrong error message #19692 for

bitwise operation in saturated assignments in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may abort with the confusing message

#19692 if
- a bitwise operation is part of an assignment
-- AND -- the left hand side of the assignment is saturated (i.e.
checkmin and/or
checkmax = 1)
-- AND -- an operand of the bitwise operation is another operation
-- AND -- (TargetLink version 2.3.1 or 3.0 and older) none of the
operands has a scaling
(LSB != 1.0 and Offset != 0.0)
- (TargetLink version 3.0.1 and newer) all operands have the
same TargetLink as
Stateflow data type and have no scaling
-- OR -- (TargetLink version 3.0.1 and newer) at least one operand
has a different
TargetLink than Stateflow data type and none of the other
operands has a scaling
(LSB != 1.0 and/or Offset != 0.0) and the code generation
option
"HandleUnscaledStateflowExpressionsWithTlType" is set to
off.
Workaround: Avoid saturation of variables to which the result of a bitwise
operation is
assigned
-- OR -avoid bitwise operation having operands that are operations
themselves by
introducing auxiliary variables.
212 / 1260
ID:
KPR.2009.09.03.001
Title:
Wrong signal connection after Simulink to TargetLink

conversion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Given is following use case:

- a subsystem should be converted to TargetLink
- there is a block whose position is very close to the left and/or
the top
border of der Simulink model window (margin < 15 pixels)
- the block has more than one input or output port, and the
block icon size is
small (less than 20 pixels)
In this case, signal lines might be unconnected or wrongly
connected after
conversion. The reason for this bug is a flaw in Simulink's API.
Workaround: Move a block that resides close to the window border to the
right or to the
bottom before starting conversion.
ID:
KPR.2009.09.04.001
Title:
Optimization may cause incorrect code if variabl with activated

checkmin or checkmax property is used in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Optimization may lead to incorrect code for a Stateflow chart if

a variable is
used which holds at least one of the following conditions:
- the checkmin property is selected but no minimum is
specified for the variable
- the checkmax property is selected but no maximum is
specified for the variable
Workaround: Specify a minimum and/or maximum value for such variables
(e.g. the lower and/or
upper limit of the used data type or a value lower and/or
higher than the data
type limit). But the specified value must be a real value, not "Inf" or "Inf".
213 / 1260
ID:
KPR.2009.09.21.001
Title:
Erroneous moving of variable redefinition into conditionally

executed control flow branches

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable "D" is defined as a call-by-reference parameter of

a function and
the function has a return value, then in a situation like
ret = foo(&D);
if (cond) {
...
b = ret;
...
}
f = D;
erroneous movement of the function call can take place, i.e.
if (cond) {
...
b = foo(&D);
...
}
f = D;
This situation can occur if the variable classes of at least two
outputs of a
subsystem with a Function block or an Index Search block are
chosen as having
Scope "fcn_return" or "ref_param", respectively, and the
function return output
drives a data input of a Switch block, Multiport Switch block or
an enabled or
action port triggered subsystem whereas the call-by-reference
output drives
blocks that bypass the conditionally executed control flow
branch.
In addition, this kind of situation can also occur for function
calls in a
Stateflow Chart.
Workaround: Assign a variable class to the variable (here "ret") that is nonMOVABLE (via
the ArgumentClass property of the respective output's variable
class) or insert
a Rescaler or TargetLink Port block that receives "ret" and has
an output
variable with a non-MOVABLE variable class.
214 / 1260
ID:
KPR.2009.09.21.002
Title:
Wrong warning 8832 about different typedef at different data elements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR export erroneously throws a warning about different typedef
specifications at different data elements.
The precondition for this faulty behavior is an analysis of two data element
objects that references the same typedef object. The typedef object represents a
structured type with a defined set of typedef components. The algorithm has to
check all data element component objects at both data elements, to find
different specifications. If all data element components are equal and the root
data element differs only in the Uuid property the AUTOSAR export wrongly
throws
the following warning:
Title: Warning
Message: A Struct typedef is used at different data elements
/Subsystems/PortInterfaces/Interfaces/IF_Test/DataElements/DataElement_Foo
versus
/Subsystems/PortInterfaces/Interfaces/IF_Test2/DataElements/DataElement_Foo2
two
types will be generated with the same name.
ID:
KPR.2009.09.21.003
Title:
Erroneous Float64 cast in bitwise operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in a model a constant block with default variable class feeds

a Stateflow
chart and the corresponding input is used in a bitwise
operation then TargetLink
erroneously generates a type cast to Float64 for the result of
the bitwise
operation.
Workaround: Set the TargetLink data type of the corresponding Stateflow
input to an integer
type.
215 / 1260
ID:
KPR.2009.09.21.004
Title:
Model initialization fails on a D Flip-Flop block because of a

data type mismatch

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Model initialization of a valid TargetLink model fails, if

- the model was upgraded from TargetLink 2.x
-- AND -- the model contains at least one D Flip-Flop block
-- AND -- the input signal data type for data input or data output of the
D Flip-Flop
block is not boolean.
An error message similar to the following will be thrown:
SIMULINK ERROR MESSAGES:
--> Data type mismatch. Input port 1 of 'myModel/ .../D FlipFlop/Logic' expects
a signal of data type 'boolean'. However, it is driven by a
signal of data type
'double'.
--> Data type mismatch. Output port 1 of 'myModel/.../D FlipFlop/D' is a signal
of data type 'double'. However, it is driving a signal of data
type 'boolean'.
Workaround: Deselect the global Simulink option "Implement logic signals
as boolean data
(vs. double)" (Simulation > Configuration Parameters >
Optimization > Implement
logic signals as boolean data).
216 / 1260
ID:
KPR.2009.09.21.005
Title:
Option "Omit dispensable initializations" for Assignment blocks

in virtual subsystems is ignored

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An Assignment block is placed in a virtual subsystem. The

virtual subsystem is
placed in a subsystem containing a For Iterator block. In the
Assigment block
the option "Omit dispensable initializations" is selected.
Nevertheless TargetLink ignores this option and generates
initialization code
for the Assignment block.
Workaround: - Do not place the Assignment block inside a virtual
subsystem, but on top level
of the For Iterator subsystem.
-- OR -- Use a Stateflow Chart block instead of the Assignment block.
ID:
KPR.2009.09.21.006
Title:
Wrong SIL simulation when root interface communication is

modeled with Data Store blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: When data flow from an externally triggered subsystem to the

TargetLink root
system is modeled with Data Store blocks (i.e. Data Store
Write block to a
mergeable global variable inside the triggered subsystem,
Data Store Read block
from the mergeable variable on root level and to the outside
via an Outport
block), the Code Generator fails to identify this virtual
connection as a root
interface. As a consequence, the SIL simulation may fail for
this signal which
remains always zero.
Workaround: Avoid modeling the data flow beyond the root level by using
Data Store blocks.
Consider using a signal flow via non-enhanced ports or, when
the variable is
used more than once, via Merge block(s).
217 / 1260
ID:
KPR.2009.09.21.007
Title:
No simulated ranges (min/max logging) for blocks which are

connected to Merge block input ports

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For TargetLink blocks which are connected to Merge block

input ports, it is not
possible to log min/max values to determine the simulated
ranges in MIL mode.
The block dialog's Output page shows only "n.a." below
caption "Simulated".
Additional, the warning message #2269 is displayed:
"It is not possible to perform overflow detection or min/max
logging for the
output signal '<port number>' of block '<block path>'.
One possible reason: The signal is connected to a Merge
block input port."
This affects also TargetLink blocks which are not directly
connected to a Merge
block but separated only by subsystem borders and/or virtual
blocks.
Workaround: After placing a non-virtual block supported by TargetLink (e.g.
the Data Type
Conversion block) between the affected block and the Merge
block input port it
is possible to determine simulated ranges in MIL mode.
218 / 1260
ID:
KPR.2009.09.21.008
Title:
Overflow detection does not take default data type into

account

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The property DefaultDataType of the Data Dictionary object

/Config/TargetLink
defines the default data type for a TargetLink block when it is
added to a
model.
This data type is taken into account as long as the block data
is not modifed by
the user.
The TargetLink overflow detection ignores this default data
type and always uses
Int16. This can lead to non-expected or missing overflow
warnings for such
untouched TargetLink blocks.
Workaround: The type property of the affected block variables can be
refreshed via
TargetLink API commands.
An example for the block variable 'output':
tl_set(<block>, 'output.type', tl_get(<block>, 'output.type'))
Alternatively this refresh can be done by the block dialog:
- Open the block dialog
- Change one block property to a different value (it doesn't
matter, which
property)
- Confirm the modification with the Apply button
- Set this block property back to the original value
- Confirm the modification with the Apply or Close button
219 / 1260
ID:
KPR.2009.09.21.009
Title:
Model upgrade does not take Data Dictionary

DefaultDataType into account

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The property DefaultDataType of the Data Dictionary object

/Config/TargetLink
defines the default data type for a TargetLink block when it is
added to a
model. As long as the user does not modify any data of the
block (i.e. the
description), the Data Dictionary setting is taken as the block's
data type by
all consumers of this information, e.g. the code generator what
means that
changing the default data type changes the behavior of the
related blocks. As
soon as the user changes anything in the block the data type
which is currently
defined as default is permanently written to the block data.
The model upgrade erroneously sets Int16 as the block's data
type if the block
data was never changed after adding the block from the
TargetLink library to the
model.
Workaround: Correct the data type after model upgrade or replace the block
by a new
untouched one from TargetLink library.
220 / 1260
ID:
KPR.2009.09.21.010
Title:
Incomplete export of all AUTOSAR Typedef objects for

module Rte_Type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The TargetLink AUTOSAR export writes only Typedef objects

that are explicitly
referenced from AUTOSAR prototype objects, like a
DataElement, OperationArgument
or Interrunnable Variable etc. If the user selects a RTE
Typedef object inside
the runnable without using at global prototypes, the Typedef
object will not be
exported as a RTE type. Additionally the TargetLink code
generator doesn't
generate the typedef. This yields to an not compilable
integration process,
because the generated RTE code and the generated
TargetLink code don't contain
the type definition for the used Typedef.
This error you will only be recognized during integration
process of the
TargetLink generated code with the RTE generated code. The
compiler will throw
an error message about usage of an undefined typedef.
During your work with
TargetLink the code generation and simulation will be
successful because
TargetLink uses its own pseudo-RTE for simulation purpose
which contains the
typedef.
Workaround: Export all RTE types from Pool area of the Data Dictionary to
make sure that the
RTE code generator get all RTE types.
221 / 1260
ID:
KPR.2009.09.22.001
Title:
Faulty 64 bit shift macros in TargetLink's fixed-point library

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The lower part of the result calculated by the following generic
macros is
faulty:
C__U64SHLI64U6
C__U64SHLI64C6_LT32
C__I64SHLU64U6
C__I64SHLU64C6_LT32
Affected file:
%DSPACE_ROOT%\Matlab\TL\SrcFiles\Generic\shl.h
Workaround: The wrong code can be fixed by modifying the code in the
header file.
The pattern
r_l = (UInt32)(r_l << csh)
must be replaced by
r_l = (UInt32)(v_l << csh)
ID:
KPR.2009.10.12.001
Title:
MIL simulation of a model containing a non-virtual bus

specified via a busobject may lead to a MATLAB crash

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A MIL simulation of a TargetLink model may lead to a

MATLAB crash if the model
contains
- non-virtual buses
-- AND -- busobjects
patches:
TargetLink 3.0.1p1
222 / 1260
ID:
KPR.2009.10.20.001
Title:
TargetLink API function get_sfobjects doesn't find all machine

data and events when there are multiple machines

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: If there is more than one machine, i.e. when Stateflow charts
from libraries are
used, get_sfobjects may not find all data and events parented
by machines. Only
the first machine encountered during processing is examined.
Workaround: Do not define data or events on machine level (see
MATLAB/TargetLink guidelines)
or sort the API function's parameters like {modell, libsubsystem}.
Note: Since TargetLink 3.0 the API function get_sfobjects is
replaced by
tl_get_sfobjects, which has fixed the problem.
ID:
KPR.2009.10.20.002
Title:
Predefinition and postdefinition block statements are output

incorrectly for macro variable class

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Predefinition and/or postdefinition block statements of a variable class

with
Macro property set to "on" are not placed correctly in the generated
code, or
not generated at all. More precisely:
Let B_1, B_2, ..., B_n consecutive blocks of macro definitions in a
generated
file and let PreDefBlockStm_k the predefinition block statement of
block B_k and
PostDefBlockStm_k the postdefinition block statement of block B_k (if
no
predefinition resp. postdefinition block statement is specified for block
B_k
then you can interpret PreDefBlockStm_k resp. PostDefBlockStm_k
as an empty
statement). Then the block definition statements are placed as follows
in the
generated code:
B_1
PreDefBlockStm_1
B_2
223 / 1260
PostDefBlockStm_1
PreDefBlockStm_2
B_3
PostDefBlockStm_2
...
PreDefBlockStm_(n-1)
B_n
PostDefBlockStm_(n-1)
For example with variable classes MACRO_VC1 with predefinition
block statement
/* PreDefinitionBlockStatement VC1 */ and postdefinition block
statement /*
PostDefinitionBlockStatement VC1 /*.
And variable classes MACRO_VC2 with predefinition block statement
/*
PreDefinitionBlockStatement VC2 */ and postdefinition block
statement /*
PostDefinitionBlockStatement VC2 /*.
The code looks like this
/*----------------------------------------------------------------------------*\
DEFINES
\*----------------------------------------------------------------------------*/
/******************************************************************************\
MACRO_VC1: global preprocessor macros
\******************************************************************************/
#define VC1_Const1 (Int16) 10
/* PreDefinitionBlockStatement VC1 */
/******************************************************************************\
\******************************************************************************/
/* PostDefinitionBlockStatement VC1 */
...
but it should look like this
/*----------------------------------------------------------------------------*\
DEFINES
\*----------------------------------------------------------------------------*/
/******************************************************************************\
\******************************************************************************/
224 / 1260
/******************************************************************************\
\******************************************************************************/
...
Workaround: If possible use predefinition and postdefinition statements instead of
predefinition and postdefinition block statements.
ID:
KPR.2009.10.20.003
Title:
A graphical function in Stateflow chart can cover the change

detection operators

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A Stateflow chart can contain a graphical functions. If such

function has the
name of a change detection operator (hasChanged,
hasChangedFrom or
hasChangedTo), this function covers the corresponding
operator.
In this case, MATLAB use the change detection operator, but
the Code Generator
use the graphical function instead.
Workaround: Rename the graphical function.
225 / 1260
ID:
KPR.2009.10.20.004
Title:
Missing check for unequal dimension of scalar Stateflow data

and vectorial Data Dictionary variables with size 1

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In Stateflow, if a size of 1 is specified for a variable (e. g. a SF

Local
variable), it is interpreted allways as a scalar variable. A vector
or array is
only possible with size equal or greater than 2.
In the Data Dictionary, a Witdh of 1 is interpreted as an array
with only one
element. If a Data Dictionary variable with Width = 1 is
referenced in a
Stateflow variable with size = 1 an error message should be
thrown that
Stateflow and Data Dictionary sizes are not identically like the
following:
"Error #20911: Subsystem/Chart.temp1:
The size/dimension of this Stateflow data object (scalar) does
not match the
size/dimension specified by DD variable
SF_temp/Components/comp1 (vector with
size 1)."
This check does not work. So the code generation is
successful and the generated
code is wrong and leads to compile errors like the follwing:
Subsystem.c(144) : warning C4090: '=' : different 'const'
qualifiers
Subsystem.c(144) : error C2106: '=' : left operand must be lvalue
Subsystem.c(156) : warning C4305: 'type cast' : truncation
from 'UInt16 [1]'
to 'Int16'
Workaround: Do not use Data Dictionary variables with Width = 1 in
Stateflow.
226 / 1260
ID:
KPR.2009.11.16.001
Title:
Headroom not taken into account during autoscaling bases on

simulated ranges

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The headroom specification is not taken into account during

autoscaling if
- simulated ranges should be used
-- AND -- headroom unit is "bit"
-- AND -- headroom value is not 1
patches:
TargetLink 3.1p2
ID:
KPR.2009.11.25.001
Title:
Misleading error message after Data Dictionary upgrade

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A Data Dictionary is loaded that must be upgraded, and it

references an included
Data Dictionary file that could not be loaded. In this case, a
misleading error
message is produced.
*** W06259: INCLUDED OBJECTS HAVE BEEN
UPGRADED:
*** Upgrading the Data Dictionary failed. See message
browser for
details
All DD objects in /Config are valid.
THERE ARE 1 INVALID OBJECTS IN /Pool
The problem comes up only if the tl_set_project tool is used to
open the Data
Dictionary.
Workaround: Use dsdd_manage_project to open a Data Dictionary project.
227 / 1260
ID:
KPR.2009.11.25.002
Title:
Warning #20743 for Multiport Switch block control input

although input is limited by preceeding Saturation block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: A Saturation block drives the control port of a Multiport Switch

block. The
Saturation block limits the range of its output signal to the
range of the
Multiport Switch block's control port range.
Nevertheless, TargetLink throws warning #20743 during code
generation pointing
out that the limits of the control inport are out of range.
Workaround: Place a dummy block (Rescaler, TargetLink InPort, TargetLink
OutPort, ...) on
the signal line between the Saturation block and the Multiport
Switch block.
Specify the Saturation block's limits as the constrained limits
of the dummy
block's output variable.
ID:
KPR.2009.11.25.003
Title:
Elimination of variable by another variable depends on

location of accesses; seemingly different handling of control
flow branches

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
228 / 1260
Description: In a situation where a variable "aux" could be replaced by a

variable "b" that
is defined as a copy of "aux", and the value of "aux" depends
on "b" in one
control flow branch "CFB" but not in other control flow
branches, the
elimination of "aux" is not performed if "CFB" is not the first
control flow
branch.
Example:
A Switch block with output "aux" has data inputs with variables
"a" and "b" and
is followed by an outport with output "b". If "b" is the first input,
if (cond) {
/* CFB */
aux = b;
else {
aux = a;
}
b = aux;
then optimization is performed:
if (cond) {
/* CFB */
b = b;
else {
b = a;
}
leading eventually to
if (!cond) {
b = a;
}
If "b" is the second input, though,
if (cond) {
aux = a;
else {
/* CFB */
aux = b;
}
b = aux;
then "aux" is not eliminated.
This situation can also occur if the eventual value of "b" is
arrived at by
applying a unary operation to "aux", e.g.
b = -aux;
or
b = (Int32) aux;
229 / 1260
Workaround: 1. Insert TargetLink Ports / Busport Blocks / Rescaler blocks

before "CFB" so
that initially the value of "aux" does not depend on "b" in
"CFB", i.e. for the
example above, the code for option OptimizationLevel = 0,
looks like
workaround = b;
if (cond) {
aux = a;
else {
/* CFB */
aux = workaround;
}
b = aux;
Utilize "inherit signal properties" where possible.
2. Use the MERGEABLE variable class optimization property
in order to arrive at
initial code where "aux" is already replaced by b:
if (cond) {
b = a;
else {
/* CFB */
b = b;
}
/* "b = aux;" would become "b = b;" which is not in the
generated code */
This workaround is not as widely applicable as the first. For
example, there may
be problems with busses or different code if the order of value
changes is not
fixed by the modeled data flow.
230 / 1260
ID:
KPR.2009.11.25.004
Title:
Copying a Runnable port block may yield to inconsistant block

state

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Copying an already initialized Runnable Inport or Runnable

Outport block within
a model may yield to an inconsistant block state, which cannot
be repaired by
setting correct blockdata.
Code generation results in error message like the following:
"Error #02900: ar_poscontrol/ ...
/Controller_Runnable/IrvLinPos2: Internal
error. Contact dSPACE Support."
NOTE: A Runnable port block can be identified as initialized, if
the block icon
contains the name of the selected AUTOSAR object instead of
common string
"Runnable Inport" or "Runnable Outport".
Workaround: Do not use a copy of an initialized Runnable port block, but
use a new one from
TargetLink's library instead.
ID:
KPR.2009.11.25.005
Title:
Unconnected ports at Runnable Ports

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: A Runnable Port block can have an additional port emitting a

status signal.
After loading the model the port may be unconnected although
the port and the
signal line are present.
Workaround: Ensure that the correct Data Dictionary is loaded before the
model is loaded.
This can be achieved e.g. by an start script.
231 / 1260
ID:
KPR.2009.11.25.006
Title:
Code generation aborts with fatal error #10007 if a modulo

operation is used in an index expression in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow an expression

- contains at least one operand that has different TargetLink
and Stateflow data
types
-- AND -- does not contain an operand that is scaled (has an LSB !=
1.0 and/or Offset !=
0.0)
-- AND -- contains an index expression that contains a modulo
operation,
then code generation may abort issuing the error message
#10007.
Example:
Int16 a; // StateflowType: double; TargetLinkType Int16;
Int16 b; // StateflowType: double; TargetLinkType Int16;
Int16 c; // StateflowType: double; TargetLinkType Int16;
a[b % c]
Workaround: Unset the code generator option
"HandleUnscaledStateflowExpressionsWithTlType" (
= "off") or assign the index expression to an auxiliary variable.
232 / 1260
ID:
KPR.2009.11.25.007
Title:
Code generation aborts with error #19602 if a bitwise

operation is assigned to a floating point variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow an assignment ist specified,

- that has a floating point variable on the left hand side
-- AND -- that has a bitwise operation as last operation on the right
hand side
-- AND -- if the whole assignment contains at least one operand that
has different
TargetLink and Stateflow data types
-- AND -- if no operand of the whole assignment is scaled (i.e. LSB !=
1.0 and/or Offset
!= 0.0),
then the code generation may abort with error message 19602
which states that
there is a bitwise operation on a scaled or floating-point
operand.
Workaround: Unset the code generator option
"HandleUnscaledStateflowExpressionsWithTlType" (
= "off") or assign the bit operation to an integer (auxiliary)
variable.
233 / 1260
ID:
KPR.2009.11.25.008
Title:
Error message #15515 if a static variable with fixed name is

varianted by a data variant and used in different modules

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A model contains two subsystems. Both systems are specified

to be generated in
different code files. In the Data Dictionary a variable is
specified to be an
element of a data variant. The variable has a fixed name, and
a variable class
whose Scope property is set to "static". The variable is used in
both systems.
When trying to generate code for the data variant, code
generation stops with
error message #15515 complaining about a the data variant
structure having
different struct components of identical names.
Workaround: Specify name macro $R in the name template of the Data
Dictionary variable.
-- OR -Specify the Module property of the variable to specify a fixed
module where the
variable should be generated.
ID:
KPR.2009.11.25.009
Title:
Logging macros are generated for merged Stateflow outputs

even if logging is globally disabled

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow output has a logging specification (signal history

or min/max)
and this outport is connected to a Merge block, logging
macros will be generated
even if the global logging mode option is "do not log anything"
or "clean code".
Since the logging macros are not defined in the simulation
frame, building the
host simulation application will fail.
Workaround: Set the Stateflow outport explicit to log nothing.
234 / 1260
ID:
KPR.2009.11.25.010
Title:
Incorrect code cause code is generated into control flow

branch though used in control flow condition

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A model contains an atomic subsystem, a subsystem with a

Function block, a
Runnable Inport block, or a Client Port block. Each signal line
of the
system's/block's outports drive exclusively the following
inports of the
following blocks:
- Either the control port and (directly or indirectly) exactly one
of the data
ports of a Switch block or a Multiport Switch block
-- OR -- the inport of an If Else block or a Switch Case block, and
(directly or
indirectly) one or more inports of exactly one of the related
Action Triggered
subsystems.
Additionally, the code generation option
"EnableBlockDiagramSwitchOptimization"
is activated.
In this case the generated code might be incorrect, because
the
subsystem's/block's code might be placed into a control flow
branch, but one of
the variables that is calculated there is used in the control
flow's condition.
Workaround: There are several workarounds available:
- Place a block (Rescaler, TargetLink InPort/OutPort, ...) on
the signal driving
the control port of the Switch block or Multiport Switch block,
respectively the
If Else/Switch Case block.
- Disable the code generator option
"EnableBlockDiagramSwitchOptimization"
- Set the optimization level to 0 (zero).
patches:
TargetLink 2.3.1p6
235 / 1260
ID:
KPR.2009.11.25.011
Title:
Error #17002 although variables have different names

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In a block a variable is specified to have a changeable name

(that means a name
containing name macro $C, $S, or $R). It has a variable class
with property
Scope set to "local". In another block a variable is specified to
have a
variable class with property Scope set to "global". Additionally,
it has the
same name as the other variable, but this time the name is not
changeable.
The block diagram is modeled in a way, so both variables are
used in the same
subsystem, but both variables will be defined in different C
code files (e.g. by
specifying property Module in the global variable's variable
class).
In this case, code generation might stop with error message
#17002 saying that
the variable is covered up by a variable of the same name.
Workaround: Specify changeable names for both variables. Or rename one
of the block
variables explicitly so both variables do have different names.
236 / 1260
ID:
KPR.2009.11.25.012
Title:
Data store semantic fails at explicitely defined Stateflow inputs

if driven by Merge block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the following situation the behavior of the generated code

differs from the
Simulink behavior:
- Stateflow block A calls a Stateflow chart or a subsystem B
(directly or
indirectly)
-- AND -- A is driven by a Merge block which is driven by an outgoing
signal of B
-- AND -- for the consuming input of A a variable X is explicitely
specified.
The mistake is that X is not updated with the signal of the
Merge block.
X is treated as explicitely specified if:
For TargetLink versions < 3.0:
In the corresponding Stateflow data object at least one
TargetLink property is
defined (e.g. see description property of the object which
contains a TargetLink
tag like $TL$class=GLOBAL; $TL$).
For TargetLink versions >= 3.0:
In the corresponding Stateflow data object the TargetLink
property
"createinputvariable" is set to 1 (on)
Workaround: Do not explicitely define input variables for an input of a
Stateflow block A if
the input is driven by a Merge block which is driven by another
Stateflow block
or subsystem which is called directly or indirectly by A.
For TargetLink versions < 3.0:
Remove all entries from the Description page of the
corresponding Stateflow data
object.
For TargetLink versions >= 3.0:
For the corresponding Stateflow data object set TargetLink
property
"createinputvariable" to 0 (off). You can use the TargetLink
Property Manager to
do this.
237 / 1260
ID:
KPR.2009.11.25.013
Title:
Calculated scaling of intermediate result of Stateflow

expression introduce overflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow expression on the right-hand side of an

assignment or in a
relational operation contains at least one scaled operand and
consists of more
than one operation (is a complex expression), then
TargetLink's Stateflow
expression autoscale mechanism has to calculate a result
type and a result
scaling for all except the top-most operation on the right-hand
side. This is
done using worst-case ranges in order to prevent overflows of
any intermediate
operation's results.
But sometimes a faulty range optimization in the scaling
calculation risks
overflow, thus yields to incorrent code, or introduces
superfluous 64-bit
operations in the generated production code.
Note:
The problem more likely occurs if a Stateflow assignment is
saturated. A
saturated assignment is an assignment whose left-hand side
variable has the
TargetLink properties "checkmin" and/or "checkmax" set to
"on".
Workaround: Disable the intermediate result scaling optimization by setting
the code
generator option "AutoscaleLsbTolerance" to 0 (zero), e.g.
using the hook
function pre_codegen_hook.
Additionally if possible, split complex statements in Stateflow
into single
operation statements with intermediate variables that have
appropriate scaling
(according to expected/needed accurary) and try to enclose
subexpressions that
only contain constant values with parentheses.
patches:
TargetLink 2.3.1p4
TargetLink 3.1p2
238 / 1260
ID:
KPR.2009.11.25.014
Title:
Code generation aborts with fatal error if an unscaled

operation consists of constant value and operation in
Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The fatal error

"Fatal #10007: Internal error. Error code: TlCEASNode 147.
Contact dSPACE's
technical support team."
may be issued if a chart contains an assignment that
- has at least one operand that has a different TargetLink than
Stateflow data
type
-- AND -- has no operand that has a scaling (LSB != 1.0, Offset != 0.0)
-- AND -- has a binary operation as last operation on the right hand
side with a
constant as first operand and a (sub-)operation as second
operand
Workaround: Introduce auxiliary variables for sub-expressions.
239 / 1260
ID:
KPR.2009.11.25.015
Title:
Code generation aborts erroneously with error #19602 for bit

operation in saturated expression in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an assignment in Stateflow

- has a variable on the left hand side that has one of the
checkmin or checkmax
properties set to on
-- AND -- all operands in the assignment have the same Stateflow and
TargetLink data
type
-- AND -- the assignment contains a bitwise operation
-- AND -- the bitwise operation has at least one operand that is an
(arithmetic)
operation,
then the error #19602 about a bitwise operation on a scaled or
floating-point
operand may erroneously be emitted.
Example:
UInt8 Var1; // StateflowType: UInt8; TargetLinkType: UInt8
Var1 = ((Var1 & 0x0f) * 16) | (Var1 & 0x0f);
will cause the error #19602.
Workaround: 1. Switch off saturation (Is it really needed for the bit
operation?).
2. For a complex bitwise operation introduce casts according
to datatype for
(intermediate) results in Stateflow, e.g.change "v = uint8(((v &
0x0F) * 16) |
(v & 0x0F));" to "v = uint8(uint8(v & 0x0F) * 16) | uint8(v &
0x0F);" or
"uint8(((v & 0x0F) * 16) | (v & 0x0F));"
3. Break down complex bitwise operations to single operations
by introducing
auxiliary variables for intermediate results.
240 / 1260
ID:
KPR.2009.12.15.001
Title:
Wrong cast to not existing 64 bit data type for saturated

bitwise operation in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink may erroneously introduce casts to 64 bit data type

in the generated
code for Stateflow expressions, if
- the expression contains a bitwise operation
-- AND -- the expression contains an arithmetic operation
-- AND -- the bitwise operation contains constant values
-- AND -- the whole expression is assigned to a variable that is
supposed to be
saturated (checkmin or checkmax property set to on)
Example:
The expression
v = ((v & 0x0F) * 16) | (v & 0x0F);
will lead to a cast to UInt64 which is incorrent if the checkmin
and/or checkmax
property for v is set.
This problem is related to KPR.2009.02.11.003. In both cases
the required range
to calculate the bitwise operation in is assumed to be 32 bit
which is wrong.
Workaround: 1. Switch off the saturation (checkmin and/or checkmax
property).
-- OR -2. For complex bit operations introduce casts according to
data type for
(intermediate) results in SF, e.g."v = uint8(uint8(v & 0x0F) *
16) | uint8(v &
0x0F);" or "uint8(((v & 0x0F) * 16) | (v & 0x0F));".
-- OR -3. Break down the complex statement that involves bit
operations into separate
statements using single operation each, e.g. "low = v&0x0F;
high = low * 16; v =
low | high;".
241 / 1260
ID:
KPR.2009.12.15.002
Title:
Edit of vector work parameter in Custom Code block not

possible

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If in a Custom Code block dialog the interface is specified

such that
- no state variable exists
-- AND -- no parameter exists
-- AND -- a work parameter is specified
-- AND -- a Data Dictionary variable with witdh > 1 is referenced for
this work
parameter,
it is not possible to set the work parameter to its width in the
"Custom Code
symbols" on the Interface page. It is also not possible to set
the width using
the API, effectively preventing the usage of vector work
parameters.
Workaround: Make sure that the states and parameters are not empty. By
specifying dummy
variables with default variable class, there are no unnecessary
additional
variables generated in the code.
patches:
TargetLink 3.1p5
242 / 1260
ID:
KPR.2009.12.15.003
Title:
Calculation order of Data Store blocks may cause MIL/SIL/PIL

differences

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The calculation order of a Data Store Write block and its
corresponding Data
Store Read block may differ from Simulink. This can cause
differences between
MIL and SIL/PIL simulation. For example, if there is a pair of a
Data Store
Write and Data Store Read block which both refer to the same
Data Store Memory
block on the same level of a subsystem the Data Store Read
may be calculated
before the Data Store Write, for instance if there is no
connection along a
signal line. TargetLink does not assume any dependencies
between the Data Store
Write and the Data Store Read rather than the data flow along
a signal line.
Workaround: If you need to control the calculation order of Data Store Read
and Data Store
Write blocks to have MIL and SIL/PIL simulations comparable
you have to schedule
them explicitely, for example by putting them into FunctionCall
triggered
subsystems which are called by a Stateflow chart in a defined
order.
ID:
KPR.2009.12.15.004
Title:
Erroneous dead code elimination for vectors redefined in loop

depending on iteration variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
243 / 1260
Description: If a vector is written to at least twice in the same loop, the last
redefinition
depending on the loop variable, the other redefinitions
depending on another
loop variable or taking place elementwise, then it is possible
that the other
redefinitions are erroneously eliminated.
This constellation usually occurs for For Iterator or other
iterated subsystems
that contain an assignment block that uses the iteration
variable for index
selection. It can also occur for a Stateflow chart or for
variables that are
merged (usually via the variable class' MERGEABLE
Optimization property).
For TargetLink 3.0 and 3.0.1, this problem can only occur if
the assignments to
the variable preceding the last assignment are elementwise
assignments.
Example:
Wrong code generated for Assignment block in connection
with For Iterator
subsystem
for (Sa2_ForIterator = 0; Sa2_ForIterator < 10;
Sa2_ForIterator++) {
....
Sa3_Assignment[0] = ....;
....
Sa3_Assignment[Sa2_ForIterator] = ...;
....
}
This is erroneously optimized to
for (Sa2_ForIterator = 0; Sa2_ForIterator < 10;
Sa2_ForIterator++) {
....
Sa3_Assignment[Sa2_ForIterator] = ...;
....
}
and may be subject to subsequent optimizations based on the
new situation.
Workaround: 1. Set Optimization level to 0.
2. Set option EfficientVectorHandling to "off"
3. In some cases, lowering the LoopUnrollThreshold can help
avoid this problem
4. If possible change model with vector processing that uses
an
Iterator-Selector-Operation-Assignment block pattern to
operate on vector
directly instead (with blocks that support vector processing).
Also see MAAB
guidelines 6.5.5. db_0117: Simulink patterns for vector
signals.
244 / 1260
ID:
KPR.2009.12.15.006
Title:
Aborted code generation if the power operator ^ is used inside

a Stateflow chart with additional parameters

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the ^ operator (as power, not as exclusive-or) is used inside

a Stateflow
chart with additional parameters, the code generation aborts
with an access
violation or with an error message like
"Fatal #10007: Internal error. Error code: TlCParamSymbol
138. Contact dSPACE's
technical support team."
Additional parameters are used if
- the chart is reused (i.e. it has an additional parameter
pointing to an
instance structure)
-- OR -- the chart uses a pointer-to-struct parameter
-- OR -- some chart data have a variable class with Scope property
"val_param" or
"ref_param".
Workaround: Use the pow function instead of the power operator, i.e.
pow(a, b) instead of
a^b.
245 / 1260
ID:
KPR.2009.12.15.007
Title:
Simulink message "Invalid dimensions encountered while

propagating dimensions from output port ..." appears when a
Bus Outport block width is not consistent to the referenced
Bus object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: During a MIL simulation, the following Simulink error might

appear:
"Invalid dimensions encountered while propagating
dimensions from output port
<number> of '<block>'. --> Error in port widths or dimensions"
This problem occurs if all of the following conditions are
fulfilled:
- A referenced model contains a TargetLink Bus Outport block
which is specified
by a bus object.
-- AND -- The Simulink property "port dimensions" of this block is set to
a value which
doesn't match the dimension of the bus object.
-- AND -- The simulation is started from the Model Referencing Control
Center, from a
TargetLink Plot window or via command tl_sim.
Workaround: Open the Simulink dialog of the affected TargetLink Bus
Outport block (via
"Switch to Simulink block properties" button from the
TargetLink block dialog)
Switch to the tab "Signal Attributes"
Deselect the option "Specify properties via bus object"
Enter the value -1 in the field "Port dimensions"
Select the option "Specify properties via bus object"
Close the dialog via OK button
246 / 1260
ID:
KPR.2009.12.15.008
Title:
Error #17422 or #17423 although min or max values are

consistently specified

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Min and max values of a Data Dictionary variable can be

either specified at the
Data Dictionary variable or at the Contraint object of the
variable's referenced
Typedef object. If a min or max value is specified at both
objects, the min
respectively max values must be identical otherwise
TargetLinks emits error
#17422 (for min values) or #17423 (for max values). In some
rare cases
TargetLink may emit one of these errors although the values
are identical.
Workaround: Specify the min or max values either at the Data Dictionary
variable or the
Typedef object.
patches:
TargetLink 2.3.1p6
TargetLink 3.1p1
247 / 1260
ID:
KPR.2009.12.15.009
Title:
Parse error for some workspace variables in If block

conditions and/or Fcn block expressions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation for models using workspace variables in If

block conditions
and/or Fcn block expressions stops with an error message like
"Error #15252: Subsystem/If:
Evaluation of parameter expression 'u1 > a1a1a' for
parameter IfExpression
failed."
if the workspace variable name contains more than one
contiguous sequence of
digits.
For example, the variable name a111a is parsed correctly,
while a123a1 is
rejected, because it contains two contiguous digit sequences
("123" and "1").
Workaround: Use variable names with at most one contiguous digit
sequence.
ID:
KPR.2009.12.15.010
Title:
Fatal error at attempted constant folding

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
248 / 1260
Description: Code generation stops with an error like

"Fatal #10007: Internal error. Error code:
TlCConstantFolder157. Contact
dSPACE's technical support team."
or
"Fatal #10007: Internal error. Error code: TlCConstantFolder
209. Contact
dSPACE's technical support team."
The reason is an unexpected attempt to fold a cast constant
and a macro with
constant initial value, e.g.
((UInt8) 0) & MASK) == CONTROL_WORD)
with
#define MASK (UInt8) 12
The following preconditions are necessary:
- The operation has two operands
-- AND -- one of these two operands is a cast constant
-- AND -- the other operand is a macro with cast initial value
-- AND -- the macro has a variable class with selected ERASABLE
(or a default variable class)
Even then, this error does not always occur as other
optimizations may have
already dealt with the effectively constant expression.
This constellation for example can occur during work at a
model if blocks or
charts involving macro constants are copied without providing
all signal sources
and then code is generated.
Workaround: - Make your macro constants non-ERASABLE by assigning a
variable class; where
necessary or safe, relax this to the original or default variable
class
-- OR -- Assign a variable class to the macro with where property
OmitCastOfMacroValue
is set to "on"
-- OR -- Only if both of above are not possible:
+ Assign a non-ERASABLE variable class to the cast constant
or its predecessor
variables; if necessary, introduce an artifical variable /
Rescaler / TargetLink
port
-- OR -+ Assign a variable class to the macro with Info property set to
"Adjustable"
249 / 1260
ID:
KPR.2009.12.15.011
Title:
Erroneous replacement of vector summation or product with

constant vector input by input constant

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Sum block with one input signal and scalar output or Product
block with one
input signal and scalar floating-point output can be subject to
wrong
optimization if
- the input signal is a vector that holds the same constant (or
scalar variable)
for each element
-- AND -- the code generator option "EfficientVectorHandling" is set to
"on"
-- AND -- the input signal width is greater or equal to the value of the
code generator
option "LoopUnrollThreshold"
In this case, the computation
MyConstantVector[Aux_S32] = 17;
}
Aux_U16 = 0;
Aux_U16 = (UInt16) (Aux_U16 + ((UInt16)
MyConstantVector[Aux_S32]));
}
Sa1_Sum = (Int16) Aux_U16;
is replaced by
Aux_U16 = 0;
Aux_U16 = (UInt16) (Aux_U16 + ((UInt16) 17));
Sa1_Sum = (Int16) Aux_U16;
Workaround: 1. If the predecessor of the Sum block is a Constant block with
homogeneous
initial value for all elements, then either use a default variable
class or a
user variable class without set ERASABLE Optimization
property for the constant.
Otherwise, set the predecessor block's output variable class to
a user variable
class without set ERASABLE Optimization property.
2. Insert a Rescaler or TargetLink Port block before the Sum
block. Set the
block output variable class to a user variable class without set
ERASABLE
Optimization property and activate signal property inheritance.
250 / 1260
ID:
KPR.2009.12.17.001
Title:
No access-function for variable within a data variant

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If data-varianted variables should be covered by access

functions, the
generation of the access functions fails. Either an error
message is issued such
as "variable class must have scope global" although the
variable class
referenced by the variable has global scope. Or no error
message appears and the
variable is part of the variant strutures but no access functions
is generated
for it.
Workaround: Do not use an access function for a variable within a data
variant.
251 / 1260
ID:
KPR.2009.12.17.002
Title:
Erroneous rounding of constant values in Stateflow relations

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow relational operation consists of a non floatingpoint operand and

a floating-point constant value and
- the constant value cannot be represented in the scaling of
the other operand
-- AND -- the relational operation itself is operand of a logical operation
-- AND -- if the relational operation is a >= operation and the constant
value is the
right hand side operand
-- OR -- if the relational operation is a < operation and the constant
value is the
right hand side operand
-- OR -- if the relational operation is a > operation and the constant
value is the
left hand side operand
-- OR -- if the relational operation is a <= operation and the constant
value is the
left hand side operand
then the constant value will be rounded in the wrong direction.
For TargetLink versions prior to TargetLink 3.0.1 this problem
only comes up for
operands with a scaling of LSB != 1.0 and/or Offset != 0.0.
For the TargetLink versions 3.0.1 and newer this problem can
also come up, if
the operand is unscaled (LSB == 1.0 and Offset == 0.0) but
has different
TargetLink and Stateflow data types.
Example:
Int16 ScaledVar; // Lsb = 0.5
the expression
ScaledVar >= 40.1
will be generated as ScaledVar >= 81 if it stands alone. This is
ok.
But if it is part of a logical expression like e.g.
(ScaledVar >= 40.1) && (...)
the generated code will be ScaledVar >= 80 which is wrong.
Workaround: Adapt constant value.
252 / 1260
ID:
KPR.2009.12.17.003
Title:
Name macro in global interface variable of a referenced

system specified in the Data Dictionary can lead to
"undeclared identifier" compiler error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an interface variable of a referenced system is specified in

the Data
Dictionary and its variable class has global scope and in the
NameTemplate
property of the variable one or more of the name macros $I,
$S, $B, $L, $E but
not $D is used, during the code generation for the referencing
system the name
macros of the interface variable are not correctly resolved.
This leads to the
compiler error "undeclared identifier" during the build of the
host application.
Furthermore this problem occures, if $D is used in the name
template for struct
variables, used at the interface of a referenced system, in
combination with a
fixed part, like "StructVar_$D".
Workaround: Avoid the usage of the name macros described above for an
interface variable of
a referenced system.
patches:
TargetLink 3.1p3
ID:
KPR.2009.12.17.004
Title:
Missing overflow detection if the maximum or minimum of the

simulated signal is exactly 0

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If the maximum of the simulated signal is exactly 0, no positive

overflow is
detected and if the minimum of the simulated signal is exactly
0, no negative
overlow is detected. This applies overflow detections for user
constraints as
well as for the scaling range. This problem can only occur if
the value zero is
not within the specified range.
253 / 1260
ID:
KPR.2009.12.17.005
Title:
Generation of simulation frame files may stop with an internal

error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The generation of the simulation frame files (part of building a

SIL / PIL
application) may stop with an internal error if all of the
are fulfilled:
- Multirate code generation is enabled (TargetLink version <
3.1: option "Enable
Multirate code generation" selected; TargetLink version >=
3.1: option "Code
generation mode" set to "RTOS")
-- AND -- on top level of the TargetLink subsystem there is an interface
specifying
BusOutport (TargetLink version < 3.1: Simulink outport with
associated
TargetLink BusOutport, TargetLink version >= 3.1: enhanced
BusOutport)
-- AND -- the interface specifying BusOutport has data types / scalings
which differ
from the data types / scaling of its predecessor blocks
-- OR -it has selected a variable class
-- AND -- at least one of the signals the bus consists of is a vector (not
a bus) which
has been created by a Mux block.
In this the following message is thrown:
Generating simulation frame files ...
*** E00000: ERROR USING I_GETSOURCESIGNAL:
*** Internal Error:
*** Source signal cannot be found
*** Please contact dSPACE technical support.
Workaround: TargetLink version < 3.1:
Remove the TargetLink BusOutport from the top level of the
TargetLink subsystem.
If necessary, place TargetLink BusOutports / TargetLink
Outports at the Simulink
outports of subsystems inside the TargetLink subsystem.
TargetLink version >= 3.1:
De-enhance the TargetLink BusOutport from the top level of
the TargetLink
subsystem. If necessary, enhance Simulink outports of
subsystems inside the
254 / 1260
ID:
KPR.2009.12.17.006
Title:
Wrong overflow detection for TargetLink block in enabled or

triggered subsystem with output ranges not containing value 0

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For a TargetLink block which fulfills all of the following

conditions the
overflow detection warning always appears, no matter if the
signal value is
really outside the specified range:
- it is located within an enabled or triggered subsystem
-- AND -- the specified output range (via scaling or user constraints)
doesn't contain
the value 0
-- AND -- (in case the block is located within an enabled subsystem)
the subsystem is
not enabled at the simulation start
The warning looks like following:
Warning #02224: <blockname>:
Negative overflow detected in signal <signalname>
Workaround: Avoid the described configuration, otherwise no workaround
available.
patches:
TargetLink 3.1p5
TargetLink 3.2p1
ID:
KPR.2009.12.17.007
Title:
A user defined InitFcn of a model is not executed during code

generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If the user has specified an InitFcn callback in Simulink model

properties, this
setting is ignored during code generation. Depending what is
done in this init
function, this may result in an uninitialized model.
255 / 1260
ID:
KPR.2009.12.17.008
Title:
Segmentation violation during worst case range calculation of

an Interpolation Using Prelookup block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: A segmentation violation occurs during worst case range

calculation of
TargetLink Interpolation Using Prelookup block for Simulink
versions greater or
equal than 6.5 (MATLAB R2006b). An interpolation block can
be detected via its
MaskType property "TL_Interpolation_n-D".
ID:
KPR.2009.12.17.009
Title:
Vector update code for a output with scope "ref_param" and

preceeding access function variable writes only the first
element

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an output of a subsystem or a chart is a vector and has a

variable class with
Scope property equal to "ref_param" and the predecessor of
the output has an
access function setting the actual variable created for that
output may be
scalar. So all but the first signal will be lost.
Workaround: Use a Rescaler block or a Gain block with a variable class like
NOPT_LOCAL
between the output and the block with the access function
variable. This leads
to an additional copying process and correct code.
256 / 1260
ID:
KPR.2009.12.18.001
Title:
Download via a docking station's serial interface may not work

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A notebook is connected to a docking station. The download

via the docking
station's serial interface may not work. Concerned EVBs are
e.g MPC5554DEMO,
MPC5561EVB, MPC5510EVB etc., but in contrast not a
TBTC1796.
The download does work when connecting the EVB directly to
the notebook's serial
interface.
Workaround: Start the Portmon program and close it. After this, there are no
problems
anylonger.
-- OR -Don't use the docking station.
-- OR -Use a USB to RS232 converter.
-- OR -Contact dSPACE support for another solution.
ID:
KPR.2009.12.18.002
Title:
Variable vector width propagation does not stop at a border of

an incremental, external, referenced or reused system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The propagation of variable vector width does not terminate at

the border of an
incremental, external, referenced or reused system as
desired. So blocks
succeeding the border of such a system inherit the variable
vector width and are
implemented with this variable vector width in the generated
production code.
Workaround: Explicitly terminate variable vector widths propagation at the
outports of the
subsystem as described in TargetLink's user documentation.
ID:
KPR.2009.12.18.003
Title:
Incorrect cast in a 64-bit multiplication function call using TOM

MPC5(x)xx/Diab/GHS

257 / 1260
TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Using one of the target optimation modules (TOM)

MPC5XX/DIAB, MPC5XX/GHS or
MPC55XX/DIAB can lead to an incorrect cast in a function
call. This is possible
for 64-bit multiplication function calls of the TagetLink fixedpoint library.
If a 64-bit warning about a multiplication operation is
generated (Warning
#17352: Implementing 64-bit operation multiplication), the
wrong cast could be
generated for the parameter of the function. If you find a cast
to a smaller
data type than 32-bit, the cast is incorrect. This incorrect cast
is only
generated, if a 64-bit multiplication function is called twice. For
the first
generated call there is no incorrect cast.
Function call with incorrect cast:
Aux__j_lo = AF__I64MULI32I32((Int16)
X_Sa1_Discrete_State_Space[0], 208131275,
&(Aux__j_hi));
There should be no cast:
Aux__j_lo =
AF__I64MULI32I32(X_Sa1_Discrete_State_Space[0],
208131275,
&(Aux__j_hi));
Function calls for which the error is possible if they are called
twice:
AF__I64MULI32I32()
AF__I64MULI32U32()
AF__I64MULI64I32()
AF__I64MULI64U32()
AF__I64MULU32I32()
AF__I64MULU32U32()
AF__I64MULU64I32()
AF__I64MULU64U32()
AF__U64MULI32I32()
AF__U64MULI32U32()
AF__U64MULU32I32()
AF__U64MULU32U32()
AF__U64MULU64U32()
AF__U64MULI64I32()
AF__U64MULI64U32()
AF__U64MULU64I32()
Workaround: Deselect the option "Functions for 64-bit operations" in the
TargetLink Main
Dialog's Advanced page.
258 / 1260
ID:
KPR.2009.12.18.004
Title:
Bus Inport with logged output variable leads to fatal error

#10007

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A model contains a Bus Inport block. The block drives

exclusively directly or
indirectly the inports of one of the following blocks:
- The block drives exactly one data inport of a Multiport Switch
block.
- The block drives exactly one data inport of a Switch block.
- The block drives the inports of exactly one action triggered
subsystem.
- The block drives the inports of exactly one enabled
subsystem.
Logging is specified for one output signal of the Bus Inport
block, and the
variable classes of all of the Bus Inport's output variables are
either
"default" or a class with Optimization property "MOVABLE"
selected.
Additionally, every block between the Bus Inport block and the
Multiport Switch
block, Switch block, action triggered subsystem, or enabled
subsystem also
drives directly or indirectly exclusively the inports listed above
and the
variable class for its output variable is also "default" or a class
with
Optimization property "MOVABLE" selected.
In this case, code generation stops with an error like the
following:
Fatal #10007:
Internal error. Error code: TL_BcBlockContext 262. Contact
dSPACE's technical
support team.
Workaround: Specify for one of the Bus Inport's output variables a variable
class that does
not have Optimization property MOVABLE selected.
259 / 1260
ID:
KPR.2009.12.18.005
Title:
Invalid time values (shrunk) during MIL logging of a InPort

block in function-call triggered subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Under certain conditions the log data of a TargetLink InPort

block contains
invalid time values after a MIL simulation.
The plot shows a curve which is assembled by several
horizontally shrunk
segments of the expected plot. These segments are
connected via straight lines.
The shrunk segments are shown at plot intervall times. If the
plot intervall is
infinity, the complete horizontally shrunk plot line is shown at
simulation end.
This problem occurs if all of the following conditions are
fulfilled:
- Logging is enabled for the affected inport block
-- AND -- The affected inport block is located in a function call
triggered subsystem
-- AND -- This subsystem is triggered by a Stateflow chart which is
triggered by a
function call as well.
If the subsystem chart is executed at every n-th chart trigger,
the simulation
time is shrunk by factor n.
Workaround: On MATLAB R2011a or newer use the Simulink signal logging
format Dataset via the
simulation confguration parameters.
Else there is no workaround available for the InPort block. For
such a
configuration, the successor(s) of the inport block should be
used for MIL
logging. They are not affected by this problem.
ID:
KPR.2009.12.18.006
Title:
Incorrect results for bitwise operation whose result is assigned

to a floating-point variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
260 / 1260
Description: A bitwise operation in TagetLink can be specified to be

calculated in a width
smaller than the target platform's integer type.
This can be done by feeding an input with a data type smaller
than the target
platform's integer type to one of TargetLink's bitwise
calculation blocks (since
TargetLink 3.1) or by specifying an operation like
Int8 Out;
Int8 In1;
Int8 In2;
Out = In1 & In2;
in Stateflow.
In such cases the code may be wrong if
- the result of a bitwise block is fed to a floating-point block
(e.g. an
OutPort block with a floating-point output data type)
-- OR -- in Stateflow the result of the bitwise operation is assigned to
a
floating-point variable
-- AND --the variable holding the result of the bitwise operation is
removed by the code
optimization.
Example:
specified in Stateflow:
Int8 Out;
Int8 In1;
Int8 In2;
Float32 Out2;
Out = In1 & In2;
Out2 = Out;
becomes, if Out can be removed
Out2 = (Float32)(In1 & In2);
In this case the bitwise operation will be calculated using the
plattform's
integer type and not Int8 as specified.
Workaround: Make sure that the variable receiving the result of the bitwise
operation cannot
be removed by the code optimization.
ID:
KPR.2009.12.18.007
Title:
Erroneous elimination of control flow for outputs of macro calls

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
261 / 1260
Class:
Description: For situations where the output of a macro with parameters

drives the input of a
conditionally executed subsystem or a data input of a Switch
or Multiport Switch
Block, the following erroneous optimization can occur:
i1 = ...
MACRO2(..., i2);
if (cond) {
o = i1;
} else {
o = i2;
....
}
is replaced by
... /* Definition of i1 */
MACRO2(..., o);
if (cond) {
o = i1;
} else {
....
}
This in principle is correct but the optimization is performed for
the wrong
reasons. If "i1" also is a macro parameter, then it is possible
that this
optimization is performed twice, leading to
MACRO1(..., o) /* Formerly: Definition of i1 */;
MACRO2(..., o);
which is wrong.
Note that a parametrized macro also can be generated by
TargetLink, e.g. for
64-bit calculations or for fixed-point versions of math
functions.
The following conditions need to hold for the problem:
- Optimization is activated (OptimizationLevel > 0)
-- AND -- The macro has a function class with deselected MOVABLE
and SIDE_EFFECT_FREE
-- OR -the macro is a TargetLink generated macro
-- OR -the macro has default function class
-- AND -- The output variable of the macro is used in exactly one
assignment inside a
conditionally executed control flow branch and has a variable
class with
selected ERASABLE Optimization property or default variable
class
In order to arrive at a situation where wrong code is
generated, additional
conditions have to hold:
- For TargetLink < 3.1, the macros have to be called in reverse
order with
respect to the using of their output variables, i.e.
262 / 1260
MACRO2(i2);
MACRO1(i1);
if (cond) {
o = i1;
} else {
o = i2;
}
- For TargetLink >= 3.1, the macros have to be called in the
same order as their
output variables are used in the conditionally executed control
flow branches,
i.e.
MACRO1(i1);
MACRO2(i2);
if (cond) {
o = i1;
} else {
o = i2;
}
Note that this is the usual order for TargetLink generated
code, i.e. the
probability of incorrect code is increased.
Workaround: Insert a Rescaler block (or TargetLink Port block for
TargetLink < 3.0) between
the output of the block or subsystem leading to a macro call
and the
conditionally executed subsystem, Switch block, or Multiport
Switch block.
Select "inherit signal properties"; set the output variable class
to a class
with deselected ERASABLE Optimization property.
patches:
TargetLink 3.1p2
263 / 1260
ID:
KPR.2009.12.21.002
Title:
Wrong autoscaling results using a scaling propagation

function for scaling invariant subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a subsystem is specified as scaling invariant, the user has to

define a
so-called scaling propagation function. This function usually
calculates scaling
information for the subsystem's outports depending on the
scalig parameters of
the inputs. Due to a wrong handling of the input parameters,
this calculation
may be wrong.
Workaround: In the block succeeding the scaling invariant system set the
Scaling propagation
property to "No autoscaling" to prevent propagation of the
wrong result.
264 / 1260
ID:
KPR.2009.12.21.003
Title:
Logging signal data via Simulink signal properties is not

possible without activating the "Test point" option

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The problem occurs if it is desired to use logging in TargetLink

models via
Simulink signal properties and not via TargetLink's logging
capabilities. Such a
case is detected by TargetLink if at least one signal in the
model contains a
test point at simulation start time.
In all MATLAB versions up to R2008a, it is sufficient to check
just for the
"Test point" option in Simulink signal properties because it is
automatically
activated (and grayed out) if the "Log signal data" option is
activated.
However, since MATLAB R2008b the "Log signal data" and
the "Test point" options
are independent.
TargetLink doesn't detect that logging via Simulink signal
properties should be
used if only the "Log signal data" but not the "Test point"
option is selected.
In this case TargetLink assumes that the
Simulink.ModelDataLogs workspace
variable (which contains all Simulink log data) is only
temporary used for
TargetLink MIL logging and removes it after finishing the
simulation.
Workaround: Always select "Test point" option if "Log signal data" is
selected.
patches:
TargetLink 3.1p5
265 / 1260
ID:
KPR.2009.12.21.004
Title:
Incorrect code for bitwise operation with large constant value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow a bitwise operation is specified

- in an expression that contains operands that have different
TargetLink and
Stateflow data types and that do not have a scaling, i.e. LSB
== 1.0 and Offset
== 0.0
-- AND -- if the bitwise operation contains an operand that is not a
constant value
-- AND -- if the bitwise operation contains another operand that is a
constant value
-- AND -- if the constant value cannot be represented in the type of the
other operand
-- AND -- the result of the bit operation is part of an operation that
demands a data
type that can represent the constant value,
then the generated code may be incorrect.
Example:
8 bit bitwise operation in 16 bit assignment.
Int16 I16Var; // StateflowType: double; TargetLinkType: Int16
Int8 I8Var; // StateflowType: double; TargetLinkType: Int8
I16Var = I8Var & 1000;
will erroneously be implemented as
I16Var = (Int16) (I8Var & ((Int8) 1000))
Workaround: Cast the non constant operand to the type of the result.
patches:
TargetLink 3.1p2
266 / 1260
ID:
KPR.2009.12.21.005
Title:
Combination of TargetLink Merge block and non-virtual buses

causes errors during MIL simulation or abnormal termination
of MATLAB

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If the inputs of a TargetLink Merge block are non-virtual buses

one of the
following errors may occur during MIL simulation:(A) MATLAB
before R2009b
terminates abnormally.
(B) One of the following error messages is reported on
MATLAB R2009b or newer:
Error evaluating 'InitFcn' callback of block_diagram 'MyModel'.
Attempt to use invalid data type id 14
Attempt to use invalid data type id 15
Workaround: - In case of (A): Avoid use of non-virtual buses in combination
with a
TargetLink Merge block.
- In case of (B): Start the MIL simulation with the TargetLink
Main dialog, Plot
window or with the API command tl_sim().
267 / 1260
ID:
KPR.2010.01.06.001
Title:
Missing addition or subtraction of constant or scaling offset

when at least one operand is floating-point

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: There are missing additions and/or subtractions of constants

in the generated
code when the following conditions are fulfilled:
- A Sum block has an integer output type
-- AND -- saturation is activated at the output of the Sum block
-- AND -- at least one input signal of the Sum block has a floating-point
data type
-- AND -- at least one input signal of the Sum block is a "real" constant
(e.g. a
Constant block with default variable class) or is fixed-point
(non-floating-point) signal with a scaling offset.
If all conditions are fulfilled, the addition or subtraction of the
"real"
constant or scaling offset is missing in the generated code.
Workaround: If the Sum block is driven by a Constant block:
Either do not select saturation at block output of the Sum
block or use a
variable class unequal "default" for the Constant block(s).
If the Sum block is driven by a signal with a scaling offset:
Do not select saturation at block output of the Sum block.
268 / 1260
ID:
KPR.2010.01.08.001
Title:
Not compilable code or code generation aborts for AUTOSAR

calibration interface for a look-up table

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Using AUTOSAR calibration interfaces for a Look-Up Table

blocks or a Look-Up
Table (2D) block with selected option "Generate map struct"
for one of the axis
or table variables leads to not compilable code or code
generation aborts with
an access violation.
For these variables it is also not possible to use an access
function with
property Kind = ADDRESS and this access function is
implemented as a function.
In both situations the initialization of the map structure is
generated using a
non-constant initializer. This is not allowed in ANSI-C.
Trying to compile this code (see the example) leads to an
error.
Example:
static const MAP_Tab2DS17I2T4169
Sc5_Pumping_Constant_map = {
18 /* Nx: */,
19 /* Ny: */,
(const U16_Speed *)
Rte_Calprm_RpAxisCalPrms_SpeedAxis() /*
Error: initializer is not a constant */,
(const U16_Map *) Rte_Calprm_RpAxisCalPrms_MapAxis()
/*Error: initializer is not a constant */,
(const uint16 *) &(pumpCon_z_table[0][0])
};
Note: since TargetLink 3.5 the code generation will abort with
an error message
#30126.
Workaround: Deselect the option "Generate map struct" in a look-up table
block.
269 / 1260
ID:
KPR.2010.01.08.002
Title:
Code generation stops at attempt to optimize implicit reading

RTE API call used in an array element access or macro call

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the output of an implicit reading RTE API call, that is, the
output of a
TargetLink port or a Receiver ComSpec Block drives
- a dynamic Selector or Assignment block or is used otherwise
in a vector
element access (e.g. in a Stateflow chart)
-- OR -- more than one block, one of them a block leading to a macro
call with this
output as argument of the call,
then TargetLink stops code generation with an access
violation.
Example:
u8CycleNumber = Rte_IRead_<...>_u8CycleNumber();
...
if (u8CycleNumber > MAX_NUMBER_OF_CYCLE) {
...
}
else {
...
UpdatedCounters[u8CycleNumber] =
UpdatedCounters[u8CycleNumber] + 1 /* 1.
*/;
}
If optimization level is > 0, then the problem occurs when
trying to optimize
"u8CycleNumber".
Workaround: Check the Runnable inports' (or their succeeding ComSpec
blocks') successors
with respect to array accesses and macro calls; insert a
Rescaler block after
affected inports (or ComSpec blocks, respectively) that has
activated "inherit
signal properties" and a variable class with deselected
ERASABLE Optimization
property.
patches:
TargetLink 3.1p1
270 / 1260
ID:
KPR.2010.01.08.004
Title:
Wrong display of signal data in busport block dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The display of AUTOSAR signal data in TargetLink Busport

blocks is wrong, if
- communication kind is operation argument
-- AND -- signal names in model differ from component names of the
associated structure
in the Data Dictionary.
Workaround: Use same names in model and Data Dictionary.
patches:
TargetLink 3.1p1
ID:
KPR.2010.01.08.005
Title:
Wrong placement of requirement informations of Runnable

Inports with AUTOSAR communication kind "Inter-runnable"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If for the Inport block of a Runnable the AUTOSAR

communication kind
"Inter-runnable" is specified and the Inport block is associtated
with
requirements, in the generated code the requirements
information is not placed
at the resulting invocation of the RTE call. Instead the
requirements
information is placed at the update of the inter-runnable
variable.
Precondition for the problem is the use of the TargetLink
support of the
requirement management interface of the Simulink Verification
and Validation
software from The MathWorks. See TargetLink Producation
Code Generation Guide
for more information about this topic.
271 / 1260
ID:
KPR.2010.01.11.001
Title:
Missing MERGEABLE attributes for CALPRM in AUTOSAR master template

dsdd_master_autosar.dd

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR master template doesn't contain the MERGABLE attribute for
the
following variable classes:
/Pool/VariableClasses/AUTOSAR/SHARED_CALPRM
/Pool/VariableClasses/AUTOSAR/SHARED_CALPRM_COMPOSITE_TYPE
/Pool/VariableClasses/AUTOSAR/CALPRM_VARIABLE
/Pool/VariableClasses/AUTOSAR/CALPRM_VARIABLE_COMPOSITE_TYPE
As consequence the defined calibration variables that references one of these
variable classes cannot be merged during code generation. This implies that
a
Data Dictionary Variable object can be referenced only ones in a TargetLink
model. The following error message will be thrown for a Variable object of the
above listed classes if the attribute is not set.
Error #17299: TL_Controller/Position_Linearization_Runnable/Constant:
Name ambiguity of identifier Rte_SharedCal_Controller_SharedCalVariable.
The
variable was first declared for 'TL_Controller/Controller_Runnable/Constant'.
Neither is one of the variables specified as 'extern' nor are both variables
declared as 'mergeable'.
Workaround: Select the MERGABLE attribute to the Optimization property of the variable
classes:
/Pool/VariableClasses/AUTOSAR/SHARED_CALPRM
/Pool/VariableClasses/AUTOSAR/SHARED_CALPRM_COMPOSITE_TYPE
/Pool/VariableClasses/AUTOSAR/CALPRM_VARIABLE
/Pool/VariableClasses/AUTOSAR/CALPRM_VARIABLE_COMPOSITE_TYPE
272 / 1260
ID:
KPR.2010.01.11.002
Title:
Frame generation may fail for cascaded event triggered

subsystems containing bus signals

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a TargetLink subsystem contains cascaded event (functioncall) triggered

subsystems and the topmost system is called from outside the
TargetLink
subsystem and the interface of a cascaded system contains
bus signals, then the
simulation frame generation may fail with the following error:
E00000: ERROR USING I_GETSOURCESIGNAL
273 / 1260
ID:
KPR.2010.01.12.001
Title:
Data variant switch variable missing in the generated TRC file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a stand-alone S-Function is generated for TargetLink

subsystem by means of
the Standalone Model Manager and the production code
generated for this
TargetLink subsystem contains a data variant, the data variant
switch variable
is missing in the generated user TRC file. It must be added
manually, if you
need to modify its value by means of the dSPACE Control
Desk to be able to
switch between the data variants:
group "SwitchVariable"
{
flags: COLLAPSED
}
<SwitchVariableName>
{
type: <SwitchVariableType>
alias: <SwitchVariableName>
desc: ""
flags: PARAM
scale: [1 0 ] -- [lsb offset]
scaleback: [ 1 0 ]/[1 ] -- [1 -offset]/[lsb]
}
endgroup
whereas <SwitchVariableName> has to be replaced with the
name of the switch
variable and <SwitchVariableType> is to be replaced with the
switch variable
data type, for example uint(8), int(8) etc.
patches:
TargetLink 3.1p2
274 / 1260
ID:
KPR.2010.01.12.002
Title:
Block dialog erroneously shows message about inconsistant

data for a parameter

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If for a block's parameter the same value is specified for Min,
Max and the
parameter value, the message "Inconsistent data: max value
is not in implemented
range." is shown erroneously.
patches:
TargetLink 3.1p2
ID:
KPR.2010.01.12.003
Title:
Model initialization fails after upgrade

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Model initialization fails after upgrade for models that

- are created in TargetLink 2.x by conversion from a Simulink
model
-- AND -- a specific sample time, e.g. 'ts' was specified at a Simulink
port before
conversion
-- AND -- after conversion to TargetLink model this specific sample
time was changed,
i.e. to 'T'.
After TargetLink upgrade to TargetLink 3.0 and newer the
sample time was reset
to the original 'ts', which leads to an initialization error.
Workaround: Correct the sample time manually
275 / 1260
ID:
KPR.2010.01.12.004
Title:
Incomplete behavior of AUTOSAR export merge option

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the user selects more than one subsystem he can set the
merge option of the
AUTOSAR export to on (e.g. dsdd('export',...,'merge','on')).
This yields to the
behavior that AUTOSAR elements with the same short name
and package path will be
merged across subsystems. The following elements are
merged:
COMPU-METHOD, PRIMITIVE-TYPE-WITH-SEMANTICS,
SENDER-RECEIVER-INTERFACE,
ARRAY-TYPE, BOOLEAN-TYPE, CHAR-TYPE, CLIENTSERVER-INTERFACE, INTEGER-TYPE,
REAL-TYPE, RECORD-TYPE, STRING-TYPE, MODEDECLARATION-GROUP, UNIT,
PHYSICAL-DIMENSION
For a whole export the set (see above) of AUTOSAR
elements to be merged is
incomplete. Especially the merge of the same software
component, that is defined
across two subsystems. As a result the exported AUTOSAR
file contains two
specifications of the AUTOSAR elements like *COMPONENT-TYPE, etc.
276 / 1260
ID:
KPR.2010.01.12.005
Title:
Variable class object with property Macro = "on" and/or Const

= "on" cannot be selected in Property Manager

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The Property Editor allows to select and assign a variable

class to e.g. a
Constant block that is selected in the Block Explorer
(output.class property). A
listbox shows all VariableClass objects that can be selected.
However,
VariableClass objects whose Macro and/or Const properties
are "on" do not appear
in the list, and can thus not be written to a Constant block or
Stateflow
Constant object.
- Use the blocks' dialog to assign the VariableClass object
- Use the Block Explorer (inline editing) to assign the
VariableClass object
- Use the TargetLink API tl_set command to assign the
VariableClass object
patches:
TargetLink 3.1p3
277 / 1260
ID:
KPR.2010.01.12.006
Title:
Error message "E00000: SIL SIMULATION NOT POSSIBLE"

after code generation if Solver is "FixedStepDiscrete" and
StepSize is greater than 1

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The error message

*** E00000: SIL SIMULATION NOT POSSIBLE:
*** The TL subsystem 'Subsystem' cannot be simulated in SIL
mode.
*** It should be triggered with the sample time of 1 sec
*** which is not a integer muliple of the solver's fixed step size
of
<current step size> sec.
*** Check the setting for sample times and counter's tick
duration in
this subsystem.
is thrown after code generation for a model, which
Simulation/Configuration
Parameters (tab 'Solver') has the following settings:
Type: Fixed-step
Solver: discrete (no continuous state)
Fixed-step-size (fundamental sample time): <a value greater
1>
patches:
TargetLink 3.1p3
278 / 1260
ID:
KPR.2010.01.13.001
Title:
Code generation may stop at a SWC Reciever Port block or a

SWC Sender Port block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The use of the SWC Receiver Port block leads to an access
violation during the
code generation if
- the inport of the SWC Receiver Port block is not connected
-- OR -- the inport of the SWC Receiver Port block is not connected
to an Inport block
-- OR -- the inport of the SWC Receiver Port block is connected to an
Inport block but
the connection is not 1:1, i.e. there is a branch in the signal
line.
The use of the SWC Sender Port block leads to an access
violation during the
code generation if
- the outport of the SWC Sender Port is not connected
-- OR -- the outport of the SWC Sender Port is not connected to an
Outport block
-- OR -- the outport of the SWC Sener Port is connected to an
Outport block but the
connection is not 1:1, i.e. there is a branch in the signal line.
Workaround: Connect the inport of the SWC Receiver Port with an Inport
Block with a direct
(1:1) connection.
Connect the outport of the SWC Sender Port with an Outport
Block with a direct
(1:1) connection.
279 / 1260
ID:
KPR.2010.01.13.002
Title:
Data Dictionary CodeGenerationUnit object cannot be

selected in the Standalone Model Manager

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: It is not possible to select a DataDictionary

CodeGenerationUnits in the
Standalone Model Manager.
It means that C modules generated straight from the Data
Dictionary and needed
to build a stand-alone S-function for selected TargetLink
subsystem(s) are
always generated and exported to the destination directory as
a stub code,
instead of production code.
But they contain identical code as their production code
versions, excepts the
stub code statement. The generated user make file, needed to
build a real time
application by means of dSPACE RTI, is also correct.
ID:
KPR.2010.01.13.004
Title:
Using a variable class template at the interface of a

referenced system may lead to errors during the code
generation of the referencing system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation for a referencing system stops with the error
E10648, if all of
the following points are fulfilled
- a variable class template is used at the interface fo the
referenced system
- the variable class referenced by the variable class template
references a
module object
- the referenced module object has a name template
(ModuleInfo > NameTemplate)
which contains at least one upper-case letter (name macros
are not taken into
account)
Workaround: Use only lower-case letters in the name template of the
referenced Module
object.
280 / 1260
ID:
KPR.2010.01.13.005
Title:
Code generation stops in case of model referencing if

TargetLink base type references a Module object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation stops at a referencing system with an error

like the following:
E08906: SYSTEM INTERFACES VALIDATION:
Data mismatch found. Property ModuleRef of typedef object
/Subsystems/<...>/tl_basetypes/Typedefs/UInt16 differs from
the origin in the
pool area. Do not edit the subsystems area. If you have edited
the variable
class in the pool, run code generation for the referenced
model <...> again.
This happens if a TargetLink base type references a Module
object and the base
type is used at the interface of a referenced system.
Workaround: Deleting the ModuleRef property. This has no impact to code
generation because
the code generator omits the ModuleRef property at
TargetLink base types.
ID:
KPR.2010.01.14.001
Title:
Replacement of function and block output variables loses

range information and may lead to wrong code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If
- a block with an output that has a variable class that has the
Optimization
property ERASABLE set
-- OR -- a function subsystem with call by reference or return output
that has empty
ArgClass or references as ArgClass a variable class that has
the Optimization
property ERASABLE set
drives a block that creates multiple definitions for its output
variable, range
propagation may be faulty and introduce erroneous code for
the succeeding
blocks.
Blocks producing multiple definitions for their output variables
281 / 1260
that can be
affected by this problem are
- Switch block
- Multiport Switch block
- Merge block
- MinMax block
- Saturation block with floating-point input and/or output or
floating-point
limits
Example:
A Custom Code block drives the first data input of a Switch
block and a Constant
block with value 42 drives the second data input.
The Switch block in turn drives a data input of a MinMax block
where the other
input has a value range that does not contain 42 or contains
42 as one of its
boundary values.
This leads to initial code of the kind
if (cond) {
/* Custom Code Block <<output section>> */
{
Sa4711_CC_out = ....
}
Sa4711_Switch = Sa4711_CC_out;
} else {
Sa4711_Switch = 42;
}
if (Sa4711_Switch < 100) {
Sa4711_MinMax = 100;
} else {
Sa4711_MinMax = Sa4711_Switch;
}
If "Sa4711_CC_out" is replaced by "Sa4711_Switch", then the
comparison
"Sa4711_Switch < 100" erroneously evaluates to "always
true". Further
optimizations yield
if (cond) {
/* Custom Code Block <<output section>> */
{
Sa4711_Switch = ....
}
}
Sa4711_MinMax = 100;
and depending on the right hand side of the last assignment
may be optimized
even further.
282 / 1260
Workaround: 1a) For block outputs: Create a workaround variable class for
the block that has
no set ERASABLE Optimization property.
1b) For function outputs: Specify an ArgClass that has no set
ERASABLE
Optimization property or switch to returning the respective
output (variable
class with Scope property set to "fcn_return").
OR
2) Insert a Rescaler block or TargetLink port block between
the block / Function
subsystem and the following block that has a non-ERASABLE
variable class as
output class.
patches:
TargetLink 3.1p2
ID:
KPR.2010.01.14.002
Title:
Generating of simulation frame files stops when referencing

an extern and mergeable Data Dictionary variable several
times

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A variable is specified in the Data Dictionary. It has a variable

class with
Storage = "extern" and selected Optimization property
"MERGEABLE". The variable
is referenced in different blocks in a model. In this case the
simulation frame
could not be built because TargetLink throws error #06273
complaining about a
property of the Data Dictionary variable that could not be
resolved.
Furthermore the generated code is less efficient because it
contains assignment
that look like
MyVar = MyVar;
Workaround: Specify a variable class that has either Storage = "extern" or
Optimization
property "MERGEABLE" selected.
283 / 1260
ID:
KPR.2010.01.14.003
Title:
API function tl_get_userdata fails for the TargetLink Main

Dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The API function tl_get_userdata reads the block comment of

a given TargetLink
block, searches for the key word $TLUSERDATA$ and
evaluates everything
encapsulated by it in MATLAB. This API function fails for the
TargetLink Main
Dialog. Although there might be user data specified, the
function returns an
empty struct.
ID:
KPR.2010.01.14.004
Title:
Wrong data type at the output of TargetLink subsystem in

SIL/PIL mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In some cases TargetLink does not require TargetLink

OutPort blocks or enhanced
Simulink ports on the root level of a TargetLink subsystem.
Simple Simulink
outports are sufficient. However, in SIL or PIL simulation
mode TargetLink
cannot correctly determine the Simulink data type for the
TargetLink subsystem's
outputs modeled only by means of the Simulink ports. The
data type is always set
to "double". This may lead to an initialization error if other data
type is
required.
Workaround: Enhance the outport (TargetLink 3.0 or newer) or use a
TargetLink OutPort (prior
to TargetLink 3.0) on the topmost level of the TargetLink
subsystem,
respectively. Note that this leads to unnecessary interface
variables, which may
be eleminated using merge of variables.
284 / 1260
ID:
KPR.2010.01.14.005
Title:
Simulation difference between MIL and SIL/PIL at Unit Delay

Reset Enabled block for negativ input values at enable input
"E"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In MIL simulation mode the delay funtionality of the Unit Delay
Reset Enabled
block is enabled if the "Input E" is driven by signals equal to or
larger than
1. In the generated code the delay functionality is enabled by
any signal not
equal to 0. This causes differences between MIL and SIL/PIL
simulation for
negativ values at input "E".
Workaround: - Change signal path to Input E in a way, that negativ signals
are converted to
positiv signals. This will change MIL results to SIL/PIL
behaviour.
- Change signal path to Input E in a way, that negativ signals
are converted to
0. This will change SIL/PIL results to MIL behaviour.
ID:
KPR.2010.01.19.001
Title:
Infinite loop during generation of simulation frame files

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The generation of the simulation frame files for a model

component (TargetLink
subsystem or Subsystem configured for incremental code
generation) may not
finished if following applies:
- the production code has been generated in AUTOSAR mode
--AND -- the model component contains stateflow charts
In this case after the production code has been succesfully
generated, following
info is displayed in MATLAB command window
"Generating simulation frame files ... "
and then MATLAB freezes.
patches:
TargetLink 3.1p2
285 / 1260
ID:
KPR.2010.01.19.002
Title:
Code generation stops on reused system with Data Store

Read or Data Store Write block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A reused subsystem contains a Data Store Read block or a

Data Store Write block.
Several instances of the system are placed in a model. The
corresponding Data
Store Memory block is placed outside the reused subsystem.
Addiditionally, the
Name property of the block's variable is not fixed, that means
it contains a $S
or a $R.
In this case TargetLink may stop code generation with fatal
error like the
following:
"Fatal #30016: Subsystem/ZZZ:
reuse. Contact
dSPACE support. Reason: The variable 'Sa1_ZZZ' shall be
used in the subsystem
'Subsystem/BBB'. But it was created for the subsystem
'Subsystem/AAA'. Reuse of
this variable is not possible."
Workaround: Specify a fixed name for the Data Store Memory block's
variable.
286 / 1260
ID:
KPR.2010.01.20.001
Title:
Code generation stops with error #90105 during processing of

tl_get_compiled_data

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a TargetLink subystem contains an InPort block that passes

a non-bus signal
that originates from a Bus Selector which specifies that one
signal of an
incoming bus signal should be selected, code generation
aborts with an error
message:
"Error #90105:
Internal error. Contact dSPACE technical support.
The eval command in tl_get_compiled data failed. See
message below
Undefined function or variable 'port'."
Workaround: Place a block between InPort and Bus Selector, for example,
a Data Type
Conversion block.
patches:
TargetLink 3.1p2
ID:
KPR.2010.01.21.001
Title:
Wrong rounding of Float32 value in relational operation yields

incorrect code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
287 / 1260
Description: TargetLink generates incorrect code for a relational operation

if
- one operand of the relational operation is Float32
-- AND -- the other operand is a constant value, which cannot be
represented in Float32
exactly.
Such a relational operation may be modeled directly or may
come up due to the
implemented code pattern by TargetLink. For example, the
MinMax block and the
Saturation block may lead to such relational operations.
Additionally, all
blocks with Float32 input signals and output saturation
activated may lead to
relational operations in the saturation control flow.
Example:
Given is a TargetLink block having a Float32 output data type
set. Its output is
connected to a TargetLink Outport block with an UInt32 type,
LSB = 2^(-11) and
activated "Saturate" checkboxes. TargetLink then generates
control flow to
implement the saturation. For the upper saturation, in principle
the incoming
signal value has to be checked whether it is greater than
((2^32 - 1) * LSB) =
2097151.99951171875. Because the values are rather big,
there is not enough
precision in a 32-bit floating-point value to represent this value
exactly.
After rounding, the implemented value instead it equals to
2097152, which is
2^32 * LSB. If the incoming signal equals to (2^32 * LSB), this
leads to an
overflow, because the upper limit of the saturation is out of the
range.
The incorrect code for this example looks like
if (INPUT > 2097152.F) {
OUTPUT = 4294967295U;
}
else {
if (INPUT < 0.F) {
OUTPUT = 0;
}
else {
OUTPUT = (UInt32) (INPUT * 2048.F);
}
}
288 / 1260
Workaround: When dealing with quantities in single precision (Float32),

always ensure that
the values can be represented in Float32 exactly.
In the case of the example, use either a higher precision (e.g.
double
precision, Float64) or use a Saturation block with the next
representable
Float32 value downwards as the upper limit, e.g.
2097151.875.
ID:
KPR.2010.01.22.001
Title:
Opening TargetLink "More infos about" plot window with

activated staircase mode leads to a frozen MATLAB

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Opening the TargetLink "More infos about" plot window with
activated staircase
mode leads to a delay until the window is open. Depending on
the number of
simulation steps contained in the plot, this can take so long
time that MATLAB
is practically frozen.
Example:
A plot with 20000 simulation steps leads to a 30s delay, a plot
with 100000
simulation steps to a 15min delay.
Workaround: If the simulation contains more than about 10000 simulation
steps, deactivate
the staircase mode before opening a "More infos about" plot
window
patches:
TargetLink 3.1p2
289 / 1260
ID:
KPR.2010.01.28.001
Title:
Extremely slow code generation for complicated Stateflow

charts with output events

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In case output events are declared in a Stateflow chart

containing many
execution branches and joins, code generation may take an
extremely long time.
For example, a structure such as the following is modeled in a
Stateflow chart
with output events, the code generation time is exponential in
N.
if (condition1) {
then_action1;
} else {
else_action1;
}
if (condition2) {
then_action2;
} else {
else_action2;
}
...
if (conditionN) {
then_actionN;
} else {
else_actionN;
}
Workaround: Partition the Stateflow chart into several graphical functions.
290 / 1260
ID:
KPR.2010.01.28.002
Title:
Code generation stops at block parameter which is specified

as a function parameter of a referenced system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a referenced system contains a block with a parameter

which is specified to
be a function parameter (variable class' Scope property "callby-ref" or
"call-by-value") of the referenced system's step function and
the name of the
actual parameter of the variable is not explicitely specified,
then code
generation for the system containing the referenced system
may fail with the
E17299: VARIABLES MESSAGES:
Name ambiguity of identifier <ParameterVariable>. The
function parameter was
first declared for '//DD0/Pool/Variables/<ParameterVariable>'.
Merging different
kinds of identifiers is not permitted. One is declared as
function parameter,
the other one as variable.
Workaround: Specify a unique name for the actual parameter. Use the
TargetLink notation
"<FORMAL>:<ACTUAL>" in the name template of the Data
Dictionary variable in
question, e.g. "f_MyParam:MyParam".
291 / 1260
ID:
KPR.2010.02.02.001
Title:
More than one cast applied to a scaled constant leads to

incorrect code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable with a scaling is replaced by its initial value and

this value is
subject to at least two casts, then it may happen that instead
of the scaled
value, the physical value is used.
Example:
A Constant block has a scaling with LSB = 2^-1, data type
"T0", a constant value
of 5 and an output variable variable class with selected
property.
In the generated code, code optimization replaces the output
variable by the
constant value "10 /* 5. */".
If this constant value drives e.g. a Switch block with output
type T1 and a
subsequent TargetLink outport (or enhanced Simulink outport)
with output type
T2, then the generated code will look like
o = (T2)((T1) 10 /* 5. */);
If "(T1) 10" has the same value as "10" and the resulting
expression is subject
to a cast, then the cast to "T1" can be omitted without loss of
information.
Here, an error may occur and instead of
o = (T2) 10 /* 5. */;
the wrong
o = (T2) 5 /* 5. */;
is generated.
Workaround: Break the cast chains by introduction of non-ERASABLE
variables. In the terms of
the example, either make the Switch block's output nonERASABLE:
s = ((T1) 10 /* 5. */);
o = (T2) s;
or make the Constant block's output non-ERASABLE:
o = (T2)((T1) c);
Alternatively, make sure that there is only one type change
involved, by either
choosing T0 := T1 or T1 := T2
patches:
TargetLink 3.1p2
292 / 1260
ID:
KPR.2010.02.02.002
Title:
ScalingAdjust property ignored for customer-specific C

function if a function argument is replaced by its initial value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Incorrect code may be generated for a customer-specific C

function from
Stateflow if following conditions hold:
- the "ScalingAdjust" property of a function's argument is set to
"no"
-- AND -- this argument is replaced by its initial value
Example:
Assume the following function call is specified in Stateflow:
MyFcn( ErasableVar );
and the function
void MyFcn(Int16 Param1);
is specified in a customer-specific C function script.
The "ScalingAdjust" property of parameter Param1 is "no" and
the LSB of that
parameter is 2^-1.
The actual parameter variable ErasableVar is specified to be:
Int16 ErasableVar = 5; // with a variable class that specifies
ErasableVar to be
ERASABLE via the Optimization property
Then the actual parameter ErasableVar may be replaced by
its initial value (5).
In that case the "ScalingAdjust" property of the function
parameter may be
ignored and MyFcn(10) instead of MyFcn(5) may be
generated.
Workaround: Do not select the ERASABLE Optimization property in the
variable class of
variables that are arguments of customer-specific C functions,
if they are not
to be scaled.
293 / 1260
ID:
KPR.2010.02.10.001
Title:
Variable with variable class property "Alias" = "on" maybe

wrongly used as an interface variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are fulfilled wrong code is

generated:
- A block output drives an outport of a conditionally executed
subsystem which
is not an interface specifying outport
-- AND -- the block output variable has following variable class
properties set: "Alias"
= "on", "InitAtDefinition" = "off" and "RestartFunctionName" =
"<empty string>".
The generated code is incorrect because the block output
variable is used as an
interface variable for the outport of the conditionally executed
subsystem
although the variable class settings "InitAtDefinition" = "off"
and
"RestartFunctionName" = "<empty string>" state that the
variable is not
initialized. A variable which is not initialized is not suitable for
an outport
of a conditionally executed subsystem.
Note:
- For external or alias variables the variable class settings
"InitAtDefinition"
and "RestartFunctionName" are used by the code generator
as a confirmation that
the variable is initialized resp. not initialized.
- 'outport which is not an interface specifying outport' means:
- TargetLink versions < 3.0: Simulink Outport without an
associated TargetLink
Outport.
- TargetLink versions >= 3.0: Simulink Outport which is not
enhanced.
Workaround: If your Alias variables are not initialized do not use them for
block outports
which drive an outport of a conditionally executed subsystem
which is not an
interface specifying outport.
ID:
KPR.2010.02.17.001
Title:
Code generation stops with fatal error F10008 during

optimization of vector code
294 / 1260
TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The combination of loops during optimization might cause a

fatal error like the
following:
Fatal #10008: <block>:
Internal error. Error code: TlCLoopMerger 549. Contact
dSPACE's technical
support team.
This happens if the start index of the first loop is greater than
the start
index of the second loop and has therefore to be adapted.
In the following the conditions of the occurence are descriped
in detail.
To generate optimized vector code, TargetLink creates a loop
for most blocks
that have a signal width greater than or equal to the code
generator option
"LoopUnrollThreshold" (see e.g. TargetLinkMain Dialog >
Advanced Tab >
AllOptions > CodeGeneration/Pattern/LoopUnrollThreshold).
Example:
The code for a Gain block with the gain value 42 will be
for(i = 0; i < 8; i++)
{
Sa1_GainOut[i] = Sa1_GainIn[i] * 42;
}
To improve the generated code, TargetLink tries to combine
consecutive loops.
Example:
The code for two consecutive Gain blocks is combined, i.e.
for(i = 0; i < 8; i++)
{
}
for(j = 0; j < 8; j++)
{
Sa1_Gain2Out[j] = Sa1_GainOut[j] * 3;
}
is combined to
for(i = 0; i < 8; i++)
{
Sa1_Gain2Out[i] = Sa1_GainOut[i] * 3;
}
The signal of a single block can be sliced into more than one
loop depending on
the block's properties (like the gain value for example).
Loops for such slices may also be combined if they have
295 / 1260
different start and end

values but the same iteration range.
Example:
Two consecutive loops with different start and end values but
same iteration
range
for(i = 8; i < 16; i++)
{
Sa1_Gain[i] = Sa1_In[i] * 12;
}
for(j = 0; j < 8; j++)
{
Sa1_Out2[j] = Sa1_Gain[j];
}
are combined to
for(i = 0; i < 8; i++)
{
Sa1_Gain[i + 8] = Sa1_In[i + 8] * 12;
Sa1_Out2[i] = Sa1_Out[i];
}
In a model the problem may come up if signals are sliced and
if
a) a slice that is not the first slice of the signal has the same
iteration
range as the first slice of the following code block and if
b) the iteration range of that slice is greater than or equal to
the
LoopUnrollThreshold and if
c) the index range of the slice is the same as the the index
range of the
variable it is assigned to
Note:
The following examples are based on signal routing blocks,
but the problem is
not specific to that class of blocks, see above.
Example 1 (Selector block):
A Mux block combines two signals of the same size n. The
first signal is the
output of an arbitrary block X and the second is the output of a
Selector block.
The Selector block is driven by block Y with a signal width
greater n and
selects the last n signals.
With width n = 8 these variables are used
Int16 XVar[8];
Int16 YVar[16];
and
SelectorOut[0:7] = YVar[8:15]
Since SelectorOut is removed the mux block combines
MuxOut[0:7] = XVar[0:7]
296 / 1260
MuxOut[8:15] = SelectorOut[0:7] = YVar[8:15]

Parallel to this Mux block another Mux block is placed with
equal input signals.
The resulting signals (pseudo code) are
MuxOut[0:7] = XVar[0:7]
MuxOut[8:15] = YVar[8:15] (condition c) fulfilled since MuxOut
and YVar both
have a range from 8:15)
MuxOut2[0:7] = XVar2[0:7] (condition a) fulfilled since
MuxOut[8:15] and
MuxOut2[0:7] both have a size of 8)
MuxOut2[8:15] = YVar2[8:15]
Now if the loops for MuxOut[0:7] and MuxOut[8:15] cannot be
combined, since
XVar[0:7], for example, resides in an atomic subsystem, but
the loops for MuxOut[8:15] and MuxOut2[0:7] can be
combined, then the code
generation might fail.
Example 2 (Assignment block):
An Assignment block is used to overwrite the first n signals of
a vector.
AssignOut[0:7] = XBlock[0:7]
AssignOut[8:16] = AssignIn[8:16]
A second parallel Assignment block is used in the same way.
The resulting
constellation is
AssignOut[0:7] = XBlock[0:7]
AssignOut[8:16] = AssignIn[8:16]
AssignOut2[0:7] = XBlock2[0:7]
AssignOut2[8:16] = AssignIn2[8:16]
Now, if AssignOut[0:7] and AssignOut[8:16] cannot be
combined, since, for
example XBlock[0:7] resides in an atomic subsystem and if
AssignOut[8:16] and AssignOut2[0:7] can be combined, the
code generation might
abort.
297 / 1260
Workaround: Apart from deactivating the code generator option

"EfficientVectorHandling" or
setting the optimization level to 0, possible workarounds are
the following:
a) avoid subsequent loops (vector signals) of the same size
with different start
indices where the start index of the first vector signal is
greater than the
start index of the second vector signal
-- OR -b) suppress the combination of two vector signals (slices)
where the first
vector signal (slice) has a start index greater than the second
vector signal
(slice)
-- OR -c) make sure that in a group of vector signals (slices) that are
combined the
first vector signal (slice) has the lowest start index in that
group
Workaround for Example 1:
Enable the combination of MuxOut[0:7] and MuxOut[8:15] by
removing XVar from the
atomic subsystem, see Workaround c).
Workaround for Example 2:
Enable the combination of AssignOut[0:7] and
AssignOut[8:16] by removing XVar
from the atomic subsystem, see Workaround c).
patches:
TargetLink 2.3.1p5
ID:
KPR.2010.02.17.002
Title:
Code cannot be compiled or is inefficient after call of 64-bit

shift operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
298 / 1260
Description: To achieve efficient code, TargetLink usually propagates the

value range of a
variable from where it is defined (i.e. where a value is
assigned to the
variable) to the place where this variable is used.
If TargetLink has to implement a 64-bit shift operation this
propagated range
can be larger than necessary. This might lead to inefficient or
even not
compilable code.
A 64-bit shift operation is implemented as a function-like
macro starting with
C__xxxSHL or C__xxxSHR where xxx denotes a type
abbreviation like I64 (signed
64-bit integer) or U32 (unsigned 32-bit integer).
A 64-bit shift operation can be caused by scale adaption of
(especially 32-bit)
operands of arithmetic operations.
Complex Stateflow expressions with scaled operands (LSB !=
1.0 and/or Offset !=
0.0) can also introduce 64-bit arithmetic an therefore 64-bit bit
shift
operations.
Inefficient code can be code that implements superfluous
- control flow
- saturation
- 64-bit operations
Code might not be compilable, if a relational operation in
Stateflow contains a
complex expression and at least one scaled (LSB != 1.0
and/or Offset != 0.0)
operand.
Example (Relational Block):
Input1: Int32; LSB = 2^-21; Offset = 0.0
Input2: UInt16; LSB = 0.0025; Offset = -70
this introduces a relational operation where the second
operand has to be
adapted to the scaling of the first operand
Aux = (Input2 << 17 / 25 - 146800640) /* 2^17 / 25 == 0.0025 /
2^-21 */
Input1 > Aux
To implement this scale adaption TargetLink generates a shift
left operation.
For this example a macro implementing a 64-bit relational
operation with an
insufficient argument list will be generated.
The generated code will contain C__GT64(Input1, Aux) but
the C__GT64() macro
needs 4 arguments, i.e. two 64-bit operands.
A typical error message during compilation may be:
TLSim\pr_model\HostPC_MSVC\Subsystem.c(138) : warning
C4003: not enough actual
parameters for macro 'C__GT64'
TLSim\pr_model\HostPC_MSVC\Subsystem.c(138) : error
C2059: syntax error : ')'
299 / 1260
Workaround: Avoid 64-bit operations by choosing appropriate scalings and

data types.
Introduce auxiliary variables to specify type and scaling of
subexpressions in
Stateflow.
ID:
KPR.2010.02.17.003
Title:
Autoscaling based on simulated ranges does not work for a

Stateflow chart

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Autoscaling tool does not scale Stateflow outputs or variables

based on
simulated ranges, although simulated ranges were available
for these objects.
Using autoscaling with or without netlist take no effect either.
Workaround: Scale the affected variable manually.
300 / 1260
ID:
KPR.2010.02.17.004
Title:
Code generation aborts during code generation for system

containing nested bus defined by means of a bus object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The production code generation for a system with a nested

bus whos leafs signals
have identical names, for example
MyBus
|
+--SubBus1
| +-- a
| +-- b
| +-- c
+--SubBus2
+-- a
+-- c
and that is defined by means of the bus object may be abort
with the following
error message:
E90105 INTERNAL ERROR
Internal error. Contact dSPACE technical support. The eval
command in
tl_get_compiled data failed. See message below In an
assignment A(I)
= B, the number of elements in B and I must be the same.
Workaround: Do not use bus objects, if possible.
patches:
TargetLink 3.1p2
301 / 1260
ID:
KPR.2010.02.17.005
Title:
A C code comment in requirement information results in not

compilable code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a requirement information is included as comment in the

generated code and
the requirement information contains a C code comment, e.g.
"/* This is my
comment */", the generated code is not compilable.
The requirement information included in the generated code
consist of the
information about the element in the model where a
requirement information has
been set, the requirement description, the name of the
document that contains
the requirement, the location of the requirement in that
document and a user
tag. If one of these parts of the requirement information
contains a C code
comment the resulting code is not compilable.
In particular a requirement set at a Stateflow transition can
lead to this
problem, because the label of the transition is a component of
the information
about the element the requirement information has been set
at. If the transition
contains a C code comment the resulting code is not
compilable.
Workaround: Do not use a C code comment in a requirement information.
patches:
TargetLink 3.1p2
302 / 1260
ID:
KPR.2010.02.17.006
Title:
Code generation abouts if the Simulink Verification and

Validation toolbox is installed, but no license available

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the code generator option

"RequirementInfoAsCodeComment" is enabled (default
setting) and the Simulink Verification and Validation software
from The
MathWorks is installed, but no license for this software is
available, then code
generation aborts with a fatal error. Which fatal error is thrown
depends on the
MATLAB version:
- With a MATLAB version prior to R2009a code generation
aborts with a fatal
error:
"Fatal #10551: Internal error: Inconsistent TargetLink
installation"
- With a MATLAB version R2009a or newer code generation
aborts with a fatal
error:
"Fatal #99999: Please contact dSPACE support"
Workaround: If no requirement information is desired in the generated code
disable the code
generator option "RequirementInfoAsCodeComment".
If requirement information is desired in the generated code,
first checkout a
license for the Simulink Verification and Validation software.
Execute the
following command on the MATLAB command window to
checkout the license:
>> bLicenseAvail = license('checkout',
'SL_Verification_Validation')
Generate code if the checkout of the license was successful.
patches:
TargetLink 3.1p3
303 / 1260
ID:
KPR.2010.02.17.007
Title:
Restart function call and include statement result from

systems called within preprocessor control flow may not be
encapsulated within preprocessor control flow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a subsystem is called within preprocessor control flow and

the subsystem is
either a subsystem for which code is generated incrementally
or which step
function has a function class with "Storage" = "extern"
specified, and
furthermore the function class of the step function has also the
"Alias" = "on"
- the call of the restart function generated for the subsystem is
not enclosed
within preprocessor control flow.
- the include of the header file generated for the subsystem is
not enclosed
within preprocessor control flow.
304 / 1260
ID:
KPR.2010.02.17.008
Title:
Systems called via preprocessor control flow may lead to

invalid order of include statements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink generates an invalid order of include statements if

the following
conditions are fulfilled:
- A subsystem is called via preprocessor control flow
-- AND -- a part of the preprocessor control flow calling the subsystem
is a macro M
which has module specified, let say "A"
-- AND -- the subsystem is either a subsystem configured for
incremental code generation
or which step function has a function class with the Storage =
"extern"
specified
-- AND -- for the subsystem a module name is specified, let say "B"
-- AND -- the name of the module specified for the subsystem, here
"B", is
alphanumerical greater than the name of the module specified
for the macro, here
"A"
This results in the following code (example):
#if M
#include "B.h"
#endif
#include "A.h"
The code is wrong, because the macro M is used before it is
defined in the
module "A".
Workaround: For the module of the macro specify a name which is
alphanumerical greater than
the name of the module of the subsystem.
-- OR -Specify another module name for the system where an
include has to be created.
This can be done via a DataDictionary ModuleTemplates
object in TargetLink 2.x
and TargetLink 3.0.x. In TargetLink 3.1 this can be done via a
DataDictionary
Module object.
305 / 1260
ID:
KPR.2010.02.17.009
Title:
Invalid encapsulation of an include statement by preprocessor

control flow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink generates an invalid encapsulation of an include

statement by
preprocessor control flow if the following conditions are
fulfilled:
- A subsystem is called via preprocessor control flow P
-- AND -- the subsystem is either a subsystem specified for
or which step function has a function class with Storage =
"extern" specified
-- AND -- for the subsystem a module name is specified, let say "Y"
-- AND -- a macro M has been specified which is used outside any
preprocessor control
flow P
-- AND -- for the macro M also the module "Y" is specified
This results in the following code (example):
#if P
#include Y.h
#endif
The code is wrong. The use of the macro M is not
encapsulated via preprocessor
control flow P but it is specified in the module "Y". Therefore
the include of
the module "Y" must not be encapsulated either.
Workaround: Specify modules exclusively for incremental / extern
subsystem called within
preprocessor control flow.
306 / 1260
ID:
KPR.2010.02.17.010
Title:
Invalid encapsulation of the include statement of TargetLink's

root function header file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a subsystem is called within preprocessor control flow and

the subsystem is
either a subsystem which is specified for incremental code
generation or which
step function has a function class with storage = "extern" and
no module is
specified for the subsystem, then in the generated code the
include statement of
the header file of TargetLink's root subsystem is enclosed by
the preprocessor
control flow. This is wrong.
Workaround: Specify a module for the subsystem configured for
incremental code generation or
storage = "extern" if it is called within preprocessor control
flow.
patches:
TargetLink 3.1p2
ID:
KPR.2010.02.17.011
Title:
Faulty export of subpackages and AUTOSAR elements in the

same root package

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR export creates an invalid AUTOSAR file if the

ExportStrategy option
is "OneFileForAllPackages" and subpackages and AUTOSAR
elements will be exported
to the same AR-package. The AUTOSAR schema specifies
that in sequence at first
the AUTOSAR elements and then the subpackages will be
defined. The AUTOSAR
export creates the XML nodes in wrong order, so that the
validation against the
AUTOSAR schema fails.
Workaround: Set the ExportStrategy option to "OneFilePerPackage" in this
case.
patches:
TargetLink 3.1p2
307 / 1260
ID:
KPR.2010.02.18.001
Title:
Variables with different data types are merged though one has
constraints and the other not

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In a model a fixed variable name is specified for different block

variables. The
block variables have the same variable class (with
Optimization property =
MERGEABLE) and identical properties except for the data
types. The block
variables reference different types with identical propertys
except that one
data type has a constraint (min and/or max) set and the other
data type not.
In this case, code generation shall stop with an error
complaining about merging
variables with different types. But in fact code generation
succeeds with
warning #17400 complaining about merging variables with
different upper/lower
limit values.
Workaround: Reference the same data type for variables to be merged. Or
specify identical
constraints (min/max values). Or specify the same constraints
in the block
dialog where no constraints are give through the data type.
308 / 1260
ID:
KPR.2010.02.18.002
Title:
Using $I in property NameTemplate of module with

CodeGenerationBasis = DDBased leads to incorrect code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a module with CodeGenerationBasis = DDBased contains

the name macro $I in its
NameTemplate, the $I evaluates to the identifier of the
associated DD Code
Generation Unit (CGU) when generating code for the CGU
and evaluates to the
identifier of the TL subsystem, when generating code for TL
subsystems, that
needs objects from the module. Thus the module exists as
production code file
and as stub code file, but with different names. This can lead
to linker errors
such as "one or more multiply defined symbols found".
Workaround: Use fixed names for the NamteTemplate of a module with
CodeGenerationBasis =
DDBased
patches:
TargetLink 3.1p2
309 / 1260
ID:
KPR.2010.02.18.003
Title:
Wrong treatment of block tag during model upgrade

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During model upgrade a dialog box appears and suggest a

restore of saved
TargetLink block data:
Restore data?
The block seems to have saved TargetLink2.x block data. Do
you wish to have it
restored?
Restore | Do not restore | Do not restore, clear saved data
This procedure is intended for a model preparation and is
erroneously invoked
during model upgrade if blocks possess a tag string that
produces a structure
when evaluated by the MATLAB interpreter.
Workaround: Select "Do not restore" to preserve the tag.
patches:
TargetLink 3.1p2
310 / 1260
ID:
KPR.2010.02.18.004
Title:
Min/max values of an AUTOSAR data element are not taken

into account

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An AUTOSAR data element is specified in the Data

Dictionary. A min and/or max
value is specified for the data element. It is referenced in an
inport of a
subsystem. Either the subsystem itself, or one of its parent
subsystems is
specified as an AUTOSAR runnable. The inport's successor
block is a Saturation
block. The limits are the same as the min/max values of the
data element.
In this case, the generated code contains unnecessary
saturation code for the
Saturation block. Furthermore the min/max values in the
comment at the
definition of the RTE API macro's actual parameter are not the
values specified
Workaround: Place a Rescaler block on the signal line between the inport
and the Saturation
block. Specify the data element's limits at the Rescaler block's
limits.
patches:
TargetLink 3.1p1
311 / 1260
ID:
KPR.2010.02.18.005
Title:
The PreLook-Up Index Search block calculates wrong fraction

values if the input signal is out of breakpoint data range

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The PreLook-Up Index Search block (TL_IndexSearch) may

calculate wrong fraction
values if the input value is either smaller than the first or
greater than the
last break point data value.
The problem is based on a read access to an unitialized
memory segment during
fraction calculation, therefore this problem is non
deterministic: Depending on
the value in the uninitialized memory segment it is possible,
that the
calculated fraction is correct. Only the fraction is affected, the
index
calculation is correct.
Workaround: A solution for this problem is to saturate the input signal to the
minimum and
the maximum of the breakpoint data values
ID:
KPR.2010.02.18.006
Title:
Opening dSPACE TargetLink Online Help freezes MATLAB
Last Update: 30 Jun 2010

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Occasionally, MATLAB freezes when TargetLink's Online Help is opened,

for
example, when the Help button in a TargetLink dialog is clicked. In this
case,
MATLAB can only be closed with the Windows Task Manager, and unsaved
data are
lost.
Workaround: Set the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\dSPACE\HelpDesk\SplashDuration
to 0. If the key does not exist, create one (data type: DWORD) and set it to
0.
312 / 1260
ID:
KPR.2010.02.26.001
Title:
Simulation frame generation aborts for multirate model due to

erroneous signal matching in Data Dictionary

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In a multirate model, when a bus signal enters a Task

subsystem inside the
TargetLink subsystem and not all of the signals inside the bus
are used inside
the Task, then the matching of the Task port signals to the
port signals on root
level ("output" to "SourceSignal") inside the Data Dictionary
subsystem area may
be erroneous, leading to an error in the Simulation Frame
generation:
*** Internal Error:
*** Number of source signals does not match the number of
output
signals.
Workaround: Create an atomic subsystem (with Function block) on root
level as a frame for
all other subsystems.
patches:
TargetLink 3.1p2
ID:
KPR.2010.02.26.002
Title:
Order of arguments in operation call may be wrong

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The order of arguments in the generated code of an operation

call may be wrong
if the order of OperationArguments objects in current Data
Dictionary is
different to the default order of arguments in a generated
function (first all
inputs and then all outputs).
Workaround: Due to the fact that it is not possible to change the order of
arguments in the
code, sort the OperationArguments objects in current Data
Dictionary, first the
inputs and then the outputs, according to the generated code.
313 / 1260
ID:
KPR.2010.03.15.001
Title:
Wrong scaling object created in Data Dictionary's Subsystems

area for custom lookup table script variable with local scaling

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a Data Dictionary variable using a non-default LocalScaling

is referenced
inside a custom lookup table script, then the Code Generator
may produce a wrong
global representation of this scaling inside the Data
Dictionary's Subsystems
area. This may lead to wrong simulation results or wrong postprocessing of the
Data Dictionary.
Workaround: Create and reference a global Scaling object for a custom
lookup table script
variable
patches:
TargetLink 3.1p2
ID:
KPR.2010.03.16.001
Title:
Simulation frame generation aborts for multirate code

generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For multirate models which include bus ports using OSEK
messages, the simulation
frame generation may fail with the following error:
*** Internal Error:
*** Source signal cannot be found
Workaround: Avoid using OSEK messages on buses, switch to
GLOBAL_BUFFER instead.
patches:
TargetLink 3.1p2
314 / 1260
ID:
KPR.2010.03.22.001
Title:
Stateflow optimization does not consider call-by-reference

output parameter of user written function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The optimization of code generated from a Stateflow chart

does not consider
(possible) value change of an actual argument within a call to
user written
function with call-by-reference formal parameter. This may
result in wrong value
propagation and therefore in wrong variable replacement by
constants and/or
wrong elemination of code branches.
Workaround: Use for actual argument of such call a variable class where
the ERASABLE flag is
not set.
If this does not solve the problem activate the volatile flag of
the variable
class,or model the actual argument as Stateflow data objects
on machine level.
ID:
KPR.2010.03.22.002
Title:
MATLAB aborts during code generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Due to internal optimizations and analysis in connection with

function inlining
code generation may run into an endless recursion which
results in a abort of
MATLAB. If code generation with inlining threshold > 0 causes
MATLAB to abort
whereas code generation with inlining threshold = 0
succeeded then the problem
described above can be the reason for the crash.
Workaround: Set option inlining threshold to 0 (null).
patches:
TargetLink 3.1p7
315 / 1260
ID:
KPR.2010.03.22.003
Title:
Stateflow option user transition execution order is not taken

into account for default transitions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Since MATLAB R14SP2 it is possible to use an user specified

order for
transitions. This order is not taken into account for default
transitions.
Instead the sematic order is used.
Workaround: Deactivate the user transition order or connect all default
transitions to a
junction and add a new single default transition to that
junction. The user
specified order given to the transitions that are now leaving
the junctions is
taken into account by the TargetLink Code Generator.
ID:
KPR.2010.03.25.001
Title:
Code generation may abort wrongly with error 32105

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may abort wronlgy with error 32105, if

hold:
- a variable is specified in the Data Dictionary
-- AND -- the variable or its variable class references a Module object
with property
CodeGenerationBasis = DDBased
-- AND -- the variable is referenced more than once in the model
patches:
TargetLink 3.1p2
316 / 1260
ID:
KPR.2010.03.25.002
Title:
Infinite loop in code generation caused by graphical function

with subfunctions which contain boxes and/or notes

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow chart contains a graphical function with at least

three
subfunctions and if these subfunctions contain boxes and/or
notes (not necessary
all of them) than code generation may run into an infinite loop.
Workaround: Don't model graphical subfunctions with boxes or notes.
Instead of notes C or
C++ like comments can be used before the first transition
statement.
patches:
TargetLink 3.1p2
317 / 1260
ID:
KPR.2010.03.26.001
Title:
Faulty import of property NameTemplate for

ModeSwitchFunction objects

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: For an init or terminate runnable the the C function name is

always InitFunction
or TerminateFunction, but not equal to the specified symbol
name of the
runnable.
The AUTOSAR import writes the value $D to the property
NameTemplate for an init
or terminate runnable, which short name is equal to the
symbol value of the
runnable. The content $D equates the name of the Data
Dictionary object, that
will be used to generate a runnable and that represends an
init oder terminate
function. The object name of a ModeSwitchFunction object is
fixed. Allowed
values are InitFunction and TerminateFunction. As a result the
specified short
name of the original runnable will not be used during code
generation.
Workaround: As a workaround use different short name and symbol values.
So the property
NameTemplate contains the specified symbol value and the
code generator creates
the correct function name.
patches:
TargetLink 2.3.1p5
318 / 1260
ID:
KPR.2010.03.31.001
Title:
Incorrect code for Saturation block if limit value cannot be

represented by output scaling and is close to the implemented
limit

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a TargetLink Saturation block

- has a limit with a default variable class
-- AND -- the limit cannot exactly be represented in block's output
scaling
-- AND -- the limit lies within a range of the implemented output limit
and one LSB
below max limit or one LSB above min limit
then the generated code might be wrong.
Note:
The implemented limits can be found on the Saturation block's
output pane.
Such a situation can be detected, if for a Saturation block a
macro call like
C__xxxFITyyy_SAT(in, value) is generated and "value" is not
the max value of the
type denoted by "xxx".
Example:
C__I8FITI16_SAT(in, 126) indicates this problem since
max(I8) = max(Int8) = 127
!= value (126)
Workaround: Specify limits that can be represented in the type and scaling
of the Saturation
block's output.
ID:
KPR.2010.03.31.002
Title:
Block annotation will be deleted if block properties

"output.show" and "output.inheritscaling" are enabled

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Block annotation of a block, that supports inherit properties,

will be deleted
if
- output.show property for this block is enabled
-- AND -- output.inheritscaling option is enabled
319 / 1260
ID:
KPR.2010.03.31.003
Title:
Code generation aborts with fatal error #10008 for variable

vector width in reused function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation may abort issuing a fatal error #10008 if
a variable with
variable vector width is specified in a reused subsystem and if
the main reuse
structure for that subsystem contains a pointer to at least one
sub-structure.
Reuse sub-structures are introduced depending on the
memory sections and the
initialization behaviour of the instance specific variables for the
reused
subsystem.
Example:
This problem may come up, if a reused subsystem contains a
global Outport and
local static UnitDelay states that all have a variable vector
width.
Workaround: Try to specify variables in the same memory section or make
them function
parameters of the reuse function.
Changing the variable class of the Outport to FCN_REF_ARG
solves the problem for
the example given above.
320 / 1260
ID:
KPR.2010.03.31.004
Title:
Incorrect code for saturated fixed-point min/max function in

Stateflow with operation as argument

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Incorrect code may be generated if following conditions for a

Stateflow min/max
function hold:
- at least one operand of the expression of the min/max
function call is scaled
(LSB != 1.0 and/or Offset != 0.0)
-- AND -- both arguments of the min/max function call are operations
-- AND -- both min/max arguments have the same scaling (These
scalings are determined
internally by TargetLink from operand's scalings)
-- AND -- the result of the min/max operation is supposed to be
saturated.
Example:
Int16 In1; // 2^-2
Int16 In2; // 2^-4
Int16 In3; // 2^-2
Int16 In4; // 2^-4
Int16 Out; // 2^-6
Out = max(In1 + In2, In3 + In4);
the resulting code may be
if(...)
Aux_ = ((Int32) (((Int32) In1) << 2)) + ((Int32) In2);
Out = C__I16FITI32_SAT(Aux_, 32767 /* 511.984375 */);
else
...
but the code should be
if(...)
Aux_ = ((Int32) (((Int32) In1) << 2)) + ((Int32) In2) << 2;
Out = C__I16FITI32_SAT(Aux_, 32767 /* 511.984375 */);
else
...
Workaround: Introduce auxiliary variables for the operations that are given
as arguments to
the min/max function.
321 / 1260
ID:
KPR.2010.03.31.005
Title:
Code generation aborts for AUTOSAR element if data type of

data element is non scalar

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink does not support the specification of non scalar

data types in the
DataDictionary.
If a data type in the Data Dictionary is specified to be non
scalar by setting
the width property, TargetLink should issue an error message
about this.
In some cases, however, the code generation might abort
issuing an error like
the following
Fault address: xxxxxxxx xx:xxxxxxxx
xxx\MATLAB\tl\Bin\XcgCV.dll
This especially happens if the code generation is in
AUTOSAR mode.
Workaround: See user documentation to define an array type (TargetLink
AUTOSAR Modeling
Guide > Modeling According to AUTOSAR > Defining Types >
How to Define Array
Types)
ID:
KPR.2010.03.31.006
Title:
Code generation aborts for Switch Case blocks driven by

variables with Scope "ref_param"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A model contains a Switch Case block with more than one
outport, or one outport,
but with several case constants. The Switch Case block is
driven by a block
whose output variable has a variable class with Scope =
"ref_param".
In this case, code generation aborts with fatal error #99999.
Workaround: Place a block on the signal line right before the Switch Case
block, e.g. a
Rescaler block, or a TargetLink Inport.
ID:
KPR.2010.03.31.007
322 / 1260
Title:
Missing #include statement for base types of typedefs

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When a type (other than builtin C types like int, char etc.) is
used at some
point in a generated code file, TargetLink ensures that at that
point a type
definition (typedef or struct declaration) is visible, either
directly in the
same file or at least through an #include of the file that
contains the
definition.
This mechanism does not work for types occurring as the
base type of simple
typedefs. For example
typedef Float64 MyFloat;
does not lead to an #include of the file tl_basetypes.h, which
contains the
definition of Float64.
As a result, compiler errors may occur while building the
application.
Additional notes:
1. Structure components are not affected by this bug, i.e.
struct MyStruct {
Float64 f;
};
will cause an include of tl_basetypes.h, regardless of whether
the structure is
defined with or without typedef
2. Pointer typedefs are not affected by this bug, i.e.
typedef Float64* Float64Ptr;
will cause an include of tl_basetypes.h
3. The problem does not affect Data Dictionary Typedefs with
a set Module
property (ModuleRef in TargetLink 3.1)
4. The problem does not exist for Data Dictionary Typedefs
without a set
ModuleRef property in TargetLink 3.1 and above if the code
generator option
"StrictTypedefPlacement" is left at its default value ("'on"'),
because typedefs
for user defined types are created in the UserDefinedTypes
header, which always
includes tl_basetypes.h.
323 / 1260
Workaround: Assign the typedef to a module by setting the

Module/ModuleRef property
-- OR -use renamed base types instead of typedefs
-- OR -cause an #include by some other means (e.g. a variable
declaration).
ID:
KPR.2010.04.19.001
Title:
Erroneous scope reduction for vector redefined in loop

depending on iteration variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink may erroneously reduce a persistent vector

variable to local scope
(without static) when the variable is first written and then read
in the same
loop, and the write access depends on the loop variable, but
the read access
dependents on an another loop variable, takes place
elementwise or the variable
is used as a parameter in a function call.
Example:
static a[10];
for (i =?) {
/* write access */
a[i] = ...
/* 3 possible read accesses */
for(j=?) {b = a[j] }
/* OR */
b = a[<const value>]
/* OR */
b = foo(a)
}
The variable "a" may be reduced to local scope without
persistence.
Workaround: Choose a variable class where Optimzation property is not set
to
"SCOPE_REDUCIBLE".
patches:
TargetLink 3.1p3
324 / 1260
ID:
KPR.2010.04.19.002
Title:
In Data Dictionary Manager the Object Dialog does not accept

formal names of syntax FormalName:ActualName

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The Data Dictionary Manager provides an Object Dialog for a

variable object, e.g
double-click on the Variable object or use Edit from context
menu. If the entry
"Name" has a value in syntax FormalName:ActualName the
dialog validation reports
following error in status line:
"The current Name Template property is incompliant."
This message however is incorrect, because TargetLink
allows a name
specification in this syntax.
Workaround: Enter the name directly in Property Value List of Data
Dictionary Manager.
ID:
KPR.2010.04.19.003
Title:
No logging in Sink block with data type "Bitfield" in SIL/PIL

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Logging in SIL/PIL simulation mode doesn't work for a Sink

block within a
TargetLink subsystem if it has a direct predecessor block with
the data type
"Bitfield" respectively a data type with base type "Bitfield".
Workaround: Place a TargetLink Gain block with gain factor 1 and data type
UInt8 before the
Sink block.
325 / 1260
ID:
KPR.2010.04.19.004
Title:
MIL simulation with Custom Code block may yield to wrong

results because the block may use outdated scaling
information for parameter

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: MIL simulation with Custom Code blocks produces wrong

results in the follwoing
use case:
- a Custom Code block parameter data type is set to an
integer type, its LSB
value != 2^0 and/or its offset value != 0.0,
- the "Use production code for floating point simulation" option
is "on"
(property prodcode),
- this setting is saved to the block,
- then, the parameter data type is set to Float32 or Float64,
- a new Custom Code S-function is generated with this setting.
Custom Code block data management preserves scaling
LSBs and offsets when the
associated data type is set to a floating-point type. The saved
LSBs and offsets
have no impact on production code generation but are kept
only to be eventually
reused when the data type is switched back to integer. They
are, however,
falsely considered for Custom Code S-functions.
Custom code block inputs, outputs, states and work variables
are not affected by
this bug.
Workaround: Before assigning a floating-point data type to a Custom Code
block parameter,
make sure that the LSB is set to 2^0 and the offset to 0.0.
326 / 1260
ID:
KPR.2010.04.19.005
Title:
AUTOSAR Software Component Model Generator aborts for

getter/setter operations that cannot be called via TargetLink
Port blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the Software Component Model Generator

(tl_generate_swc_model) is not
explicitly instructed via the
ForceOperationCallSubsystemUsage option to model
all client/server operation by means of the operation call
subsystem, then it
tries to use TargetLink Port or BusPort blocks for getter and
setter operations.
But in cases where this is not possible, e.g. because the
getter/setter
operations to be modeled contain arguments of structure data
type or application
error, the software component model generator aborts with an
error message like:
??? Error using ==>
tl_generate_swc_model>FcnConnectPorts at 2073
Invalid Simulink object name: .
Error in ==>
tl_generate_swc_model>FcnAddContentToTlSubsystem at
727
runOutputConnectionList = FcnConnectPorts(hSubsystem,
runOutputConnectionList, senderConnectionList, 3,
autorounting); %#ok
Error in ==> tl_generate_swc_model at 525
FcnAddContentToTlSubsystem(hTlSubsystem,
options.swcObjectList,
options.simulinkAutorouting, ...
Workaround: Run the SWC model generator with the option
'ForceOperationCallSubsystemUsage'
set to 'on' or with the option 'ModelClientServerPorts' set to
'off'.
patches:
TargetLink 3.1p6
327 / 1260
ID:
KPR.2010.04.21.001
Title:
Missing synchronization of variable components after

AUTOSAR import

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the user tries to generate code after an AUTOSAR import

into the Data
Dictionary an error message like the following may occur:
Error #32044: / ... /ABC/XYZ_9pyf0dmf5pv4e6ffqc40ihti5:
Initial value-specifying variable does not match the variable to
be initialized.
The Code Generator throws an error message, when the
names of the component
variables of a complex Data Dictionary variable object don't
correspond to the
names of the referenced TypdefComponent objects.
Workaround: Open the complex variable object with the Variable dialog. By
selecting the OK
button the names of the component objects will be
automatically corrected.
patches:
TargetLink 3.1p3
328 / 1260
ID:
KPR.2010.04.21.003
Title:
Problem with module object information during roundtrip with

AUTOSAR description files

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR export writes the module object name to the
AdminData group of the
software component or runnable element. The Data Dictionary
NameTemplate
property of the module object will not be written to the
AUTOSAR file. During
the re-import of the AUTOSAR XML file, the NameTemplate
property of the module
object in Pool area will be overwritten with the module name.
For example, the
user has used a name macro in the property like "TlSwc_$D",
it will be
overwritten by TlSwc_Test.
Workaround: The property NameTemplate of a Module object that is
referenced from a software
component or a runnable object shall have the same name as
the Module object
itself. Additionally the module object shall be placed directly
under the
/Pool/Modules node in a Data Dictionary.
patches:
TargetLink 3.1p3
329 / 1260
ID:
KPR.2010.04.21.004
Title:
Incorrect calculation if non integer constant value is used in

integer min/max operation of TOM TriCore

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Incorrect code for a Min/Max block in Stateflow or a min/max

function call in
Stateflow may be generated, if following conditions hold:
- the code generation target is a TriCore TOM
-- AND -- the option "Assembler and C extension" is selected
-- AND -- at least one operand is a non integer constant value (e.g.
from a Constant
block with default variable class)
-- AND -- the other operand or the result of the min/max operation is
not floating-point
Workaround: Replace the constant value by a variable. If the constant value
originates from
a Constant block, specify a non default variable class.
ID:
KPR.2010.04.21.005
Title:
Increased file size of simulation data MAT-file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Compared to TargetLink 2.x, a simulation data MAT-file saved

with TargetLink 3.x
contains redundant data structures (e.g. geninfo, int_plotdata)
which leads to
unnecessary increased file size.
patches:
TargetLink 3.1p3
330 / 1260
ID:
KPR.2010.04.21.007
Title:
Unspecific error message #17066 for cyclic includes in context

with reused systems

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a reused subsystem has no exclusive code file specified

sometimes cyclic
includes occur which results in an unspecific error message
#17066 during code
generation. There are two ways on which a reused system
can get a non-exclusive
code:- No code file specified:
If a reused system has no code file specified the code
generator inherits the
code file specification from the parent of the reused system.
Note: In case of
several instances of the reused system the code generator
inherits the code file
specification from the parent of the first instance he finds.
- Code file specified:
A reused system has specified a code file which is also used
by other
subsystems.
Workaround: For a reused system specify a code file which is exclusively
used by this reused
system.
ID:
KPR.2010.04.21.008
Title:
Code generation aborts with error #17154, if user-supplied

files with the same base name are added via Addfile block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation terminates with error #17154, if usersupplied files with the
same base name are added via Addfile block, one by linking
and the other by
including, and the included file has not the default extension
"h"
If two user-supplied files with the same base name (name
without extension) are
added via Addfile block, one by linking and the other by
including, and the
included file has not the default extension "h", the code
generation aborts with
the error #17154, e.g.
Error #17154: Subsystem/Addfile1
331 / 1260
An existing file with the base name 'myFile' but with different
properties has
been found.
The following properties are different:
- Extension: 'he' vs. 'h'
Information on the existing file:
Subsystem/Addfile
if the following conditions are fulfilled:
a) - the Addfile blocks are located in the same subsystem and
- the name of the Addfile block linking the file is
alphanumerical lesser
than the name of the Addfile block including the file
or
b) - if the Addfile block linking the file is placed in the same
subsystem
hierarchy, but above the subsystem with the Addfile block
including the file
or
c) - if the Addfile blocks are placed in parallel subsystem
hierarchies and name
of root subsystem of the subsystem hierarchy containing the
Addfile block
linking the file is alphanumerical lesser than the root
subsystem of the
subsystem hierarchy containing the Addfile block including the
file
Example for c)
---------------------------------------------------------------------------||
||
| ------------------------------- ------------------------------------- |
||||||
| | ------------------------- | | ------------------------------- | |
| | | Addfile block | | | | | | |
| | | (linking file x.c | | | | | | |
| | ------------------------- | | | ----------------------- | | | |
| | | | | | Addfile block | | | |
| | | | | | (including file x.hpp)| | | |
| ------------------------------- | | ------------------------- | | |
| Subsystem B | | | | |
||||||
| | ------------------------------- | |
| | Subsystem C | |
||||
| ------------------------------------- |
| Subsystem D |
||
||
---------------------------------------------------------------------------Subsystem A
In the example Subsystem B and Subsystem C are the root
subsystems of the
relevant subsystem hierarchies. Because the name
"Subsystem B" is alphanumerical
lesser than "Subsystem C" and the Subsystem hierarchy of B
contains the Addfile
block linking the file, the code generation aborts with the error
332 / 1260
#17154.
The case a) is the most common case, the cases b) and c)
are of a more
theoretical nature and should not be relevant for the praxis.
Workaround: Change the name of the Addfile blocks in a way, that the
name of the Addfile
block linking the file is alphanumerical greater than the name
of the Addfile
block including the file. This workaround works only for the
most common case
a). For the cases b) and c) there exists no workaround in
TargetLink versions
prior 3.1.
With TargetLink 3.1 and newer you can use the Data
Dictionary Module objects to
avoid the problem:
Specify a Module object with two FileSpecfications objects,
one for file to be
linked, one for the file to be included in the Data Dictionary,
and select the
FileSpecfication objects in the Addfile blocks.
ID:
KPR.2010.04.21.009
Title:
Code generation aborts for subsystem referencing an AUTOSAR

calibratable parameter that can be optimized

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the code generator is called for subsystem that contains a block
referencing
an AUTOSAR calibratable parameter that can be optimized, for
example a Constant
block connected to the Terminator block,
the production code generation aborts with the following error:
*** E02012: ERROR IN HOOK FUNCTION:
*** There is a syntax error in the user-defined hook function
***
***
C:\dSPACE\matlab\tl\config\autosar\autosar_post_codegen_hook.m
***
*** MATLAB interpreter error message was:
*** .....................................
*** Error using ==> dsdd
*** Invalid value for attribute "name"!
Workaround: Delete the block from the subsystem. It does not affect the
generated production
code, because the corresponding variable is optimized.
333 / 1260
ID:
KPR.2010.04.21.010
Title:
The HTML code browser may fail to find correct variable

usages due to missing BlockVariable reference in Data
Dictionary for multiply used block parameter variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a merged variable is used for more than one block

parameter of the same
block, then only one BlockVariableRef entry is generated for
this variable
inside the Data Dictionary ModelView area. As a
consequence, the browsable HTML
code has missing links to the other variable uses for this
block.
patches:
TargetLink 3.1p3
ID:
KPR.2010.04.22.001
Title:
Incorrect generated documentation due to BlockVariable

reference for Stateflow blocks containing equally named (but
different) Stateflow block variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If in a Stateflow chart, two different struct components are

used that have got
the same name, then only one single BlockVariable entry is
created inside the
Data Dictionary ModelView area. In the "StatflowNodes"
hierarchy of the Chart
block, two entries are (correctly) generated, each referencing
the same
BlockVariable, which is wrong. This leads to an incorrect
generated
documentation.
patches:
TargetLink 3.1p3
334 / 1260
ID:
KPR.2010.04.27.001
Title:
Configuration parameter "Bus signal treated as vector" is set

to "none" during preparation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A pre-condition for performing a TargetLink MIL simulation is,

that the
configuration parameter (model property) "Mux blocks used to
create bus signals"
(Configuration Parameters > Diagnostics > Connectivity) is set
to "error".
The parameter "Bus signal treated as vector" (Configuration
Parameters >
Diagnostics > Connectivity) may have any value ("none",
"warning" or "error").
Nevertheless, the model preparation resets the parameter
"Bus signal treated as
vector" value always to the value "none", even if it is already
set to one of
the valid values "warning" or "error".
Workaround: After the model has been prepared, the parameter has to be
set to the desired
value again.
Alternatively this can be done via API commands, e.g. on
MATLAB command window:
To set "Bus signal treated as vector" to "none", perform
>> set_param(<model>, 'StrictBusMsg', 'ErrorLevel1');
To set "Bus signal treated as vector" to "warning", perform
>> set_param(<model>, 'StrictBusMsg',
'WarnOnBusTreatedAsVector');
To set "Bus signal treated as vector" to "error", perform
>> set_param(<model>, 'StrictBusMsg',
'ErrorOnBusTreatedAsVector');
335 / 1260
ID:
KPR.2010.05.03.001
Title:
Simulink window disappears when TargetLink simulation

frame is inserted, or removed

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Use case:

- Simulink's global WindowReuse option is set to "reuse"
-- OR -- Simulink model is opened in Model Browser mode
-- AND -- Subsystem is open in Simulink model window (which in this
case is the only
window for this model)
When this use case applies and TargetLink's simulation frame
is created or
removed for said subsystem, the Simulink model window
disappears. The model is
still open, but invisible.
TargetLink's simulation frame is inserted during System
Preparation, and removed
when a system is cleared from TargetLink. Additionally, it can
be removed and
re-inserted with TargetLink's Main Dialog. The frame enables
to switch between
MIL/SIL/PIL simulation modes.
Workaround: 1. Reopen the model manually after the subsystem has been
processed.
2. Make sure the subsystem that is processed is not the
subsystem that is
currently displayed in the model window when the tool (for
example, System
Preparation) is started.
3. Set Simulink's global WindowReuse option to "none".
Simulink options can be
edited with the Simulink Preferences dialog.
ID:
KPR.2010.05.03.002
Title:
Property Manager always opens model root

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When the Property Manager is called up to open a model, it

always opens the
model's root, even if model window(s) are already open.
336 / 1260
ID:
KPR.2010.05.04.001
Title:
Simulation frame generation fails in AUTOSAR mode due to

missing SourceSignal entry for unused bus signal in Data
Dictionary's ModelView

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a bus is entering the TargetLink subsystem via a Simulink

port, is passed
into another subsystem again via an Simulink port, and is then
partly consumed
by a Runnable system, then the Data Dictionary Output does
not create
SourceSignal entries for the not consumed signals at the
Simulink port driving
the Runnable system. This leads to an arror in during frame
generation:
E00000: ERROR USING I_GETSOURCESIGNAL
...
Workaround: - Do not pass unused signals though the TargetLink
subsystem border
-- OR -- Place an enhanced (specifying) busport on root level
patches:
TargetLink 3.1p3
337 / 1260
ID:
KPR.2010.05.05.001
Title:
Different results from tl_get_blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The search criteria for tl_get_blocks can be (among others) a

single block name
or a list of block names. The following commands should
return identical
results:
>> tl_get_blocks(<system>, 'Inport')
>> tl_get_blocks(<system>, {'Inport'})
But unlike than expected the results differ. The first command
delivers the
TargetLink InPort blocks, whereas the second command
delivers the unenhanced
Simulink Inport blocks.
Note that this problem is only limited to port blocks.
Workaround: If you are interested in TargetLink blocks only use their mask
types instead of
their blocks names from TargetLink block library as search
criteria, i.e. the
criteria 'Inport' returns unenhanced Simulink Inports, whereas
'TL_Inport' finds
the TargetLink port blocks. The use of 'InPort' (attend to the
notation) to find
the TargetLink Inport blocks is intended for convenience, if the
mask type is
not known.
patches:
TargetLink 3.2p1
338 / 1260
ID:
KPR.2010.05.12.001
Title:
Saturation in Stateflow not taken into account for math

function call

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow a math function is called, a specified saturation

may be not
taken into account, if following conditions hold:
Functions: abs, labs or fabs
- all operands are integer
-- AND -- at least one of the operands has a different TargetLink type
than Stateflow
type
Functions: sqrt, min or max
- at least one of the operands has a different TargetLink type
than Stateflow
type or is scaled (LSB != 1.0 and/or Offset != 0.0)
-- AND -- the saturation limits (i.e. the min/max values at the variable
on the left
hand side of the parent assignment) are not the limits that are
implemented by
data type and scaling
Function: fmod
- at least one of the operands is scaled (LSB != 1.0 and/or
Offset != 0.0)
Note:
Saturation for a math function call can be specified by
assigning the result of
the math function call to a variable that has property
Checkmin/Checkmax = 1.
Workaround: Introduce a local variable with a data type that can hold the
required result
range of the math function call and assign that variable to the
saturated
output.
339 / 1260
ID:
KPR.2010.05.21.001
Title:
Data type of substruct of multirate message variable is not

defined in $N_msg.h

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A message variable is specified in a multirate model. The

variable is specified
with a struct type that does contain a substruct. No module is
specified for the
substruct type.
In this case, code generation in RTOS mode may lead to one
of the following
errors:
- Code generation succeeds, but the generated RTOS code is
incorrect, because
the substruct is not defined in the message data type header
file $N_msg.h, but
in file udt_$I.h.
- Code generation aborts with message #17066 complaining
about a cyclic include
of files $N_msg.h and udt_$I.h.
Workaround: First, specify a NameTemplate for the module object
/Pool/Modules/TLPredefinedModules/RTOS/ITCDataTypes in
the Data Dictionary that
is different from "$N_msg". Then create a new module object
with NameTemplate
"$N_msg". At last, specify the newly created module object as
ModuleRef for
every data type that is used by a message variable and that is
not a base type.
patches:
TargetLink 3.1p3
340 / 1260
ID:
KPR.2010.05.27.001
Title:
Build process for SIL/PIL mode may abort if DataDictionary

CodeGenerationUnit object are selected

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The build process for SIL/PIL mode can be started in several
ways:
1. Call one of the API commands "tl_build_host",
"tl_build_target",
"tl_compile_host" or "tl_compile_target"
2. TargetLink Main Dialog click one of the buttons "Build SIL",
"Build PIL",
"Compile SIL", "Compile PIL"
If a Data Dictionary CodeGenerationUnit is selected additionaly
to a TargetLink
subsystem, the build process may abort with the following
error:
??? Error using ==> sprintf
Function is not defined for 'cell' inputs.
Error in ==> dsdd_get_sourcefile_list>FcnCheckCommandLine
at 165
msgText = sprintf( ...
This happen if following conditions hold:
1. Production code was generated the selected
CodeGenerationUnit object
2. After code generation the CodeGenerationUnitID of the
selected
CodeGenerationUnit object was modified
3. Production code was generated for the selected
CodeGenerationUnit object
again and started the compilation of the production code
SIL/PIL application
Workaround: After modifing the CodeGenerationUnitID of the selected
CodeGenerationUnit
object delete in the Subsystems area of the current
DataDictionary the Subsystem
objects corresponding to the selected CodeGenerationUnit
object. There are
objects named:
<CodeGenerationUnitObjectName>_<CodeGenerationUnitID>.
patches:
TargetLink 3.1p3
341 / 1260
ID:
KPR.2010.05.27.002
Title:
Error message 8665 (Invalid DD output) issued during A2L file

export

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a subsystem contains an Interpolation Using Prelookup

block the A2L file is
generation for that subsystem may issue an error like the
following:
Message 8665, Kind Error
Title: Invalid DD output
Message:Found invalid Data Dictionary output: The number of
SourceSignal block
variables does not match the number of Output block
variables.
Affected DD object <DDObjectPath>
The are two different use cases where the wrong error
message occurs:
1. The Interpolation Using Prelookup block is connected to the
Prelookup Index
Search block residing in the same subsystem. The error is
caused by an internal
error in the DataDoctionary output.
2. The Interpolation Using Prelookup block is directly
connected to the
TargetLink root InPort blocks. This error is unjustified and may
be ignored. The
generated A2L file is correct.
NOTE:
Two blocks are directly connected, if the signal path between
the two blocks
contains no block or only virtual blocks for instance TargetLink
port blocks,
Mux blocks etc.
342 / 1260
ID:
KPR.2010.06.07.003
Title:
Incorrect code for numerical integer function argument

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Description:
If in Stateflow
- a function within Stateflow is called
-- AND -- the return type of the function is Void
-- AND -- a formal parameter of this function is scaled (LSB != 1.0
and/or Offset !=
0.0)
-- AND -- the associated actual argument is an integer value that is not
given in
floating-point syntax,
then the actual argument value in the generated code might
be wrong.
Workaround: Enter the numerical value in floating-point syntax, e.g. "1.0"
instead of "1".
343 / 1260
ID:
KPR.2010.06.07.004
Title:
Lookup table axis or table variables are not moved to the

function reuse structure if generation of map structure is
disabled

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Relevant variables for reuse have to be appended to a reuse

structure. For a
lookup table there exist three cases how the variables can be
created:
1) with map structure - indirect (a map structure with pointer to
the axis/table
vriable)
In this case a map structure has to be moved into a reuse
structure, the
axis/table variables shall be left outside and not being reused.
2) with map structure - direct (a map structure where
axis/table are direct
members)
In this case a map structure with the containing elements is
reused.
3) without map structure
In this case each single variable (axis/table) has to be reused.
In the third case the axis and/or tabe variable is not reused.
This leads to
incorrect code since all instances of such reused system use
the same axis
and/or table variable.
Workaround: Enable the generation of a map structure or replace the lookup table blocks by
a pair of "PreLookup Index Search" and "Interpolation (n-D)
Using PreLookup"
blocks.
344 / 1260
ID:
KPR.2010.06.07.005
Title:
Call to function with return value and call-by-reference output

is erroneously removed

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a function has at least two outputs, one of them the return
value, the other
one a call-by-reference value, then it is possible that
TargetLink erroneously
removes the function call (and, if it was the only call to the
function,
subsequently the function itself) if
- the return value is never used (e.g. sent to a Terminator
block)
-- AND -- the return value's variable class is either a default class or
has an ArgClass
that is a default class or has enabled ERASABLE Optimization
property.
Furthermore, the function must have
- a default function class or a user function class with disabled
SIDE_EFFECT_FREE Optimization property
-- AND -- an internal state (a local variable with static storage duration)
Workaround: If the function in question is called and generated for
OptimizationLevel = 0,
then setting the code generator option
SideEffectFreeAnalysisThreshold = 0
usually leads to correct code but may lead to missing
optimizations.
The best workaround for situations where the model can be
modified is inserting
a Rescaler (or TargetLink port) block after the return value
function output;
this workaround block is set to "Inherit properties" and has a
block output
variable class with disabled ERASABLE Optimization
property.
Otherwise, if the return value function output's variable class
can be
influenced, an ArgClass with disabled ERASABLE
Optimization property can be
used.
patches:
TargetLink 3.1p3
ID:
KPR.2010.06.07.006
345 / 1260
Title:
Incorrect code due to missing cast of multiplication with 64-bit

result and smaller operation range

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
346 / 1260
Description: For the blocks

- Discrete-Time Integrator
- Discrete Transfer Fcn
- Discrete Filter
- FIR Filter
- Discrete State-Space
an auxiliary 64-bit variable or a 64-bit state may be introduced
(look for
warning 17352).
Based on the preceding code the result of a multiplication can
be assigned to
that variable.
If the result range of such a product can be represented in a
data type smaller
than 64 bit, an auxiliary variable will be introduced to receive
the result of
that multiplication. In the assignment of the product to that
auxiliary variable
casts might be missing.
Example:
For a Discrete Integrator block a 64-bit state was introduced.
static Int32 X_Sa1_Discrete__e_Integrator_hi;
static UInt32 X_Sa1_Discrete__e_Integrator_lo;
The state is initialized by the input considering the sampling
rate:
X_Sa1_Discrete__e_Integrator = In * 400;
implemented as
UInt32 Aux_U32;
UInt16 StartValue;
Aux_U32 = StartValue * 400;
C__I64COPYU32(Aux_U32,
X_Sa1_Discrete__e_Integrator_hi,
X_Sa1_Discrete__e_Integrator_lo);
The multiplication given above has an operation range of
UInt16 * 400 which can
be represented with UInt32.
Since the operands of the multiplication are not cast to UInt32
the
multiplication can render wrong results.
Instead the correct code line should have at least one operand
cast to 32 bit,
e.g. "Aux_U32 = ((UInt32)StartValue) * 400;".
Note: the incorrect code will still calculate correct results on a
32 bit target
MCU due to implicit type conversion rules of ANSI C, but likely
will fail on
16/8 bit targets.
Workaround: Try to avoid unefficient 64-bit code in general, e.g. by
adjusting scalings
and/or by specifying contstraint ranges.
347 / 1260
ID:
KPR.2010.06.08.001
Title:
AUTOSAR Diff/Merge-Explorer shows differences that are

unfounded

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If an AUTOSAR file is imported into a new Data Dictionary and

the AUTOSAR
Diff/Merge-Explorer is opened with the previously imported file
no differences
are expected.
Nevertheless some objects (related to CalPrm elements) are
marked as
missing/deleted.
Reason:
The import of the AUTOSAR file worked correctly and CalPrm
elements were
synchronised with the related variable objects. When the
AUTOSAR
Diff/Merge-Explorer is opened the file again is imported but
into another
workspace of the Data Dictionary. In this case the
synchronisation of the CalPrm
elements is not done which leads to the pretended
differences.
Workaround: No workaround available. Ignore the differences related to
CalPrm variable
objects and groups.
348 / 1260
ID:
KPR.2010.06.08.002
Title:
AUTOSAR export aborts with error message E08812 for Data

Constraint element

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR export creates a DATA-CONSTRAINT

element for range information from
Min/Max properties of a certain DataDictionary object
(Variable object,
DataElement object, OperationArgument object,
CalPrmElement object). During the
creation of the DATA-CONSTRAINT element its name will be
built of the prefix
"DC_" and the name of the associated DataDictionary object.
The whole short name
will be cut to 31 characters, which implies that the name of the
DATA-CONSTRAINT
element can become ambiguous. The AUTOSAR export
throws the error message E08812
with references to the DataDictionary objects if the names of
the
DATA-CONSTRAINT elements are ambiguous and the
DataDictionary objects are not
equal. This error message can be incomprehensible if the
names of the
DataDictionary objects exceed 28 characters because the
error message does not
show the shortened names of the DataDictionary objects but
the original names.
Workaround: The error message E08812 list two Data Dictionary objects.
Rename one of the
two, so that the first 28 characters of the name of the first Data
Dictionary
object are different to the second one.
patches:
TargetLink 3.1p3
349 / 1260
ID:
KPR.2010.06.10.001
Title:
Incorrect code due to missing saturation of

addition/subtraction if Min value is set to value >= 0

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If
- in a Sum block saturation to the upper limit is enabled
-- AND -- for the Min property that block a value >= 0 is specified
or if
- the last operation on the right hand side of a Stateflow
expression is an
addition/subtraction
-- AND -- the variable on the left hand side has a Minimum value >= 0
and a Maximum
value that is the implemented max value
-- AND -- the variable's TargetLink property sf.checkmax ("Saturate
against overflow")
is set
-- AND -- at least one operand of the expression has a different
TargetLink than
Stateflow data type,
then the saturation to the upper limit might be lost.
Note:
The problem does not come up if the code for the affected
block/Stateflow
expression is a macro call of C__xxxFITxxx_SAT() where xxx
denotes a type cut
(like e.g. I32 for Int32).
Workaround: Do not use saturation and constrained ranges for
additions/subtractions
together.
350 / 1260
ID:
KPR.2010.06.14.002
Title:
Rows in Property Manager's Block Explorer may become

unsynchronized

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The 1st ("Name") column in the Property Manager's Block

Explorer (top right
pane) displays the names of the TargetLink blocks and
Stateflow objects in the
model. If the items do not fit into the column, a vertical and a
horizontal
scroll bar are added to the column and allow to move hidden
items into view.
Separate scrollbars are added to the remaining (2nd, 3rd, ...)
when they are
needed. However, when the 1st column has a horizontal and
a vertical scrollbar
while the other columns have only a vertical scrollbar, the
rows get out of sync
when the vertical scrollbar of the name column is moved to
the end of the list.
When it is moved to the beginning, the rows are resynchronized.
Workaround: - enlarge Block Explorer pane so that all items can be
displayed
-- OR -- move up and down using the keyboard (arrow keys) instead
of the mouse
-- OR -- mark line to see which cells in the 2nd, 3rd etc column
belong to which item
in the 1st.
351 / 1260
ID:
KPR.2010.06.15.001
Title:
RECORD_LAYOUT generated for AXIS_PTS may be

incorrect if a user lookup table script is used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In the generated A2L file the description of the lookup table
axis may be
incorrect if a user has customized the production code
generation for the look
up table by means of the user lookup table script.
The RECORD_LAYOUT referenced from the corresponding
AXIS_PTS entry may be
generated with the FNC_VALUES keyword, for example
/begin RECORD_LAYOUT
UWORD_COL_DIRECT /* Name */
FNC_VALUES 1 UWORD COLUMN_DIR DIRECT
/end RECORD_LAYOUT
but the AXIS_PTS_X keyword should be used:
/begin RECORD_LAYOUT
UWORD_X_INCR_DIRECT /* Name */
AXIS_PTS_X 1 UWORD INDEX_INCR DIRECT
/end RECORD_LAYOUT
Workaround: In the used lookup table script set the "Keyword" property of
the variable
describing the axis to "AXIS_PTS_X" or "AXIS_PTS_Y", for
example:
tlscript('Set','xval', ...
'Name' ,blockData.input.name, ...
...
'Keyword' ,'AXIS_PTS_X' ...
);
352 / 1260
ID:
KPR.2010.06.15.003
Title:
2D lookup table with vectorial table variable leads to fatal error

#99999

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is a Data Dictionary Variable which has a Width

property that specifies a
vector, e.g. 5, and an unset Value property. If such Variable
object is
referenced in a table parameter of a Look-Up Table (2D) block
it leads to an
unspecific error message and a fatal error during code
generation. In addition,
starting the table tool via the block dialog leads to the
following error
messages on the MATLAB command window:
??? Attempted to access tWidth(2); index out of bounds
because numel(tWidth)=1.
Workaround: Specify the correct width at the Data Dictionary Variable used
for the table
parameter of the Look-Up Table (2D) block.
353 / 1260
ID:
KPR.2010.06.15.004
Title:
The function "tl_generate_swc_model" may abort with a "Input

bounds are out of range" error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The function tl_generate_swc_model may abort with following

Simulink error:
??? Error using ==> set_param
Input bounds are out of range.
Error in ==>
tl_generate_swc_model>FcnAddRunnableSubsystems at
1601
set_param(hSubsystem, 'Position', currentRunnablePosition);
Error in ==>
tl_generate_swc_model>FcnAddContentToTlSubsystem at
715
[runInputConnectionList,...
FcnAddContentToTlSubsystem(hTlSubsystem,
options.swcObjectList,
options.simulinkAutorouting, ...
This happen if the position of the blocks or subsystems to be
placed in the
generated model exceeds the Simulink maximal position of
32767, for example if
within a SWC subsystem many runnable subsystems with
multiple inputs and outputs
must be placed.
354 / 1260
ID:
KPR.2010.06.16.001
Title:
Model containing a TargetLink subsystem with incomming bus

signal with mixed data type cannot be initialized in SIL/PIL
simulation mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A Simulink model containing a TargetLink subsystem with an

input port driven by
a bus signal with mixed data type cannot be initialized if
hold:
- The TargetLink subsystem is in SIL or PIL simulation mode
-- AND -- This input port, or an element of the input port, is connected
directly to an
output port.
In this case following Simuling initialization error is issued:
"Input port cannot accept mixed data types. Input port 1 of
<portPath> expects a
signal with unique data type. However, it is driven by a signal
with elements of
differing data types."
Workaround: Place a non virtual block, for example a TargetLink Gain
block, between the
affected input and output port. If the signal between the
affected input and
output port consists of elements of different types you will
have to handle them
separately.
355 / 1260
ID:
KPR.2010.06.16.002
Title:
Incorrect code due to erroneous value propagation for index

expression of matrix

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The initial value of an index variable may replace a constant

index value in
second dimension if following conditions are met:
- The first dimension of a matrix is accessed using a variable
-- AND -- this variable can be replaced by its initial value
-- AND -- the second dimension of the matrix is accessed by a
constant value
Example:
Int16 Var = 3;
Int16 MatrixVariable[5][5];
The expression
MatrixVariable[Var][2]
might be changed to
MatrixVariable[3][3]
This kind of code can be modeled using Stateflow.
Workaround: Suppress the initial value propagation of the variable used to
access the first
dimension.
356 / 1260
ID:
KPR.2010.06.17.001
Title:
Missing CTO comment for Sum block with more then 2 inputs

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Sum block

- has more than two inputs
-- AND -- it the output has an unsigned type
-- AND -- the result range of the addition/subtraction of the first two
inputs can be
negative
-- AND -- the PolySpaceSupport option is enabled,
then the result of the first addition/subtraction shall be marked
with a Compute
Through Overflow comment, but it this not marked.
Example:
A Sum block with
UInt8 U8Var; /* Input 1 */
UInt8 U8Var2; /* Input 2 */
UInt8 U8Var3; /* Input 3 */
UInt16 U16Var; /* Output*/
U16Var = U8Var - U8Var2 + U8Var3;
will be implemented as
U16Var = (UInt16)((UInt16)((UInt16)U8Var - (UInt16)U8Var2)
+ (UInt16)U8Var3);
The second UInt16 cast casts the result of the subtraction to
UInt16. It should
be marked with a Compute Through Overflow comment,
because the result of the
subtraction can be negative.
Workaround: Replace the Sum block by a cascade of Sum blocks with two
inputs.
357 / 1260
ID:
KPR.2010.06.17.002
Title:
Saturation is omitted for Data Dictionary variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink does not generate saturation code for a Data

Dictionary variable that
references a Data Dictionary module which has its
CodeGenerationBasis property
set to "DDBased" or "ModelAndDDBased"
and is used in a block with activated Saturation flag.
ID:
KPR.2010.06.23.001
Title:
Call to client/server operation without argument cannot be created by the

SWC model generator

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If within the software component that is to be modeled by means of the

SWC model
generator a runnable with call to an operation without argument is defined,
during model generation following warning is issued:
*** W02992: UNSUPPORTED OPERATION ARGUMENTS FOUND:
*** Operation
'/Pool/Interfaces/DWA/DWA_DwaOutputEvt_csif/Operations/evtAlarmStart'
*** referenced by synchronous server call point of runnable
'DWAMakeOneStep'
*** either has not operation arguments at all, or has operation
arguments
*** of unsupported kind (ARGINOUT, RETURN_VALUE).
*** For this server call point no block will be placed inside
*** the subsystem modelling the runnable.
The ceation of such operation call is currently not supported by the model
generator.
The problem is fixed by using the following patches or later patches:
TargetLink 2.3.1p5
TargetLink 3.1p2
358 / 1260
ID:
KPR.2010.06.30.001
Title:
TargetLink Data Server uses more memory in TargetLink 3.x

compared to TargetLink 2.x

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In MIL simulation mode substantially more memory is in use

after simulation
compared to TargetLink 2.x, especially if there are many
signals and/or
vectorized signals with many vector elements while only a few
(< 4096) samples
are logged. The problem does not occur in SIL/PIL simulation
mode.
Workaround: - Save the simulation, delete it, and reload it from file. This can
be done from
TargetLink Main Dialog, tab Simulation with Save and Load
buttons.
- Decrease the number of simulations kept in memory. This
can be done in the
TargetLink Main Dialog, tab Simulation with "Max. number of
simulations" entry.
patches:
TargetLink 3.1p3
359 / 1260
ID:
KPR.2010.07.01.001
Title:
MODULE IF_DATA does not appear in the generated A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The MODULE IF_DATA is generated into an A2L file only if

the user has provided a
suitable description under the Subsystem's IF_DATA child
object in the Data
Dictionary (for details see A2L export manual > How to Create
and Specify an
IF_DATA Object for a MODULE Element).
If there are at least two subsystems selected for A2L export
and in only one has
an IF_DATA child object sepcified, it may happen that the
corresponding MODULE
IF_DATA element does not appear in the generated A2L file.
This occurs if the
Subsystem object with the IF_DATA child object is not
specified as the first one
in the selection.
Workaround: Ensure the correct order of the Subsystem object specified for
the A2L file
generation or provide the IF_DATA child object in each of the
selected
subsystems objects
ID:
KPR.2010.07.01.002
Title:
Modulo operator "%" is not displayed in the HTML code view

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: An expression with the % operator in the generated C code

like
b = a % 6;
will appear in the model-linked code view HTML file without
the % operator:
b = a 6;
360 / 1260
ID:
KPR.2010.07.05.001
Title:
Dialog of Bus Outport block shows wrong properties of a

signal

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Using the TargetLink Busport block dialog two bus signals are
not editable
independently, if the two bus signals have names starting with
the same string
like "Signal2_first" and "Signal2".
If the second signal has a name that is only the starting part of
the other
signal (like shown above) and it is below the first signal in the
tree view,
then the choosen properties are stored always for first signal,
although the
second signal is selected in the tree view. It does not matter
whether there are
other signals also available in the bus in any order.
Workaround: Use the API or the TargetLink Property Manager to set
properties for these
signals.
patches:
TargetLink 3.1p4
ID:
KPR.2010.07.05.002
Title:
Data Dictionary Variable that is not explicitly configured as

global (e.g. <default>) is generated in stub file without use in
the model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A Data Dictionary Variable that has not explicitly set a variable
class with
global scope, has a specified module and a fixed variable
name is generated in a
stub file, although it is not used in the model.
patches:
TargetLink 3.1p3
361 / 1260
ID:
KPR.2010.07.05.003
Title:
Code generation aborts if using dynamic struct components,

that fulfills criterias for code generation from the
DataDictionary

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in the Data Dictionary a struct with dynamic components is

specified, and the
struct root Variable object fulfills the following conditions
- The Data Dictionary Variable object or the VariableClass
object referenced by
the Variable object references a Module object with property
CodegenerationBase
set to "DDBased" or "ModelAndDDBased", or set to
"ModelBased" and the module
will be generated as a stub module because of ownership
-- AND -- The scope of the Data Dictionary Variable is global
-- AND -- The name template of the Data Dictionary Variable does not
contain
model-specific name macros
the code generation aborts with an accesss violation.
Workaround: If possible, one of the points in the description should be
changed, so that not
all conditions are fulfilled.
patches:
TargetLink 3.1p3
362 / 1260
ID:
KPR.2010.07.05.004
Title:
Aftereffects of inconsistent TargetLink simulation frame

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The simulation frame can become inconsistent if ports on the

top level of an
TargetLink Subsystem are added or removed. The number of
ports outside and
inside the subsystem differs in such a situation. If you omit
correcting the
simulation frame, this can lead to aftereffects. Typical for such
an aftereffect
is an error message regarding an add_line operation. The
operation fails due to
an "Invalid Simulink object specifier" or an "Invalid Simulink
object name".
Workaround: The TargetLink simulation frame can be made consistent by
toggling the
simulation mode (TargetLink version 3.0) or activating the MIL
mode (TargetLink
3.1)
ID:
KPR.2010.07.05.005
Title:
Navigating through the bus hierarchy impossible

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: In order to detect changes of the bus hierarchy the dialog of

TargetLink Busport
blocks provides a function called "Rescan bus hierary". In the
case that the bus
has no name, i.e. the signal line has no label, the dialog
becomes unusable
after performing the rescan.
Workaround: Close and reopen the dialog.
patches:
TargetLink 3.1p4
363 / 1260
ID:
KPR.2010.07.05.006
Title:
Unintended library link resulting from copy action within a

library

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: When building a library you might need several instances of

the same block type.
If you copy for this purpose a TargetLink block within the
library to be
created, the copy possesses a library link to the original block
in the same
library. This can cause further side effects like confused
numbering of
subsystem inports.
Workaround: You can avoid the unintended library links by using the
TargetLink library as
sole source for TargetLink blocks.
ID:
KPR.2010.07.08.001
Title:
Saturation of unsigned 64-bit value to upper limit less than 0

results in wrong value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A saturation of an unsigned 64-bit value to an upper limit less

than 0 results
in wrong values. Such case can be identified in the generated
code, because the
following macros are affected if the upper limit (upsatval) has
a negativ value:
C__I32SATU64_SATb(v_h, v_l, upsatval, losatval)
C__I32SATU64_SATu(v_h, v_l, upsatval)
364 / 1260
ID:
KPR.2010.07.08.002
Title:
Tangent function results in wrong values, if calculation should

be done in 16-bit fixed-point with arbitrary scaling

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Calculation of trigonometric tangent (tan) function results in

wrong values, if
calculation should be done in 16-bit fixed-point with arbitrary
scaling. In more
detail, the tangent function F__I16TANI16_ARB(v,N,D) with
arbitrary scaling
calculates wrong output values for input u with -0.68 < u
<0.68.
365 / 1260
ID:
KPR.2010.07.16.001
Title:
Download for PIL simulation does not work with virtual COM
port

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A download for PIL simulation through virtual COM port with
the TLLoader fails.
After the board has been reset and the flash was erased the
programming phase
started and stopped with an error messages "Error: A serial
buffer overflow
occurred." This problem may cause in a new version 2.06 of
FTDI device driver.
This FTDI device driver is "Windows Logo Verification" now
and is automatically
installed with a Windows update. This new device driver
belongs to the
evaluation board and is not supported by TargetLink.
Workaround: If you have an old version of the driver available, e.g. from an
old
installation, following workaround can be applied:
1. Switch the evaluation board off
2. Rename the file "ftser2k.sys" of the device driver in
common windows
directory "C:\windows\system32\drivers" to "ftser2k.sys__"
3. Copy the file "ftser2k.sys" of an older device driver to
directory
"C:\windows\system32\drivers"
4. Rename the file "ftd2xx.dll" in directory
"C:\windows\system32" to
"ftd2xx.dll__"
5. Copy the file "ftd2xx.dll" of an older device driver to
directory
"C:\windows\system32".
6. Switch the evaluation board on
If your windows system is not installed in "C:\windows" you
have to use the
directories according to your system.
The device driver is shown in the device manager still in the
version 2.06, but
the download works.
patches:
TargetLink 2.3.1p6
TargetLink 3.1p4
366 / 1260
ID:
KPR.2010.07.16.004
Title:
Incorrect code for abs function call with operation as argument

in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow
- an abs or fabs (not labs) function is called
-- AND -- the argument of that function call is an operation
-- AND -- at least one of the operands of the expression containing the
call has a
different TargetLink than Stateflow data type
-- AND -- none of the operands has a scaling (LSB != 1.0 and/or Offset
!= 0.0)
-- AND -- none of the operands has a floating-point data type
-- AND -- the abs/fabs function call is not the last operation on the right
hand side of
an assignment,
then the generated code may be wrong.
The erroneous production code can be identified by a
conditional operator (?:)
containing an unary minus operation with an Int8 cast.
Workaround: - Introduce an auxiliary variable to hold the result of the
abs/fabs functions
argument operation
-- OR -- use the labs() function
-- OR -- specify the same TargetLink as Stateflow data type for the
operands that are
part of the expression
-- OR -- introduce a scaling (LSB != 1.0 and/or Offset != 0.0) for at
least one of the
operands of the affected expression
patches:
TargetLink 3.1p4
367 / 1260
ID:
KPR.2010.07.16.005
Title:
Wrong message about wrong dimensions when selecting a

Data Dictionary variable for the table in Direct Look-Up Table
(n-D) block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface

2D table with
the dimension [n m] the current Width property in Data
Dictionary is also [n m].
Selecting this variable for the table variable of a Direct LookUp Table (n-D)
block results in error message like:
z_table.width = [n m]
The message is wrong, because the data is handled
incorrectly in the block's
dialog. Hence such variable cannot be set in the block's
dialog.
Workaround: Use the API (tl_set) or Property Manager to set the variable
patches:
TargetLink 3.1p4
ID:
KPR.2010.07.16.008
Title:
Broken block dialog of Discrete State-Space block using

matrix values from DataDictionary

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The block dialog of Discrete State-Space block aborts, if

hold:
- The matrices tab of the dialog is displayed
-- AND -- a Data Dictionary variable specifying a matrix with size n x m
(n>1 and m>1)
is selected for B, C or D matrix
-- AND -- this matrix is selected for display via select control.
patches:
TargetLink 3.1p4
368 / 1260
ID:
KPR.2010.07.19.001
Title:
PIL simulation aborts with error message "Number of

simulation variables must not be exceeded."

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In case production code generated in AUTOSAR mode is

simulated in PIL simulation
mode and the number of input and output signals of all
runnables to be called
during simulation exceeds 20, the simulation aborts with this
following error
message:
"Number of simulation variables must not be exceeded".
patches:
TargetLink 3.1p4
369 / 1260
ID:
KPR.2010.07.19.002
Title:
MIL/SIL differences in the signal plot for the outport of an

enabled subsystem, if the "Output when disabled" property of
the outport is set to "reset"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: There are MIL/SIL differences in the signal plot for the outport
of an enabled
or action triggered subsystem, if the "Output when disabled"
property of the
outport is set to "reset":
During the time the enabled or action triggered subsystem is
disabled, the Plot
of the MIL simulation shows the Initial output value specified
at the outport.
This is the outside behavior of the enabled or action triggered
subsystem. In
contrast the plot of the SIL simulation shows the last value of
the outport
before the enabled or action triggered subsystem has been
disabled. This is the
inside behavior of the enabled or action triggered subsystem.
Workaround: Disable the logging the outport of an enabled or action
triggered subsystem, if
the "Output when disabled" property of the outport is set to
"reset". Instead:
To plot the outside behavior of the enabled or action triggered
subsystem, log
the output signal of the enabled or action triggered subsystem,
e.g. via a
TargetLink Sink-Block. If for the outport of the enabled or
action triggered
subsystem a global variable is created, you can alternatively
log the global
variable by adding the variable to the log variable list in the
Data Dictionary
after code has been generated for the TargetLink Subsystem.
To plot the inside behavior of the enabled or action triggered
subsystem, log
the input signal of the outport block of the enabled or action
triggered
subsystem, e.g. via a TargetLink Sink-Block.
370 / 1260
ID:
KPR.2010.07.19.003
Title:
No block declarations statements for function class in

generated code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: It is possible to specify following kinds of block declaration

statements in a
function class (function class property
"DeclarationStatements"):
- PreDeclarationBlockStatements
- PostDeclarationBlockStatements
- PreDefinitionBlockStatements
- PostDefinitionBlockStatements
If you specify for example a PreDeclarationBlockStatement for
a function class
FUNCCLASS then this statement shall be emitted in the
generated code before the
block of function declarations of function belonging to class
FUNCCLASS.
But such declaration statement is not emited in the code.
ID:
KPR.2010.07.20.001
Title:
Code generation aborts with error in Look-Up Table map

although no map shall be generated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A variable of struct type is specified in the Data Dictionary.

The variable has
a variable class which Scope is "ref_param". One of its
components is specifies
as an axis of a Look-Up Table block. In the block's dialog the
option "Generate
map struct" is disabled, thus no map struct shall be generated
for this block.
In this case, code generation may stop with an error message
like the following:
Error #20352: TLSS/func/Look-Up Table1:
The variable TableAxis is specified to be a part of a structure
with ref_param
scope. Additionally, this variable is specified to be a
component of the Look-Up
Tables Map Structure. This is not permitted.
Workaround: Replace the lookup table blocks by a pair of PreLookup Index
Search and
Interpolation Using PreLookup block.
371 / 1260
ID:
KPR.2010.08.11.001
Title:
Accuracy loss at sqrt call with fixed-point input and floatingpoint result

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If for a Math block the function "sqrt" is chosen

-- OR -if a Stateflow expression contains an sqrt call
-- AND -- the expression the sqrt is part of contains floating-point
operands
-- AND -- the call argument of the sqrt function is fixed-point
-- AND -- the expression is not an assignment where the sqrt call is the
only operation
on the right hand side
an auxiliary variable is introduced to hold the sqrt result.
This auxiliary variable will get the argument type, i.e. it will be
fixed-point.
This introduces unnecessary accuracy loss compared to an
floating-point
auxiliary variable.
Inaccurate Pattern:
I16AuxVar = (Int16)sqrt((Float64)I16Var)
F64Var = (Float64)I16AuxVar + 0.5;
Better:
F64AuxVar = sqrt((Float64)I16Var)
F64Var = F64AuxVar + 0.5;
Workaround: Stateflow: Introduce a floating-point auxiliary variable for the
result of the
sqrt operation.
Math block: No workaround available.
ID:
KPR.2010.08.11.002
Title:
Vector input passed as call-by-value (value_param) to a

Stateflow graphical function can lead to incorrect code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
372 / 1260
Description: For Stateflow graphical function, it is possible to modify inputs,

i.e.
output = foo(input);
where input also can be used inside foo() as temporary
variable:
... = input;
input = ...
...
For a parameter with variable class' Scope = value_param
(default for the above
mentioned kinds of functions), there is a difference between
Stateflow semantics
and semantics of the generated C code:
In C, for scalar variables, the parameter is a copy of the
passed value, but for
vectors and matrices, the parameter is the start address of the
respective
passed "value" (i.e. the actual argument is changed by
changes of the formal
parameter).
For Stateflow, it is always a copy of the passed value, i.e. the
actual argument
cannot be changed.
For
aux_input = input
output = foo(aux_input);
something = output + input;
where foo() changes "aux_input", "aux_input" can be
eliminated for scalar
variables and must not be eliminated for vectors and matrices.
TargetLink also optimizes vector "aux_input" to
which is wrong.
Workaround: 1) Do not use inputs as temporary variables
2) For Stateflow specification
TargetLink generates
aux_input = input;
output = foo(aux_input);
which is correct but will be optimized wrongly. You can make
this explicit
by specifying
fooInput = input;
output = foo(fooInput);
and assigning a variable class to "fooInput" that has no set
ERASABLE
Optimization property. In this case, fooInput is not eliminated.
ID:
KPR.2010.08.11.003
373 / 1260
Title:
Endless loop if the implementation of loop head/condition

results in standalone macro call or if an auxiliary variable is
introduced for an operand

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Whenever the implementation of an operation that is part of a

loop's condition /
header requires a standalone macro call or an auxiliary
variable, the resulting
code will be incorrect, because the standalone statement will
not be placed
inside the loop which means that it will not be updated.
A standalone macro call is a single statement macro call (not
a macro call that
returns a value and is part of another expression).
Example 1:
If a while loop modeled in Stateflow with the condition
(UnscaledI32Var >
UnscaledU32Var - 1), then the relational operation will be
implemented using
64-bit.
The calculation of the arguments of this 64-bit relation (macro
C__GT64),
however, is only placed in front of the loop instead of in front
and within the
loop.
The incorrect generated code is:
C__I64SUBU32U32(Ca2_UnscaledU32Var, (UInt32) 1,
Aux__hi, Aux__lo);
C__I64COPYI32(Ca2_UnscaledI32Var, Aux__a_hi,
Aux__a_lo);
while (C__GT64(Aux__a_hi, Aux__a_lo, Aux__hi, Aux__lo))
{
...
}
The subtraction and 64-bit copy shall also appear at the end
of the loop.
Example 2:
A similar while loop with an sin() call in the condition will be
implemented as
AuxVar = ...;
while(i < sin(AuxVar))
{ ... }
AuxVar will not be updated for every step of the loop.
Note:
The code generation will abort with an error E17007 in
TargetLink version 3.2
and 3.3. So no incorrect code will be generated.
With TargetLink 3.3p3 and newer versions, the code
generator will not abort with
an error message but generate correct code.
374 / 1260
Workaround: Avoid complex loop expressions by introducing additional

auxiliary variables.
Or use TargetLink 3.3p3 and newer versions.
ID:
KPR.2010.08.18.001
Title:
No saturation for Chart Input object code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A model contains a Stateflow chart. An Input object is

specified for the Chart,
so TargetLink creates an input variable for this object.
Additionally,
saturation against underflow and/or against overflow is
specified for the Input
object.
In this case, TargetLink does not generate any saturation
code for the Chart
input, even if the input's signals exceed its constraints.
Workaround: Place a Saturation block right before the Chart input, and
specify saturation
there.
375 / 1260
ID:
KPR.2010.08.18.002
Title:
Assignment to width-varianted variable may be implemented

as loop with fixed limit in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Let A be a variable with a variable vector width, and let M be

the associated
width macro. Then an assignment
A = <expression...>
should be implemented using the width macro as loop limit:
for (i = 0; i < M; i++) {
A[i] = <expression...>
}
However, if the right-hand expression contains an array
access into a fixed-size
array, the loop will be implemented using the numeric width of
A.
Example:
A = B[0] + C
for (i = 0; i < 10; i++) { /* assuming A has 10 elements */
A[i] = B[0] + C[i]
}
Workaround: Assign such array accesses to auxiliary scalar variable:
temp = B[0];
A = temp + C
ID:
KPR.2010.08.19.001
Title:
Operation Call block shows settings as invalid if subsystem of

corresponding Runnable is masked

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Use a Function block in the special case of an operation call

block and open the
block's dialog. Then the operation call code options on the
AUTOSAR tab are
marked red (invalid), if the corresponding Runnable
subsystem is masked.
376 / 1260
ID:
KPR.2010.08.19.002
Title:
Incorrect code for switch statement with scaled argument in

Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Switch statements should only be generated if the switch

argument is unscaled,
i.e. data type = integer, LSB = 1 and offset = 0.
If a Stateflow input data is not enhanced (createinputvariable
= off) all
settings for type, LSB and offset should be inactive. In such a
case the
predecessor block output variable is taken as Input. But for
the decision if to
generate a switch or an if-else cascade the settings of the
predecessor are not
checked, the inactive settings of the Stateflow input data are
checked. So
falsely a switch statement is generated instead of an if-else
cascade.
This can lead to code like the following example:
switch (Sa1_InPort) {
case 0 /* 1. */: {
...
}
case 0 /* 2. */: {
...
}
default: {
...
}
}
Workaround: Delete all properties of the Stateflow input data used in the
switch condition
or set the createinputvariable property to "on".
377 / 1260
ID:
KPR.2010.08.19.003
Title:
Code generation aborts if a Data Store Write block is inside a

reuse subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If AUTOSAR code generation mode is enabled and a Data

Store Write block is
inside a reused subsystem an access violation occurs during
code generation.
Workaround: Remove the Data Store Write blocks from the reused system.
ID:
KPR.2010.08.23.001
Title:
Signal size mismatch error and wrong or missing overflow

warning in MIL simulation at bus containing muxed signals

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A bus containing muxed signals connected with a TargetLink

bus port block can
lead to following problems during MIL simulation, if logging is
not activated
for this block:
- The following error message appears:
'scaling data/signal size mismatch in block '<block path>' has
been detected.
The block property 'lsb' is a (2,1) vector, but the compiled
signal size is
(1,1).'
Nevertheless, the compiled size is equal to the size of the
property 'lsb'.
Any other scaling property ('offset', 'min' or 'max') can be
affected by this
problem.
- A non expected overflow warning appears for a bus element.
- An expected overflow warning does not appear for a bus
element.
Workaround: One of the following workarounds can be used:
1) Muxed signals and bus signals shall not be combined.
2) If there is a de-muxed or muxed signal connected to a bus
creator, a
non-virtual block (e.g. a data conversion block) must be
placed between it.
3) Activate logging for all parts of the bus in the TargetLink
port block.
378 / 1260
ID:
KPR.2010.08.23.002
Title:
Code generation aborts or incorrect code for Look-Up Table

(2D) block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For the block variable row of a Look-Up Table (2D) block it is
possible to use a
variable defined in the Data Dictionary that has specified a
width of
[NumberOfRows 1]. This means in the TargetLink semantic
that the variable has to
be implemented as a matrix and this is wrong for the row
variable. The correct
specification is a width of [NumberOfRows] which will be
generated as vector.
For a model containing a Look-Up Table (2D) block with such
a matrix variable
defined in the Data Dictionary and the enabled option
"Generate map struct"
(generatemapstruct), it is possible to generate code like the
following:
Wrong code:
const Int8 Sa1_Look_Up_Table__2D__x_table[3][1] =
{
...
}
Correct code:
const Int8 Sa1_Look_Up_Table__2D__x_table[3] =
{
...
}
The behavior of the code is correct, no wrong results because
the lookup
function is able to work with such a matrix correctly.
For a model containing a Look-Up Table (2D) block with such
a matrix variable
defined in the Data Dictionary and the disabled option
"Generate map struct"
(generatemapstruct), code generation aborts.
Workaround: Correct the width property of the Data Dictionary variable. The
width property
shall be specified as a scalar value.
379 / 1260
ID:
KPR.2010.08.23.003
Title:
Faulty export of AUTOSAR structured constant specifications

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR standard defines constant specifications for

AUTOSAR prototypes to
set init values to generated RTE variables.
For structured constant specifications the AUTOSAR export
throws an error
message, when the constant specification contains scalar
literal elements
(Integer, Real, Boolean) after the init value of an array
specification. The
associated Data Dictionary contains a structured variable
object, which contains
a scalar variable component directly below of a variable
component specifying a
vector.
The message thrown from the AUTOSAR export looks like the
following:
Message 8717, Kind Error
Title: Error during AUTOSAR export
Message: The export tries to generate the CONSTANTSPECIFICATION element 'Comp2'
which is of 'vectorial' kind. The associated variable object
references the
Typedef object 'DTUInt8', which is of 'scalar' kind. This is not
supported by
the AUTOSAR standard. Try to reference a compatible
Typedef object to export a
valid AUTOSAR description.
Workaround: Reorder the constant specification variable object in the Data
Dictionary. Move
all scalar variables to the top/begin, all vectorial variables to
the end of the
structured variable.
patches:
TargetLink 3.1p3
380 / 1260
ID:
KPR.2010.08.23.004
Title:
Saturation code is erroneously omitted if block output is

merged with subsequent Saturation block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the block output variable of a Saturation Block

- does not have static storage duration (static storage means
variable class'
Properties Scope = global and/or Storage = static)
-- AND -- it has a variable class with set MERGEABLE Optimization
property
-- AND -- the merged variable is also the block output variable of the
predecessor
block,
then the generated code might not contain the saturation
code, i.e. it might be
incorrect
Example:
A Gain block is followed by a Saturation block that is followed
by a Product
block:
/* Gain */
MergeableVar = InputVar * 5;
/* Saturation*/
MergeableVar = SaturateLower(MergeableVar, 1);
/* Division */
DivisionOut = DivisionIn / MergeableVar;
The result range from the Saturation block i.e. the limits of that
block will be
propagated to
- the denominator of the division (which is right) and to
- the input of the Saturation block (which is wrong)
This will lead to the erroneous conclusion that the saturation
for the
saturation block is superfluous and can be omitted.
Workaround: Besides of violating one of the conditions noted above in the
description
following is possible too:
Specify the limits of the Saturation block to be variables with
unset variable
class ERASABLE Optimization property and Macro = on.
-- OR -Give the block output variable of the Saturation block static
storage duration
(see condition 1).
381 / 1260
ID:
KPR.2010.08.24.001
Title:
Contradicting specifications of parameter scalings for

Stateflow customer-specific functions lead to incorrect code if
called with an operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: To specifiy extern functions TargetLink offers the customerspecific function

mechanism. This mechanism allows the user to describe the
interface of a
function for each time it is called from Stateflow. If the scaling
of a function
parameter is specified to be different for different calls and the
function is
called with an operation as argument for that parameter, the
resulting code may
be incorrect. Example: "f(a+1)".
Using an operation as argument is currently not supported,
thus since TargetLink
version 3.2 the code generation will not generate possibly
incorrect code but
abort with an error message like:
Error #30053: Subsystem/Chart Found contradicting
specification for scaling of
parameter in of function userfcn: LSB 0.01 and offset 0. In a
previous call the
specified scaling was LSB 0.00488281 and offset 0. Adapt
your script or, if the
function parameter is invariant to scaling, set the
'ScalingAdjust' property to
'off'.
Workaround: Introduce an auxiliary variable for the operation result and use
this variable
as function argument. Example: "tmp = a+1; f(tmp);".
382 / 1260
ID:
KPR.2010.08.30.001
Title:
Erroneous removal of assignment if variable has another

subsequent assignment and is used in another function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink removes unnecessary definitions of the kind

b = a1;
b = foo(a2);
bar();
b = a3 * a4;
i.e. the first two assignments are removed if foo() has no side
effects and all
intervening functions, in this case foo() and bar(), contain no
reading (or
reading and writing) accesses to "b", leading to
bar();
b = a3 * a4;
TargetLink tries for this pattern starting at every direct
assignment. The right
hand side of the last assignment is not checked.
This is not correct if foo() contains a reading (or reading and
writing) access
of "b", then starting at the second direct assignment
b = a1;
b = foo(a2);
a removal of "b = a1;" is allowed by the above rules but leads
to wrong
simulation behavior.
The problem occurs (without merging of variables) only for
Stateflow charts with
graphical functions. foo() then is a graphical function.
Workaround: 1) Do not "reuse" variables in this way, i.e. use a separate
input variable for
foo().
-- OR -2) Pass "b" to foo() as a function parameter in order to make
the data flow
explicit.
-- OR -3) Do not use "b" to receive the return value of foo():
- Either assign the returned value to "b" inside foo()
- or insert another variable "ret" to receive the return value
where "ret" has
a variable class without set ERASABLE Optimization property.
383 / 1260
ID:
KPR.2010.08.30.002
Title:
Simulation differences if nested triggered subsystems used

that drive a Merge block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Due to incorrect generated code the SIL/PIL simulation result

for a model may
differ from the MIL simulation result, if the following conditions
are met:
- the model contains enabled or action port triggered
subsystems that drive a
Merge block
-- AND -- at least one of these subsystems further contains an inner
enabled or action
port triggered subsystem
-- AND -- the outport of the inner subsystem(s) is directly connected to
the outport of
the outer subsystems, that means there are no process blocks
like Gain etc. on
that line
-- AND -- one of the outports, that do not belong to the innermost
subsystem, is
enhanced (for TargetLink < 3.0: There is a TargetLink Outport
on the signal
line).
The problem in the generated code is that the update of the
Merge block might
use an incorrect old (static) value from the inner subsystem if
in a step the
outer subsystem's code is executed and the code of the inner
subsystem is not
executed.
Workaround: De-enhance all outports (in TargetLink < 3.0 remove
TargetLink OutPort blocks),
that belong to the virtual signal line and that do not belong to
the innermost
system.
384 / 1260
ID:
KPR.2010.08.31.001
Title:
First chart output port must be logged to allow remaining

output ports to be logged in MIL simulation mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For a Stateflow chart containing more than one output port,
the first output
port must be logged to enable logging for the remaining output
ports in MIL
simulation mode. Otherwise, the remaining output ports are
not logged. No
message notes about such a problem.
The SIL and PIL simulation mode is not affected by this
problem.
Workaround: Enable logging of the first output port of a chart if logging is
desired for any
of the remaining output ports.
ID:
KPR.2010.09.03.001
Title:
Code generation aborts for Simulink system containing Model block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may abort for a system (TargetLink subsystem, subsystem
configured for incremental code generation or referenced model), containing a
Model block.
The error is like the following:
Fatal #10007: Internal error. Error code:
E:\SB\Xcg31p5\BuildConfiguration\Core\XcgIntermediateView\Sources\XcgIntermediat
eView\BlockContext\DataBlockContext\TlCBcBusInportContext.cpp_ 627. Contact
dSPACE's technical support team.
The problem is fixed by using the following patch or later patches:
TargetLink 3.1p4
385 / 1260
ID:
KPR.2010.09.03.002
Title:
Building of a real-time application from Simulink model

containing multiple stand-alone S-functions cause linker errors
or warnings

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Building of a real-time application, for example by means of

dSPACE RTI, from
Simulink model containing multiple TargetLink stand-alone Sfunctions
results in linker error resp. warning, similar to the following
one:
(E) #A0307-D Symbol: szErrMsg in file: TLFunc2_sfcn.o50
already defined in file:
TLFunc1_sfcn.o50
TLFunc1_sfcn.o50
TLFunc1_sfcn.o50
TLFunc1_sfcn.o50
TLFunc1_sfcn.o50
TLFunc1_sfcn.o50
TLFunc1_sfcn.o50
TLFunc1_sfcn.o50
The problem is based on insufficient scope of variable
szErrMsg.
patches:
TargetLink 3.1p4
386 / 1260
ID:
KPR.2010.09.07.001
Title:
An ExchangeableWidth object referenced directly by Stateflow

object is ignored by code generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A Data Dictionary ExchangeableWidth object can be

referenced by a Stateflow
object either directly via TargetLink's property "exwidth" (Data
Dictionary path
referencing an ExchangeableWidth object) or indirectly by
referencing a Variable
object via property "variable" which contains a reference to an
ExchangeableWidth object.
If property "exwidth" is directly specified and not via a Variable
object, it is
ignored during code generation to determine the width of the
object. This can
lead to an abnormal termination in a later phase of code
generation. Furthermore
the TargetLink API returns a wrong width of such Stateflow
object.
Workaround: Use the Data Dictionary Variable objects property
"ExchangeableWidthRef" to
reference a ExchangeableWidth object and TargetLink
property "variable" to
reference the Variable object by the Stateflow object.
patches:
TargetLink 3.1p5
387 / 1260
ID:
KPR.2010.09.07.002
Title:
CHARACTERISTIC resp. MEASUREMENT entry missing in

A2L file generated from Subsystem object created by import
of an XML file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In some use cases the objects within the Data Dictionary
Subsystems area created
by Code Generator are exported to an XML file. If such XML
file is imported to
the Data Dictionary and from the corresponding Subsystems
objects an A2L file is
generated some measurable and calibratable variables may
be missing in the A2L
file. This applies for a variable that is not referenced from any
BlockVariable
object below the ModelView area, because they:
1) belong to module generated straight from the Data
Dictionary and are not
referenced from any TargetLink block
2) are specified as actual argument of a function's formal
parameter
3) were manually inserted by the user into the Subsystems
object
Workaround: In Data Dictionary correct the Class property of the Variable
objects
corresponding to the measurable and calibratable variable
missing in the A2L
file. It must be a DD Handle and not a DD Reference. This can
be done only by
API commands:
Example:
hClass = dsdd('GetClassTarget',<DDVariable>) ;
dsdd('SetClass', <DDVariable>, hClass);
where <DDVariable> has to be replaced by the path to the
Variable object within
388 / 1260
ID:
KPR.2010.09.07.003
Title:
In batch mode a Port block cannot be transformed into

BusPort block or vice verca

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If the batch mode is active (ds_error_set('BatchMode','on')) it

is not possible
to transform a Port block into a BusPort block or vice verca.
A click on the text "Click here to transform the port block into a
busport
block" seems to be without any function.
The dialogs that should appear during transformation are
suppressed by the batch
mode and therefore the block remains in its current state.
Workaround: Disable batch mode (ds_error_set('BatchMode','off')) and start
transformation
again.
patches:
TargetLink 3.1p4
ID:
KPR.2010.09.07.004
Title:
Incorrect code for saturated tangent function with integer

operand in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A saturation will be omitted and incorrect code may be

generated if the
following conditions are met:
- An assignment of the form out = tan(in) is specified in
Stateflow
-- AND -- both operands (in, out) are integer
-- AND -- the variable on the left hand side has the checkmin and/or
checkmax option
enabled
389 / 1260
ID:
KPR.2010.09.08.001
Title:
Code generation aborts at attempt to simplify "a + MACRO" or

"a - MACRO" for MACRO with constant negative value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The Code Generator simplifies

a + -5
to
a-5
and
a - -5
to
a+5
If instead of "-5" an eligible macro with negative but constant
value is found,
then an access violation occurs.
A macro is eligible if it has a default variable class or a user
variable class
with set ERASABLE optimization property, Alias = off, Storage
!= extern, Info =
none (or Info = readonly).
Apart from explicit user specification, macros of this kind are
generated for
Stateflow parameter objects. If in doubt, inspect the code
generated for
OptimizationLevel = 0.
Workaround: 1) Set OptimizationLevel = 0
-- OR -2) Do not use ERASABLE macros and give Stateflow
parameter objects a variable
class that is not ERASABLE
-- OR -3) Use one of the above to identify the respective parameters
and macro
constants and change only their variable class
ID:
KPR.2010.09.08.002
Title:
Erroneous elimination of vector function parameters copied

from or to states

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
390 / 1260
Description: The Code Generator eliminates a variable if it can be replaced

by a valid
expression. This also holds for function arguments:
b[0] = a[0];
...
b[9] = a[9];
... /* 1 */
f(b, c);
... /* 2 */
d[0] = c[0];
...
d[4] = c[4];
can be optimized to
f(a, d);
if nothing in "/* 1 */" and "/* 2 */", respectively, prevents it.
If "d" and "a" are used as states and the other accesses lie
between the
assignments and the call to f(), e.g.
b[0] = a[0];
...
b[9] = a[9];
a[0] = i[0];
...
a[9] = i[9];
f(b, c);
o[0] = d[0];
...
o[4] = d[4];
d[0] = c[0];
...
d[4] = c[4];
then no optimization should take place. TargetLink performs
the optimization,
though.
In a Stateflow chart, the above situation can be easily
provoked.
In a Simulink model, the situation can occur with respect to
elimination of "c"
if a function output drives a Unit Delay block or a Data Store
Write block (with
Data Store Read situated to provide the initial situation);
provoking
elimination of "b" requires the use of atomic subsystem
boundaries between a
Unit Delay / Data Store Read and Write and the call to f() in
order to force the
state update before the call to f().
Workaround: Introduce an explicit actual variable by inserting a TargetLink
port block or a
Rescaler block and set its block output variable's variable
class to a class
with unset ERASABLE Optimization property.
391 / 1260
ID:
KPR.2010.09.09.001
Title:
Using Function Class property "CodeOutputTemplate" leads

to Fatal #17107 errors during Code Generation
Last Update: 08 Nov 2011

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Setting the Function Class property "CodeOutputTemplate"

(used to specify custom
XSL output templates for task functions in Multirate mode)
leads to an XML
validation error during code generator output similar to:
Fatal #17107: An error occurred in processing XSL:
Generated Document <file.c>
contains a parse error
This occurs because by default, the code generator validates
the generated XML
representation of the code against an XML Schema where the
custom templates are
not defined.
As of TargetLink 3.2 or later, this also applies to the respective
Variable
Class property used to implement the AUTOSAR Compiler
Abstraction specification.
Workaround: Disable the Schema validation inside the code output
configuration file, by
default located in
"%DSPACE_ROOT%\Matlab\Tl\config\codegen\cconfig.xml".
I.e. specify validate-xml-against-schema="false".
392 / 1260
ID:
KPR.2010.09.20.001
Title:
Documentation generation may run in an endless loop if

documented production code contains code from Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If production code to be documented has been generated

from system that contains
an Stateflow Chart block, it may happen that the
documentation generation run
does not finished. The documentation generator, sometimes
the MATLAB session,
must be aborted. In the up to abort generated documentation
file
<model>_main.html as last entry the unfinished hierarchy of
Stateflow functions
is shown.
patches:
TargetLink 3.1p4
393 / 1260
ID:
KPR.2010.09.20.002
Title:
Code Generator aborts or produces incorrect code for

operation as operand of bit operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow a bitwise operation (~, &, |, ^) is specified

- that is the top level operation of a condition
-- AND -- the Code Generator option
HandleUnscaledStateflowExpressionsWithTlType is
enabled
-- AND -- the bitwise operation contains a scaled operand (LSB != 1.0,
Offset != 0.0),
then the code generation may abort or the generated code
may be incorrect.
A top level operation of a condition expression is the last
operation that will
be executed and deliver the result.
Workaround: - Disable the Code Generator option
HandleUnscaledStateflowExpressionsWithTlType
-- OR -- introduce an auxiliary variable for the none relational, logical
or bitwise
sub operation.
Furthermore in some cases the bitwise operation can be
replaced by a logical
operation.
394 / 1260
ID:
KPR.2010.09.20.003
Title:
Wrong scaling and simulation mode for SIL/PIL simulation

loaded from MAT file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A SIL or PIL simulation loaded from a MAT file via TargetLink
Main Dialog
Simulation tab is wrongly shown as a MIL simulation. If this
simulation is
plotted, the unscaled integer values which are used internally
by the generated
code are displayed as real world values. These problem does
not come up if the
SIL/PIL simulation is loaded from file after a SIL/PIL simulation
has been
performed for the same opened model and Data Dictionary.
patches:
TargetLink 3.1p4
395 / 1260
ID:
KPR.2010.09.20.004
Title:
Incorrect code for bitwise operation with operation as operand

in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow a bitwise operation (~, &, |, ^) is specified

-- AND -- the Code Generator option
HandleUnscaledStateflowExpressionsWithTlType is
enabled
-- AND -- at least one of the operands of the bitwise operation is
another operation
-- AND -- the other operand is not a variable/macro
-- AND -- the whole expression contains at least one operand that has
a different
Stateflow than TargetLink type
-- AND -- none of the operands of the whole expression has a scaling,
i.e. no operand
has LSB != 1.0 and/or Offset != 0.0,
then the generated code might contain casts to an 8-bit type
which may be wrong.
HandleUnscaledStateflowExpressionsWithTlType
-- OR -- introduce an auxiliary variable for the sub operation.
396 / 1260
ID:
KPR.2010.09.20.005
Title:
No warning/error message is issued about inconsistent bus

structure in TargetLink Bus port blocks if logging is not
activated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If the specified bus structure of a TargetLink Bus port block

does not match the
connected bus signal, the following warning shall appear:
"Warning #02229: <block path>:
The current bus structure does not match the TargetLink block
data of '<block
path>'. Therefore all MIL capabilities (logging and overflow
detection) are
disabled for this block."
But if a Bus port block has not signal to be logged, the
warning will not
appear. The bus inconsistency is detected only by TargetLink
Code Generator.
Workaround: Perform a "rescan bus hierachy" in the Bus port block.
397 / 1260
ID:
KPR.2010.09.20.006
Title:
Incorrect code for product with unsignd type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a multiplication is specified, for example, in a Product block

and the
product
- has an unsigned 8-bit (UInt8) or 16-bit (UInt16) type
-- AND -- both factors (inputs) are of signed type
-- AND -- the variable that receives the product can be replaced
-- AND -- the code generation target is a 32-bit platform,
then the resulting code gives wrong results, if both factors
have small negative
values (like -3 and -7).
Example:
UInt16 out;
Int16 in1;
Int16 in2;
out = in1 * in2;
out = ((UInt16) in1 * (UInt16) in2);
If the variable out is replaced and the right hand side
expression is propagated
to a relational operation the resulting code could be
((UInt16) in1 * (UInt16) in2) > 1
This expression gives wrong results on a 32-bit platform for
small negative
inputs like (in1 = -3 and in2 = -5).
Workaround: Make sure that the product does not have a variable with
variable class'
property Optimization set to "ERASABLE".
patches:
TargetLink 2.3.1p7
TargetLink 3.1p5
TargetLink 3.2p1
398 / 1260
ID:
KPR.2010.10.08.001
Title:
Selection of many Subsystems in Main Dialog leads to

unexpected results

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If a model has a lot of TargetLink subsystems, all these

subsystems are shown in
the TargetLink Main Dialog.
- Selecting all subsystems using <shift> + mouse will spend a
lot of time.
Therefore each mouse click just after the selection might
result in unexpected
behaviour, e.g. switch fom SIL to MIL results in SIL is activ
and open a
subsystem will crash MATLAB.
- Selecting a few subsystems using <shift> and arrow keys will
result in
randomize selecting and deselecting the subsystems.
Workaround: Before applying any action after selection wait about 0.2 *
(number of selected
subsystems)^2 seconds.
ID:
KPR.2010.11.12.001
Title:
Using same data store name for several data store systems
results in problems during MIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
399 / 1260
Description: If more than one data store systems (a set of corresponding

Data Store Read,
Data Store Write and Data Store Memory blocks) use the
same data store name, it
is possible, that Data Store Read blocks use TargetLink
properties of a wrong
Data Store Memory block during MIL simulation.
This may result in following problems:
If the width of affected Data Store Memory blocks is different,
the following
error message may be issued:
*** E02291: SCALING DATA/SIGNAL SIZE MISMATCH:
*** A scaling data/signal size mismatch in block '<Data Store
Read
block>' has been detected.
*** The block property '<property>' is a (<n>,1)-vector, but the
compiled signal size is (<m>,1).
In this case, the simulation aborts.
If the scaling of affected Data Store Memory block is different,
following may
occur:
- wrong overflow warnings
- missing overflow warnings
- wrong constraint lines in signal plots
Simulation results and generated code are not affected.
Workaround: There are two alternatives to avoid the problem:
1) Avoid using same data store names for different data store
systems
2) If it is not possible to use different data store names (e.g.
because using
libraries), the affected Data Store Read blocks must be
excluded from MIL
simulation overflow detection and logging by using the black
list. This can be
done in following way (if all Data Store Read blocks are
affected):
Typoe following commands in the MATLAB command window
(replace <model> by the
model name in quotation marks)
>> hDSRBlocks = tl_get_blocks(<model>,
'TL_DataStoreRead')
>> for n=1:numel(hDSRBlocks),tl_create_blacklist('add',
<model>, 'block',
hDSRBlocks(n));end
The blacklist file must be removed and created again after
model modifications.
patches:
TargetLink 3.1p5
TargetLink 3.2p1
400 / 1260
ID:
KPR.2010.11.22.001
Title:
SWC model generator aborts for multiple runnables that

access identical data elements or interrunnable variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If SWC model generator is used to generate an AUTOSAR

frame model the model
generator may abort if the following conditions are met:
- A SWC omponent to be modeled contains multiple runnables
-- AND -- multiple runnables write data to identical data elements or
interrunnable
variables
-- AND -- within at least one runnable setter operations are to be
modeled
-- AND -- the SWC model generator is called with enabled option
ForceClientPortUsage
?? Error using ==> add_line
Invalid Simulink object specifier.
Error in ==> tl_generate_swc_model>FcnPlaceMergeBlocks
at 2008
add_line(subsystemFullName,
runOutputConnectionList(idx).connectionPort,
...
Workaround: Call the SWC model generator with disabled option
ForceClientPortUsage.
patches:
TargetLink 3.1p4
401 / 1260
ID:
KPR.2010.11.22.002
Title:
AUTOSAR AdminData in Data Dictionary leads to error during

SIL/PIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: AUTOSAR AdminData object in the Data Dictionary below a

Typedef or Variable
struct object leads to error during SIL/PIL simulation.
E08166 SYMBOL ADDRESS DETERMINATION
An internal error occurred. Please contact dSPACE technical
support. error: 8166
During a SIL/PIL simulation the offset address of the elements
of a structure
are calculated. If there are AUTOSAR AdminData object
below the structure an
error occurs.
patches:
TargetLink 3.1p4
ID:
KPR.2010.11.22.003
Title:
The SWC model generator does not correctly connect

outports of the subsystem representing a server runnable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the SWC model generator is called with enabled option

ModelClientServerPort
the operation argument outports of the subsystem
representing a server runnable
must be combined to one bus signal corresponding to the
modeled operation by
means of the Bus Creator block. However the SWC model
generator uses the Merge
block instead.
Workaround: Before staring with the modeling of the server runnable's
functionality replace
the Merge block with the Bus Creator block manually.
402 / 1260
ID:
KPR.2010.11.22.004
Title:
Incorrect code for call-by-reference input of custom look-up

function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a custom look-up function has an input signal whose

variable class defines
the driving signal to be a call-by-reference parameter of the
surrounding
function and in the call of the look-up function that input is
used as actual
parameter of an call-by-value parameter, then the generated
code can be wrong,
because it might miss a derefence of the input or, if inlined, a
superfluous
reference operator.
Example:
Assume an TargetLink InPort block preceeds a look-up block
using a custom
look-up function script and the variable class of the InPort
specifies it to be
FCN_REF_ARG and the look-up function call is specified to
be
out = MyFcn(table, in1)
then the generated code might be
Sa1_TableOut = MyFcn(&Sa1_TableVar[0][0], Sa1_InputVar);
although the input var is specified to be FCN_REF_ARG
which means that it is a
pointer and although the second parameter of the custom
look-up function is
specified to be a call-by-value parameter.
The generated call shall be
Sa1_TableOut = MyFcn(&Sa1_TableVar[0][0],
*Sa1_InputVar);
Workaround: Avoid call-by-reference inputs for custom look-up functions.
403 / 1260
ID:
KPR.2010.11.22.005
Title:
Limitation of code identifiers to 31 characters may result in

simulation differences and may cause errors during
AUTOSAR export

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If for an AUTOSAR model the Main Dialog option "Code

identifiers max. 31 chars"
(codeopt.limidentlength) is selected and if there are two or
more data elements
or client-server operation or CalPrm elements with similiar
names associated
with the same runnable then SIL simulation may differ from
MIL simulation.
Furthermore AUTOSAR export may fail with error message
8773.
In the situation above SIL simulation may only differ from MIL
simulation if the
subsystem modeling such runnable is either triggered via a
function call from
outside of the TargetLink subsystem or is a TargetLink
subsystem.
Workaround: Set the option "Code identifiers max. 31 chars"
(codeopr.limidentlength) to
"off", or choose different names for affected data elements,
operations or
CalPrm elements.
patches:
TargetLink 3.1p5
404 / 1260
ID:
KPR.2010.11.22.006
Title:
Generating code for Custom Code block with additional code

files fails with referenced models

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Additional code files (*.c or *.h) can be added to custom code
by inserting a
TargetLink Addfile block for each file into the subsystem
where the Custom Code
block resides. However, if *.c files (as opposed to *.h files) are
added to the
custom code, RTW code generation results in linker errors.
This happens, for
example, when the Custom Code blocks reside in a
referenced model for which the
RTW should generate an S-function. Then, the model cannot
be initialized, and
neither MIL/SIL/PIL simulation nor code generation are
possible.
Workaround: Edit the generated TLC file and add an entry
%<LibAddToModelSources({myfile})>
to the BlockTypeSetup function for each file, where {myfile}
has to be replaces
by the module name of the *.c file
Example for file "table.c":
...
%function BlockTypeSetup(block, system) void
%<LibAddToModelSources("table")>
%openfile buffer
#include "tmwtypes.h"
...
Note the missing .c file extension.
405 / 1260
ID:
KPR.2010.11.22.007
Title:
Possibly missing initialization in the generated code when

merging extern variable with non-extern variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Two different variables are specified in a code generation unit.

Both variables
have identical properties except for their variable classes. The
variable
classes differ in the following properties: one has Storage =
"extern", while
the other one the Storage = "default". Additionally, one
variable class has
property InitAtDefinition set to "on", while the other one's
property is "off".
In this case TargetLink should follow the setting of the nonextern variable
class, but due to an implementation mistake the setting of the
extern variable
class might be used instead. This means the variable in the
generated code may
be not initialized which may also lead to wrong simulation
results. Regardless
of initialization, in some cases warning #17001 is issued
stating that one of
the two variables is not initialized.
The problem depends on TargetLink's internal behavior and is
not directly
predictable on model level.
Workaround: Use the same variable class with Optimization property
MERGEABLE for both
variables. Then it is assured that the InitAtDefinition properties
have the same
setting.
406 / 1260
ID:
KPR.2010.11.22.008
Title:
"Error due to multiple causes" message during model

initialization

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In Matlab 2009b and higher following error occurs while

initializing a model for
the production code generation:
Error #01225:
Error due to multiple causes.
-- OR -Error #90105:
message below
Error using ==> tl_get_compiled_data at 508
Error due to multiple causes.
But the "multiple causes" are not named.
Workaround: To get the reasons for the "Error due to multiple causes."
message either try to
initialize the model by manual update diagram (CTRL-D) or
invoke these following
commands in MATLAB command Window:
>> eval(['<modelName>' '([],[],[],''compile'');'])
>> eval(['<modelName>' '([],[],[],''term'');'])
where <modelName> has to be replaced by the model name.
patches:
TargetLink 3.1p5
TargetLink 3.2p1
407 / 1260
ID:
KPR.2010.11.22.009
Title:
Real-time simulation of TargetLink production code embedded

in real-time application with multiple tasks may work
incorrectly

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The real-time simulation on the dSPACE processor board may

work incorrectly or
aborts if the following conditions are met:
- A stand-alone S-function has been generated for the
-- AND -- a real-time application for dSPACE DS1005, DS1103,
DS1104 or DS1401 processor
board has been built based on the model containing this
stand-alone S-function
-- AND -- the real-time application is partitioned in mulitple tasks.
The incorrect behaviour is caused by the usage of the not
interrupt proteced
malloc() command within the stand-alone S-function frame.
patches:
TargetLink 3.1p4
408 / 1260
ID:
KPR.2010.11.22.010
Title:
Autoscaling based on user range is wrong for Stateflow inputs

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The key problem is the semantic of the values given as user
range (min/max).
For Simulink blocks this property has the following semantic:
The user garantees that a value is within the given range
For Stateflow data the semantic depends on the saturation
flags:
- If saturation flag is disabled for min and/or max:
The user garantees that the value is within the given min
and/or max
- If saturation flag is enabled for min and/or max:
Code Generator garantees that the value will allways be within
the given min
and/or max (by inserting saturation commands)
Currently the autoscaling based on min/max assumes allways
the semantic with the
user garantee. For Stateflow output data this semantic
exception seems to be no
problem, because it is irrelevant for the following block who
garantees the
range, the user or the Code Generator with satuaration.
For Stateflow inputs this is defintly a serious problem. The
min/max of Inputs
may be propagated backwards to preceding blocks during the
autoscaling. But if
saturation is active the only thing which is sure that after the
Stateflow input
the value is inside min/max range because of the saturation.
But the driving
signal at that Stateflow input can be outside that range. Such
a backward
propagation is currently done and the resulting autoscaled
blocks in front of
Stateflow charts are very likely insufficient scaled leading to
over/underflows.
Workaround: Scale a Stateflow chart manually and additional exclude them
from autoscaling.
409 / 1260
ID:
KPR.2010.11.22.011
Title:
Abnormal termination during MIL simulation with error

message "E-0080: INTERNAL ERROR" if model contains
vectorized AUTOSAR port blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The MIL simulation aborts with error message

*** E-0080: INTERNAL ERROR:
*** Internal Error - Please call dSpace support:
*** TLDS error: Width of scaling property 'arb' is not compliant
to at
least one other scaling property.
After this message appeared, MATLAB terminates abnormal.
This problem come up for models containing TargetLink port
blocks within AUTOSAR
systems (e.g. Runnables) if following conditions are met:
- A Data Dictionary DataElement object referenced by an
AUTOSAR port block has a
Width > 1
-- AND -- A Data Dictionary Scaling object referenced by this
DataElement object
contains a scalar LSB property.
The problem comes up for Scaling objects referenced directly
by the DataElement
object as well as for Scaling objects referenced indirectly by
constraints of
referenced Typedef object.
Workaround: Ensure, that property LSB of the Scaling object referenced by
the DataElement
object has the same width as the DataElement object.
Example:
DataELement object Width is 4. In this case, the LSB of the
referenced Scaling
object must be e.g. [2^-5 2^-5 2^-5 2^-5] and not 2^-5.
patches:
TargetLink 3.1p5
410 / 1260
ID:
KPR.2010.11.22.012
Title:
Model preparation or system synchronization aborts with

Multiport Switch block with only one data port

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Following use case is given:

- a Mutiport Switch block with only one data port resides in a
system
(subsystem, model or library)
- the system is prepared for TargetLink, or TargetLink data are
synchronized
with Simulink data
- the option Map output scaling data / Sync output scaling data
is enabled
In this case preparing/sync'ing the system aborts with an error
message like the
following:
Error in ==>
tl_map_output_scaling>FcnInheritanceShouldBeSet at 388
bSetInheritance =
all(isequal(bs.compiledBlockDataTypes(idx).Inport{:}));
.....
The system is only partially prepared or sync'ed after this
abort.
Workaround: - Disable the option Map output scaling data / Sync output
scaling data
-- OR -- redesign the system to have Multiport Switch blocks with > 1
data ports.
411 / 1260
ID:
KPR.2010.11.22.013
Title:
Incorrect code for Multirate system cause sample time's

counter variable is calculated in control flow branch only

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For a TargetLink model multirate code generation is enabled.

The model contains
a subsystem that is placed inside another subsystem. Both
subsystems are not
placed directly or indirectly inside a subsystem that is enabled.
For the inner
subsystem a sample time is specified that is different from the
sample time of
its parent system. The inner subsystem's outports does drive
directly or
indirectly
- exclusively one data inport of a Switch block
-- OR -- exclusivley one data inport of a Multiport Switch block
-- OR -- exclusively inports of an enabled subsystem
-- OR -- exclusively inports of an action triggered subsystem.
Additionally, the Code Generator option
EnableBlockDiagramBasedSwitchOptimization is activated.
In this case the generated code might be incorrect, because
the inner
subsystem's code might be placed into a control flow branch,
because the sample
time's counter variable is calculated only in this control flow
branch.
- Place a Function block in the inner subsystem. Specify a
function class that
does not have Optimization property MOVABLE set for the
step function.
-- OR -- Disable the Code Generator option
EnableBlockDiagramSwitchOptimization.
-- OR -- Set the optimization level to 0 (zero).
ID:
KPR.2010.11.22.014
Title:
Wrong treatment of AUTOSAR operation calls with respect to

interface variable information

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
412 / 1260
Description: The Code Generator can only treat a function or macro call
correctly during
optimization if it knows the contents or is given information
about the contents
of the function (or macro).
For RTE API functions and macros, the Code Generator
usually knows the desired
behavior with the exception of operation calls: Only if the
Code Generator also
generates a server runnable implementing the operation, the
contents can be
assumed to be known.
The Code Generator erroneously assumes trivial semantics
for the operations and
optimizes accordingly if inputs or outputs to runnables are
obtained / set via
operation call or if the contents of an operation call subsystem
are only to be
used for SIL/PIL simulation.
This means that calls to Rte_Call_...() are moved into
control flow branches even if they have side effects and that
they can be moved
past other RTE API calls even though they influence the result
of these calls.
Note that calls to implicit reading RTE API functions can never
change their
outcome, so they can be moved past any other function or
macro call.
Workaround: In order to find out whether you experience this optimization
problem, you can
set the Code Generator option OptimizationLevel = 0 before
code generation; if
the generated code then performs as intended, the following
local workarounds
can be applied in order to make it possible to switch back to
OptimizationLevel
> 0.
Mobility of the call to Rte_Call_...() can be restricted by
inserting a Rescaler
block after at least one output of the call. The block has
"Inherit signal
properties" enabled and a block output variable with a variable
class that has
unset ERASABLE and MOVABLE Optimization properties. For
ease of use, the class
can be given Scope = global and set SCOPE_REDUCIBLE
Restricted mobility past the call can only be realized by
identifying critical
blocks and making their block output variables nonERASABLE and non-MOVABLE (or
inserting a Rescaler block as described above).
413 / 1260
ID:
KPR.2010.11.24.001
Title:
Code generation aborts with an access violation if a file name

is given in the AddFile block and the extension is not "c" or "h"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An access violation occures during code generation if the

are met:
- the property "Code File" at the AddFile block is set
-- AND -- the extension of the file is != c, if option "Compile & Link" is
enabled or
the extension of the file is != h, if option "Include in generated
file" is
enabled
Workaround: Use a Module object and the corresponding FileSpecification
objects to spedify
the name and the extension of the file.
ID:
KPR.2010.11.24.002
Title:
Tangent function of Trigonometric Function block with rough

output scaling yields wrong results

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The tangent function yields to wrong results if the following

conditions are met
for the Trigonometric Function block:
- output data type is at most 16 bit
- data type of the opration argument is 16 bit
- output LSB is a power-of-two and greater than 1
Workaround: Arbitrary scaling works exept from values, that can be
represented in power of
two scaling.
414 / 1260
ID:
KPR.2010.11.24.003
Title:
The Data Dictionary Manager Stand-Alone aborts when the

toolbar button "Open CodeEditor" is pressed

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If the Data Dictionary Manager is started from the start menu
outside from
MATLAB and the toolbar button with the symbol "C" (code
editor) is pressed the
application aborts due to memory access violation.
When started from MATLAB the Data Dictionary Manager
shows an error message
"Plugin Action failed / E1: File Information not found" if no
code file was
found for the current node but this is not an issue.
Workaround: Avoid pressing the Code Editor toolbar button when Data
Dictionary Manager is
not started from within MATLAB.
415 / 1260
ID:
KPR.2010.11.24.004
Title:
Unconnected port warnings after build SIL/PIL

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: After two consecutive SIL/PIL builds, starting a SIL/PIL

simulation results in
Simulink warnings similar to:
Warning: Input port 1 of
'pipt1/picontroller/Subsystem/SameDT1' is not
connected.
> In tl_sim at 321
In C:\Program Files (x86)\dSPACE TargetLink
3.2\Matlab\Tl\dlg\dstabdlg.p>FcnManageSystemButtons at
1086
In C:\Program Files (x86)\dSPACE TargetLink
3.2\Matlab\Tl\dlg\dstabdlg.p>dstabdlg at 156
Warning: Input port 2 of
'pipt1/picontroller/Subsystem/SameDT1' is not
connected.
The warnings appear only with MAtlab R2010a and later.
Workaround: The warnings can safely been ignored. They no longer appear
if the TargetLink
subsystem is switched to MIL and back to SIL/PIL before
starting a SIL/PIL
simulation.
patches:
TargetLink 3.2p1
416 / 1260
ID:
KPR.2010.11.29.001
Title:
SIL/PIL simulation frame cannot be initialized with labelled

input signal

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation

- a signal with a propagated label runs into a TargetLink
subsystem
- inside the subsystem, this signal is fed into a Bus Creator
- the signal from the Bus Creator is fed into a Bus Selector
which selects the
signal by said label
In this use case, SIL/PIL simulation results in an error
message similar with
Selected signal 'aaaa' in the Bus Selector block
'testModel/Subsystem/Subsystem/Subsystem/Bus Selector'
cannot be found in the
input bus signal.
Workaround: Define the name of the TargetLink subsystem input signal
explicitly with the
signal's Signal Properties dialog.
patches:
TargetLink 3.3p3
417 / 1260
ID:
KPR.2010.11.29.002
Title:
No error messages when code is generated for system with

matrix signals

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink does not support matrix signals. Attempts to

prepare a system (model
or subsystem) which contains matrix signals for TargetLink
result in error
message(s) #3061. However, no error message is issued
when the code generator is
invoked on a system that is already prepared for TargetLink,
and contains matrix
signals. This is only possible when the model has been
modified after
peparation, or has been built from scratch. Code generation
will proceed without
errors, but the generated code is false, and model initialization
in SIL/PIL
simulation modes fails.
Workaround: Do not alter a prepared system to introduce matrix signals.
Use the Invalid
Blocks tool on the TargetLink Main Dialog Tools tab to detect
matrix signals.
patches:
TargetLink 3.2p1
418 / 1260
ID:
KPR.2010.11.29.003
Title:
Port blocks in library are not re-enhanced

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: A TargetLink-compliant Simulink library contains port blocks that are enhanced
for TargetLink. The library is cleared from TargetLink with the "Keep TL data
for re-preparation" option enabled. Afterwards, the library is re-prepared for
TargeLink with the "Restore saved TargetLink block data" option enabled. This
means that data saved during clearing the library are restored, and ports that
had been enhanced are re-enhanced with the saved block data. However, Simulink
ports remain un-enhanced and their block data are thus lost.
Workaround: A pre preparation hook function fixes the problem. Code:
if strcmpi(get_param(bdroot(hSubSystem),'BlockDiagramType'),'Library')
hSavedDataPorts = [ ...
find_system(hSubSystem,'LookUnderMasks','on','RegExp','on','BlockType','Inport',
'tag','{.*')
find_system(hSubSystem,'LookUnderMasks','on','RegExp','on','BlockType','Outport'
,'tag','{.*')];
m = tl_enhance_block(hSavedDataPorts,struct('bRestoreTLData',1));
ds_error_register(m);
end
TargetLink 3.2p1
ID:
KPR.2010.11.29.004
Title:
Incorrect block execution order in conjunction with Merge

blocks between triggered subsystems

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
419 / 1260
Description: In some cases the block execution order determined by

TargetLink is incorrect.
The error described in this publication depends on the
following necessary
conditions:
- Two Function-Call Subsystems A and B are triggered by the
same source.
- There exists a data connection from A to B.
- The data connection contains only blocks with direct feedthrough (i.e. no
Unit Delays or similar).
- The data connection branches off to another block C.
+-------+
| |>---------------------------------------------+
| |>-----+ |
+-------+ | |
Trigger | |
+-------v------+ +---+ +--------v--------+
| f() |>------>| |>---+---->| f() |>-------- ...
+--------------+ +---->| | | +-----------------+
A | +---+ | B
| Merge | +---+
| +----------->| |>--------------- ...
: +---+
C
As the execution order of the two subsystems is completely
determined by the
function-call source, the data connection is disregarded when
the execution
order is determined. As an unwanted side effect, the
dependency between the
first subsystem A and the block C is lost as well, which can in
some cases lead
to generated code in which the block code for C is scheduled
before the code for
A.
Additional notes:
- This problem applies to Stateflow Charts with input events of
type function
and Counter Alarm blocks, as well.
- A and B may be the same subsystem with a feed-back loop
containing the Merge
block.
- This problem is not specific to the Merge block, the Merge
block just happens
to be the only nonvirtual block allowed in this place. Other
blocks cause data
dependency errors at model initialization time.
420 / 1260
Workaround: If only one of the subsystems is triggered in the same time

step, the Merge
block acts as a unit delay, because the value written in one
time step is only
read in the next time step. Then it may be sensible to insert an
additional Unit
Delay block to "break" the data connection. In order to prevent
performance
degradation due to additional assignments, it is advisable to
use the same
variable for the Merge output and the Unit Delay state, using a
variable class
with the MERGEABLE attribute (see Advanced Practices
Guide > Configuring
TargetLink and Adapting Code to Company Coding Styles >
Example of Merging
Multiple Declarations of Variables.)
+---+ +---+
from A --->| |>---+-->|1/z|---> to B
--->| | | +---+
+---+ |
Merge +--> to C
In the general case, there is no known work-around.
patches:
TargetLink 3.2p3
421 / 1260
ID:
KPR.2010.11.29.005
Title:
Stateflow chart missing in generated documentation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: TargetLink does not document all Stateflow charts contained

in multiple
TargetLink subsystems, incremental subsystems and
referenced models selected for
documentation. In the generated HTML documentation for all
the Stateflow charts
links are added, but only the last one points to an existing
chapter.
Workaround: Generate documentation for each system containing a
Stateflow chart separately.
By default, if tldoc_default, tldoc_rtf or tldoc_pdf script is used,
all
TargetLink subsystems, incremental subsystems and
referenced model contained in
the model are documented. To document one specified
system change the property
'TLSubsystems' of the tldoc funktion 'TargetLink Code
Generation Units' in the
script used for the documentation generation. To avoid
overwritting of the
generated documentation files, make sure that for each
system an unique
documentation file name is specified, too.
patches:
TargetLink 2.3.1p6
422 / 1260
ID:
KPR.2010.11.29.006
Title:
Missing saturation for graphical function inputs in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink will not generate saturation code for an input

parameter of a
Stateflow graphical function. The settings "Saturate against
overflow",
"Saturate against underflow" are ignored. Arguments of
graphical functions are
always passed as if no saturation was specified, which can
lead to wrong results
if argument values fall outside the limits of the parameter
range.
Workaround: Use an auxiliary intermediate variable of the same type as the
parameter and
specify saturation for that variable.
Example:
/* instead of y = fcn(x+1); */
temp = x + 1;
y = fcn(temp);
423 / 1260
ID:
KPR.2010.11.30.001
Title:
Extracting a referenced model with bus port blocks aborts with

Simulink error message "??? Reference to non-existent field
'Name'."

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The extraction of a referenced model with a BusInport or

BusOutport block by
means of the tl_extract_subsystem function aborts. The
following Simulink error
messages appear:
??? Reference to non-existent field 'Name'.
Error in ==> tl_extract_subsystem>FcnEmbedInSubsystem at
1299
FcnAddLine(objSubsys.getFullName, objTlInport(m).Name, 1,
objBlock.Name, m);
Error in ==> tl_extract_subsystem at 402
[hDestBlock, ok] = FcnEmbedInSubsystem(hDestBlock, ...
The API function tl_distribute_refmodel_files is affected by this
problem if its
parameter 'CreateDevFrame' is 'on'.
Since TargetLink 3.1, this API function is called, if a
referenced model is
selected in the 'Code generation units' area of the TargetLink
Main Dialog's
Code Generation tab and the context menu command
"Distribute files" is
performed.
In TargetLink 3.0.1, tl_distribute_refmodel_files is called from
the Model
Referencing Control Center dialog, if the button "Distribute
Files" is pressed.
patches:
TargetLink 3.2p1
ID:
KPR.2010.11.30.002
Title:
Vector element update code for passing function arguments

by address leads to incorrect code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a vector has READ_INDEX, WRITE_INDEX or ADDRESS

access functions and if its
424 / 1260
elements are passed by address to a function, then

TargetLink erroneously passes
the whole vector rather than the element addresses. This
means, that effectively
only the address of the first element is passed.
For function outputs, this constellation with WRITE_INDEX
access functions also
may be affected by KPR.2009.12.17.009 in which case the
code does not compile.
Example:
Consider an iterated system containing a call to f() where the
elements of "A"
are provided by a dynamic Selector block and where the
output is assembled into
a vector via an Assignment block with "Omit dispensable
initializations".
Without access functions, the following code is generated:
for (Sa2_loop_it = 0; Sa2_loop_it <= 16; Sa2_loop_it++)
{
f(&(A[Sa2_loop_it]), &I, &(D[Sa2_loop_it]));
}
Expected code with READ_INDEX or WRITE_INDEX access
functions:
{
_tmpu_A = GetAIndexed(Sa2_loop_it);
f(&_tmpu_A, I, &_tmpd_D);
SetDIndexed(Sa2_loop_it, _tmpd_D);
}
Actual (incorrect) code:
{
for (Aux__a = 0; Aux__a < 17; Aux__a++)
{
_tmpu_A[Aux__a] = GetAIndexed(Aux__a);
}
f(_tmpu_A, I, &_tmpd_D);
SetDIndexed(0, _tmpd_D); /* KPR.2009.12.17.009 */
}
Expected code with ADDRESS access functions:
{
f(&(RetrieveA()[Sa2_loop_it]), I, &(RetrieveD()[Sa2_loop_it]));
}
Actual (incorrect) code:
{
f(RetrieveA(), I, RetrieveD());
}
For TargetLink versions prior to 2.3, no efficient vector
handling was
available, the generated code for READ_INDEX or
WRITE_INDEX access functions
looks like this:
for (Sa2_For_Iterator_it = 0; Sa2_For_Iterator_it <= 4;
(Sa2_For_Iterator_it)++)
{
425 / 1260
/* SLLocal: Default storage class for local variables | Width: 16

*/
Int16 _tmp_A[5] /* LSB: 2^0 OFF: 0 MIN/MAX: -32768 ..
32767 */;
_tmp_A[0] = GetAIndexed(0);
/* call of function: AfBug/For Iterator Subsystem/Foo */
Foo(_tmp_A, &(Assignment[Sa2_For_Iterator_it]));
As the Assignment block's block output variable cannot be
eliminated, the
problem only affects the input.
Workaround: Use a Rescaler block - or, prior to TargetLink 3.0, a
TargetLink port block or
Gain block with gain factor 1 - with a variable class that has
the ERASABLE
Optimization property not set in front of a read access or after
a write access.
This leads to an additional copying process and correct code.
426 / 1260
ID:
KPR.2010.11.30.003
Title:
Wrong code for constants in preprocessor expressions

outside the range of long integer

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Constants in preprocessor expressions which values are

outside the range of long
int [-2^31, 2^31-1] are not correctly handled by TargetLink.
Instead of an error
message, TargetLink generates incorrect code:
With TargetLink 2.3 and above
- constants which exceed the upper limit of long integer are
represented as long
max (2^31-1) in the generated code
- constants which exceed the (lower limit - 1) of long integer
are represented
as - long max (-2^31-1) in the generated code
- constants with the lower limit of long integer are represented
as - long max
(-2^31-1) in the generated code
With TargetLink below 2.3
- constants which exceed the (upper limit + 1) of long integer
are represented
as - long max (-2^31-1) in the generated code
- constants with (upper limit + 1) of long int are represented as
long min
(-2^31) in the generated code
- constants which exceed the lower limit of long int are
represented as long max
(2^31-1) in the generated code
The precondition that wrong code is generated is, that for the
macros used in
the preprocessor expression and specified via a Constant
block for the type in
the Constant block a 32-bit type is specified, e.g. Int32 or
UInt32
ID:
KPR.2010.11.30.004
Title:
Potentially wrong optimization of custom code or function call

in For Iterator subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: To implement efficient vector code TargetLink generates forloops for blocks
427 / 1260
with vector signals and combines them where possible.

Example:
Two Gain blocks with a signal size of 5
Instead of
Sa1_Gain[0] = Sa1_In[0];
...
Sa1_Gain2[0] = Sa1_Gain[0];
...
TargetLink creates
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
Sa1_Gain[Aux_S32] = Sa1_In[Aux_S32];
}
{
Sa1_Gain2[Aux_S32] = Sa1_Gain[Aux_S32];
}
and combines these loops if possible to
{
}
There are two different scenarios to take into account:
1. Custom Code block
- A Custom Code block resides in a For Iterator subsystem
which has an certain
iteration limit
-- AND -- an input or an output of the For Iterator subsystem has a
signal width which
is equal to the iteration limit
-- AND -- the Custom Code block is connected to one of these inputs
or outputs
Then the loops generated for efficient vector handling of the
predecessor of the
input or the successor of the output might be merged with the
loop around the
Custom Code resulting from the For Iterator subsystem.
Depending on the Custom
Code this can render undesired results.
2. Subsystem that results in a function
- An atomic subsystem or a subsystem with Function block
resides in a For
Iterator subsystem which has an certain iteration limit
-- AND -- an input or an output of the For Iterator subsystem has a
signal width which
is equal to the iteration limit
-- AND -428 / 1260
- the atomic subsystem or subsystem with Function block

reads or writes global
variables, e.g. as input or output, and is connected to one of
the For-Iterator
inputs or outputs.
Then the loops generated for efficient vector handling of the
predecessor of the
input or the successor of the output might be merged with the
loop around the
function call resulting from the For Iterator subsystem.
Depending on the
implementation of the function this can render undesired
results.
Example:
A For Iterator subsystem contains a Custom Code block, has
one input, one output
and an Iteration limit of 16.
If the signal width of the For Iterator subsystem input is 16,
then the not
optimized code would be
for (Aux_S32 = 0; Aux_S32 < 16; Aux_S32++)
{
ForIteratorSubsystemIn[Aux_S32] =
ForIteratorPredecessor[Aux_S32];
}
{
/* Custom code: .... */
{
... /* some custom code */
}
}
This might be optimized to a single loop
{
ForIteratorSubsystemIn[Aux_S32] =
ForIteratorPredecessor[Aux_S32];
/* Custom code: .... */
{
... /* some custom code */
}
}
which can be wrong depending on the custom code.
It would be wrong, for example, if the custom code adds some
signals of the
inputs like
CustomCodeOut = ForIteratorSubsystemIn[10] +
ForIteratorSubsystemIn[11];
because the inputs have not yet been calculated for all
iteration steps of the
surrounding loop.
429 / 1260
Workaround: - Disable Code Generator option EfficientVectorHandling.

-- OR -- Specify one of the concerned loops to be generated in a
separate function (use
TargetLink Function block).
-- OR -- To avoid problems with function calls (scenario 2), do not
use global
variables in the interface of functions in For Iterator
subsystems.
ID:
KPR.2010.11.30.005
Title:
Autoscaling based on logged ranges may be wrong because

of logging limitations

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Mostly a signal, for example a block output is only calculated

once during one
simulation step. In the Simulink area there are only a few
exceptions: block in
For Iterator subsystem, block in Function called systems.
In Stateflow instead it is often the case that a data is changed
more than once
during one simulation step. Due to logging restriction only the
last value is
registered. So only some values, the last one in each
simulation step, of the
blocks/Stateflow data are taken into account for the simulated
min/max. But the
autoscaling based on logging ranges bases on this unsafe
und incomplete
information and the changed scaling settings are likely to be
wrong and leading
to overflows (wrong SIL/PIL simulation).
Workaround: Vary headroom settings to make sure, that the calculated
scaling includes all
simulated values.
430 / 1260
ID:
KPR.2010.12.01.001
Title:
Incorrect code for saturated assignment with a constant on the

right hand side and variables as saturation limits

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink may generate incorrect code if

- the right hand side of a saturated assignment is a constant
value
--AND-- at least one saturation limit is not constant (e.g. has a
variable class !=
default and/or a variable class where the CONST property is
not set).
These conditions hold if a Constant block with default variable
class leads into
a Saturation block. If the saturation limits of the Saturation
block have a
variable class != default which has no CONST property set,
the generated code
may be incorrect.
Workaround: Force that the constant of the Constant block is represented
by a variable by
referring a variable class != default. Use for example
OPT_LOCAL to obtain
correct code and allow optimization to eliminate the variable
and using the
correct constant value.
ID:
KPR.2010.12.01.002
Title:
TargetLink ignores initial values specified via a

SenderComSpec block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If for the output of a function-call triggered runnable sender

receiver
communication is specified and for the data element used at
the outport an
initial value is specified via a SenderComSpec block, this
value is ignored by
TargetLink. This may lead to unexpected simulation behavior.
Workaround: Set the initial value specified via the SenderComSpec block
explicitly at the
outport of the function-call triggered runnable.
431 / 1260
ID:
KPR.2010.12.01.003
Title:
Duplicate inports are not detected

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink does not support duplicate inports. Duplicate

inports are Simulink
inport blocks that represent the same signal.
Code can be generated for a system (model or subsystem)
with duplicate inports,
which means that no error messages are produced although
TargetLink does not
support these blocks. The TargetLink Upgrade tool converts
the duplicate ports
in ordinary ports. Subsequent code generations result in a
code generator abort.
Workaround: Make sure there are no duplicate inports in your model.
ID:
KPR.2010.12.01.004
Title:
Incorrect optimization of AUTOSAR interrunnable variables

and per-instance memory

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Under certain circumstances TargetLink's optimization

erroneously deletes
accesses to interrunnable variables with explicit
communication mode and
accesses to per-instance memory. In these cases the RTE
API calls are
erroneously replaced by direct accesses to constants.
Workaround: Unset the "ERASABLE" Optimization property for the following
variable classes:
- AUTOSAR/INTER_RUNNABLE_VARIABLE (TargetLink 2.2
- TargetLink 3.0.1)
- AUTOSAR/DISP_INTER_RUNNABLE_VARIABLE
(TargetLink 2.3 - TargetLink 3.0.1)
- AUTOSAR/EXPLICIT_IRV (TargetLink 3.1)
- AUTOSAR/DISP_EXPLICIT_IRV (TargetLink 3.1)
- AUTOSAR/PER_INSTANCE_MEMORY (TargetLink 2.3 TargetLink 3.1)
432 / 1260
ID:
KPR.2010.12.01.005
Title:
Using component of Data Dictionary pointer-to-struct variable

in one subsystem several times may lead to missing or too
many saturation code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A struct of scope "ref_param" is specified in the Data

Dictionary. One of its
components has a variable class with Optimization property
MERGEABLE. The struct
component is referenced as output variable of several blocks
in the same
subsystem of a model. In one of these blocks saturation is
specified, while in
another one it isn't.
In this case, TargeLink does generate saturation code for
each of these blocks,
or it does not generate saturation code for any of these
blocks. The exact
result of the code generation depends on TargetLink's internal
behaviour.
Workaround: Either specify the saturation on all blocks that reference the
same variable or
assure the saturation in the driving blocks, e.g. by a Saturation
block as a
predecessor block.
433 / 1260
ID:
KPR.2010.12.02.001
Title:
Code generation aborts with fatal error #10008 for uninitialized

sub-structure pointer from a function script

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may aborts with a fatal error if following

conditions are met:
- a structure variable is specified, that has
- at least one component with an initial value and
- contains a pointer to a structure that has no destination.
Something like that can be build using a Stateflow customerspecific function or
a look-up function script.
Fatal #10008: <block path>: Internal error. Error code:
TlCVarDeclDefOperation
261. Contact dSPACE's technical support team.
Note:
The number (261) given in the error message may vary with
different versions of
TargetLink.
Workaround: Remove the pointer component from the struct (if extern and
not needed) or
specify a destination.
434 / 1260
ID:
KPR.2010.12.02.002
Title:
Code generation aborts with fatal error #10008 if parts of a

signal with variable vector width lead into a Stateflow chart or
into an atomic subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation aborts with fatal error #10008 in internal

module
TlCVariableWidthsBlockValidator if parts of a signal with
variable vector width
lead into a Stateflow chart or into an atomic subsystem. This
happens for
example if a signal with variable vector width is splitted by a
Demux or a
Selector which is going into a chart or an atomic subsystem.
Workaround: - Insert a Rescaler block or Gain block (gain value = 1) in front
of the chart
input or subsystem input.
-- OR -- For charts only: Set the 'createinputvariable' property of the
chart input to
on.
--OR-- For atomic subssytems only: Use a TargetLink Inport as
input for the signal
and not only a Simulink Inport. Enhance the port if it is a
Simulink Inport.
--OR-- Use another variable class (with Scope != global) for the
block output
variable of the block in front of the chart/subsystem.
435 / 1260
ID:
KPR.2010.12.03.001
Title:
Wrong overflow warnings for non-executed block if Simulink

configuration parameter "Conditional input branch execution"
is enabled

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: During MIL simulation wrong overflow warning message

appear for a TargetLink
block if all of the following conditions are met:
- The Simulink configuration parameter "Conditional input
branch execution" is
enabled.
-- AND -- Due to this optimization, the block is not executed during
simulation start
(e.g. because it is connected to a Switch block input port
which is disabled at
simulation start time)
-- AND -- The block scaling specifies a range which doesn't contain its
initial output
value or (if the block doesn't allow to specify the initial output
value) zero
Workaround: The following alternative workarounds are possible:
- Disable the Simulink configuration parameter "Conditional
input branch
execution"
- If it is possible to set the initial output value (e.g. the initial
condition
for a Unit Delay block), set it to a value which is within the
range specified
by its scaling
- Use a scaling which contains the initial output value
respective zero.
436 / 1260
ID:
KPR.2010.12.03.002
Title:
Upgrade of a model using libraries fails

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Following error may occur during an upgrade of a model:

*** F03217: FATAL EXCEPTION:
*** The following fatal exception occured:
*** The LinkStatus can be set only for a linked block.
*** File:
<TARGETLINK_INSTALLATION_DIR>\matlab\tl\datafcn\tl_upgrade.m
*** (Sub)Function: FcnBreakLink
This happens if the model uses a library with TargetLink blocks and
one of the
library block instances got a tag 'COPIED_DURING_UPGRADE'. You
can check this
condition by opening the <LIBRARY>.mdl file in the MATLAB Editor
and search for
the string 'COPIED_DURING_UPGRADE'.
Workaround: For a solution contact dSPACE support.
TargetLink 3.1p6
TargetLink 3.2p1
ID:
KPR.2010.12.03.003
Title:
MATLAB freezes when file type is selected in Property

Manager Export to CSV file dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The Property Manager Block Explorer can be exported into a

CSV file with the
Property Manager's File/Export as CSV file menu. However, if
another file type file extension - is selected in the associated file save dialog,
MATLAB freezes
and must be terminated with the Windows Task Manager.
Workaround: If you want to have another extension than .csv, export into a
*.csv file and
rename it afterwards.
437 / 1260
ID:
KPR.2010.12.03.005
Title:
Code generation aborts at XML validation failure when user

statement comments are activated, code generation aborts

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If user defined style of statement comments is activated in the

cconfig.xml
output style file (i.e. in the XML file <TargetLink
installation>\Matlab\Tl\config\codegen\cconfig.xml the attribute
'user-type-of-comment' of the XML element 'TL:statementcomment' has assigned an
arbitrary value except 'simple', 'fragmented' or 'prefixed'), then
code
generation aborts with fatal error 17107
Fatal #17107:
An error occurred in processing XSL: ... .
To solve this problem and make code generation succeeding
the XML validation
must be disabled.
Furthermore if user defined style of statement comments is
activated and XML
validation is disabled the name of the generated XML
elements for user statement
comments is not be given by the value of the attribute 'usertype-of-comment',
but the name is always "user-type-of-comment" (i.e.
TargetLink generates
elements like <TL:user-type-of-comment
indent="1">...</TL:user-type-of-comment>
in the XML representation of the code). Therefore a XSL
template must match with
"TL:user-type-of-comment" to process statement comments in
the XSL
transformation.
Workaround: Disable XML validation in the root element of the config XML
file:
validate-xml-against-schema="false". Use XSL templates
matching with
"TL:user-type-of-comment" to process statement comments in
the XSL
transformation (<xsl:template match="TL:user-type-ofcommen"> ...
</xsl:template>).
438 / 1260
ID:
KPR.2010.12.07.001
Title:
TargetLink creates an implicit interface variable for the outport of a

runnable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the following conditions are fulfilled TargetLink generates an implicit

interface variable for the output of a function-call triggered runnable:
- At the output of the function-call triggered runnable an initial value is
specified
-- AND -- For the output of the function-call triggered runnable interrunnable
communication is specified
-- AND -- The interrunnable variable is not directly specified at the outport of the
function-call triggered runnable but at a predecessor outport
-- AND -- For the runnable variable constraints are specified
-- AND -- The initial value specified at the outport of the function-call triggered
runnable is not covered by the constraints specified for the runnable
variable
The generation of an implicit variable is not correct. Because the initial
value
is not covered by the constraints of the interrunnable variable, is expected
that the code generation aborts with an error.
Example:
Void Runnable(Void)
{
...
Rte_IrvIWrite_Runnable_InterRunnableVariableB(InterRunnableVariableB);
/* update of variable(s) associated with
TL_SS/Runnable/InnerLogic/Runnable
Outport */
IF_Sa3_Runnable_Outport =
Rte_IrvRead_Runnable_InterRunnableVariableB();
}
In the example above the variable IF_Sa3_Runnable_Outport is the
wrongly created
implicit interface variable.
Workaround: At the outport of the function-call triggered subsystem specify an initial
value
which is covered by the constraints of the interrunnable variable.
Alternatively
adapt the constraints of the interrunnable variable.
439 / 1260
ID:
KPR.2010.12.07.002
Title:
SIL/PIL simulation fails because single-signal bus is not

detected properly

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: It has always been difficult to reliably detect buses with only
one signal. In
MATLAB R2006b and earlier, it was necessary to add a Bus
Creator block to make
sure that TargetLink treats single-signal buses as actual bus
signals. This is
not necessary with later MATLAB/Simulink versions.
However, if a single-signal bus runs into a TargetLink
subsystem in which its
signal name is needed (for example, by a Bus Creator), the
model cannot be
initialized in SIL/PIL simulation modes, but Simulink issues an
unknown signal
name error message. MIL simulation and code generation,
however, still work.
Workaround: Avoid to pass single-signal buses into TargetLink subsystems.
patches:
TargetLink 3.1p6
440 / 1260
ID:
KPR.2010.12.07.004
Title:
Code generation aborts for multiple instances of Custom Code

block with non scalar parameter

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A model cannot be simulated, nor code can be generated if

are met:
- A Targelink Custom Code block contains a parameter
-- AND -- multiple instances of that block are used
-- AND -- the "scalar" option for that parameter is disabled
-- AND -- at least at one instance of that block the parameter value is
scalar
-- AND -- at least at one instance of that block the parameter value is
non-scalar
An error message similar to the following is displayed:
Error reported by S-function 'bbb_flp' in
'sample_TL23/Subsystem/Subsystem/Subsystem/Custom
Code Block1':
Invalid value for parameter 'parameter p': Has 2 elements (is
not scalar)!.
MODEL INITIALIZATION FAILED
Workaround: Split custom code up for scalar and non-scalar use case.
ID:
KPR.2010.12.07.005
Title:
Code generation of TargetLink Function block inside library

linked subsystem leads to parameterized library links in the
model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: TargetLink Code generation leads to unexpected

parameterized library link in the
model, if the model contains TargetLink Function block inside
a library linked
subsystem.
441 / 1260
ID:
KPR.2010.12.07.006
Title:
Incorrect code for Stateflow switch pattern

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow chart contains a pattern like

if (IN==0) { OUT=1; }
else {
if (IN==1) { OUT=2; }
OUT++;
}
the following incorrect code will be generated:
switch (IN) {
case 0: OUT=1; break;
case 1: OUT=2; break; // The code OUT++; is missing for this
case.
default: OUT++;
}
442 / 1260
ID:
KPR.2010.12.07.007
Title:
Interpolation (n-D) using PreLook-up block calculates wrong

values under certain conditions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The TargetLink Interpolation (n-D) using PreLook-up block

calculates wrong
values during simulation if all of the following conditions are
fulfilled:
- The Number of table dimensions is 2
-- AND -- The option "Apply interpolation" is enabled
-- AND -- Index value for the second input is equal or greater than
number of table rows
(size(<table>, 1))
The full-featured mode and the standalone-mode are affected
by this problem.
Workaround: There is no workaround (except to avoid at least one of the
conditions listed
above).
patches:
TargetLink 3.1p7
TargetLink 3.2p1
ID:
KPR.2010.12.07.008
Title:
Erroneous elimination of intermediate variable or erroneous

moving of code into conditionally executed control flow branch
due to inlined code preceding If or Switch

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink moves calculations that are only needed in a

control flow branch into such branch; this can also occur in the
form of
elimination of a variable.
Example:
b = a + 5;
if (cond) {
c = b;
...
}
can become
if (cond) {
c = a + 5;
...
443 / 1260
}
if "b" has default variable class or a user variable class with
set ERASABLE
Optimization property and
if (cond) {
b = a + 5;
c = b;
...
}
if "b" has a user variable class with set MOVABLE and unset
ERASABLE
Optimization property or if "b" is used more than once in the
"then branch".
If there is a redefinition of "a" between the assignment to "b"
and the start of
the then branch, none of these optimizations may be
performed:
b = a + 5;
a = new_a;
if (cond) {
c = b;
...
}
If this redefinition of "a" takes place in code stemming from
inlining of a
function (that is output if the Code Generator option
InliningThreshold is set
to 0) and the inlined part immediately precedes the if or switch
statement
controlling the conditionally executed target control flow
branch, then it is
possible that TargetLink erroneously moves the statement "b
= a + 5;" or
eliminates "b":
b = a + 5;
...
/* --- inlined section begin */
...
a = new_a;
...
/* --- inlined section end */
if/switch (cond) {
...
c = b;
...
}
Finding out whether this problem applies requires the
following steps:
- Assign a variable class to "b" that is neither MOVABLE nor
ERASABLE. The
problem vanishes.
- Set InliningThreshold to 0. A function call immediately
precedes the if or
switch statement in the same control flow branch as the
assignment to "b" into
which "a + 5" or "b = a + 5" are moved. The called function or
one of the
444 / 1260
functions it calls contain the redefinition of "a".

Note that "b = a + 5" also could take place in another function.
Provoking this problem in a block diagram requires
- that the atomic system redefining "a" drives the last control
flow branch for
which calculations are necessary.
- using Data Store Memory blocks or merging of different
block variables to "a".
Otherwise, the problem can occur in Stateflow code without
special modeling, for
example in the context of state transitions, or be explicitly
provoked in
Stateflow.
Workaround: Assign a variable class with unset ERASABLE and MOVABLE
Optimization property to
the variable taking the role of "b" in the above example. If "b"
cannot be
specified explicitly, insert a Rescaler block with this variable
class and
enabled option "Inherit signal properties" after the block
leading to "b = ...".
If this is a problem with Stateflow auxiliary variables, then
prevent inlining
of the function containing the redefinition of "a" via assigning
an appropriate
function class.
If none of these applies, then only setting either
OptimizationLevel or
InliningThreshold or both to 0 can help reliably without taking
recourse to
remodeling.
patches:
TargetLink 3.2p1
445 / 1260
ID:
KPR.2010.12.07.009
Title:
Function fmod() in Stateflow only supported as the last

operation within an assignment

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation aborts if the fmod() operation is used in

Stateflow and it is
not the last operation to be executed on the right hand side of
an assignment.
Workaround: Introduce optimizable auxiliary variable and asign result of
fmod() operation to
it.
patches:
TargetLink 3.2p1
ID:
KPR.2010.12.07.010
Title:
Uninitialized local variable is used in index operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: To implement efficient vector code the Code Generator

introduces loops for each
block with a vector signal and merges the loops of
consecutive blocks where
possible.
Example:
Two Gain blocks with gain value 1 and signal width of 5.
Instead of
...
...
TargetLink creates
{
}
{
}
and combines these loops if possible to
446 / 1260
{
}
Incorrect code because of a not initialized loop counter
variable or a fatal
error like
Fatal #10008: Subsystem/Subsystem1/Gain1 Internal error.
Error code:
TlCVSQSOReplacer (number). Contact dSPACE's technical
support team.
may come up, if following conditions are met:
- the function for a subsystem is inlined into another function
-- AND -- the inlined subsystem uses vector inputs and vector outputs
for its interface
-- AND -- the loops resulting from those interface vectors are merged
with loops that
are created for the surrounding subsystem
-- AND -- not all statements from the inlined function can be merged
with a loop from a
block of the surrounding subsystem.
Example:
The subsystem OuterSubsystem has a Gain block
{
Sa1_OuterGain[Aux_S32] = Sa1_OuterIn[Aux_S32];
}
that feeds a subsystem InnerSubsystem that will be inlined
{
Sa2_InnerIn[Aux_S32] = Sa1_OuterGain[Aux_S32];
}
The InnerSubsystem contains a Gain block
{
Sa2_InnerGain[Aux_S32] = Sa2_InnerIn[Aux_S32] * 42;
}
which is followed by a block that doesn't produce a loop that
can be merged with
the other loops.
Sa2_X = ...
This block is then followed by second Gain in the
InnerSubsystem that feeds the
OutPort of its subsystem.
{
Sa2_InnerOut[Aux_S32] = Sa2_InnerGain2[Aux_S32];
}
The inlined InnerSubsystem is followed by a Gain in the
surrounding subsystem
447 / 1260

{
Sa1_OuterGain2[Aux_S32] = Sa2_InnerOut[Aux_S32];
}
The code for this model shall be
{
}
code of none mergeable block like
Sa2_X = ...
{
Sa2_InnerOut[Aux_S32] = Sa2_InnerGain[Aux_S32];
Sa1_OuterGain2[Aux_S32] = Sa2_InnerOut[Aux_S32];
}
For code pattern like this the Code Generatior might produce
the problems
described above.
It might create a loop containing a loop counter variable that is
not
initialized
{
Sa2_InnerOut[Aux_S32_a] = Sa2_InnerGain[Aux_S32_a];
}
Note:
Loops implementing vector code cannot be merged, for
example, if
- they are separated by non vector code
- they reside in different control flow paths
- they have different loop sizes
- they are used in way that combining the loops will change
the result
Workaround: Suppress the inlining of the inlined subsystem.
patches:
TargetLink 3.1p7
TargetLink 3.2p1
448 / 1260
ID:
KPR.2010.12.08.001
Title:
Wrong scaling data used for logs and plots in SIL/PIL

simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Wrong scaling data is used for logging and plotting a variable
in a SIL/PIL
simulation, if all of the following conditions are met:
- It is the first logged variable in the code generated for the
TargetLink
subsystem
-- AND -- the model contains a TargetLink Custom Code block which
is located outside of
this TargetLink subsystem
-- AND --- this Custom Code block is running in MIL mode (it is either
located in a
TargetLink subsystem in MIL mode or outside of a TargetLink
subsystem)
-- AND -- no TargetLink simulation block with logging capabilities is
connected to the
Custom Code blocks outport
This wrong scaling data can result in following effects:
- The plot of the affected variable has a correct shape but a
wrong numeric
range
- Wrong error messages concerning scaling property
inconsistencies appear during
simulation. Some examples of possible error messages:
--- "TLDS error: Invalid lower constrained limit!"
--- "TLDS error: Invalid LSB value!"
- The wrong error message "TLDS error: Problem with DD
Synchronization. Please
check DD object references." appears
Remark: The calculated simulation values for this block
(respectively it's
variable) are not affected by this problem, only the logging
data. That means,
consecutively executed blocks (respective their variables) get
correct
simulation values.
Workaround: Following workarounds can be used alternatively:
- Activate logging for the last output signal of the Custom
Code block
- Connect a TargetLink block with logging capabilities (e.g a
TargetLink Gain
block) between the Custom Code block and the consecutively
449 / 1260
ID:
KPR.2010.12.09.001
Title:
Incorrect code for block with enabled "Inherit properties"

option and indirectly referenced Data Dictionary Scaling object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A Data Dictionary Scaling object can be referenced indirectly

by referencing a
Data Dictionary Variable object or a Data Dictionary Typedef
object with
Constraints. The scaling of this Scaling object is used in
generated code. But
if the option "Inherit properties" is enabled in a TargetLink
block, the scaling
of the referenced Scaling object is ignored. Instead of
expected scaling,
default values for LSB (2^0), Offset (0), Min (NaN) and Max
(NaN) are used. The
problem appears when reading the TargetLink block data, so
that the expected
scaling values are not shown in block dialog.
For TargetLink blocks with a state and option "Inherit
properties" (Unit Delay
block and Unit Delay RE block) this problem can lead to
generation of incorrect
compilable code, because the scaling of the state has no
"Inherit properties"
option and is therefore not directly affected by the problem.
This results in
differences between output and state scaling in generated
code. This
inconsistency cannot be recognized in block's dialog because
scaling data for
states is not visible there.
Workaround: Disable TargetLink block option "Inherit properties" before
referencing a Data
Dictionary Variable object or a Typedef object with constraints.
This can be done via TargetLink block dialog or via API
command tl_set(<TL block
path or handle>, 'output.inheritscaling', 0).
patches:
TargetLink 3.2p1
450 / 1260
ID:
KPR.2010.12.14.001
Title:
No limitation error message #20986 for a Stateflow chart with

defined state reset

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Since Matlab R2010a it is possible to define the state reset

behaviour for
function-called charts explicitly.
TargetLink only supports the default behaviour "inherited". In
case of "held"
and "reset" the limitation error message #20986 shall be
thrown.
But currently no error message appears and the code
generation succeeds with
code in which the reset behaviour is inherited. This can lead to
wrong
simulation behaviour.
Workaround: Change the state reset behaviour of function-called charts to
"inherit".
451 / 1260
ID:
KPR.2010.12.15.001
Title:
Stateflow data type erroneously set to unscaled integer during

synchronization

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Use case 1:

- a Stateflow data object (for example, a SF Output) has a
built-in datatype
that is not "double",
- the TargetLink data type is an integer type, LSB is != 2^0 or
offset != 0.0,
which means that the type is scaled
- TargetLink to Simulink synchronization is invoked with the
"Sync Stateflow
scaling data" option set to "on", or
- the model is cleared from TargetLink data with the Clear
System tool, and the
"Remap Stateflow scaling data" option is "on".
Use case 2:
- in TargetLink preferences, the "Always synchronize Simulink
scaling parameters
with TargetLink properties is "on"
- TargetLink data are written to an SF object as described in
use case 1.
In these use cases, the Stateflow object's data type is set to
the built-in data
type that corresponds with TargetLink's data type.
Example:
SF object data type is the built-in type "single", its TargetLink
data type is
Int16, LSB = 2^-3, Offset = 0.
Synchronization sets SF object data type to built-in type
"int16".
Workaround: 1. Disable the synchronization options described above.
-- OR-2. Insert the following code snippet in
tl_remap_sf_scaling_config.m :
if sf('get',hSFObject,'.props.type.method') == 0
tlLSB = tl_get(hSFObject,'lsb');
tlOffset = tl_get(hSFObject,'offset');
bModified = (tlLSB == 1 || tlOffset == 0);
end
patches:
TargetLink 3.2p1
452 / 1260
ID:
KPR.2010.12.15.002
Title:
An expression of the form "BoolVar >= 0.5F" or "0.5F <=

BoolVar" is erroneously optimized to "1"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code of the form

Bool Ca1_In;
...
if (Ca1_In >= 0.5F) {
Ca1_out = 10;
}
else {
Ca1_out = 20;
}
...
may be optimized to
Ca1_out = 10;
which is wrong. The same happens for other right hand side
constants between 0
and 1.
Workaround: - Use "Ca1_In >= 1F" or "Ca1_In == 1F" instead
-- OR -- assign a variable class to Ca1_In that has unset ERASABLE
Optimization
property
-- OR -- use a macro instead of the constant 0.5F; the corresponding
variable needs a
variable class with Macro = on and unset ERASABLE
patches:
TargetLink 3.1p7
453 / 1260
ID:
KPR.2010.12.15.003
Title:
Starting a MIL simulation via tl_sim prohibits write of

simulation data using ToWorkspace block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a MIL simulation is started via TargetLink API command

tl_sim, variables
specified in ToWorkspace blocks are not written to the base
workspace. The
problem doesn't come up if the simulation is started via 'Start
simulation'
buttons in TargetLink dialogs.
Workaround: The TargetLink tl_sim command is necessary to perform MIL
logging for referenced
models. If the model doesn't contain model references with
activated logging,
the Simulink sim command or the Simulink 'Start simulation'
button can be used.
If MIL logging for referenced models is required, either call
tl_sim with
following parameters:
tl_sim(<model>, [], simset('DstWorkspace', 'base'))
Alternatively use the 'Start simulation' button in TargetLink
main dialog or
TargetLink plot window.
454 / 1260
ID:
KPR.2010.12.15.004
Title:
Call of not existing saturation macro after Saturation block

with constant limit variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The generated code my contain a call of a saturation macro

that does not exist
if following conditions hold:
- A Saturation block has a limit whose variable class is not
"default"
-- AND -- that limit is const
-- AND -- that Saturation block is (not necessarily directly) followed by
a block whose
output is saturated
-- AND -- the saturation of that block can be omitted.
Such a saturation macro can be C__I16FITI16_SAT().
Workaround: Remove the superfluous saturation.
ID:
KPR.2010.12.15.005
Title:
Type of iterator variable of iterated system is not taken from

VariableTemplate object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A TargetLink model contains a subsystem that contains a For

Iterator block or a
While Iterator block. In the block dialog the option "Show
iteration number
port" is disabled. There is a VariableTemplate for an iterator
output in the
Data Dictionary. A Type is specified by the template's settings.
In this case, the Code Generator does not take the data type
of the iterated
system's iterator variable from the VariableTemplate. The
Code Generator
determines a suitable data type instead.
Workaround: Enable the option "Show iteration number port" and terminate
this signal by a
Terminator block.
455 / 1260
ID:
KPR.2010.12.15.006
Title:
A2L import aborts with error 8412 or 8418

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In case A2L import is called via the MATLAB API command
err = dsdd('Import','Format','A2L','File', <fileToBeImported>)
the import aborts with error 8412 or 8418.
This happens if these following conditions holdy:
- The file to be imported resides in deep nested directory
-- AND -- The MATLAB current working directory is the directory where
the file to be
imported resides
-- AND -- The file to be imported is specified only by its name
Workaround: - Specify the file to be imported with its full path
-- OR -- Import the A2L file via the Data Dictionary Manager > File >
Import > from A2L
file
456 / 1260
ID:
KPR.2010.12.15.007
Title:
Code generation aborts if lookup table blocks with different

axis dimensions and record layouts are used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If two Lookup Table blocks have the same settings and differ
only in their axis
values, the Code Generator generates the same lookup
function for both.
Moreover, the same typedef is generated for the map
structure. If the
corresponding axes of the two Lookup Table blocks differ in
their dimension,
this usually is not a problem, since the typedef only specifies
pointers for the
axes. However, if a record layout with DIRECT addressing
mode is used, the
dimension has to be different for the two typedefs. Since the
names are the same
for both of the typedef and the lookup function, this leads to
some errors
during code generation, e.g.:
Error #17153: Subsystem/Look-Up Table1:
An initial value is to be copied from variable x_table to variable
x_table. The
variables differ in data type dimensions.
Error #15511: Subsystem/Look-Up Table:
Found Int8[11] type for component x_table of a structure with
MAP_Tab1DS0I2T1563_a type. The typedef of
MAP_Tab1DS0I2T1563_a defines the
component type of x_table as Int8[12] (Source =
Subsystem/Look-Up Table).
Workaround: Set the TypedefName property of the Record Layout to
"MAP_$(FunctionName)_$S_$B"
and the LookupFunctionName to "$(FunctionName)_$S_$B".
Note that this leads to
different lookup functions for each lookup table block in the
model, which may
be highly inefficient.
To reduce the inefficiency use a name witch has coded the
number of axis points
in there names. i.e. LUT1DNX8 for an 1D Lookup-Table block
with 8 axis points.
For a 2D Lookup-Table Block you have to consider the x and
the y axis i.e.
LUT2DNx8Ny7.
457 / 1260
ID:
KPR.2010.12.15.008
Title:
If-else or switch statement is erroneously moved into

conditionally executed code which may result to wrong code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the following condition is fulfilled the generated code may be

wrong:
- For a block X an IF or a SWITCH-CASE statement is
generated (Switch, Multiport
Switch, Triggered/Enabled Subsystem, If, Switch Case)
__AND__
- X drives a data input of another block Y for which an IF or a
SWITCH-CASE
statement is generated
__AND__
- X drives a Simulink Outport Z which is located at the border
of an atomic
subsystem or at the border of a subsystem which has a
TargetLink Function block
inside.
If this situation is given it may be that the code of X and of
blocks which
drive X is erroneously moved into a conditional branch of Y.
The situation may be further exacerbated if the conditional
branch of Y in which
the code of X and of blocks which drive X is erroneously
moved is removed by
other optimizations. In this case, the code of X and of blocks
which drive X is
also removed (example: Y is a Switch block toggled by a
constant 0 or 1).
Workaround: Specify the Simulink Outport Z for TargetLink (in versions <
TargetLink 3.0:
insert a TargetLink Outport block before Z; in versions >=
TargetLink 3.0:
enhance Z). It is allowed to set Class=default and to activate
"Inherit
Properties" for ease of use.
458 / 1260
ID:
KPR.2010.12.16.001
Title:
Abort of XML Export with style sheet transformation or during

A2L export

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If an XML export is started with style sheet transformation

option and
characters stored in the current Data Dictionary cannot be
transformed to
ISO-8859 character set MSXML 4.0 throws an error. In
TargetLink 3.1 the error
handling for this kind of error causes itself a memory
corruption and thus the
current MATLAB session aborts.
Note:
When executing A2L Export internally an XML export with a
style sheet
transformation is started and will also abort MATLAB when
non-ISO characters
(e.g. Shift_JIS characters) are found in Data Dictionary
objects used by the A2L
export. Despite this fact A2L Export cannot handle characters
other than
ISO-8859-1 in TargetLink 3.1.
Workaround: When exporting Data Dictionary objects using the style sheet
transformation
option avoid non-ISO (e.g. Shift_JIS) characters in these
objects or export
without style sheet transformation and use an XML tool to do
the style sheet
transformation manually after export is finished.
In case of A2L export avoid non-ISO characters in general.
patches:
TargetLink 3.1p6
459 / 1260
ID:
KPR.2010.12.17.001
Title:
Error #17253 or #17254 for same initial values or widths in

Data Dictionary and block dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Data Dictionary variable with a specified Value property is

referenced in a
block where also an initial value can be specified then both
values must be
identical. Otherwise the Code Generator throws error #17253:
Inconsistent init values are specified for variable <DD
varialbe>. The block's
data specify an init value of <value1>, but an init value of
<value2> is
specified in the Data Dictionary.
Due to floating-point rouding effects in some cases the Code
Generator may abort
with error #17253 even if both values are identical. This may
happen if the
initial value is a non-interger number.
Similar this problem may also appear for the Width property.
Then the Code
Generator aborts with error #17254.
Workaround: - Use ddv('<PathtoDDVariable>') in the initial value field in the
block dialog.
-- OR -- Do not specify the value property at the Data Dictionary
variable.
-- OR -- Do not specify the width property at the Data Dictionary
variable.
460 / 1260
ID:
KPR.2011.01.06.001
Title:
Wrong code optimization if state activity output variables are

accessed

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Incorrect code may be generated if a chart output variable

created for a state
with an enabled "Output state activity" option is used in an
action language
expression in the chart. If optimization is enabled, all uses of
such a variable
are replaced with its initial value and possibly eliminated.
This only applies to uses of such variables in the chart itself.
Computations in
blocks connected to the output by signal lines are not affected.
Workaround: Do not use the output variables in the chart itself. All such
uses can be
replaced by appropriate in-expressions. For example, if S is a
state with
enabled "Output state activity" option, then the condition [S &&
x >= 0] can be
written as [in(S) && x >= 0].
ID:
KPR.2011.01.10.001
Title:
Autoscaling of a 2D Lookup Table block with vectorized output

aborts

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Start autoscaling using worst-case ranges of a TargetLink 2D

Lookup Block leads
to en error like
ERROR:Error using ==> mpower Matrix must be square.
ERROR:Output argument "result" (and maybe others) not
assigned during call to
"..\tl_calculate_scaling.p (i_CalcBlockOutport)"
if
- the block output of 2D Lookup Table block should be
autoscaled and
- the output signal is vectorized.
patches:
TargetLink 3.1p6
TargetLink 3.2p1
461 / 1260
ID:
KPR.2011.01.11.001
Title:
Simulation differences for nested event triggered subsystem

with Restart function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a function-call triggered subsystem resides inside a

TargetLink subsystem, it
is called from outside the TargetLink subsystem and there are
no other code
generating blocks on TargetLink subsystem level, then no
function will be
generated for the TargetLink subsystem. If the nested
triggered function causes
a root restart function to be generated, then MIL/SIL/PIL
simulation differences
occur, because the restart function is not be called by the
simulation frame,
leading to missing initializations due to wrong entries inside
the
DataDictionary.
Workaround: Place a function block inside the TargetLink subsystem,
forcing the empty root
function to be generated.
462 / 1260
ID:
KPR.2011.01.13.001
Title:
Incorrect code caused by Unit Delay block's code moved in a

branch of a control flow statement

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A model contains a Unit Delay block that drives directly or

indirectly one of
the following block inputs:
- a data input of a Switch block,
- a data input of a Multiport Switch block,
- any input of an action port triggered subsystem,
- or any input of an enabled subsystem.
The Unit Delay block either drives directly the data input
mentioned above, or
it drives another block. This other block does read from the
Unit Delay block's
state variable and its code pattern is moved into the control
flow generated for
the input. Additionally, there is a signal branch on the signal
line at the Unit
Delay block's output, so the state variable is used outside the
input's control
flow, too.
In this case, code generation may lead to incorrect code
because TargetLink
moves the calculation of the variable that reads from the Unit
Delay block's
state variable into a control flow branch. This can lead to
simulation
differences between MIL and SIL/PIL simulation mode.
Note: the problem may not always happen, this depends on
complex internal
situations inside the code generator. One instance where the
problem may happen
is if IF_ variables are introduced in combination with the Unit
Delay block's
code.
Workaround: - Disable the optimization by disabling the option
"EnableBlockDiagramBasedSwithOptimization" (this may lead
to less optimal code),
-- OR -- Place a Rescaler or Port block between the Unit Delay block
and the signal
branch (the block properties are irrelevant),
-- OR -- Specify a variable class, that has not set the Optimization
property MOVABLE,
for the output variable of the Unit Delay block.
patches:
TargetLink 3.1p6
TargetLink 3.2p1
463 / 1260
ID:
KPR.2011.01.13.002
Title:
Incorrect code for Unit Delay Reset Enabled block part of a

conditionally executed subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the following conditions are fulfilled, incorrect code will be

generated for
the Unit Delay Reset Enabled block:
- The Unit Delay Reset Enabled block is part of a conditionally
executed
subsystem
-- AND -- The output y of the Unit Delay Reset Enabled block is
connected to a Simulink
outport of the conditionally executed subsystem
-- AND -- The Simulink outport of the conditionally executed
subsystem is not enhanced
(only TargetLink 3.x)
-- AND -- The block output variable for the outport y of the Unit Delay
Reset Enabled
block cannot be used as variable for the Simulink outport of
the conditionally
executed subsystem. For instance if the variable class of the
variable has not a
global scope or if the variable class has the properties
InitAtDefinition =
"off" und RestartFunctionName = "" set.
In this case an implicit variable is created for the Simulink
outport of the
conditionally executed subsystem, but this variable is not
updated in the
generated code.
Workaround: Specify the output of the conditionally executed subsystem
explicitly, that
means
- In TargetLink 2.x specify the output of the conditionally
executed subsystem
via a TargetLink Outport block / TargetLink Bus Outport block
- In TargetLink 3.x enhance the Simulink outport of the
subsystem
ID:
KPR.2011.01.24.001
Title:
Incorrect code for Stateflow expression due to user specified

cast
464 / 1260
TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: To generate code for a Stateflow expression the Code

Generator has to determine
a result type and a result scaling for each operation in that
expression. To
avoid overflows this is done basically according to these three
rules:
1. If all operands of a Stateflow expression have the same
TargetLink and
Stateflow type and no TargetLink scaling (LSB != 1.0 and/or
Offset != 0.0), the
Stateflow expression will be treated like Custom Code and will
be copied without
changes to the generated code.
2. If at least one operand of a Stateflow expression has a
different TargetLink
than Stateflow type and no scaling, then the result type of all
operations of
that expression will be determined based on a worst case
range analysis and the
code will be adapted accordingly. No scaling will be assumed.
3. If at least one operand of a Stateflow expression has a
TargetLink scaling
(i.e. LSB != 1.0 and/or Offset != 0.0), then TargetLink will
determine a result
scaling for all operations in that expression and the code will
be adapted
accordingly.
This can cause a problem, if a Stateflow expression contains
a cast operation
whose operands, according to the three rules given above,
would be treated
differently than the whole expression, because TargetLink
implements explicit
cast operations specified in Stateflow using an auxiliary
variable.
Example:
Int16 Result; // Stateflow data type = double
Int16 Var1; // Stateflow data type = double
Int16 Var2; // Stateflow data type = Int16
Int16 Var3; // Stateflow data type = Int16
The Stateflow expression
Result = Var1 + Int32(Var2 + Var3);
Int32 AuxVar;
AuxVar = Var2 + Var3; // both operands of the addition have
the same TargetLink
465 / 1260
and Stateflow data type, thus no casts or scale operations are

introduced
Result = (Int16) ((UInt16) Var1 + (UInt16) AuxVar); // since
Var1 has different
TargetLink and Stateflow data types, casts are introduced
and after AuxVar has been removed by Code Generator's
code optimization
Result = (Int16) ((UInt16) Var1 + (UInt16) Var2 + Var3);
I.e. the (Int32) cast disappeared.
Workaround: Replace casts by a local variable that is not marked as
ERASABLE in their
variable class and initialize it with the expression that is
supposed to be
casted.
Do this whenever the casted subexpression would be treated
according to a
different rule (see description) as the whole expression.
466 / 1260
ID:
KPR.2011.01.24.002
Title:
Documentation generation aborts with error "Operands to the

|| and && operators must be convertible to logical scalar
values"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The TargetLink document generation aborts with Simulink

error message
??? Operands to the || and && operators must be convertible
to logical scalar
values.
Error in ==> FcnPrintRequirementInfoBlocksTable at 167
if ~isempty(hStateflowNodes) ...
Error in ==> FcnPrintFunction at 629
FcnPrintRequirementInfoBlocksTable(fid, fcnData, options);
Error in ==> FcnPrintAllFunctions at 127
[newSourceFiles, newImageFiles] = FcnPrintFunction(fid,
fcnData(i), options);
Error in ==> FcnTargetLinkSubSystems at 822
[fcnList{i}, sourceFileList, imageFileList] =
FcnPrintAllFunctions(fid, rootFcnList,
options);
Error in ==> tldoc at 255
[fid, ok] = FcnTargetLinkSubSystems(fid,properties,values);
Error in ==> tldoc_default at 431
tldoc(docFid,'TargetLink Code Generation Units' ...
if all of the following conditions are fullfilled:
- A library block contains a Stateflow chart and a TargetLink
Function block
with enabled option "Make function reusable"
-- AND -- TargetLink subsystem contains at least two links to this
library block
-- AND -- TargetLink code generation has been performed for this
subsystem
-- AND -- Option "PrintRequirementInfo" is activated for document
generation (default)
Workaround: Currently, the only workaround is to disable "RequirementInfo"
documentation.
This can be done by setting the option "PrintRequirementInfo"
to "off" in
document generation script file (e.g. tldoc_default.m).
This script file can be specified in TargetLink Main Dialog, tab
"Tools", entry
"Script file:".
467 / 1260
ID:
KPR.2011.01.25.001
Title:
Inconsistent output and/or display of renamed base type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: If a TargetLink base type is renamed the original name should

not only appear in
all Graphical User Interfaces, these names should also be
consistently usable
with the TargetLink API. Actually only "tl_set" handles
renamed base types
correctly whereas "tl_get" returns the original name and
"tl_find" accepts the
original type identifiers only.
ID:
KPR.2011.01.27.001
Title:
MIL simulation aborts with error "Error evaluating 'StartFcn'

callback of block_diagram '<model name>'. Cell contents
reference from a non-cell array object."

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The MIL simulation aborts with the error message

"Error evaluating 'StartFcn' callback of block_diagram '<model
name>'. Cell
contents reference from a non-cell array object."
if all of the following conditions are fullfilled:
- The model contains Stateflow charts containing Input Event
objects
-- AND -- The model contains TargetLink Bus Inport blocks
-- AND -- For at least one TargetLink Bus Inport block logging is
disabled
Workaround: For all TargetLink Bus Inport blocks logging must be activated
for at least one
bus signal.
patches:
TargetLink 3.2p1
468 / 1260
ID:
KPR.2011.02.14.001
Title:
Code generation aborts for a system that contains a

referenced system, if the strings NaN, PosInf or NegInf for
values are used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation for a referencing system may fail with
error message 08905,
if the following conditions are fulfilled:
- the strings NaN, PosInf or NegInf are used in the
DataDictionary for
specifying the Value/Min/Max property of Variable objects
-- OR -- the strings NaN, PosInf or NegInf are used in the
DataDictionary for
specifying the Min/Max property of a Constraints object of a
Typedef
-- AND-- the object is part of the interface of a referenced system
Workaround: Do not use the string constants NaN, PosInf and NegInf for
properties of objects
that are part of the interface of a referenced system.
patches:
TargetLink 3.1p8
TargetLink 3.2p1
ID:
KPR.2011.02.14.002
Title:
Logging macro is not moved into conditionally executed

control flow branch if variable is mergeable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a direct assignment (or another write-only operation) to a

variable is moved
into a conditionally executed control flow branch, the Code
Generator also moves
a logging macro statement if necessary.
It is possible that the Code Generator does not move the
logging macro statement
with the value changing operation, if all of the following
conditions are
fulfilled:
- The variable has a variable class with set MERGEABLE
- The variable (or its identifier and variable class) is used more
than once in
469 / 1260
the model.
- One use is logged while another use isn't.
Example:
The output of a Sum block is logged, the Sum block drives a
data input of a
Switch block. Without optimization, the following code is
generated.
Sum = ...;
LOG_VAR(..., Sum);
...
if (Cond != 0) {
Switch = Sum;
} else {
...
}
Optimization leads to
...
if (Cond != 0) {
Sum = ...;
LOG_VAR(..., Sum);
Switch = Sum;
} else {
...
}
If "Sum" drives a Rescaler block that in turn drives the Switch
block, the
Rescaler output is merged via MERGEABLE Optimization
property with "Sum", and
the output of "Sum" is logged while the output of the Rescaler
is not logged,
then optimization either produces the above code or the
following
LOG_VAR(..., Sum);
...
if (Cond != 0) {
Sum = ...;
Switch = Sum;
} else {
...
}
This is subject to internal order during code generation.
The code generator option "DoNotMoveIfLogged" does not
affect this behavior.
If the code generator option
"EnableBlockDiagramBasedSwitchOptimization" is
enabled (default setting since its introduction in TargetLink
2.3), then this
usually only occurs if the moving takes place across atomic
subsystem, function,
or Stateflow chart borders, e.g. if a block output is merged with
a Stateflow
chart input variable and the conditionally executed control flow
branch is
modeled in Stateflow.
470 / 1260

- Avoid merging of the variables; if possible, then this is the
best solution
- Log all occurrences of the same variable
- Assign a variable class with unset MOVEABLE Optmization
property to the
variable; this leads to correct logging but inefficient code
- Log via TargetLink Sink block; this can lead to inefficient
code
ID:
KPR.2011.02.25.001
Title:
Signal properties are lost during disabling reference to a

model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: TargetLink offers the functionality for disabling a reference to

a model which
is available
- via the tl_refmodel_to_subsystem API command
- via the context menu of the referenced model code
generation unit in Main
Dialog (TargetLink 3.1 or above) or
- via Disable Reference button in the Model Referencing
Control Center
(TargetLink 3.0/3.0.1)
If the reference to a model is disabled, a subsystem,
configurated for
incremental code generation is created for the referenced
model. But in the
newly created subsystem, the signals attributes, as for
example RTWStorageClass,
may have different values as in the model.
patches:
TargetLink 3.1p6
TargetLink 3.2p1
471 / 1260
ID:
KPR.2011.03.02.001
Title:
Incorrect code for FIR Filter block in terms of missing output

saturation or incorrect code of successor blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The generated code may be incorrect when the following

conditions for a FIR
Filter block are met:
- The delay line code options "Inline" and "Generate loops" are
both enabled
-- OR -- The delay line code options "Inline"' and "Generate loops"
are both disabled.
In those cases the generated code may contain two errors:
1. If saturation for the block output of the FIR Filter block is
enabled, the
saturation code may be missing in the generated code.
2. The code for successor blocks may be optimized incorrect.
For example
saturation for successor blocks may be missing, expressions
are simplfied to
zero or control flow may be optimized incorrectly.
Workaround: - Do not use the delay line code option combinations "Inline"
enabled and
"Generate loops" enabled, or "Inline" disabled and "Generate
loops" disabled.
The unproblematic combination is if both options do not have
the same state,
thus either one is enabled and other one is disabled.
-- OR -- If the FIR Filter output should be saturated, enable the Code
Generator option
"KeepSaturationStatements".
-- OR -- If the FIR Filter output should not be saturated, either enable
the Code
Generator option "KeepSaturationStatements" OR set the
variable class of the FIR
Filter output to have global or static scope.
patches:
TargetLink 3.2p1
472 / 1260
ID:
KPR.2011.03.02.002
Title:
In Blockset Standalone mode wrong error message when

changing table values of Direct-Look-Up Table block
(TL_LookupNDDirec)

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: In the standalone blockset mode, changing the table values of

a TargetLink
Direct-Look-Up Table block via GUI or API leads to the error
messages "Data
inconsistency!" which is wrong.
Workaround: Use Simulink API set_param to modify the table values.
Example:
set_param(gcb, 'mxTable', '[1 2 3; 4 5 6; 7 8 9;]')
473 / 1260
ID:
KPR.2011.03.02.004
Title:
Not compilable code caused by inport or outport with address

entry at TargetLink subsystem's interface

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A TargetLink subsystem has an inport or outport that is

specified with an
address of a C variable in the block dialog's Address entry.
In this case, code generation succeeds, but building SIL/PIL
stops with errors
on the MATLAB Command Window like
.\TLSim\ds_test\HostPC_MSVC\tl_subsystem_pcf.err for
details
tl_subsystem_pcf.c
.\TLSim\tl_subsystem_pcf.c(100) : error C2065: 'Sa1_OutPort'
: undeclared
identifier
Workaround: Delete the address entry in the port's block dialog. Specify a
variable class
referencing an AccessFunctionTemplate instead. The
AccessFunctionTemplate should
have the following settings:
- Kind: ADDRESS
- FunctionClass: Any FunctionClass that specifies a macro
(property "Macro" =
"on").
- MacroBody: Should contain the string in the address field.
Another workaround is to place the contents of the TargetLink
subsystem into a
dummy atomic subsystem that is placed on top level of the
TargeLink subsystem.
The port with address entry should be connected with an
enhanced port of the
TargetLink subsystem that does not have any address
specified.
The code of the subsystems can be generated to different files
by inserting a
Function block with different "C code file name" or "module"
entry in each
subsystem.
474 / 1260
ID:
KPR.2011.03.03.001
Title:
Unnecessary upgrade of TargetLink blocks from user libraries

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: All instances of TargetLink blocks residing in user libraries are

handled by
TargetLink's upgrade routine notwithstanding that libraries
should be excluded
from upgrade. Especially in case of custom code blocks this
can be annoying
since the upgrade of a custom code block is coupled with a
rebuild of it's
S-function. Note that the S-Function rebuild cannot be
suppressed if the model
or library is upgraded from 2.x to 3.x.
Workaround: The unecessary upgrade doesn't thwart a successful upgrade.
If the (already
rebuilt) S-functions are write protected then copy them into the
working
directory for the duration of the upgrade procedure.
475 / 1260
ID:
KPR.2011.03.03.002
Title:
Error #17253 for the same initial value in block dialog and for
Data Dictionary Variable object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink may issue erroneously error #17253 if the following

conditions are
fulfilled:
- a block variable with an initial value references a Data
Dictionary Variable
object
AND
- the value property of the Data Dictionary variable is a floating
point value
that can not be represented exactly in binary, e.g. 0.1
AND
- the block dialog uses a MATLAB workspace variable with the
same value
AND this workspace variable
- has datatype 'single', e.g. by using a Matlab cast like
WorkspaceVar =
single(0.1)
OR
- is a Simulink Parameter object with datatype 'single'
TargetLink uses double precision for the Data Dictionary
Variable object's value
but does not correctly consider the single precision of the
workspace variable.
As a result TargetLink issues error #17253: "Inconsistent init
values are
specified for variable <variablename>. The block's data
specify an init value of
0.1, but an init value of 0.1 is specified in the Data
Dictionary.". Confusingly
enough the message mentions the same value for block
dialog and Data Dictionary.
Workaround: - Use the Simulink datatype double for the workspace
variable.
OR
- Leave the Value property at the Data Dictionary Variable
object empty.
476 / 1260
ID:
KPR.2011.03.03.003
Title:
Range calculation aborts with error #03461 for several blocks

with a calibratable parameter

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Range calculation aborts with error #03461 for following

blocks
- Look-Up Table (2D) block
- Gain block
- Relay block
- Saturation block
if a parameter/limit has calibratable variable class and the
input size and
output size are different in at least one input.
Example:
A Gain block has a scalar driving signal. The calibratable Gain
parameter is a
vector of size 3, e.g. [2 4 6], thus the output size is 3 as well.
Workaround: Make sure, that all input and output signals have same size.
patches:
TargetLink 3.1p9
477 / 1260
ID:
KPR.2011.03.03.004
Title:
TargetLink Inport block is unconnected after Simulink to

TargetLink conversion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During Simulink to TargetLink conversion, Targetlink Inport

and Outport blocks
are inserted at the root level of the system that is converted.
However, if the
following conditions apply, TargetLink Inport blocks are not
always inserted
properly, but are sometimes unconnected:
- the adjacent Simulink Inport block icon is large (greater than
50 pixels),
- the distance between the Simulink Inport and the follwoing
block (or signal
line branch) is small (less than 20 pixels).
Workaround: Make sure that
- Simulink Inport blocks at root level are small,
- there is sufficent free space between the Simulink Inports
and the following
block
before starting Simulink to TargetLink conversion.
Also consider the hint in TargetLink Production Code
Generation Guide:
"To avoid inserted blocks overlapping with other blocks after
conversion, you
should leave sufficient space between Simulink Inport and
Outport blocks of the
topmost level and the blocks they are connected with.
Otherwise, the model might
look disorganized after conversion." (see TargetLink
Production Code Generation
Guide > Using Simulink Models in TargetLink > Converting a
Simulink Model to
TargetLink > Converting a Simulink Model into a TargetLink
Model > How to
Convert a Simulink Controller Subsystem into a TargetLink
Controller Subsystem >
Block layout in the model)
478 / 1260
ID:
KPR.2011.03.03.005
Title:
Unsupported block from Simulink library not detected during

System Preparation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling

- a system (subsystem, model or library) should be prepared
for TargetLink
- the system contains a Simulink block that is Simulink library
subsystem, for
example, the simulink/Logic and Bit Operations/Compare To
Constant block
- there is at least one block that originates from a custom
library which is not
prepared for TargetLink
- preparation is started with the enabled option "Prepare
related user
libraries".
Preparation succeeds, however, the Compare To Constant
block remains unmodified.
Because it contains Simulink blocks that are not enhanced for
TargetLink, the
system is not prepared completely. Code generation will not
succeed, but the
Compare To Constant block is detected as an Unsupported
Block.
Workaround: - provide a TargetLink-compliant library and a libmap for the
Compare To
Constant block,
- re-invoke preparation on the system to have it prepared
completely; the
Compare To Constant block is replaced by the corresponding
block form the custom
library.
patches:
TargetLink 3.2p1
479 / 1260
ID:
KPR.2011.03.03.006
Title:
Autoscaling ignores headroom at TargetLink OutPort block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Autoscaling ignores specified headroom at TargetLink OutPort

block, if
- autoscaling with simulated ranges is used
-- AND -- the OutPort block was logged, i.e. simuated ranges exists for
the outport
block.
Workaround: Exclude the TargetLink OutPort block from logging and use
the netlist from
autoscaling with simulated ranges.
In case of the netlist the simulated range of the predecessor
block is used to
scale the TargetLink OutPort block.
ID:
KPR.2011.03.03.007
Title:
Compilation of TargetLink simulation frame fails with an error

message for variables initialized with NaN

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a vectorial address mapped macro variable is used at the

Inport or Outport of
the TargetLink subsystem then the compilation of the
TargetLink simulation frame
may fail during 'Build SIL' or 'Build PIL', as in this case some
variables in
the simulation frame code may be initializied with 'NaN'.
Note: An address mapped macro is generated if a block dialog
has a non-empty
Address field or references a Data Dictionary variable with a
non-empty Address
property.
Workaround: Use only scalar address mapped macros at the Inports and
Outports of the
OR
Leave the Address field empty, use a Variable Class with
property 'Alias' = 'on'
and define the variable/macro in a hand-written code file.
480 / 1260
ID:
KPR.2011.03.03.008
Title:
Autoscaling aborts on MinMax or Multiport Switch block driven

by one vector signal

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Autoscaling aborts with fatal error during scaling calculation, if

- a MinMax or Multiport Switch block with only one vectorized
data signal should
be autoscaled
-- AND -- the driving block has calculated or fixed scaling
-- AND -- the scaling is not equal for all components. Therefore inherit
scaling is not
possible.
The error message is like the following
*** F00000: ERROR DURING SCALING CALCULATION:
*** The access to the inport scaling of
'testmodel/Subsystem/Subsystem/Subsystem/MinMax' failed.
Workaround: Demux the driving signal and create as many inputs for the
MinMax block as
vector elements of the driving signal.
481 / 1260
ID:
KPR.2011.03.03.009
Title:
Preparation aborts on Interpolation (n-D) using PreLookup

block with unsupported parameter set although a libmap
specifies a corresponding TargetLink block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility

- System (subsystem, model or library) contains an
Interpolation (n-D) using
PreLookup block with tree dimensions, which is not
suppported by TargetLink.
-- AND -- A libmap specifies a corresponding TargetLink block (for
example, a Custom
Code block) that should replace the incompliant PreLookup
during preparation.
However, preparation fails with an error message like the
following:
Error #03066: testmodel/ ... /subsys/Interpolation(n-D)
using_PreLook-Up:
The parameter set of the Pre Look-up Interpolation block is
not supported by
TargetLink.
The libmap file is ignored.
Workaround: Write a pre preparation hook function with the following code:
bs.hRepBlocks = [bs.hRepBlocks ; bs.hUnSupInterpBlocks];
bs.hUnSupInterpBlocks = [];
patches:
TargetLink 3.2p1
482 / 1260
ID:
KPR.2011.03.03.010
Title:
Simulink error in SIL/PIL if function-call signals are passed

into the TargetLink subsystem via more than one inport

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In Simulink, function-call subsystems that build an algebraic

loop must have a
common function-call initiator (for example, a statechart or a
function call
generator).
In the following case, TargetLink's SIL/PIL simulation is not
possible with such
systems:
- two or more function-call triggered subsystems that build an
algebraic loop
reside in a TargetLink subsystem AND
- function-call initiator resides outside the TargetLink
subsystem AND
- function-call signals run from the initiator through more than
one inport on
the root level of the TargetLink subsystem
In this case, SIL/PIL simulation results in a Simulink error,
which means that
the model cannot be initialized. Inside the simulation frame,
the input ports of
the TargetLink subsystem are connected with Ground blocks
in SIL/PIL mode, which
violates the common function-call initiator rule.
Currently this is a limitation of TargetLink's MIL/SIL/PIL
simulation frame.
Workaround: Mux the function-call signals outside of the TargetLink
subsystems, and pass
them into it via a single inport. Inside the TargetLink
subsystem, demux the
signal and connect the individual signals with the function-call
subsystems.
483 / 1260
ID:
KPR.2011.03.03.011
Title:
Code for Custom Look-Up Table map struct does not compile

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an user look-up table script uses a typedef for a table map
struct with
TargetLink property 'CreateTypedef' set to 'no' and if also the
template code of
the user look-up table script does not contain an include
directive for a file
which contains the type definition of the map struct, then
TargetLink may
generate incorrect code that cannot be compiled.
The compile error results from a duplicate 'struct' keyword
inside cast
operations to the anonymous map struct type. Especially if
such cast operations
are generated inside conditions of control statements, then the
duplicate
'struct' keyword will always occur, like in this example:
if (A < Tab1DS16I80T31798_a((struct struct
MAP_Tab1DS16I80T31798_a_tag *) ,
B)) {
...
}
Workaround: 1) Either Set the 'CreateTypedef' property of the map struct
type to 'yes'
2) or insert a proper include directive in the template code.
patches:
TargetLink 3.2p1
ID:
KPR.2011.03.03.012
Title:
Code generation aborts with error #17155, if a user specified

file has the basename "compiler"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a user specified file has the base name "compiler" code
generation aborts
with the error #17155: "Two different TargetLink default files
which have the
same base name 'compiler'.h found."
Workaround: The base name "compiler" is reserved by TargetLink and must
not be used as the
base name for a user sepcified file.
484 / 1260
ID:
KPR.2011.03.03.013
Title:
Output reset of conditionally executed system does not use

RTE API function call

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A model contains a subsystem that is specified as an

AUTOSAR runnable. The
runnable subsystem contains a conditionally executed
subsystem. One outport of
the conditionally executed subsystem is specified with 'Output
when disabled' as
'reset'. Additionally, the outport is specified with AUTOSAR
Sender/Receiver, or
Client/Server communication.
In this case, TargetLink generates code that is not AUTOSAR
conform, because the
output reset is not done by calling the correct RTE API
function.
TargetLink resets the RTE frame variable instead. Please
note, that the variable
is not defined in the AUTOSAR production code.
Workaround: Do not specify any AUTOSAR communication for the outport
mentioned above.
Specify the AUTOSAR communication in an outport that is
placed right after this
block instead.
ID:
KPR.2011.03.03.014
Title:
Incorrect code for value of Stateflow data element with scope

"Parameter"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The value of a Stateflow data element with scope "Parameter"

is usally specified
by a variable in base workspace or mask workspace. If you
are using TargetLink
3.2 together with Matlab R2010a or higher the value may not
be determined
correctly and the value 0 is used instead.
Workaround: You may consider to switch the scope from "Parameter" to
"Constant" and use the
parameter variable identifier as initial value expression.
patches:
TargetLink 3.2p1
485 / 1260
ID:
KPR.2011.03.03.015
Title:
Autoscaling does not handle calibratable parameters correctly

during range calculation and scalar expansion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Worst case range calculation failed during autoscaling if

- the block, that should be autoscaled has a calibratable
parameter
-- AND -- the parameter is scalar, but input signal is vectorized OR the
parameter is
vectorized and input signal is scalar.
Workaround: Make sure that parameter and input signal have same size.
patches:
TargetLink 3.1p7
486 / 1260
ID:
KPR.2011.03.03.016
Title:
Address mapped macro erroneously optimized to a constant

value in the generated code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an address mapped macro is used in arithmetic, logical or

shift operation
with a constant value then the TargetLink Code Generator
may erroneously
optimize the expression to a constant value in the generated
production code,
e.g. code like
out = ADDRESS_MACRO * 10;
incorrectly gets optimized to
out = 0;
This problem may occur if the Variable Class of the address
mapped macro
variable is either 'default' or has the 'ERASABLE' flag set at
the
'Optimization' property.
Note: an address mapped macro is generated when a block
dialog has a non-empty
Adress field or references a Data Dictionary Variable object
with a non-empty
Address property.
Workaround: Use a Macro Variable Class without 'ERASABLE' at the
'Optimization' property.
ID:
KPR.2011.03.08.001
Title:
Address qualifier of pointer variable wrongly appears in

generated code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Although the option "Enable sections/pragmas/inline/ISR/user

attributes"
(EnableSections) is disabled, e.g. in Main Dialog, an address
qualifier of
pointer variable still appears in generated code.
Workaround: Remove the qualifier manually from the TargetConfig.xml file
or the variable
class, respectively.
487 / 1260
ID:
KPR.2011.03.18.001
Title:
Incomprehensible prefix "PD_" added to units during

AUTOSAR export

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During export of a PHYSICAL-DIMENSION element the

TargetLink AUTOSAR export
extends the element's short name with the prefix "PD_". This
has an impact to
the roundtrip behavior, because in further iterations always a
new Unit object
is added to the Data Dictionary, with the new name PD_PD_
...
This results not in a wrong AUTOSAR description, but violates
the rule that the
exported element is the same as the imported one.
Additionally with every
iteration the number of Unit objects increase and existing unit
objects will
become obsolete.
patches:
TargetLink 3.1p7
TargetLink 3.2p1
488 / 1260
ID:
KPR.2011.03.21.001
Title:
Problem with newly created or changed Stateflow data with

data type fixpt since ML2008a

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In TargetLink 2.3.1 and with Matlab R2008a or higher exists a

problem with
Stateflow data which has the Stateflow type fixpt.
In TargetLink versions prior to TargetLink 3.0, i.e. TargetLink
2.x, such a
Stateflow type is used as input information for the TargetLink
Code Generator.
But the Code Generator does not handle this information
correctly which may
result either in wrong scaling in the production code or wrong
error message
about invalid scaling like the following:
Error #15241: Subsystem1/chart.counter:
Found lsb with invalid value.
The problem also occurs if a TargetLink 2.3.1 model which
was created and/or
modified with MATLAB R2008a or newer is upgraded to
TargetLink 3.0 or newer.
During upgrade process the wrong scaling information may be
stored as TargetLink
scaling.
Workaround: For a solution regarding TargetLink 2.3.1 contact dSPACE
TargetLink support.
In TargetLink 3.0 or newer either set the right scaling
information, e.g. using
the Property Manager, or do a sync (Simulink ot TargetLink)
using the System
Synchronization dialog (tl_sync_system).
489 / 1260
ID:
KPR.2011.03.21.002
Title:
Problems during AUTOSAR import of DATA-CONSTR

elements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: SystemDesk exports data constraints for real data types since
version SystemDesk
3.0p2. These data constraint objects contain lower and upper
limits, with the
infinite value flag.
In an AUTOSAR XML file this looks like:
<PHYS-CONSTRS>
<LOWER-LIMIT INTERVAL-TYPE="INFINITE" />
<UPPER-LIMIT INTERVAL-TYPE="INFINITE" />
</PHYS-CONSTRS>
TargetLink throws the error message 8768 for floating-point
data types that
references these data constraints:
E08768: Error during AUTOSAR import
Error detected in attempt to import REAL-TYPE
Float_with_NaN. The referenced
object DataTypes/DC_Float_with_NaN does not exist.
The problem is due to the infinite flag which implies that no
value will be
written to the element itself. TargetLink interprets this as a
data constraint
without any data and rejects it.
patches:
TargetLink 3.1p7
TargetLink 3.2p1
490 / 1260
ID:
KPR.2011.03.21.003
Title:
Autoscaling determines wrong scaling for Product block using

division

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The Autoscaling tool calculates wrong scaling for output of

TargetLink Product
block, if
- at least one operation used in Product block is a division
-- AND -- output scaling cannot be calulated backwards from following
blocks
-- AND -- scalings of all inputs are known or calculated
-- AND -- the LSB of division input is greater than the expected LSB of
block's output
Workaround: Scale Product block manually und set the autoscaling mode to
no autoscaling.
patches:
TargetLink 3.1p10
TargetLink 3.2p4
ID:
KPR.2011.03.30.001
Title:
No min and/or max value at output variable of a scaling

invariant subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Any min and/or max value of an output variable of a scaling

invariant subsystem
that is set through a scaling propagation function is ignored by
the Code
Generator.
Workaround: Place a Rescaler block (>= TargetLink 3.0) or Port block
(TargetLink 2.x) with
the correct min and/or max value after the affected output of
the scaling
invariant subsystem.
patches:
TargetLink 3.2p2
491 / 1260
ID:
KPR.2011.04.19.001
Title:
Wrong code optimization for mod and rem operation with

floating-point types

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For mod and rem operations with floating-point types a range
calculated during
code generation is wrong. This may lead to wrong code for the
operation itself
as well as for successor operations.
A wrong range is calculated when a mod or rem operation has
- at least one floating-point input argument
-- OR -- a floating-point result.
Workaround: - Try to avoid mod/rem operations with floating-point arguments
and
floating-point results
-- OR -- Set a variable class with the following properties at the result
variable of
the Math block with mod/rem function:
- Scope=global OR (Scope=local AND Storage=Static)
- Optimization.SCOPEREDUCIBLE=OFF
- Optimization.ERASEABLE=OFF
-- OR -- To omit the global/static variable from the previous
workaround: For
TargetLink < 3.0, place an additional TargetLink Outport block
behind the Math
block with mod/rem function. For TargetLink >= 3.0, place an
additional
TargetLink Rescaler block behind the Math block with mod/rem
function.
Set the following properties at the variable classes of the Math
block with
mod/rem function and the additional Outport/Rescaler block:
- Math.VariableClass.Scope=global OR (Scope=local AND
Storage=Static)
- Math.VariableClass.Optimization.SCOPEREDUCIBLE=OFF
- Math.VariableClass.Optimization.ERASEABLE=ON
- Outport/Rescaler.VariableClass.Scope=local
Outport/Rescaler.VariableClass.Optimization.ERASEABLE=OFF
For mod/rem operations in Stateflow, use one of the
workarounds above for the
result variable of the mod/rem operation.
492 / 1260
ID:
KPR.2011.04.21.001
Title:
Document generation throws error message about missing

references on InterfaceVariable objects in DD Subsystem
area

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: For a reused function which is encapsuled by a Preprocessor

Ifdef block and
which has local variables or formal parameters, the
corresponding variable are
not correctly generated inside the DD Subsystem area. This
leads to error
messages during Document Generation.
patches:
TargetLink 3.2p2
493 / 1260
ID:
KPR.2011.04.26.001
Title:
Plot deviations between MIL vs. SIL/PIL due to conflicting

Scalings of a Data Dictionary Variable object and it's Typedef

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a block has logging of 'Signal history' enabled and

references a Data
Dictionary Variable object that
- is a vector
- AND it's Scaling property references 'VOID_SCALING'
- AND the variable references a Typdef object with a
Contraints object
- AND that Constraints object references a Scaling object with
LSB != 2^0 or
Offset != 0.
Then the TargetLink plot window does not correctly visualize
the signal history
of this block variable in SIL and PIL simulation, as the plot
mechanism
incorrectly assumes that the variable's scaling is LSB = 2^0
and Offset = 0.
Note: this is only a visualization problem. The generated
production code is
correct as the Scaling at the Typedef overwrites the Scaling at
the Variable
object.
Workaround: Use the same Scaling object for the Data Dictionary Variable
object and for the
Typdef object.
patches:
TargetLink 3.3p1
494 / 1260
ID:
KPR.2011.04.26.002
Title:
Incremental code generation for a Runnable system aborts

with unclear error message #15207

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Currently it is a TargetLink limitation that Incremental Code

Generation
directly for a Runnable subsystem is not possible. Still such a
code generation
could be started:
* by means of TargetLink's API
* out of the Function block dialog
* out of the Main Dialog
* via the menu entry TargetLink > Code Generation >
Generate Code
In this case the code generator aborts with following error
message:
Error #15207: <path_to_block>:
The <block_name> block is part of a system interface but is
not well-defined
(direct one-to-one connection of a TargetLink or bus
inport/outport with a
Simulink inport/outport). Insert the appropriate TargetLink Port
or Bus Port
block.
This message is confusing and can be ignored.
Workaround: No workaround available. Currently the code generation can
only be initiated for
the whole TargetLink subsystem wherein the Runnable
resides.
495 / 1260
ID:
KPR.2011.04.26.003
Title:
Incorrect code caused by unused component of struct

operation argument of AUTOSAR operation call system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A subsystem is specified as an AUTOSAR runnable. It

contains another subsystem
that is specified as an operation call. The operation call
system references an
Operation object in the Data Dictionary which has an
OperationArgument of Kind =
"ARGIN" and a Type with BaseType = "Struct". This operation
argument is
referenced in a BusInport of the operation call system. One of
the bus signals
is not used or terminated directly in the operation call system.
In this case, the generated optimized AUTOSAR code may be
incorrect. The
generated code may lack an assignment to the component of
the actual struct
parameter of the operation call system's Rte_Call that belongs
to the unused bus
signal mentioned above.
Workaround: Explicitely model a use of the bus signal in the operation call
system. Another
possible workaround is to replace the operation call system by
a BusOutport that
is specified as the same operation call.
ID:
KPR.2011.04.26.004
Title:
Incorrect code for suppressed right shift operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a right shift operation is specified in a Stateflow chart or with

a Shift
Arithmetic block, and if the Code Generator option "ShiftMode"
is set to "don't
shift at all" or "don't shift right", then the generated code will be
wrong,
because the shift operation will be implemented as a division
by zero.
The Shift Arithmetic block was introduced with TargetLink 3.1.
Workaround: Manually replace the shift operation by a division.
496 / 1260
ID:
KPR.2011.04.26.005
Title:
Currently unused block data leads to obscure error message

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Using TargetLink port blocks with invalid but grayed/inactive

settings of output
variable block data in AUTOSAR mode leads to obscure error
messages during
simualtion, code generation etc.:
#06273: <block>: The reference path '<dd-path>' of reference
property '<block
property>' could not be resolved.
-- AND -#01236: <block>: During the synchronization of block data
and referenced Data
Dictionary objects an inconsistency was detected. See the
for further information.
Workaround: Make sure that no invalid data is saved on the block. You can
activate the dual
edit mode in the block's dialog to see and correct the wrong
output settings.
497 / 1260
ID:
KPR.2011.04.26.006
Title:
MATLAB API of the Data Dictionary does not work correctly

with logicals

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: Logicals cannot be safely used to set custom properties of

Data Dictionary
objects using the DD MATLAB API. The property is set, but it's
value maybebe
undefined depending on the state of the MATLAB heap
memory.
Example:
>> dsdd('Set', '//DD0/Config/DiffMergeConfiguration',
'TestTest', true);
>> dsdd('GetAll', '//DD0/Config/DiffMergeConfiguration')
ans =
TestTest: 711589377
The bug applies only for custom properties, i.e. properties that
are not
pre-defined in the Data Model.
Note: "true" and "false" are identical to "logical(1)" and
"logical(0)",
respectively.
Workaround: Use another syntax to set a boolean custom property:
>> dsdd('Set', '//DD0/Config/DiffMergeConfiguration',
{'name','TestTest','TypeId','boolean'},1);
498 / 1260
ID:
KPR.2011.04.26.007
Title:
Included Data Dictionary files not saved during MATLAB

shutdown

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AutoSave property of DDIncludeFile objects specifies

whether an included
Data Dictionary file should be saved with the main Data
Dictionary file.
Possible values for this property are "on", "off",
"OnlyIfModified",
"PromptIfModified".
Use case:
- The AutoSave property of a DDIncludeFile object specifies
that the associated
included Data Dictionary should be saved.
- The included Data Dictionaries filename does not specify
paths.
- The included Data Dictionaries filename does not use the
MAINDDDIR macro.
- The Data Dictionary is forcibly closed when MATLAB is shut
down.
In this use case, the included Data Dictionary is saved to a
location that
depends on the TargetLink installation instead to the file from
which it had
been loaded.
Workaround: Use absolute file paths for included Data Dictionary files, or
the MAINDDDIR
macro. Alternatively, save the current Data Dictionary before
closing MATLAB.
This can be achieved with the dsdd save command, or the
dsdd_manage_project
tool, or the Data Dictionary Manager.
499 / 1260
ID:
KPR.2011.04.26.008
Title:
Error in ASAP2 file because of reusing an axis in custom lookup scripts

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a variable represents a look-up block axis and if

- that variable is used in different custom look-up scripts and if
- that variable represents different axis' in different scripts (like
e.g. an
x-axis in script1 and an y-axis in script2), then
the generated ASAP2 file might be wrong.
patches:
TargetLink 3.1p7
TargetLink 3.2p2
ID:
KPR.2011.04.26.009
Title:
Opening the ContainerManager from the Data Dictionary

Manager's Tool menu fails with an error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When trying to open the ContainerManager from the Data

Dictionary Manager's Tool
menu, it may happen that the action fails and instead a
message box is shown
which tells "Invalid command line arguments". The error
occurs if a Catalog Set
file (*.cts) has already been created and if the path of that file
contains a
space character (" ").
Workaround: There are three alternatives:
1. Open the Container Manager by hand from the Windows
Explorer.
2. Put the CTS file into a folder which doesn't contain a space
character in its
path and set the /Config/General.CatalogSet property to the
absolute path of the
file.
3. Put both the Data Dictionary project file and the CTS file
into a folder
which doesn't contain a space character in its path.
patches:
TargetLink 3.2p2
500 / 1260
ID:
KPR.2011.04.26.010
Title:
Code generation aborts with fatal error #10007 caused by

Model block in AUTOSAR runnable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation aborts with fatal error #10007 if the following
conditions are
fulfilled:
- Code generation mode is "AUTOSAR".
- A Model block is placed inside a subsystem that is specified
as an AUTOSAR
runnable. The Model block resides on the same hierarchy
level as the Runnable
block or on any hierarchy level below. The runnable belongs
to a software
component that has a restart runnable specified. The
referenced model contains a
variable whose variable class property "RestartFunctionName"
is set to
"default".
- The name of the Model block (including the block path) is the
first one in a
sorted list of names of all block within the runnable subsystem
and below. The
following blocks are not taken into account here: Mux, Demux,
Bus Creator and
Bus Selector.
- Code is generated for a code generation unit where the
Model block resides in.
Workaround: Respecify the model in a way that one condition is not fulfilled,
e.g. rename
the Model block (by adding a prefix "z_"), or by inserting a
Rescaler block with
a suitable name (e.g. "A_Rescaler").
501 / 1260
ID:
KPR.2011.04.27.001
Title:
Compiling of production code SIL or PIL applicatian may fail if

the production code to be compiled has been generated in
AUTOSAR mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The build process of the SIL/PIL application fails for

production code generated
in AUTOSAR mode in following cases:
1. You try to build a SIL/PIL application for TargetLink
subsystem(s) for which
the production code was generated in AUTOSAR mode, after
you have built a
SIL/PIL application for the same or other TargetLink
subsystems in the same root
model, but from the production code generated in
Standard/RTOS mode.
2. You try to build a SIL/PIL application for multiple TargetLink
subsystem(s),
but for some of them the production code was generated in
AUTOSAR mode, for the
other ones in Standard or RTOS mode.
Depending on the used compiler errors like these one may be
issued:
MSVC compiler:
<moduleName> : error C2081: 'RTE_APPL_CODE' : name in
formal parameter list
illegal
<moduleName> : error C2860: 'void' cannot be an argument
type, except for
'(void)'
LCC compiler:
Error <moduleName>: <moduleName>: 101 missing
parameter type
Error <moduleName>: <moduleName>: 101 illegal formal
parameter types
Workaround: Case 1:
- Delete the build directory
.\TLSim\<modelName>\HostPC_<compiler> for SIL
simulation or
.\TLSim\<modelName>\<boardName>_<compiler> for PIL
simulation
-- OR -- Delete the whole .\TLSim directory. In this case the
production code must be
generated again.
Case 2:
- No workaround is available. It is a TargetLink limitation.
502 / 1260
ID:
KPR.2011.04.27.002
Title:
Build of simulation application fails if an AddFile block

references the root file of a subsystem configured for

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a TargetLink subsystem contains a subsystem, that is

configured for
incremental code generation, and an AddFile block
referencing the root file of
the subsystem configured for incremental code generation,
code generation is
successful, but build of simulation application fails.
Workaround: This is an wrong specification. The root file of a subsystem
configured for
incremental code generation must not be referenced by an
AddFile block.
ID:
KPR.2011.04.27.003
Title:
Error #30053 if a custom look-up function is called with

different scalings

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a function is specified in a custom look-up script and if

- that function is called more than once and if
- a parameter of that function is specified to have different
scalings (LSB,
Offset) for different calls,
then the Code Generator might issue the error message
Error #30053 <block> Found contradicting specification for
scaling of parameter
<parameter> of function <function>: LSB <LSB1> and
offset<Offset1>. In a
previous call the specified scaling was LSB <LSB2> and offset
<Offset2>. Adapt
your script or, if the function parameter is invariant to scaling,
set the
'ScalingAdjust' property to 'off'.
Workaround: Use different function names for different scalings in the script
and map those
names to the original function name in an header file. Include
that header file
in the generated code via an AddFile block.
patches:
TargetLink 3.2p2
503 / 1260
ID:
KPR.2011.04.27.004
Title:
Parameter of TargetLink block in an instance of a library

subsystem referenced in a model is modifiable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a TargetLink block resides in a library subsystem which is

referenced in a
model then the TargetLink block is modifiable which leads to a
parametrized
library link. It is not intended that a TargetLink block is
modifiable in such a
model configuration.
Workaround: Do not modify a TargetLink block in a linked library
subsystem.
patches:
TargetLink 3.1p8
TargetLink 3.2p2
ID:
KPR.2011.04.27.005
Title:
Variables accessed by Access Functions may superfluously

be declared inside Simulation Frame Include Files and inside
exported A2L files

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a variable that is accessed by Access Functions is shared

between TargetLink
Subsystems, the variable may additionally be declared inside
the SIL/PIL
Simulation Frame Include Files of other Subsystems, where
this variable is not
actually used. This may then as well lead to superfluous
entries inside the
corresponding A2L Files exported for these Subsystems.
504 / 1260
ID:
KPR.2011.04.27.006
Title:
Incorrect code for function call of external Stateflow function in

reused functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the Code Generator option

"EnableExternCStateflowSymbols" is enabled and a
reused chart contains calls to such an extern C function the
call to it should
be as written in the Stateflow chart, for example:
out = myCustomFcn(a,b);
But TargetLink modifies the name in the generated code with
"DEL_REUSE" like the
following example:
out = DEL_REUSE_myCustomFcn(a,b);
Workaround: Don't use extern C Stateflow symbols in reused charts. Use
instead graphical
functions with a function class which has storage extern or
alias.
505 / 1260
ID:
KPR.2011.04.27.007
Title:
Code generation may abort without a proper error message if instances of a reused
system or AUTOSAR ClientPort blocks are different

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink's code generation may abort without a proper error message if
instances of a reused system are different. This violates the concept of
function reuse, for which only one function should generated in the production
code. Thus all instances in the model must be identical. But for example by
(accidently) using parameterized links, the instances of a reused library system
may differ.
The problem may also happen when using the same Port and Operation in multiple
AUTOSAR ClientPort blocks (from the TargetLink AUTOSAR library prior to
TargetLink version 3.1).
If such a problem is present in the model then the Code Generator may abort with
different fatal internal errors like #10007 or #99999. For example like in the
following:
Fatal #10007:
[...]\Core\XcgIvTransformer\Sources\XcgIvTransformer\FcnReuseAnalysis\FcnReuseVa
lidator\TlCIvFcnReuseInstanceVisitor.cpp_ 490. Contact dSPACE's technical
support team.
Workaround: 1) Make sure all reused system instances in the model are identical. E.g. are
not parameterized links.
-- OR -2) If possible avoid multiple ClientPort blocks for the same Port and Operation.
506 / 1260
ID:
KPR.2011.04.27.008
Title:
Erroneous floating-point casts in relational operation with

integer operands specified in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink might erroneously cast the integer operands of a

relational operation
to floating-point, if
- the relational operation is specified in Stateflow
-- AND -- at least one of the operands of the relational operation has a
scaling (LSB !=
1.0 and/or Offset != 0.0) or has a different TargetLink than
Stateflow data type
-- AND -- one of the operands is an operation that produces a local
auxiliary variable.
Operations in Stateflow producing local auxiliary variables are
- calls of functions that have a function return value
- casts
Workaround: Assign the result of the operation to a static or global auxiliary
variable and
use that auxiliary variable in the relational operation.
patches:
TargetLink 3.2p4
ID:
KPR.2011.04.27.009
Title:
Errors during Code Generation because of insufficient

documentation for "How to Create DD Look-Up Table Objects"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
507 / 1260
Description: The User Documentation contains insufficient step by step

descriptions for
creating Data Dictionary Look-Up Table Objects at:
1) TargetLink Advanced Practices Guide > Working with
Special TargetLink Blocks
> Look-Up Tables > Implementing Look-Up Tables > How to
Create DD Look-Up Table
Objects from Scratch in the Data Dictionary
2) TargetLink Advanced Practices Guide > Working with
Special TargetLink Blocks
> Look-Up Tables > Implementing Look-Up Tables > Create
DD Look-Up Table Objects
Based on a Model
Following these instructions leads to the following error
messages during code
generation because of a not complete Data Dictionary LookUp Table object:
Error #20356: //DD0/Pool/BlockSpecifications/Test/Map The
VariableRef
property has not been set for the Block object's BlockVariable
child object Map.
TlCTraceFallThrough.cpp_ 271.
Error #20356:
//DD0/Pool/BlockSpecifications/Test/NumAxisPoints The
VariableRef property has not been set for the Block object's
BlockVariable child
object NumAxisPoints.
Error #10016: The model analysis failed. Check the error
messages above for
further details.
508 / 1260
Workaround: To avoid these errors, please use in addition the following

corrected version of
the "How to Create DD Look-Up Table Objects":
1 Open the DD project file in the Data Dictionary Manager.
2 If no BlockSpecifications object exists in the Pool area, rightclick the
Pool object in the Data Dictionary Navigator and select Create
BlockSpecifications.
3 Right-click the BlockSpecifications object and select the
table object to
create from the context menu.
Next step: You need to reference the missing Related
Variable objects (e.g.
Table).
4 From the objects context menu select Edit Look-up Table
Settings.
5 If necessary, change the Look-up options.
6 Reference the missing Related Variable objects, for
example, Table.
Whether fields are enabled or disabled depends on the
settings of
the Look-up options. Referencing an Output variable is
optional.
Note: The Map variable must make use of the
IMPLICIT_STRUCT type definition.
7 Click OK.
509 / 1260
ID:
KPR.2011.04.27.010
Title:
Wrong overflow detection for TargetLink block in If Action

subsystem with output range not containing value 0

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For a TargetLink block which fulfills all of the following

conditions the
overflow detection warning always appears, no matter if the
signal value is
really outside the specified range:
- The block is located within an If Action subsystem
-- AND -- the specified output range (via scaling or user constraints)
doesn't contain
the value 0
-- AND -- the subsystem is not executed at the simulation start.
The warning looks like following:
Warning #02224: <blockname>:
Negative overflow detected in signal <signalname>
Workaround: Avoid the described configuration, otherwise no workaround
available.
patches:
TargetLink 3.1p7
510 / 1260
ID:
KPR.2011.04.28.001
Title:
Function reuse mechanism does not consider structures

specified in customer-specific function scripts

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A struct variable will not be reused, even if it is specified in a

way that it
should be reused, under the following conditions:
- the function is supposed to be reused AND
- some blocks or actions of the library subsystem or Stateflow
chart
representing that function are generated using a customerspecific function
script (also known as custom look-up function script or
Stateflow
customer-specific function script) AND
- the customer-specific function script specifies a structure
variable, for
example a look-up map structure.
511 / 1260
ID:
KPR.2011.04.28.002
Title:
Wrong code optimization of array elements if the array is

passed to a Stateflow User Function by reference via &a[0]

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink treats "f(&a[0])" for a scalar pointer formal of "f" as

access
to "a[0]" rather than all of "a". In the case of Stateflow custom
functions
this is wrong and may lead to unexpected and erroneous
optimization of
subsequent accesses to "a[1], a[2], ...".
Example:
loc is the array in question. The Stateflow action is written as
loc = 5;
userFunction(&loc[0]);
out = loc;
which the Code Generator translates to
Ca1_loc[0] = 5;
Ca1_loc[1] = 5;
Ca1_loc[2] = 5;
Ca1_loc[3] = 5;
userFunction(&Ca1_loc[0]);
Sa1_OutPort[0] = Ca1_loc[0];
and then "optimizes" to
Ca1_loc[0] = 5;
userFunction(&Ca1_loc[0]);
out[0] = Ca1_loc[0];
out[1] = 5;
out[2] = 5;
out[3] = 5;
Workaround: If Matlab R2010a or later is used:
- rewrite f(&a[0]) as f(a)
If a Matlab version before R2010a is used:
- Assign a variable class to the array that has unset
property AND
- switch off the code generator option
"ExploitRangesIndependentOfErasable".
Note: The expression f(a) will pass a temporary copy of a to
the function in
Matlab versions before R2010a.
512 / 1260
ID:
KPR.2011.04.28.003
Title:
No error message when atomic subchart is used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink does not support Stateflow atomic subcharts and

produces an error
message if one is found in a system (Simulink subsystem, or
model) that should
be prepared for TargetLink or code should be generated for.
If, however, the
parent Stateflow Chart resides in a library, no error message
appears. The
system seems to have been prepared correctly or code might
be generated for it,
but the code will be incorrect.
Workaround: Do not use systems with atomic subcharts for TargetLink.
ID:
KPR.2011.04.29.001
Title:
MIL simulation aborts for model containing Merge block with

muxed input signal

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: MIL simulation of TargetLink model aborts with an error

message like
[...]
Index exceeds matrix dimensions.
[...]
if,
- a Merge block is used, which has a muxed input signal
-- AND -- the number of inputs of the Mux block is specified via
workspace variable.
Workaround: Use numeric value to specify the number of inputs of the Mux
block.
patches:
TargetLink 3.1p7
513 / 1260
ID:
KPR.2011.05.03.001
Title:
Look-Up Table code generated for floating-point axis with

integer fraction is wrong

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The Code generated for an Index Search block is wrong for
floating-point data
types if
- the axis is using a float data type AND
- the fraction is using an integer data type.
In this case the code generator creates a superfluous
multiplication which leads
to wrong calculation results. The the calculated fraction value
is always zero.
For example the generated incorrect code (inside the index
search routine) could
look like this:
*fraction = (uint8) (Aux_F32 * 256.F);
correct code would be:
*fraction = (uint8) Aux_F32;
Workaround: Also use floating-point data type for the fraction.
patches:
TargetLink 3.1p10
TargetLink 3.2p5
514 / 1260
ID:
KPR.2011.05.19.001
Title:
Fatal error #10007 TlCIdsRestartEncapsulator 617 during

code generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink Code Generation may abort with 'Fatal #10007:

Internal error. Error
code: TlCIdsRestartEncapsulator 617. Contact dSPACE's
technical support team.'
if a genreated C code variable
- has a Variable Class with a non-empty
RestartFunctionName property AND
- this Variable Class has the ERASABLE flag set in the
Optimization property AND
- the Restart function initialization for this variable is generated
as a
for-loop AND
- the TargetLink Optimization can remove the variable from
the generated code.
Workaround: The following steps can be used to workaround the
problematic situtation after
the problem happend:
1. Set the Optimization level to 0 and inspect the generated
code for variables
that are initializied in a for-loop inside a Restart function.
These variables
are potentially problematic.
2. Remove the RestartFunctionName at the variable classes
of these variables.
Code generation should now succeed. Look which of the
variables are now longer
present in the generated code. This variables cause the
problem.
3. Choose/create another Variable Class without
RestartFunctionName for this
variables. Since this variables are removed by the TargetLink
Optimization the
initialization method shouldn't matter.
515 / 1260
ID:
KPR.2011.05.20.001
Title:
TargetLink block property "Inherit properties" is possibly

undesirable enabled in MATLAB R2008b and newer

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In MATLAB R2008b and newer, it is possible, that the

TargetLink block property
"Inherit properties" contains the boolean value "true"
nevertheless it is
specified as "false". This leads to the following problems:
- All scaling properties in the block dialog ("Type", "Scaling",
"LSB",
"Offset", "Min" and "Max" ) are disabled (invisible).
- The TargetLink API command tl_get returns default values
for these properties
(e.g. 2^0 for output.lsb or 0 for offset).
- The code is generated as if property inheritance would be
enabled although it
is disabled.
This behavior is non-deterministic.
The following TargetLink blocks are affected by this problem:
- Assignment
- Bus Inport
- Bus Outport
- D Flip-Flop
- D Latch
- InPort
- Merge
- MinMax
- Multiport Switch
- OutPort
- Rescaler
- Saturation
- Switch
- Unit Delay
- Unit Delay Reset Enabled
patches:
TargetLink 3.1p8
516 / 1260
ID:
KPR.2011.05.27.001
Title:
Data Dictionary validation fails after XML import of

ModuleOwnership objects

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In cases where ModuleOwnership objects are imported from

an XML file into the
current Data Dictionary and the ModuleOwnership objects
specify an ownership for
a system by its name - the property SystemName is set - the
Data Dictionary is
invalid after the import. The error origins from the property
CodeGenerationUnitRef, which is also set to its default value,
namely a
reference to the TL_DefaultCodeGenerationUnit.
Note, the validation error only occurs in cases of
ModuleOwnerhip objects that
specify the ownership of a system. A ModuleOwnership object
that specifies the
ownership of a DD-CodeGenerationUnit, will not produce a
validation error after
import.
A solution to handle the invalid Data Dictionary is to delete the
CodeGenerationUnitRef property for all ModuleOwnership
objects where a
SystemName property is set.
Example:
dsdd ('Delete','/Pool/ModuleOwners/<ModuleOwnership object
name>','CodeGenerationUnitRef')
where <ModuleOwnership object name> is the name of a
ModuleOwnershipObject.
Workaround: It does not exist a workaround, but a post-processing such as
described as
solution in the description fixes the invalid Data Dictionary
properties.
517 / 1260
ID:
KPR.2011.05.27.004
Title:
Error message E08664 misleadingly reported during A2L file

export

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If data pages are enabled by code generator option

"EnableDataPages" = "on", and
an A2L file is exported after code generation, an error
message like the
following is issued:
E08664: Name ambiguity found The names of the calibratable
variables:
'Psa_Page_0.<componentName>'
and
'Psa_Page_1.<componentName>'
do not lead to a unique CHARACTERISTIC names if page
switching is activated.
This error message is not correct and can be ignored.
Workaround: Ignore the error message.
ID:
KPR.2011.05.27.005
Title:
Logging of a signal inside AUTOSAR operation call

subsystem does not work

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Signal logging of a block variable of a block inside an

AUTOSAR operation call
subsystem does not work correctly.
With TargetLink 3.1 the signal will not be logged at all. With
TargetLink 3.2
the signal will be logged, but the signal is not mapped to its
corresponding
block. So the signal is plotted in different subplot or window for
MIL and SIL
simulation.
518 / 1260
ID:
KPR.2011.06.01.001
Title:
Incorrect code if a 'either' triggered subsystem or chart resides

in a subsystem with state reset

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink generates wrong production code, which may

result in MIL/SIL
differences, if all of the following conditions are fulfilled:
- A triggered block resides in a subsystem where state reset is
activated, for
example an enabled subsystem whose Enable port property
'States when enabling'
is set to 'reset' . Affected triggered blocks are
a.) triggered subsystems
b.) triggered and enabled subsystems
c.) triggered Stateflow Charts.
AND
- The triggered block has the trigger kind = "either" selected.
AND
- The triggered block is driven by a signal whose TargetLink
type is boolean or
an unsigned type.
AND
- If the triggered block is a triggered or triggered and enabled
subsystem, the
trigger port property 'Show output port' is not selected.
In this situtations in the generated production code the either
trigger
condition is always false after a state reset of the surrounding
state reset
subsystem.
Workaround: - Do not use a trigger variable whose type is boolean or an
unsigned type.
-- OR -- Select 'Show outport port' at the trigger port in case of a
triggered or
triggered and enabled subsystem.
-- OR -- avoid constellations where a either triggred block resides in a
subsystem with
state reset.
519 / 1260
ID:
KPR.2011.06.30.001
Title:
Wrong representation of case constant if switch variable has a

Stateflow fixed point type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow control flow is modeled in a way that the Code

Generator
transforms it to a switch-case construct and if
- the switch variable has a Stateflow fixed point data type and
if
- the TargetLink data type of the switch variable is an integer
type and if
- the TargetLink scaling is not set or has an Lsb = 1.0 and an
Offset = 0.0 and
if
- a case expression is a constant,
then the case constant might be wrong in the generated code.
Example:
If the Stateflow variable "var" has a TargetLink data type =
UInt8 and a
VOID_SCALING and its Stateflow data type is fixdt(0,8,0) the
generated code
might look like this
switch (var) {
case 0: { ... }
case 0 /* 2. */: { ... }
default: { ... }
}
Where the second case expression should be "case 2:"
instead of "case 0:".
This problem can be identified by looking for case constants
that differ from
the value that is given in a comment next to them.
The case constant must be the value from the comment (here
2) in the scaling of
the switch variable (here LSB = 2^0, Offset = 0.0).
On modeling switch case expressions in Stateflow refer to
TargetLink's Advanced
Practices Guide chapter Working with Stateflow > Flowchart
Style Guide > Switch
Statements.
Workaround: Replace the Stateflow fixed-point type by a build-in type at the
switch
variable.
ID:
KPR.2011.07.06.001
Title:
TargetLink upgrade may fail if Custom Code file is changed by initialization

commands of masked subsystems
520 / 1260

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: TargetLink upgrade may fail if a Custom Code block's Custom Code file
property
is changed by the initialization commands of a masked subsystem. As
Simulink
will execute the initialization commands during the upgrade, this can lead to
problems with S-Functions for the Custom Code block. Then the upgrade will
fail
with errors like this:
*** E03210: UPGRADE FAILURE:
*** Failed to upgrade block
***
'CustomCodeUpgrade/Subsystem/Subsystem/Subsystem/SsWithInit/Custom
Code
Block'
*** MATLAB error message was:
*** Error using ==> tl_upgrade>FcnUpgradeCustomCode at 2848
*** For S-function 'MyCustomCode_flp', the number of defined parameters,
2, does
not match the number of parameters on the dialog of
'CustomCodeUpgrade/Subsystem/Subsystem/Subsystem/SsWithInit/Custom
Code Block',
3. These two values must be identical.
*** F03250: UPGRADE FINISHED WITH ERRORS:
*** The system
*** 'CustomCodeUpgrade'
*** was upgraded with errors. See error messages above.
Note: in general be careful when using initialization commands, i.e. make
sure
to check error codes from API commands etc. - this increases the possibility
to
detect problems.
Workaround: If you encounter such errors, following workarounds may be helpful,
depending on
the actual situation:
1) Delete old Custom Code S-Function DLLs before starting the upgrade,
and then
let tl_upgrade() rebuild them during the upgrade.
-- OR -2) Keep Simulink from executing the mask initialization commands, e.g. by
removing it in the mask at the beginning of the upgrade process and add it
again
after upgrade finished (e.g. by using tl_post_upgrade_hook.m and
tl_post_upgrade_hook.m functions).
-- OR -3) Try to avoid using mask initialization commands where possible, e.g.
maybe
Mask Parameter Dialog Callbacks can be used instead to change TargetLink
Custom
Code block properties.
521 / 1260
ID:
KPR.2011.07.06.002
Title:
Container export doesn't consider the Data Dictionary active

variant

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The container export called by Data Dictionaries Export menu

or by MATLAB API
command tl_export_container doesn't consider the selected
active variant. The
Code Generator stores the generated source code and
header files into a folder
which name depends on the active variant. This folder is
different to the
standard output folder. The container export doesn't consider
this behavior
during the synchronization with the catalog standard output
folder and throws
the following error message:
Note Exporting AUTOSAR description for subsystem ...
*** F08800: ERROR DURING AUTOSAR EXPORT:
*** Internal Error. Please contact dSPACE Support.
*** [Context: >The system cannot find the path specified.
patches:
TargetLink 3.2p4
522 / 1260
ID:
KPR.2011.07.26.002
Title:
Data Dictionary Merge Explorer shows incorrect differences

when macro %MainDDDir% is used for included .dd files

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Comparing Data Dictionary project files with include files using
the Merge
Explorer does not show differences when the path to a
included file is defined
using the macro %MainDDDir%.
In such a case the Merge Explorer does not show any of the
Data Dictionary
objects contained in the included file of the compared project
file. This leads
to incorrect display of differences between the two compared
project files and a
merge of objects in the included file is impossible.
Workaround: Use the dsdd_compare command in MATLAB to see the
differences (no merge
possible).
-- OR -Separately compare the included files with the Data Dictionary
Merge Explorer.
ID:
KPR.2011.07.26.003
Title:
TargetLink Preferences Editor ignores changes of compiler path entries

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If several Code Generation Targets or Target Simulation Modules

(TSM) share a
cross compiler it may happen that it is not possible to change the
setting of
the compiler path with the TargetLink Preferences Editor. Any new
entry is
overwritten by the old one when reopening the Preferences Editor.
Workaround: Cleanup the preferences file manually. Open the file with
>>edit(fullfile(tl_env('GetApplicationSettingsPath'),'TLPreferences.xml'))
and save a copy of the file as backup. Then delete all unwanted entries
in the
section<CompilerPaths> and save the file.
Note that you have to delete the whole XML-Element <CompilerPath ...
/> to
remove an unwanted entry from the list of compiler paths.
TargetLink 3.3p1
523 / 1260
ID:
KPR.2011.08.23.001
Title:
Wrong code generated for constant Stateflow input used in

remainder operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow a remainder operation is specified and

- one of its operands is a Stateflow input
AND
- the 'Create variable for SF Input' property of this input is set
to 'off'
(which is the default)
AND
- the Stateflow input is preceeded by a Constant block that
has it's Variable
Class set to 'default'
then the generated production code for this remainder
operation will contain the
negative value of the constant in a cast instead of containing
the constant
value as operand. Further a warning like the following will be
issued by the
Code Generator: "Warning #31463: Subsystem/Chart Found a
remainder operation in
which operand <name> is scaled. This may lead to
differences between
floating-point and fixed-point simulation."
Example:
A Statechart is preceeded by a Constant block with value 7.
Expression in Chart: UInt8Var = Input %% UInt8Var;
The generated code will be
UInt8Var = (UInt8)(((Int32) -7) % UInt8Var)
instead of
UInt8Var = (UInt8)(7 % UInt8Var)
Note: If the Stateflow input is used as denominator of the
remainder operation,
then the generated code will produce correct results, because
x % y == x % -y.
But if the Stateflow input is used as numerator of the
remainder operation, then
the generated code will produce wrong results, as x % y != -x
% y.
Workaround: 1) If possible use a Variable Class other than 'default' for
Constant block.
OR
2) Set the property 'Create variable for SF Input' for the
Stateflow input
variable to 'on' (using the TargetLink Property Manager).
524 / 1260
ID:
KPR.2011.08.23.002
Title:
Incorrect code caused by incorrect rescaling of actual

argument in Rte_Call function call

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A Bus Inport block or a Bus Outport block is specified with

AUTOSAR
communication kind Client-Server. The specified operation
has at least two
operation arguments. One argument has a different scaling
than the first
operation argument.
In this case, the Code Generator generates an incorrect call of
the Rte_Call
function. It is assumed that all arguments of the Rte_Call
function have the
same scaling as the first operation argument. So an actual
argument with
different scaling as the first one will be rescaled to the scaling
of the first
operation argument in the function call.
Though the generated code is incorrect, only differences
between MIL and SIL/PIL
simulation in TargetLink are visible that seem to be a result of
quantization.
That is because TargetLink's internal implementation of the
Rte_Call for the
SIL/PIL simulation contains a rescaling to the correctly scaled
value.
Simulation differences only occur when trying to simulate
TargetLink's runnable
code with the correct RTE code.
Workaround: Replace the Bus Inport or Bus Outport by a subsystem that is
specified as an
AUTOSAR operation call. The subsystem must have exactly
one in- or outport for
every operation argument. It is not permitted to have
additional in- or
outports. The signal line that drives the Bus Inport or
emanates the Bus Outport
must be replaced by using Data Store Memory blocks.
patches:
TargetLink 3.1p9
TargetLink 3.2p4
525 / 1260
ID:
KPR.2011.08.24.001
Title:
Incorrect code for scaled Stateflow variables with Scope

'Temporary'

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow a variable x is defined that has the Stateflow

Scope property
set to 'Temporary' and if this variable has an offset or an LSB
< 1.0 then wrong
code might be generated.
This can cause relational operations to be erroneously
replaced if one of their
operands is the variable x.
Or it might lead to the loss of saturation code if x is an
operand on the right
hand side of an assignment.
Additionally, if x is operand of an arithmetic operation, this
operation might
introduce overflows, because the arithmetic operation might
be calculated in a
smaller type than necessary.
Workaround: 1) Change the Variable Class to make the variable static or
global.
OR
2) Set the Stateflow scope to 'Local'.
526 / 1260
ID:
KPR.2011.08.24.002
Title:
Optimization: Erroneously passing the address of a pointer

variable to a function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The TargetLink Code Generator optimization may not

correctly substitute
variables with pointer parameters resulting in an additional
and wrong reference
operator. This may happen if a scalar pointer parameter is
assigned to an
intermediate variable and this intermediate variable is used at
least two times
and at least one of this uses is a paramter of a function call
with an reference
operator:
foo(Int16* Param)
{
Var = *Param;
func1(&Var);
func2(&Var);
}
This situation can be erroneously optimized to:
foo(Int16* Param)
{
func1(&Param);
func2(&Param);
}
Correct code would look like:
foo(Int16* Param)
{
func1(Param);
func2(Param);
}
Workaround: Place a Rescaler block with a variable class that has no
ERASABLE flag set in
it's Optimization property ahead of the problematic inputs of
the subsystems
that result in func1() and func2().
ID:
KPR.2011.08.24.003
Title:
Optimization: Erroneous moving of Conditional Value

Assignment into a Conditionally Executed Control Flow
Branch
527 / 1260
TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink moves the code of Switch / Multiport Switch blocks

driving the input
of a conditionally executed system (or Switch / Multiport
Switch block) into the
respective conditionally executed control flow branch. This
happens on block
diagram and on C Code level. On C Code level the effect of
this optimization
looks like this:
if (cond1) {
b = a1;
} else {
b = a2;
}
if (cond2) {
...
c = b;
} ...
becomes
if (cond2) {
if (cond1) {
b = a1;
} else {
b = a2;
}
...
c = b;
} ...
If the else branch or the default branch of a switch directive,
respectively, is
missing, then the respective compound statement may not
assign a value to "b".
In this situation, moving the if or switch statement into a
conditionally
executed leads to wrong code in the majority of cases.
TargetLink performs this kind of erroneous optimization based
on its internal
representation of the C code to be generated.
The following preconditions must hold that this error can
occur:
- The if or switch statement containing the incomplete
definition of "b"
contains only direct assignments to a variable or its scalar
elements
(potentially in a loop) in its control flow branches.
AND
- For vectors and matrices, all control flow branches contain
assignments to the
same elements.
AND
- The right hand side does not contain calls to functions (or
528 / 1260
"calls" to macros)
with internal states or global communication or unknown
contents or operations
with side effect.
AND
- There must be a subsequent conditionally executed control
flow branch
containing all reading accesses of "b" (or its elements that are
defined in the
original if / switch statement).
AND
- There are no other value assignments to "b" / the respective
elements of "b".
Workaround: 1. Switching on the Code Generator option
'EnableBlockDiagramBasedSwitchOptimization' (TargetLink
>= 2.3, this is also the
default setting) decreases the likelihood of this kind of error,
as it activates
further mechanisms inside the Code Generator.
OR
2. Assigning a variable class without MOVABLE Optimization
property to the
variable taking the role of "b". If this is not directly possible,
then
introducing an intermediate variable that has such a variable
class, e.g. by
inserting a Gain block with gain factor 1 in the model.
patches:
TargetLink 3.2p4
529 / 1260
ID:
KPR.2011.08.24.004
Title:
Interpolation (n-D) Using Prelook-Up block may give wrong

results in MIL simulation mode due to incorrect TLC code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The problem only occurs if you drive the "Interpolation (n-D)
Using Prelook-Up"
not directly with a "PreLook-Up Index Search" block. In such a
case, because of
a wrong TLC file, driving the block with an input signal outside
of the allowed
ranges, leads to wrong MIL simulation behavior when using
the Simulink/RTW
generated code for simulation.
For example driving the Interpolation (n-D) Using Prelook-Up
block with an index
signal smaller than zero, the value has to be saturated to zero
by the code that
is generated by Simulink, but there is an error in the saturation
code so that
the inputs may become out of range.
The allowed input signal ranges are:
Index signal = [0 .. number of axis points]
Fraction signal = [0 .. 1]
Note: such code is automatically generated by Simulink and
used implicit for
blocks inside of a referenced model, or by running a MIL a
simulation in the
accelerator mode.
Workaround: 1) Add a saturation block to limit the fraction and the index
signal block
inputs to their allowed ranges.
-- OR -2) If you are not using "Common output for index and fraction"
and you are using
TargetLink 3.0 or newer with Matlab R2006b or higher, please
use the
"Interpolation Using Prelookup" and the "Prelookup" blocks
instead as found in
the tllib. These blocks are not affected, only the old blocks as
described
above. Note: since TL 3.0 these old "Interpolation (n-D) Using
Prelook-Up" and
"PreLook-Up Index Search" have been moved to the
tl_needs_upgrade.
ID:
KPR.2011.08.24.005
Title:
Generated A2L file may contain incomplete entries for struct

bitfield components

530 / 1260
TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In case in the generated production code a struct with bitfields

as well as with
non-bitfields components is definied, for example:
struct tag_StructWithBitfield {
const volatile UInt8 NoBitfieldScalar;
const volatile unsigned int Bitfield_A : 1;
const volatile unsigned int Bitfield_B : 1;
const volatile UInt16 NoBitfieldVector[3];
const volatile unsigned int Bitfield_C : 1;
}
and if this structure is calibratable, during A2L file generation
errors like
following are issued:
E8650: Error while attempting to access the Data Dictionary.
The error message
was:
E5070 The "NumberOfBits" property does not exist.
DD object path:
<DDSubsystemPathOfTheNoBitFieldComponent>
Related object: NumberOfBits
These errors are written in the a2lexport.log file, nevertheless
the A2L file is
generated.
However it contains incomplete entries for the bitfields
components:
MyStruct.Bitfileld_A /* Name */
"" /* LongIdentifier */
VALUE /* Type */
/* Address */
/* Deposit */
/* MaxDiff */
/* Conversion */
/* LowerLimit */
/* UpperLimit */
/end CHARACTERISTIC
531 / 1260
Workaround: 1) If possible avoid mixed structures with non-bitfield and

bitfield components
or
2) Create a substructure for the bit field components in the
root structure, for
example
struct tag_BitFieldStruct {
const volatile unsigned int Bitfileld_A : 1;
const volatile unsigned int Bitfileld_B : 1;
const volatile unsigned int Bitfileld_C : 1;
}; /* struct type created for variable: BitFieldStruct */
struct tag_MyStructSecond {
const volatile UInt8 NoBitFieldScalar;
const volatile UInt16 NoBitFieldVector[3];
const volatile struct tag_BitFieldStruct BitFieldStruct;
}; /* struct type created for variable: MyStructSecond */
532 / 1260
ID:
KPR.2011.08.24.007
Title:
The Signal Builder block's command "Run all and produce

coverage" leads to an error if signal histories are logged in
TargetLink MIL on MATLAB >= R2010b

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: It is possible to start more than one simulation at once via the
"Run all and
produce coverage" command of the Simulink Signal Builder
block.
In MATLAB >= R2010b, starting simulations in this way leads
to the error message
Error reported by S-function 'tl_mil_handler76_s' in '<a
href="matlab:open_and_hilight_system (...)">.../MIL
Handler</a>':
Internal error: Error invoking
tlds_copy_data("logSignalList",<blockPath>)
if the signal history of at least one block is to be logged during
TargetLink
MIL simulation.
NOTE: TargetLink overflow detection and min/max logging are
not affected by this
problem.
Workaround: 1) If signal history logging is required during MIL simulation in
MATLAB >=
R2010b, starting simulations via Signal Builder block
command "Run all and
produce coverage" must be avoided. Note that Simulink itself
does not support
logging in this case. Instead "normal" simulations can be
started separately via
Signal Builder block "Start simulation" button for each desired
Group.
2) Before using the command to produce the coverage data,
set TargetLink's
Global Logging option to "Do not log anything". Later switch
the option back to
the desired value (e.g. "Log according to block data").
533 / 1260
ID:
KPR.2011.08.24.008
Title:
Display problems in block dialogs when using workspace

variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: When using workspace parameters in block dialogs the

following problems can
occur:
- No actual minimum and maximum values are displayed for
these parameters in the
TargetLink block dialogs, instead "n.a." is shown.
- The workspace parameters may appear in red color in the
TargetLink block
dialogs in rare cases.
This affects all block parameter values except look-up table
values.
534 / 1260
ID:
KPR.2011.08.24.009
Title:
Incorrect code caused by recursive function call in if-else or

switch-case statement

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Following conditions are given:

- A subsystem contains an If Action Subsystem or an Switch
Case Action
Subsystem. One of its outports drives an Action-Triggered
subsystem indirectly
via From/Goto blocks.
- The Code Generator option
"EnableBlockDiagramBasedSwitchOptimization" is
enabled.
In this case, TargetLink may generate incorrect code
containing a recursive call
of the subsystem's step function. The generated if-else/switchcase construct in
the step function's body incorrectly calls the step function
itself.
"EnableBlockDiagramBasedSwitchOptimization"
-- OR -- Connect all If Action Subsystem or Switch Case Action
Subsystem outports
directly with Action-Triggered subsystems. Do not place
From/Goto blocks on the
event line between these blocks.
patches:
TargetLink 3.1p10
TargetLink 3.2p3
535 / 1260
ID:
KPR.2011.08.24.010
Title:
Generated A2L file contains wrong addresses if bit fields are not "unsigned int"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The ECU_ADDRESS in an A2L file can be wrong if a bit fields are used in
structures and the type of a bit field is not ?unsigned int? . For the generated
code the acutal C code type of a bit field can be specified in TargetConfig.xml
file which is located in
%DSPACE_ROOT%\Matlab\Tl\SrcFiles\<mycontroller>\<compiler>\TargetConfig.xml
at
element Bitfield->CodedType.
Note: In ANSI C a bit fields is always ?unsigned int?, but some cross compiler
supports bitfields with the type ?unsigned char?.
Please see the following example: All components of a structure have the
variable class ?DISP?. For the first structure ?MyStruct_NotOk? the
ECU_ADDRESS
of elements MyBfStruct and all following elements have wrong addresses.
The addresses of second structure ?MyStructOk? are for all elements correct.
struct MyStruct_NotOk {
UInt8 c_UInt8;
struct MyBfStruct
{
unsigned char bf_1 : 1;
}
UInt16 c_UInt16;
}
struct MyStructOk {
UInt8 c_UInt8;
struct MyBfStruct
{
unsigned int bf_1 : 1;
}
UInt16 c_UInt16;
}
Workaround: Keep the CodedType of a bit field to "unsigned int".
536 / 1260
ID:
KPR.2011.08.24.011
Title:
Code Generation aborts with a Fatal #99999 if a nonenhanced Inport is driven by a bus signal with constant and
non-constant values

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The Code Generator may abort with a Fatal #99999

(ACCESS_VIOLATION) if all of
the following conditions are fulfilled:
- An atomic subsystem has a non-enhanced Simulink Inport.
AND
- It is driven by a bus signal that contains constant values and
non-constant
values.
AND
- Some of the non-constant values are not used in the atomic
subsystem.
AND
- Furthermore, the bus signal has a signal branch that drives
the Inport of
another, reused subsystem or reused Stateflow chart
(Function Reuse).
Workaround: - Respecify the bus signal sources, so it contains only
constant values,
OR
- disable Function Reuse of the reused subsystem or chart,
OR
- place a scaling bus port (that is a virtual system with an
enhanced Bus In- or
Outport) right before the reused system.
ID:
KPR.2011.09.06.001
Title:
Erroneous elimination of empty preprocessor "Control Flow"

leads to wrong scope reduction or wrong elimination of
variables or wrong condition

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: 1) Wrong Control Flow

TargetLink is supposed to transform
# if COND
...
# else
/* Nothing */
# endif
to
537 / 1260
# if COND
...
# endif
Unfortunately, the optimization leads to an internal
representation that leads
to an output of
# if COND
...
# else
# endif
and treats the code as if only
...
were present.
This leads to unjustified reduction of output variables to
automatic storage
duration or elimination of these output variables without
consideration of their
initialization behavior and initial values.
2) Wrong Condition
TargetLink is supposed to transform
# if COND
/* Nothing */
# else
...
# endif
to
# if !COND
...
# endif
Unfortunately, the optimization leads to an internal
representation that leads
to an output of
# if !COND
# else
...
# endif
and treats the code as if only
...
were present.
The most important problem is that this leads to the opposite
of the intended
behavior with respect to conditional compilation.
Apart from that, this leads to unjustified reduction of output
variables to
automatic storage duration or elimination of these output
variables without
consideration of their initialization behavior and initial values.
As one example, a variable which is used in the remaining
control flow branch
and needs static storage as well as an initialization will be
optimized to local
scope without any initialization.
538 / 1260
Workaround: Scope reduction and elimination of variables can be avoided

by using variable
classes without set SCOPE_REDUCIBLE and ERASABLE
Optimization property (and
InitAtDefinition = on). Use global variables or scope reduction
downgrade chains
(via ScopeReducedClass property) stopping at Storage =
static, Scope = local.
All kinds of errors can be avoided if the model does not allow
for empty
conditional compilation branches. This may necessitate using
a PreprocessorIf
block or abstaining from manual merging (forcing "a=a"
patterns via the variable
class MERGEABLE Optimization property).
patches:
TargetLink 3.2p1
ID:
KPR.2011.09.19.001
Title:
Different scopes for the components of Bus Inports/Outports

at the interface of a referenced model may lead to wrong code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
539 / 1260
Description: If a Bus Inport block or a Bus Outport block at the interface of

a referenced
model fulfills all of the following conditions, TargetLink may
generate wrong
code:- The property "Create bus struct" for the components
and subcomponents of
the bus is not selected
AND
- The bus components are not specified to be components of
a structure specified
in the DataDictionary
AND
- differing scopes are specified for the bus components (via
different Variable
Classes).
Example:
For the the three leaf components a, b and c of a bus the
following variable
classes are specified:
- leaf component a -> VariableClass: GLOBAL (scope: global)
- leaf component b -> VariableClass: FCN_ARG (scope:
value_param)
- leaf component c -> VariableClass: FCN_REF_ARG (scope:
ref_param)
This specification will lead the following wrong code generated
for the
referencing system:
/* update(s) for inport TL_Subsystem/RefSystem/InPort1 */
SREF1_b_GLOBAL = *Sa1_e_CALLB_BY_REFERENCE;
/* call of function: TL_SS/RefSystem */
STEP_SREF1(Sa1_b_GLOBAL, Sa1_d_CALL_BY_VALUE);
The correct code would be:
/* update(s) for inport TL_Subsystem/RefSystem/InPort1 */
SREF1_b_GLOBAL = Sa1_b_GLOBAL;
/* call of function: TL_SS/RefSystem */
STEP_SREF1(*Sa1_d_CALL_BY_VALUE,
Sa1_e_CALL_BY_REFERENCE);
That means that the input variables of the referenced models
are updated with
the wrong variables in the generated code for the referencing
system.
Workaround: At Bus Inport / Bus Outport blocks of referenced models use
Variable Calsses
with same scopes for the bus components.
540 / 1260
ID:
KPR.2011.09.21.001
Title:
Compilation of the TargetLink simulation frame fails due

multiple logging of a variable generated with Access Function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The compilation of the TargetLink simulation frame may fail

during Build SIL or
Build PIL when a variable is used and logged at at least two
times in a model
and the log access happens in separate functions in the
generated code.
Additionally an Access Function must be used for the variable,
i.e. the variable
uses a Variable Class with a set AccessFunctionTemplate
property.
The compiler emit errors like this:
Error .\TLSim\<ModelName>\HostPC_LCC\<filename>.c: 193
unknown field `_var' of
`struct LOG_STRUCT_1'
Workaround: If possible the variable should be logged only once in the
model.
patches:
TargetLink 3.3p2
541 / 1260
ID:
KPR.2011.09.26.001
Title:
Wrong code when using non-scalar Stateflow constants or

parameters

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The Code Generator performs constant folding for Stateflow

expressions which can
be determined to be constant. For example, if A and B are
Stateflow data of
scope 'constant' or 'parameter' and A=2 and B=3, the
expression A*B will be
replaced with the constant 6. This behavior is independent of
the optimization
setting.
However, this transformation works only with scalar constants.
Non-scalar
constants are incorrectly treated as scalar constants, their
value being their
first element. For example, if C is a Stateflow data of scope
'parameter' and C
is initialized with the vector [5 6 7 8], the expression C*2 will
be replaced
with the scalar 10 (from C[0]*2).
This applies only to uses of non-scalar constants in
expressions all of whose
subexpressions are constant, except array subscript
expressions. Direct uses are
also unaffected.
Examples: (with the constants C=[5 6 7 8], A=2)
2 * A => 4 (correct)
1 << A => 4 (correct)
C + 2 => 7 (incorrect, expected [7 8 9 10])
C - A => 3 (incorrect, expected [3 4 5 6])
C == 6 => 0 (incorrect, expected [0 1 0 0])
Workaround: Disable constant folding for the affected data, i.e., specify a
non-ERASABLE
variable class like CONST or make the scope 'local' instead of
'constant'/'parameter'.
542 / 1260
ID:
KPR.2011.09.26.002
Title:
Reading of variable values by means of tl_sim_interface API

function does not work correctly after SIL simulation has finished

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: With the TargetLink simulation interface command

tl_sim_interface() it is
possible to write and read values of the global variables within
the production
code simulation application.
In the following case however, the reading of the variable values
will not work
correctly:
1) The Production code SIL simulation application is build
2) The SIL simulation is started
3) The SIL simulation is finished
4) The current values of the global variables after the SIL
simulation are
readout by means of tl_sim_interface commands:
- ConnectToSimPlatform
- Get*Addr
- Read
- DisconnectFromSimulationPlatform
In this case the read values are not the values after the SIL
simulation, but
the initial values of the variables at the beginning of the SIL
simulation.
NOTE: This problem does not occur for the PIL simulation mode.
Workaround: Before the SIL simulation is started already connect to the
simulation platform
by invoking hSim =
tl_sim_interface('ConnectToSimPlatform','BoardName','HostPC').
This means the steps described above must be carried out in
other order:
1) The Production code SIL simulation application is build
2) The connection to the HostPC simulation platform is establish
by means of the
tl_sim_interface command:
- ConnectToSimPlatform
3) The SIL simulation is started
4) The SIL simulation is finished
5) The current values of the global variables after the SIL
simulation are
readout by means of tl_sim_interface commands:
- Get*Addr
- Read
- DisconnectFromSimulationPlatform
543 / 1260
ID:
KPR.2011.09.26.003
Title:
Autoscaling Tool aborts with fatal error #03468 or #03461 for

Look-up Table blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Enhanced Simulink Lookup Table (n-D) blocks are not

supported by the TargetLink
Autoscaling Tool, independend of their dimension, so also 1D
and 2D.
Instead it will abort with error messages like:
Error #03461: ..../Look-Up Table: Could not call the
'tl_scale_lookup' block
function.
Fatal #03468: .../Look-Up Table: Could not determine the
output scaling of
'..../Look-Up Table' .
ERROR:Error using ==> i_scale at 674
TL_Lookup1D block (mask) does not have a parameter
named 'InputValues'.
Note that with TargetLink version 3.2 and later also the Lookup Table 1D and 2D
blocks in the TargetLink library have been realized via
enhanced Simulink Lookup
Table (n-D) blocks for MATLAB Releases >= R2010a due to
future deprecation of
these blocks in the Simulink itself.
Workaround: Use Simulink Lookup Table (1D) and Lookup Table (2D)
blocks instead of Lookup
Table (n-D), if possible.
This also means on MATLAB >= R2010a instead of directly
using the Look-up Table
blocks from the TargetLink library, use the Simulink library
blocks and enhance
them. Since R2011a these blocks have been deprecated in
Simulink, though.
544 / 1260
ID:
KPR.2011.10.11.001
Title:
MIL/SIL or MIL/PIL simulation differences for the Relay block if

SwitchOff == SwitchOn

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the SwitchOn value is equal to the SwitchOff value for the
Relay block then
TargetLink generates code that differs from the Simulink
simulation behavior as
follows:
If the input singal of the Relay block is equal to SwitchOn or
SwitchOff
respectively, then Simulink holds OutOn (MIL) but the
generated code OutOff
(SIL/PIL).
Workaround: Avoid equal values for SwitchOn and SwitchOff
OR
use a Switch block instead of a Relay block to model with
clear semantics.
545 / 1260
ID:
KPR.2011.10.17.001
Title:
Wrong code generated for left shift operations specified in

Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow a left shift operation is specified, internally the

Code
Generator incorrectly treats the result of the operation as 0.
This leads to
generation of wrong production code surrounding such left
shift operations.
Example:
The condition for entering a transition is
[(UInt8Var << 8) + UInt8Var2 == 300]
with UInt8Var and UInt8Var2 being variables with the
TargetLink data type UInt8.
In that case the Code Generator erroneously assumes that
the result of the shift
operation is 0.
That reduces the condition to [UInt8Var2 == 300] which can
never be true and
will therefore be removed.
Workaround: 1) Introduce a global or static auxiliary variable to hold the
result of the
left shift operation and break the complex expression.
For the above example: UInt16Temp = UInt8Var << 8; and
then use [UInt16Temp +
UInt8Var 2 == 300].
-- OR -2) Replace the left shift operation by a multiplication, e.g.
[(UInt8Var*256) +
UInt8Var2 == 300].
ID:
KPR.2011.10.17.002
Title:
Incorrect rounding in generated code for relational operations

with arbitrary scaled negative operands or if ShiftMode is set

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
546 / 1260
Description: The result of relational operations can be wrong, if

- both operands have different scalings AND
- both operands can have a negative value AND
- the value of the operand with the smaller LSB cannot be
represented in the
scaling of the other operand AND
- both operands will be represented by a variable or macro in
the generated code
AND
- the quotient of both LSB is not a power of two OR if the Code
Generator's
ShiftMode option suppresses the generation of shift
operations in the generated
code.
In addition to this conditions
a) the LSB of the first operand has to be less or equal to the
LSB of the second
operand and the relational operation has to be < or >=.
--OR-b) the LSB of the first operand has to be greater than the LSB
of the second
operand and the relational operation has to be > or <=.
In those cases erroneous rounding might be applied in the
generated code.
The erroneous code can be identified, if the specified
relational operation has
an operand whose value becomes smaller due to shifting to
the right or due to a
combined multiplication and division whose value is smaller
than 1 or due to a
division.
Example:
Int32 I32Var = -100001; // LSB = 0.0001
Int16 I16Var = -10 /* -10.0*/; // LSB = 1.0
Comparing these variables will create an operation like
I32Var / 10000 < I16Var
Since I32Var represents the value -10.0001 and I16Var
represents -10.0, the
result of the relational operation should be true.
But it will be false since -100001 / 10000 = -10.0001 which is
rounded to -10
In this example erroneous results can come up for the values 10.0001 to
-10.9999... for I32Var, if I16Var stays -10.0.
patches:
TargetLink 3.1p9
TargetLink 3.2p4
547 / 1260
ID:
KPR.2011.10.18.001
Title:
Preparation of Simulink model aborts with an error message

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A Simulink model (e.g. a referenced model, as opposed to a Simulink subsystem

or
a library model) should be prepared for TargetLink. On root level the model
contains an Inport block that is directly connected with an Outport block. In
this case the preparation aborts with an error message:
??? Error using ==> get_param
block_diagram does not have a parameter named 'PortConnectivity'.
Error in ==> tl_check_system>FcnInportEnhanced at 2233
pCon = get_param(get_param(pCon.DstBlock,'Parent'),'PortConnectivity');
Error in ==> tl_check_system>FcnCheckSystem at 931
elseif ~FcnInportEnhanced(bs.hTopLevelInports(i),hSavedDataInports)
Error in ==> tl_check_system at 267
[bs,msgStruct,options] = FcnCheckSystem(bs,options);
Error in ==>
D:\TargetLink\TL3.1\TL3.1\matlab\tl\tools\tl_prepare_system.p>tl_prepare_system
at 407
Workaround: 1) Before starting preparation delete the direct Inport-Outport signal
connection and restore it when preparation has finished.
OR
2) Already enhance the port blocks before starting preparation.
548 / 1260
ID:
KPR.2011.10.18.002
Title:
Memory allocated for logged simulation data is not released

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Memory which is allocated to store logged simulation data is

not released after
usage.
This leads to the following effects:
- Additional memory is occupied for new simulations, even if
the maximum number
of simulations specified in the TargetLink Main Dialog is
already reached.
- It is not possible to free the occupied memory by removing
the obsolete
simulations in the TargetLink Main Dialog
This problem affects MIL, SIL and PIL simulations with logged
signals.
Workaround: The occupied memory can be released with following
commands:
>> clear tlds;
>> clear tl_mil_handler<current Simulink version>_s (e.g.
'tl_mil_handler73_s'
in Simulink 7.3)
Be careful because all TargetLink simulations are removed
from memory by these
commands. If you need them for later comparisons or
analysis, first save them as
mat files from TargetLink Main Dialog, 'Simulation' page.
patches:
TargetLink 3.2p4
549 / 1260
ID:
KPR.2011.10.18.003
Title:
Changes to certain TargetLink global preferences may not

become immediately active

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Changes to certain TargetLink global preferences may not

become immediately
active, e.g changes to the list of preselected Target Simulation
Modules (TSM)
or the selected MEX compiler. This may then lead to missing
entries in the
drop-down lists of the Main Dialog or errors when building SIL
simulation, as
the updated preferences are not detected by the Main Dialog.
Workaround: You can use one of the following workarounds:
- Type in Matlab command window:
tl_global_options('refresh'); and re-open the
Main Dialog.
OR
- Restart Matlab.
ID:
KPR.2011.11.08.003
Title:
Code generation may crash if japanese characters are used in

Simulink block names

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The use of japanese characters in Simulink block or

subsystem names may lead to
a crash in code generation on systems with a Japanese
Windows installation.
Workaround: Do not use japanese characters for block names.
Note: also compare common Modeling Guidelines on this
topic.
patches:
TargetLink 3.2p4
TargetLink 3.3p1
550 / 1260
ID:
KPR.2011.11.15.001
Title:
Code generator incorrectly aborts with error about cyclic

includes when using nested implicit bus structures

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may terminate with an error message like the
following:
Error #17066: Cyclic includes detected: subsystem.h, udt_a.h
Type <structure type> is defined in 'udt_a.h', also used in
'subsystem.h'.
This may occur if
- a nested bus with at least 3 tiers is used, i.e. a bus which
contains a bus
which contains another bus AND
- in the associated bus port block(s) "Create bus structure"
property is enabled
for the complete bus hierarchy AND
- the types of the bus structures are implicit, i.e. either the
predefined type
IMPLICIT_STRUCT or user-defined struct types without
components AND
- the bus is passed by reference, i.e. the outermost bus has a
variable class of
FCN_REF_ARG or similar.
Workaround: 1) Set the code generator option 'StrictTypedefPlacement' to
'off'. This option
can be found via TargetLink Main Dialog > Advanced Tab >
All Options... > Code
Generation or set via in a pre_codegen_hook function.
-- OR -2) If the outermost bus structure type is a component-less
struct type: Set its
ModuleRef property to some Module (which may have to be
created for that
purpose).
551 / 1260
ID:
KPR.2011.11.15.002
Title:
Incorrect error message about wrong dimensions when

selecting a Data Dictionary variable for the table in TargetLink
Interpolation block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface

table with the
dimension [n m], then the current Width property in Data
Dictionary is also [n
m].
Selecting this variable for the table variable of a TargetLink
Interpolation
block incorrectly results in an error message like the following:
<ddvar>.width = [n m]
Workaround: Set the table variable using the Property Manager or the
TargetLink API, e.g.
tl_set(<block>,'table.Variable', '<ddvar>').
patches:
TargetLink 3.1p10
552 / 1260
ID:
KPR.2011.11.18.001
Title:
Generated code for an operation involving 64bit arithmetics

and vectorial auxiliary variables may be wrong

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If for a vectorial operation

- the use of 64bit arithmetics is needed AND
- the Code Generator is forced to introduce an auxiliary
variable AND
- the 64bit operation is calculated inside a loop in the
generated code AND
- the results of the 64bit operation are further needed outside
of the loop
then this auxiliary variable may incorrectly be defined as
scalar, leading to
wrong behavior of the generated code, as only the result of
the last vector
element is kept.
Example:
for (Aux = 0; Aux < 4; Aux++)
{
C__I64MULI32I32(IF_Sa1_InPort[Aux], Sa2_Sum4, Aux_hi,
Aux_lo);
}
Aux_hi and Aux_lo are only scalar, should be
for (Aux = 0; Aux < 4; Aux++)
{
C__I64MULI32I32(IF_Sa1_InPort[Aux], Sa2_Sum4,
Aux_hi[Aux], Aux_lo[Aux]);
}
Workaround: Switch off the Code Generator Option
'OptimizedVectorProcessing'.
553 / 1260
ID:
KPR.2011.11.18.002
Title:
Wrong generated code if bit operation blocks are used in

reused systems and instance-specific parameter values

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Using one of the blocks Bitwise Operator, Blocks Bit Clear, Bit
Set, Shift
Arithmetic and Extract Bits inside of a function reuse system
and
instance-specific parameter values, the generated code is
wrong and compilable.
Example:
A reused subsystem contains a Bit Set block, the Bit-Index
parameter is set
according to a Mask variable of the reused Subsystem. This
subsystem is used
twice, once with
Bit Index value 1 and once with Bit Index value 2. Then the
resulting code may
look like the following (incorrectly for both code instances the
fixed Bit Index
value 2 is used instead of an instance-specific value):
Void TL_SS(Void)
{
STEP_REUSED(Sa1_InPort1, &(Sa1_OutPort2));
STEP_REUSED(Sa1_InPort1, &(Sa1_OutPort1));
}
static Void STEP_REUSED(UInt16 SREUSED1_InPort,
UInt16 * SREUSED1_OutPort)
{
*(SREUSED1_OutPort) = SREUSED1_InPort | 2;
}
Workaround: - For a Bitwise Operator block with "Use bit mask" enabled
use a Variable Class
with explicit global scope to get correct code.
- Using a Bitwise Operator block with "Use bit mask" disabled
and specification
of the bit mask in a driving Constant block does not lead to the
misbehavior.
- For the blocks Bit Clear, Bit Set und Extract Bits use a
Bitwise Operator
block instead to work around the problem (with workaround
like above).
- The use of a Shift Arithmetic block with "external source"
enabled and
specification of the shift count in a driving Constant block does
not lead to
the misbehavior.
554 / 1260
ID:
KPR.2011.11.18.003
Title:
Matlab crash because of For Iterator subsystem with reseting

states

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a For Iterator subsystem resides in a subsystem

representing a function that
is inlined in the generated code and if
- two further subsystem that result in inlined functions
(function fcn_a() and
fcn_b()) follow that For Iterator subsystem and if
- the For Iterator block of the For Iterator subsystem has the
property 'States
when starting' set to 'reset' and if
- no blocks that have any states reside in the For Iterator
subsystem and if
- the subsystems representing the functions fcn_a() and
fcn_b() contain blocks
that have vector signals and if
- not all the calculation done in fcn_a() can be merged into a
single loop and
if
- all the calculation done in fcn_b() can be merged into a
single loop and if
- the subsystem representing function fcn_b() follows directly
fcn_a() and if
- fcn_b() is not directly followed by a block with the same
vector with,
then the code generation might cause Matlab to crash.
Note: Vector calculations can be merged into single loops, if
the widths of the
associated vectors are equal.
Workaround: 1) Change the 'States when starting' property of the For
Iterator block
2) or suppress the inlining of the affected subsystems.
555 / 1260
ID:
KPR.2011.11.18.004
Title:
Problems during subsystem to referenced model conversion of an

incremental subsystem with library link

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Conversion of an incremental subsystem into a referenced model

(via TargetLink
Main Dialog or API function tl_subsystem_to_refmodel) leads to the
following
problems, in case the incremental subsystem has a library link:
1) Matlab < R2011a
The conversion works, however the blocks at the root level of the
newly created
referenced model still contain library links to the corresponding
blocks within
the incremental subsystem that the referenced model has been
converted from.
Furthermore the numbering of the root TL_Inport blocks within the
model changes,
which leads to different meanings of the corresponding inports of
the
incremental subsystem and of the model reference block.
For example, the n-th inport of the incremental subsystem should be
connected
with the signal A, whereas in the model reference block the n-th
inport should
be connected with the signal B. Since the connection lines are not
affected by
the conversion, the n-th inport of the model reference block is still
connected
to the signal A, what leads to wrong system behavior.
2) Matlab >= 2011a
The conversion is not possible at all. Error similar to the following
one is
issued:
*** E03312: SUBSYSTEM TO MODEL CONVERSION FAILED:
*** Conversion subsystem <incrSubsystemPath> to referenced
model failed. The
Simulink message was:
***
*** Error using ==>
Simulink.SubSystem.convertToModelReference>set_IO_attributes_l
at 643
*** Cannot change param 'PortDimensions' because
'r_AirflowCalculation/throttle
(estimated)' is linked. The parameter can only be changed on the
master in the
library
Workaround: Break the library link of the incremental subsystem before
converting it into a
referenced model.
556 / 1260
ID:
KPR.2011.11.18.005
Title:
SIL/PIL simulation aborts with an error for unconnected

incoming signals connected to a Terminator block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Starting a SIL/PIL simulation will lead to a model initialization

error if the
following conditions are fulfilled:
- the incoming signal of a TargetLink Subsystem is a data
signal
OR
- the incoming signal of a TargetLink Subsystem is a bus
containing data signals
AND
- inside the TargetLink Subsystem the incoming signal is not
connected
OR
- inside the TargetLink Subsystem the incoming signal is
connected to a
Terminator block without a computing block between the
Simulink Inport block of
the TargetLink Subsystem and the Terminator block AND
- in TargetLink 3.x the Simulink Inport block of the TargetLink
Subsystem
passing the incoming signal is not enhanced
OR
- in TargetLink 2.x the Simulink Inport block of the TargetLink
Subsystem
passing the incoming signal is not followed by a TargetLink
Inport block
If the incoming signal is a not a bus OR
the incoming signal is a bus AND the TargetLink version is
lower than 3.1 errors
like the following will be thrown:
Invalid "function-call" connection.
Function-call trigger port of 'model_name/TL_Subsystem/Sfunction frame' must be
driven by an S-function. 'model_name/Constant2' is not an Sfunction.
If the incoming signal is a bus and the TargetLink version is
3.1 or higher
errors like the following will be thrown:
Invalid setting for output port dimensions of 'model_name/Bus
Creator'. The
dimensions are being set to [-1]. This is not valid because the
total number of
input and output elements are not the same
Error in port widths or dimensions. Invalid dimension has been
specified for
input port 2 of 'model_name/TL_Subsystem'
557 / 1260
Workaround: There are several different workarounds:

1) Delete all incoming signals of the TargetLink subsystem
which are not
connected or connected to a Terminator block.
2) Or in TargetLink 3.x enhance the Simulink Inport block of
the TargetLink
Subsystem.
3) Or in TargetLink 2.x place a TargetLink Inport block after
the Simulink
Inport block if the signal is not a bus.
4) Or in TargetLink 2.x place a TargetLink Bus Inport block
after the Simulink
Inport block if the signal is a bus.
ID:
KPR.2011.11.18.006
Title:
Missing or wrong saturation code for Unit Delay block when

the type of the state is greater than the output type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Unit Delay block has

- saturation activated on the output tab
AND
- the type specified for the state variable references a Data
Dictionary
Variable object
AND
- the Variable object's data type is wider than the block output
type (e.g.
Int32 vs. Int16)
then saturation may be omitted or saturation to the type of the
state is
implemented in the generated code, which is both wrong.
There should be
saturation code which saturates to the type limits of the output
variable.
Workaround: If possible use the same type for state and block output of a
Unit Delay block
if saturation is activated for the block output.
patches:
TargetLink 3.3p1
558 / 1260
ID:
KPR.2011.11.21.001
Title:
Exported Stateflow function or truthtable in incremental

system leads to code generation error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An exported graphical function or truthtable as part of a chart

inside an
incremental subsystem prevents the TargetLink code
generator to succesfully
capture the model. The code generator stops with an error
message referring to
the function / truthtable:
Error #15305: <path_of_exported_function> Failed to get the
block data for the
TargetLink block.
The message appears when code for the TargetLink
Subsystem that hosts the
incremental subsystem is generated.
patches:
TargetLink 3.3p2
559 / 1260
ID:
KPR.2011.11.21.002
Title:
Child objects of a Data Dictionary object moved per "Cut" and

"Paste" from one workspace into another one cannot be
selected in the target workspace

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If the Data Dictionary Manager is used to move an object from

one Data
Dictionary workspace to another, this object's child objects
can no longer be
selected in the target workspace.
Moving an object is achieved with a Cut+Paste operation.
Note that moving an
object means that the complete Data Dictionary subtree that is
constituted by
this object is moved.
When the DD Matlab API is used to move the object, the child
objects' "treeIdx"
attribute still relates the Data Dictionary index of the original
workspace.
These effects do not apply to the object that has been moved,
but only to the
objects underneath.
Workaround: Save the target workspace to file, close and re-open it.
patches:
TargetLink 3.3p1
560 / 1260
ID:
KPR.2011.11.28.001
Title:
Saturation in the generated code for a Saturation block driven

by MinMax block may be missing

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a MinMax block is followed by a Saturation block and if

- the data type and scaling of the Saturation block and the
MinMax block are
equal AND
- the MinMax block is saturated AND
- the Code Optimization Level is set to a value > 0,
then the saturation in the generated production code for the
Saturation block
may be missing.
Workaround: Insert a TL 3.x Rescaler or a TL 2.x Outport block with Inherit
properties set
to on between the MinMax block and the Saturation block.
-- OR -Between the MinMax block and the Saturation block insert a
Gain block with gain
value 1 and the same data type and scaling as its
predecessor, i.e. as the
MinMax block.
561 / 1260
ID:
KPR.2011.11.29.001
Title:
Optimization: Erroneous Replacement if an Intermediate Index

Vector is Involved

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given a use case that selects one index of a vector that itself
is a copy of a
permutation or subset of another vector, TargetLink may build
an inccorect index
access in the generated code.
Example:
The indices stored in "Index[]" are selected from array "a" and
stored in array
"b". A subsequent operation uses only an arbitrary index "i" of
"b", e.g. based
on a calculation:
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32) {
b[Aux_S32] = a[Index[Aux_S32]];
}
...
do {
...
i = ...;
condition = f(b[i]);
...
} while (condition && (iter <= 9));
In this case, TargetLink can eliminate "b" but instead of
condition = f(a[Index[i]]);
TargetLink keeps the original index variable:
condition = f(a[Index[Aux_S32]]);
or omits "Index":
condition = f(a[i]);
Workaround: Make sure
- that the selection "b[i]" cannot take place (by inserting a
Rescaler block
with a non-ERASABLE variable class for the output variable)
OR
- that "b" has a variable class that is not ERASABLE
Note: ERASABLE is specified via the Optimization property of
a variable class.
562 / 1260
ID:
KPR.2011.11.29.002
Title:
Autoscaling based on simulated ranges and without Netlist

aborts with an error if Busport blocks are present in the model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Running the Autoscaling tool based on simulated ranges

message on the MATLAB command line if
- Busport blocks are present in the model AND
- no Netlist is created/used for the Autoscaling.
The resulting error message is like:
Undefined variable "busData" or class "busData.widthVector".
patches:
TargetLink 3.3p1
ID:
KPR.2011.12.05.002
Title:
Generated code contains wrong Pre/Post

Declaration/Definition Statements when using preprocessor
control flow for variable definitions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When using preprocessor control flow via the

"UseProprocessorIf" Variable Class
property together with Variable Class Declaration Statements,
the resulting
declaration statements in the generated production code may
be wrong. Both
superfluous or missing statements may occur.
patches:
TargetLink 3.2p4
TargetLink 3.3p1
563 / 1260
ID:
KPR.2011.12.07.001
Title:
Direct Look-Up Table blocks are unusable on MATLAB R2009a when a

system has been cleared from Targetlink data

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: When a system (model, TargetLink subsystem, or library) is cleared from

Targetlink data using the Clear System Tool, Direct Look-up Table blocks
lose
their block icon, and the blocks' dialogs no longer work. When the system is
re-prepared for Targetlink, errors come up and the blocks are replaced by
Targetlink Custom Code blocks.
When a TargetLink Direct Look-up is de-enhanced manually, it loses its
block
icon, and the block's dialog no longer works. Re-enhancing for TargetLink
results in an error message.
This problem comes up only with MATLAB R2009a (Simulink 7.3).
Workaround: After clearing the system correct the block references. E.g. create or edit a
file which name contains "post_clear_hook" in the working directory. Paste
the
following lines into this file:
if get_param(0,'version') < 7.4
hLuts = find_system(hSubSystem, ...
'LookUnderMasks','all', ...
'BlockType','S-Function', ...
'FunctionName','sfun_nddirectlook', ...
'MaskType','');
for i=1:numel(hLuts)
set_param(hLuts(i),'ReferenceBlock',sprintf('simulink/Lookup\nTables/Direct
Lookup\nTable (n-D)'));
end
end
ID:
KPR.2011.12.07.002
Title:
MATLAB error 'Undefined function or variable

'matRefModelBlockDataList'' appears during MIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
564 / 1260
Description: During MIL simulation, TargetLink generates temporary mat

files named
<referenced model>_tlds_logdata.mat if logging is enabled for
at least one
referenced model. The purpose of these files is to provide
read access to
simulation-specific TargetLink block data from referenced
models. This is
necessary because referenced models are not opened in
Accelerated simulation
mode. Instead their S-function's are used for calculation.
If all of the following conditions are met
- the MIL simulation is started via the Main Dialog or via the
TargetLink tl_sim
API command AND
- the logging in at least one referenced model is enabled AND
- at least one file <referenced model>_tlds_logdata.mat
related to a logged
referenced model exists in the search path, which was created
by TargetLink
version 3.2 or older, then the following MATLAB error
message may appear:
??? Undefined function or variable
'matRefModelBlockDataList'.
Error in ==> tl_sim at 216
if ~isfield(matRefModelBlockDataList, 'portDataLoggingName')
Error in ==> tl_maindialog_dlg>FcnManageSystemIcons at
288
tl_sim(dlgdata.model, 'gui');
Error in ==> tl_maindialog_dlg at 173
[dlgdata, bModified] =
FcnManageSystemIcons(dlgfig,dlgdata,pageAction);
Error in ==> d:\dSPACE\TargetLink
Setup\Matlab\Tl\dlg\dstabdlg.p>FcnManageSystemButtons at
1049
Error in ==> d:\dSPACE\TargetLink
Setup\Matlab\Tl\dlg\dstabdlg.p>dstabdlg at 156
??? Error while evaluating uipushtool ClickedCallback
Workaround: Delete all '<referenced model>_tlds_logdata.mat' files created
by TargetLink 3.2
or older from the directories in the search path.
patches:
TargetLink 3.3p1
565 / 1260
ID:
KPR.2011.12.07.003
Title:
Custom Code block vector state variables with scalar initial

condition produce access violations during simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: TargetLink Custom Code blocks with state variables that are
vectors and are
initialized by scalars may produce access violations during
MIL/SIL/PIL
simulation.
Workaround: Specify an initial value whose size matches the state
variable's number of
elements.
patches:
TargetLink 3.3p1
ID:
KPR.2011.12.07.004
Title:
Code generation aborts with fatal error #99999 when using an

access function at a Look-Up Table block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The Code Generator may abort with a fatal error #99999 when
a Variable Class
with AccessFunctionTemplate is used at the Table or Axis
variable of Look-Up
Table block and the 'Generate Map Struct' flag is set.
Note: since TargetLink 3.3 this situation is additionally limited
to
AccessFunctionTemplates which have the Kind ADDRESS,
ADDRESS_BY_PARAMETER or
DIRECT and the FunctionClass property references a class
with Macro = 'on'.
Workaround: 1) Disable 'Generate Map Struct'.
2) Or for TargetLink 3.3 or newer versions choose a Variable
Class for the Table
and Axis variable that does not use an
AccessFunctionTemplate with the properies
mentioned above.
patches:
TargetLink 3.3p1
566 / 1260
ID:
KPR.2011.12.07.005
Title:
Vector variable in A2L file has wrong scaling information for

COMPU_METHOD

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A production code variable in the A2L file may have a wrong
scaling information
for COMPU_METHOD if the variable
- is a Data Dictionary variable
- AND is a vector
- AND it's Scaling property references 'VOID_SCALING'
- AND the variable references a Typdef object with a
Contraints object
- AND that Constraints object references a Scaling object with
LSB != 2^0 or
Offset != 0.
The scaling in the A2L file is incorrectly LSB = 2^0 and Offset
= 0.
Note: this is only a A2L file problem. The generated
production code is correct
as the Scaling at the Typedef overwrites the Scaling at the
Variable object.
Workaround: Use the same Scaling object for the Data Dictionary Variable
object and for the
Typdef object.
patches:
TargetLink 3.3p1
ID:
KPR.2011.12.09.001
Title:
Confusing error message or wrong code generated for Data

Dictionary struct Variable objects with the same name or
unsupported name macros

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
567 / 1260
Description: If two or more Data Dictionary struct Variable objects have the
same name or a
name macro that results in the same code identifier and are
used in the same
model then TargetLink may internally create only one variable
and issue
confusing error messages like
Error #15505: Component <component> not found in
structured type <type>.
or
Error #17441: The block <block> uses the struct component
<component>. The
struct component is used multiple times. This is not allowed,
since the
component is associated with a variable class that has no
mergeable attribute
set.
Additionally TargetLink does not support the use of a Data
Dictionary struct
variable as template variables. I.e. you can not use name
macros that evaluate
to different values at different places in the model like $S, $I,
etc. so that
multiple instances appear. Unfortunately TargetLink does not
give a proper error
message that this is not supported. Instead TargetLink may
emit one of the
messages above. Please note that the approach of using Data
Dictionary Variable
objects as templates works fine for non-struct variables.
In both situations, i.e. using two or more struct variables with
same code
identifier or using a struct variable as templates, using a
variable class with
Optimization:MERGEABLE at the components of the struct
can lead in rare cases to
wrong code since TargetLink
may generate less struct variables than expected.
Workaround: Make sure that all Data Dictionary struct variables have uniqe
names (the use of
$R is not sufficient) AND do not use Data Dictionary struct
variables as
templates for multiple instances, i.e. do not use name macros
that evaluate to
different values in different locations in the model, like $S, $I,
etc.
patches:
TargetLink 3.3p3
568 / 1260
ID:
KPR.2011.12.19.001
Title:
MIL/SIL simulation differences because Look-Up Method

without interpolation incorrectly synchronized between
TargetLink and Simulink

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a Simulink Lookup Table (n-D) block is used in TargetLink

(either by model
preparation of such a block or by using the 1D/2D Look-Up
Table blocks from the
TargetLink library on MATLAB R2010a or newer) and the
interpolation method is
"None - Flat", i.e. without interpolation, then TargetLink
incorrectly uses it's
Look-Up Method "Use Input Nearest". Correct would be "Use
Input Below" which
corresponds to the Simulink behavior.
Even after changing the Look-Up Method in the TargetLink
block dialog the method
is not correctly stored in the TargetLink block data. Thus after
re-opening the
block dialog the method is reset to "Use Input Nearest".
In such case the TargetLink Code Generator will also use
"Use Input Nearest"
which may lead to different MIL/SIL simulation results.
Note: if Simulink Lookup Table and Lookup Table 2D blocks
are used with
TargetLink the problem does not apply, as these Simulink
blocks support all
Look-Up Methods of TargetLink directly. Please note that from
MATLAB R2011a the
Simulink 1D/2D Lookup Table blocks became unified with the
n-D block (as
dimension 1 or 2).
patches:
TargetLink 3.2p4
569 / 1260
ID:
KPR.2011.12.22.001
Title:
Wrong MIL simulation results as non-scalar Custom Code

block states are not initialized correctly

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In Targetlink Custom Code block S-functions non-scalar state

variables are not
initialized correctly if the "Use production code for floatingpoint simulation"
property is set to "off". This has an impact on MIL simulation
results.
Workaround: 1. Set the "Use production code for floating-point simulation"
property to "on".
or
2. Add initilization code to the flp_init section of the custom
code file, for
example with a state variable x[256]
/* flp_init_begin */
for(i=0; i<256; i++)
{
x[i] = 0;
}
/* flp_init_end */
570 / 1260
ID:
KPR.2012.01.02.002
Title:
TargetLink simulation frame does not work with

"Underspecified initialization detection" set to "Simplified"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In Simulink's Configuration parameters the "Data

Validity/Underspecified
initialization detection" option can be set to "Simplified" or
"Classic" (which
is the default). This option has been introduced with ML
R2008b. However, the
"Simplified" setting does not work with TargetLink's simulation
frame and can
therefore not be used for SIL/PIL simulation. If selected,
Simulink stops with
error messages similar to the following:
"Invalid setting for parameter 'Initial output:' of Outport block
'Sample_04/ModelTaskController/S-function frame/Out1'. The
initial output value
must be fully specified when the parameter 'Source of initial
output value:' is
set to Dialog".
*** Note that said option "Simplified" is currently not supported
by TargetLink,
so despite the fact that the MIL simulation with TargetLink
might be working, it
should not be used for code generation. ***
Workaround: Set "Data Validity/Underspecified initialization detection" to
"Classic".
patches:
TargetLink 3.3p5
571 / 1260
ID:
KPR.2012.01.02.003
Title:
E02241 error occurs after building the production code

simulation application or after starting the SIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Description:
While working with TargetLink it may happen that after building
the production
code SIL application or after starting the SIL simulation,
TargetLink reports
one of the following error message:
*** E02241: TLSS ERROR:
*** Error reported by the operating system:
*** Das angegebene Modul wurde nicht gefunden.
*** Cannot load
.\TLSim\<ModelName>\HostPC_<Compiler>\<ModelName>.dll
into the address space!
or
*** E02241: TLSS ERROR:
*** Error reported by the operating system:
*** The specifed module could not be found.
*** Cannot load
into the address space!
This error is issued although the affected file:
exists at the denoted
location.
The circumstances that lead to this error are not exactly
known. In some cases
this problem occured after another program using ActiveX
controls was executed.
Workaround: Contact dSPACE technical support.
patches:
TargetLink 3.1p10
TargetLink 3.2p5
TargetLink 3.3p1
572 / 1260
ID:
KPR.2012.01.03.001
Title:
PIL linker errors due to incorrect configuration file of the TSM

for MPC5604BEVB with GreenHills Compiler

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: When building the PIL simulation errors during linking for
MPC5604B TSM with
GreenHills compiler may appear because of unresolved
externals.
The cause of the problem is an incorrect DSFxp library path in
the file
"TsmInfo.xml" for the MPC5604BEVB/GHS51 and
MPC5604BEVB/GHS52.
Note: The linker errors only happen, if the DSFxp Library is
required in the
build process.
Workaround: Open the file " TsmInfo.xml "
"<TL_ROOT>\Matlab\Tl\SimFiles\MPC5604BEVB\GHS51"
(in TL32) or
"<TL_ROOT>\Matlab\Tl\SimFiles\MPC5604BEVB\GHS52" (in
TL33)
and change the property of the value "MyC=" from
"MPC55XXVLE " to "MPC560xBVLE".
Now open the TargetLink Preferences Editor once and close it
to refresh the
configuration (or restart MATLAB). After reopening the
the linker errors should appear anymore.
573 / 1260
ID:
KPR.2012.01.17.001
Title:
Incorrect code generated for Stateflow 'for' loops with update

statements containing Stateflow action language type cast
operations

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A 'for' loop modeled in Stateflow whose update statement

contains a type cast
operation in the Stateflow action language will lead to
incorrect generated
code. For example, if a 'for' loop update action like "i =
(UInt8)(i + 1)" is
modeled in Stateflow, TargetLink will generate incoreect 'for'
loop code like
following
UInt8 Aux_U8;
Aux_U8 = (UInt8)(i + 1);
for (i = 0; i < N; i = Aux_U8) { ... }
Note that this is in most cases an infinite loop, as 'Aux_U8' is
updated only
once outside the loop.
Workaround: 1) Avoid specifying such Stateflow type cast operations in 'for'
loop update
actions, e.g. by modeling the loop as a 'while' loop instead.
The flow chart
pattern for a 'for' loop is the same as that for a 'while' loop,
except that the
last statement before the loop and the last statement inside
the loop have to be
assignments to the same variable. Try to reorder these
statements in order to
have a 'while' loop generated.
2) If that is not possible, create a local dummy variable without
any TargetLink
properties and insert the statement 'dummy++' just before the
loop.
574 / 1260
ID:
KPR.2012.01.17.002
Title:
tl_clear_system crashes for a Relay block using a TargetLink

type Bool and remapping to Simulink data type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Clearing a system from TargetLink data will abort if

- a TL Relay block's TargetLink datatype is Bool AND
- the block's Simulink data type is specified explicitly and is not
"double"
AND
- the "remap output scaling data" option of tl_clear_system is
switched on.
In this case TargetLink tries to set the Simulink data type to
"boolean", which
is not supported for Relays and leads to an error like:
Remapping local output scaling data of 3 blocks : .??? Error
using ==>
tl_remap_scaling at 149
'boolean' is not a valid built-in data type in Relay block 'Relay'.
Error in ==>
tl_remap_output_scaling>FcnRemapOutputScaling at 91
msgStruct = tl_remap_scaling(hBlock, ...
Workaround: 1. Set the "remap output scaling data" option to off when
clearing a model from
TargetLink.
OR
2. Insert the following code in
tl_remap_output_scaling_config.m :
if strcmp(get_param(hBlock,'BlockType'),'Relay') &&
ds_isa(tl_get(hBlock,'output.type'),'booltype')
bModified = 1;
end
575 / 1260
ID:
KPR.2012.01.17.003
Title:
Fatal error during code generation due to unused AUTOSAR

access point objects in the Data Dictionary

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation crashes with Fatal #f99999 for a TargetLink

AUTOSAR model if all
of the following conditions are met:
- there is a Runnable object R in the Data Dictionary which is
referenced in the
model AND
- for R an AccessPoint AP of one of the following kinds is
specified in the Pool
area of the Data Dictionary
- PerInstanceMemoryVariableAccess
- InterRunnableVariableReadAccess
- InterRunnableVariableWriteAccess
- SharedCalPrmVariableAccess
AND
- AP is not used in the model AND
- at the SoftwareComponent to which R belongs there is a
ClientPort object CP
specified AND
- the NVRAMVariableRef property of CP is set.
Workaround: In the Data Dictionary delete unused AUTOSAR access point
objects.
Or unset the NVRAMVariableRef at ClientPort objects if
possible.
576 / 1260
ID:
KPR.2012.01.17.004
Title:
Code Generation aborts with fatal error 17107 due to

unresolvable XSL includes

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink allows the customer to use his own Code

Generation XSL root style
sheets which are placed in other file locations than the default
location. In
this case the root style sheet which shall be used must be
referenced from the
TargetLink Main Dialog. But either the directory which
contains the referenced
root style sheet must also contains all the other TargetLink
XSL style sheets
for code formatting (originally located in
<TL_ROOT>\Matlab\Tl\XML\CodeGen\Stylesheets) or in the
referenced root style
sheet the <xsl:import>-Statements must contain absolute
paths to the included
XSL style sheets.
If this is not the case, instead of stating the problem clearly in
an error
message, the code generation will abort with a rather
unspecific fatal error
17107 like:
Fatal #17107: An error occurred in processing XSL: COMError: The system cannot
locate the object specified.
Error occurred during compilation of included or imported
stylesheet
'TL_GlobalVar.xsl'.
or for older TargetLink versions equal or less TargetLink 2.2:
Fatal #17107: An error occurred in processing XSL: : An
exception occurred!
Type:RuntimeException, Message:The primary document
entity could not be opened.
Id=file:///<path to the referenced TL root style
sheet>/TL_GlobalVar.xsl
Workaround: 1) Place all TargetLink XSL stylesheets for Code Generation
in the same
directory.
or 2) Put absolute paths in the <xsl:import>-Statements in the
according XSL
root style sheet.
577 / 1260
ID:
KPR.2012.01.17.005
Title:
Error #0815 appears during SIL simulation for a user-defined

Module object named "common"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: TargetLink's Symbol Table Parser is called after a SIL or PIL

simulation
application is compiled and linked and imports the production
code symbols for
simulation into the DataDictionary. Some C compilers place
global variables into
.common module. If the Symbol Table Parser finds a symbol
without any module
name specification or a compiler places a symbol into
common the Symbol Table
Parser create a symbol description below ?/<application
name> /Build_<
application name >_<compiler> /Symbols/common?,
otherwise the common node is
empty.
If the user also defines a Module object ?common? in the
TargetLink model or
Data Dictionary both common modules overwrite each other,
wich may result in
missing symbols for the simulation and leads to an error
message like:
"Error #08152:Cannot find the symbol tmp_Switch_1_On in
Build_pipt1_HostPC_LCC."
Workaround: If possible try to avoid using a user-defined module
?common? in your the
TargetLink model, e.g. by renaming it.
578 / 1260
ID:
KPR.2012.01.17.006
Title:
Code generation aborts with TargetLink Port blocks whose tag

parameter contain a valid MATLAB expression

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a library or a model contain an Inport or Outport block that is

enhanced for
TargetLink and the block's tag parameter contains a string that
is a valid
MATLAB expression, then the code generation fails with a
misleading error
message similar to the following:
Codegeneration of attached model (subsystem 'ctrl2') failed
with
Error #03019: floor_model/ ... /ctrl2/Rounding Function:
CUSTOM_ROUND block is not supported by TargetLink and
no corresponding block is
defined. The block has a library link to floor_lib/Rounding
Function. The
library floor_lib is yet to be prepared for TargetLink.
Workaround: Make sure that the tag parameters of TargetLink Inport and
Outport blocks in
models and libraries used for code generation do not contain
strings that are
valid MATLAB expressions.
ID:
KPR.2012.01.17.008
Title:
Code generation aborts with fatal error #10020 if in the Extract

Bits block only a single value for the range of bits is specified

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation fails if the Extract Bits block has the
following settings:
- "Bits to extract" = "Range of bits" AND
- for the bit range only one value is specified, e.g. 5 or [5].
In such cases the TargetLink code generation terminates with
the following
error:
Fatal #10020: An internal error (LEDA exception: array::entry
index out of
range) has occurred.
Workaround: Specify the range of bits in the form [start end]. If only one bit
should be
extracted set the same value for start and end, e.g. [5 5].
579 / 1260
ID:
KPR.2012.01.17.009
Title:
"Rescan bus hierarchy" aborts with an error if Simulink option

'Specify properties via bus object' is enabled for the port block
but no bus object is referenced

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: On MATLAB <= R2010a the step 'rescan bus hierarchy' for a
TargetLink busport
dialog crashes if the underlying Simulink port block's option
'Specify
properties via bus object' is enabled but the according input
field for
specifying the bus object is empty.
Workaround: Specify a valid Simulink bus object
or disable the option 'Specify properties via bus object'.
patches:
TargetLink 3.3p2
580 / 1260
ID:
KPR.2012.02.07.001
Title:
Code Generation error #15099 for Struct Component Access

Functions for Structs with "DDBased" Module

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a struct variable has a ModuleRef (directly or via its Variable

Class) of a
Data Dictionary Module with CodeGenerationBase=DDBased
AND
if at least one of the struct components has a variable class
referencing an
AccessFunctionTemplate that contains AccessFunction
objects with a ModuleRef
(directly or via its function class) of a Data Dictionary Module
with
CodeGenerationBase=DDBased
then code generation for the model terminates with an error
message:
Error #15099: / ... /Components/new_Component:
Access functions for variable new_Component cannot be
created in the DD-based
module new_module because the variable cannot be
generated from the DD.
I.e. the code generator effectively ignores the Module
assigned to the struct
component's "parent struct".
Example:
struct T1 {
T2 new_Component;
} myStructVar;
T2 myPlainVar;
Assigning a DDBased Module and a "DDBased
AccessFunction" to "myPlainVar" works.
Assigning a DDBased Module to "myStructVar" and a
"DDBased AccessFunction" to
"myStructVar.new_Component" leads to the error.
patches:
TargetLink 3.3p2
581 / 1260
ID:
KPR.2012.02.07.002
Title:
Setting of TargetLink PreLook-up Index Search block is lost

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The deprecated TargetLink PreLook-up Index Search block

(from the
tl_needs_upgrade library; leftmost block in the 2nd row)
supports the "Common
output for index and fraction" setting for the property
"outputmode".
If a block with this setting is cleared from TargetLink data (with
the Clear
System tool), subsequent re-preparations of the associated
system do not recover
the block with said setting, but the block is enhanced to a
PreLookup Index
Search block which supports only the "Output only the index"
mode.
Workaround: Open the tl_needs_upgrade library and replace the
PreLookup Index Search block
in the model with the PreLook-Up Index Search block from
this library.
582 / 1260
ID:
KPR.2012.02.07.003
Title:
Empty log objects and plot windows for Simulink fixed-point

data types in MIL simulation mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Logging Simulink signals of a Simulink fixed-point data type is

not possible in
MIL simulation mode. Plot windows and log objects are
created but they contain
no simulation data.
Workaround: It is only possible to log Simulink fixed-point signals if Simulink
data type
overriding is used to represent them internally as double.
Data type overriding can be activated with Simulink menu
command
'Tools'->'Fixed-Point'->'Fixed-Point Tool ...'.
A possible disadvantage of this workaround is, that (with
checked Simulink menu
'Format'->'Port/Signal Displays'->'Port Data Types') all fixedpoint signals in
the model are shown as double.
patches:
TargetLink 3.2p4
TargetLink 3.3p1
ID:
KPR.2012.02.07.004
Title:
Extremely long code generation duration due to feedback

loops with bus processing blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation time can increase considerably if a

contains large feedback loops (approx. > 100 Blocks) that only
involve routing
and also bus processing blocks.
Bus processing blocks are: Unit Delay, Merge, Switch,
Multiport Switch, Simulink
In- and Outports.
Routing blocks are: BusCreator, BusSelector, Mux, Demux
and Selector block.
Workaround: Insert a non-bus processing block in the feedback loop, i.e. a
Gain block with
gain factor 1 or a TargetLink Rescaler block.
583 / 1260
ID:
KPR.2012.02.07.005
Title:
No warning and no generated code if header file for nonextern subsystem is explicitly included by AddFile block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If for a subsystem it is specified that its code shall be

generated into a
special module (e.g. via a TargetLink Function block) and if an
AddFile block in
the model specifies an include of the header file of that
module then TargetLink
treats the subsystems code and module like extern and thus
does not generate
code for it. This is correct behavior. But in case no extern
Function Class is
specified in the Function block then warning should be issued,
as the user's
intention is ambiguous. This warning is missing.
Workaround: Either select an extern Function Class to clearly specify the
extern code
OR remove the AddFile block if TargetLink should generate
the code into the
specified module (instead the module can e.g. be directly
specified in the
Function block).
Note that the TargetLink Function block itself has an option to
compile and link
external code for SIL/PIL simulation, so in the above use case
no AddFile block
is needed at all.
584 / 1260
ID:
KPR.2012.02.07.006
Title:
Erroneous AUTOSAR export if non scalar data element uses

a data type with constraints referecing a scaling object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a AUTOSAR data element

- has a data type with a Scaling specified in its associated
Constraints object
AND
- the data element is not scalar
then the representation of that data element in the Data
Dictionary Subsystem
area might refer to a LocalScaling object instead of refering to
the Scaling
object that is specified with the constraint data type.
Due to this erroneous representation the AUTOSAR export
might be flawed.
Reimporting the ARXML file might produce the errors like the
following:
Error <time> E06567: Invalid Variable object <variable object>
The Scaling
property of the Variable object <variable object> specifies a
different Scaling
object than the constraints of the associated Typedef object
<typedef object>.
Workaround: Avoid data types with a scaling associated to them to get a
valid DD
representation.
OR
The AUTOSAR export problem can be worked around by
deleting the LocalScaling
objects at the variables with such a constraint data type in the
Subsystems area
and by specifying the scaling of the data type directly at those
variables.
585 / 1260
ID:
KPR.2012.02.07.007
Title:
Code generation aborts but error messages are missing

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: It is possible that the code generation aborts but the according
error messages
are missing. The problem occurs if the number of Data
Dictionary messages during
code generation exceeds the maximum Data Dictionary
message buffer size
(default: 4096 messages). This buffer is used not only for
collecting error
messages but also internal notes, so that it can grow to that
size during code
generation for large models.
Workaround: The maximum size of the internal Data Dictionary message
buffer can be increased
to avoid this problem. For this the following command can be
used in MATLAB
before starting the code generation, e.g. via a
pre_codegen_hook function
(example for a size of 1.000.000):
>> dsdd('SetMaxNumMessages', 1000000);
Note the message buffer is automatically cleared before every
code generation,
so such a huge number should be enough in most cases.
586 / 1260
ID:
KPR.2012.02.07.008
Title:
AUTOSAR import with automatic group adaptation according

to given package information fails

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Before the actual import TargetLink analyzes the given

package structure in the
selected DD Workspace, for example //DD0. The found
information of the package
to group object mapping will then be used to create
AUTOSAR objects under the
defined groups. With this feature it is possible to specify a
different
destination point for AUTOSAR objects in the Data Dictionary.
The feature works only in the default DD Workspace //DD0. In
other workspaces
predefined group objects have no effect on the import
behavior.
For example, you create a TypedefGroup object with Name
?A? in a different DD
Workspace than DD0 and specify the AUTOSAR package
name ?B?. A file containing
AUTOSAR data types in package ?B? will be imported into
this DD Workspace. A new
TypedefGroup object ?B? will be created during import, but
instead the
TypedefGroup ?A? should have been used.
patches:
TargetLink 3.3p1
587 / 1260
ID:
KPR.2012.02.07.009
Title:
Incorrect implementation of FIR Filter macros/functions for 32

bit accu width and saturation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink may generate calls to the following

macros/functions for a FIR Filter
block in the model that uses a 32 bit accu width and
saturation. Due to a
mistake in their implementations in the Fixed-Point Library
they may calculate
incorrect results:
F__I32FIR32_SAT_I8I32
F__I32FIR32_SAT_I8CBI32
C__I32FIR32_SAT_I8I32
C__I32FIR32_SAT_I8CBI32
Workaround: 1) If possible use another accu width or other data types for
the coefficients
and the delay line to avoid the call of the mentioned
macros/functions.
OR
2) Use one of the following combinations for the delay line
code options to
avoid generation of the mentioned macros:
- Inline = on and Generate loops = on
- Inline = off and Generate loops = off
588 / 1260
ID:
KPR.2012.02.07.010
Title:
Internal error during AUTOSAR frame generation if Runnable

Outport is fed by muxed signals

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If code generation mode is AUTOSAR and an outport of a

runnable is fed by a
muxed signal then following
error may occur during frame generation:
The frame generation for the TL Subsystem contained in the
attached model
<ModelName> failed with the internal error:
*** E00000: ERROR USING FCNGETSOURCESIGNAL:
*** Internal Error:
output signals.
The problem can only occur if the outport does not implement
an operation
argument, an operation return value or
interrunnable communication.
Workaround: Insert a Rescaler block between the mux and the outport.
ID:
KPR.2012.02.07.011
Title:
Wrong generated code for non-scalar AUTOSAR calibration

parameters without *_COMPOSITE_TYPE Variable Class

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
589 / 1260
Description: If Data Dictionary Variable object is specified as an AUTOSAR

calibration
parameter. That means it is
- either an SWC-internal calibration parameter (that is
accessed by the
Rte_CData function),
- or an SWC-external calibration parameter (that is accesssed
by the
Rte_CalPrm/Rte_Prm function).
AND if this variable is not a scalar
AND additionally one of the following VariableClasses is
specified for the
variable:
- SHARED_CALPRM for an SWC-internal calibration
parameter OR
- CALPRM_VARIABLE for an SWC-external calibration
parameter
then the generated code incorrectly does not contain a call to
the desired RTE
API function Rte_CData or Rte_CalPrm/Rte_Prm. Instead, it
contains accesses to a
stub variable that is only defined in TargetLink's simulation
files.
As a result, the code can be compiled for TargetLink SIL/PIL
simulation and does
not lead to any simulation differences with MIL mode, but the
code is not
compilable with the code of any RTE generator.
Workaround: Either
- specify VariableClass
SHARED_CALPRM_COMPOSITE_TYPE resp.
CALPRM_VARIABLE_COMPOSITE_TYPE for the variable
(as described in TargetLink
AUTOSAR Modeling Guide > Modeling According to
AUTOSAR > Preparing SWCs for
Measurement and Calibration)
OR
- in case of SWC-external parameters create the variable by
the entry "Create
variable object in associated variable group" in a CalprmPort
object's context
menu. Do not modify the created variable object (also see
TargetLink AUTOSAR
Modeling Guide > Modeling According to AUTOSAR >
Preparing SWCs for Measurement
and Calibration > How to Prepare Block Parameters of
Several SWCs for
Calibration).
590 / 1260
ID:
KPR.2012.02.08.001
Title:
Wrong error handling of TargetLink API in case of optional

properties at Custom Code blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: In general a Custom Code block has following kinds of

variables:
* input
* output
* parameter
* state
* work
If any of these variable kinds is not used by an instance of an
Custom Code
block an access to the associated properties should lead to an
error. For
instance, if your Custom Code block has no work variable the
command
>> [lsbValue, errFlag, errMsg] = tl_get(hCustomCodeBlock,
'work.lsb')
should result in
lsbValue = []
errFlag = 7
errMsg = 'TargetLink API error: 'work.lsb' is not a valid
property
specification!'
Unfortunately, the TargetLink API commands tl_get / tl_set
abort with an
internal error instead:
??? Reference to non-existent field 'param'.
Error in ==> tl_get>FcnGetPropertyValue at 259
compfield = field.(props{n});
Note that also some TargetLink functions may run in this error
condition, e.g.
the synchronization of scaling data fails due to this problem.
Workaround: Consider to check that the number of variables of a certain
kind is greater than
zero before accessing it:
if tl_get(hCustomCodeBlock, 'numworks') > 0
[lsbValue, errFlag, errMsg] = tl_get(hCustomCodeBlock,
'work.lsb')
end
patches:
TargetLink 3.3p2
ID:
KPR.2012.02.09.001
591 / 1260
Title:
Wrong reference to MEASUREMENT resp.

CHARACTERISTIC from the FUNCTION entry in generated
A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If for an actual function's argument all of the following

conditions apply:
- it is measurable or calibratable AND
- it is a vector AND
- at least one of the vector elements has different scaling, min
or max value as
the other ones,
then the exported A2L file containing the description of these
function's
argument is not correct.
Since the identical scaling and limits do not apply for all vector
elements,
TargetLink generates for each vector element a single A2L
entry, for example:
/begin MEASUREMENT
ActualVector[0]
...
/end MEASUREMENT
...
/begin MEASUREMENT
ActualVector[N]
...
/end MEASUREMENT
From the FUNCTION entry however the whole vector is
referenced:
/begin FUNCTION
MyFumction
...
/begin LOC_MEASUREMENT
ActualVector /* identifier */
/end LOC_MEASUREMENT
/end FUNCTION
whereas the correct FUNCTION entry should look like:
/begin FUNCTION
MyFumction
...
ActualVector[0] /* identifier */
...
ActualVector[N] /* identifier */
/end FUNCTION
592 / 1260
Workaround: The situation that a measurable vector variable is an actual

function's argument
may occur, if a block whose output block variable has the
variable class DISP is
driven by a function subsystem's inport block whose output
block variable has
the variable class set to FCN_REF_ARG. In this case as a
workaorund insert a
TargetLink Rescaler block (TargetLink 3.x) or Outport block
(TargetLink 2.x)
between these blocks.
No workaround exists in the case the ArgClass property of the
FCN_PARAM,
FCN_REF_PARAM, FCN_REF_ARG, FCN_ARG is set to
CAL resp. DISP. So the generated
A2L file must be corrected manually.
patches:
TargetLink 3.2p4
593 / 1260
ID:
KPR.2012.02.09.002
Title:
Missing state entry steps in the generated code for

complicated state transitions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the generated production code for Stateflow charts, entry

steps may be
missing in the case that
- in a state, there is an inner transition which splits in two
paths at one
point which later join again AND
- one of the paths lies completely inside the state, the other
leaves the state
and later enters it again.
Then in the generated code upon reaching the end of the
transition along either
path, the state is exited, but incorrectly not entered again, as
the call to the
associated entry action function (*_ea()) or, if the function was
inlined, it's
contents including the setting of the state flag are missing.
Schematic example:
/--------------------------------\
| State |
||
|---->O--------------------O---->|
||^|
||||
\-----|--------------------|-----/
||
v|
O------------------->O
594 / 1260
ID:
KPR.2012.02.16.001
Title:
Data Dictionary XML Import (extended mode) does not report

any error if a numeric property value cannot be imported

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In extended mode the XML import of the Data Dictionary will
not erport any error
if the numeric value of a property of a Data Dictionary object
cannot be
imported due to an invalid formatting of the numeric data
within the XML
element. Instead the problematic data is ignored and not
imported. This can lead
to loss of data without notice.
This is generally not a problem if the data was exported prior
by XML export of
the Data Dictionary. But if the XML was formatted by a foreign
tool or manually
formatted to become incorrect and thus it cannot be parsed.
Sample of valid and invalid formatted data:
Valid:
<ddProperty Name="Value">[1 2 3 0.5 ;0 0 0 0 ;0 0 0
0.87]</ddProperty>
Invalid:
<ddProperty Name="Value">
1 2 3 0.5
0000
0 0 0 0.87
</ddProperty>
Workaround: Make sure that the imported XML files content of numeric data
is in valid format
(e.g. by comparing to the exported XML).
595 / 1260
ID:
KPR.2012.02.21.001
Title:
Missing description in generated code for blocks with property

inheritance

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The description specified via TargetLink block dialog is

missing in the
generated code, if property inheritance is activated for the
following blocks:
- Merge
- Switch
- Multiport Switch
- Unit Delay
The problem also applies for the following blocks if
- the block output is scalar AND
- the data type Bool is inherited AND
- the variable class is default AND
- on the Adavanced Page of the TargetLink Main Dialog the
option "Use global
bitfields for Booleans" is activated:
- TargetLink Inport
- TargetLink Outport
- Assignment
- D Flip Flop
- D Latch
- Min Max
- Saturation
- Unit Delay Reset Enable
- Rescaler (since TL 3.0)
- TargetLink Bus Inport (if the component for which property
inheritance is
activated is not configured to become part of a structure
resulting from the Bus
Inport block)
- TargetLink Bus Outport (if the component for which property
inheritance is
activated is not configured to become part of a structure
resulting from the Bus
Outport block)
596 / 1260
ID:
KPR.2012.02.28.001
Title:
Symbol Table Parser for LCC compiler does not find all static variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The symbol table parser for the LCC host compiler does not find all static
variables. Thus problems may occur by using online parameter modification with
static variables and LCC is the selected mex compiler. In such a case the API
tl_sim_interface('GetDDVarAddr',.....) returns with the error message like:
*** E02405: SYMBOL ADDRESS NOT FOUND:
*** The address of the symbol could not be found. The reason was: Cannot find
the symbol 'VariantSwitch' below the data dictionary object
'//DD0/online_parameter_modification/Build_online_parameter_modification_HostPC_
LCC'.
Workaround: If possible use global scope instead of static.
TargetLink 3.2p5
TargetLink 3.3p2
597 / 1260
ID:
KPR.2012.02.29.001
Title:
Missing cast to signed integer type for the operand of a unary

minus operation leads to a compiler warning

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If
- the numerator of a division operation has a 16 or 32 bit
signed integer type
AND
- the denominator has an 32 bit unsigned integer type AND
- the result of the division has a signed integer type
then a code pattern as follows is generated:
result = (Numerator < 0) ? (-((-Numerator) / Denominator)) :
(Numerator /
Denominator);
Although the code calculates correctly, there might occur a
compiler warning
when compiling the production code.
For example MSVC compiler emits "warning C4146: unary
minus operator applied to
unsigned type, result still unsigned" and the LCC emits the
warning " unsigned
operand of unary ? ?.
There is a cast to signed integer missing for the operand of
the first unary
minus.
patches:
TargetLink 3.2p5
598 / 1260
ID:
KPR.2012.03.05.002
Title:
Missing min/max property of actual parameters of subsystem

internal block variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A block is neither an inport nor an outport at the interface of its

parent
subsystem. One of the block's variables (block parameter or
outport variable) is
specified with a variable class with scope value_param,
ref_param, or
fcn_return. Additionally, min/max values are specified for this
variable.
In this case, TargetLink generates the variable as a function
parameter or a
function return parameter of the subsystem's step function. It
is expected that
the corresponding actual parameter in the production code
inherits the specified
min/max values.
But in fact it does not inherit any min/max values at all. Only
the formal
parameter inherits the min/max values instead.
As a result, the actual parameter's description in a generated
A2L file does
lack the specified min/max values.
Workaround: Specify the min/max values by using a data type with
constraints for this
Variable object.
patches:
TargetLink 3.2p5
TargetLink 3.3p2
599 / 1260
ID:
KPR.2012.03.05.003
Title:
Incorrect code generated for change detection for SF input

with createinputvariable=off

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For realizing change detection TargetLink generates

additional variables to
store copies of the watched Stateflow data. These should
have the same data type
and scaling as their associated Stateflow data objects. But if
the watched
variable is a Stateflow data with scope input and TargetLink
property
createinputvariable=off TargetLink incorrectly creates the
additional variables
with data type double (Float64).
Workaround: 1) Set the createinputvariable property to "on" and define type
and scaling
explicity
or 2) Set createinputvariable to "on" and also inheritscaling to
"on".
600 / 1260
ID:
KPR.2012.03.05.004
Title:
Code generation aborts with access violation if a data

varianted Variable object has no values set

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a data varianted Variable object has no initial values for a

data variant the
following error should appear:
Error #10622: / ... /CAL/Ki: Reading the value (variant 2) failed
However in some cases the code generator may crash before
or after this message
is shown:
Fault address: 2D37052E 01:0000F52E
D:\TargetLink\Matlab\Tl\Bin\XcgCvTools.dll
Call stack:
Address Frame
2D37052E 00CE3B98 0001:0000F52E
D:\TargetLink\Matlab\Tl\Bin\XcgCvTools.dll
2AD7B9F0 00CE3BAC 0001:0048A9F0
D:\TargetLink\Matlab\Tl\Bin\XcgCV.dll
2BE96DCA 00CE3CF4 0001:00495DCA
D:\TargetLink\Matlab\Tl\Bin\XcgCVT.dll
...
Workaround: Specify a value for all variants in the Data Dictionary.
601 / 1260
ID:
KPR.2012.03.06.001
Title:
Erroneous removal of Struct Variable Definition if all Struct

Members are accessed via Access Function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Struct variable definitions may be missing in the generated

code even though the
variable definition is necessary.
This problem may happen if
- the struct variable's variable class is default or a user class
with set
ERASABLE Optimization property AND
- all struct members have a variable class with
AccessFunctionTemplate AND
- Code generation mode is not AUTOSAR.
Workaround: Assign a user Variable Class to the struct variable that does
not have the
ERASABLE Optimization property set.
patches:
TargetLink 3.3p2
602 / 1260
ID:
KPR.2012.03.06.002
Title:
Wrong error message if properties of TargetLink

PreProcessorIf block are modified in Blockset stand-alone
mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: In TargetLink Blockset stand-alone mode modifying properties

of the
PreprocessorIf block will lead to an wrong error message
about inconsistent
TargetLink blockdata, but actually the data can be saved
correctly at the block
with exception of the property mode, which is actually not
editable in
stand-alone mode, as it is not a mapped Simulink property.
The other block
properties work.
The error message is: "TargetLink specific blockdata cannot
be saved in
stand-alone mode.".
Workaround: 1) Ignore the error message from tl_set() or the block dialog
(answer the dialog
with yes).
or
2) Set data directly via Simulink API or via the Simulink block
dialog (by
switching DialogProvider or using the Simulink properties
button in the
TargetLink dialog's toolbar or looking under the mask).
603 / 1260
ID:
KPR.2012.03.06.003
Title:
Error #2287 "No Simulink log variable found" appears for

logged TargetLink blocks in library subsystems linked from
referenced models

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: It is not possible to perform logging during MIL simulation for

TargetLink
blocks located in library subsystems linked from referenced
models. In this case
the following error message appears:
No corresponding Simulink log variable could be found for the
signal connected
to '<block path>'.
Consult the online help for possible reasons and solutions.
patches:
TargetLink 3.1p10
ID:
KPR.2012.03.06.004
Title:
Incorrect code generated for Access Function on matrix struct

component

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Currently TargetLink does not support access functions for

matrix variables. An
error should be thrown during code generation if such a
situation appears. But
this error message is only thrown if the matrix variable is
generated as a plain
variable. If it is a structure component no error appears and
wrong code is
generated like the following example (new_Component is a
matrix):
#define GetAddrF64() (&new_Variable_2.new_Component)
...
Sa1_OutPort = (Int16) *(GetAddrF64());
...
Workaround: Currently TargetLink does not support access functions for
matrix variables.
Please avoid using access functions with matrix variables.
604 / 1260
ID:
KPR.2012.03.06.005
Title:
Erroneous code for folded and saturated addition/subtraction

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an addition or subtraction is specified, for example, using a

Sum block or in
Stateflow AND
- both operands of the addition/subtraction are constant
values so that the
operation can be replaced by the result of the
addition/subtraction of those
operands AND
- the result of the addition/subtraction is supposed to be
saturated (Saturation
flags set in block dialog or checkmin/checkmax set for
Stateflow object) AND
- the saturation is only specified for the upper limit but not for
the lower
limit AND
- the result value of the addition/subtraction is smaller than 42,
the generated code may be wrong.
Example: Sum block preceded by two constant blocks with
default variable class.
Sum block: Saturate Upper = true, Saturate Lower = false,
Type = UInt8, LSB =
1.0, Offset = 0.0
Constant block 1: Value = 2
Constant block 2: Value = 2
The resulting erroneous code might be
SumOut = 42;
This problem can be identified by the result of 42.
Workaround: 1) Either switch off (possibly superflous) saturation for
calculation with
constants.
Or 2) if saturation is needed, then also saturate the lower limit.
605 / 1260
ID:
KPR.2012.03.06.006
Title:
Code generation error #10014 occurs if an AUTOSAR

operation argument with struct typedef is referenced in a
normal port block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an AUTOSAR data element or operation argument with

struct typedef is
referenced in a TargetLink Port block (not a bus port block)
code generation for
the model results in following unspecific error message:
But further error details are missing.
Workaround: Select only data elements / operation arguments with plain
typedef in port
blocks and for struct types use bus port blocks.
ID:
KPR.2012.03.06.007
Title:
Option "Sync parameter scaling data" cannot be chosen in

System Synchronization dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: TargetLink provides a dialog for system synchronization of

fixed point data
between TargetLink and Simulink. The dialog offers all
synchronization options,
but due to an error in dialog's logic it is impossible to include
parameter
scaling data in synchronization from TargetLink to Simulink.
Workaround: Invoke synchronization via command line API
tl_sync_system(...
'SyncParameterScalingData', 'on').
ID:
KPR.2012.03.06.008
Title:
Access Violation if Variable Access Function is utilized for

Writing Access

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
606 / 1260
Class:
Description: If a variable access function is specified for a variable that is

redefined,
then TargetLink generates code like
Var_A()
Var_B()[0] = ...
*(Var_C()) = ...
This is also the case for AUTOSAR Per-Instance-Memory
accesses.
TargetLink tries to eliminate intermediate variables. There is a
pattern for
backward propagation that optimizes
if (cond) {
r = n;
} else {
r = o;
}
lhs = r;
arriving at
if (cond) {
lhs = n;
} else {
lhs = o;
}
If
- a scalar variable with a variable class referencing an
AccessFunctionTemplate
containing an address access function OR
- a vector variable with a variable class referencing an
containing an address or direct access function
takes the place of "lhs", then this may lead to abnormal
termination of the code
generation with output like
Fault address: 688ED3AA 01:003EC3AA
D:\dSPACE\TL3.3\Working\Matlab\Tl\Bin\XcgCVT.dll
Call stack:
Address Frame
00000000688ED3AA 0000000000C22CBC
0001:00000000003EC3AA
D:\dSPACE\TL3.3\Working\Matlab\Tl\Bin\XcgCVT.dll
[...]
If deactivating optimization, e.g. via the Advanced tab of the
TargetLink Main
dialog, leads to successful code generation, then you may
have encountered this
problem.
607 / 1260
Workaround: 1) Inspect the unoptimized code for calls like described above
or use the Data
Dictionary Subsystems area in order to identify variables with
access function
template used in the model.
2) For "b()[0] = a" or "b()[0] = (T) a" or "b()[0] = -a" or "b()[0] =
!a"
situations place a TargetLink Rescaler block before the block
leading to the
assignment.
3) Set the block output properties as follows:
a) Inherit properties == on
b) Class: A variable class that has the following properties
i) Optimization: { MOVABLE, SCOPE_REDUCIBLE }
ii) Scope: global
iii) Storage: default
4) If necessary, you have to abandon (3a)
5) Now, code generation with activated Optimization should
work. You can now try
to change the variable class of the Rescaler blocks to "default"
block by block
in order to identify the problematic areas.
patches:
TargetLink 3.3p2
ID:
KPR.2012.03.06.009
Title:
Code Coverage incorrectly removes code line before the

coverage macros

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The Code Coverage reporter removes it's measurement

macros for the coverage
report and if API Command
"tl_code_coverage('RemoveAllCCMarks')" is used then
also within the "\TLProj\" folder with the generated production
code.
Incorrectly it always deletes the (usually empty) line before the
macros for
aesthetic reasons. Thus running
"tl_code_coverage('RemoveAllCCMarks')" or
copying the code directly from the report may yield incorrect
production code
that might be compileable.
Workaround: Generate code again with deactivated Code Coverage
(default setting is
deactivated).
patches:
TargetLink 3.2p5
TargetLink 3.3p2
608 / 1260
ID:
KPR.2012.03.06.010
Title:
Code generation aborts with error #30016 if a conditioned

subsystem is placed in a reused system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation aborts with a fatal internal error if one of
the following
subsystems is placed in a reused system:
- a triggered subsystem with trigger type "either", '"rising", or
"falling" OR
- an enabled subsystem OR
- a subsystem that is triggered and enabled.
In this case code generation stops with an error message
similiar to the
following one:
Fatal #30016: Subsystem/Outer/Inner1/Out1 An internal error
occurred during
implementation of function reuse. Contact dSPACE support.
Reason: The variable
'SInner11_Out1' shall be used in the subsystem
'Subsystem/Outer/Inner1'. But it
was created for the subsystem 'Subsystem/Outer'. Reuse of
this variable is not
possible.
patches:
TargetLink 3.3p2
609 / 1260
ID:
KPR.2012.03.06.011
Title:
Overload in Data Dictionary message list leads to lost

messages (e.g. wrong validation results)

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the Data Dictionary message list contains the maximum

number of messages
(which is currently 4096) no further messages are recorded.
Using the Data Dictionary Manager this may lead to wrong
results of the
validation and other commands.
E.g. if previous actions in the Manager or MATLAB-API
commands have filled the
message list with 4096 entries the validation shows no error
even if there are
invalid DD objects. But also if some other command that
results in a failure is
started no error is shown.
Workaround: Any MATLAB script using dsdd commands should clear the
message list after having
evaluated the messages: dsdd('ClearMessageList');.
patches:
TargetLink 3.3p3
610 / 1260
ID:
KPR.2012.03.19.001
Title:
Possibly wrong code or misleading error messages for nonscalar const, volatile or prefixed Variable object using type
with constraints

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Variable object in the Data Dictionary

- has a variable class that specifies a type prefix or the type
specifier const
or volatile AND
- that variable is not scalar AND
- that variable has a data type that has a scaling AND
- at that variable the VOID_SCALING is specified (i.e. the
scaling is inheritet
from the data type),
then the code generated for that variable might be wrong,
because it might be
implemented using a default scaling (LSB = 1.0, Offset = 0.0)
instead of the
scaling specified at the data type.
Another symptom might be that misleading error messages
like, for example, error
#17286 about not representable initial values are reported by
the Code
Generator.
Workaround: Instead of VOID_SCALING explicitly specify the same scaling,
which is used for
the constraint data type, also for the variable.
patches:
TargetLink 3.3p2
611 / 1260
ID:
KPR.2012.03.21.001
Title:
Data Dictionary validation falsely produces error message

#06581

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Data Dictionary validation produces an error message #06581

for Variable objects
whose bounds are not covered by the associated scaling
range. The bounds are
specified with the Variable's Min and Max properties, or the
Constraints.Min and
Constraints.Max properties of the associated Typedef object.
Note that the validation is automatically invoked prior to code
generation.
Workaround: Ignore the error message and proceed with code generation.
patches:
TargetLink 3.3p2
ID:
KPR.2012.03.30.001
Title:
Incorrect rounding in generated code for relational operations

with arbitrary scaled negative operand or if ShiftMode option is
set

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
612 / 1260
Description: The result of relational operations can be wrong, if

- both operands have different scalings AND
- one operand can have a negative value AND
- the other operand is unsigned or his Min value = 0 AND
- the value of the operand with the smaller LSB cannot be
represented in the
scaling of the other operand AND
- both operands will be represented by a variable or macro in
the generated code
AND
- the quotient of both LSB is not a power of two OR if the Code
Generator's
ShiftMode option suppresses the generation of shift
operations in the generated
code.
In addition to this conditions
a) the LSB of the first operand has to be less or equal to the
LSB of the second
operand and the relational operation has to be < or >=.
--OR-b) the LSB of the first operand has to be greater than the LSB
of the second
operand and the relational operation has to be > or <=.
In those cases erroneous rounding of negative values
approaching zero might be
applied in the generated code.
The erroneous code can be identified, if the specified
relational operation has
an operand whose value becomes smaller due to shifting to
the right or due to a
combined multiplication and division whose value is smaller
than 1 or due to a
division.
Example:
Int32 I32Var = -1; // LSB = 0.001
UInt16 UI16Var = 0 /* 0.0*/; // LSB = 0.1
Comparing these variables will create an operation like
I32Var / 100 < UI16Var
Since I32Var represents the value -0.001 and UI16Var
represents 0.0, the result
of the relational operation should be true. But it will be false
since -1 / 100
= -0.01 which is rounded to 0.
patches:
TargetLink 3.1p10
TargetLink 3.2p5
TargetLink 3.3p2
613 / 1260
ID:
KPR.2012.04.02.001
Title:
Code generation aborts with Fatal #10007 Error code:

TlCUnparamSymbol 633

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In certain situations involving function reuse or function

parameters pointing
to structures the TargetLink Code Generator may abnormally
abort with a fatal
error:
"Fatal #10007: Internal error. Error code: TlCUnparamSymbol
633"
patches:
TargetLink 3.3p2
ID:
KPR.2012.04.17.001
Title:
Error in simulation frame generation or wrong SIL/PIL

simulation results for model containing Incremental/Model
Referencing system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a model contains an Incremental or Model Referencing

system and the Outport
interface variable(s) of this system have scope "ref_param",
this may lead to
1) an error in simulation frame generation
*** E00000: ERROR USING FCNGETSOURCESIGNAL:
if the Incremental/MR system is externally called (i.e. is a root
system) or
2) wrong simulation results in SIL/PIL simulation.
patches:
TargetLink 3.3p3
614 / 1260
ID:
KPR.2012.04.20.002
Title:
Incorrect code generated for very large integer constants in

Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Integer constants greater than 9223372036854775807 (2^631, maximal value of a

signed 64-bit integer) or less than -9223372036854775808 (2^63, minimal value
of a signed 64-bit integer) used in a Stateflow Action
Language statement will
be parsed incorrectly by the TargetLink code generator. This
can lead to
generation of incorrect code.
The behavior depends on the TargetLink version:
2.0, 2.1 and 2.2: An unspecified number is recognized.
2.3, 3.0 and above: The number is recognized as
9223372036854775807.
Workaround: Use floating-point data types for numbers exceeding the 64-bit
integer range,
for example
myFloatingPointVariable =
100000000000000000000000000.0;
615 / 1260
ID:
KPR.2012.04.27.001
Title:
Wrong logging in SIL/PIL simulation for AUTOSAR ports

placed deeper inside a function-called runnable subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If all of the following conditions apply:

1) An AUTOSAR runnable is modeled within a function-call
subsystem that is
triggered from outside of the TargetLink subsystem, so that for
the runnable a
root step function is generated
AND
2) the runnable's access points, such DataSendPoints, are
specified at
TargetLink Outport resp. BusOutport blocks that are not
placed directly at the
root level of the Runnable subsystem, but are embedded in a
further subsystem,
for example function-call subsystem
AND
3) the signals outgoing from the Outport/BusOutport of the
inner subsystem lead
to non-enhanced outports of the TargetLink subsystem
then the signals mentioned in 3) are always logged as 0
during SIL/PIL
simulation.
Note that the generated production code is not affected by this
problem.
Workaround: For the nested function-call subsystem enhance the outport
block of the
TargetLink subsystem leading the outgoing signal of the
runnable port embedded
in a subsystem. In this case however there might be a one
step delay between
the results of the MIL and SIL/PIL simulation (for details see
the manual at
"TargetLink Limitations > Subsystem Limitations > Externally
triggered function
calls").
patches:
TargetLink 3.2p5
TargetLink 3.3p3
TargetLink 3.4p1
616 / 1260
ID:
KPR.2012.05.02.001
Title:
Reduced precision of unsigned operation with signed operand

in generated code for Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in Stateflow
- all the operands of an operation are unsigned (i.e. have
unsigned data type or
are positiv constant or have a positive range) AND
- at least one of the operands of that operation has a signed
type but min/max
values that define the value range of that operand to be
always zero or greater
AND
- at least one of the operands of the whole expression the
operation is part of
is scaled (LSB != 1.0 or Offset != 0.0) AND
- the operation is not the last operation on the right hand side
of an
assignment,
then the precision of that operation might be reduced
compared to TargetLink
versions before TargetLink 3.2.
patches:
TargetLink 3.3p3
617 / 1260
ID:
KPR.2012.05.07.001
Title:
Stateflow bitshift operation on scaled variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When Stateflow calculates a shift operation on a floating point

operand, it
casts that operand to integer before it performs the shift.
That means that all digits below the decimal point are omited.
If, however, TargetLink shifts a scaled variable (LSB != 1.0
and/or Offset !=
0.0) it correctly rescales the variable to integer (LSB = 1.0 and
Offset = 0.0).
But that scale operation is combined with the shift operation
itself. So it may
occur that not all digits below the decimal points are removed
and the generated
code behaves differently compared to the MIL/Stateflow.
Additionally, if one operand is an expression containing scaled
variables, the
result type of that expression may be determined to double
which may lead to
compile errors in the generated code.
Workaround: Assign the shifted expression to an not optimizable Stateflow
local variable
which is integer and unscaled. Then use this local variable in
the bitshift
operation
ID:
KPR.2012.05.07.002
Title:
Create netlist for autoscaling aborts with fatal error for

nonvirtual busses that pass From/Goto blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Creating a netlist for the Autoscaling tool for a model with
nonvirtual busses
that pass From/Goto blocks aborts with an error:
*** F00000: ERROR DURING NETLIST CREATION:
*** The block identification while netlist creation failed.
Workaround: If possible use virtual buses.
Or avoid using From/Goto blocks for modelling nonvirtual
buses.
618 / 1260
ID:
KPR.2012.05.07.003
Title:
Wrong optimization of Stateflow code with a right-shift with

large uint32 operand

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The optimization of code generated from a Stateflow chart

may evaluate a
right-shift operation to a wrong value. This may result in
incorrect value
propagation and therefore in wrong variable replacement by
constants and/or
wrong elemination of code branches in the generated
production code.
The problem happens if the value to be shifted is a constant
greater than
2147483647 (2^31 - 1) or the value to be shifted is given by a
Stateflow Data
with Stateflow data type uint32 and this Stateflow Data has a
constant value
greater than 2147483647 on all possible executions of that
chart.
Workaround: Use the result of the shift operation instead of the shift
operation itself.
619 / 1260
ID:
KPR.2012.05.07.004
Title:
Misleading error message #05040 from Data Dictionary or

code generation aborts with E10602

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: In the following case the Data Dictionary may report wrong
error messages during
upgrade or validation:
- a Data Dictionary file from TargetLink 3.1 or earlier is
upgraded with TL 3.3
AND
- there are included Data Dictionaries that are modified during
upgrade, which
results in warning messages #06341 and #06259
Then prior to the warning messages, an error message
#05040 is produced:
"Error #05040: Config: The specified object "Config" does not
exist."
Further it is also possible that the Code Generator aborts with
an error
messages if the Data Dictionary is not consistent:
W10603 DATA DICTIONARY INTERFACE MESSAGES
Error while reading Data Dictionary object. The following
required
properties are missing or invalid: The specified object "Config"
does
not exist.
E10602 DATA DICTIONARY INTERFACE MESSAGES
Could not read the Data Dictionary object.
Workaround: Create the missing Config object below /Pool/Autosar in the
Data Dictionary.
620 / 1260
ID:
KPR.2012.05.07.005
Title:
Selectable data types in Property Manager incorrectly depend

on all selected blocktypes

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: In the Property Manager only Data Dictionary objects can be

selected in the
Property Editor that comply with all block types that are
currently selected in
the Block Selector.
For example, since the output.type property of Relational
blocks must be
boolean, only boolean data types (from the available Data
Dictionary Typedef
objects) are selectable in the Property Editor when Relational
blocks are
selected in the Block Selector, although for other blocks also
other types
should be selectable.
Workaround: Use the Blocktypes Selector to deselect block types
accordingly.
patches:
TargetLink 3.3p3
621 / 1260
ID:
KPR.2012.05.07.006
Title:
AUTOSAR code is not compilable with RTE code caused by

faulty assignment to Merge variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In an AUTOSAR model a subsystem is specified as a

Runnable. It has an OutPort
that is specified as using AUTOSAR communication. The
OutPort is driven by a
Merge block. The Merge block is driven by two OutPorts in
encapsulated
subsystems that are specified as using the same AUTOSAR
communication as the one
driven by the Merge block (that means all these OutPort
blocks have identical
AUTOSAR settings).
In this case, the AUTOSAR code that is generated by
TargetLink may be not
compilable with code that is generated by an RTE code
generator. The AUTOSAR
code may be not compilable because of the following reasons:
- The AUTOSAR code contains an include of a non-existing
file.
- The Merge block's code makes use of a variable that is
undefined.
Notes:
- The generated code may still be compilable in TargetLink's
simulation
environment. Furthermore the faulty code lines do not result in
any differences
in SIL or PIL.
- The modelling is not valid. TargetLink should stop code
generation with an
error when facing it. But TargetLink does just emit the
following warnings, if
the code generation option 'StrictRunnableInterfaceChecks' is
not disabled:
Warning #32040: [...]
The outport is specified to be an AUTOSAR outport but has
no one-to-one
connection to the border of the executing runnable subsystem.
Workaround: De-enhance the OutPort that is driven by the Merge block.
Then rebuild the model
so the Merge block is placed outside the runnable subsystem,
and not inside.
Ensure that on the signal line between an OutPort specified
with AUTOSAR
communication and the runnable's subsystem border is no
other block than
not-enhanced Ports.
622 / 1260
ID:
KPR.2012.05.07.007
Title:
Model upgrade from TargetLink 2.x to 3.x reports error

messages E03213 if saved Simulink scaling cannot be
restored

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Usually an upgrade implicates a change of the TargetLink

version as well as a
change of the Simulink version. The problem occurs if the
corresponding Simulink
blocktype of a TargetLink block has been changed due to the
change of the
Simulink version. A further prerequisite is that a model
recently processed with
TargetLink version 2.x is upgraded to version 3.x.
One aspect of the upgrade from TargetLink 2.x to 3.x is to
restore Simulink
scaling data to the Simulink block properties that was saved
during sl2tl
conversion of the model. If this fails TargetLink issues an error
message
similar to the following one:
*** E03213: UPGRADE FAILURE:
*** Failed to set Simulink data for:
*** 'MyModel/LookupTableBlock'
*** MATLAB error message was:
*** Error using ==> tl_upgrade>FcnUpgradeBlocks at 1794
*** TL_Lookup1D block (mask) does not have a parameter
named
'ShowAdditionalParam'.
Note: The upgrade routine itself still finishes. Afterwards
Simulink data types
used for a MIL simulation should be checked at the according
blocks and adapted
if necessary. The model can then be used without further
changes.
ID:
KPR.2012.05.08.001
Title:
Fatal #10007 if at the ports of virtual subsystem, located inside a referenced model or
incremental subsystem, reference components of a pointer to struct variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a virtual subsystem is located inside a referenced model and at the InPorts
or OutPorts of the virtual subsystem components of a structure from Data
Dictonary are referenced which is defined as pointer to struct, the code
623 / 1260
geneneration for the code geneneration unit containing the reference to the
model terminates with a fatal error.
Since TargetLink 3.3 this is also the case if a virtual subsystem is located
inside an incremental subsystem.
The error message depends on the TargetLink version and the port type:
-------------------------------Error Messages in TargetLink 3.0
-------------------------------- For a TL Inport:
Fatal #10007:
Internal error. Error code: TlCSvModelReferenceDDReaderTools 956. Contact
dSPACE's technical support team
- For a TL Outport:
Fatal #10007:
- For a Bus Inport:
Fatal #10007:
\Core\XcgIntermediateView\Sources\XcgIntermediateView\BlockContext\DataBlockCont
ext\TlCBcBusInportContext.cpp_ 614. Contact dSPACE's technical support team.
- For a Bus Inport:
Fatal #10007:
Internal error. Error code: TlCBcBusOutportContext 616. Contact dSPACE's
---------------------------------Error Messages in TargetLink 3.0.1
---------------------------------- For a TL Inport:
Fatal #10007:
- For a TL Outport:
Fatal #10007:
- For a Bus Inport:
Fatal #10007:
Core\XcgIntermediateView\Sources\XcgIntermediateView\BlockContext\DataBlockConte
xt\TlCBcBusInportContext.cpp_ 618. Contact dSPACE's technical support team.
- For a Bus Inport:
Fatal #10007:
---------------------------------Error Messages in TargetLink 3.1
---------------------------------- For a TL Inport:
Fatal #10007:
624 / 1260

- For a TL Outport:
Fatal #10007:
- For a Bus Inport
Fatal #10007:
- For a Bus Outport
Fatal #10007:
---------------------------------- For a TL Inport:
Fatal #10007:
- For a TL Outport:
Fatal #10007:
- For a Bus Inport:
Fatal #10007:
- For a Bus Outport:
Fatal #10007:
---------------------------------- For a TL Inport:
Fatal #10007:
- For for a TL Outport:
Fatal #10007:
- For Bus Inports / Bus Outports:
Fatal #10007:
625 / 1260

TargetLink 3.3p3
ID:
KPR.2012.05.08.002
Title:
Error #15268 for pointer to struct variables part of the interface

of a referenced model or incremental subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a pointer to struct variable is a formal parameter of a step

function created
for a referenced model and the variable class of the pointer to
struct variable
is located in a variable class group in the Data Dictionary, the
code
geneneration for the code geneneration unit containing the
reference to the
model terminates with the error #15268, e.g.
Error #15268: / ... /Variables/Arg_In_Out_REF__d:
Variable class MY_FCN_REF_ARG2 is undefined in the
current data dictionary.
Since TargetLink 3.3 this is also the case for pointer to struct
variable which
are formal parameters of a step function created for
incrementel subsystems.
Workaround: Avoid the use of a variable class located in a variable class
group in such a
case.
patches:
TargetLink 3.3p3
626 / 1260
ID:
KPR.2012.05.08.003
Title:
Generation of incorrect code with uninitialized Aux variables

when using Access Functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the generated code initially has a situation similar to the

following (x is
the variable with access functions):
out1 = x;
out2 = x + 1;
...
x = in1*2;
the code generator may wrongly analyze this and generate
incorrect code with an
aux variable:
out1 = aux;
out2 = aux;
...
aux = in1*2;
setX( aux );
A reading access function to initialize the aux variable is
missing so the uses
of aux read from an uninitialized variable (in the above
example for assignment
to out1 and out2).
patches:
TargetLink 3.3p3
627 / 1260
ID:
KPR.2012.05.09.001
Title:
DSDD merge changes order of components of Data

Dictionary struct objects

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Each Data Dictionary object has a position in its parent's

common child
object/property list (child index). For code generation, this is
significant for
struct variables and struct data types, since their components
are generated
according to the order of the (Variable's or Typedef's)
Component child objects.
However, merging an object into another modifies the
positions of the
destination object's child objects.
Workaround: Correct the order of components manually after merging.
ID:
KPR.2012.05.09.002
Title:
Calculated worst-case range of 1D and 2D Look-up Table

blocks calculated from TargetLink Autoscaling tool might be
wrong

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Calculated worst-case range of 1D and 2D Look-up Table

blocks calculated from
TargetLink Autoscaling tool might be wrong, if
- range of input values is smaller than range of axis points
AND
- the axis points are not integral values.
Workaround: Set constraint limits at these blocks to specify a correct range.
628 / 1260
ID:
KPR.2012.05.09.003
Title:
Auto-save of included DD files via Data Dictionary Matlab API

fails if MainDDDir macro is used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: When an included DD file is loaded, %MainDDDir% macros in

DDIncludeFile.FileName
properties are expanded to the directory where the main DD
file resides.
However, the macros are not expanded when included DD
files are auto-saved using
the Data Dictionary Matlab API's dsdd('save') command.
Instead, an error message
similar to the following is produced:
Title: 'Saving to included file failed'
Message: 'File I/O error during saving to included file
%MainDDDir%\MyTypedefs.dd.'
Note that auto-save is controlled by the
DDIncludeFile.AutoSave property.
Workaround: 1. Save the DD file with the Data Dictionary Manager.
or
2. Add the file attribute to the API command:
dsdd('save',0,'file',dsdd('GetDDAttribute',0,'fileName')) ;
patches:
TargetLink 3.3p3
629 / 1260
ID:
KPR.2012.05.09.004
Title:
AUTOSAR code not compilable with RTE code caused by

generated InterRunnable read function that is not specified in
the model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In an AUTOSAR model, an outport of a subsystem is specified

as using AUTOSAR
InterRunnable communication. The outport is driven by an
outport of another
subsystem that will be implemented as a call-by-reference
parameter of it's
parent subsystem's step function in the generated code. The
signal line between
both outports has a signal split to an inport of a subsystem
that will be
implemented as a function parameter (call-by-value or call-byreference) of its
parent subsystem's step function in the generated code.
Additionally, only the following blocks are placed on these
signal lines:
- not-enhanced in- or outports,
- Mux or Demux blocks,
- Bus Creator or Bus Selector blocks,
- From or Goto blocks, or
- Selector blocks whose index vector is specified via the block
dialog.
In this case, the generated code may contain an additional call
of an
InterRunnable read function (Rte_IrvRead or Rte_IrvIRead)
that is not specified
in the model. The function call is taken as the actual
parameter to the
parameter implemented for the subsystem inport above.
Within TargetLink, the code is still compilable. That means the
TargetLink
simultation modes SIL and PIL are possible. Furthermore, the
code above does not
lead to any simulation differences.
But TargeLink may not generate any AUTOSAR AccessPoint
for the additional
function call. So the code may not be compilable with RTE
code generated by an
RTE generator (as generated e.g. by SystemDesk).
Workaround: Place a additional code generating block (e.g a Rescaler
block) right before the
outport that is specified as using AUTOSAR InterRunnable
communication.
630 / 1260
ID:
KPR.2012.05.09.005
Title:
No re-enhancing of Data Type Conversion blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Simulink Data Type Conversion blocks can be enhanced to Targetlink Rescaler
blocks. When a Simulink system that contains Rescaler blocks is cleared from
TargetLink with the "Keep TL data for re-preparation" option set to "on",
TargetLink data is saved to the de-enhanced blocks to be restored during a
subsequent re-preparation. However, during a re-preparation Data Type
Conversion
blocks with saved TL data are not re-enhanced to TargetLink Rescaler blocks, but
remain unmodified.
Workaround: Write a post preparation hook function that re-enhances DTC blocks with saved TL
data:
hBlocks =
find_system(hSubSystem,'LookUnderMasks','all','RegExp','on','BlockType','DataTyp
eConversion','tag','.+');
for h=hBlocks'
tmp = tl_enhance_block(h,options,bs);
end
Note that this workaround does not include a Simulink --> TargetLink scaling
data mapping. This must be started independently with the tl_sync_system tool.
631 / 1260
ID:
KPR.2012.05.09.006
Title:
Warning about incorrect PoolRef property type when saving

partial Data Dictionary file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When saving a Data Dictionary "Subsystem" object via "Save

as...", the following
warning may occur:
"Possible Broken References After Reload If you want to save
a partial DD
project file and it contains DD handle references inside this
subtree, some of
these references might refer to DD objects that are not part of
the partial DD
project file. Reloading the partial DD project file into another
DD project file
might then cause problems.
The problematic properties are:
(1) Property 'PoolRef' of
//DD0/Subsystems/ModuleA/tl_basetypes/ModuleInfo links
to //DD0/Pool/Modules/TLPredefinedModules/tl_basetypes
This warning occurs due to a wrong Data Dictionary output of
the Code Generator
and may lead to validation errors when validating the partial
DD after reload.
Workaround: Correct the PoolRef properties of modules inside the
Subsystems area manually
after reload of the partial DD file.
patches:
TargetLink 3.3p3
632 / 1260
ID:
KPR.2012.05.09.007
Title:
Data Dictionary Variable objects used for Stateflow data

cannot be scaled with TargetLink Autoscaling tool

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Stateflow objects specified via Data Dictionary Variable

objects are not
autoscaled during TargetLink Autoscaling tool, if
- Scale outputs AND
- Scale DataDictionary Variables
is activated.
In this case no message appears.
Workaround: Scale Data Dictionary Variable objects manually and disable
autoscaling for this
object.
ID:
KPR.2012.05.09.008
Title:
Insufficient Scope Error #17054 for an Access Function

Auxiliary Variable of a TargetLink Root InPort

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
633 / 1260
Description: Background
TargetLink root InPorts are the first TargetLink InPort blocks of
TargetLink
subsystems, incremental subsystems, referenced models
encountered on the input
signal lines of the system.
If the output variable of a TargetLink root InPort has a variable
class
referencing an AccessFunctionTemplate (AFT), then
TargetLink buffers the input
under the following conditions:
- The AFT has a Read AccessFunction that applies to the
variable (READ,
READ_INDEXED, READ_BY_PARAMETER,
READ_INDEXED_BY_PARAMETER) AND
- The FunctionClass referenced by the AccessFunction does
not set the
SIDE_EFFECT_FREE optimization property AND
- The CodeGenerationMode is Standard or AUTOSAR
TargetLink analyzes the resulting C Code, so several root
InPorts sharing the
same variable are considered together. TargetLink identifies a
function calling
all of them in order to find a location where the access
function can be called
as few times as possible; the result is buffered in an auxiliary
variable that
is accessed by the respective functions. Up to TargetLink 3.2,
the variable is
created "Static Global" and not subject to further optimization.
Starting from
TargetLink 3.3, the variable is created "Global" and subject to
subsequent
attempts to reduce it in scope.
Problem
TargetLink terminates with
Error #17054: / ... /Variables/MyInport: The variable
'Aux_MyInport_a' is
implemented with 'module local scope', but requires 'global
scope'.
Possible causes are, up to TargetLink 3.2:
- Aux_MyInport_a needs to be "Global" OR
- Aux_MyInport_a has been created in the wrong module
Workaround: Assign a FunctionClass with set SIDE_EFFECT_FREE
Optimization property to the
Read AccessFunction.
If you need the buffering, then model it explicitly:
- Use the variable as block output of exactly one TargetLink
InPort
- Insert either a Rescaler block (TargetLink >= 3.0) or an
additional
TargetLink InPort (TargetLink < 3.0) after the InPort and
specify this
subsequent block's output variable as needed
634 / 1260
ID:
KPR.2012.05.09.009
Title:
The "More Infos about" plot window always displays LSB

value as arbitrary number for SIL and PIL simulations

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If the 'More Infos about' plot window is opened for a simulation
in SIL or PIL
mode, it always displays LSB as an arbitrary number even if
the block property
'lsb' has to be represented as a power-of-two number.
This problem does not appear for a simulation in MIL mode.
Example:
The block output property 'arb' is 0 and 'lsb' is 2^-9.
The 'More infos about' plot window for this block output shows
the LSB value
2^-9 in MIL mode but 0.001953 in SIL and PIL mode.
Workaround: No workaround available
ID:
KPR.2012.05.11.001
Title:
Aborted Code Generation or incorrect code due inherited

Access Functions for struct components in a Custom Code
block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
635 / 1260
Description: TargetLink currently does not support the use of variables with
an
AccessFunctionTemplate as Custom Code block variables.
This limitation is checked for AccessFunctionTemplates
referenced by the
variable's variable class. If a variable is used that has an
AccessFunctionTemplate or a variable class referencing an
is used, then TargetLink emits an error message, e.g.
Error #20624: Subsystem/Custom Code Block class
GLOBAL_AF used for p variable
has access function template
//DD0/Pool/Templates/AccessFunctions/AFT_Get
specified. Access functions are not supported for variables
used inside Custom
Code blocks.
As of TargetLink 2.2, struct components without an
AccessFunctionTemplate can
inherit AccessFunctionTemplates from their (recursive) parent
struct variables'
variable class. They inherit the first AccessFunctionTemplate
encountered on the
way to the "root" struct.
If a struct component that "inherits" it's
AccessFunctionTemplate is referenced
as block variable of a Custom Code block, then TargetLink
does not detect the
resulting problem. Instead the code generator may either
- terminate with an access violation (in combination with Fatal
Error #99999) OR
- give an unspecific error like #10014 without preceding
messages explaining the
problem OR
- generate wrong code, usually code that does not compile but
there are no
guarantees for not compiling such erroneous code OR
- accidenttaly produce the desired code.
Workaround: If one of the above undesired symptoms occurs, then check
all Custom Code block
variables referencing a struct component of a struct variable
specified in the
Data Dictionary project file. If one of the structs has a variable
class
referencing an AccessFunctionTemplate, then try another
variable class without
an AccessFunctionTemplate.
636 / 1260
ID:
KPR.2012.05.11.002
Title:
Upgrade routine overwrites callbacks of detached TargetLink

library blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Detached TargetLink blocks in a customer library, i.e. blocks

that are not part
of a subsystem and intended to be copied into models directly,
are a special
case because they must be an one-to-one copy of the original
block from tllib.
But usually a copied TargetLink library block automatically
receives callback
functions different from the original in TargetLink's block
library. Therefore
callback functions of detached TargetLink blocks are
accordingly adapted in the
same way by the creator of the library.
Unfortunately the upgrade routine does not distinguish
between regular copied
and detached blocks. Hence the upgrade routine overwrites
callbacks of detached
blocks.
Workaround: By means of an post upgrade hook function the callbacks of
detached blocks can
be adapted again.
637 / 1260
ID:
KPR.2012.05.14.001
Title:
A2L generation for external symbols fails with error 8662 due
to incorrect Variable objects in Data Dictionary Subsystems
area

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When using extern/alias calibratable variables multiple times

inside a model,
the A2L generation may fail with the following error:
-----------------------------------------Message 8662, Kind Error
Title: Data dictionary access error
Message:Error while trying to access the Data Dictionary.
The DD object which the reference property 'Type' of the DD
object
'//DD0/Subsystems/XYZ/xyz/Variables/MyExternCalVar(#2)'
refers to does not
exist.
The error occurs due to incorrect variable objects inside
Simulation Frame
Include File in the Data Dictionary Subsystems area.
Workaround: Delete the respective variable entries from the Frame Include
File (*_fri) DD
module, e.g. during using post codegen hook function.
patches:
TargetLink 3.3p3
638 / 1260
ID:
KPR.2012.05.23.001
Title:
Code generation aborts with Error #17150 if a Vector Element

is assigned to several Elements of a Vector

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink eliminates intermediate variables of vector type

that are used only
in part after their assignments:
b[Aux_S32] = a[Aux_S32];
c[Aux_S32] = 1;
e[Aux_S32] = d;
}
f = (b[i] + c[5]) * e[2];
can be optimized to
f = (a[i] + 1) * d;
If the right-hand side of an assignment is an access to a single
vector element,
l[Aux_S32] = k[0];
then in some cases, usually if the width of k is 1, TargetLink
erroneously tries
to replace the reading accesses by accesses to the
corresponding elements of k,
which may not exist. This leads to an error message like
Error #17150: TL_Subsys/ ... /path/to/block:
Array index out of bounds: block
Workaround: 1) If you set a width of "1" in the Data Dictionary, then you
request a vector
of size 1. Leave the Width property empty for scalar variables.
2) If the vector of width 1 is necessary, then make sure that
the intermediate
vector with higher width cannot be eliminated by assigning a
variable class
without set ERASABLE Optimization property.
3) If the intermediate vector "needs to go", consider
introducing a scalar
intermediate variable e.g. via a Rescaler block. This variable
needs a variable
class without set ERASABLE Optimization property.
639 / 1260
ID:
KPR.2012.05.23.002
Title:
Code generation aborts with Error #03019 for user library with Simulink
port blocks that have saved TargetLink data

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When a block is de-enhanced, it's TargetLink data can be saved to the
tag
property for restoring the date during a later re-enhancement. This also
applies
to Simulink port blocks that had been de-enhanced from Targetlink port
blocks.
The tag property is copied when a block is copied, for example, into a
new
library. Thus it may happen that a Simulink port block in a user library
unintentionally carries saved TargetLink data.
When the user library is used in a system for which code should be
generated,
code generation aborts with an error message #03019:
Error #03019: testModel/ ... /Subsystem/Filter:
block is not supported by TargetLink and no corresponding block is
defined. The
block has a library link to userLib/Filter. The library userLib is yet to be
prepared for TargetLink.
Workaround: Delete saved TL data in the port blocks' tag property. E.g. if <userLib> is
the
name of the user library:
hPorts = find_system(<userLib>,
'LookUnderMasks','all','RegExp','on','BlockType','Inport|Outport','Tag','.+');
set_param(<userLib>,'Lock','off');
for h=hPorts', set_param(h,'tag',''); end
save_system(<userLib>);
TargetLink 3.3p3
640 / 1260
ID:
KPR.2012.05.23.003
Title:
Compilation of SIL fails if Microsoft Visual C++ 2010 Express

or Microsoft Windows SDK 7.1 is used as mex compiler

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: To use the Microsoft Visual C++ 2010 Express with Matlab
64bit Version as a mex
compiler, Microsoft Windows SDK 7.1 must be installed.
But in spite of installation of Window SDK 7.1 the Microsoft
Visual C++ 2010
Express selected as mex compiler cannot be used to compile
the production code
simulation application for the SIL simulation. During the build
process linker
errors similar to the following occur:
LINKING PROGRAM ...
LINKING FAILED
LINKING FAILED. See
.\TLSim\mdl_BSD_Sim\HostPC_MSVC\mdl_BSD_Sim.err for
details
LINK : fatal error LNK1104: cannot open file 'uuid.lib'
MAKE PROCESS ABORTED
In ML 2011b it is also possible to select the Microsoft
Windows SDK 7.1 as a mex
compiler. In this case however TargetLink issues another error
message
*** E02387: DETERMINATION OF THE HOST COMPILER
LOCATION FAILED:
*** Internal error. Cannot determine the installation directory of
the selected
mex compiler. Contact dSPACE Support.
Workaround: If possible use another supported mex compiler.
patches:
TargetLink 3.3p3
641 / 1260
ID:
KPR.2012.05.23.004
Title:
Code generation aborts with error #30016 if an actiontriggered subsystem is placed in a reused system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation aborts with a fatal internal error if one of
the following
subsystems is placed in a reused system:
- a subsystem that is triggered by an If Else block OR
- a subsystem that is triggered by a Switch Case block.
In this case code generation stops with an error message
similiar to the
following one:
Fatal #30016: Subsystem/ ... /aa/OutAA:
reuse. Contact
dSPACE support. Reason: The variable 'OutAA' shall be used
in the subsystem
'Subsystem/ReuseableSys1/aa'. But it was created for the
subsystem
'Subsystem/ReuseableSys1'. Reuse of this variable is not
possible.
patches:
TargetLink 3.3p3
642 / 1260
ID:
KPR.2012.05.23.005
Title:
Code generation aborts with Error #30053 if a customerspecific function is called with different scalings from Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a customer-specific function is specified via an according

script file and
- that function is called from Stateflow more than once AND
- a parameter of that function is specified to have different
scalings (LSB,
Offset) for different calls by the script,
then the Code Generator might issue an error message like
the following:
Error #30053 <chart> Found contradicting specification for
scaling of parameter
<parameter> of function <function>: LSB <LSB1> and
offset<Offset1>. In a
previous call the specified scaling was LSB <LSB2> and offset
<Offset2>. Adapt
your script or, if the function parameter is invariant to scaling,
set the
'ScalingAdjust' property to 'off'.
Workaround: Use different function names for different scalings in the script
and map those
names to the original function name in another header file.
Include that header
file in the generated code, e.g. via an AddFile block.
patches:
TargetLink 3.3p3
643 / 1260
ID:
KPR.2012.05.31.001
Title:
Subsystem and Application objects are deleted when a model

is opened in batch mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When a TargetLink model is opened, it's associated Data

Dictionary project file
is opened automatically. However, in batch mode, Subsystem
and Application
objects in the Data Dictionary are deleted during this process.
Data from prior
code generation runs is thus lost.
Note: TargetLink batch mode is enabled with
ds_error_set('batchMode', 'on');
Workaround: 1. Do not use batch mode when code generation data in the
DD should be
preserved.
or
2. Open the associated DD before the model is opened using
the DD Matlab API
open command, for example with
dsdd('open',<ddFile>,'upgrade','off');
For this workaround, you must make sure that the DD
complies with the current
Data Model, i.e. that it had already been upgraded.
patches:
TargetLink 3.3p3
644 / 1260
ID:
KPR.2012.05.31.002
Title:
Erroneous optimization of variable carrying previous state for

"SIDE_EFFECT_FREE" Access Functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable "x" is used as a state and the state update takes
place prior to
using the old value,
out = x;
x = in;
f(out);
then TargetLink does not eliminate the temporary variable
"out".
If "x" has a Variable Class referencing an
AccessFunctionTemplate with at least
one AccessFunction object that has a function class with set
SIDE_EFFECT_FREE
Optimization property, then it is possible that TargetLink loses
information
about the accessed variables and consequently optimizes
wrongly to
SetX(in);
f(GetX());
Workaround: There are two ways to suppress this optimization:
1) Make sure that "out" cannot be eliminated (via a variable
class without set
ERASABLE Optimization property)
2) Do not use SIDE_EFFECT_FREE.
patches:
TargetLink 3.3p3
645 / 1260
ID:
KPR.2012.05.31.003
Title:
Model specific Data Dictionary filename is replaced by full

path to Data Dictionary file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The Data Dictionary project file which is associated with a

model can be
specified globally or assigned to the model, using the Options
page of the
TargetLink Main Dialog. However, if a Data Dictionary
filename is assigned by
the user and the Data Dictionary file resides in a directory
which is on the
MATLAB search path but is not the model's directory, the Data
Dictionary
filename is automatically augmented to a full path. This
change takes effect
when the model itself is saved to file.
Workaround: Assign the DD file manually with
set_param(<model>,'DS_PROJECTFILE',<fileName>).
patches:
TargetLink 3.3p3
646 / 1260
ID:
KPR.2012.05.31.004
Title:
Incorrect code for Access Functions if a read access is inside

a condition

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the generated code initially has a situation similar to the

following (x is
the variable with access functions, a read access inside an
condition and a
write access inside the if branch):
if( x )
{
...
x = in1*2;
...
}
The code generator may wrongly analyze this and generate
incorrect code with an
aux variable:
if( aux )
{
...
aux = in1*2;
setX( aux );
...
}
The reading access function to initialize the aux variable is
missing so in the
if condition the aux variable is used unintialized.
patches:
TargetLink 3.3p3
647 / 1260
ID:
KPR.2012.05.31.005
Title:
Wrong SIL/PIL simulation results on TargetLink root level in

combination with Function Reuse

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a library subsystem representing a reused function is driving

a Simulink
(un-enhanced) port on TargetLink root level, and the
corresponding variable
generated for this port is inside an instance-specific struct,
then the port on
root level may show wrong SIL/PIL simulation results due to a
wrong interface
variable description inside the Data Dictionary.
Workaround: If possible enhance the corresponding Simulink port(s).
patches:
TargetLink 3.3p3
648 / 1260
ID:
KPR.2012.06.15.001
Title:
Code generation aborts with Fatal #17077 for saturated bit

operation in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in an assignment in Stateflow

- the last operation on the right hand side is a bitwise
operation AND
- the variable on the left hand side has the TargetLink property
'checkmin' or
'checkmax' activated (i.e. saturation),
then the generated code might contain a call to a not existing
macro (TargetLink
3.2) or the code generation aborts
with fatal error #17077 (TargetLink 3.3).
Fatal #17077: <chart> Encountered inconsistent internal state
which will
introduce an invalid call to a TargetLink fixed-point macro.
Contact dSPACE
Support. Additional information: Trying to call a saturation
macro that does not
exist. The name of the macro is <name>.
Example in Stateflow:
c = (b * 0x11) | (a & 0xF0); with c being saturated.
Workaround: 1) Switch off saturation for the bit operation result variable.
2) Introduce a Stateflow action language cast for the right
hand side result e.g. like c = uint8((b * 0x11) | (a & 0xF0));.
patches:
TargetLink 3.3p3
649 / 1260
ID:
KPR.2012.07.03.002
Title:
Possibly reduced precision of values for 'min' and 'max' of

Stateflow data objects

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: TargetLink Stateflow properties 'min' and 'max' are only stored
with about 4
digits after decimal point. Values that require more digits thus
may be reduced
in precision.
As TargetLink sets Stateflow properties as a whole, the
problem may always occur
in case any Stateflow property, even other than min/max, is
changed by a
TargetLink API command or GUI function. For example this
means especially
tl_set(), tl_upgrade(), the TargetLink Property Manager and
the Autoscaling
tool, the Rename&Adapt operation of the Data Dictionary
Manager if Stateflow
data is associated with Variable objects and also the creation
of such Variable
objects for Stateflow with the Model Browser.
In addition with TargetLink 3.x this problem may also happen
if Stateflow
scaling data is synchronized during System Preparation or via
System
Synchronization.
Note: other properties like e.g. sf.lsb are not affected by a
reduced precision.
Workaround: If more precision is required, then use Stateflow's own object
dialog or API to
set the Minimum/Maximum properties again after changing
any TargetLink Stateflow
property with TargetLink.
650 / 1260
ID:
KPR.2012.07.04.001
Title:
Wrong results for saturation of unsigned 64-bit value to lower

limit less than 0

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Saturation of an unsigned 64-bit value to an lower limit less

than 0 may
calculate wrong results, e.g. the value may overflow, as the
saturation code is
not implemented correctly.
The problem can be identified in the generated code, because
the following
macros are affected if the lower limit (losatval) has a negativ
value:
C_I32SATU64_SATb(v_h, v_l, upsatval, losatval)
C_I32SATU64_SATl(v_h, v_l, losatval)
651 / 1260
ID:
KPR.2012.07.04.002
Title:
TargetLink subsystem ID is changed when removing or

adding the TargetLink simulation frame

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: Each TargetLink subsystem has an ID which must be unique

in the list of all TL
subsystems in the model. However, when the simulation
frame of a TargetLink
subsystem is removed, its associated TargetLink subsystem
ID maybe set to a
default value (usually "a", but unique to other subsystem IDs
in the same model,
so e.g. "b" if "a" already exists). The same applies when a
simulation frame is
added again after prior removal.
Note: The TargetLink Main Dialog or tl_clear_system() and
tl_prepare_system()
can be used to remove or insert the TargetLink specific
simulation frame that is
needed for SIL/PIL simulation.
Workaround: Manually set the TargetLink subsystem ID to the desired value
via Main dialog or
by API.
patches:
TargetLink 3.3p4
652 / 1260
ID:
KPR.2012.07.04.003
Title:
Wrong operation argument order if InPort or OutPort blocks of

AUTOSAR runnable/operation-call subsystem contain
leading/trailing spaces

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the names of InPort or OutPort blocks of an AUTOSAR

runnable or
operation-call subsystem contain leading/trailing spaces, the
order of the
operation arguments in the generated production code may be
different from the
operation argument order defined at the respective
ClientServerInterface object
Workaround: Remove whitespace from the names of InPort and OutPort
blocks of server runnable
and operation-call subsystems.
patches:
TargetLink 3.3p4
ID:
KPR.2012.07.04.004
Title:
Stateflow temporal logic events may never be executed

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the counter argument of a temporal logic event is given by a

Stateflow data
object with scope 'Input' or by an expression using such a data
object and if
this Stateflow Input is fed by a Constant block inside the
TargetLink subsystem,
then the temporal logic event may never executed. I.e. the
generated code can be
wrong but compilable.
Workaround: Define either the Constant block as non-optimizable variable
or the Stateflow
Input (createinputvariable=1).
653 / 1260
ID:
KPR.2012.07.04.005
Title:
Autoscaling 'Refresh netlist' fails with an error if blocks have

been deleted in between

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During autoscaling "refesh netlist" may fail if

- show ranges or show scaling is activated and
- model is modified by deleting blocks.
In such a case an error message like the following is printed
on MATLAB command
line:
??? Index exceeds matrix dimensions.
Error in ==> tl_restore_AFS at 78
Workaround: After deleting blocks in the model, close the autoscaling tool
once and then
start it again.
ID:
KPR.2012.07.04.006
Title:
Calibratable or measurable variable is missing in generated

A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In case in the production code calibratable or measurable

variables are defined
with names that differ only in upper and lower case, for
example Sa1_XY, Sa1_xy
and Sa1_Xy, then in the ASAP2/A2L file generated by
TargetLink for this
production code only one of these variables will be described,
i.e. either
Sa1_XY or Sa1_xy or Sa1_Xy.
Workaround: Avoid generating production code with variables whose
names differ only in in
upper and lower case. For this either set explicitly the variable
name in the
Varibale-Name edit field of the TargetLink block dialog or, in
case you use the
$S_$B name macro, ensure that the names of the blocks
(=$B) in the same
subsystem (=$S) differ not only in upper and lower case but
also in other
characters.
ID:
KPR.2012.07.09.001
654 / 1260
Title:
Incorrect code generated with erroneous combination of read

and write accesses of the same variable in a function call

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink performs elimination of actual variables of function

calls if there
is a replacement variable subject to a preceding or
subsequent copy assignment,
respectively:
foo() {
in = a;
bar(in, &out);
b = out;
for (Aux = 0; Aux < 10; ++Aux) {
IN[Aux] = A[Aux];
}
baz(IN, OUT);
for (Aux = 0; Aux < 10; ++Aux) {
B[Aux] = OUT[Aux];
}
}
becomes
foo() {
bar(a, &b);
baz(A, B);
}
If instead of "a" and "b" ("A" and "B"), there is only one
variable "x" ("X"),
then TargetLink still performs this optimization, leading to
foo() {
bar(x, &x);
baz(X, X);
}
This code is correct for the scalar case "bar(x, &x)" because
the previous value
of "x" is copied at function call.
For the vector case "baz(X, X)", the code is only correct if the
data flow
inside baz() allows for optimization, e.g.
baz(T In[10], T Out[10]) {
for (Aux = 0; Aux < 10; ++Aux) {
Out[Aux] = Par[Aux] * In[Aux];
}
}
is allowed because every element of "Out" (i.e. "X") is
changed only after all
reading accesses to the corresponding element of "In" (i.e.
"X") have taken
place but
655 / 1260
baz(T In[10], T Out[10]) {

static T D;
Out[0] = D;
for (Aux = 0; Aux < 9; ++Aux) {
Out[Aux + 1] = In[Aux];
}
D = In[9];
}
leads to different behavior of the optimized code because
"X[1]" is changed as
"Out[1]" in the first loop iteration and read as "In[1]" in the
second loop
iteration.
Example:
A Unit delay block connects an output and an input of a
subsystem containing a
Function block.
Note that in this case, inefficient modeling can lead to more
errors, e.g. if
the function output variable is the output variable of a
TargetLink Outport
block of a For Iterator subsystem: The Outport variable is
subject to a complete
copy assignment in every iteration step (as modeled). If
instead the For
iterator subsystem is inside a subsystem with the Function
block, then the
output of the iterated subsystem is copied once to the Outport
specifying the
function output after execution of the iterated subsystem. This
decoupling of
the respective loops may lead to a decoupling of reading and
writing as in the
"good case" above whereas the "copy loop inside For Iterator
loop" approach
leads to writing the full output vector ahead of the second,
third etc. element
of the input even in the "good case".
Workaround: Explicitly model the decoupling by inserting a Rescaler block
(or, prior to
TargetLink 3.0, a TargetLink OutPort block) on the line driving
the function
input. Specify a variable class without set ERASABLE
optimization property.
656 / 1260
ID:
KPR.2012.07.13.001
Title:
Undocumented limitation: Function Reuse code generated by

different TargetLink versions may be incompatible

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Code generated for a function reused system may not

generally be compatible
between different TargetLink versions.
A reused function and the generated reuse structures may
differ by TargetLink
version. This means that generating new instance calls to the
reused function
without also generating the code for the reused function itself
again may not
work, as e.g. layout or content of the reuse structure is
generated differently.
Problem: The user documentation for TargetLink versions
before 3.4 did not
mention this limitation.
Workaround: To ensure that the function reuse code is compatible a
complete code comparison
of the reused function code and the reuse structures has to be
done.
If this comparison reveals differences in the function interface
or the reuse
structure the only way to avoid problems when combining the
generated code is to
duplicate the reused function once per involved TargetLink
version. For this
change the name of the reuse functions, for example by
adding "_TL33" as suffix,
and change the code file into which the reused system is
generated. In this way
the old implementation and the new do not conflict which each
other.
657 / 1260
ID:
KPR.2012.07.26.002
Title:
Erroneous code following a MinMax block with struct

components as operands

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a MinMax block

- has a variable class, that is not global or static AND
- at least one of the outputs of a predecessor block is
implemented as a
structure component,
then the internal representation of the worst case range of the
MinMax block's
result range
might be smaller than required, which might lead to generation
of erroneous
code.
The predecessor's output might be implemented as structure
component, if it
- is moved to a reuse structure or if
- the variable has variants or if
- it is a component in structure that is specified to be a
function parameter.
The effects of this problem on the generated production code
might be like
following
- erroneously omited saturation
- overflows because operations are calculated in a smaller
type than necessary
(e.g. 8 bit)
- erroneously omited control flow
Workaround: Choose a global or static variable class for the output of the
MinMax block.
658 / 1260
ID:
KPR.2012.07.26.003
Title:
Not all of imported AUTOSAR objects are saved in Data

Dictionary file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: It may happen that Data Dictionary objects that are newly
created during AUTOSAR
2.x/3.x import are not saved when the working Data Dictionary
is saved to a
file. Thus, when the saved Data Dictionary file is reloaded, the
objects newly
created by the AUTOSAR import are missing.
The problem cause why the newly created Data Dictionary
objects are not saved to
a file is that they still have the attribute 'temporary' set to 1.
Workaround: After AUTOSAR import set the attribute 'temporary' of the
imported Data
Dictionary objects to 0.
E. g. for Typdef and TypedefGroup objects this can be
performed by the following
m-script:
hTypes = dsdd('find', '/Pool/Typedefs', 'objectkind', 'Typedef');
for n=1:numel(hTypes)
errorCode = dsdd('SetAttribute', hTypes(n), 'temporary', 0);
end
hTypeGroups = dsdd('find', '/Pool/Typedefs', 'objectkind',
'TypedefGroup');
for n=1:numel(hTypeGroups)
errorCode = dsdd('SetAttribute', hTypeGroups(n), 'temporary',
0);
end
To perform the reset of the temporary attribute automatically
after every
ordinary AUTOSAR 2.x/3.x import you can place the reset
code in the
tl_post_arimport_hook.m file.
patches:
TargetLink 3.3p4
ID:
KPR.2012.07.26.004
Title:
Code generation for Access Functions aborts with a fatal error

#99999
659 / 1260
TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the right hand side of a supposed state update statement

contains (after
optimization) an access function call that is subject to
dereferencing, address
taking or index access, e.g.
X_Sa4_Unit_Delay = (sint16) *(Rte_Pim_MyPIM());
Sa4_DataStore = GetAddressOfMyVar()[5];
then the TargetLink Code Generator may terminate with an
access violation like
following:
Fault address: 38CA62F1 01:000352F1
D:\TargetLink\tl_3_3\Matlab\Tl\Bin\XcgCV.dll
Call stack:
Address Frame
0000000038CA62F1 0000000000C22C58
0001:00000000000352F1
00000000390F28D7 0000000000C22C68
0001:00000000004818D7
[...]
The problem only occurs for variable access functions, i.e.
Data Dictionary
AccessFunction object Kinds ADDRESS,
ADDRESS_BY_PARAMETER, DIRECT,
DIRECT_BY_PARAMETER. Note that some RTE API calls
are realized via access
functions, too.
Statements eligible for this State Update code scheduling
optimization are,
apart from the obvious, possibly also caused by the following
blocks: Data Store
Write, Merge, and Outports of conditionally executed
(enabled, triggered,
action-port-triggered etc.) systems.
660 / 1260
Workaround: 1) Switch off the code generator option

"ExtendedLifeTimeOptimization".
or
2) If you can identify the block B causing the assignment that
leads to the
access violation, you can instead place a Rescaler block with
Inherit Propertys
activated and a non-ERASABLE output variable class
between the block A
containing the variable with the AccessFunctionTemplate in its
class and "B".
Note: There may be additional blocks between "A" and "B".
This approach causes
an additional variable and may or may not lead to more
efficient code than
switching off the code generator option.
patches:
TargetLink 3.3p4
ID:
KPR.2012.07.26.005
Title:
Differences between MIL and SIL/PIL simulations due to

differing precedence for power operator in Stateflow action
language

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: In Stateflow the ^ sign is interpreted as the power operator if

the chart
property 'Enable C-bit operations' is disabled. In this case, in
MIL simulation
it has a higher precedence than the unary operators (-, ! and
~). However in
TargetLink the precedence level of the power operator lies
above the
multiplicative operators (*, / and %%), but below the unary
operators.
Thus, for example, the Stateflow action language expression x^y is understood
as
-(x^y) by Stateflow and
(-x)^y by TargetLink.
Workaround: Use the pow function, i.e. -pow(x, y) instead of -x^y,
or
specify your desired order of operations more clearly by using
parentheses
-(x^y).
ID:
KPR.2012.07.28.002
661 / 1260
Title:
Missing saturation code in Stateflow charts for variable with

(static) local variable class

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
662 / 1260
Description: In the generated production code for certain Stateflow charts

the saturation
code may be missing, which may lead to incorrect results if
operations overflow.
Saturation code in Stateflow is normally generated for
assignments where at
least one of the properties 'checkmin' or 'checkmax' is enabled
for the variable
on the left-hand side, but the saturation code is missing if all of
the
following conditions hold:
- The assignment takes place in a function other than the step
function of the
Stateflow chart AND
- for the left-hand side variable of the assignment a variable
class with
(static) local scope is specified.
Affected functions are not only user-defined functions like
graphical functions,
but also auxiliary functions, like entry functions, entry action
functions,
during functions, exit functions and node functions.
Note that after code generation such functions may have been
inlined in the
caller's code, in which case the problem still occurs. So, in
order to see them,
generate code with code generation option for Inline
Threshold set to 0.
In case of above condition the left-hand variable is then
passed by reference
from the chart function to the subordinate function.
Example:
Let A, B and C be local variables of the chart. Let A have
saturation enabled.
The action language statement
A = B + C;
found in a graphical function F is then translated as
/* in the chart function */
F(&A, &B, &C);
/* graphical function */
Void F(Int16* AUX_A, Int16* AUX_B, Int16* AUX_C)
{
(*AUX_A) = (*AUX_B) + (*AUX_C);
/* No saturation code. */
}
663 / 1260
Workaround: Specify either the default variable class or a variable class

with global scope
for Stateflow variables with saturation. For improved code
efficiency in case
all occurrences of such a variable are in inlined functions, the
global variable
class should have the optimization flag SCOPE_REDUCIBLE.
The optimization will
then reduce the variable's scope after inlining, as possible.
ID:
KPR.2012.08.02.001
Title:
Code generation fails with error #08921 for models containing

incremental code generation units

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an interface variable or the typedef of an interface variable

of an
incremental code generation unit is placed in an external
module and if the
EmitFile-Property of the DD FileSpecification objects of the
external module are
set to 'auto' or 'on', then the code generation incorrectly aborts
with an error
message #08921 like the following:
Error #08921: A valid PoolRef is expected for the DD object.
Do not edit the
Subsystems area. Remember to generate code for a
incremental code unit again, if
you have edited DD objects in the Pool area that are relevant
for the
incremental code unit.
Workaround: Set the EmitFile property of the corresponding
FileSpecification objects to
'off'.
664 / 1260
ID:
KPR.2012.08.02.002
Title:
Build of a stand-alone S-Function fails if user modules

specified via Data Dictionary Module objects should be
compiled and linked

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In same cases you may use your own module for building a
SIL/PIL simulation
application and/or a standalone S-function of a TargetLink
subsystem instead of
a module generated by the TargetLink Code Generator. For
example, you wish use
an own module containing definitions for variables used in
code.
To accomplish this you can specify a Module object in Data
Dictionary and create
corresponding FileSpecification child objects with their
EmitFile property set
to 'off'.
Additional you have to specify the search path for your
modules at
/Config/TargetLink.
If you then build a SIL/PIL application the compilation
succeeds, but building a
stand-alone S-Function either by means of the Stand-alone
Model Manager Dialog
or tl_build_standalone or tl_tl2rti API functions may fail with an
error similar
to the following one:
D:\MATLAB\R2011B\BIN\MEX.PL: Error:
'.\TLSim\BuildStandaloneSFcn\<subsystem>\<module>.c' not
found.
Workaround: Specify your own module additionally via the AddFile block
placed at the root
level of the TargetLink subsystem and in a
post_codegen_hook function
delete the /Subsystems/<subsystem>/<modulename> module
object, if created by the
Code Generator.
patches:
TargetLink 3.3p4
ID:
KPR.2012.08.02.003
Title:
Certain variables are not initialized in a restart function if they

become part of the global bitfield structure
665 / 1260
TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The following kinds of implicitly created variables are not

initialized in a
restart function if they become part of the global bitfiled
structure:
- ResetStateWhenDisabling (Rswe)
Used for an enabled subsystem in which the States when
enabling property of the
Enable port is set to ?reset?. It indicates whether the enabled
subsystem is to
be reset before its next execution.
- ResetOutputWhenEnabling (Rowd)
Used for an enabled subsystem in which the States when
enabling property of the
Enable port is set to ?reset?. It indicates whether the enabled
subsystem is to
be reset before its next execution.
- FirstRun
Used to indicate whether a subsystem is executed for the first
time. It is used
for certain blocks which require this information, for example,
edge-triggered
blocks.
- LastEvent
Used as an auxiliary variable for implementing trigger logic. It
indicates
whether the triggered block was triggered in time step [n-1].
- TriggerInputState
Used as an auxiliary variable for implementing trigger logic. It
holds the
trigger input state.
- FlipFlopState
Used to hold the input state of certain flip flop blocks (JK and
D).
- GlobalInterfaceVar
Used as an interface variable for unspecifed subsystem
inports/outports to
implement a global interface so that the variable can also be
used for the
preceeding/succeeding inports/outports (kind of optimization).
Furthermore a block variable of a block with activated "Inherit
properties"
setting is not initialized in a restart function if it becomes part
of the
global bitfiled structure and the following conditions are
fulfilled:
- the variable is scalar AND
- the variable class specified in the block is "default" AND
- the variable has an initial value AND
- the block inherits the Bool type.
Notes:
A variable has to be initialized in a restart function if for its
default
variable class a variable class template is specified in the
666 / 1260
Data Dictionary
which references a variable class from the Data Dictionay with
the
RestartFunction property set.
Variables will become part of the global bitfield structure if
they are bool and
scalar and if on the Advanced page of the TargetLink Main
Diaog the option "Use
global bitfields for boolans" ist activated.
Workaround: Avoid placement of the variables into the global bitfield
structure:
- For implicitly created variables specifies a variable template
in the Data
Dictionary. In the settings of the variable template select a
variable class
with the RestartFunction property set.
- For variables resulting from a block with activated "Inherit
properties"
setting select a variable class from the Data Dictionary with
the
RestartFunction property set.
ID:
KPR.2012.08.02.004
Title:
Error #02091 incorrectly reported

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In case
- an output signal of a TargetLink subsystem is specified with
a Simulink.Signal
object and then
- the subsystem is set into SIL or PIL simulation mode
TargetLink produces an error message #02091 which reads
Error #02091:
The Simulink.Signal object OutSig specifies the signal of the
TargetLink
subsystem output port OutPort, and the Data
Validity/Signals/Signal Resolution
configuration parameter is set to 'Explicit and implicit'. SIL/PIL
simulation is
therefore not possible.
This message is sometimes misleading. Simulation is only
impossible if the
RTWInfo.Storage property of the Simulink.Signal object is not
"Auto".
Workaround: In case of RTWInfo.Storage = "Auto" the message can be
ignored.
667 / 1260
ID:
KPR.2012.08.06.001
Title:
Aborted code generation with error #10014 without preceding

error message for Struct Access Functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Starting from TargetLink 3.3, TargetLink identifies variable

access patterns for
variables that are to be accessed via access functions or
macros.
Example:
if (cond) {
S.m = a;
} else {
S.m = b;
}
o = S.m;
TargetLink usually creates
if (cond) {
aux = a;
} else {
aux = b;
}
<Assign the value of "aux" to S.m>
o = aux;
Depending on whether the Data Dictionary AccessFunction
object applies to "m" or
"S", TargetLink has to create
SetM(aux);
or
*GetAddressOfM() = aux;
for the former case and
GetAddressOfS()->m = aux;
in the latter case. For the struct access function case the
TargetLink Code
Generator incorrectly terminates with error #10014 without
preceding error
messages.
Note: For TargetLink <= 3.3, struct access functions are only
possible if
CodeGenerationMode=AUTOSAR and are used for access to
AUTOSAR PIM and
calibration variables.
Workaround: If possible, use struct member access functions instead.
668 / 1260
ID:
KPR.2012.08.08.001
Title:
Code generation fails with error #17107 when user function

header comments are activated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If user-defined style of function header comments is activated

in the style
definition file (cconfig.xml) and if the model contains Look-Up
Table blocks,
then the code generation incorrectly aborts with an error
message #17107 like
the following:
Fatal #17107: An error occurred in processing XSL:
Generated Document
.\TLProj\<...>.c contains a parse error at Line: 0 Element
'{http://www.dspace.de/TargetLink}settings-description' is
unexpected according
to content model of parent element
'{http://www.dspace.de/TargetLink}user-function-header'.
Workaround: Disable XML validation in the root element of the style
definition file
(cconfig.xml):
validate-xml-against-schema="false".
669 / 1260
ID:
KPR.2012.08.08.002
Title:
Code generation for Access Functions aborts with access

violation and error #99999

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: During code generation, a call stack like the following (for
TargetLink 3.3p3)
terminates the code generation unsuccessfully
Fault address: 3CD2D9C1 01:0036C9C1 C:\Program
Files\dSPACE TargetLink
3.3\Matlab\Tl\Bin\XcgCVT.dll
Call stack:
Address Frame
000000003CD2D9C1 0000000000C25010
0001:000000000036C9C1 C:\Program Files\dSPACE
TargetLink 3.3\Matlab\Tl\Bin\XcgCVT.dll
000000003CDBD66E 0000000000C250FC
0001:00000000003FC66E C:\Program Files\dSPACE
000000003CA0964E 0000000000C253A0
0001:000000000004864E C:\Program Files\dSPACE
000000003CF034DB 0000000000C254D4
0001:00000000005424DB C:\Program Files\dSPACE
This problem can occur if several variables with access
function templates are
accessed in one statement and one of the variable accesses
necessitates creation
of an additional statement during the code generation (e.g. for
copying the
variable to an auxiliary variable).
Note: several kinds of AUTOSAR RTE API accesses are
realized via access
functions and thus may also trigger this problem.
670 / 1260
ID:
KPR.2012.08.08.003
Title:
Simulation mat file does not keep unit information

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The simulation mat file which can be saved and opened from
the 'Simulation' tab
of the TargetLink Main Dialog does not keep the 'unit'
property. Therefore the
plot window for a simulation which is opened from the mat file
does not show the
unit information.
ID:
KPR.2012.08.08.004
Title:
AUTOSAR 2.x/3.x import saturates upper limit of linear

CompuMethod to SINT32_MAX

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If an AUTOSAR 2.x/3.x XML file to be imported contains a

COMPU-METHOD with a
COMPU-SCALE of category LINEAR, the UPPER-LIMIT of
the COMPU-SCALE is not
imported correctly in case of an UPPER-LIMIT greater than
SINT32_MAX.
If the UPPER-LIMIT is greater than SINT32_MAX, the
property "LinearMax" of the
respective Scaling object is saturated to SINT32_MAX instead
of containing the
UPPER-LIMIT's actual value.
patches:
TargetLink 3.3p4
671 / 1260
ID:
KPR.2012.08.08.006
Title:
OK button inside the State Space Scaling Tool and Transfer

Function Scaling Tool dialogs does not work

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Open the State Space Scaling Tool dialog from Discrete State
Space block or the
Transfer Function Scaling Tool dialog from Discret Transfer
Function block or
Discrete Filter block optimized output scaling can be
calculated. But the
calculated scaling cannot be set automatically to the output
variable.
Pressing of the OK button leads to error "??? Reference to
non-existent field
'maskType'."
Workaround: Use the scaling tool to calculate optimized scaling and then
maually transfer
the results.
ID:
KPR.2012.08.14.001
Title:
Edit Dialog for DeclarationStatements in the Data Dictionary

cannot handle commas inside statements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The Data Dictionary Manager provides for a property named

'DeclarationStatements' a dialog called DeclarationStatements
Dialog. In this
dialog a string can be entered for each type of a Declaration
statement. In case
this String contains a comma, the string is incorrectly splitted,
when the value
is written back to the DataDictionary.
Workaround: Enter declaration statements directly in DD Manager in the
Property Value List
e. g. "PreDefinitionStatement","Text with a , inside."
OR
Use SetDeclarationStatements API command to set
declaration statements.
672 / 1260
ID:
KPR.2012.08.17.001
Title:
TLC file for TargetLink Custom Code blocks yields wrong simulation
results

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For TargetLink Custom Code blocks, TLC files can be generated
enabling to run
the custom code in RTW generated applications. The TLC file is
needed when a
model is simulated in accelerator mode, when a Custom Code block
resides in a
referenced model, or when RTW code is needed for another purpose.
However, if
the following conditions are met, the TLC file yields wrong simulation
results:
- The Custom Code block has at least one input that is scaled, i.e. the
associated LSB != 2^0 and/or the Offset != 0.0.
- The "use production code for MIL simulation" property is set to "off".
In the TLC code, the input is scaled instead of being used as-is.
Example:
/* declaration of input u */
Int16 u;
u=
SCALE_FP_FX(Int16,%<LibBlockInputSignal(0,"","",0)>,0.00390625,0);
is generated for a scalar input u with Int16, 2^-8, 0.0 instead of
/* declaration of input u */
Float64 u;
u = (Float64)%<LibBlockInputSignal(0,"","",0)>;
Workaround: Modify the TLC file manually. Make sure that inputs are declared as
Float64 and
are not scaled with the SCALE_FP_FX macro, but used as-is.
673 / 1260
ID:
KPR.2012.08.23.001
Title:
Bus signal plot shows always the unit of the first bus element
for all elements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a TargetLink block variable contains a non empty unit entry

(e.g. 'm/s'), the
unit is displayed in the title of the corresponding plot window,
enclosed in
brackets.
This mechanism does not work correctly for bus signals. The
bus element signal
plot window displays always the unit of the first bus element
also for any other
plotted bus elements.
ID:
KPR.2012.08.23.002
Title:
AUTOSAR 2.x/3.x import of SENDER-RECEIVERINTERFACE with MODE-DECLARATION-GROUPPROTOTYPE raises error E08735

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The error E08735 is thrown during the import of a SENDERRECEIVER-INTERFACE

containing a MODE-DECLARATION-GROUP-PROTOTYPE, if
the SENDER-RECEIVER-INTERFACE
does not specify any data elements, but contains an empty
<DATA-ELEMENTS/> tag.
The SenderReceiverInterface with name <InterfaceName>
cannot be imported,
because specifying DataElementPrototypes and
ModeDeclarationGroupPrototypes at
the same SenderReceiverInterface is not allowed.
Workaround: Remove the empty <DATA-ELEMENTS/> tag prior to import.
674 / 1260
ID:
KPR.2012.08.23.003
Title:
Code generation aborts with fatal error #99999 for AUTOSAR

struct operation arguments having a non-empty Width
property

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When generating code for an AUTOSAR struct operation

argument that has a
non-empty Width property, the code generation will abort with
a fatal error
#99999 and access violations are printed on the MATLAB
command line:
Fault address: 35D05695 01:00094695
C:\TargetLink_3_3\Matlab\Tl\Bin\XcgCV.dll
Fault address: DAA4D440 01:0009C440
D:\TargetLink_3_3_64Bit\Matlab\Tl\Bin\XcgCV.dll
Workaround: Note that TargetLink currently does not support arrays of
structs, so only
scalars are allowed.
For a scalar delete/unset the Width property at the struct
OperationArgument
object in the Data Dictionary instead of specifying 1.
Note with a script similar to the following all such objects can
be found:
hOperationArguments = dsdd('find', '/Pool/Autosar',
'ObjectKind',
'OperationArgument');
hDataElements = dsdd('find', '/Pool/Autosar', 'ObjectKind',
'DataElement');
hElems = [hOperationArguments hDataElements];
for n=1:numel(hElems)
hType = dsdd('GetTypeTarget', hElems(n));
BaseType = dsdd('get', hType, 'BaseType');
if strcmp(BaseType, 'Struct')
Width = dsdd('get', hElems(n), 'Width');
if ~isempty(Width)
msg = sprintf('Found vector struct: %s', dsdd('GetAttribute',
hElems(n), 'path'));
disp(msg);
end
end
end
675 / 1260
ID:
KPR.2012.08.23.004
Title:
TLPredefinedOptionSet has wrong value for the option

"CodeGenerationMode" in dsdd_master_autosar.dd

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: In the Data Dictionary AUTOSAR template "dsdd_master_autosar.dd" the

code
generation mode is incorrectly set to "Standard"
(/Pool/CodegenOptionSets/TLPredefinedOptionSet.CodeGenerationMode=0)
and not to
"AUTOSAR" (CodeGenerationMode=1). This can lead to errors in the context
of code
generation directly from the Data Dictionary for AUTOSAR applications.
Example: If an AUTOSAR module for which code shall be generated directly
from
the Data Dictionary contains a variable (with global scope) of the type
TlDataTypes/Int16. If the code generation mode is set to "0", i.e. "Standard",
an error message like the following appears:
E32106 The Module object has CodeGenerationBasis set to 'DDBased', but
includes
the module Rte_Type, which has CodeGenerationBasis
'ModelAndDDBased'. This is
not allowed.
Workaround: Set /Pool/CodegenOptionSets/TLPredefinedOptionSet.CodeGenerationMode
to "1" in
676 / 1260
ID:
KPR.2012.08.23.005
Title:
Unallowed change of sign for the coefficients of a Discrete

Filter or Discrete Transfer Function block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink changes the signs of coefficients for the

denominator of a Discrete
Filter and a Discrete Transfer Function block, to generate
code patterns like
y = y + coeff * x
Some compilers recognize this as a MAC (multiply
accumulate) expression, if it
is implemented as an instruction in the target hardware, which
makes the code
more efficient.
Problems occur when the coefficients are specified to be
struct components AND
1.) if the variable class of the coefficients has the Info property
set to
"readwrite" (i.e. calibratable), the switch of signs for
coefficients in the
code may lead to erroneous results when using a calibration
tool.
--- OR -2.) if the variable class of the coefficients has the Storage
property set to
'extern', the switch of signs for coefficients in the code may
lead to erroneous
results, because the extern definition still has the unchanged
values, as they
are not generated by TargetLink.
Workaround: Set the additional Code Generator option
"KeepDenominatorCoefSign" = "on".
patches:
TargetLink 3.3p4
677 / 1260
ID:
KPR.2012.08.23.006
Title:
Long code generation times with bus and function-call signals

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: In case of
- big model (> 5000 blocks) with TargetLink subsystem with
bus signals at its
inports AND
- the buses have at least dozens of signals with different data
types AND
- additionally, function-call signals run into the subsystem
the code generation may take long time, e.g. up to several
hours.
Workaround: Invoke tl_generate_code() with the CheckSystem option set to
"off".
patches:
TargetLink 3.3p4
ID:
KPR.2012.08.27.001
Title:
Code generation aborts with Error #17054 for Struct

Components initialized in Restart Function or Init Runnable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
678 / 1260
Description: TargetLink reduces variables, including struct variables, to

smaller visibility
(global to module local to function local) if the variable has a
default
variable class or a user variable class with the Optimization
property
SCOPE_REDUCIBLE set. In addition, for function local scope,
TargetLink tries to
reduce from static storage duration to automatic storage
duration.
If a variable has a variable class with non-empty
RestartFunctionName property,
then accesses in the respective restart function or Init
runnable have to be
ignored for this last analysis step, as neither static nor restart
initialization are necessary for automatic storage duration. For
struct
variables, it is possible that TargetLink omits struct component
reinitialization in restart functions / Init runnables for the
visibility
analysis as well. As a consequence, struct variables that have
accesses in one
module and restart reinitialization in another module may be
reduced to module
local or function local visibility, leading to code that would not
compile. In
this case, TargetLink terminates with error #17054, e.g.
Error #17054: TL_Component/Run_Y/SomeLibFcn:
The variable 'tagISV_Sa5_SomeLibFcn' is implemented with
'module local scope',
but requires 'global scope'.
This problem can also occur for implicit struct variables like
instance structs
for function reuse.
679 / 1260
Workaround: - If the struct variable can be explicitly specified, then use a

non-SCOPE_REDUCIBLE variable class.
- Otherwise: If it is a special kind of implicit struct, e.g. a
function reuse
instance struct, then specify a non-SCOPE_REDUCIBLE
variable class via the
appropriate StructTemplate in the Data Dictionary
- Otherwise: If the respective struct is an interface variable
(IF_...), then
specifying an additional struct variable via a bus inport or bus
outport taking
the place of the implicit interface variable allows for specifying
the now
explicit struct interface variable
- Otherwise: Generate code with deactivated optimization.
Analyze the accesses
to the struct variable. If possible, drag out the non-restart
accesses to at
least two files. If not, try to restrict all accesses to one file. If
this does
not work, then no easy workaround is available.
patches:
TargetLink 3.3p4
ID:
KPR.2012.08.27.002
Title:
Property "inheritscaling" of Merge block cannot be activated

via dialog for user types with scaling

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The property "inheritscaling" of the Merge block cannot be

activated via dialog,
if a scaling is defined at the currently selected type.
This happens, independent the value of the inheritscaling
property. If the
scaling property is derived from the user data type und the
dialog is opened,
then the inherit scaling checkbox is always deactivated and
cannot be activated
anymore. If the dialog is closed using the 'close' button
"inheritscaling" is
set to 'false' in the blockdata.
Workaround: Use the API to set the property: tl_set(<block>, 'inheritscaling',
1)
680 / 1260
ID:
KPR.2012.08.30.001
Title:
'Uniform elements' checkbox inside Custom Code block

behaves wrong

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If a signal with a width > 1 enters a custom code block and
same scalings should
be applied for the vector signals elements, activating the
'Uniform elements'
checkbox incorrectly does not equalize the elements inside
the block data
accordingly to the currently displayed scaling specifications
visible in the
block dialog GUI. Therefore after applying, closing and
reopening the dialog,
the old settings are still in place and the checkbox is not
checked anymore, as
it reacts to the saved settings in the block data. Similar the
generated
production code may not use one uniform scaling for all vector
elements, but be
generated from the old data that was set for the block before.
Workaround: 1) Either apply the same scaling settings for each element.
or
2) Use the API to set equal scalings for all elements, e.g.
tl_set(<block>,
'output.lsb, [2^-10 2^-10 2^-10 2^-10 2^-10]).
patches:
TargetLink 3.3p4
681 / 1260
ID:
KPR.2012.08.30.002
Title:
Generated code contains broken japanese or other non USASCII characters

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In some cases characters from outside the US-ASCII range,

do not show up
correctly in the generated production code if the
MATLAB/Simulink
slCharacterEncoding is set to an encoding different from the
local encoding of
your Windows Operating System.
Note: characters outside the ASCII range or only supported
for descriptions and
comments. So in the generated production code only
comments are affected, not
the C code itself.
Workaround: If possible avoid using different character encodings in your
Windows Operating
System and for the slCharacterEncoding in MATLAB/Simulink.
682 / 1260
ID:
KPR.2012.09.03.001
Title:
Erroneous elimination of assignment to global input variable of

SIDE_EFFECT_FREE function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink removes unnecessary assignments to variables or

vector elements with
other "guaranteed" subsequent value changes:
b = 0;
... /* no access to b */
b = a + 5;
...
c = 0;
... /* no access to c */
f(&c); /* c is changed in f() on all control flow paths */
Here, the initial assignments to b and c may be eliminated.
If b is a variable with global visibility (i.e. file scope), then
function calls
located between the two "assignments" have to be
considered:
b = 0;
foo();
b = a + 5;
If the function class of foo() is SIDE_EFFECT_FREE, then
only the input and
output variables of the respective subsystem can be global
interface variables
of foo().
If b is a global input variable of foo() and foo() is an external
and
SIDE_EFFECT_FREE function, and several calls to foo() are
in the same control
flow branch, then it is possible that TargetLink erroneously
eliminates the
input updates to b of all calls but the last.
Such situations can for exmaple occur if a function is called
several times via
function call trigger from a Stateflow chart.
Workaround: If possible, use a variable class with Scope=value_param for
the input variable.
Otherwise, use a function class with unset
SIDE_EFFECT_FREE Optimization
property for the extern function.
683 / 1260
ID:
KPR.2012.09.10.001
Title:
Code generation may abort if a preprocessor encapsulation is

modeled via enabled subsystems

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the following conditions are fullfilled the code generation

may abort with an
access violation:- the code generation unit contains two or
more subsystems
which should be encapsulated via preprocessor macros AND
- one of the preprocessor encapsulations is not modeled via
the Preprocessor If
block with action called subsystems but via an enabled
subsystem AND
- the enabled subsystem which has to be encapsulated via
preprocessor macros is
part of a subsystem which is directly or indirectly inlined by the
code
generator.
Workaround: Use Preprocessor If blocks and action called subsystems
instead of enabled
subsystems for modeling the preprocessor encapsulations.
684 / 1260
ID:
KPR.2012.09.10.004
Title:
Code generation fails with error #08907 for models containing

incremental code generation units

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are met:

- there is an interface variable of an incremental code
generation unit
implemented by a struct or struct component AND
- the type of the that struct is specified by a Data Dictionary
Typedef object
AND
- one or more TypedefComponent objects of this Typedef
object refer to a base
type B AND
- the base type B is renamed by another Typedef object R.
the code generation incorrectly aborts with an error #08907
like the following:
E08907:SYSTEM INTERFACES VALIDATION: *** Data
mismatch found. Property Type of
component object <object> differs from the origin in the pool
area. Do not edit
the subsystems area. If you have edited the variable class in
the pool, run code
generation for the referenced model <incr. subsystem> again.
Workaround: Use the basetype rename as type at the relevant
TypedefComponent objects, e.g.
for an AUTOSAR model use
/Pool/Typedefs/PlatformTypes/sint16 instead of
/Pool/Typedefs/Int16.
patches:
TargetLink 3.3p4
685 / 1260
ID:
KPR.2012.09.10.006
Title:
Model initialization errors in SIL/PIL simulation mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Switching to SIL/PIL simulation mode for

- a TargetLink subsystem with many input signals (> ca. 50)
and
- some signals have non-double data types
might result in a model that cannot be initialized. Simulink
issues error
messages like the following:
Data type mismatch. Input port 1 of <block> expects a signal
of data type
'boolean'. However, it is driven by a signal of data type
'double'.
Data type mismatch. Output port 1 of <block> is a signal of
data type 'double'.
However, it is driving a signal of data type 'boolean'.
The problem may show up rarely and unexpectedly.
Workaround: Remove the TargetLink simulation frame, and re-add it, for
example, with the
context menu of the TargetLink subsystem in the TargetLink
Main Dialog.
ID:
KPR.2012.09.19.001
Title:
Access Function auxiliary variables are utilized without

respect to interprocedural data flow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Starting from TargetLink 3.3, TargetLink analyzes the data

flow relationships
between accesses of variables that are associated with an
applying to the variable and tries to utilize auxiliary variables in
order to
minimize the number of access function (or access macro)
calls.
Example:
B = a * 5;
f(B);
...
c = B - 3;
leads to
686 / 1260
SetB(a * 5);
f(GetB());
...
c = GetB() - 3;
Using auxiliary variables, the generated code instead is
Aux_ = a * 5;
SetB(Aux_);
f(Aux);
...
c = Aux_ - 3;
For the respective analysis, TargetLink does not sufficiently
respect
interprocedural relationships between the accesses of the
variable.
Example:
B = a * 5;
f(B);
g(); /* Call masks a value change of B */
c = B - 3;
TargetLink still transforms this to
Aux_ = a * 5;
SetB(Aux_);
f(Aux);
g(); /* Call masks a value change of B */
c = Aux_ - 3;
giving rise to an erroneous calculation of "c".
Note regarding "variables that are associated with an
applying to the variable":
Usually, a variable is associated with an
AccessFunctionTemplate via its
variable class.
Struct components can "inherit" the AccessFunctionTemplate
of a parent struct
(for TargetLink < 3.4, this always happens in
CodeGenerationMode Standard or
RTOS, for TargetLink >= 3.4, this can be influenced via the
PropagateStructToComponents property of the
AccessFunctionTemplate's Settings)
or can be subject to an access function call if one of its parent
structs has a
variable access function.
An AccessFunctionTemplate only applies to a variable, if it
contains at least
one AccessFunctionObject that specifies an access function
that can apply to
accesses to this variable (AccessFunction
Kind=READ_INDEXED does not apply to
687 / 1260
scalar, numerical variables; for TargetLink >= 3.4, the kind of

variables to be
affected can be further specified via the VariableKindSpec
property of the
AccessFunction object).
Workaround: Make the data flow explicit, e.g.
B = a * 5;
f(B);
g(&B);
c = B - 3;
or
B = a * 5;
f(B);
B = g(B);
c = B - 3;
ID:
KPR.2012.09.19.002
Title:
Errors on MATLAB command line while trying to enhance a

TargetLink BusPort blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: An attempt to enhance a TargetLink BusPort block once more

results in the
following Matlab errors:
??? Reference to non-existent field Istructvar' or 'signals' in
tl_supplement_data_struct
This error occurs if
- "enhance block" from TargetLink context menu is executed
on (already enhanced)
TargetLink BusPort blocks OR
- "prepare system" for a subsystem containing (already
enhanced) TargetLink
BusPort blocks is used OR
- AUTOSAR frame model generation
(tl_generate_swc_model) is run for a model that
already contains TargetLink BusPort blocks.
NOTE: After trying to enhance a TargetLink BusPort block
once more the block is
corrupted afterwards, i.e the block dialog cannot be opened
anymore.
Workaround: No workaround available. If possible try to avoid above
situations.
688 / 1260
ID:
KPR.2012.09.28.001
Title:
Simulink scope blocks in referenced models do not contain

simulation data after simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Simulink scope blocks within referenced models do not

contain simulation data if
the MIL simulation is started from a TargetLink dialog or via
the tl_sim()
command.
Workaround: Use one of the following workarounds:
1) Use the TargetLink block's logging mechanism or
TargetLink Sink block instead
of the Simulink scope block.
2) If you do not need TargetLink logging in referenced models,
start the MIL
simulation via Simulink "Start simulation" button or sim()
command.
ID:
KPR.2012.09.28.002
Title:
Erroneous moving of expressions containing a function or

macro call having an argument with index expression

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink eliminates intermediate variables if data flow and

variable
properties allow for it:
For example,
b = f(a);
...
c = b + 5;
can be optimized to
...
c = f(a) + 5;
if there is no intervening redefinition of "a" and if the call to "f()"
does not
access global variables that are accessed in the "..." part (side
effect free).
However, if an argument of "f()" is of the form
a[expression]
or
&a[expression]
then TargetLink does not analyze "expression" for data flow
preventing moving
"f(a[expression])".
This does NOT affect arguments of the form "(T)
a[expression]" or "a[expression]
689 / 1260
<operation> ...".
In addition to function calls, this problem also occurs for macro
"calls", e.g.
of TargetLink DsFxp macros.
A special case is related to moving expressions between
loops. Ordinarily,
TargetLink does not move code depending on a loop variable
between separate
loops.
In this case, TargetLink moves the code but does not adapt
the loop variable,
i.e.
for (Aux_ = 0; Aux_ < 12; Aux_++)
{
b[Aux_] = f(a[Aux_]);
}
...
{
[Aux_S32] = (b[Aux_S32] > g(c[Aux_S32])) && (P[Aux_S32] >
0.);
}
becomes
...
{
[Aux_S32] = (f(a[Aux_]) > g(c[Aux_S32])) && (P[Aux_S32] >
0.);
}
"Aux_" either is out of the valid index range (in this case 12) or
undefined,
depending on whether its original loop is subsequently
removed because it has
become empty.
Note that the optimization order strategy of TargetLink usually
precludes this
kind of situation.
690 / 1260
Workaround: Identify the functions and macros with return values taking a
vector or matrix
element argument (for a scalar parameter) affected by this
problem.
Then you can either insert a TargetLink Rescaler block with
non-ERASABLE
variable class after the function / macro return output of the
block leading to
the function call (this can be a subsystem or a block calling a
math, lookup
table or TargetLink Fixed-Point library function)
OR switch from function return value to a ref_param output if
possible.
For the loop case, it may be possible to use an atomic
subsystem for grouping
all vector code together which leads to merged loops and thus
permitted
intra-loop optimization.
691 / 1260
ID:
KPR.2012.09.28.003
Title:
Missing indirection operator (*) of an indirect reuse pointer

variable in custom code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A variable is indirectly reused if its variable class has the

following property
values
- FunctionReuse = instanceSpecific
- FunctionReuseAccessByPointer = on
In this case, the reuse structure member is implemented as a
pointer to an
underlying variable rather than a variable carrying the desired
value.
If the predecessor block of a TargetLink Custom Code block
has as output an
indirectly reused variable, then the pointer to this variable may
be used
directly in the Custom Code section rather than being subject
to the C
indirection operator (*<pointer>).
Workaround: 1) You can force creation of a separate Custom Code input
variable by setting a
non-default variable class for the respective input, e.g.
OPT_LOCAL from the
preconfigured Data Dictionary project files of the TargetLink
installation. Then
even if TargetLink eliminates the respective variable during
optimization, the
resulting code will still be correct.
OR
2) Alternatively, you can insert a Rescaler block with "Inherit
properties"="on"
on the line to the Custom Code input.
692 / 1260
ID:
KPR.2012.10.24.001
Title:
Error #02928 during code generation for path of AUTOSAR objects that contain
names of embedded Data Dictionary objects

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Path of TargetLink AUTOSAR objects referenced from Runnable subsystems

cannot
contain own names of following embedded TargetLink Data Dictionary objects:
'Ports', 'Interfaces', DataElements', 'Operations', 'ModeElements',
'Components'.
This could be e.g. for group objects and in then such a case the selected path
from the Data Dictionary maybe cut at a wrong position and not fully saved in
the block data. Thus objects cannot be correctly identified afterwards from the
block data and code generation stops with an error message like:
Error #02928: ar_poscontrol/ ... /Controller_Runnable/(ref):
Data element of
'ar_poscontrol/TL_Controller/Subsystem/TL_Controller/Controller_Runnable/(ref)'
is not specified!
Workaround: Rename such objects via context menu " rename and adapt ..." in the TargetLink
Data Dictionary to another name, e.g. 'myInterfaces'.
TargetLink 3.4p1
693 / 1260
ID:
KPR.2012.10.31.001
Title:
Simulation build process for AUTOSAR aborts with internal

error E90112

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If the production code has been generated in AUTOSAR

mode, but it does not
contain any AUTOSAR elements such as Runnables, building
the production code
simulation application fails with in an internal error message:
*** Internal error. Contact dSPACE technical support.
*** Neither tl_types.h nor Rte_type.h exists.
Workaround: In the Data Dictionary Subsystem object representing the
code generation unit
that the production code has been generated for create an
empty Data Dictionary
Autosar object.
This can e.g. be done automatically in the
post_codegen_hook function by adding
there the following lines:
if isempty(ddCodeGenUnit)
systemName = get_param(tlSystem,'Name');
dsdd('CreateAutosar',['/Subsystems/' systemName]);
end
patches:
TargetLink 3.4p1
694 / 1260
ID:
KPR.2012.10.31.002
Title:
Using slashes in file's path is not feasible in Addfile block API

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: Setting the CodeFile property of the TargetLink Addfile block

fails with an
unclear message, if the file's path contains slashes (instead of
backslahes).
For example tl_set(gcb,'CodeFile','C:/temp/a.h') fails with:
"TargetLink API error: New value 'C:/temp/a.h' for property
'codefile' specifies
a path!"
Note: the block GUI dialog accepts slashes.
Workaround: Use the block's GUI dialog to add the file with path.
patches:
TargetLink 3.3p5
TargetLink 3.4p1
ID:
KPR.2012.11.12.001
Title:
AUTOSAR 2.x/3.x import of ARRAY-TYPE sets wrong width

at data prototypes

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If all of the following conditions apply, the AUTOSAR 2.x/3.x

import sets a
wrong width at a
DataElement/CalprmElement/OperationArgument/AUTOSAR
Variable
object in the Data Dictionary:
- The set of .arxml files to be imported contains an ARRAYTYPE that is defined
multiple times AND
- the ARRAY-TYPE is referenced by a data element, calprm
element, operation
argument, interrunnable variable, or per instance memory.
Workaround: If each of the .arxml files to be imported does not contain
more than one
definition of the ARRAY-TYPE, import the .arxml files one by
one.
Alternatively, remove the double definitions of the ARRAYTYPE from the .arxml
files.
695 / 1260
ID:
KPR.2012.11.12.002
Title:
Opening a TargetLink model on MATLAB R2011b the number

of BitShifts ofArithmetic Shift block is lost

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The Number of BitShifts of first Arithmetic Shift block is lost, if

- the model was created in MATLAB R2010b or earlier AND
- the model contains one or more Arithmetic Shift blocks AND
- the TargetLink subsystem was renamed to a name, that
starts with a letter from
A to L.
Workaround: Correct shift factor afterwards.
696 / 1260
ID:
KPR.2012.11.12.003
Title:
Clearing a system from TargetLink or removing its simulation

frame corrupts Stateflow Chart in model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling

- a TargetLink subsystem resides on the 3rd level of a model
AND
- the TargetLink Subsystem contains a Stateflow Chart block
AND
- the TargetLink Subsystem or the parent model is cleared
from TargetLink, or
its Simulation Frame is removed
In this case, the Chart in the Subsystem is corrupted.
Initializing the model
results in error messages similar to:
Bad object handle (351) at index 1.
Error in parameter number 2.
--> Error using sf
Object parameter contains an invalid handle.
Saving the model conserves its corrupted state.
Note: Clearing a system from TargetLink is done with the
Clear System Tool,
removing a simulation frame (which enables MIL/SIL/PIL
simulation modes) can be
achieved with the TargetLink Main Dialog.
Workaround: Place TargetLink subsystems with Stateflow Charts on the
1st, 2nd, 4th, ...
level, but not on the 3rd.
Or do not clear a system from TargetLink which matches the
use case described
above.
patches:
TargetLink 3.3p5
TargetLink 3.4p1
ID:
KPR.2012.11.12.004
Title:
Import of AUTOSAR 2.x/3.x XML files with namespace prefix

fails with error E08763

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
697 / 1260
Class:
Utility
Description: The import of AUTOSAR 2.x/3.x XML files fails, if the files use
a namespace
prefix, e.g.: <AR:SHORT-NAME> instead of <SHORTNAME>.
The following message is thrown by the import:
Error detected in attempt to import a SHORT-NAME. Missing
or empty mandatory
AR-PACKAGE element detected.
If multiple documents are imported, the problem occurs only if
the first
selected file uses a namespace prefix. For all other selected
files, the import
considers the prefix correctly.
Workaround: The workaround is to create a dummy AUTOSAR XML file
without a namespace prefix
and select the dummy file as the first file to import and
subsequently select
all other files.
Create a dummy AUTOSAR XML file dummy.arxml with the
following content:
<?xml version="1.0" encoding="UTF-8"?>
<AUTOSAR xsi:schemaLocation="http://autosar.org/3.2.2
autosar.xsd"
xmlns="http://autosar.org/3.2.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<TOP-LEVEL-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>dummy</SHORT-NAME>
</AR-PACKAGE>
</TOP-LEVEL-PACKAGES>
</AUTOSAR>
Replace both AUTOSAR version entries in the second line
with the actual AUTOSAR
version:
autosar.xsd"
Example for AUTOSAR 2.1.4:
autosar.xsd"
The file "dummy.armxl" must be the first file selected in the
import dialog.
patches:
TargetLink 3.3p5
TargetLink 3.4p1
698 / 1260
ID:
KPR.2012.11.12.005
Title:
Generation of RTF documentation on MATLAB >= R2012b

fails with "not enough memory" message.

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The conversion of the generated HTML documentation to the

RTF format fails under
MATLAB >= R2012b, if Microsoft Word 2007 is used.
In this case the following information is displayed in the
MATLAB Command
Window:
Converting: <fileName>.html
to: <fileName>.rtf
using: WORD
before other "Not enough memory" and the subsequent "The
command is not
available" messages are issued by Word.
Workaround: 1) If possible use Word 2010 or
2) Edit your script controlling the generation of the RTF
documentation, for
example tldoc_rtf.m, and change the value of "GraphicFormat"
property of the
"Convert" function from 'eps' to 'png'.
ID:
KPR.2012.11.13.001
Title:
Possibly erroneous code generated for extern const variable if

its init value cannot be excatly represented in it's scaling

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
699 / 1260
Description: If a variable (not a macro)

- is specified as extern AND
- that variable is const AND
- that variable is not alias AND
- that variable's variable class property info is set to readonly
or unspecified
AND
- that variable has an initial value which cannot be exactly
represented in the
scaling of that variable,
then, depending on how the user specified the initial value in
his external
code, the generated code may be wrong, but no message is
emitted by the code
generator that warns the user about this possibly problematic
situation.
The generated code could be wrong, because
- necessary saturation code might be omited
- an arithmetic operation is calculated in a smaller width than
necessary (and
thus cause possible overflows)
- control flow might be erroneously omitted.
A simple example:
extern Int16 a; LSB = 1.0; Initial Value = 1.7;
For this variable the code generation will incorrectly assume
an initial value
of 1.0 (digits were cut off) and derive a worst case range of
[1.0 1.0] for that
variable.
If this variable is used, for example, at a constant block that
preceeds a
saturation block with the limits [1.0 1.0], the saturation code
will be omitted.
This is correct assuming the initial value is implemented by
the user as 1.0.
If, however, the user would implemented the initial value as
2.0, i.e. if the
user would round the initial value instead of cutting off the
decimal digits,
the code would be wrong.
The example describes the behavior for TargetLink versions <
3.4.
TargetLink 3.4 will calculated the range by rounding and find a
worst case range
for the variable
of [2.0 2.0] which is fine in this case. But in other cases this
might be wrong
or at least inefficient.
Note that this describes only the internal range calculation. In
the generated
code initial values will be rounded by the TargetLink code
generator, so itself
would initialize above variable with a value of 2 if it was not
specified as
being extern. This applies to all TargetLink versions.
700 / 1260
Workaround: Specify an initial value which can be represented in the

associated scaling or
adjust the scaling; with the precision as needed in your actual
case.
ID:
KPR.2012.11.16.001
Title:
AUTOSAR 2.x/3.x import incorrectly merges port objects with

the same name without considering the object type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During the import of AUTOSAR 2.x/3.x files the import checks
whether the port
object to be imported already exists in the Data Dictionary, but
the merge
routine erroneously does not consider the port type, thus port
objects maybe
incorrectly merged upon import.
Example.
A ModeReceiverPort with the identifier "MyPort" exists in the
Data Dictionary
referencing a ModeSwitchInterface.
An AUTOSAR XML file is imported, which contains a
DataReceiverPort with the same
short name "MyPort". The import will erroneously identify both
objects as equal,
because both objects are port objects and have the same
identifier. The import
does not consider that the port types of the objects are
different.
The import throws a warning informing the user about the
merge of objects of a
different type:
W08890: Warning during AUTOSAR import:
The following Data Dictionary port objects are overwritten by a
port with a
different type: ...
Workaround: There are two alternative workarounds available:
1) Rename the particular port object before the import, so that
the merge does
not affect that port object.
2) Set the ImportStrategy to "Overwrite" instead of "Merge".
You can set it in
the Data Dictionary at the property
"Pool/Autosar/Config/ImportExport.ImportStrategy". For
TargetLink <= 3.3, this
option is also available in the Import Dialog.
patches:
TargetLink 3.3p5
TargetLink 3.4p1
701 / 1260
ID:
KPR.2012.11.16.002
Title:
Abnormal termination or erroneous optimization if global

function reuse pointers are utilized and extern function is
called in a reused function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink analyzes the relationship between the function

reuse pointers and the
instance struct variables they point to as well as the
relationship of
pointer-to-struct struct components of instance struct variables
and the struct
variables they point to. This is essential for optimizing the
code generated for
reused functions.
If
- you configured function reuse pointers to be global variables
rather than
function arguments (via a variable class template with filter
VariableClassSpec="SLFcnOutput") AND
- have reused functions call another extern function AND
- there is at least one struct pointer in a reuse instance struct
variable type
(due to calling a reused function from a reused function or due
to different
variable class properties like const or DeclarationStatements)
then it is possible, that TargetLink does not resolve the
relationships between
struct variables and struct pointers correctly or that TargetLink
terminates
with fatal error #99999 and an access violation like
Fault address: 40C2E9E1 01:0000D9E1
D:\TL_32Bit\TL_Curr\Matlab\Tl\Bin\XcgExprDes.dll
The incorrectly mapped relationships can lead to erroneous
optimization, e.g.
the assigning of an initial value in restart functions or restart
runnables may
be removed even though the variable is a state and still in
use.
Workaround: The only viable workaround is to do without global function
reuse pointers.
702 / 1260
ID:
KPR.2012.11.19.001
Title:
Error #17300 for a struct component with variable class

default or scope struct_component for a look-up table axis or
table variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For Look-Up Table and Look-Up Table 2D Blocks it is possible

to specify a struct
component from the Data Dictionary for the block variables
axis, axis#2 or
table.
Then the code generation will abort with an error #17300 in
the case of
- not using a Custom Look-Up script AND
- generating a map struct with pointers to these struct
compontens AND
- the struct components having set their variable class to
"default" or use a
variable class with the scope "struct_component".
For structures that are not global the error is correct, but
incorrectly it also
is emitted if the actual struct itself is of global scope.
Workaround: 1) Use a variable class with scope = global for the struct
components
2) or disable the generation of the map struct for the Look-Up
Table block.
703 / 1260
ID:
KPR.2012.11.20.001
Title:
AUTOSAR 4.x import fails with error 7100 when DISPLAYNAME contains SUP or SUB element

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR import aborts with error 7100, if the display of
a unit contains
nested XML elements.
The elements can be e.g. the SUP and SUB subelement, like
<DISPLAYNAME><SUP>1</SUP><SUB>1</SUB><DISPLAY-NAME>
This is a valid AUTOSAR 4.x XML file, but the TargetLink
import mechanism is not
able to handle sub elements in DISPLAY-NAME.
Workaround: If possible remove or uncomment the SUP and SUB
elements, like from
<DISPLAYNAME><SUP>1</SUP><SUB>1</SUB><DISPLAY-NAME>
change to
<DISPLAY-NAME> Interfaces
|
|--> MyInterfaceGroup
|
|--> MyInterface
|
| --> MyInterface
Workaround: For PDF documentation generation no workaround is
available. However, the
generation of documentation in HTML or RTF format works.
patches:
TargetLink 3.4p5
834 / 1260
ID:
KPR.2013.11.18.002
Title:
AUTOSAR frame model generation reports no errors and the

created model is empty

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR frame model generation

tl_generate_swc_model() may not report any
errors, nevertheless the created model is empty, if these
conditions apply:
1) tl_generate_swc_model() was called with the
'SwcDescFileNames' property to
specify AUTOSAR software component description files for
AUTOSAR version 4.0 and
higher AND
2) the AUTOSAR import of these files has failed.
In this case the AUTOSAR frame model generation is aborted
without displaying
the AUTOSAR import errors.
Workaround: 1) Try to import the AUTOSAR software component
description files to the Data
Dictionary before calling the tl_generate_swc_model()
function.
2) Analyse the reported errors. If necessary, modify the
related files and start
the AUTOSAR import again.
3) Call the tl_generate_swc_model function with the
'UseCurrentDD' property set
to on instead with the 'SwcDescFileNames' property.
patches:
TargetLink 3.4p5
835 / 1260
ID:
KPR.2013.11.19.002
Title:
SIL/PIL compilation fails due to RTE simulation frame code

having re-defined Std_VersionInfoType typedefs

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If the Std_VersionInfoType Typedef object is defined in the

Data Dictionary and
its ModuleRef property is set to
"TLPredefinedModules/AUTOSAR/Rte_Type", a SIL
or PIL simulation application cannot be built ("MAKE
PROCESS ABORTED") in the
AUTOSAR code generation mode because of multiply defined
types in the generated
RTE simulation frame files Rte_Types.h and Std_Types.h.
Workaround: Delete the ModuleRef Property of the Std_VersionInfoType
Typedef object.
ID:
KPR.2013.11.19.004
Title:
Limitations when using the %MainDDDir% macro for included

partial DD files

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Partial Data Dictionary DD files can be included into project

DDs by
DDIncludeFile objects. Their FileName property specifies the
partial DD file
which should be included. The %MainDDDir% macro in this
filename is expanded to
the directory where the project file resides. For example, if the
project file
D:\Work\MainControl.dd is used,
%MainDDDir%\Config\Scalings.dd would be expanded
to D:\Work\Config\Scalings.dd .
However, this method does not work if the included files
reside in a directory
which is neither the directory of the project file, nor a
subdirectory of that
directory. For example, one cannot specify
%MainDDDir%\..\Config\Scalings.dd
with the Config directory lying parallel to D:\Work.
Workaround: Use the DDINCLUDE system environment variable to specify
directories where
included partial DD files reside.
836 / 1260
ID:
KPR.2013.11.19.006
Title:
Abnormal termination during SIL/PIL simulation with activated

code coverage

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Performing a SIL/PIL simulation leads to an abnormal

MATLAB termination, if the
- the code coverage is activated AND
- the TargetLink simulation settings/callbacks in the model
have been corrupted,
e.g. the Simulink model init callback was removed or changed
and does not call
function tlds_init. This may happen if other software or userscripts modify
such model settings.
Workaround: One of the following actions modifies/restores automatically all
necessary
Simulink model callbacks to be TargetLink-compliant again:
1) Copy the TargetLink Main Dialog block to the model (it
does not matter if the
model already contains a TargetLink Main Dialog - the copyaction adds the
necessary TargetLink function calls to the callbacks).
Or 2) Perform a system preparation, e.g. via
tl_prepare_model().
Or 3) Perform tl_upgrade().
837 / 1260
ID:
KPR.2013.11.19.007
Title:
Autodoc Customization block cannot be modified in a library

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a TargetLink Autodoc Customization block is used inside a

library the block's
dialog cannot be used to modify the block data, even if the
library is unlocked.
After reinitialization of the model and the Autodoc
Customization block mask
setting are overwritten by the original block in the TargetLink
library.
Workaround: Break the link of the Autodoc Customization block in the
library to the
TargetLink library tllib, then modify the block in the library
instance in the
model and resolve the library link to push changes into the
library instance
again.
patches:
TargetLink 3.4p5
838 / 1260
ID:
KPR.2013.11.22.001
Title:
AUTOSAR frame model generation fails if a software

component contains ports and runnables with identical names

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In case a software component that an AUTOSAR frame model

is to be generated,
e.g. by API tl_generate_swc_model(), for a software
component that contains a
runnable and a port of identical name, the frame model
generation abnormally
aborts with a command line error similar to the following one:
??? Error using ==> tl_generate_swc_model>FcnAddPorts at
1167
Invalid Simulink object name: InfoData/1.
Error in ==> tl_generate_swc_model>FcnAddSwcSubsystems
at 877
[swcOutportsConnectionList,...
Error in ==>
tl_generate_swc_model>FcnCreateOneTLSubsystemForAll at
5791
[~, swcSubsystemInfoList] =
FcnAddSwcSubsystems(hTlSubsystem, options);
[hTlSubsystem, swcSubsystemInfoList] =
FcnCreateOneTLSubsystemForAll(options);
Workaround: Specify unique names for the software component's ports and
runnables.
839 / 1260
ID:
KPR.2013.11.25.001
Title:
Generation of PDF documentation may fail for production

code containing reused functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If for a TargetLink subsystem and generated production code

the following
conditions apply:
1) For the TargetLink subsystem more than one root step
functions have been
generated (e.g. this is a case if the TargetLink subsystem
contains
function-call subsystems called from the outside of the
subsystem) AND
2) within the function's hierarchy of at least two root step
functions an
identical reused function is called AND
3) the reused function calls further subfunctions
then the generation of the documentation in PDF format may
abnormally abort with
errors similar to the following one:
*** E09999: ERROR USING DS_DOS:
*** Error when trying to invoke the command
*** "<MATLAB_ROOT>\sys\java\jre\win64\jre\bin\java.exe" Xmx512m -cp <command>
***
*** [ERROR] file:<filePath>:1357:264 The id <anchor> already
exists in this
document
840 / 1260
ID:
KPR.2013.11.25.002
Title:
Building SIL/PIL fails due to undeclared identifier of erased

AUTOSAR interrunnable communication

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a TargetLink subsystem contains another nested subsystem

that is modelled as
an AUTOSAR Runnable AND
- one of this inner subsystem's inports is specified with implicit
interrunnable
communication AND
- this inport is modelled in a way so that TargetLink does not
generate (erase)
the call of the RTE API function Rte_IrvIRead into the
production code, e.g. by
driving a Term block while generation of optimized code is
activated,
then the build process for SIL or PIL simulation may fail with a
compiler error
for an undeclared identifier "Rte_Irv_...".
Workaround: 1) Place a rescaler block with a non-ERASABLE variable
class right after the
inport block.
Or 2) remove the inport from the model if it is superflous.
841 / 1260
ID:
KPR.2013.11.25.003
Title:
Generation of "model-linked code view" fails for scaled macros with

negative values

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the generated production code contains a definition of a macro

which is
scaled (LSB != 1 and/or Offset != 0) and whose initial value is
negative the
generation of "model-linked code view" fails with a warning message
like this:
Warning #04301:
The HTML code view file for the production code file
'[...]\TLProj\Subsystem\Subsystem.h'
could not be generated completely.
As a result the HTML view of the referenced code file is only filled
down to the
definition of the macro, for example:
...
/******************************************************************************\
MACRO: global preprocessor macros
\******************************************************************************/
#define MY_GAIN ((Int16) -5 /* -10. */)
[end of file]
Workaround: The workaround is to turn off the generation of the "scalar-constcomment"
comment (here: /* -10. */). This is done in
%TL_ROOT%\Matlab\Tl\config\codegen\cconfig.xml:
...
<TL:scalar-const-comment show="false"/>
...
Note:
It is not necessary to make this change in your TargetLink installation
directory. You can also create a local copy of
%TL_ROOT%\Matlab\Tl\config\codegen\cconfig.xml and reference it
in TargetLink
Maindialog->Advanced->"Style definition file" or the according code
generator
option 'ConfigXML' in a pre_codegen_hook function.
842 / 1260
ID:
KPR.2013.11.25.004
Title:
AUTOSAR 4.x files are not imported if additional elements

exist under paragraph elements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR 4.x import expectes that the content of

Paragraph Elements (such as
L-1, L-2 ...) is only plain text. If the content of those elements
consist of
also other elements (for example SUP and SUB) the import
aborts with an error.
The following Error Message is given: E07100: Import Error
Message Cannot read
AUTOSAR file 'SampleFile.arxml' because an internal error
was thrown (XML format
error at Element node 'NodeName' (Line 21, Column
73).EndElement node
expected.). Check the file for a valid AUTOSAR description.
Workaround: Comment-out all elements except the plain text. Elements
such as SUP and SUB are
irrelevant to TargetLink's AUTOSAR Import. The Error
Message shows exactly at
which line and column in the .arxml file those elements which
needs to be
commented are to be found.
843 / 1260
ID:
KPR.2013.11.26.001
Title:
Incorrect code due to erroneous determination of AUTOSAR

Restart hierarchy for Access Function creation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In order to provide the correct RTE API calls, TargetLink

needs to know for a
variable access to which Software Component (and
Runnable) this access belongs.
Starting with TargetLink 3.4p4 and 3.5, TargetLink has a
different call
hierarchy for AUTOSAR Restart Runnables.
For incremental subsystems (or referenced models), this
"current Software
Component" determination is wrong inside Operation Call
subsystems. If the
Operation Call subsystem also determines the implementation
of a server runnable
from a different Software Component than the one "calling"
the incremental
subsystem, then this leads to problems for
1) the instance handle parameter of functions and runnables
of Software
Components that support multiple instantiation: The
parameter may be used
wrongly or may be missing inside the server runnable
implementation or
2) name macros $(Component) or $(Runnable) if evaluated
for identifiers of
variables or access functions, then this evaluation returns the
wrong Software
Component or Runnable.
This usually leads to code that does not compile but may also
lead to a code
generation error or even incorrect code that does compile but
behaves wrongly.
844 / 1260
ID:
KPR.2013.11.27.001
Title:
Code generation aborts for nested calls to customer-specific

functions in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If there are

- nested calls in the Stateflow action language to customerspecific functions,
e.g. "out = f( g() );", AND
- the inner user function doesn't specify constraints (min/max)
for its return
value
then the TargetLink code generator may abort abnormally:
Fault address: 7E3C71B8 01:002A61B8
D:\TargetLink\Matlab\Tl\Bin\XcgCV.dll
Workaround: There are two possible workarounds:
1) Linearize the call "out = f( g() )" by introducing a temporary
variable,
for example:
temp = g();
out = f( temp );
In oder to help TargetLink to eliminate the temporary variable
the inner user
function "g" has to have a function class with
SIDE_EFFECT_FREE=ON and the
temporary variable has to be fully optimizable (default or
erasable,movable,...).
Or 2) Select a typedef with user-constraint min/max values for
the return value
of the inner customer-specific function. Note: These min/max
could even be the
full range resulting from data type and scaling parameters.
845 / 1260
ID:
KPR.2013.12.02.001
Title:
Warning #17412 erroneously emitted for initial value equal to

min or max value of a variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Warning #17412 may be emitted erroneously during code

generation, if the
(initial) value of a generated variable is the same as the userspecified
constraint max or min value for that variable.
This problem is usually caused by an (arbitrary) LSB or by an
(initial) value,
that cannot exactly be represented as a double precision
floating-point value.
Example for a variable having:
Data Type: Int16
arb. LSB: 0.00078125
Offset: 0.0
Value: 25.59921875
Max: 25.59921875
This is a valid specification, but due to floating point effects
TargetLink
might issue a warning #17412 like the following:
Warning #17412: <block> Variable <variable> has an initial
value 25.59921875 and
a calibratable range [-25.6 25.59921875]. Due to scaling and
rounding effects,
the scaled initial value 25.59921875 is outside the constrained
range.
In this case the LSB cannot be exactly represented by double.
Its double
representation is e.g. 0.00078125000000000004 instead of
0.00078125.
Note: The generated code is not affected by this problem.
846 / 1260
ID:
KPR.2013.12.06.001
Title:
Code generation aborts for matrix variable in structure with

access function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a structure (like e.g. an AUTOSAR CALPRM structure),

whose variable class
demands an access function, contains a component with
matrix dimensions (like
e.g. a look-up 2D table variable), then the code generation
might abort with a
fatal error:
TlCSpecialQSOInserter
patches:
TargetLink 3.4p5
847 / 1260
ID:
KPR.2013.12.12.002
Title:
Superfluous warning "The file <DDName>.dd to save the point

of inclusion to is read-only"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The Data Dictionary Manager respective the DD MATLAB API

(dsdd) with command
'CheckPointsOfInclusion' reports an warning in case the target
partial DD File
is read only. This warning is reported even if there are no
changes in POI
(Point of Inclusion).
Workaround: In case you receive this warning you can do the following
check:
After receiving this warning in DD Manager you could do the
following steps:
Click in DD Manager in Messager Browser to the DD object
(origin column in
message browser)
Copy the POI path shown in property DDPath
In Matlab enter: dsdd('GetAttribute',<DDPath>,'modified') and
see result:
0: This warning is superfluous
1: This warning is correct (means something is changed in this
POI)
In case the warning is superfluous it can be ignored.
ID:
KPR.2014.01.08.001
Title:
RTE modes and elements of the component data structure

are not correctly sorted in the RTE simulation frame code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
848 / 1260
Description: The AUTOSAR standard requires the elements of the

component data structure in
the RTE code to be sorted alphabetically according to the
ASCII / ISO 8859-1
code in ascending order within each section. This means, that
upper-case letters
appear before lower-case letters. This also applies to the
assignment of values
in the RTE_MODE macros. The RTE simulation frame
generation in TargetLink,
however, employs a case-insensitive sorting scheme and not
the ASCII / ISO
8859-1 scheme.
Example:
Incorrect definition in the RTE simulation frame code:
/* definition of component data structure */
typedef struct {
Rte_DE_Int32Type * Run_aSenderPort_2_data_2;
Rte_DE_Int32Type * Run_bReceiverPort_2_data_2;
Rte_DE_Int32Type * Run_YSenderPort_data;
Rte_DE_Int32Type * Run_ZReceiverPort_data;
} Rte_CDS_SWC;
The correct definition according to AUTOSAR would be:
/* definition of component data structure */
typedef struct {
Rte_DE_Int32Type * Run_YSenderPort_data;
Rte_DE_Int32Type * Run_ZReceiverPort_data;
Rte_DE_Int32Type * Run_aSenderPort_2_data_2;
Rte_DE_Int32Type * Run_bReceiverPort_2_data_2;
} Rte_CDS_SWC;
Note: This is only problematic if the header files of the RTE
simulation frame
code are included in building the object code files for an
AUTOSAR software
component in TargetLink. Then problems can occur if the
object code is linked
with RTE code generated by another RTE code generator. But
MIL/SIL/PIL
simulations in TargetLink and also the generated production
code files <SWC>.c/h
for an AUTOSAR software component itself are not directly
affected by this
problem.
Workaround: No workaround available. I.e. if the object code for a
AUTOSAR software
component generated by TargetLink is affected by this
problem, it should not be
linked with RTE code produced by another RTE code
generator.
patches:
TargetLink 3.4p5
849 / 1260
ID:
KPR.2014.01.20.001
Title:
API tl_get() returns wrong data or leads to error message for

certain "Inherit properties" blocks referencing Data Dictionary
Variable objects

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: If for a TargetLink block with "Inherit properties"="on" a Data

Dictionary
Variable object is selected, then "Inherit properties" should
automatically be
set to "off", as the properties of the Variable object become
the valid
specification. But, due to an implementation error, this is not
the case for the
following block types:
* Unit Delay
* Unit Delay Reset Enabled
* Rescaler
* SF Input
The effects of this wrong behavior are the following:
1) for TargetLink 3.2, 3.3, 3.4: tl_get(..., 'output.inheritscaling')
gives 1.
Correct would be 0.
2) for TargetLink <= 3.3: tl_get() for block variable properties
(i.e
'output.min', 'output.max', 'output.type', 'output.lsb' and
'output.offset')
returns empty [] and may lead to error messages like:
??? Error using ==> tl_get>FcnGetPropertyValue at 279
TargetLink API error: Property 'output.lsb' not available with
inheritscaling =
'on'!
Error in ==> tl_get at 117
[propertyValue{m}, errorflag(m), msg{m}] = func(objTypes{m},
h(m), d{m},
propertyName, bThrowError);
Correct would be to return the corresponding property value of
the Data
Dictionary Variable object.
Workaround: Before selecting a Data Dictionary Variable object (for one of
above listed
affected block types) set "Inherit properties" to "off" in the
block dialog GUI,
or via API tl_set(<block>, 'output.inheritscaling', 0).
850 / 1260
ID:
KPR.2014.01.23.001
Title:
Wrong flags for bus struct components in the TRC file created
for standalone S-Functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The code variables generated for the leaf components of the
bus signal, with the
exception of the first leaf, are described as "parameters",
instead of as
"outputs", in the user TRC file created by TargetLink's
Standalone Model Manager
and API commands for generating standalone S-functions.
Example from TRC file:
Sa1_FirstBusElement
{
type: flt(32,IEEE)
alias: "Sa1_FirstBusElement"
desc: "This is variable generated for the first bus's leaf signal.
The flags are
correct set."
flags: OUTPUT|READONLY
}
Sa1_SecondBusElement
{
type: flt(32,IEEE)
alias: "Sa1_SecondBusElement"
desc: "This is variable generated for the second bus's leaf
signal. The flags
are not correct set."
flags: PARAM
}
patches:
TargetLink 3.4p5
851 / 1260
ID:
KPR.2014.01.28.001
Title:
Aborted code generation when using "alias" variables in

combination with Pre/PostBlockStatements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When using variables with VariableClass property "Alias=on"

in combination with
Pre/PostBlockStatements specified in their VariableClass, the
code generation
may abort abnormally with an ACCESS_VIOLATION.
Workaround: If possible, instead of using the "Alias=on" property, set the
scope of the
VariableClass to "extern" and if needed add and reference the
according Module
object in the Data Dictionary that will not be emitted by the
Code Generator
(EmitFile = off).
ID:
KPR.2014.02.18.001
Title:
AUTOSAR Frame Model Generation creates a new model

instead of upgrading an existing one

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: AUTOSAR Frame Model Generation may create a new model

instead of upgrading an
existing one.
The problem happens if the following conditions apply:
1) The model to be updated is not open AND
2) The extension of the model file differs from the default
model file format
specified for the current MATLAB/Simulink version. For
example the model file
extension is .mdl, the default model file format is .slx.
Workaround: 1) Open the existing model before trying to update it by means
of the Frame
Model Generator
or
2) Modify the default model file format to match. This can be
done, for example,
with the Matlab command set_param:
set_param(0, 'ModelFileFormat', 'slx') resp.
set_param(0, 'ModelFileFormat', 'mdl')
852 / 1260
ID:
KPR.2014.02.18.003
Title:
The File Export Manager returns error message 3517 if more

than one board package directory matches the target/compiler
combination specified via API parameters

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The TargetLink File Export Manager allows to specify the

target and compiler via
API function tl_export_files(). For some target/compiler
combinations, the error
message 3517 appears:
MORE THAN ONE EVALUATION BOARD FOR SPECIFIED
TARGET/COMPILER
*** There is more than one matching evaluation board
configuration for
specified target '<target>' and compiler '<compiler>'.
This problem appears if all of the following conditions are
fulfilled:
- The file export is started with deactivated 'Verbose' option
which also
suppress the GUI for manual selection of a BoardPackage
directory AND
- the specified target / compiler combination corresponds to
more than one
BoardPackage directories (located in
<TL_ROOT>\Matlab\TL\ApplicationBuilder\BoardPackages).
This situation appears
for Board Package directories containing TargetInfo.xml files
with identical tag
values <Compiler> and <MyC>.
Examples for affected Board Package directories:
- TBTC1766 and TBTC1766_20MHz
- HCS12EVB and HCS12DP512EVB
- MPC5604BEVB, MPC5561EVB and MPC5561EVB_USB
- CMD565 and CME555
Workaround: One of the following workarounds are possible:
1) Activate the 'Verbose' option.
Disadvantage: In this case, a manual selection of the desired
Board Package
directory is necessary which avoids a full-automated
execution
2) Temporary remove or invalidate the undesired Board
Package directory. This
can be done via renaming the TargetInfo.xml file.
Disadvantage: A manipulation of TargetLink installation files is
necessary.
853 / 1260
ID:
KPR.2014.02.19.001
Title:
UNIT-REF not imported by COMPU-METHODs with Category

TEXTTABLE for AUTOSAR > 4.0.2

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The warning message W07007 is thrown during the

AUTOSAR import of a COMPU-METHOD
with CATEGORY=TEXTTABLE and a UNIT-REF. Such UNITREFs are not set in Data
Dictionary.
This behavior is correct for AUTOSAR 4.0.2 but it is erroneous
for AUTOSAR >
4.0.2 which allows a UNIT-REF for TEXTTABLE COMPUMETHODs.
A message like the following will be emitted by the Data
Dictionary:
W07007: Import Warning Message
/Pool/Scalings/CompuMethods/<ScalingName> Object
"<ScalingName>":
The reference to a Unit object is invalid for the scaling object
'<ScalingName>'
of conversion type TEXTTABLE/TAB-VERB. The reference
property UnitRef was not
set.
854 / 1260
ID:
KPR.2014.02.19.003
Title:
A2L File Generator does not take the min/max value specified
in the TargetConfig.xml file into account

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In case that the calibratable or measurable variable the min

and max limits are
not set, the A2L File Generator
calculates them for the integer variables from the datatype's
min and max values
and from the variable's scaling according to the rules:
VariableMinValue = DataTypeMin * LSB + Offset
VariableMaxValue = DataTypeMax * LSB + Offset
For the floating point variables however the A2L File
Generator uses the hard
coded values:
for Float32: -3.402823466e+38F and 3.402823466e+38F
for Float64: -1.7976931348623158e+308 and
1.7976931348623158e+308
Since the min/max values are hard coded their modification in
the
TargetConfig.xml file has not effect on the generated A2L File.
Workaround: Contact dSPACE support for possible workaround.
855 / 1260
ID:
KPR.2014.03.05.001
Title:
Incorrect production code generated for state variables in

combination with loops

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In some situation the code generator may incorrectly move a

state variable
definition, which is located after a loop, to the inside of the
loop.
This transformation then leads to differences between MIL
and SIL.
Imagine the following not optimized code:
do {
aux = X + 1;
}
while (...);
X = aux;
The code generator may optimize this code wrongly to the
following incorrect
code:
do {
X = X + 1;
}
while (...);
For example this problem may occur if your model contains a
Unit Delay block
which drives an iterated subsystem and the iterated
subsystem itself drives the
Unit Delay block.
But also with Stateflow and other situations it is possible to
generate code
which is wrongly optimized as shown above.
Workaround: Disable the code generator option
"UtilizeValueEqualitySignalSplit".
ID:
KPR.2014.03.17.001
Title:
Incorrect production code after input variable of MinMax block

calculation is reused

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
856 / 1260
Description: In rare cases the code generation may obtain an erroneous

range for the second
use of a variable MinMaxIn if
- the according block output that specifies the variable
MinMaxIn is used as
input of a MinMax block AND
- also as input of another block (i.e. the signal is branched in
the model) AND
- variable MinMaxIn is replaced by another variable in the
generated code (e.g.
by optimization during the code generation).
This then can lead further to several effects for the generated
code:
- incorrect elimination of control flow in the generated code
- incorrect elimination of saturation code in the generated
code
- overflows in the generated code
A possibly effected example situation (inside a bigger model)
with a Rescaler
block in the code:
In = PrevIn;
which is followed by a Min block's code:
if(In < 0) OutMin = In; else OutMin = 0;
and code of another parallel Max block:
if(In > 0) OutMax = In; else OutMax = 0;
In this example case, In will always be < 0 in the then case of
the Min block's
code.
Later PrevIn replaces In and in the process of merging the
Worst Case Ranges of
these two variables, the Always-Smaller-Zero range might be
chosen and
erroneously applied to the condition of the Max block. Then as
one possible
effect some of the Max block's code parts may be incorrectly
erased from the
generated production code.
Note: Whether this problem actually happens (even for the
above example) really
depends on further conditions like e.g. the number of
definitions of PrevIn and
the order of optimization tasks in which variables are replaced
during code
generation. This makes it nearly impossible to fully describe
all the
circumstances in which the problem will or may arise.
857 / 1260
Workaround: 1) Disable code optimization.

or 2) Don't share the input of a MinMax block with another
block.
or 3) If this is desired, force the shared input to be global or
static in the
generated code (e.g. by using an appropriate Variable Class).
ID:
KPR.2014.03.18.001
Title:
Transfer Function Scaling Tool does not accept any value

changes

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: When using the Transfer Function Scaling Tool (which is a

GUI dialog only, with
no corresponding API function) changing any value does not
have any effect, but
instead on MATLAB command line the following errors are
printed:
Undefined function or variable 'action'.
Error in tl_tftool_dlg>FcnManageScalingPage (line 623)
if strcmp(action,'loInputEdit')
Error in tl_tftool_dlg (line 139)
[dlgdata, bModified] =
FcnManageScalingPage(pageNum,dlgfig,dlgdata,pageAction);
Error in dstabdlg (line 144)
Error while evaluating uicontrol Callback
858 / 1260
ID:
KPR.2014.03.18.002
Title:
During code generation, the System Checker runs into an

endless loop

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In case of all of the following conditions and certain signal

configurations,
the System Checker - called up before any code is generated
- sometimes may run
into an endless loop:
- A TargetLink subsystem (subsystem for code generation)
contains function-call
ports.
- The function-call signals which feed the ports are generated
by blocks (for
example, Statecharts or Function Call Generators) which
reside outside the
- Inside the TargetLink subsystem, the function-call signals
are passed around
with bus signals, with both Bus Creator and Bus Selector
blocks on the signal
path.
- The bus signals comprise data as well as function-call
signals.
- The data signals are non-scalar.
- Code generation is started for the TargetLink subsystem.
Note: You can break the loop by entering Ctrl-C. However, the
model remains in
compiled state, which can be terminated by typing
>> <modelName>([], [], [], 'term')
in the MATLAB Command Window (<modelName> = name of
the Simulink model).
Workaround: Avoid buses with non-scalar data and function-call signals in
TargetLink
subsystems, if possible e.g. use two separate (bus) signals
instead.
859 / 1260
ID:
PR20030211-01
Title:
Imported Stateflow signal with no read access is eliminated

from code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: An imported Stateflow signal (i.e. a Stateflow data with scope

'imported')
is erased from code if no read access is applied to it. This
optimization can
be undesired if a read access is placed outside in user-written
custom code.
Workaround: Imported signal must be defined with a non-optimizable
variable class.
ID:
PR20030715-06
Title:
Errors after closing a model when

Class/Type/Variable/Scaling selection dialog is open

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If from a block dialog the selection dialogs for Variable, Class,
Type or
Scaling are opened and then the model is closed without
closing the selection
dialog before, an error occurs.
Workaround: Close all Class/Type/Variable/Scaling selection dialogs before
closing the
model.
ID:
PR20030926-13
Title:
Simulink crashes when undeleting blocks using ctrl-z

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Under some circumstances simulink crashes when undeleting

blocks using ctrl-z
and when between the delete and the undelete operation of
the block a new SIL
application is build.
860 / 1260
ID:
PR20031113-20
Title:
Difference between MIL and SIL simulation if variable step

size and inherit sample time selected

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The simulation results differ critically between MIL and SIL if
variable
step size and inherit sample time for the SL inports are
selected.
ID:
PR20040109-08
Title:
MIL mode logging in loops may be wrong and differ from SIL
or PIL mode logging

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a signal inside an iterator system (i.e. inside a loop) is

selected for
logging, the signal history displayed during simulation in MIL
mode may be wrong
and differ from SIL / PIL mode logging.
This is a display problem in the plot window. The data is
logged correctly, but
the plot may show intermediate results of loop steps.
Workaround: - Set plot update interval to simulation end time, thus no plot
updates are
performed during simulation.
-- OR -- Close the plot window. Select the MIL plot in the "Simulation"
tab of the
TargetLink Main Dialog and plot the simulation again by
pressing the "Plot"
button.
861 / 1260
ID:
PR20040220-25
Title:
Using a non-default Variable Class when specifying a variable

address leads to warning message 17285

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The address field of a TargetLink block's output variable reads

e.g.
'&MY_STRUCT.Sum_Output'.
If the Class settings are 'default', everything works as
expected, but the
variable's erasable flag may be erroneously set by the Code
Generator, which can
lead to over-optimzation in the generated code, i.e. the
variable is missing.
If a non-default class (e.g. GLOBAL) is used, a message
W17285 is issued, for
exmaple:
Warning #17285: subs/address_macro/Unit Delay
A macro variable class was expected for the address mapped
variable 'UnitDOut'.
Because the variable class 'NOPT_GLOBAL' does not fulfill
the conditions, the
variable class was exchanged internally.
Selecting a variable class with the macro property set - as
suggested by the
warning message - is not possible, because macros are not
allowed for block
outputs and block states.
Workaround: Directly type name/path of a user defined Variable Class
(Macro = on and Const =
off) into the input field in the block dialog.
-- OR -Use API command tl_set() to set a Variable Class with
properties Macro = on and
Const = off.
Note: still the class may be displayed in red in the dialog, but
the code
generation works (possibly after ignoring Data Dictionary
validation errors in
older TL versions).
862 / 1260
ID:
PR20040227-24
Title:
Codesize information file shows wrong date

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The date string in the code size information file does not show
the date when
the code size was evaluated. It shows the date of the makefile
fragment
<application>.mk in the same directory, which is generated at
'compile
target' time.
*******************************************************************
***** Code size information file for model: emw
***** Generated with TargetLink : 2.0
***** Compiled with : TASK60
***** 2004-02-23 11:02:09
ID:
PR20040312-19
Title:
Initialization code in for loop not optimal

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A missing optimization leads to non-optimal code.

If an iterated subsystem is used in which blocks reside that
perform an
initialization, TargetLink 2.0 does not move the initialization
code out of
the generated loop.
Workaround: Adapt the model by removing the initialization blocks from the
iterated
subsystem.
863 / 1260
ID:
PR20040329-20
Title:
Sometimes TargetLink emits warnings/notes for blocks for

which no code is generated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: TargetLink creates an internal representation of the

associated model and
performs various analysis on those representations.
Sometimes an analysis
emits a warning or a note for a certain block and a succeeding
algorithm
removes this block from the internal representation, because it
has found out
that code generation for this block is superfluous. In this case
TargetLink
emits a warning/note that might be misleading.
ID:
PR20040401-11
Title:
Changing of the InitAlarm template function between code

generation and compilation of the production code simulation
application leads to wrong SIL/PIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a function template is used to modify the name of the init

alarm function
it must not be changed between code generation and
compilation of the
production code simulation application.
The following sequence is not allowed:
1) The name of the init alarms function is modified via function
template.
2) Production code and frame are generated.
3) The name of the init alarms function is modified.
4) The production code simulation application is compiled and
linked.
These steps will produce the situation that the init alaram
function is not
called at all during simulation and the tasks will not be
evaluated.
Workaround: Do not modify the function name in the init alarms function
template between
code generation and building of the simulation application.
864 / 1260
ID:
PR20040402-05
Title:
Crash in autoscaling of discrete state-space block using

inconsistent matrices settings

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Autoscaling of matrices may crash if incorrect matrix values

are used. Those
values are marked red in the block GUI. Such situations can
occur if the
dimensions of the input/output signals and the parameter
matrices are not
consistent, e.g. if there are no inputs but Matrices B and D
exist.
Workaround: Ensure that all block settings are valid before using the 'scale
matrix'
button.
ID:
PR20040406-05
Title:
Mixing float and integer operands in a remainder operation in

Stateflow will lead to code that cannot be compiled

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a remainder operation like IntVar % FloatVar is specified in

Stateflow,
TargetLink 2.0 will generate code that cannot be compiled.
Workaround: Introduce a temporary variable for one of the operands to
calculate the
remainder operation either in integer or float.
E.g.:
Int16 IntTempVar = FloatVar;
out = IntVar % IntTempVar;
865 / 1260
ID:
PR20040407-04
Title:
Look-Up Table: map structure components may loose their

additional qualifiers like CONST or VOLATILE

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Influenced of this problem are all Look-up Table blocks except
the Direct
Look-Up Table (n-D) block for which a special record layout
with direct
addressing - as described in TargetLink Advanced Practices
Guide pp. 196
chapter Custom Table Maps - is specified.
The look-up table mechanism reuses look-up table functions
and structs.
Whether a new struct/function is generated depends on the
data type of the
input, on the look-up table values, and on the implementation
details (search
method, use end values, etc.).
If two blocks have the same settings for these properties, only
a single map
structure type and a single look-up function are created. But
the components
of the two blocks may have different type attributes, e. g. the
first block
may have CAL as variable class and the second may have
only CONST. Since
these attributes are propagated to a single common structure
type the
settings of one block are overwritten. It is not predictable
which block with
its settings will be the source for the components' type
attributes.
Workaround: For all Look-Up Table blocks with a record layout as described
above select
the same axes variable classes for all instances.
866 / 1260
ID:
PR20040407-09
Title:
Direct Look-up-Table: building of a SIL/PIL simulation may fail

due to undefined references in production code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The Direct Look-up-Table checks for possible underflows and

overflows depending
on the property 'Action for out-of-range input'.
In case the action is 'Warning' (default) or 'Error', additional
macros are
generated in code.
If this property is selected, building a SIL/PIL simulation fails if
'Do not log
anything' is chosen from the 'Global logging option' pop-up
menu and and option
'Clean code' is deselected in the TargetLink Main Dialog.
In AUTOSAR mode the property value 'Log according to block
data' and the block
property 'Data to log' to 'None' for all Direct Look-Up Table (nD) blocks leads
to the error, too.
Workaround: If 'Do not log anything' is chosen from the 'Code generation
mode' pop-up menu
in the TargetLink Main Dialog, open the block dialog of the
look-up table block
and choose 'None' from the 'Action for out-of-range input' popup menu, or
select the option 'Clean code' in the TargetLink Main Dialog.
If 'AUTOSAR' is chosen from the 'Code generation mode' popup menu and 'Log
according to block data' from the 'Global logging option' popup menu in the
TargetLink Main Dialog, open the block dialog of the look-up
table block and
choose 'Signal history' or 'Min / Max values' in the 'Data to log'
pop-up menu.
867 / 1260
ID:
PR20040506-06
Title:
Autoscaling: Switch and Multiport Switch block scalings are

inherited wrongly

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The scaling of the Switch block is inherited to all blocks

connected to its
inports. This behavior can be wrong if the connected blocks
need different
scalings.
Workaround: Scale the outputs of the blocks which are connected to the
inputs of the
Switch block manually and set them to 'Scaling reviewed'.
ID:
PR20040611-01
Title:
Inconsistent initial value of Unit Delay Reset Enable output

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a Unit Delay Reset Enable (UDRE) block in a conditionally

executed
subsystem feeds an Outport block which has no initial value
specified (i.e.
the initial condition is set to []), the Outport block always
inherits 0 as
inital value in MIL simulation mode. In SIL simulation mode
the Outport block
inherits the initial value of the UDRE's state variable. This may
lead to
different simulation results.
Workaround: Set an initial condition at the Outport block.
868 / 1260
ID:
PR20040708-02
Title:
Model containing a TargetLink subsystem with multiple

function call inputs cannot be initialized

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: A model containing a TargetLink subsystem with multiple

function call inputs
cannnot be initialized in SIL/PIL mode, although it is
initializable in MIL
mode. This may be the case if the order in which the function
call signals
are evaluated during the initialization is important.
869 / 1260
ID:
PR20040907-01
Title:
Missing code generator error/warning if the output type of

some specific blocks are not one of the currently defined
Boolean types

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: For the output of some specific blocks only one of the
following types can be
specified:
- Bool
- Bitfield
- constrained user type with void scaling (LSB = 1, offset = 0)
and min, max
values equals 0 and 1 respectively.
An attempt to set a other type results in error message:
*** The current datatype
*** [typeName]
*** is not one of the currently defined Boolean types!
If constrained user type has once be selected the user can
modify it in Data
Dictionary, for example he can remove the constraints.
However during the
subsequently code generation no error/warning is issued to
inform the user that
such type is not allowable for the block output, whereas the
block dialog issues
an error.
The problem concerns the following blocks:
- Relational Operator
- SR FlipFlop (both outputs)
- JK FlipFlop (both outputs)
- D FlipFlop output !Q)
- D Latch (output !Q)
Workaround: Use only currently defined Boolean types for the output of the
blocks listed in
the description.
870 / 1260
ID:
PR20041015-02
Title:
Superfluous casts are generated for relational operations with

bit operands

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For relational operations like 'bit1 > bit2', where the boolean
operands are
mapped to bit types, casts are generated:
'((UInt8) bit1) > ((UInt8) bit2)'
In some cases these casts are superfluous, in others they
help to avoid a
compiler bug.
ID:
PR20041110-13
Title:
State variables with local scope are not re-initialized

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: State variables are not re-initialized in init functions if they

have local
scope. This problem affects the following blocks if they reside
in an enabled
or an action port triggered subsystem which has set 'States
when enabling'
resp. 'States when action is resumed' to 'reset':
- Stateflow
- FIR Filter
- Unit Delay
- Custom Code
- Discrete Transfer Function
- Discrete Filter
- Blocks which need a FirstRun symbol in code.
Workaround: Select global scope for block state variables which have to be
reset
or keep their variable classes set to 'default'. If the FirstRun
symbol
is specified via a template in the Data Dictionary, select here
global
scope or keep the variable class set to 'default'.
871 / 1260
ID:
PR20041124-09
Title:
Simulink.Parameter objects used in block parameter

expressions not supported

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a Simulink.Paramater object is part of a vector or a matrix

which is used
as a block parameter, the code generation fails.
Example:
For the gain value of a Gain block a vector is specified:
[Param 5]
The variable 'Param' is specified as a Simulink.Parameter
object with
the value 3. The MIL Simulation works fine, but the code
generation
fails with the error #15252:
Evaluation of parameter expression '[Param 5]' for parameter
gain.value
failed.
The code generation also fails if the Simulink.Paramater
object is part
of an expression which is used as a block parameter.
Example:
For the gain value of a Gain block an expression is specified:
5*Param
The variable 'Param' is specified as a Simulink.Parameter
object with the
value 3. The MIL Simulation works fine, but the code
generation fails with
the error #15252:
Evaluation of parameter expression '5*Param' for parameter
gain.value
failed.
Workaround: Do not use Simulink.Parameter objects in vectors, matrices or
expressions,
which are used as block parameters.
ID:
PR20041125-05
Title:
In triggered TargetLink Subsystem an initial value cannot be

set at an outport

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
872 / 1260
Description: It is possible to define an initial value at an outport of a

triggered
subsystem. If the TargetLink Subsystem itself is triggered then
the field
containing the initial value is deactivated in the dialog of the
Simulink
outport, regardless whether there is a value specified or not.
This is based on the TargetLink simulation concept, which
uses some intermediate
subsystems where the content of the TargetLink subsystem
resides in. If the
entry of an initial value is disabled, the Trigger port of the
corresponding
subsystem is not a real Simulink trigger port but rather only a
dummy trigger
port of TargetLink, which can be identified by the double lines
in the block
icon. This dummy port is not a trigger port from Simulink's
standpoint of view,
therefore Simulink will disable the entries of initial values. The
dummy trigger
port is only a visual control for the user that the system is
triggered during
simulation. Even if the trigger is not a real one, the initial
values of the
outports are taken into account during simulation.
Since TargetLink 2.0.6 the values are used in MIL, SIL and
PIL simulation. In
TargetLink 2.0 as well as TargetLink 2.0.5 the values are used
only in SIL and
PIL simulation, but not in MIL simulation. In MIL simulation an
initial value of
zero is used instead. This difference is based on a missing
synchronization
between the outports of the TargetLink subsystem and the
ports in the
intermediate simulation subsystems.
873 / 1260
Workaround: Since TargetLink 2.0.6 a possible workaround would be to

replace the dummy
trigger port by a real one. Afterwards it is possible to set inital
values.
Please take into account that the trigger port will be replaced
automatically by
a dummy trigger if the simulation mode is changed. Therefore
switch the
simulation mode, e.g. MIL to SIL and back, after setting initial
values to get a
valid model.
-- OR -In TargetLink version 3.0 or newer from the Main Dialogs
context menu of a
TargetLink Subsystem the action "Remove TargetLink
Simulation Frame" can be used
to temporarily remove the Simulation Frame, then set the
initial value at the
Outport blocks and via the same context menu "Add
TargetLink Simulation Frame"
again.
Note: if the initial output value was set before preparing the
system for
TargetLink, this initial value is kept by TargetLink.
ID:
PR20050222-03
Title:
Look-up table maps with different contents are merged without

any notification

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
874 / 1260
Description: If mergeable variable classes and fixed names are specified

for block variables
with struct types, then the TargetLink code generator merges
the struct
variables in any case even if they have different initial values.
TargetLink implements block variables of struct types for the
following blocks:
- Look-Up Table blocks (1-D and 2-D): TargetLink implements
the map struct as a
struct variable (for newer TL versions only with "Generate map
struct" option
being enabled) with the name specified by the map.name
block property.
- Discrete State Space: TargetLink implements the state
space matrices as a
struct variable if "Keep matrix structure" is disabled. The struct
variable's
name is derived from the name specifications of all matrices
A, B, C, and D. For
example, specifying the same fixed name for A, B, C, and D
results in a struct
variable of the same name.
- Discrete Filter: TargetLink implements the coefficients as a
struct variable
if "Keep vector structure" is disabled. The name of the struct
variable is
derived from the name specifications of Numerator and
Denominator. For example,
specifying the same fixed name for Numerator and
Denominator results in a struct
variable of the same name.
- Discrete Transfer Function: TargetLink implements the
coefficients as a
struct variable if "Keep vector structure" is disabled. The name
of the struct
variable is derived from the name specifications of Numerator
and Denominator.
For example, specifying the same fixed name for Numerator
and Denominator
results in a struct variable of the same name.
875 / 1260
Workaround: - Check all 1-D and 2-D Look-Up Table blocks that have their
table map set to a
mergable variable class. Ensure that all blocks that share the
same fixed name
for the table map have the same axis data for all table axes.
- Check all Discrete State Space blocks that have the check
box "Keep matrix
structure" disabled and mergeable variable classes for the
state space matrices.
Ensure that all blocks that share the same fixed name for the
state space matrix
struct have the same values for matrices A, B, C, and D.
- Check all Discrete Filter blocks that have the check box
"Keep vector
structure" disabled and mergeable variable classes for the
coefficients. Ensure
that all blocks that share the same fixed name for the
coefficient struct have
the same values for Numerator and Denominator.
- Check all Discrete Transfer Function blocks that have the
check box "Keep
vector structure" disabled and mergeable variable classes for
the coefficients.
Ensure that all blocks that share the same fixed name for the
coefficient struct
have the same values for Numerator and Denominator.
- Avoid merging look-up table maps with coefficient structs or
state space
matrix structs, as well as coefficient structs with state space
structs.
ID:
PR20050315-07
Title:
Static global scope not possible for inports of externally

function-call-triggered subsystems

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: It is not possible to specify static global scope for inports of

externally
function-call-triggered subsystems even if the inport variable is
only accessed
in one module. An error message about insufficient scope is
thrown.
Workaround: Avoid static global scope for inports of externally function-calltriggered
subsystems.
876 / 1260
ID:
PR20050414-04
Title:
Wrong A2L file output for axis of Lookup Table block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In Data Dictionary wrong entry for Lookup Table block may be
generated under
ModelView if the axis symbols are merged and used once as
x-axis and once as
y-axis: two block variables named AXIS_PTS_X may be
created, but only one is
allowed. The name of the second one should be
AXIS_PTS_Y.
This bug causes wrong A2L file output for this Lookup Table.
Workaround: Do not merge axis symbols.
877 / 1260
ID:
PR20050509-11
Title:
Wrong width property in block dialog of Saturation block or

Relay block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The error message

"Property 'onswitch.width' cannot be synchronized because its
current value is
obtained from the dSPACE Data Dictionary."
is thrown after applying block dialog modifications and the
width of the limits
blockdata is always 1 if the following conditions are fullfilled:
- The output of the Saturation block is vectorized
AND
- The upper limit or lower limit on block dialog "Limit" tab
references to a
Data Dictionary variable
AND
- The width of the referenced Data Dictionary variable is equal
to the block
output width
AND
- The block dialog is opened and a modification (i.e. selecting
another vector
element) is applied
This behavior is wrong: The limit block variable should get the
width specified
in the referenced Data Dictionary variable and no
error message should be thrown.
A similarly behaviour can be observed for the "Switch Points"
tab of the Relay
block.
878 / 1260
ID:
PR20050621-13
Title:
Osek message with more than one sender created

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Under the following condition the code generator implements

an Osek message with
more than one sender (this is not conform to Osek COM2):
- a function-call-triggered subsystem is called by more than
one tasks
AND
- for an outport of the function-call-triggered subsystem an
Osek message is
selected.
ID:
PR20050628-20
Title:
TOM TriCore/Task23: Renaming of sections does not comply

with syntax of Tasking 2.3 compiler

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The syntax how to change section names has changed with
the Tasking 2 compiler.
While the new style has been implemented for TOM
TriCore/Task22, it has not for
TOM TriCore/Task23.
Old:
/* new name for section 'rom' */
#pragma section rom = "near_MyCalSection" farrom =
"far_MyCalSection"
CAL Int16 Sa2_Gain_gain = 20480 /* 2.5 */ /* LSB: 2^-13
OFF: 0 MIN/MAX: -4 ..
3.9998779296875 */;
/* set default section names */
#pragma section
New:
#pragma section near
#pragma section far
CAL Int16 Sa2_Gain_
/* set default sect
#pragma section all
879 / 1260
ID:
PR20050712-07
Title:
Wrong datatype conversion to boolean during MIL/SIL

simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a variable of type double is assigned to a boolean, Simulink

has the
following semantic:
out = (in!=0);
That means that out can only have the values 0 and 1.
The same semantic is implemented in the generated
production code.
Such conversion is not done during MIL/SIL simulation,
instead simple cast to
the Bool datatype is done:
out = (Bool)in ;
The value of out depends on the definition of the Bool
datatype.
This leads to wrong simulation results.
In SIL simulation mode only signals at the TargetLink
subsystem boundary are
affected.
Workaround: Use a data type conversion block to ensure that all signals
assigned to boolean
datatype have a valid range and type.
880 / 1260
ID:
PR20050721-08
Title:
Handling of expressions with Stateflow integer types can differ

from Stateflow semantics

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an operation of variables with a Stateflow integer type is

assigned to a
floating point variable, TargetLink and Simulink/Stateflow
behave differently.
TargetLink computes the operation on the right hand side in
floating point
whereas Simulink/Stateflow performs an integer operation.
Example:
Int16 Var1 = 11;
Int16 Var2 = 3;
double Result; // TargetLink data: Type Int16; Lsb = -4; Offset
= 0;
Result = Var1/Var2;
evaluates to 3.0 in Simulink/Stateflow and 3.66 in TargetLink.
Workaround: Assign the result of the right hand side to an intermediate
integer variable.
ID:
PR20050728-05
Title:
In Direct Look-Up Table block impossible to set "Inputs select

this object from table" = Column, "Number of table
dimensions" = 1 and "Make table an input"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: For the Simulink block it is possible to set "Inputs select this
object from
table" = Column, "Number of table dimensions" = 1 and
selected "Make table an
input", but for the TargetLink block this is not possible. The
specification
contains this settings, but it is not possible to select them in
the GUI.
Note: With this settings the Direct Look-up Table Blocks
behaviour is like a
vectorial signal line.
Workaround: Delete this Direct Look-Up Table block, in such cases this
block is not
necessary.
881 / 1260
ID:
PR20050728-20
Title:
UNICODE strings are mapped to the local code page with

MATLAB R13

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: With MATLAB R13, Data Dictionary properties which are

UNICODE strings are always
mapped to the local code page when they are read with the
DD MATLAB API. Thus,
when UNICODE strings are written to the Data Dictionary
using one code page (for
example, UTF-8 during DD XML Import), characters may be
different when the
strings are subsequently read with the DD MATLAB API.
The problem does not occur with MATLAB R14.
Workaround: Use the local code page when strings are, for example,
imported into the DD
using XML Import.
882 / 1260
ID:
PR20050729-10
Title:
Invalid use of module name in Addfile block not detected

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: A file is included via an Addfile block with the setting "Compile
and link to
the production code application". A module with the same
name is specified
somewhere else in the model or in the associated dSPACE
Data Dictionary. But the
source file of the module and the file specified by the Addfile
block differ in
the file extension or path. This is an invalid specification that
may not be
detected during code generation. Instead the operation "Build
Host" or "Build
Target" may fail with a linker error.
Example:
A variable class is used having the "Module" property set to
"user_file".
Furthermore via an Addfile block the file "UserFiles\user_file.c"
is included
with the setting "Compile and link to the production code
application". Since
the source file of the module and the file specified in the
Addfile block differ
in the path the code generation should abort with an error.
Instead the code
generation succeeds but the operations "Build Host" and
"Build Target" fail with
a linker error.
Workaround: Do not include a file via an Addfile block with the setting
"Compile and link to
the production code application, if a module with the same
name is specified
somewhere else and the source files differ in the file extension
or path.
883 / 1260
ID:
PR20050804-03
Title:
SIL simulation for HCS12/S12X-Metrowerks may give wrong results because of

compiler's "typedef int Bool"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In it's stdtypes.h the HCS12/S12X Metrowerks compiler typedefs Bool as int
(signed 16bit for this target), thus TargetLink also uses signed int for the
Bool type (generated in tl_basetypes.h with the information from
TargetConfig.xml). This may cause the SIL simulation on the Host PC to
calculate
wrong results, as int on the Host is 32bit (for IA32). Changing TargetLink's
typedef to signed short int does not work as the compiler then issues an error
about conflicting typedefs if stdtypes.h is included (indirect via math.h via
dsfxp.h).
Note: The PIL simulation calculates the correct results.
Workaround: Change Bool to 16bit signed short int in:
a) the compiler inlcude stdtypes.h (only needed if indirectly used in the TL
code)
b)
%TL_ROOT%\Matlab\Tl\SrcFiles\HCS12\Metrowerks12,20,31\TargetConfig.xml
(respective for S12X\Metrowerks41,45)
c) %TL_ROOT%\Matlab\Tl\SrcFiles\i86\<your mex compiler>\TargetConfig.xml
884 / 1260
ID:
PR20050808-06
Title:
Unnecessary task created when Stateflow input or output is

FCN_REF_ARG

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink may generate an unnecessary task if all of the

are fulfilled:
- multirate code generation is enabled
- the TargetLink subsystem only contains atomic subsystems
and routing blocks
- a Stateflow block is executed by a task
- the chart inputs and/or outputs are connected to TargetLink
ports of the
- the datatype of these chart inputs/outputs is the same as the
datatype of the
TargetLink ports
- the variable class of one or more chart inputs and outputs is
FCN_REF_ARG.
Under these circumstances the warning #31659 is emitted
notifying that the
datatype of the TargetLink port and the chart input/output is
different and an
unnecessary task may be generated.
Workaround: As a workaround perform the following steps:
1) Encapsulate the chart in an own subsystem.
2) Ensure that the newly created subsystem is executed by
the task instead of
the chart, e.g. by placing a Task block inside the subsystem.
3) Place TargetLink ports at the subsystem's inputs and
outputs. Choose
'default' as variable class and choose the same datatype as
the TargetLink port
in the TargetLink subsystem.
885 / 1260
ID:
PR20050808-20
Title:
SIL/PIL simulation deviation for Stateflow chart triggered by

multiple OSEK events

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If all of the following conditions apply for a Stateflow chart:

- it has multiple input events
- the input events are associated with OSEK events
- at least one of the input event sources is outside the
the SIL/PIL simulation is not correct, although the generated
production code is
correct.
886 / 1260
ID:
PR20050809-07
Title:
Nonpersistent variable in multirate production code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: You may specify a local variable although a persistent (i.e. at

least static
local) variable is required. TargetLink does not detect this
situation and
incorrect production code is generated. This error may occur if
all of the
- RTOS code generation is activated
- all systems inputs and outputs are mapped to FCN_ARG
and FCN_REF_ARG variable
classes via template
- at least two subsystem are directly executed by the same
task (e.g. by
assigning the task via a Task block)
- one of the systems is a direct or indirect child system of the
other
- the input/output of one of the systems has a variable class
which has the
'ArgClass' property set to a variable class with scope local and
no static
storage.
The variable generated due the 'ArgClass' property must be in
some cases at
least static local to obtain correct production code.
Workaround: Select at least a static local variable class for the 'ArgClass'
property for
the inputs/outputs of subsystems described above. You may
set the
'Scope_reducible' flag to obtain efficient production code.
887 / 1260
ID:
PR20050818-13
Title:
Superfluous calls of extern restart function if extern subsystem

is placed inside a reused subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An extern subsystem with an extern declared restart function

is placed inside a
reused subsystem. In the generated code for each instance of
the reused
subsystem a call of the extern restart function is placed inside
the restart
function. Only the first call of the extern restart function is
required, all
further calls are superfluous.
ID:
PR20050823-05
Title:
Compilation fails if two-dimensional array is address-mapped

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink generates not compilable code, if the address field

(property
address) of a Discrete State-Space, Look-Up Table (2D),
Interpolation (n-D)
using PreLook-Up, Interpolation Using Prelookup and Direct
Look-Up Table (n-D)
block is used for the two-dimensional block variable.
Workaround: Use of custom look-up functions:
For custom look-up functions there is a workaround possible.
You have to create a variable instead of a two-dimensional
array for the table
data. As the value for this variable you have to use zero or
leave the value
property unset.
After you have made this changes for the respective custom
look-up scripts the
code generator will create the correct initialization of the
address-mapped
table data.
No use of custom look-up functions:
If you do not use custom look-up functions avoid using the
address field for the
Discrete State-Space, Look-Up Table (2D), Interpolation (n-D)
using PreLook-Up,
Interpolation Using Prelookup and Direct Look-Up Table (n-D)
block.
888 / 1260
ID:
PR20050824-04
Title:
Exponent of x-axis not shown

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If the zoomed x-range of the plot is small (e.g. 0 ms-10 ms),
an exponent is
used for displaying the current time. But the exponent is
drawn outside the
visible range of the plot window, therefore it seems that the
time values of the
plot axis are wrong.
ID:
PR20050831-02
Title:
#ifdef support: missing include of macro definition

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If functions are generated whose definition is in a '#ifdef

macro' expression,
the declaration of this function in the associated header is also
in a '#ifdef
macro' expression.
If the macro that is used in the macro expression is defined in
an extra file
that is included
via an AddFile block, the extra file must also be included in the
header file
that contains the
function declaration.
This doesn't happen. So the macro is undefined in the header
file hence the
function is not declared.
889 / 1260
ID:
PR20050916-01
Title:
Matlab R13 crashes during "Create Subsystem"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Creating a subsystem for a system that contains trigger ports

can lead to a
segmentation violation. The problem can occur if the following
conditions are
fullfilled:
- Matlab R13 is used
AND
- the model contains a trigger port
AND
- the user creates a subsystem which activates a callback
function.
Workaround: - Before creating the subsystem, save the model.
OR
- Before creating the subsystem, open the TargetLink Main
Dialog or a TargetLink
port dialog.
ID:
PR20050922-02
Title:
Header file of reused function erroneously included in source

file instead of header file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a function is reused and placed into a separate module, the

header file will
be included in the header of that source file where the function
is called even
if this is not necessary. If the same function is not reused the
associated
include statement will be placed into the source file where the
function is
called and not in the corresponding header file.
890 / 1260
ID:
PR20050923-03
Title:
Code generation aborts with an access violation if nonexternal macro has a return parameter

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If both of the following conditions are fulfilled code generation

aborts with an
access violation:
- A subsystem is specified to be a non-extern macro (function
class has set
'Macro' to 'on' and 'Storage' to 'default' or 'static').
-- AND -- The subsystem has a function return parameter (a
subsystem outport or a block
inside the subsystem has a variable class which has 'Scope'
set to
'fcn_return').
Workaround: Do not specify subsystems to be implemented as non-external
macros
(implementation of subsystems as non-external macros is not
supported yet).
ID:
PR20050930-05
Title:
Custom Code block's common update sections are not

handled correctly

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Update sections with the keyword "common" are created

multiple times (one for
each instance in the model) in the step function of the
This is not correct. Update sections with the keyword
"common" are to be created
one time in the step function of the parent subsystem of the
Custom Code block
which defines the sections.
891 / 1260
ID:
PR20051005-05
Title:
Inherited data types of Stateflow objects

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: With Stateflow Vs. 6, Stateflow data objects can inherit their
data type, which
can be achieved by setting their type to "inherited". This is not
supported by
the TargetLink API.
- Trying to set the type (in TargetLink: sf.sftype property) with
the TargetLink
API via command line (tl_set function) fails with an error
message.
- The Property Manager does not offer "inherited" for
selection.
- The TargetLink API (tl_get function) returns "Float64" for the
sf.type
property if sf.sftype is "inherited". Likewise, the Property
Manager displays
"Float64".
Workaround: Use the Stateflow dialog to apply "inherited" to a Stateflow
object. This dialog
can be opened with Simulink's Model Explorer, or with the
TargetLink Property
Manager by double-clicking on the respective item.
ID:
PR20051017-01
Title:
Stateflow: overflow in relational operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink does not check relational operations in Stateflow

for overflow. Under
the following conditions the generated code for relational
operations in
Stateflow is incorrect:
- one operand is a variable
AND
- the other operand is a constant or an arithmetic operation
AND
- the constant or the result of the arithmetic operation cannot
be represented
within the implemented range of the variable.
Workaround: Introduce an auxiliary variable for the constant/arithmetic
operation.
892 / 1260
ID:
PR20051020-07
Title:
Suspiciuous warning #03441 during autoscaling range

calculation of Gain block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the Gain Value of a Gain block is arbitary, e. g. 3.1415, and

a range is
given at the input of the Gain block, the autoscaling routine
calculates first
the range of the output of the Gain block and uses this
calculated range for
propagation. Then a backward propagation is initiated.
Calculating the resulting
range for the previous block differs by eps from the given
range. Therefore the
warning is generated:
Warning #03441: <model>/ ... /Subsystem/Gain:
Backward range propagation of a constrained lower limit to
'<model>/Subsystem/Subsystem/Subsystem/Inport' is not
possible. The constrained
lower limit at the input of the current block is not equal to the
constrained
lower limit at the outport of the previous block.
893 / 1260
ID:
PR20051027-07
Title:
Selection window for VariableRef of a LogVariable object

points to wrong DD object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: When trying to set the property ?VariableRef? of a DD

LogVariable object via
DDManager, the opened selection dialog shows all variables
within the folder
/Pool/Variables.
But in some situations it is necessary to select a variable
located in the
Variables folder within the Subsystems area. This situation is
currently not
supported by the selection dialog at all. E. g. from the
selection window it is
not possible to select a subsystem variable.
Workaround: Type in the path - starting at /Subsystems - explicitly in the
inplace edit in
the property value list of the DDManager or use the DD
Matlab API for setting
the reference.
894 / 1260
ID:
PR20051117-01
Title:
Variables used in initializers are not reduced to minimal scope

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable is used as part of an initializer, then it is not

reduced in
scope.
At the moment, this affects only pointer struct member
initializers.
Examples:
1) Function Reuse
ISV_SUD1_tp tagISV_SUD1_my__sted_lib_test_1 = {
0 /* X_SUD1_Unit_Delay: */
};
ISV_SBLIB1_tp tagISV_SBLIB1___sted_lib_test_1 = {
&(tagISV_SUD1_my__sted_lib_test_1) /* pISV_SUD1_tp: */,
0 /* X_SBLIB1_Unit_Delay: */
};
The former variable is not reduced as it is needed for the
initialization of the
latter.
2) Lookup table axes and maps
The scope of axis arrays and map arrays remains global while
the map struct that
is initialized with their address can be reduced.
Workaround: In the first case, there is no workaround for the scope. If this
leads to
problems when compiling or linking due to identical identifiers
with external
linkage, then make the identifiers unique (either via making
sure that the
reused library blocks have different names or via
SubStructTemplate
specification, see "Filter Criteria for the SubStructTemplate
Object").
In the second case, choose a variable class with the desired
scope and storage
duration in the Lookup-Table Block dialog.
895 / 1260
ID:
PR20051130-05
Title:
Data Dictionary variable shall have a scaling

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The scaling property of a Data Dictionary variable shall not be

empty. Otherwise
the code generation will abort with error #20003. It is not
sufficent to specify
a scaling at the associated Type object only.
Workaround: Choose "VOID_SCALING" for the scaling property. TargetLink
uses the scaling
specified at the Type object.
ID:
PR20051205-04
Title:
Deviation in MIL simulation for Logical block in an algebraic

loop

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A Logical block is placed inside an algebraic loop, which is

only broken by a
fcncall trigger. This constellation leads to a wrong simulation
in MIL mode.
The TargetLink Logical block initializes the output depending
on the selected
logical operation with 0 or 1. In a loop the input and the output
signal share
the same memory. This leads to the effect that modifying the
output signal
changes the input signal as well. Therefore the input signal of
the last loop
run is overwritten by the initialization which leads to the
different behavior
compared with Simulink.
896 / 1260
ID:
PR20051214-05
Title:
Document generation produces wrong subsystem snapshot

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A wrong snapshot is generated and used inside the generated

documentation. This
behaviour occurs if inside a TargetLink Subsystem called
"Subsystem" lies a
subsystem also called "Subsystem". In the generated
document a snapshot of the
child subsystem is shown instead of the parent.
Workaround: Rename the respective subsystem to another name than
"Subsystem"
897 / 1260
ID:
PR20060113-06
Title:
Path to VariableClass object is clipped during Simulink to

TargetLink conversion of Simulink Constant block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: When a Simulink Constant block that has a fixed-point output

is converted to
TargetLink, the TargetLink Constant block scaling parameters
are set to match
the Simulink fixed-point parameters of the block that is being
replaced. For
this purpose, the output.class property is set so that it refers to
a Data
Dictionary VariableClass object, since by definition, a
TargetLink Constant
block whose output.class property is "default" does not have
scaling parameters.
The first VariableClass object in the current Data Dictionary is
selected which
fulfills following conditions:
Const = "on"
Macro = "off"
Scope = "global".
However, the VariableClass object is only set by name,
preceding
VariableClassGroup object names are clipped.
Example:
The VariableClass is
/Pool/VariableClasses/myConstVarClasses/myFirstConstClass
(/Pool/VariableClasses/myConstVarClasses is a
VariableClassGroup object)
The correct setting is
myConstVarClasses/myFirstConstClass
However, "myConstVarClasses/" is clipped off, which results in
the invalid
setting
myFirstConstClass.
Workaround: Set the output.class propery of TargetLink Const block
manually after
conversion.
ID:
PR20060116-07
Title:
Missing update assignments for extern called subsystems
898 / 1260
TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
899 / 1260
Description: A Function-Call triggered subsystem which is called from

outside the TargetLink
subsystem ("extern called subsystem") may require additional
update operations
before and/or after its call. These update operations are not
part of the
production code but must be implemented by the code where
the call is
implemented (TargetLink simulation frame resp. the calling
environment of the
target).
TargetLink simulation frame:
Update operations are not created (limitation).
Environment on the target:
Update operations must be created by the user himself.
Indicators for the necessity of update operations are the
following points:
- Extern called subsystem drives a Merge block. The outport
of the subsystem is
specified by a TargetLink-Outport / BusOutport.
- Extern called subsystem has a TargetLink-Outport /
BusOutport with a global
variable whose variable class does not alow to initialize the
variable.
- Extern called subsystem has a TargetLink-Outport /
BusOutport with a CallByRef
/ FcnReturn variable whose variable class has an ArgClass
which does not alow to
initialize the belonging actual parameter variable.
- Extern called subsystem has an TargetLink-Inport /
BusInport with a global
variable.
- Extern called subsystem has an TargetLink-Inport /
BusInport with a CallByVal
/ CallByRef variable whose variable class has an ArgClass.
To be sure if and which update operations are necessary the
following is
recommended:
- Insert an atomic subsystem X on the same level where the
extern called
subsystem resides.
- Insert a FunctionCallGenerator block in X.
- Connect the FunctionCallGenerator to the Trigger block of
the extern called
subsystem (use a Mux block).
- Let TargetLink generate code.
- Inspect the code which TargetLink has generated for X. The
content of the
function X shows how the external call of the extern called
subsystem has to be
implemented.
- Remove X.
900 / 1260
Workaround: If you want to avoid the necessity of update operations before

and / or after
extern called subsystems, you can do the following:
- If the extern called subsystem drives a Merge block:
- Do not use TL-Outports / BusOutports for the Outports which
drive the
Merge block
OR
- Map the TargetLink-Outport / BusOutport and the Merge
block the the same
variable (use fixed name and variable class
MERGEABLE_GLOBAL).
- Make shure that the outport's interface variables (global
variable resp.
global actual parameter) have variable classes which allow to
initialize them
(InitAtDefinition = ON or set a restart function name).
- Avoid TargetLink-Inports / BusInports for the inports of the
extern called
subsystem.
- If you want the inports to be CallByRef or CallByVal: Do not
set an ArgClass
at their variable classes.
ID:
PR20060203-01
Title:
TargetLink to Simulink conversion sets Simulink Inport data

type to undesired value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling

- a Simulink subsystem is converted to TargetLink; one of the
Simulink Inport
blocks has a fixed point data type, thus the scaling parameters
of the
TargetLink Inport which is inserted are adapted accordingly
- during working with TargetLink, the user creates another
Simulink Inport at
root level and uses a copy of said TargetLink Inport to define
the interface of
the new input; the new Simulink Inport has data type "auto",
- when the model is converted back to Simulink, the fixed
point settings of the
new Simulink Inport are set according to the scaling
parameters of the copied
TargetLink Inport, i.e. the Simulink data type is fixed point after
reconversion.
Workaround: Copy TargetLink Inport from TargetLink library tllib.
901 / 1260
ID:
PR20060222-09
Title:
Graphical function output in Stateflow is not logged during MIL

simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a graphical function output is logged it should be logged in

all simulation
modes. But currrently no signal values are shown if a MIL
simulation is done.
ID:
PR20060306-03
Title:
Erroneous message about defining different types with the

same name in custom look-up table script

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An error about defining different types with the same name
can be issued
although the types are equal if all following conditions hold:
- Two equal types with the same name are specified in a
custom look-up table
script
- Both types are not to be defined
- The template code containing one of the type definitions
contains an include
while the template code with the second type doesn't
Workaround: Specify includes in both template codes.
902 / 1260
ID:
PR20060309-03
Title:
No error message if TargetLink Main Dialog is not present in a

model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a new TargetLink model is created from scratch without

adding a TargetLink
Main Dialog block, the results of a MIL simulation of
TargetLink subsystem can
differ from results of an equivalent Simulink subsystem (e.g.
Min/Max block or
Saturation block).
Placing the TargetLink Main Dialog block to the model assigns
a script to the
model property "InitFcn" which initializes the data server. This
is necessary
for performing correct simulations and loggings.
The desired behavior would be to throw an error message,
that the TargetLink
Main Dialog was not added to the model.
Note: This error does not occur if a different TargetLink model
supplied with a
Main Dialog was opened before. The data server was already
initialized by the
former model and therefore it must not be initialized again to
provide correct
simulation handling.
Workaround: Place always a TargetLink Main Dialog to the model or write a
script which
checks if the entry
"if exist('tlds_start','file'), tlds_start(gcs); end" is included in the
model
property "InitFcn".
903 / 1260
ID:
PR20060310-02
Title:
No warning is issued if saving partial Data Dictionary files via

dsdd('copytree',...) command, references may be broken after
reload

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: If you save a partial Data Dictionary file and this partial Data
Dictionary
contains Data Dictionary handle references inside this sub
tree, it is expected,
that these references are restored without any problems after
reloading this
Data Dictionary file into another Data Dictionary file. This is
not correct. If
the reference properties are stored as "Reference" ? e.g. as
path string ? then
resolving the references works. In the other case it is not and
leads to
unresolved references. But no warning is issued.
Workaround: Check if your partial Data Dictionary file contains Data
Dictionary handle
reference properties. If so convert them to use path strings
instead.
904 / 1260
ID:
PR20060315-07
Title:
The TargetLink code generator has problems to get the

(correct) values of variables which names starts with "L_" and
which are defined in the "Initialization Commands" of a
subsystems

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the name of a variable defined in the "Initialization

Commands" of a
subsystem starts with "L_" and the variable is used inside this
subsystem the
code generation fails. The code generation reports for each
use of the variable
inside the masked subsystems that the variable could not be
evaluated.
If this variable is defined in the base or model workspace
either, no evaluation
error occurs. Instead in the generated code the value
specified in the base or
model workspace is used, but not the value specified via the
"Initialization
Commands" of subsystem.
Workaround: Do not specify variables which name starts with "L_" via the
"Initialization
Commands" of a subsystems.
ID:
PR20060316-05
Title:
No warning issued for Custom Code variables not included in

function reuse structure

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Variables for states of Custom Code block are not moved to
the function reuse
structure. Thus they are not instance specific. This is a
limitation of the
TargetLink code generator. Currently neither a warning/error
thrown by the code
generator nor this limitation is mentioned in the
documentation.
Workaround: A state can be modeled by an additional Unit Delay block.
905 / 1260
ID:
PR20060322-08
Title:
In Product block with division the constraint ranges are not

considered for output of division-by-zero exception handling

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the output of a Product block with division has constraint

ranges, these
limits are not considered for the division-by-zero exception
handling.
The outport of the division has a constraint range of [-4000,
3800], e.g. as
integer range divided by its lsb.
The following code is generated:
*/
Int16 Sa1_Product /* LSB: 1.3 OFF: 0 MIN/MAX: -4000 ..
3800 */;
Int16 Aux_S16;
/* Product: Subsystem/Product */
Aux_S16 = ((Int16) Sa1_InPort1) * 26;
if (Aux_S16 != 0) {
Sa1_Product = (Int16) (((Int32) (((UInt16) Sa1_InPort) * 11)) /
Aux_S16);
}
else {
/* Subsystem/Product: Numerator always greater than or
equal to zero. */
Sa1_Product = 32767;
}
In the else case, the data type max value (= 32767) is used,
which ignores the
constraint range.
The implemented exception behaviour may cause trouble in
the following
operation, where a smaller maximum value is expected.
Workaround: Do not constrain the ranged from within the product block, but
by means of a
subsequent saturation block.
906 / 1260
ID:
PR20060323-06
Title:
Simulink initialization error if bus object referenced in Simulink

Inport block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: In a special case the source of a bus is given by a Simulink

Inport block which
references a bus object. This constellation leads to an
initialization error.
The error occurs with R14SP2, R14SP3 and R2006a.
ID:
PR20060323-11
Title:
Wrong base type rename

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the typedef section of the Data Dictonary a base type can
be specified. It is
possible to set in the BaseTypeRename property of a base
type a link to a type
whose IsBaseType property is set to "off".
Furthermore it is not proved by the code generator that the
BaseTypeRename
property of a renamed base type contains a link to itself.
This may lead to wrong result of $(BaseType) name macro.
Workaround: Use correct specification of base type rename.
907 / 1260
ID:
PR20060323-13
Title:
Base type may be wrong if renamed base type has a link to a

wrong origin base type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: It is not proofed that a base type and corresponding renamed

type reference each
other.
For example, if a base type "OriginalType" is renamed to a
base type
"RenamedType" then the "BaseTypeRename" property of
"OriginalType" has a link to
"RenamedType".
The renamed type "RenamedType" should have set the
property "BaseType" to origin
base type "OriginalType" and not to another base type e.g.
"OtherType". If such
a renamed base type "RenamedType" has set a link to a
wrong base type
"OtherType" then the Data Dictionary is invalid. Although it is
possible to
generate code for a model using such invalid Data Dictionary.
In file "tl_basetypes.h" the renamed type "RenamedType" is
correctly mapped to
the base type "OriginalType", but when selecting the renamed
base type
"RenamedType" in a block dialog of a model the wrong type
"OtherType" is used,
which finally appears in the generated code. This may be
confusing and there
apperars no warning or hint for the user to identify this
inconsistency.
Workaround: Specify the base type rename as described in the
documentation.
908 / 1260
ID:
PR20060323-17
Title:
A write-protected Data Dictionary file results in an endless

"beep" sequence on closing MATLAB

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: This problem occur if all of the following conditions hold:

- MATLAB R14 or later,
- a Data Dictionary file had been loaded and the Data
Dictionary has been
modified, but not saved,
- the Data Dictionary file is write protected,
- MATLAB is shut down.
Then the Data Dictionary prompts the user if the modified
Data Dictionary should
be saved. However, due to a modified exit sequence this fails
in MATLAB R14 and
later, and MATLAB runs into an endless loop emitting beeps.
The MATLAB process
must be kiled via the Windows Task Manager.
Workaround: There are several possibilities:
1. Make sure that the file is not write protected to enable
saving when MATLAB
is closed down.
2. If the Data Dictionary should not be saved, clear it prior to
closing MATLAB
by invoking
>> dsdd clear;
or
>> dsdd_free;
3. Save the DD before closing MATLAB by invoking
>> dsdd save;
This implies that the DD file is not write protected. To save it to
another
file, invoke
>> dsdd save //DD0 anotherFile.dd
909 / 1260
ID:
PR20060323-23
Title:
Data Dictionary Manager does not discard irrelevant

whitespace from object paths

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If a user enters a Data Dictionary object with trailing or leading

whitespace,
say due to copy & paste, then in the former case everything
up to the last slash
is deemed valid; in the latter case, everything is deemed
invalid and treated as
if a single slash had been entered.
Expected behaviour: Leading and trailing whitespace is
trimmed from the path or
ignored when evaluating the path.
Workaround: Enter the path string without whitespaces.
ID:
PR20060324-12
Title:
Special character "carriage return" inside a filename

specification for Data Dictionary include files is not handled
correctly

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: An error message during save of Data Dictionary is thrown if

the Data Dictionary
is configured as follows:
1. The Data Dictionary contains DDIncludeFiles located at
/Config/DDIncludeFiles
2. The property "FileName" of one of the DDIncludeFiles
contains the special
character "carriage return". It is possible to enter such
character by using the
Edit String dialog.
The error message is:
Could not save the current DD project file. The message was:
File I/O error
during saving to included file [filename].
This is caused by the special character "carriage return". The
character is not
show in "FileName" property but in Edit String dialog.
Workaround: Enter the filename without special characters like "carriage
return".
910 / 1260
ID:
PR20060328-18
Title:
Error #20160 when two Bus Selector blocks in series select

the same signal

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Codegeneration may abort with Error #20160 "Selected signal

for Bus Selector
outport not found" in following model situation:
A signal from a Bus Selector block drives a bus capable block.
Bus-capable
blocks are
- Unit Delay block
- Merge block
- Rate Transition block
- Zero-Order Hold block
The output signal of the bus-capable block is fed into another
bus. The output
signal is selected form the bus with a Bus Selector block. If
this Bus Selector
block drives another Bus Selector which selects the same
signal error #20160
comes up.
Usually it makes no sense to have two Bus Selector in series
that select the
same signal (which is no bus signal). Nevertheless this is not
prohibited
according to Simulink's semantics.
Note: bus-capable blocks where introduced in MATLAB R14.
Therefore this problem
occurs only in MATLAB R14 and above.
Workaround: Remove the second Bus Selector block.
911 / 1260
ID:
PR20060330-09
Title:
Event triggered tasks with AutoStart property set to "off" are

not started during SIL/PIL simulation.

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Event triggered tasks with AutoStart property set to "off" are
not started
during SIL/PIL simulation. This a correct behaviour.
However, the user is not informed about it. Thus, it's difficult to
find the
reason for the differences between MIL and SIL/PIL
simulation.
Workaround: Set the AutoStart property of the event triggered tasks to "on".
ID:
PR20060330-13
Title:
Wrong code is generated for FIR Filter block using TriCore

Target Optimization Module

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the code generation option TOM TriCore is chosen, a FIRfilter with circular
buffers is implemented through a macro call. A wrong macro
call is generated, if
the width of the delay line variables is less than the width of
the coefficient
variables. The chosen macro returns wrong results.
Workaround: Use the same variable type for the delay line parameters as
for the
coefficients.
912 / 1260
ID:
PR20060403-11
Title:
Wrong code is generated if the FIR Filter block using TriCore

Target Optimization Module

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Wrong code is generated if the FIR Filter block with circular
buffer is placed
in a library in a reused subsystem. The code generator
ignores the reuse
specification completely, which results in compilable code, but
produces
incorrect results.
Workaround: Do not use circular buffers or do not use FIR filters with them
in a reused
library function.
ID:
PR20060404-06
Title:
Unintentional optimization of relational operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A relational operation may be be simplified unintentionally, if

- a Constant block preceeds a Relation, Logic, Switch or If
block
- the variable class specifies the constant to be const
- the variable class of the constant has the "Optimization"
property not set to
"ERASABLE" or if the variable class specifies the constant to
be volatile.
Workaround: Set the "Info" property of the associated variable class to
"adjustable" or
unset the Const property in the associated variable class.
913 / 1260
ID:
PR20060404-09
Title:
No warning about not exactly representable constant value in

a relational operation in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If in Stateflow a relational operation is specified, whose

operands are
- a unscaled, integer variable (unscaled means LSB = 1.0 and
Offset = 0.0)
- and a constant value that cannot exactly be represented in
the scaling of the
variable,
then no warning will be issued about the constant value not
being representable
in the scaling of the variable.
The generated code will be correct because the constant
value will be rounded.
914 / 1260
ID:
PR20060405-15
Title:
Incorrect initialization of auxiliary variable storing access

function return value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Under the following conditions the handling of variable access

via an access
function may be incorrect:
- A TargetLink InPort block of a TargetLink subsystem is
connected to a
Stateflow chart.
AND
- The output variable of the InPort block is associated with an
access function
template.
AND
- The Stateflow chart has at least one graphical function that
uses the
Stateflow input data connected with the respective TargetLink
InPort block.
In this situation the auxiliary variable storing the return value
of the access
function's call may be used before its definition.
Workaround: Set the optimization property "SIDE_EFFEKT_FREE" in the
corresponding function
class of the access function. This will suppress the creation of
the auxiliary
variable for storing the access function's return value. If the
acess function
is not side-effekt free at all, additionally insert another
TargetLink InPort
block between the existing TargetLink InPort block and the
Stateflow inport.
915 / 1260
ID:
PR20060407-05
Title:
If data variants are used for coefficients of Discrete Filter block

or Discrete Transfer Fcn block, their signs are not handled
correctly

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Generally, the signs of coefficients are modified by code

generator to provide
multiply-add code sequences and to benefit from
microprocessor's MAC feature. If
the numerator's and denominator's coefficients of a discrete
filter or discrete
transfer function are specified as data variants their signs are
not handled
correctly and the generated code is wrong.
ID:
PR20060407-09
Title:
In discrete blocks with variant coefficients the appearance of

coefficients in code can not be influenced

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: For several discrete blocks the appearance of coefficients in

the generated code
can be influenced
- Discrete Filter: "Keep vector structure"
- Discrete Transfer-Function: "Keep vector structure"
- Discrete State-Space: "Keep current matrix structure"
or "matkeep" via the MATLAB-API for all of the above.
Although the option can be changed via the block dialog, it
does not influence
the generated code, if the coefficients are given as variants.
The coefficients
are always generated as if the option is selected (all
coefficients are kept as
arrays).
916 / 1260
ID:
PR20060410-06
Title:
In Data Dictionary Manager the Data Dictionary Navigator

does not display huge amount of objects properly

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: When a Data Dictionary object contains more than 60000

objects on one level, the
objects which are below these 60000 objects will not be
displayed in Data
Dictionary Navigator.
ID:
PR20060412-11
Title:
Data type mismatch after Simulink to TargetLink conversion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When Simulink scaled data types are used in a model, these
scalings are
transferred to the replacing TargetLink blocks during Simulink
to TargetLink
conversion. However, after conversion has finished the model
might be
inconsistent, since TargetLink blocks do not support scaled
Simulink signals.
Workaround: Simulate with "true doubles".
917 / 1260
ID:
PR20060417-01
Title:
Difficult to adjust width of Name column of Block Explorer in

Property Manager

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If the Name column of the Block Explorer has scrollbars, the
width of the column
can only be modified by
- scrolling the column to its rightmost position (use the
horizontal scrollbar)
- drag & drop the limit between the buttons on top of the first
(Name) and the
2nd column
The Name column has scrollbars if items are out of view.
Workaround: If possible, enhance size of Block Explorer to have all items
displayed. Then,
the scrollbars disappear.
ID:
PR20060426-03
Title:
Internal error for function reuse if Data Dictionary structure

component is used and struct root has a variable name

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When Data Dictionary structure component is used inside a

reused system and the
structure root has a variable name (containing $R, $S, $C) the
fatal error
E30016 can occur.
Workaround: Don't use $R, $S and $C in the structure root.
918 / 1260
ID:
PR20060504-01
Title:
Multiple calls of variant switch function if the switch functions

of several data variants are "merged"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In general for each data variant a separate switch in a

separate function is
generated in which the data variant pointer is initalized. These
functions are
called from the main restart function of a TargetLink
subsystem. With a function
template it is possible to redefine the function names of this
variant switch
functions. If a fixed name is given without $R leading to the
same function name
for every data variant currently only one function is generated
in which the
code for all data variants resides. But this function is still
called several
times in the main restart function:
Void RESTART_Subsystem(Void)
{
x();
x();
}
919 / 1260
ID:
PR20060510-02
Title:
Wrong RTW simulation code for "PreLook-Up Index Search"

and "Interpolation (n-D)using PreLook-Up" block using
Standalone Blockset

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: 1) The TargetLink "PreLook-Up Index Search" block has

wrong out-of-range
handling using RTW if the TargetLink Standalone blockset is
used and a RTI
environment is used to generate simulation code for the model
(Code generation
is done by RTW) and Input signal of "PreLook-Up Index
Search" block is
out-of-range of breakpoint data.
The simulation behavior differs in Simulink and RTI/RTW. A
fractional part will
be calculated even if the input is out-of-range.
The calculation can cause a crash, because there is a
memory read outside of the
breakpoint data vector.
2) Additionally there is generated but not compliable
simulation code if code
generation is done by RTW for the "Interpolation (n-D)using
PreLook-Up" if this
block is driven by a "PreLook-Up Index Search" with setting
"output only the
index".
Workaround: 1) Is the input signal of the "PreLook-Up Index Search" block
out-of-range of
the breakpoint data, use a saturation block to satur?te the
inputsignal to the
range of the breakpoint data vektor.
2) It is not possible to use the "Interpolation (n-D)using
PreLook-Up" Block
with a "PreLook-Up Index Search" block with setting "output
only the index", use
"Separat output for index and fraction" instead or don't use the
the
Interpolation Block, if you want to use the "PreLook-Up Index
Search" block with
setting "output only the index", use the Simulink Selector
block.
patches:
TargetLink 2.3.1p2
920 / 1260
ID:
PR20060515-01
Title:
Elementwise different scalings of CustomCode parameters

are not considered in MIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Elementwise different scalings of CustomCode parameters

(currently only possible
if the parameter variable is a Data Dictionary variable) are not
considered in
MIL simulation mode. Because of this MIL and SIL results
may differ.
Workaround: Avoid vectorized Custom Code block parameter variables with
elementwise
different scalings.
ID:
PR20060524-01
Title:
Constant block dialog does not correctly show renamed

variable types

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: In the constant block dialog the variable type is not shown
correctly if it is a
renamed base type and
- the Variable Class is "default" and
- the option "Cast output signal to TargetLink type" is
activated.
Instead of the renamed base type, the actual base type is
shown. Moreover in the
Object Selection dialog that opens after pressing the [...]
Button, both the
renamed base type and the base type are shown (instead of
only the renamed
type).
921 / 1260
ID:
PR20060609-01
Title:
If a Data Dictionary variable with code varianted properties is

used inside root function interface, the simulation frame
generation fails.

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a Data Dcitionary variable with code varianted properties is

used inside root
function interfaces, the generated information inside the Data
Dictionary is
incorrect and the simulation frame generation fails with the
following error
message:
*** Error while attempt to access the data dictionary.
ID:
PR20060609-02
Title:
Code generator aborts for Stateflow chart containing floating

point index variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation aborts if following conditions hold:

- Stateflow variable of floating point type is used as index
variable
AND
- Index variable is used in condition as part of operand of a
relation
The error message is an access violation in "tl_codegen.dll"
Workaround: Assign fixed point data type to index variable.
922 / 1260
ID:
PR20060614-01
Title:
Superfluous notes/warning reported during autoscaling of

Look-Up Table block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During autoscaling with unchecked option "Scale parameters"

of Look-Up Table
block notes and a waring are given that are superfluous.
The notes are:
Note #03430: <block>:
Parameter x-axis scaled according to current value.
Parameter y-axis scaled according to current value.
Scaling of look-up table output synchronized with scaling of yaxis.
Warning #03409: Look-Up Table:
Autoscaling is not possible, because at least one port has no
ranges.
The two notes #03430 have different text as in online help.
They are not
necessary cause the parameters should not be scaled
The warning #03409 contradicts note #03439, cause the block
is scaled based on
table values, no ranges are needed.
Workaround: Activate option "Scale parameters" for the Look-Up Table
block.
ID:
PR20060614-02
Title:
Simulink segmentation violation if the simulation mode is

changed to MIL mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The change to MIL simulation mode ends with a segmentation

violation, in the
case a root level inport is deleted before and inserted once
again by an undo
command.
923 / 1260
ID:
PR20060619-69
Title:
Undefined variable initialized in restart function leads to

compiler error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are fulfilled the code generator
creates an
initialization of an undefined variable which leads to a compiler
error:
- The TargetLink subsystem is a conditioned subsystem (e.g.
enabled or
triggered)
AND
- an outport of the TargetLink subsystem has scope
"ref_param" or "fcn_return"
AND
- the variable class template SLFcnInput is either not defined
or it is defined
and mapped to a variable class with scope "global"
AND
- the variable class template SLGlobal is mapped to a variable
class which has a
restart function name.
Workaround: Make at least one of the conditions described above not
fulfilled.
ID:
PR20060621-03
Title:
Simulation differences because of non-global scope of

SystemTime variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The codegenerator does not warn on a non-global scope of

the SystemTime variable
(DD/Pool/Variables/RTOS/SystemTime). A SystemTime
variable with scope local or
static global can lead to differences of MIL vs. SIL/PIL
simulation because the
TargetLink simulation frame needs access to this variable
during simulation.
Workaround: Specify global scope for the SystemTime variable.
924 / 1260
ID:
PR20060623-03
Title:
Wrong variable reference for reference parameter in Data

Dictionary subsystem area leads to compilation errors in
simulation frame

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The use of Data Dictionary Pool variables with scope

ref_param/value_param and
with name template "$D" may lead to the generation of
corresponding actual
parameter variables with the same name. In this case, the
naming of the
corresponding variable objects inside the generated Data
Dictionary subsystem
area fails, leading to wrong variable names in the simulation
frame file.
Compilation of the simulation frame file fails.
Workaround: Make sure that the names of Pool variable objects with scope
ref_param or
value_param differ from the names of the respective code
variables, i.e. do not use "$D" in the NameTemplate or the
same name as the
object's name.
ID:
PR20060628-01
Title:
Error #15252 for an unused workspace variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: If for a Simulink Outport a workspace variable is specified in

the "Initial
Output" field but the "Initial Output" field is greyed, the
TargetLink Code
Generator tries to evaluated the workspace variable although
the value of the
workspace variable is not required for the code generation. If
the workspace
variable is not defined in the workspace, the code generation
fails with the
error #15252:
Evaluation of parameter expression "VariableName" for
parameter "Initial Output"
failed.
Workaround: There exits two solutions to avoid the problem:
- Define the missing workspace variable
- Specify "[]" in the "Initial Output" field of the Simulink Outport
block.
925 / 1260
ID:
PR20060704-01
Title:
Static property of array is neglected during optimization

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the generated code, in every simulation step one element of

an array is
written - but all elements are read, e.g.
a[i] = in;
out = a[0] + a[1] + a[2] + ...
With optimization level 0, "a" is a global initialized variable.
With
optimization level > 0, the scope of this variable is
errouneously reduced to
local (non static) and the initialization is eliminated. This lead
to wrong
simulation behaviour.
Workaround: Give "a" a user variable class that has the
SCOPE_REDUCIBLE optimization
attribute not set.
ID:
PR20060706-02
Title:
The macsave option for the SH2e compiler is switched off in

TargetLink provided makefiles

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The macsave option specifies if the MACH and MACL

registers of the SH2e are
saved on function calls and restored afterwards. The
TargetLink makefiles for
simulation and DsFxp.lib switch this option to off (compiler
default would be
on). This poses no problems on the TargetLink code itself, as
the TargetLink
SH2e TOM code does not call functions that use MACH or
MACL recursively.
Problems can arise if the customer calls TargetLink generated
code or DsFxp code
from inside other code that also uses the MAC registers,
which may lead to wrong
computations of results by register trashing.
Workaround: Change m=0 to m=1 in the related makefiles, especially the
DsFxp makefiles if
you consider this problem important to you and rebuilt the
library.
926 / 1260
ID:
PR20060710-01
Title:
Renaming custom property to an already existing custom

property name leads to content deletion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If you rename a custom property inside the Data Dictionary

Manager to a name of
a custom property which already exits, this content of the
property, e.g. the
value, will be overwritten without any warning.
ID:
PR20060710-05
Title:
Required initialization for struct variable may be suppressed in

generated code without warning

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: TargetLink emits no warning if a struct variable must be

initialized but the
user has chosen not to initialize it by specifying for all relevant
struct
components a variable class with "InitAtDefinition" set to "off"
and empty
"RestartFunctionName".
ID:
PR20060710-06
Title:
Sum block with more than two inputs can result in

nonoptimizable auxiliary variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Sum block has more than two inputs auxiliary variables
are generated to
store intermediate results. These auxiliary variables are not
optimizable and
remain in the code.
Workaround: Since TargetLink 3.2 and newer activating the code generator
option
"DoNotUseAssignArithmeticForAccumulation" will improve the
generated code.
927 / 1260
ID:
PR20060712-01
Title:
Code generation aborts with error #15203 for Constant block

inside an incremental subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink may throw the unnecessary error #15203 during

code generation for an
Constant block that
- resides inside an incremental subsystem AND
- drives an input of an atomic subsystem AND
- the input of the atomic subsystem has no TL or Bus port
block.
Workaround: Use one of the following alternative workarounds:
- choose another variable class than 'default'
- insert a TL or Bus port block at the atomic subsystem input
- place the constant inside the atomic subsystem.
ID:
PR20060712-07
Title:
False error for name ambiguity of typedef and variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If an interface variable of a Custom Code block has the same

name as an user
defined typedef, an error message reports this name
ambiguity. The error is
false, if typedef property "CreateTypedef" is set to "off".
Workaround: Alter the name of typedefs or variables to have different
names (e.g. use a
prefx t_ for typedefs).
928 / 1260
ID:
PR20060712-08
Title:
Look-Up Table structure for user look-up script may not be

correctly initialized in restart function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a structure is specified in a user look-up script and has a

component that
has a pointer type, the component will not be initializable in a
restart
function, even if this is specified in the corresponding variable
class
(property "InitAtDefinition" set to "off" and property
"restartFunctionName" is
set to "default"). Neither a warning nor an error will be emitted
during code
generation.
ID:
PR20060717-06
Title:
Switching simulation mode fails if TargetLink subsystem uses

more than 466 root level ports

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Switching from MIL to SIL/PIL mode leads to an error during

the reconstruction
of the simulation frame for a TargetLink subsystem with a
number of either root
level in- or outports larger than 466. The reason is that in this
case the
calculated block positions for the blocks in the simulation
frame are out of the
Simulink maximum drawing area scope.
929 / 1260
ID:
PR20060721-03
Title:
Warning #20681 for Discrete Time Integrator block in

combination with an Unit Delay Reset Enable block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If the External Source input of a Discrete Time Integrator block

is connected to
an Unit Delay Reset Enable block then the initial value of the
latter is also
used to initialize the state of the integrator. Although code is
correctly
generated for such a configuration a superfluous warning will
be issued during
code generation:
"Warning #20681
The state's external initialization value could not be
determined. Using zero as
initial value."
Workaround: Ignore the warning.
ID:
PR20060803-01
Title:
Optimization does not eleminate dead code if auxiliary

variables are used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code optimization does not eleminate dead code if

auxiliary variables are
used.
The so-called dead code elemination cannot optimize the
code, cause the
auxiliary
variables are treated as not optimizable, regardless whether it
is the case or
not.
Auxiliary variables can be introduced because of certain code
pattern in many
different
constellations.
Workaround: Try to prevent the generation of auxiliary variables by different
modeling.
930 / 1260
ID:
PR20060811-01
Title:
Code lines containing string literals in custom code may be

split in generated code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When using custom code by applying the Custom Code block,
and the custom code
file contains a string literal, it may happen that in the
generated code the
string literal is split into two lines at a space-character near the
line break
limit, making the code uncompilable.
Workaround: Raise the line break limit.
ID:
PR20060817-01
Title:
Invalid Data Dictionary variables created via block dialog if the

value must be scalar expanded

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Creating a Data Dictionary variable object via a block dialog

leads to invalid
Data Dictionary variable object if the width is larger than one
and the value
is scalar (scalar expansion). The Data Dictionary validation
leads to the
following error message: "The Width property must be
compliant with the Value
property."
Workaround: Manually correct the invalid Data Dictionary variable object.
931 / 1260
ID:
PR20060818-01
Title:
Using NameMacros in a LookupFunctionTemplate may lead

to error #17299 during code generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Using NameMacros in LookupFunctionTemplate leads to the

following error, if the
function name for two Look-Up Table Blocks will get the same
name after
resolving the NameMacro:
Error #17299 Merging functions is not permitted
Workaround: Do not use NameMacros in LookupFunctionTemplate for the
function name for
templates that are used for more than one block, which lead to
the same function
name.
Use the Template with a fixed name.
ID:
PR20060824-01
Title:
Simulation logging fails for external interface variables using

access functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If the access to interface variables of the TargetLink

Subsystem is done by
access functions the simulation may not work if
- the interface variables have a variable class with properties
"Scope" =
"extern" and "Alias" = "on"
AND
- an access function template with property "Kind" = "READ".
In this case the simulation plots are always zero.
932 / 1260
ID:
PR20060830-05
Title:
Code generation stops with internal error #10007 for struct

variables with Variable Class EXTERN_MACRO

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Using the Variable Class EXTERN_MACRO on structure

variables specified in the
Data Dictionary can cause the code generation to stop with an
internal error
like:
Fatal #10007: Internal error. Error code: ExprLocAr93.
Contact dSPACE's
Workaround: Use Variable Class GLOBAL_EXTERN_ALIAS instead.
ID:
PR20060831-07
Title:
Inconsistent behaviour to Simulink/Stateflow for data type

conversion resp. explicit casts from float to boolean

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Casts (explicit and implicit) from float type to boolean type in
Simulink/Stateflow are treated inconsistent as well in
Simulink/Stateflow as in
TargetLink. Sometimes such a cast is treated like a
comparision "!=0". Sometimes
it is treated like a cast to an integer type. Furthermore
the behaviour of TargetLink and Simulink/Stateflow is not
equal in every case.
The behaviour of Simulink/Stateflow can change from version
to version.
Workaround: Don't cast from float to boolean in the model. If such a cast is
not avoidable
model the behaviour you want explicit by using if-else
constructs.
933 / 1260
ID:
PR20060831-12
Title:
Initialization of Simulink model with stand-alone S-function

fails

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The Initialization of a Simulink model with stand-alone Sfunction fails if the
following conditons apply
- the data type for all outports of the TargetLink subsystem
that the
stand-alone S-function has been generated for is different
from double
AND
- the data type of the input signal of the subsystem replaced
by the subsystem
with stand-alone S-function is different from double.
In this case Simulink reports following error message:
"Cannot set the output port 1 data type of
'<modelName>/<subsystemName>/S-function
frame/TriggerPort' to <dataType>'. The
output port data type must be either 'double' or 'int8'."
Workaround: Set the output data type in TriggerPort block in
'<modelName>/<subsystemName>/S-function frame' to
double (instead of auto).
934 / 1260
ID:
PR20060901-03
Title:
Wrong code generated for ActionPort triggered subsystems

driving Merge block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If Switch Case Action Subsystems (or If Action Subsystems)

driven by the same
Switch Case block (or If block) drive the same Merge block
and one or more
outports of the Switch Case Action Subsystems (or If Action
Subsystems) which
drive this Merge block have option "Output when disabled" set
to "reset" the
generated code does not match the Simulink behavior.
Workaround: A workaround is available if both of the following conditions
are fulfilled:
- All ActionPort triggered subsystems of the Switch Case block
(or If block)
drive the same merge block.
- A "default" (or "else") branch exists.
In this case you can set all outports to "Output when disabled"
to "held"
without changing the model behavior.
ID:
PR20060908-14
Title:
Error opening block dialog in TargetLink Blockset Standalone

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Opening a block dialog in TargetLink Blockset Standalone the

following error may
occur:
Error evaluation 'OpenFcn' callback of <mask type> block
(mask) '<block name>'.
Undefined function of variable 'tl_get_scaling_str'.
Reason is a missing file in installation, which is called, if block
property
"output.show" is set to "on".
Workaround: In full featured mode set block property "output.show" to "off"
(Property
Manager, Property Selector > Block output > Show output
scaling beneath block
icon).
935 / 1260
ID:
PR20060920-15
Title:
Function for Look-Up Table uses insufficient auxiliary variable

for index search with more than 256 axis points

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For the implementation of a Look-Up Table an auxiliary

variable is used for
index search. If the Look-Up Table has more than 256 axis
points this variable
is insufficient regarding the data type. Erroneously always an
auxiliary
variable of type UInt8 is generated.
Workaround: To get correct code it is necessary to use less than 256 axis
points.
ID:
PR20060926-15
Title:
Simulation frame cannot be generated caused by constant

parameter of an internally and externally called Stateflow chart

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A chart is triggered with Trigger type "function-call". The chart

is called
inside the TargetLink root system and outside the TargetLink
root system. The
variable class of a constant in the externally and internally
called stateflow
chart has scope "value_param". Its "ArgClass" is left to
default, or it is
optimizable.
In this situation TargetLink cannot generate the simulation
frame.
Workaround: Specify an "ArgClass" that is not optimizable for the constant
variable.
936 / 1260
ID:
PR20060928-17
Title:
Components of DataDictionary struct variables may get

incorrectly merged in generated code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: You may use components of DataDictionary struct variables

multiple times in one
TargetLink Subsystem if the component's variable class has
the MERGABLE flag
set. The component may be used for block variables that
require an initial
value. Unlike for plain variables TargetLink doesn't check if all
the initial
values are identical. Only one initial value is used and all other
initial
values are ignored. Wrong production code may be
generated.
Workaround: Set an initial value at the Value Property and use the ddvcommand at the
affected blocks.
ID:
PR20061002-06
Title:
Initialization error reported by an Unit Delay Reset Enable

block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: According to documentation the Unit Delay Reset Enable

block should be able to
process signals of any basic data type when performaing a
MIL simulation.
Actually an initialization error occurs if the data type of the
input signal is
not double or single.
Workaround: If possible, select another data type for output signal at the
driving block or
insert a Data Type Conversion block before the Unit Delay
Reset Enable block.
937 / 1260
ID:
PR20061009-25
Title:
Function for Look-Up Table block uses interface variable of

insufficient type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In a function for PreLook-Up Index Search block the interface

variable that
holds the calculated index and fraction may be of insufficient
type.
The variable type is specified in the bock dialog. Although the
index will not
fit in the variable, no warning or error is thrown.
Workaround: Please use a variable type that will fit the range of index
values.
938 / 1260
ID:
PR20061013-17
Title:
Inefficient code pattern may be generated for Merge/Mutliport

Switch block successor variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In conjunction with Merge blocks or Multiport Switche block

often code patterns
like
if (cond) {
c = a;
}
else {
c = b;
}
d = c;
are created. In many cases, these could be optimized to
if (cond) {
d = a;
}
else {
d = b;
}
If 'c' has a RestartFunctionName of 'default' or scope
reduction of 'c' is
performed to a ScopeReducedClass with a
RestartFunctionName of 'default', then
the reinitialization of 'c' in the restart function prevents
optimization even
if the linkage of 'c' will lead to erasure of the reinitialization
operation.
Workaround: Unset the 'default' value for the successor variable class
property
'RestartFunctionName' in the DataDictionary.
ID:
PR20061017-05
Title:
The generation of model-linked code view fails when

comments contains control characters

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: HTML generation of model-linked code view fails when the

HTML generator
encounters control characters in comments.
Workaround: Remove control characters from comments
939 / 1260
ID:
PR20061018-05
Title:
Value for CustomCode variable may be missing in DataDictionary Subsystem

area

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If a CustomCode variable uses a pool variable class with the property "Macro"
set to "on" and the variable has a value set in the block mask, then this value
does not appear in the DataDictionary Subsystem representation of the variable
after code generation (e.g. in won't appear in
DataDictionary>Subsystems/Name_Of_TL_Subsystem/Name_Of_TL_Module_Generated_For_
It/Variables/CustomCodeBlock_Variable->Value).
ID:
PR20061020-06
Title:
String containing ",", "{" or "}" will be split by XML

Import/Export and inplace edit of Data Dictionary Manager

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: A string is split, if it contains one of the following characters:

- comma ","
- left curly bracket "{"
- richt curly bracket "}"
If the user types in a string like the following, two strings split
at the ","
are inserted.
Example:
Original string: "This string is split, by accident."
Leads to string 1: "This string is split"
and string 2: "by accident."
The same applies to strings containing the characters "{" or
"}".
Workaround: Use another character for separation, for example ";".
This means for the example above: "This string is split; by
accident".
940 / 1260
ID:
PR20061023-09
Title:
Aborted code generation because style definition XSL file for

generated code cannot be opened

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the style definition XSL file is located in a folder that is in the
MATLAB
search path, but which is different to
%TL_ROOT%\Matlab\Tl\config\codegen, and
the file is specified via the TargetLink Main Dialog, then code
generation may
abort with the following warning and error message:
Warning #17108:
XSL warning: xml file is probably not well-formated. Line: 0, Col:
0 An
exception occurred! Type:RuntimeException, Message:The
primary document entity
could not be opened.
Id=%TL_ROOT%\Matlab\Tl\config\codegen\<StyleDefFIleName>
Fatal #17107:
An error occurred in processing XSL: mycconfig.xml could not be
opened. Please,
check if specified file name is correct or file exists!
Workaround: Set the style definition file via API command instead via the Main
Dialog:
tl_set(<model>t, 'codeopt.outputstylefile', <StyleDefFile>')
where <StyleDefFile> is the full file name including path.
ID:
PR20061025-01
Title:
Warning #19615 reported during code generation for FIR

Filter coefficients

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The warning #19615 "Due to the scaling of variable <var> its
initial value
<value> will become 0." is issued for a FIR Filter block, if both
of the
- the variable class of the coefficients is selected to be
"default"
- the accu width is equal to the delay line width.
Workaround: Switch to broader accu width or finer delay line width.
941 / 1260
ID:
PR20061030-09
Title:
Wrong code for a relational operation in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a relational operation is specified in Stateflow which has

- a single unsigned variable as one operand and
- a mathematical operation (e.g substraction) which can lead
to negative results
as second operand,
the code will be wrong for negative results of the mathematical
operation.
This problem arises, because TargetLink assumes, that the
result of the
mathematical operation fits into the variable of other operand.
This is a
general assumption. Whenever a single variable is compared
to an operation
result, TargetLink assumes that the result of the operation fits
the single
variable.
Example:
a - 50 <= b (a: Int16; b: UInt16; both of scaling 2-^3)
The pattern is generated as:
((UInt16)(((UInt16)a) + 65136)) <= ((UInt16)b)
The addition is correct representation of difference in two's
complement. But
the final cast to UInt16 leads to wrong results,
if the difference is negative, because instead of negative value
the difference
is interpreted as hugh positive value.
Workaround: Introduce an auxiliary variable for the result of the arithmetic
operation.
patches:
TargetLink 2.3.1p2
942 / 1260
ID:
PR20061101-03
Title:
Wrong code may be generated for Merge block in an enabled

subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are fulfilled, wrong code may
be generated
for a Merge block:
- A Merge block resides in an enabled subsystem X and
drives a Simulink Outport
of X AND
- The Simulink Outport has specified another initial value than
the Merge block
AND
- The Merge variable is not written during the execution of X.
Simulink behavior in this case:
X returns the initial value of the Simulink Outport when it is
executed.
TargetLink behavior in this case:
X returns the initial value of the Merge block when it is
executed.
Workaround: Specify equal initial values for the Merge block and the
Simulink Outport which
is driven by the Merge block.
943 / 1260
ID:
PR20061102-14
Title:
Generated code not compilable because C array for Look-up

Table is accessed using a floating point variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Using a LookupFunctionTemplate with a RecordLayout with

RecordLayoutEntries with
Addressing direct in the DataDictionary for a Look-Up Table
2D block in
combination with floating point data types for the column axis
may lead to not
compilable C code being generated by TargetLink, for
example:
Float32 Aux_F32;
....
Aux_F32_d = z_table[Aux_F32];
Using PageSwitching leads to a used RecordLayout with
RecordLayoutEntries with
Addressing direct immediately.
Workaround: Do not use float types for column in combination with a
RecordLayoutEntries for
AXIS_PTS_Y with Addressing direct or use pre-lookup and
index search blocks
instead of Look-Up Table 1D and 2D blocks.
944 / 1260
ID:
PR20061102-18
Title:
Graphical function output data associated with a pointer to

structure component leads to inefficient code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the output of a graphical function is associated with an

pointer to structure
component (a structure component which structure root has a
variable class scope
"ref_param"), the result should be returned via this variable
like in the
following example:
...
f(in1,in2,&s)
out = s.result;
...
void f(Int32 in1, Int32 in2, struct stype * ps)
{
...
ps->result = ...
}
But currently the following code is generated for such a
situation:
...
aux = f(in1,in2,&s)
out = aux;
...
Int32 f(Int32 in1, Int32 in2, struct stype * ps)
{
...
ps->result = ...
return ps->result;
}
The outpout is returned via return value and not as specified
with the pointer
to struct parameter.
Workaround: Set the variable class of the structure component to class with
scope "GLOBAL".
945 / 1260
ID:
PR20061102-19
Title:
No name ambiguity error for unmergeable Stateflow local

machine variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink currently generates only one structure variable for

a structure which
is defined in the Data Dictionary. If a component of such a
structure is
referenced from two different places this is merging of
variables, because the
same structure component is used at two different places in
the generated code.
Therefore the structure component has to be mergeable. If it's
not mergeable, a
name ambiguity error should occur (#17299).
In most cases TargetLink throws this error message. Only if
the one of the
places which refers to the structure component is a Stateflow
variable on
machine level no error is thrown, even if the component is not
mergeable.
Note: for TargetLink 2.0.x and 2.1.x this problem is described
by PR20061102-13,
but there also applies to non local machine variables.
946 / 1260
ID:
PR20061103-02
Title:
Uncatched name ambiguity if two unused Stateflow graphical

function outputs refer to the same pointer to struct component

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Normally a name ambiguity warning should be raised if two

variables (Stateflow
data or Simulink block variables) refer the same structure
component in the Data
Dictionary and if that component is not mergeable. But this
name ambiguity is
not detected if all of the following conditions are fulfilled:
1) The variables are Stateflow data with scope
"function_output" (graphical
function outputs).
2) All refer to the same DD structure component which is not
defined to be
mergable and the structure root has "ref_param" as variable
class scope.
3) The returned values of the graphical functions are not used.
TargetLink currently does not throw any error message. The
code may be wrong if further conditions are matched:
4) The two graphical functions call each other.
5) The calling graphical function writes to its output 'o', then
calls the other
graphical function 'g' and then reads its output 'o' like in the
following
example. The output variable of 'g' refers to the same pointer
to structure
component as 'o':
o = 1;
g();
output1=o;
947 / 1260
ID:
PR20061106-31
Title:
2D User Lookup Scripts do not work correctly for non-scalar

Min/Max when referencing Data Dictionary variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Trying to generate code for 2D User Lookup Scripts does not
work correctly for
non-scalar Min/Max when referencing Data Dictionary
variables. Code generation
aborts with an error E0000.
Workaround: Do not use vectorized Min/Max values for DataDictionary
variables, but scalar
values (the scalar value is used for each element of the table).
ID:
PR20061107-10
Title:
Not compilable code caused by an actual parameter of a

subsystem/chart that is called internally and externally

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A subsystem/chart is triggered with Trigger type "functioncall". The

subsystem/chart is called inside the TargetLink root system
and outside the TL
root system.
A variable with scope "ref_param" or "value_param" is
specified as an interface
variable of the subsystem/chart. Its variable class property
"ArgClass" is left
to default. In this situation TargetLink generates not
compilable code.
Workaround: Specify the variable class property "ArgClass" for every
variable with scope
"ref_param" or "value_param" inside the externally and
internally called
subsystem/chart.
948 / 1260
ID:
PR20061107-15
Title:
Different names and different number of plot windows when

logging Bus Ports using access functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: When using TargetLink Bus In/Outport Blocks whose

components are specified to be
accessed via access functions, logging of these bus
components results in
different names and a different number of plot windows during
simulation.
ID:
PR20061109-15
Title:
Autoscaling fails for blocks from the AUTOSAR library

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The Autoscaling Tool supports no AUTOSAR blocks. The

netlist creation ends with
the following error messages:
Unsupported SIMULINK block type 'TL_RunnableOutport'
Unsupported SIMULINK block type 'TL_RunnableInport'
Unsupported SIMULINK block type 'TL_Runnable'.
During all autoscaling steps error messages are displayed for
the unsuppored
blocks, the calculations for all other blocks are not affected
and executed
without problems.
949 / 1260
ID:
PR20061109-16
Title:
Autoscaling fails with fatal error F03468 if blocks with a non

scalar output scaled with simulation data

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The Autoscaling fails if all of the following preconditions a

given:
1. In the selected scope are blocks with non scalar outputs.
2. The Autoscaling is based on simulation data.
3. The Autoscaling is executed without a netlist.
Then the calculation ends with the Fatal error F03468.
Workaround: Use the Autoscaling with netlist and simuation data.
ID:
PR20061109-18
Title:
Chart triggered by multiple events leads to an error during

generation of simulation frame

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For a chart triggered via two or more different events

originating from outside
TargetLink, the simulation frame generation will fail, if these
event machine
variables have scope call-by-val/call-by-ref.
ID:
PR20061109-21
Title:
Stateflow action language: wrong precedence for shifts

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description:
The priority of left- and right-shifts in TargetLink is too high.

Use the following expression as sample:
o1 = i - 2 << 3;
The execution in MATLAB is like this:
o1 =(i - 2) << 3;
TargetLink executes the expression like this:
o1 = i - (2 << 3);
Workaround: Use brackets for specifing the correct execution order.
950 / 1260
ID:
PR20061109-24
Title:
Code size does not work for an AUTOSAR model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Checking code size does not work for an AUTOSAR model
(e.g. Target simulation
configuration SH2EEVB/HIT80, but the problem also occurs
with other Target
simulation configurations).
The following error occurs:
*** E00000: MAKE PROCESS ABORTED WITH ERRORS:
*** There was an error executing the command
***
*** dsmake.exe -f
C:\dSPACE\matlab\tl\SimFiles\SH2EEVB\HIT80\makefile.mk
CODESIZE=ON model=DCMC
app=DCMC target=SH2EEVB_HIT80
***
*** See MATLAB Command Window for details.
951 / 1260
ID:
PR20061110-01
Title:
Exported OIL file contains wrong accessname in accessor

definition

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If all of the following conditions are fulfilled the Data Dictionary
will
contain an incorrect AccessorNameTemplate:
- a Stateflow chart is specified to be an OSEK event triggered
task
- the Stateflow chart is triggered by multiple Stateflow events
- each Stateflow event is assigned to a separate OSEK event.
This may result in a wrong accessname in the exported OIL
file if the Stateflow
chart uses OSEK messages for intertask communication.
Workaround: Specifiy a Variable Class with scope global or static global
instead of default
(which is local) for the Sent/Receive Accessors of OSEK
messages if they are
sent/received by Stateflow charts which are triggered by
multiple OSEK events.
ID:
PR20061110-02
Title:
Wrong initial values for outputs of conditionally executed

subsystems

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink may uses wrong initial value outputs of

subsystem if
- the outport of the subsystem has no specified initial value
(i.e. '[]' as
'Initial output')
- the outport is driven by a subsystem's inport (i.e. there are
no or only
routing blocks between in- and outport)
Workaround: Specify an initial value at the subsystem's outports.
952 / 1260
ID:
PR20061110-14
Title:
Code generation may abort with error #17434 for Bus Port
blocks using a Variable Class with an Access Function
template

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If for the Variable Class of a structure or substructure defined

at a Bus Port
block a reference to an Access Function template is specified,
the code
generation incorrectly aborts with error #17434.
Workaround: Remove the reference to the Access Function template in the
Variable Class of
the (sub-)structure defined at the bus port block. Instead
specify for each leaf
component of the structure a Variable Class with the desired
Access Function
template.
ID:
PR20061110-16
Title:
Links in HTML file for the model-linked code view do not work
when response time of web browser is too long

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The Generate model-linked code view feature uses the

MATLAB web browser to
display the HTML for the model-linked code. This browser has
a timeout that
varies according to MATLAB release and that affects the
Generate model-linked
code view feature. If the time used to calculate and load the
linked Web sites
takes too long, the timeout is triggered and a message is
displayed (MATLAB is
unable to link to this URL:<LocalPath>/MenuVar).
Workaround: Switch to a newer version of MATLAB or try to reduce
response time by stopping
background processes.
953 / 1260
ID:
PR20061113-04
Title:
Error #19602 for bitwise operations of unscaled integer

operands

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a bitwise operation "OR", "XOR", or "AND" is used in

Stateflow as part of
another bitwise operation, the following error is thrown:
Error #19602
"Subsystem/Chart: TargetLink does not support bit operations
with two operands
that have nondefault scaling or are floating-point."
Workaround: Introduce an auxiliary variable that holds the result of the
bitwise operation.
ID:
PR20061115-01
Title:
Special characters in comments are not correctly displayed in

model-linked code view.

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If you use German umlauts or Japanese characters inside C

comments and generate
HMTL files for this code ? using the model-linked code view
feature - the HTML
presentation of the code does not contain this special
characters any more. They
are either missing or replaced by their ASCII representatives.
954 / 1260
ID:
PR20061115-05
Title:
Error #17073 for implicit created bus struct types that are not
merged if for one ore more components "Inherit Properties" is
active.

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Although two implicit created bus structs have compatible

struct types, it may
occur, that for the struct variables not the same struct type is
used if for one
ore more components "Inherit Properties" is active. This
problem occurs if the
inherited type and the type which has been specified for the
component before
"Inherit Properties" has been selected, differ and lead to a
different sorting
of the components inside the structure.
In this case the error 17073 is emitted.
Workaround: Specify the inherited type at the inheriting component.
ID:
PR20061116-01
Title:
Error #15064 reported because of erroneous scope reduction

of structures containing members with AccessFunctions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A struct member is configured to be accessed via access

functions or macros.
Its parent struct is reduced to TargetLink scope StaticLocal,
thus access via
access functions can no longer work and access via access
macros may no longer
work.
Consequently, Error #15064 is thrown.
However, the error information is not in all possible
constellations sufficient
to deduce the correct user action; this is such a case.
Workaround: Use a user variable class for the parent struct that is not
SCOPE_REDUCIBLE or
configure the scope reduction chain of the user variable class
to stop at
TargetLink scope StaticGlobal.
Alternatively, use only optimization level 0.
955 / 1260
ID:
PR20061117-08
Title:
Wrong default Variable Classes used in generated code for

Stateflow inputs and outputs

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Stateflow inputs and outputs may get SLGlobal as default

Variable Class instead
of SFGlobal (for inputs) resp. SFGlobalInit (for outputs).
Workaround: Manually assign SFGlobal(Init) Variable Classes to Stateflow
inputs and outputs
instead of using default.
ID:
PR20061121-08
Title:
SIL/PIL simulation fails for model with subsystems called from

extern

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If the following conditions are fulfilled the SIL/ PIL simulation
may not work:
- A function-call-triggered subsystem X is called indirectly*
from outside the
TargetLink Subsystem
AND
- X receives / sends data from / to the TargetLink Subsystem
border.
*indirectly means:
X is not called directly from outside the TargetLink Subsystem
but with a level
of indirection via one or more subsystems inside the
TargetLink Subsystem.
Workaround: No workaorund available.
956 / 1260
ID:
PR20061121-13
Title:
MATLAB may crash if deleting receive accessors of a

message variable via the Manage Messages Dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The problem may occur in the following cases:

1) If deleting the last remaining receive accessor of a
message variable in list
of at least three receiver accessors and not being in advanced
mode of the
Manage Message Dialog then MATLAB may crash.
2) If you select a receive accessor in the middle of a list of
receive accessors
in the Data Dictionary Manager and then delete this receive
accessor via the
Manage Message Dialog then MATLAB may crash.
Workaround: 1) Delete the receive accessors in the Data Dictionary
Manager and not via the
Manage Message Dialog or work in advanced mode of the
dialog.
2) Do not select those Data Dictionary objects in the Data
Dictionary Manager
which you want to delete.
ID:
PR20061122-04
Title:
Code generation aborts, if FIR filter code is to be inlined

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation is not possible for a FIR Filter block, if all of
the following
conditions hold:
- The FIR Filter block is located inside a subsystem for which
the generated
code can be inlined
- 'Inline Code' is selected for the FIR Filter block, while
"Generate Loops" is
not
Workaround: De-activate "Inline Code" in the FIR Filter block or activate
"Generate Loops"
or avoid inlining of the subsystem (e.g. by adding a function
block)
957 / 1260
ID:
PR20061122-05
Title:
Source file generated for AUTOSAR runnables has wrong

name

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the code file for a runnable block is specified as 'Controller',

the
generated file name will be 'controller.c'. The header will be
emitted
correctly.
ID:
PR20061122-06
Title:
Wrong code in simulation frame for extern global macro

accessible by an access function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If an interface variable of the production code root function is

specified as an
extern global macro accessible by an access function, the
corresponding frame
variable is defined twice in the target simulation frame file
(.TLSim\<subsystem>_pcf.c), for example:
Bool g_Fcn_b1ArgOut1;
Bool g_Fcn_b1ArgOut1;
This may lead to compiler or linker error while trying to build a
production
code simulation application.
Workaround: Prevent the specification as extern macro as well as
accessible by an access
function, e.g. specify the variable as extern alias.
958 / 1260
ID:
PR20061123-08
Title:
Missing cast for FIR Filter code may not be accepted by

compiler

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If "Generate Loops" is not selected for a FIR filter block, code
like
const Int16 * DelayLine;
Int16 * pDelayLine;
UInt16 * Counter;
pDelayLine = DelayLine + *(Counter);
is generated by TargetLink, where a cast is missing in the final
assigment. Some
compilers issue an warning about it, some issue an error
message, which makes
compilation impossible.
Workaround: Select "Generate Loops" for the FIR Filter block
959 / 1260
ID:
PR20061123-09
Title:
Model-Linked Code View generation is aborted if code

contains deeply nested if-else constructs

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In the context of Stateflow sometime deeply nested if-else

constructs are
generated by the TargetLink code generator. This can lead to
an internal stack
overflow of the parser transforming the code to HTML files. In
this case no HTML
file for the feature linking code and model is generated and
the following error
message shows up during code - more precisely - HTML file
generation.
It is not possible to generate an html file for the following
model:
Parser stack overflow at '*' in line <XXX>.
Please contact dSPACE technical support.
*** '<file>.c'
Workaround: Attributing the code with comments of the kind specified
below, the code will
not be parsed and the stack overflow can be avoided. To do
so encapsulate the
deeply neested included if-else-statements with the following
special comments:
/*#TL#Custom Code#TL#*/
<if-else-statement>
/*#TL#End Custom Code#TL#*/
Use the add-custom-code block or the code comment features
to ensure this
comments inside you generated code.
960 / 1260
ID:
PR20061124-07
Title:
Error #17257 reported during code generation for Stateflow

fixed point data element with default length and sign

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When using a data element with the data type "fixed point" in
a Stateflow chart,
the code generation with TargetLink may fail with the following
error message:
Error #17257: The data type 'error' is invalid for the variable
'xxx'.
This behaviour may occur under the following conditions:
- MATLAB R14SP3 (Stateflow 6.3) or higher is used and
- The resepctive data element has been newly created with
the MATLAB Model
Explorer without changing the default values for the properties
length and
signed.
Workaround: After changing one of the properties length or signed, the
code generation will
work. So for each new fixed point data element execute the
following steps:
- change the property signed to off.
- apply the changes.
- change the property signed to on.
- apply the changes.
961 / 1260
ID:
PR20061127-02
Title:
Struct component may be initialized with wrong value of 0 in

generated code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generated by TargetLink may initialize a struct

component with 0
although a different initial value has been specified if all of the
following
conditions apply:
- the struct component belongs to a DataDictionary variable
which has a variable
class with scope 'ref_param'
- the DataDictionary variable references a Typedef object
- the DataDictionary variable is passed as a parameter to an
incremental or
extern subsystem
- the struct component has an initial value different than 0
- the struct components variable has variable class with
'InitAtDefinition' set
to 'on'
- the component is not further used in the model
Workaround: Choose IMPLICIT_STRUCT for the DataDictionary variable or
use the struct
component in the model.
962 / 1260
ID:
PR20061130-04
Title:
Inherited arbitrary fixed-point scaling not converted during

Simulink to TargetLink conversion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: When converting a fixed-point Simulink model where some

block outputs are scaled
arbitrarily by inheritance, the arbitrary scalings are not
converted correctly
by TargetLink, i.e.
the output.lsb property is not set. "Arbitrary" means that the
LSB value is not
a power of two.
The error returned is:
Error #03051: aaal/bbb:
TargetLink datatype set to UInt16 (corresponds with Simulink
datatype
ufix16_Sp001234567890).
TargetLink LSB could not be set to 0.001234567890
(corresponds with Simulink
fixed point setting): TargetLink API error: New value for
property 'lsb' must be
a power of 2, because the arbitrary flag is 'off'!.
The problem comes only up if the arbitrary scaling is inherited,
i.e. not set
locally on block level. This implies that a Simulink Fixed Point
license is
available
and active.
Workaround: Open the block after conversion (use Open button in Message
Browser), and set
the output.lsb manually using the block's dialog.
963 / 1260
ID:
PR20061130-07
Title:
Initialization failures due to data type mismatches when using

stand-alone version of TargetLink blockset

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If the TargetLink blockset is used in stand-alone mode it might

happen that the
model cannot be initialized due to data type mismatches. The
reason is a wrong
evaluation of flag "Cast output signal to TargetLink type". Even
though a
suitable TargetLink data type is set the resulting data type is
different from
the expected one.
Workaround: Invoke TargetLink's upgrade routine tl_upgrade.
ID:
PR20061130-14
Title:
TargetLink Custom Code block variable names with more than

15 chars result in RTW errors

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If names of TargetLink Cuctom Code block variables

(properties output.varname,
input.varname, etc) exceed 15 characters, the mdlRTW
method in the generated
custom code S-function uses an abbreviated identifier as
opposed to the
associated TLC script, which uses the full version. This results
in TLC errors
when RTW code is being generated for the block, for
example:
Error: File: example_flp.tlc Line: 72 Column: 60 Unable to find
LongVariableNamePara within the SFcnParamSettings scope
Workaround: If RTW code should be generated for a TargetLink Custom
Code block, do not use
identifiers that exceed 15 characters for the block variables.
Alternatively,
correct the mdlRTW method in the custom code S-function
sourcecode file manually
and recompile it.
964 / 1260
ID:
PR20061201-02
Title:
Data Dictionary Manager tree view cannot be scrolled to the

end if a lot of objects are displayed

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If you open a Data Dictionary file in the Data Dictionary

Manager and this file
contains a lot of objects in one level (more than 5000 for
example) the tree
view on the left side of the Data Dictionary Manager displays
not all DD
objects. More precisely: The scrollbar is not sized correct and
so you cannot
scroll to the lowest objects in the tree view.
Workaround: No workaround available. You can only access the required
data via Data
Dictionary Matlab API.
ID:
PR20061201-07
Title:
Faulty code may be generated for Bus signals entering

subsequent subsystems without TargetLink Inports

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are fulfilled the codegenerator

may generate
faulty code:
- A BusInport / BusOutport block drives an unspecified*
subsystem inport AND
- The components of the BusInport / BusOutpost have
different scopes AND
- The unspecified subsystem inport receives the bussignals in
a changed order*.
*unspecified means:
The inport is a Simulink Inport without a specifying TargetLink
Inport /
BusInport.
*changed order means:
The output signals of the BusInport / BusOutport are mixed
up, for example by
using selectors or mux / demux blocks.
Workaround: Specify the unspecified subsystem inports via TargetLink
Inports.
965 / 1260
ID:
PR20061204-03
Title:
Missing DeclarationStatements/TypePrefix/SectionName for

reuse structs

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable class of an instance specific variable has the

properties
DeclarationStatements, TypePrefix or SectionName set, this
settings are not
taken into account for the declaration/definition of the struct
variable the
instance specific variable becomes part of.
ID:
PR20061207-01
Title:
Unnecesary ANSI-C or resp. incorrect TOM MPC5(5)xx/Diab

64-Bit code for multiplications is generated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When generating generic ANSI-C code for a model containing

a multiplication of
two integer variables, for example a product, square or gain
block, the model
is unnecessary calculated with 64-bit code. This problem can
only occur when the
scaling of the operands have offsets != 0.0.
Although the generated code is more inefficient due to the 64bit calculations,
the simulation results are correct.
But when trying to avoid these 64-bit operations and switching
from generic ANSI
to the TOM MPC5(5)xx/Diab CG with assembler extensions,
the generated code may
become compilable but incorrect. Incorrect calls of assembler
macros might be
generated, which leads only to warnings during compilation.
Example:
The TL2.1.6 generic ANSI code is:
/* Math: subsystem/Math1 */
Aux_S32 = (Int32) (((UInt32) (Int32) (((UInt32) ((((Int32)
Sa1_Relay_onoutput) * ((Int32) Sa1_Relay_onoutput)) /
((Int32) 203))) ((UInt32) ((((Int32) Sa1_Relay_onoutput) * 41672) / ((Int32)
483))))) 966 / 1260
((UInt32) ((((Int32) Sa1_Relay_onoutput) * 41672) / ((Int32)

483))));
if (Aux_S32 > -1431725) {
/* # combined # TargetLink outport: subsystem/OutPort */
Sa1_OutPort = 32767;
}
else {
if (Aux_S32 < -1497260) {
Sa1_OutPort = -32768;
}
else {
Sa1_OutPort = (Int16) (((UInt16) Aux_S32) + 1464492);
}
}
The TL2.2 generic ANSI code is:
Aux_S32 = ((Int32) Sa1_Relay_onoutput) * 41672;
Aux_S32_a = ((Int32) Sa1_Relay_onoutput) * 41672;
C__I64ADDI32I32(Aux_S32, Aux_S32_a, Aux_S32_b,
Aux_U32);
C__I32DIVI64U32(Aux_S32_b, Aux_U32, (UInt32) 483,
Aux_S32);
Aux_S32_a = (((Int32) Sa1_Relay_onoutput) * ((Int32)
Sa1_Relay_onoutput)) /
((Int32) 203);
C__I64SUBI32I32(Aux_S32_a, Aux_S32, Aux_S32_b,
Aux_U32);
C__I64ADDI64U32(Aux_S32_b, Aux_U32, (UInt32) 1464492,
Aux_S32_b, Aux_U32);
/* TargetLink outport: subsystem/OutPort */
Sa1_OutPort = C__I16FITI64_SAT(Aux_S32_b, Aux_U32,
32767 /* 61.49435716 */);
The incorrect TOM MPC5(5)xx code is:
AC__I64ADDI32I32(((Int32) Sa1_Relay_onoutput) * 41672,
((Int32)
Sa1_Relay_onoutput) * 41672, Aux_S32, Aux_U32);
C__I64DIVI64U32(Aux_S32, Aux_U32, (UInt32) 483,
Aux_S32_a, Aux_U32_a);
AC__I64SUBI32I32((((Int32) Sa1_Relay_onoutput) * ((Int32)
Sa1_Relay_onoutput)) / ((Int32) 203), Aux_S32_a,
Aux_U32_a, Aux_S32, Aux_U32);
AC__I64ADDI64I32(Aux_S32, Aux_U32, 1464492,
Aux_S32_a, Aux_U32_a);
/* TargetLink outport: subsystem/OutPort */
Sa1_OutPort = C__I16FITI64_SAT(Aux_S32_a, Aux_U32_a,
32767 /* 61.49435716
*/);
In this case the assembler macro AC__I64SUBI32I32 has a
wrong number of
arguments.
967 / 1260
Workaround: Specify constraint ranges as small as possible for the output

of the predecessor
block leading to the block representing the multiplication (e.g.
product, square
or gain).
ID:
PR20061207-02
Title:
Removed function call connection of ClientPort block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: When using the option "Show function call trigger port" of the
ClientPort block,
the connected function call line will be removed when
initializing the model.
Workaround: Do not use the option "Show function call trigger port" and
place the ClientPort
block into a function call triggered subsystem.
ID:
PR20061208-01
Title:
Incorrect code generated for Discrete Time Integrator with 64

bit state variable and finite limits with default Variable Class

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Incorrect, but compileable code is generated for the Discrete

Time Integrator
block if all of the following conditions hold:
- a 64 bit state variable is created, which is commonly forced
by a 32 bit
input
- finite limits are given
- the Variable Class of the limit variables is set to "default"
The scaling for the constants representing the limits is wrongly
calculated in
this case, which may also lead to wrong simulation results.
Workaround: Select any Variable Class different from "default" for the limit
variables, most
preferable "OPT_LOCAL".
968 / 1260
ID:
PR20061213-03
Title:
Specifying output of Custom Code block as "OPT_LOCAL"

may lead to wrong compilable code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Specifying custom code outputs as having a user variable

class with scope <
global my lead to wrong compilable code if the output itself
drives a
conditionally executed subsystem necessitating a global
interface variable and
another Custom Code block (as input); in this case, the
assignment of the output
to the interface variable may be erroneously moved into the
conditionally
executed code.
Workaround: There are several possible workarounds:
1) Make variable class of Custom Code block output "default".
2) Make variable class of Custom Code block output
''OPT_SCOPERED_MERGEABLE_GLOBAL", which is a copy
of "OPT_GLOBAL" with all
optimization attributes active.
3) Specify the input of the dependent systems via TargetLink
inport in order to
get different interface variables for the different signal lines
after the
split.
4) Use optimization level 0.
969 / 1260
ID:
PR20061214-08
Title:
PIL simulation with TSM MPC5554DEMO/GNU34 may abort

with the error #08152

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a PIL simulation is started using TSM

MPC5554DEMO/GNU34 an error #08152 may
be issued, e.g. like the following:
Error #08152:
Cannot find the symbol Arg_In_Out_a__b in
Build_D_RS_I2_MPC5554DEMO_GNU34.
The problem is caused by a defect in the GNU software, more
precisely, incorrect
map-file generation.
Study the following example. For some variables, which
names differ only in the
suffix:
Int32 Arg_In_Out_a_;
Int8 Arg_In_Out_a__a;
Int16 Arg_In_Out_a__b;
Float32 Arg_In_Out_a__c;
in the corresponding map-file the following entries can be
found:
Arg_In_Out_a_ 0x4
.\TLSim\D_RS_I2\MPC5554DEMO_GNU34\Subsystem_fri.obj
Arg_In_Out_a__a 0x1
Arg_In_Out_a(bool) 0x2
Arg_In_Out_a(char) 0x4
Therefore the TL map-file parser fails to find the symbols
Arg_In_Out_a__b and
Arg_In_Out_a__c.
970 / 1260
ID:
PR20061214-09
Title:
Documentation generation may abort after creation of EPS

image

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the Simulink preference option "Window Reuse" is set to

"replace" or "reuse",
the TargetLink model window is closed during the TargetLink
documentation
generation after an EPS images has been created. As a
consequence, the
documentation generation may fails when the model window
is needed again.
Workaround: Set the preference option "Window Reuse" to "none" or
"mixed".
ID:
PR20061215-01
Title:
Custom Code block's "decl" and "header" sections appear

multiple times if function is reused

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Custom Code block is placed inside a reused subsystem

and defines "decl"
sections and / or "header" sections the decl / header sections
appear one time
for each instance of the reused subsystem. This is not correct.
The decl /
header sections should appear exactly one time.
Workaround: Specify the decl / header sections of Custom Code blocks
inside reused
subsystems as "common" (use keyword "common").
971 / 1260
ID:
PR20061218-14
Title:
Model is not switched to MIL mode when opening in

TargetLink Blockset Stand-Alone mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a model is opened in TargetLink Blockset Stand-Alone

mode, it may happen that
the TargetLink subsystem is not switched to MIL mode
automatically. Starting a
simulation may throw an error like the following:
Error #02275:
The build object 'example/Build_example_HostPC_LCC'
cannot be found in the Data
Dictionary.
The build object with the name
Build_<application>_<Board>_<Compiler> is created
when the corresponding production code simulation
application is compiled.
The problem may occur if the model callback PostLoadFcn
contains comments. Due
to the fact that TargetLink appends own commands to
PostLoadFcn, these commands
are not executed, if the last line in PostLoadFcn is a comment.
Workaround: Avoid comments in the model's PostLoadFcn. If it is not
possible, please insert
a newline in the model's PostLoadFcn callback and a
command without any
operation, e.g:
%my comment
pause(0);
972 / 1260
ID:
PR20061219-09
Title:
Data Dictionary Manager window is not visible after starting it

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If the Data Dictionary Manager is used on computers with

changing resp. multiple
display devices, the startup position of the Data Dictionary
Manager window is
not reset and thus may be placed outside of the visible screen
area.
For example: If you have an additional display and move the
window of the
Manager to be visible on this display, close the Manager,
unplug the display and
restart the Manager, then the window may be invisible to you.
Workaround: To overcome this problem, delete the following registry
settings:
HKEY_CURRENT_USER\dSPACE\dsddman_<version>
entry: LeftUpperCorner_X
entry: LeftUpperCorner_Y
entry: Height
entry: Width
<version> can be ?1.4? for example.
You can use the command line tool ?regedit? to delete these
entries.
After these steps the DD Manager will start up in the upper left
corner of the
main display of your computer.
973 / 1260
ID:
PR20061222-08
Title:
Custom Code block's work variable cannot be initialized in the

common restart section

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Custom Code block's work variable cannot be initialized in the

common restart
section. This leads to an abort of code generation.
Workaround: Specify a variable which need to be initialized in the common
restart section in
the "decl" section of the Custom Code block (not as part of the
Custom Code
block's interface).
ID:
PR20061227-02
Title:
Typedef for Bool differs between dsfxp tl_types.h and generated

basetypes.h for SH-2 targets

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Generated basetypes.h defines Bool as signed char whereas the static
tl_types.h
used for DsFxp library uses unsigned char (for all supported SH-2 compiler
versions). Note: the DsFxp library does not use the typedef for Bool.
Workaround: Manually change Bool to unsigned char in
%DSPACE_ROOT%\Matlab\Tl\SrcFiles\SH2\Hit<version>\TargetConfig.xml.
ID:
PR20070102-02
Title:
The File Export utility ignores Source Files added via the
TargetLink Addfile Block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a TargetLink Addfile block with the option 'Compile and link
to production
code application' is used, the associated file is not exported by
the file
export utility.
Workaround: It is possible to write an M script placed in a
post_export_files_hook function
to copy files associated with TargetLink Addfile blocks.
974 / 1260
ID:
PR20070108-02
Title:
Wrong error message for table variable of the Look-Up Table

2D block, if the variable but not the value is defined in Data
Dictionary

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The table variable of a TargetLink Look-Up Table 2D block is

defined in the Data
Dictionary. The value of the variable isn't defined in the Data
Dictionary, the
value comes from the block.
If the Look-Up method "Interpolation-Extrapolation" is set and
the property
"Distances between table entries less than half of
implemented range" is set,
the following unnecessary error message is created by the
code generator:
Error #26008: torquemap/Look-Up Table (2D)
The Width property of the associated DD Variable object
specifies that the table matrix vector has (x, y) elements.
However, it has
actually ( x+1 , y+1) elements. (x an y are the size of the
x_axis and the
y_axis)
Workaround: Apply one of the following workarounds
- Enter the table value to the Data Dictionary variable object
<variable>.
Use ddv('<variable>') in the block dialog entry Table.
- Don't use a Data Dictionay variable.
- Disable the option "Distances between table entries less
than half of
implemented range"
- Don't use "Interpolation -Extrapolation" .
975 / 1260
ID:
PR20070109-02
Title:
Combination of scope reduction, function reuse and

assignment or Fcn block can lead to not compilable code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a vectorized input variable of an assignment block or of a

Fcn block can be
scope reduced and is also placed in a reused function, the
generated code may be
wrong. In this case the variable will be replaced by an auxiliary
variable and
the associated index
operation may be wrong.
For a constellation of the form
pS1->pS2->a[index_expression]
replacement of "a" by an auxiliary variable "Aux_" yields
Aux_[pS1]
instead of
Aux_[index_expression]
This leads to wrong, non-compilable code.
ID:
PR20070109-03
Title:
Code generation aborts, because Discrete State Space block

does not support matrices with non-external macro variable
class

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: As matrix elements are referenced by two indices, which can

not be handled by
macros, selecting a variable class with property "Macro" =
"on" and "Storage" !=
"extern" is not supported for the matrices of the Discrete State
Space block. A
check for this configuration is already implemented for the
block dialog, a
further check within the code generator is missing, the code
generator exits
with an exception.
Workaround: Select a variable class with "Macro" = "off" or set "Storage" =
"extern" and
provide a macro by your own.
976 / 1260
ID:
PR20070110-01
Title:
Strange error message given during extended XML file import of a

complete Data Dictionary as a subtree

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: When exporting a complete Data Dictionary file as extended XML file
from //DD0
and re-import this file as a child of //DD0 - and not into //DD0 - a rather
confusing error message shows up. Further the structure of the reimported Data
Dictionary file is not maintained.
Workaround: Import the complete Data Dictionary XML file into //DD0, e.g. use the
"Root"
property of the import instead.
OR
Create a DataDict object explicitly by the following workaround and
import to
file into this node:
dsdd('Clear','//DD2')
dsdd('save','//DD2','file','datadictEntry.dd')
dsdd('Load','//DD0','file','datadictEntry.dd')
%now import into this new node
dsdd('import','format','xml','mode','extended','Root','//DD0','file','ExtendedX
mlFile.xml')
ID:
PR20070111-03
Title:
Block parameters are not visible for manipulation in

ControlDesk

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Using the TargetLink Stand-Alone Blockset, variables that are

used as block
parameters are not visible for manipulation in ControlDesk.
Example:
- Given is a workspace variable MyGain.
- The variable is used as gain parameter of TL Gain block.
- The Simulink Configuration Parameters "Inline Parameters"
is enabled
- The variable MyGain is specified as "ExportedGlobal"
If the model is opened in TargetLink Standalone mode to work
with RTI, and the
model is build, the parameter is not visible in ControlDesk.
977 / 1260
ID:
PR20070111-04
Title:
Code generation aborts if legacy function script specifies a

pointer to a structure within a structure

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in a legacy function script (user look-up script) a structure is

specified
that contains a pointer to another structure, the code
generation aborts.
ID:
PR20070112-02
Title:
Missing optimization of unnecessary saturation statements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the range of a saturated variable is within the saturation

limits but the
limits and the range are partially or entirely negative, then the
superfluous
comparisons realizing the saturation are not optimized.
Example:
/* -8 <= a <= 8 */
if (a < -10) {
b = -10;
} else {
if (a > 10) {
b = 10;
} else {
b = a;
}
}
could be optimized to
b = a;
but is only optimized to
if (a < -10) {
b = -10;
} else {
b = a;
}
978 / 1260
ID:
PR20070112-03
Title:
Linker error while building a stand-alone S-function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The stand-alone S-function cannot be build for TargetLink

subsystem, if the root
function has formal function parameters.
The Standalone Model Manager or the corresponding API
functions
tl_build_standalone or tl_tl2rti issue a linker error similar to the
following
one:
<TLSubsystemName>_sfcn.obj : error LNK2001: unresolved
external symbol
Workaround: If possible use global variables as interface variables of the
root function
generated for affected TargetLink subsystem.
ID:
PR20070115-02
Title:
Code generation for Discrete-Time Integrator block aborts with

error E99003

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation for integrator block aborts with error
E99003 if all of the
- a RestartFunction is given for the variable class
STATIC_GLOBAL and
- for the Discrete-Time Integrator block the Forward Euler
integration method is
chosen and
- the input of that block is a 32bit integer type (signed or
unsigned).
Workaround: Avoid the combination of 32 bit integer input and Forward
Euler integration
method.
979 / 1260
ID:
PR20070115-06
Title:
Saturation statements may be omitted in generated code even

though option "Keep saturation statements" is enabled

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Saturation statements might be eleminated even though the

global option "Keep
saturation statements" is enabled, if one of the following
conditions holds:
- the input of a saturated block has a floating-point type or
- the output of a saturation block has a floating-point type or
- a saturated multiplication, division with a constant value is
specified or
- a saturated addition or subtraction is specified that does not
result in a
macro call.
I.e. this problem can come up, if TargetLink generates control
flow to handle
the saturation.
ID:
PR20070117-01
Title:
The validate and save buttons in Data Dictionary Manager do

not consider multi selected objects

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If multiple Data Dictionary objects are the selected in the

Object Explorer in
the Data Dictionary Manager and the validate or save button
is pressed inside
the toolbar, the following misleading error message is
displayed:
Error #05040: The specified object does not exist.
Workaround: Perform validation and file saving of DD objects only for one
object at the same
time.
980 / 1260
ID:
PR20070118-01
Title:
TargetLink's subsystem output connected to a Merge block is

always zero during SIL/PIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The output of the TargetLink subsystem connected to the

Merge block is always
zero during SIL/PIL simulation if following conditions hold:
- the TargetLink subsystem contains two or more function-call
triggered
subsystems, whereas the function call signals are driven from
outside the
- the outputs of these subsystems lead to a merge block
connected (only via the
TargetLink outport block) to the output of the TargetLink
subsystem
- the merge variable is directly assigned in both subsystem,
thus no production
code for TargetLink subsystem is generated
Workaround: The code generator must be forced to generate a production
code for the
TargetLink subsystem, where it is not necessary for the finaly
ECU application.
This can be achieved by:
- inserting a Function block in the TargetLink subsystem and
specifying there
the name of the C-module that is to be generated for the
- associating the merge variable with a Data Dictionary
Variable, whos Module
property is set to the name of the module containing the code
of the function
called subsystems
The module generated for the TargetLink subsystem will
contain only one empty
function, needed only for SIL/PIL simulation. It is not
necessary to link this
module to the final ECU application.
981 / 1260
ID:
PR20070118-02
Title:
Superfluous includes may be generated for extern or alias

macros

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink may generate superfluous includes if a variable

class is used that
has
- a unset Module property (Module property is empty)
AND
- Macro is set to "on" and Storage is set to "extern" OR
- Alias is set to "on".
ID:
PR20070118-03
Title:
Variable described as AXIS_PTS as well as as

CHARACTERISTIC in same A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
982 / 1260
Description: If the same variable is used as axis in a 1D Look-Up Table

block and as table
values in the another one, the generated A2L file is not
correct. It contains
for same variable two entries: the first one for AXIS_PTS and
the second one for
the CHARACTERISTIC. This is not allowed by the A2L
syntax.
Example:
LUT1: X-Axis: VarA; Table values: VarB
LUT2: X-Axis: VarB; Table values: VarA
A2L File:
VarA
...
/end CHARACTERISTIC
/begin AXIS_PTS
VarB
...
/end AXIS_PTS
/begin AXIS_PTS
VarA
...
/end AXIS_PTS
Multiple entries are created for VarA or VarB depending on
the sequence in which
the Look-Up Tables are evaluated by the A2L file generator. In
earlier versions
of TargetLink (2.0) multiple entries (CHARACTERSITIC and
AXIS_PTS) will be
generated for both variables.
Workaround: Create a dummy TargetLink subsystem for A2L file
generation. In this subsystem
copy dummy blocks whose outputs resp. parameters are
associated with CAL/DISP
variables for which the A2L file has to be generated. Connect
the outputs of
these blocks to a Terminator block and the inputs to a Ground
block.
To generate Look-Up Table entries for the example above
copy only one Look-Up
Table block in this subsystem and associate its axis and table
values as
desired, for example:: x-axis VarA, table value VarB.
Note:
it is not possible to describe both Look-Up Tables from the
example in one A2L
file!
Generate production code for such subsystem and afterwards
the A2L file.
983 / 1260
ID:
PR20070118-04
Title:
Incomplete check of cross-dependencies in Data Dictionary

level 4 validation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The level 4 validation of the Data Dictionary checks only a

subset of
cross-dependencies, e.g. references to non existing variable
classes are not
found.
Checks which are performed are for example:
- Checks, if the type property of a variable points to an existing
typedef
object.
- Checks, if the variable object <DDPath> has a LocalScaling
child object, but
the Scaling property refers another object.
ID:
PR20070118-07
Title:
Ports of subsystems in simulation frames are not connected

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: In rare cases it may happen that some ports of subsystems in

the simulation
frame are not connected correctly. The problem is indicated
by the following
error message:
get_param(hPort,'Line');
??? Error using ==> get_param Invalid Simulink object handle.
Error in ==> tl_connect at 555
hGround = get_param(hLine,'SrcBlockHandle');
An other indicator is warning of unconnected lines during the
simulation.
Workaround: The ports are correctly connected after resizing the subsystem
with the
unconnected ports. This can be done by looking unter the
mask of the TargetLink
subsystem. The unconneced ports can be found by red
marked signal lines.
984 / 1260
ID:
PR20070123-01
Title:
Problems with incremental code generation for Discrete-Time

Integrator block residing in a function-call triggered subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The following two problems may arise when using incremental
code generation for
a Discrete-Time Integrator block residing in a function-call
triggered
subsystem:
1) Although the incrementally generated code is fine,
TargetLink shows incorrect
simulation behaviour if a function-call triggered subsystem
contains a Function
block that has incremental code generation enabled and a
Discrete-Time
Integrator block. Access to a SystemTime-Variable is needed
for this kind of
configuration, but with incremental code generation this
information is not
correctly passed to the TargetLink simulation frame. When
accessing the
SystemTime-Variable the return value is always zero, which
results in wrong
output values for the Integrator block.
2) If the Function block with incremental code generation
enabled and the
Discrete-Time Integrator block is located in a different
subsystem which is
located deeper inside a function-called triggered subsystem,
the latter is not
recognized and the TargetLink Code Generator expects a
fixed sample time to be
given for the integrator. As this contradicts an inherited
sample time (-1)
needed for Simulink model initialization, model initialization
fails and thus
code generation is not possible.
Workaround: Do not use incremental code generation if a Discrete-Time
Integrator block is
(transitive) located inside a function-call triggered subsystem.
985 / 1260
ID:
PR20070124-02
Title:
Autoscaling of subsystems inside libraries maybe not possible

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The autoscaling tool handles subsystems inside libraries, if

the subsystem
- is not on the top most level
- contains TargetLink blocks, that have activate "calculate
scaling" at the
block data
- is selected for calculating.
Note
If the whole library block is selected for autoscaling and start
one autoscaling
action, the following message is dsplayed: "Autoscaling
method of ALL blocks in
current scope is set to 'No autoscaling'."
ID:
PR20070124-03
Title:
Error during PIL simulation with HCS12/S12X and Cosmic

compiler for a variable name containing "switch"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a variable name contains "switch", e.g. a variable named

"Sa1_Endswitch" then
running the PIL simulation with the HCS12/S12X and Cosmic
compiler fails with an
error like the following: "Cannot find the symbol
Sa1_Endswitch [...]".
Workaround: Change the variable name, e. g. "Sa1_Endswitch" to
"Sa1_EndSwitch".
986 / 1260
ID:
PR20070125-05
Title:
Name macro $L is evaluted like $B instead being replaced by

propagated signal name

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The name macro $L can be used for input variables of

Custom Code block and
Stateflow chart. If the input of the block/chart
- is directly connected to a Simulink Inport block and
- the signal name is propagated, because the line has no
signal name specified,
TargetLink fails to evalute the name Macro $L for input
variable. Instead using
the propagated signal name as replacement for $L, the name
macro is evaluated
like $B. This is wrong and can cause name ambiguities, if
more than one input is
given.
Workaround: - Specify the signal name directly on signal line that drives the
block.
OR
- Add a TargetLink InPort block between the Simulink Inport
Block and the Custom
Code block/Stateflow chart. The TargetLink InPort block must
have the virtual
property set in this case.
987 / 1260
ID:
PR20070126-01
Title:
TRC file generation of Standalone Model Manager exports

multiline descriptions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The description of a variable might be of multiple lines. It is

possible to
specify such descriptions in Data Dictionary (variable property
"description").
In a block dialog it is not possible. Nevertheless the multilined
description is
exported to TRC file without handling of line breaks. The entry
in the TRC file
looks like:
MyGain
{
type: flt(64,IEEE)
alias: "MyGain"
desc: "Description of MyGain
with new lines"
flags: PARAM
}
The TRC file parser is currently not capable to parse
descriptions with line
breaks. Thus an error is thrown when the file is processed e.g.
in CalDesk.
Workaround: Do not use line breaks in descriptions.
ID:
PR20070129-06
Title:
Use of predefined SystemTimer variable inside a nested

incremental system leads to code generation abort

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generation aborts, if the predefined SystemTimer

variable
(/Pool/Variables/RTOS/SystemTimer) is used inside an
incremental system that
itself is part of an incremental system.
Workaround: Switch off incremental code generation for the subsystem
where the SystemTimer
is used.
988 / 1260
ID:
PR20070129-09
Title:
Missing optimization due to inconsistent treatment of

SCOPE_REDUCIBLE and restart functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Scope reduction doesn't work for variables of a variable class

which specifies a
restart function.
Even if no restart function is generated or the variables aren't
used in a
restart function.
This holds for user variable classes and variable classes used
in templates.
Workaround: Specify the ScopeReducedClass along the downgrade chain.
For VariableClassTemplates, use the same variable classes in
the downgrade chain
as in the respective templates in order to make sure that the
code does not
change when this problem is corrected.
989 / 1260
ID:
PR20070129-14
Title:
Generated code incorrectly uses additional global auxiliary

variable instead of access function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Under one of the following conditions a superfluous global

auxiliary variable
may be created:
1) An unspecified Simulink Outport / Simulink Inport (Simulink
Inport / Simulink
Outport without a specifying TargetLink InPort / TargetLink
OutPort) is driven
by a block output whose static global variable X is accessed
via global access
function Y.
2) A specified Simulink Inport (Simulink Inport with a
specifying TargetLink
InPort) of of a function call triggered subsystem is driven by a
block output
whose static global variable X is accessed via global access
function Y.
In both cases an additional global auxiliary variable is created
(IF_*) although
the global access function Y could be used instead.
Workaround: Specify non static global scope for X.
ID:
PR20070130-04
Title:
Error message if a renamed basetype is selected in the

Relational or Logical Operator block dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Trying to select a renamed base type in the Relational block

dialog and in the
Logical Operator block dialog leads to the following error
message (here for a
renamed boolean type):
*** E00000: INVALID DATATYPE:
*** The current datatype
*** Bool
*** is not one of the currently defined Boolean types!
Workaround: This is only a problem of the dialog. If the error message is
ignored, the
renamed basetype is used in the generated code.
990 / 1260
ID:
PR20070131-01
Title:
Infinit loop in code generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The TargetLink code generator may encounter an endless

loop if
- a signal is fed into a bus
- the signal is also used in a feedback-loop
- the feedback-loop contains only bus capable blocks
This problem only occurs in MATLAB R14 and above.
Workaround: Place a non-buscapable block, e.g. a Gain block with gain
factor 1, in the
feedback-loop.
ID:
PR20070131-02
Title:
"Show output port" at Trigger port and Iterator port can cause
inefficient code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: "Show output port" at Trigger port and Iterator port can cause
inefficient code
because the actual range of the output is not taken into acount
for optimization
of the succeeding code.
Workaround: Insert a TargetLink InPort or a TargetLink OutPort behind the
"Show output
port". Enter Min / Max values according to the given situation:
- Trigger with "Trigger Type" = "rising": Min = 0; Max = 1;
- Trigger with "Trigger Type" = "falling": Min = -1; Max = 0;
- Trigger with "Trigger Type" = "either": Min = -1; Max = 1;
- Trigger with "Trigger Type" = "function call': Min = 0; Max =
2;
- For Iterator with "Iteration limt source" = "'internal": Min = 0;
Max =
<IterationLimit>;
- For Iterator with "Iteration limt source" = "external": Min = 0;
Max =
<max(first Iterator input)>;
- While Iterator with "Maximum numer of iterations" != -1: Min
= 0; Max =
<Maximum numer of iterations>;
- While Iterator with "Maximum numer of iterations" == -1: Min
= 0; Max =
<empty>;
991 / 1260
ID:
PR20070201-01
Title:
Combination of Relational/Logical Operator block and MinMax

block can lead to initialization error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: At the Simulink Relational Operator block output data types

different from
"boolean" can be selected (e.g. uint8). However, after
conversion to TargetLink,
these types are replaced by boolean types (e.g. uint8 by
Bool8). In MIL
simulation, the output signal data type is then either boolean
or double,
depending on the global model option "Implement logic
signals as boolean data
(vs. double)".
This can lead to initialization errors if the succeeding block
can not process
boolean input signal data types.
Workaround: - Insert Data Type conversion blocks after Relational block
- If possible, unselect "Implement logic signals as boolean
data (vs. double)"
option (however, this is a global option). This option as also
called "Boolean
logic signals" depending on used MATLAB version.
992 / 1260
ID:
PR20070202-03
Title:
Compiling of SIL/PIL simulation application may fail in case of

externally linked code files

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a model contains a Function block that is specified in the

following way:
- the selected "Step function class" has scope "extern"
- and in the "Code file options" a "C code file name" is
specified
- and in the "Code file options" the flag "Link external code" is
set
- and the externally linked code file is placed in a directory that
is not the
working directory
then TargetLink may fail to compile the SIL/PIL simulation
application although
before this directory has to be specified in the Data Dictionary
node
'Config/TargetLink' with the property 'SourceFileSearchPath'.
Workaround: Either place the code file into the working directory, or link the
code file by
using an Add File block instead of using the Function block.
ID:
PR20070205-03
Title:
Using a vectorial data element in Stateflow with variable class

of scope "local" may lead to an error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow data element of vectorial or matrix dimension,

that is
configurated with a variable class of scope "local", TargetLink
throws the error
message Error #20864.
Workaround: Select a non local scope for the variable.
993 / 1260
ID:
PR20070206-03
Title:
Task spanning state reset can cause data inconsistencies

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an enabled / action port triggered subsystem A with "States

when enabling" /
"States when action is resumed" set to "reset" belonging to
task / ISR X calls
directly / indirectly a non cyclic subsystem B belonging to task
/ ISR Y the
reinitialization of A requires the reinitialization of B. This may
lead to
inconsistencies of the state data of B because both X and Y
access to the state
variables of B.
Workaround: Follow one of the following suggestions:
- If possible, set the "States when enabling" / "States when
action is resumed"
settings of A to "held". This workaround changes the state
reset behavior of A
and B to "held".
- Create an enabled subsystem with "States when enabling"
set to "held" on the
top level inside B, set its enable condition permanently to "1"
(use a Constant
block) and have this helper system execute the contents of B.
This action will
break the "State Reset dependencies" between the root step
functions. This
workaround changes the state reset behavior of B to "held".
- Create an enabled subsystem with "States when enabling"
set to "reset" on the
top level inside B, connect its enable port to the enable source
of A and have
this helper system execute the contents of B. This action will
break the "State
Reset dependencies" between the root step functions. This
workaround changes the
state reset behavior of B due to the time of its state reset.
994 / 1260
ID:
PR20070206-04
Title:
PIL simulation fails with Error #02240 for HCS12/S12X

Cosmic compiler version 4.7.6 and newer

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For Cosmic compiler version v4.7.6 and newer the PIL
simulation does not run but
aborts with an error message:
Error #02240:
Host PC - simulation target communication error: unknown
command.
ID:
PR20070207-02
Title:
Code generaten aborts using PowerPC TOM with assembler

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation aborts when using PowerPC TOM with

"Assembler and C extensions",
for models which are containing the blocks "PreLook-Up Index
Search" and
"Interpolation (n-D) using PreLook-Up" with floating point
types for the axis
and the fixed point type UInt8 for the communication between
this blocks.
This problem occurs for following TOMs:
- MPC5XX/DIAB
- MPC5XX/GHS
- MPC55XX/DIAB52
Workaround: Don't use one of the PowerPC TOMs with "Assembler and C
extensions" in
combination with an "Interpolation (n-D) using PreLook-Up"
block with all data
type floating-point types in combination with a "PreLook-Up
Index Search" block,
which has all data types set to floating-point except the output
(output =
UInt8).
995 / 1260
ID:
PR20070207-05
Title:
Applying access functions icomplete information for the

SIL/PIL simulation in Data Dictionary output

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Only a write (set) access function for an interface variable

(output) is
specified. This variable is merged over serveral subsystem
borders. The
generated code is correct and compiled. But the simulation
frame can not be
build. The following error occurs in MATLAB command
window:
*** The number of the 'ReadAccessFcnName' properties
*** does not match the number of the 'WriteAccessFcnName'
properties.
done.
SIMULATION FRAME GENERATION FAILED
Workaround: Specify a corresponding read access function to complete
set/get pair.
996 / 1260
ID:
PR20070207-06
Title:
Code generaton aborts for vectors with different widths

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In situations where TargetLink generates the following code

on optimization
level 0, the code generator aborts with a LEDA exception for
optimization levels
> 0:
b[0] = a[0];
b[1] = a[1];
c[0] = a[2];
....
foo(b);
This happens typically if a vector signal is demuxed before
entering an atomic
subsystem.
Workaround: Change the variable class template for SlFcnInput to a global,
scope reducible,
erasable, and movable variable class.
If this works, then an alternate specific workaround can be
applied: For all
vector signals that are split, e.g. via demux, the signal line
containing the
start slice of the vector needs to be specified via TargetLink
inports when
entering atomic subsystems. Afterwards, the variable class
template is no longer
necessary.
997 / 1260
ID:
PR20070207-07
Title:
Replacement of vectors used in function interfaces

erroneously performed for vectors of different width

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In situations where TargetLink generates the following code

on optimization
level 0, the code generator erroneously replaces b by a for
optimization levels
> 0:
b[0] = a[0];
b[1] = a[1];
c[0] = a[2];
...
foo(b);
This happens typically if a vector signal is demuxed before
entering an atomic
subsystem.
In TargetLink 2.2, this may lead to abort of code generation.
Workaround: Change the variable class template for SlFcnInput to a global,
scope reducible,
erasable and movable variable class.
If this works, then an alternate specific workaround can be
applied: For all
vector signals that are split, e.g. via demux, the signal line
containing the
start slice of the vector needs to be specified via TargetLink
inports when
entering atomic subsystems. Afterwards, the variable class
template is no longer
necessary.
ID:
PR20070208-03
Title:
DATA-WRITE-ACCESS information incomplete in exported

AUTOSAR SWC-description file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a runnable contains multiple RunnableOutport blocks, the

exported AUTOSAR
SWC-description file does not list all the data that are written
by this
runnable. The list of DataWriteAccesses just contains a single
entry.
998 / 1260
ID:
PR20070208-04
Title:
Option "Use Prefix for AR-Elements" is ignored during export

of AUTOSAR SWC-description files

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the option "Validate on Export" is enabled in the AUTOSAR

SWC-description
file export dialog, the export ignores the setting of the option
"Use Prefix for
AR-Elements". In this case the generated AUTOSAR SWCdescription file does not
contain any prefix for the AR-Elements.
The same applies if the AUTOSAR SWC-description file
export is called via the
MATLAB API function dsdd('Export','Format','AUTOSAR',....).
ID:
PR20070209-02
Title:
Difference between output signal and logged signal if option

"Cast output signal to TargetLink type" is selected

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The calculation of block output is done with floating point

accuracy. The output
data type can be changed to a non-double data type via the
flag "Cast output
signal to TargetLink type". In this case it may happen, that the
output signal
value is modified by the cast (e.g. a calculated value 3.132 is
casted to 3).
But nevertheless the original calculated signal is logged. This
leads to a
difference between the signal of the block output and the
logged signal.
Although the output is of type other then double, the values
are logged as if
there are of double type.
Example:
- A product block's output is integer type
- The option "Cast output signal to TargetLink type" is enabled
- The output values are of integer type
Although the specification is done to get integer values, the
values are logged
with double type. Thus values like 0.5 are possible
999 / 1260
ID:
PR20070209-06
Title:
TargetLink S-R Flip-Flop and J-K Flip-Flop have output data

type double, although corresponding Simulink blocks have
type boolean

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The output of TargetLink S-R Flip-Flop block and J-K Flip-Flop
block is always
of type double.
The data type of the corresponding Simulink block depends
on the model parameter
"Boolean logic signal" or "Implement logic signals as boolean
data (vs. double)"
(depends on MATLAB version). If this parameter is "Off",
Simulink S-R and J-K
Flip-Flop blocks have output data type double - same as
TargetLink. But if it is
"On", they have data type boolean.
This may lead to problems during simulation or initialization
due to the
mismatch of data type.
Workaround: Set model parameter "Implement logic signals as boolean
data (vs. double)" to
"Off". In this case, TargetLink and Simulink blocks have output
data type
double.
Another workaround is not available.
1000 / 1260
ID:
PR20070209-07
Title:
Creating a vector Data Dictionary Variable object with the

Property Manager results in an invalid Width property

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: When a Data Dictionary Variable reference property (for

example,
output.variable) is set with the Property Manager and the Data
Dictonary
Variable object does not exist, the user is prompted if it should
be created. If
the user acknoledges with "yes", the Data Dictionary Variable
object is created
and receives the properties from the TargetLink block variable
(for example, the
output) which is being edited. However, if the width of the
block variable is >
1, i.e. the block variable is a vector, the Width property of the
DD Variable
object is set to [1 <width>] instead of <width>, which results in
code
generation errors.
Workaround: Correct the Width property manually after the Data Dictionary
Variable object
has been created.
ID:
PR20070209-09
Title:
AUTOSAR export crashes if the file dependency list is to long

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The export of the AUTOSAR SWC description file from the
Data Dictionary
Subsystem object may crash, if the dependency list of the Cmodule that
implements the runnables is to long, for example more than
30. The exact length
cannot be named, since it depends on the names of the
dependency files.
1001 / 1260
ID:
PR20070213-01
Title:
LCC linker error if path to compiler is in UNC notation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the location of the LCC compiler is given in UNC notation,

e.g.
\\machine\MATLAB\sys\lcc the linking process fails.
The list of linker files is passed to the linker as a file.
The file is generated by make tool, that generates absolute
paths for the
libraries. During this step the UNC path notation will be
corrupted and the
first backslash is replaced by drive letter of current drive. This
will result
in a linker error, cause the files are not found.
The error is like the following
LINKING PROGRAM ...
LINKING FAILED. See
.\TLSim\example\HostPC_LCC\example.err for details.
Could not locate
E:/machine/MATLAB_R2006b/sys/lcc/lib/kernel32.lib
Workaround: Please do not use UNC notation.
ID:
PR20070213-03
Title:
Truncated Japanese text is displayed in Property Manager

Block Explorer

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The Property Manager sometimes truncates text properties

(for example,
output.description) that is written with Japanese characters.
Truncation means
that the text is only partially displayed in the Property
Manager's Block
Explorer, although the block still keeps the complete text.
Workaround: Use block dialog or TargetLink API to enter TargetLink
description properties in
Japanese.
1002 / 1260
ID:
PR20070214-01
Title:
Trigonometric Function ACOS: SIL differs from MIL because

of overflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in a trigonometric function block the acos function is chosen

and
- the input is not floating point and
- the block's output is non floating-point and
- the input signal is less than -0.4
than SIL will be different from MIL.
ID:
PR20070214-04
Title:
Production code for sin/cos with 64/32 bit input and 16 bit
result calculates wrong results

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The production code generated for the Trigonometric Function

block calculates
wrong results, if all of the following conditions hold:
- the sin or cos function is chosen and
- the input width is 64 bit or 32 bit (64 bit can result from a
scale
transformation of an 32 bit input) and
- the output width is 16 bit.
1003 / 1260
ID:
PR20070215-06
Title:
Wrong production code may be generated for

addition/subtraction with saturation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When adding or subtracting two non floating point operands

with a saturated
result in some cases plausibility checks are generated that
may omit cast
operations. This problem can come up for a number of
constellations. In general,
most probably the target compiler will fix this problem so the
simulation will
be correct. So far, wrong calculation results didn't appeared
during product
test.
ID:
PR20070215-10
Title:
RTW code generation aborts for Look-Up Table block in

TargetLink Blockset Stand-Alone

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Using the TargetLink Blockset Stand-Alone, the RTW code

generation may abort for
a model which contains a Look-Up Table block where the
"Cast output signal to
TargetLink type" option is set.
Workaround: Please prevent using the option in Look-Up Table block.
1004 / 1260
ID:
PR20070215-13
Title:
Trigonometric Function ASIN/ACOS: Wrong saturation limits

in the exception code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If for a trigonometric function asin or acos

- exception code is generated and
- the blocks output is saturated and
- the implemented limits of the block are smaller than the
exception value
wrong code will be generated.
For instance values less than -1 for an asin function will
deliver -1.570796327.
If the output is saturated to e.g. -1 overflow will happen.
ID:
PR20070220-07
Title:
Wrong number of iterations output by production code for

subsystem containing For/While Iterator Block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a For or a While Iterator block has activated "Show Iteration

Variable" and
its "Show Iteration Variable" output is directly connected to a
Simulink outport
X then the blocks driven by X may read the wrong number of
iterations in the
generated production code.
Simulink behavior:
Driven blocks read <iteration limit>
TargetLink production code behavior:
Driven blocks read <iteration limit + 1>
Workaround: Insert a TargetLink OutPort before Simulink Outports which
are driven by outputs
of For / While Iterator blocks.
1005 / 1260
ID:
PR20070221-03
Title:
Stateflow variable is unnecessarily persistent

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable is used as a counter in a for-loop in Stateflow, like

COUNT in
for(COUNT = 0; COUNT < 10; COUNT++) {
TargetLink generates COUNT always persistent i.e. COUNT is
either global or
static local although it could be an automatic (e.g. local)
variable.
Workaround: If your are using Matlab R13 or below:
Choose "temporary" for the variable's Stateflow scope and
assign a TargetLink
variable class with scope local to the variable.
If your are using Matlab R14 and above:
No workaround available.
ID:
PR20070223-02
Title:
Data varianted variable appears twice in the generated code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A data varianted variable is generated correctly as a

component of data variant
structure. But it also appears as an unused, plain and
superfluous variable in
the generated code.
Workaround: - Activate the optimization level 1 or 2
- Select a variable class with optimization flag "erasable" for
the data
varianted variable.
1006 / 1260
ID:
PR20070226-01
Title:
Size of iteration variable generated for For / While Iterator

block may be insufficient

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a For / While Iterator block has set "Iteration Limit Source" to
"external"
and "Show Iteration Variable" to "off" then the datatype of the
iteration
variable is always Int16. An iteration value > 32767 will
exceed the implemented
range of the variable. This will lead to undefined behavior of
the generated
code caused by overflows. No warning is given during code
generation.
Workaround: Set "Show Iteration Variable" = "on" then the datatype of the
iteration variable
is defined by "Iteration Variable Datatype". Choose a datatype
with a sufficient
range, e.g. Int32.
1007 / 1260
ID:
PR20070226-04
Title:
Critical sections are not taken into account during optimization

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink erroneously moves variables assigned whitin a

critical section.
Example:
The specified code
float64 SignalXy;
void foo(float64 * myRefArg)
{
float64 MyTmpVar;
/* CriticalSection */
SuspendAllInterrupts();
MyTmpVar = SignalXy;
ResumeAllInterrupts();
*myRefArg = MyTmpVar;
}
is erroneously optimized to
void foo(float64 * myRefArg)
{
*myRefArg = SignalXy;
}
The variable MyTmpVar has assigned a variable class with
the optimization
attribute "ERASABLE". Nevertheless the code must not be
optimized.
Workaround: Use a non-optimizable "MyTmpVar" variable.
1008 / 1260
ID:
PR20070227-03
Title:
Trigonometric Function ATAN: wrong fixed point code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The generated code for the trigonometric function atan can
easily result in
wrong code, if
- the input is 32 bit wide and
- the fixed point range of the input exceeds 16 bit
or if
- the factor 1/ ( LSB(Input) * LSB(INPUT) ) cannot be
represented as 32 bit.
Workaround: Use 16 bit operands.
ID:
PR20070227-07
Title:
False negatives during Data Dictionary validation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a Data Dictionary variable object has

- a Boolean data type,
- a Value specified that is not empty, and
- the Min and/or Max properties set to NaN
level 4 validation throws an error (E06253), although this
configuration is not
invalid. Level 4 validation is always invoked prior to code
generation.
Min/Max properties are set to NaN when a Data Dictionary
variable is created
using the Property Manager or a TargetLink block dialog.
Workaround: Set the Min and the Max property of the Data Dictionary
variable object to empty
matrices, or to 0 and 1, respectively. Alternatively, ignore the
validation
errors.
1009 / 1260
ID:
PR20070301-04
Title:
Trigonometric Function TAN: wrong fixed point code using 32

bit input with offset

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If in a trigonometric function block the tan function is chosen

and
- the input datatype is 32 bit integer with offset
- and the LSB of block's output is less than 2^-14
SIL simulation differs in many cases from MIL simulation.
ID:
PR20070301-07
Title:
Trigonometric Function ATAN2: Wrong code is generated,

which limits its input range

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The generated code of trigonometric function atan2(In1, In2)

can result in wrong
code if
- the factor ( In2 * In2 ) / ( LSB(In1) * LSB(In1) ) cannot be
represented as
Int32.
Example:
In1 has LSB of 2^-9. The code give wrong results for input
abs(In2) > sqrt( 2^31 * (2^-9 * 2^-9) ) = sqrt(2^13) = 90.5
Workaround: Adjust scaling of first input or limit input range of second input
according to
formula given above.
1010 / 1260
ID:
PR20070301-08
Title:
BIND in connection with output reset can cause MIL/SIL

differences

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the following conditions are fulfilled TargetLink behavior

differs from
Simulink behavior:
- A Stateflow chart A has an outgoing event B.
- E is bound to a state C in A (with the BIND operator).
- E calls directly or indirectly a subsystem which has an
outport D with "Output
when disabled" set to "reset".
Simulink behavior:
The output of D is reset when C is left.
TargetLink behavior:
The output of D is heldt when C is left.
This is a TargetLink limitation. The mistake is that no warning
is thrown.
1011 / 1260
ID:
PR20070301-10
Title:
BIND in connection with state reset can cause MIL/SIL

differences

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the following conditions are fulfilled TargetLink behavior

differs from
Simulink behavior:
- A Stateflow chart A has an outgoing event B.
- E is bound to a state C in A (with the BIND operator).
- E calls directly ore indirectly a function subsystem D which
has "States when
enabling" set to "inherit".
- A is called directly or indirectly by an enabled / action port
triggered
subsystem which has "States when enabling" / "States when
action is resumed" set
to "reset".
Simulink behavior:
The states of D are reset when C is entered.
TargetLink behavior:
The states of D are held when C is entered.
This is a TargetLink limitation. The mistake is that no warning
is thrown.
ID:
PR20070301-16
Title:
Variable definition is omitted, although variable is used as

array index

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Stateflow variable "i" is used in a chart as an index of an

array "a" and
if the expression "a[i]" is used on the left side of an
assignment then
optimization doesn't recognize this use of the variable "i". This
may lead to
the removing of variable definition statement of "i" which may
lead to wrong
code.
Workaround: Assign a variable class to the index variable "i" which has
unselected ERASABLE
flag in the Optimization property.
1012 / 1260
ID:
PR20070302-15
Title:
Stateflow transition action flag may not be reset

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A required transition action flag may not be reset to get correct
Stateflow
semantic if following is modeled in Stateflow:
A complex transition with several junctions and parallel paths
which contains
several sequenced transition actions
Workaround: Use conditions actions instead of transition actions.
ID:
PR20070302-17
Title:
The event type "wakeup" is not supported in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When using the event "wakeup" in Stateflow, the TargetLink

throws the error
E20889 during code generation.
Workaround: The event "wakeup" has the same behaviour as the event
"tick". So the event
"tick" can be used instead of "wakeup".
1013 / 1260
ID:
PR20070305-11
Title:
Wrong code for data varianted Stateflow data inside init

functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Many of the Stateflow data are states. So they may be

reinitialized in init
functions. TargetLink currently does not support this state
reset if the state
is data varianted. Normally TargetLink throws limitation error
message #30082,
but if the state is a Stateflow data variable no error is thrown.
The init
function code is generated without data variants like in the
following example:
pVca_DV->TestVar4 = 3;
The default value of the Data Dictionary variable is used to
reinitialize the
state, not the currently active data variant value.
Workaround: Do not use data variant states which are reinitialized in init
functions.
ID:
PR20070305-16
Title:
Missing error message for trigonometric function TAN using

offsets

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If in a trigonometric function block the tan function is chosen

and
- the block's output is not floating-point and
- the block's output has an offset, which makes the
implemented range asymmetric
around 0
than error message Error #19521: "Found offset at the output
of a tan function.
This is only supported with unsigned data types to create a
symetric implemented
output range." should be displayed but instead SIL simulation
will be different
from MIL outside that range, that results from same data type
and LSB, but
offset = 0.
Workaround: Do not use an offset.
1014 / 1260
ID:
PR20070309-01
Title:
Model conversion fails, cause wrong TargetLink port was

inserted

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: During Simulink to TargetLink conversion of a subsystem in a

model (as opposed
to a subsystem in a library), TargetLink ports are inserted at
root level
Simulink ports. If a signal is a bus, TargetLink bus ports are
inserted,
otherwise, ordinary (non-bus) TargetLink ports. (If a signal is a
function call,
no TargetLink port is inserted).
In the use case described below, TargetLink inports are
inserted instead of
TargetLink bus inports, which results in error #3008 after
conversion
"Selected signal <signal> in <block> is not part of the bus
entering the Bus
Selector." ,
i.e.after conversion has finished, the model can not be
initialized and is thus
invalid.
The use case:
- a bus signal enters the subsystem to be converted.
- the port width of the associated Simulink inport is set to a
fixed value
instead of -1, which means inheritance. This implies that the
data types of all
bus signals are equal.
- the Bus Creator block that produces the bus resides in a
subsystem that
resides on the same hierarchy level as the subsystem to be
converted.
Workaround: Set port widths of Simulink inports that pass bus signals to -1
(= inherited).
Replace wrongly inserted TargetLink ports by TargetLink bus
ports.
1015 / 1260
ID:
PR20070312-03
Title:
During AUTOSAR file import base types are overwritten with

wrong properties

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The TargetLink base types are overwritten with wrong

properties during AUTOSAR
file import. For instance the property "Module" is set to
"Rte_Type" and
"BaseTypeRename" is set to "<.>", although these properties
are not specified in
the XML file.
Workaround: There is no workaround available for Data Dictionary 1.4.
With TargetLink 2.2.1 and Data Dictionary 1.4.1 this problem
does not exist any
more. For Data Dictionary 1.4.1 the new AUTOSAR master
DD template has to be
used for each AUTOSAR model.
ID:
PR20070313-01
Title:
Feedback loop with bus signals leads to error #20160

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If some signals of a bus signal are fed back into the same bus
and the feedback
loop only contains bus capable blocks TargetLink may abort
the code generation
with error #20160 "Selected signal for Bus Selector outport
<%i,n> not found".
Please refer to the Simulink manual for more details about bus
capable blocks.
This problem affects only MATLAB R14 and above.
Workaround: Place a non bus capable block, e.g. a Gain block, in the
feedback loop.
1016 / 1260
ID:
PR20070319-04
Title:
Wrong axis information in A2L file for reused interpolation

table

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If an Interpolation (n-D) using PreLook-Up block is used inside

a reused
subsystem with multiple instances the axis information may be
wrong in the
exported A2L file. Instead of a COM_AXIS only a FIX_AXIS is
exported, which may
be wrong.
ID:
PR20070319-05
Title:
Stateflow variables that have data variants are not exported to

A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a Stateflow variable is specified to have data variants, the

A2L export of
this variable fails. The variable is not exported into the A2L
file.
1017 / 1260
ID:
PR20070319-07
Title:
Wrong error massage during autoscaling of block with inherit

properties enabled

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Applying autoscaling using simulation ranges for blocks with

"Inherit
properties" enabled yields to following error:
Scaling not feasible: No simulation data available.
The error does not occur at worst-case autoscaling.
Workaround: The error message has no effect to autoscaling of other
blocks. Because the
affected block use property inheritance, its scaling properties
are not used.
So despite the error message, the autoscaling can be
performed for all scalable
blocks. Therefore ignore the error message.
1018 / 1260
ID:
PR20070320-01
Title:
TargetLink InPort or BusInport on root level may cause

downsampling of data

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A TargetLink InPort or BusInport on the top level of the

may cause an unwanted downsampling of the data which
passes the TargetLink
InPort or BusInport. This error may occur if:
- The TargetLink subsystem does not result in an empty
function
AND
- Behind the TargetLink InPort or BusInport the signal line
branches to a
subsystem which is executed by an own root step function.
Workaround: For each Simulink Inport which receives data from outside the
TargetLink
subsystem:
- Specify the Simulink Inport by adding a TargetLink InPort or
BusInport.
- Create a "One-to-One" connection to the border of the
- [only TargetLink 2.0.x] Add TargetLink InPorts to the newly
created Simulink
Inports on root level. Set variable class to "default". Set
datatype and scaling
as set at the succeeding TargetLink InPort.
- [only TargetLink 2.1.x or TargetLink 2.2] Do not add
TargetLink Inports or
BusInports to the newly created Simulink Inports on root level.
ID:
PR20070320-03
Title:
Missing entry for AXIS_PTS_REF in A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If for a pair of PreLook-Up Index Search block and

Interpolation (n-D) using
PreLook-Up block the output variable of the PreLook-Up Index
Search block gets
optimized (eliminated), the exported A2L file does not have an
entry for
AXIS_PTS_REF, because the two blocks are not linked inside
the Data Dictonary
ModelView area.
Workaround: Use Look-Up Table block instead.
1019 / 1260
ID:
PR20070320-06
Title:
Early return logic problems not detected in some cases

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: General Info:

In Stateflow, early return logic is performed to maintain state
consistency
after local event broadcasts. TargetLink does not support
early return logic. It
does, however, perform a static analysis to detect and warn
about possible
problems in this area. This analysis is designed to be very
conservative. It
completely ignores transition labels, for example.
Problem:
If an event broadcast inside a transition action is directed
(using the send
function) towards the parent state of that transition, in some
cases the
analysis fails to detect and warn about possible problems with
early return
logic.
Workaround: Use local events carefully.
1020 / 1260
ID:
PR20070320-07
Title:
Problem with incremental code generation for Rate Limiter

block residing in an enabled subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The following two problems may arise when using incremental
code generation for
a function containing a Rate Limiter block and residing deeper
in an enabled
subsystem:
1) TargetLink complains, if the sample time of the function
inport is set to
"inherited" and code generation aborts, although code
generation should be
possible.
2) Wrong code is generated, if a sample time is given at the
function inport and
the property "States when enabling" is set to "held" at the
Enable port. This
results in wrong simulation behaviour.
ID:
PR20070321-03
Title:
Simulink error message (TLDS error: Error -66) may occur during
MIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: It may happen in MIL simulation that an error message is thrown

similar to
following one:
Error in
'model/Subsystem1/Subsystem/Subsystem1/Subsystem/LogOp5'
while
executing C MEX S-function 'tl_logical_s', (mdlStart), at time 0.
MATLAB error
message:
TLDS error: Error -66.
This error may appear if a non-scalable TargetLink block (Logical
Operator,
Relational Operator, Sign, S-R Flip-Flop, J-K Flip-Flop) resides in
the same
model as a block with a vectorized output.
1021 / 1260
ID:
PR20070322-02
Title:
Components of extern structures do not appear in restart

functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a component of a structure, which is specified in the Data

Dictionary, shall
be reinitialized in a restart function (i.e. the property
RestartFunctionName in
the components variable class is set) and the root of the
structure is extern
(i.e. the root of the structure has a variable class with storage
'extern') the
component is not initialized in the restart function.
ID:
PR20070322-03
Title:
Warnings 15353 ... 15363 may be thrown unnecessarily

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The warnings 15353 ... 15363 (all of them due to additional
update operation(s))
may be thrown unnecessarily.
This is the case if the follow situations hold:
- An inport of chart or subsystem X is driven by an output of
another chart or
subsystem Y. Y is called directly or indirectly by X. The inport
of X and the
outport of Y are merged together (via variable class
MERGEABLE_GLOBAL for
example).
- An inport of chart or subsystem Y is driven by an output of
another chart or
subsystem X. Y is called directly or indirectly by X. The inport
of Y and the
outport of X are merged together (via variable class
MERGEABLE_GLOBAL for
example).
1022 / 1260
ID:
PR20070323-02
Title:
Long execution time on creating a build object, generation of

A2L file or compiling a production code simulation application

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: It may take a long time creating a build object, generating an

A2L file via
dsdd_export_a2l_file command or compiling a production
code simulation
application for SIL/PIL simulation. Additionally the size of the
XML file
generated by the symbol table parser, which contains the
symbol addresses, is
very large.
This happens if common modules are used in multiple
TargetLink subsystems or
subsystems configurated for incremental code generation. In
this case these
common modules are parsed multiple times by the symbol
table import.
1023 / 1260
ID:
PR20070323-04
Title:
Overflow of partially saturated assignment

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: For a block an overflow occurs and no warning is thrown if

hold:
- an assignment is created that is saturated only to the upper
limit and
- the input of this assignment is less than the lower limit of the
implemented
range
The same will happen if a large value is assigned to an output
that is only
saturated to the
lower limit.
Example:
A Constant block with the value 200 feeds an Int8 OutPort that
is saturated to
the lower limit.
Sa1_OutPort = -56 /* 200. */;
and no warning about the overflow will come up.
The code is not wrong, cause it represents exactly the
operation with given
values. It is a drawback, that no warning is thown to note that
this is possible
error-prone.
This problem may arise for the TargetLink OutPort, UnitDelay,
MinMax, Switch,
Abs, Multiport Switch and
Bus Outport.
Workaround: Saturate both limits.
1024 / 1260
ID:
PR20070323-05
Title:
Erroneous variable sharing for auxiliary variables in do-while

loop

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Variables that are accessed in condition of do-while loop, may

be erroneously
shared with variables accessed inside the do-while loop.
Example:
b = a;
do {
... = ... b ...;
...
d = ...
} while (d != 0);
becomes
Aux_ = a;
do {
... = ... Aux_ ...;
...
Aux_ = ...
} while (Aux_ != 0);
instead of
Aux_ = a;
do {
... = ... Aux_ ...;
...
Aux_a = ...
} while (Aux_a != 0);
Workaround: For a do-while loop originating from Stateflow chart:
Either calculate the loop condition first thing in the loop or
make sure that
all variables that are accessed in do-while conditions are of
non-ERASABLE user
variable class.
For do-while loops originating from a Simulink while iterator:
Make sure that all variables that are accessed in do-while
conditions are of
non-ERASABLE user variable class
Other workarounds:
- It may help to switch off extended variable sharing
- Optimization level 0 will prevent the error as well.
1025 / 1260
ID:
PR20070323-08
Title:
Getting property list of TargetLink Main Dialog fails

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The API command TL_GET can be used to obtain a list of all
property names of a
TargetLink block. Thereto the function has to be invoked with
a blockhandle as
sole argument. This method fails if the block is of type
or if the functions is invoked with a model handle as argument.
ID:
PR20070326-02
Title:
Simulation aborts if component of function argument struct is

initialized in init function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Given is a structure that is passed to a function via a pointer. If

a component
of this structure should be initialized in the init function, the
struct is also
passed to init function (via a pointer).
Due to the fact that the simulation frame does not take
function arguments into
account for init function, the simulation will abort with an error
message like
the following:
Fatal #02318:
An exception was detected at program counter position
0x1000135b while executing
production code.
Exception cause: Write memory access violation.
Address of inaccessible data: 0x1354.
Exception detected in attempt to evaluate the function
'INIT_Fcn' at simulation
time 0.
Workaround: Do not use the init function for a component of a struct that is
used passed to
a function via a pointer.
1026 / 1260
ID:
PR20070326-03
Title:
Make process aborts, because of undeclared struct identifier

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A struct variable is specified in the Data Dictionary and its

variable class has
scope "ref_param", ArgClass set to <empty>. For a struct
component a variable
class with a not-empty RestartFunctionName is specified. The
struct is passed as
a parameter to the root step function (pointer to struct).
In this case the generated code is not compilable. Any attempt
leads to an error
like the following:
.\TLSim\example\HostPC_LCC\Subsystem.err for details.
Error .\Subsystem.c: 113 undeclared identifier
'Arg_In_Out_a_'
Error .\Subsystem.c: 113 left operand of . has incompatible
type 'int'
2 errors, 0 warnings
Workaround: Set the ArgClass property for the variable class with scope
"ref_param".
An unspecified ArgClass lets TargetLink place the actual
parameter variable
definition inside the simulation frame file which is not part of
the production
code. Under the circumstances described in this report, this
variable is still
used inside the production code, leading to a linker error.
Specifying the
ArgClass informs TargetLink where the actual parameter is
located, either inside
the production code (ArgClass global) or inside an external
file.
1027 / 1260
ID:
PR20070329-01
Title:
Importing into a Data Dictionary build object may be aborted

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: On attempt to import the information about the ECU

application into the dSPACE
Data Dictionary's build object the parsing of a map file may be
aborted with an
error like following:
## Parsing the file application.map...
Error: The specified MAP file does not contain the section
information
or was not generated by Green Hills V800 linker !
This problem may very likely arise in case the modules the
ECU application is
built of are contained inside a library.
Workaround: Before invoking the import tool make sure that modules the
ECU application is
built of are not member of a library.
1028 / 1260
ID:
PR20070330-01
Title:
Generation of simulation frame files aborts

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The generation of simulation frame files may abort with an

error like the
following:
*** Internal Error:
output
signals.
*** Please conntact dSPACE technical support.
***
*** Function stack:
*** 1: dstabdlg (298)
*** 2: tl_main_dlg (78)
*** 3: i_ManageCodePage (529)
*** 4: i_GenerateCode (1241)
*** 5: tl_generate_code (574)
*** 6: i_GenerateFrameFiles (890)
*** 7: tl_generate_simulation_frame (213)
*** 8: tl_generate_prodcode_frame (232)
*** 9: i_IterateRootFunctions (429)
*** 10: i_ProceedWithFcn (730)
*** 11: FcnProceedWithFunctionInterface (1029)
*** 12: i_GetInterfaceVariableData (6746)
*** 13: i_GetRootConnection (4827)
*** 14: tl_get_root_connection (65)
*** 15: i_GetConnectionToRootInport (101)
*** 16: i_GetSourceSignal (310)
Workaround: There are several resons for that error. To clearify the case,
please contact
the TargetLink Support Team.
1029 / 1260
ID:
PR20070330-11
Title:
Code generation may abort on access functions with specified

codefile property

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is a model with both a TargetLink InPort and OutPort.

Code generation
aborts if following conditions hold:
- In both ports the same Data Dictionary variable is referenced
- This variable has a variable class with an access function
template specified.
- In the settings of this access function template a codefile is
specified.
The code generation aborts with an error message like:
Error #15036:
Name ambiguity of identifier for an access function. The
identifier <name> is
not unique, which means that access functions with the same
name would have been
generated.
Workaround: Unset the codefile property in the access function template
ID:
PR20070402-01
Title:
Reopen of Runnable block dialog is impossible with

inconsistent settings

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Runnable block cannot be reopened and an error appears on

the MATLAB command
window if
- the selected runnable does not exist and
- an event is selected and
- the changes are applied ignoring the pop up message
-- or -- a function call triggered event was selected and
- the selected events list is empty
Workaround: Please restart the model to edit the dialog again.
If you save the model, you have to substitue the runnable by a
new one.
1030 / 1260
ID:
PR20070403-01
Title:
Wrong RESERVED entry generated within

RECORD_LAYOUT in A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Within the RECORD_LAYOUT the RESERVED entry should

get info about the size (in
bytes) of the component in the table structure to be skiped.
For the size information following keywords can be used:
BYTE, WORD, LONG.
If the component is of the type Float32 or Float64, the A2L file
generator
creates following entries:
RESERVED FLOAT32_IEEE or
RESERVED FLOAT64_IEEE
This is wrong. A syntax error will be reported while parsing
such A2L file.
Following entries are to be generated:
RESERVED LONG --> for Float32 components to be skiped
RESERVED LONG
RESERVED LONG --> for Float64 components to be skiped
1031 / 1260
ID:
PR20070404-03
Title:
Wrong sample time error message for TargetLink subsystem

in multirate model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may abort with an error message E15553 if

all following
conditions hold:
- The TargetLink subsystem contains only extern called
subsystems, TargetLink ports (including also bus ports) and
Simulink ports
- No function shall be generated for the TargetLink subsystem.
This happens if at least two of the Simulink inports inherit
different sample
times by Simulink and if these Simulink inports are connected
to TargetLink
InPorts and/or BusInports.
Workaround: Move the TargetLink InPorts and/or BusInports from the
level into the function call triggered subsystems.
Or specify for each Simulink inport which is connected to a
TargetLink InPort
and/or BusInport an arbitrary but equal sample time.
ID:
PR20070410-01
Title:
Multiple sample times inside one TargetLink subsystem are

not supported for an AUTOSAR model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: In a TargetLink AUTOSAR model, multiple sample times

inside one TargetLink
subsystem are not supported.
Workaround: Place runnables with different sample rates into separate
TargetLink subsystems.
1032 / 1260
ID:
PR20070411-02
Title:
Replacement of intertask communication by access functions

not possible for BusInports and/or BusOutports

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When trying to use access functions instead of intertask

communication at the
border of the TargetLink subsystem the error #31686 is
thrown ("The
inport/outport is specified to be a non-message-receiving
inport but its block
variable does not form a well defined vector. This is not
allowed.").
Workaround: Replace the TargetLink BusInport and/or BusOutport by
several TargetLink InPorts
and/or OutPorts. Map each bus component to a separate
TargetLink InPort and/or
OutPort.
ID:
PR20070412-01
Title:
Faulty rounding behavior in For Iterator block driven by

Constant block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the "N" input of a For Iterator block (For Iterator block with
"Iteration
limit source" set to "external") is driven by an unscaled
constant (Constant
block with variable class set to "default") with a non integer
constant value
the For Iterator subsystem may be executed one time more
than in Simulink due to
different rounding behavior of Simulink and TargetLink.
Workaround: Enter an integer value as constant value in the block dialog of
the Constant
block if the constant block drives the "N" input of a For Iterator
block.
1033 / 1260
ID:
PR20070413-01
Title:
The using of code in the exit events in Stateflow charts may

lead to wrong code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The actual state A in a Stateflow chart can have a conditional

branch in the out
path to leave this state. If this branch have a default transition
and the
condition depends on a variable, that is changed in the exit
event of the state
A, then TargetLink may generate incorrect code which yields
to an incorrect
position for the exit event in the generated code file.
Workaround: Make the default transition also conditional inverse to the
other condition.
ID:
PR20070413-03
Title:
Model conversion detects muxed signal as bus

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During Simulink to TargetLink conversion, muxed signal are

sometimes treated as
bus signals. Consequently, the inherit scaling flag of
TargetLink Switch, Unit
Delay and Multiport Switch blocks that are connected to such
signals are set to
"on":
N03006 PARAMETER MAPPING
The inheritscaling property has been set to "on", because the
block is
connected up with bus signal(s).
OBJECT: Subsystem/Switch
Workaround: Reset the property "Inherit scaling" manually after conversion.
1034 / 1260
ID:
PR20070416-01
Title:
Incorrect overflow warning during autoscaling (worst-case

range calculation) of look-up table

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: An overflow warning may be thrown in "Calculate Autoscaling"

routine (worst case
autoscaling method), because tool compares the input of a
look-up table with
min/max table knots and not with implemented ranges.
ID:
PR20070416-02
Title:
Erroneous message during autoscaling with simulation ranges

and "inherit properties" active

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Autoscaling may leads to erroneous messages like "E03463:

Scaling not feasible:
No simulation data available."
This may occur if the following conditions hold:
- autoscaling with simulation ranges
AND
- netlist is used
AND
- "inherit properties" is active.
If the properties are inherit, there's no scaling needed.
Nevertheless during
autoscaling an error is thrown, if no simulation ranges are
available in such
block.
Workaround: Please rate, whether the scaling is not needed for the blocks,
where the error
is thrown. For instance if the properties are inherit, the error
can be
neglected.
1035 / 1260
ID:
PR20070416-04
Title:
Data Dictionary Manager may crash when switching to

another window

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: When the property "FilterCondition" of a SubStructTemplate

object is edited in
the property value list and one switch to another window while
the drop down box
of this property is still expanded, MATLAB may crash, which
leads to an abnormal
termination of MATLAB. If this happens MATLAB must be
terminated using Windows
Task Manager.
This problem may also occur if the property to edit is
- The last property in the property value
-- and -- an enum value property,
-- and -- the option show unset properties is disabled.
Workaround: Close the drop down combo box first - either by entering
return or clicking on
some part of the Data Dictionary Manager - before switching
to another
application.
ID:
PR20070416-05
Title:
Unspecific error F10007 when using EXTERN_MACRO for a

table map

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A variable class with "Storage" = "extern" and "Macro" = "on"

is not allowed for
the map structure of 1D and 2D look-up tables. However,
when using such a
variable class (e.g. EXTERN_MACRO), a very unspecific fatal
occures:
Contact dSPACE's
Workaround: Use a variable class which has set the property "Alias" to "on"
instead of a
variable class with "Storage" = "extern" and "Macro" = "on"
(e.g. EXTERN_MACRO).
1036 / 1260
ID:
PR20070416-06
Title:
COMPU_METHOD of the FORM type is not generated

correctly

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The COMPU_METHOD entry of the conversion type FORM is

not correctly generated.
The FORMULA_INV keyword is generated outside of the
FORMULA block:
For example:
/begin COMPU_METHOD
...
FORM /* ConversionType */
...
/begin FORMULA
"1/X" /* f(x) */
/end FORMULA
FORMULA_INV "1/X"
/end COMPU_METHOD
instead of:
/begin COMPU_METHOD
...
FORM /* ConversionType */
...
/begin FORMULA
"1/X" /* f(x) */
FORMULA_INV "1/X"
/end FORMULA
/end COMPU_METHOD
Workaround: On demand, via an M-Script. Please contact TargetLink
support.
ID:
PR20070417-03
Title:
SubStructTemplate filter property "VariableClass" does not

work with "StructSpec" = "FcnReuse"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Appliying a SubStructTemplate, the filter criteria property

"VariableClass" does
not work when the "StructSpec" property is set to "FcnReuse".
Therefore it is
not possible to filter a substruct within a reuse struct based on
the variable
class of the substruct.
1037 / 1260
ID:
PR20070418-04
Title:
Missing cast in look-up table functions, using page switching

or a look-up function template with record layout

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When look-up tables are used with similar properties, a

reusable function is
created for this blocks. To reuse this function it is not
necessary that the
variable classes of this look-up table blocks are the same. For
the default case
there is no missing cast, but if page switching or a lookup
function template
with a record layout is applied to generate the table data direct
into the map
structure (Addressing is DIRECT), in the generated code there
might be missing a
cast. This cast is only missing if variable classes with different
type
qualifiers are used in look-up table blocks for the same axis
variable. The
missing cast leads to a compiler error.
Workaround: For different Look-Up Table blocks only use variable classes
with the same type
qualifier for an axis variable if page switching is enabled or a
look-up
function template with a record layout (with the Addressing
properties value is
DIRECT) is used.
1038 / 1260
ID:
PR20070418-05
Title:
Simulink initialization error by TargetLink Rate Limiter block in

multirate model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a TargetLink rate Limiter block is used in a multirate model

the follwoing
Simulink initialization error may occur:
Illegal rate transition found involving '<subsystem>/Rate
Limiter' at input port
1 and '<subsystem>/Rate Limiter/Saturation' at output port 1.
A Rate Transition
must be inserted between them.
The sample rates between the Saturation and Rate Limiter
under the mask of the
TargetLink Rate Limiter block differs, because the Saturation
block is
calculted with a disrete sample rate and the Rate Limiter is
with a continuous
rate.
Workaround: Switch 'Simulation -> Configuration Parameters -> Diagnostics
-> Sample Time ->
Multitask rate transitions' to warning.
ID:
PR20070418-06
Title:
Outport of reused subsystem connected to an outport of

conditionally subsystem may cause fatal error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an outport of a reused subsystem drives an outport of a

conditionally
subsystem code generation may abort with a fatal error.
- Insert a Gain block with Gain value 1 behind the reused
subsystem.
- Set the variable class of the outport of the reused subsystem
to FCN_REF_ARG.
1039 / 1260
ID:
PR20070419-04
Title:
Values of LowerLimit and UpperLimit are not correct for

CHARACTERISTIC with COMPU_METHOD of type FORM

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In the generated A2L file the values of LowerLimit and

UpperLimit of
CHARACTERISTIC entry with COMPU_METHOD of
conversion type FORM are not correct.
They are always set to double minimum: 2.22507e-308 or
double maximum:
1.79769e+308.
Example:
calVar /* Name */
...
FormEQ116 /* Conversion of type FORM */
2.22507e-308 /* LowerLimit */
1.79769e+308 /* UpperLimit */
...
/end CHARACTERISTIC
Workaround: On demand, via an M-script. Please conntact TargetLink
support.
ID:
PR20070419-05
Title:
PIL simulation may fail if model contains many root and/or

incremental subsystems

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If there are many TargetLink root subsystems or incremantal

subsystems in a
model then the PIL simulation may fail at some point with a
communication error.
Workaround: In TargetLink Main Dialog > Options > Compiler options enter
Target compiler
option which disables using of simulation lists:
-UTL_LIST_FEATURE_SUPPORTED
1040 / 1260
ID:
PR20070419-12
Title:
Shift of floating-point variable in Sum block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink generates a shift operation of a floating-point

variable if following
holds:
A Sum block has
- only one negative input (list of signs "-"),
- the input is of floating-point type and
- the output is a scaled fixed-point type
Workaround: Use a Gain block with a gain value of -1 instead of the Sum
block or introduce a
Scale block to convert the input to fixed-point before feeding it
to the Sum
block.
ID:
PR20070419-13
Title:
Code generation aborts if busses with different Simulink data

types are fed into AUTOSAR Runnable Inports

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: To get a structure variable for the output of a Runnable Inport,

you have to fed
a bus into it. If the bus signal has different Simulink data types,
it is
possible to start a simulation in MIL mode, but it is not
possible to generate
code, because of a model initialization error.
For code generation, internaly an atomic subsystem is
inserted under the mask of
the Runnable Inport, which is different to the MIL simulation. It
is not
possible for a bus signal with different Simulink data types to
pass the Inport
of an atomic subsystem except in the following conditions:
- The bus is non-virtual, which is only possible for bus objects.
This is
currently not supported by TargetLink.
- The Inport of the atomic subsystem is followed by a Signal
Conversion block
with activated bus-copy option. This is currently not supported
by TargetLink.
Workaround: Data Type Conversion blocks can be used to unifiy the
Simulink data type of all
incomming bus signals of the Runnable Inport.
1041 / 1260
ID:
PR20070419-14
Title:
AUTOSAR export for structured types fails

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If data elements of AUTOSAR interfaces have a structured

type, the AUTOSAR XML
description of the interface is erroneous. It contains a wrong
type reference
that does not exist. There may also appear warning messages
about suspect Data
Dictionary data.
ID:
PR20070420-01
Title:
Initializations of variables in restart functions are not

encapsulated with preprocessor directives

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Initializations of variables in restart functions are not

encapsulated with
preprocessor directives. This is a current limitation which is
not documented in
the user manual.
A necessary consequence of this limitation is that variables
which are
initialized in a restart function will never be encapsulated with
preprocessor
control flow.
Workaround: If it is possible to prevent the initialization of the variable in the
restart
function (e.g. initialization at definition) the encapsulation of
other
statements where the variable is used (like initialisation etc.)
may be
possible, otherwise no workaround available.
1042 / 1260
ID:
PR20070420-02
Title:
INIT section of Custom Code block may be not in production

code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The INIT section of a Custom Code block on the top level of
the TargetLink
subsystem may not result in production code. This will cause
differences between
MIL and SIL simulation.
The INIT section of a Custom Code block only results in
production code if one
of the following conditions hold:
- The Custom Code block resides in an enabled or ActionPort
triggered subsystem
with "States when enabling" or "States when action is
resumed" set to "reset".
- The Custom Code block resides in the TargetLink subsystem
or in an incremental
subsystem whose Function block has activated the option
"Force init function".
If the Custom Code block resides in the TargetLink subsystem
the missing
production code INIT section may cause differences between
MIL and SIL
simulation.
Workaround: If a Custom Code block has an INIT section and resides in the
TargetLink
subsystem or in an incremental subsystem insert a Function
block and activate
the option "Force init function".
1043 / 1260
ID:
PR20070420-14
Title:
Superfluous code for Stateflow charts due to preprocessor

directives

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are fulfilled, superfluous code

is generated
inside codefragments which are encapsulated by
preprocessor directives (#if,
#ifdef, #if defined):
- Several preprocessor controlled subystems* drive the same
Merge block.
- One or more of the preprocessor controlled subsystems
contain a Stateflow
chart which outport drives the Merge block over an outport of
the subsystem.
- The preprocessor controlled subsystems exclude among
each other (only one or
none of them will result in compiled code).
The superfluous code consists of assignment operations with
the Stateflow chart
output variables on the left side. These assignment operations
are necessary
inside ordinary control flow constructs (due to the semantic of
the Merge block)
but are superfluous inside preprocessor control flow if a
situation described
above is given.
*preprocessor controlled subsystem:
- Subsystem triggered by a Preprocessor IF block
- Subsystem triggered by an If block which input arguments
have set
"UsePreprocessorIf" to "on" (variable class property).
- Enabled subsystem whose enable signal has set
"UsePreprocessorIf" to "on"
(variable class property).
Workaround: If the situation described above is given, insert a TargetLink
OutPort between
the Stateflow charts' output and the subsystem's outport. Set
variable class to
"default" and datatype and scaling equal to datatype and
scaling of the
Stateflow chart's output (TargetLink 2.2: activate "Inherit
properties" in the
TargetLink OutPort's block dialog). Alternatively insert a Gain
block with gain
factor 1, variable class "default" and datatype and scaling
equal to datatype
and scaling of the Stateflow chart's output
1044 / 1260
ID:
PR20070423-01
Title:
During optimization the backward propagation ignores content

of index operations

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The following example code pattern

Int16 i;
if (cond) {
b = a1;
} else {
b = a2;
}
i = c;
d[i-1] = b;
is "optimized" into
Int16 i;
if (cond) {
d[i-1] = a1;
} else {
d[i-1] = a2;
}
i = c;
which is wrong as "i" is evaluated before it's assignment.
Workaround: Use optimization level 0
Partial:
Simulink: Find all Assignment Blocks with dynamic index and
place a maximum
atomic subsystem around the block and the signal lines to
their respective first
two inputs.
Stateflow: Rearrange statements, calculate indices earlier.
ID:
PR20070423-02
Title:
Simulink to TargetLink conversion aborts

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
1045 / 1260
Description: A subsystem had been reconverted from TargetLink to Simulink using a

TargetLink
version 2.1 or 2.0. During this reconversion, TargetLink data had been
saved,
and TargetLink Port blocks replaced by TargetLink Dummy Port blocks.
The
TargetLink subsystem has at least one Bus Port block with more than
one signal.
A subsequent conversion back to TargetLink using version 2.2 aborts
with an
error message:
??? Error using ==> tl_sync_data
Bus components have been changed. Open the block and check all
settings, then
apply the consistent data to the block.
Error in ==> set_tlcg_data at 77
[data,extData,err,msg,attrString] =
tl_sync_data(data,maskType,get_param(block,'AttributesFormatString'));
%#ok
Error in ==> sl2tl>i_ReplaceBlocks at 2327
set_tlcg_data(h,data,1);
Error in ==> sl2tl>i_SL2TL at 840
[msgstruct,repcnt] = i_ReplaceBlocks( ...
Error in ==> sl2tl at 457
[m,bSuccess,options] = i_SL2TL(options);
Error in ==> tl_conversion_sl2tl_dlg>i_sl2tl at 448 [bSuccess,
modelMsgStruct] =
sl2tl( ...
Error in ==> tl_conversion_sl2tl_dlg at 71
varargout{1} = i_sl2tl(varargin{2});
Error in ==> ds_generic_dlg>i_ManageButton at 1690
userData =
feval(userData.callBackFcn,userData.buttonData(idx(1)).tag,userData);
Error in ==> ds_generic_dlg at 753
i_ManageButton(userData,actionIdx);
??? Error while evaluating uicontrol Callback.
Workaround: 1) Convert in TargetLink 2.1 or TargetLink 2.0, open the converted
model in
TargetLink 2.2, and have it upgraded.
2) Remove the Dummy Bus Ports prior to conversion in TargetLink 2.2.
1046 / 1260
ID:
PR20070423-03
Title:
Error during info file generation if Stateflow variables are

removed by code optimization

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If Stateflow variables are removed from the code generator

optimization, the
info file generation (tl_generate_info_file) throws the following
error message:
*** E05040: OBJECT NOT FOUND:
ans =
5040
Workaround: The optimization level of the code generator can be set to
zero. In this case
the Stateflow variable is not removed by optimization and the
info file
generation can be finished successfully. This workaround has
the disadvantage,
that the generated code is not optimized.
ID:
PR20070424-03
Title:
Data Dictionary Manager may crash during edit of

/Config/General/CharacterSet of old Data Dictionary file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When an old Data Dictionary created with Data Dictionary 1.1
(TargetLink 2.0) is
opened with a Data Dictionary 1.4 (TargetLink 2.2), it will be
converted. The
type of "CharacterSet" and "CharacterSetCodePage" is not
corrected and displayed
as "unknown type". If the user clicks on the value combo box
or if the context
menu "Open Editor" is chosen, the Data Dictionary Manager
shows assertions
and/or crashes. This applies to Data Dictionary files which are
not upgraded for
TargetLink 2.1.
Workaround: Run dsdd_upgrade within TargetLink 2.0.
1047 / 1260
ID:
PR20070502-07
Title:
Index search method not converted correctly during

TargetLink to Simulink conversion of Lookup Table block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The following scenario results in a faulty parameter mapping

during TargetLink
to Simulink conversion:
- a TargetLink Lookup Table block (1D or 2D) had been
converted from Simulink,
the original block was a Simulink Lookup Table (n-D) block
whose interpolation
method was "None - Flat", and the index search method
"Linear".
- this TargetLink block is converted back to Simulink, which
correctly results
in a Simulink Lookup Table (n-D) block. However, the index
search method is set
to "Binary" instead of "Linear".
Note:
"Binary" is the default search method for Simulink Lookup
Table (n-D) blocks.
Workaround: Set search method manually after TargetLink to Simulink
conversion.
1048 / 1260
ID:
PR20070502-12
Title:
Wrong code generated for latched inport if signal is fed back

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for a
latched inport:
- A Simulink inport X of a subsystem Y has activated option
"Latch input by
delaying outside signal"
- X is driven by an outport of a subsystem Z
- Z is called directly or indirectly by Y
- X is not implemented as "Call by value" or "Call by
reference"
Hint:
The generation of wrong code is indicated by the warning
message #15353
("<block> Performance warning: Additional update
operation(s) required, caused
by specification of own inport variable") if <block> is a latched
inport.
Workaround: - Insert a TargetLink InPort behind the latched inport.
- Select a variable class with "Scope" = "value_param" or
"ref_param".
ID:
PR20070502-20
Title:
Detach of struct members and elimination of instance specific

struct do not work for too many struct variables of the same
type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the same struct type T is used multiple times, then detaching
struct members
from their parent struct (i.e. replacing them by a local auxiliary
variable) may
take place no longer if an additional struct variable of type T is
added to the
struct.
This problem may arise for function reuse and pointer-to-struct
variables.
Workaround: No general workaround available. Maybe the use of different
types reduces the
number of variables of same type in the struct.
1049 / 1260
ID:
PR20070503-02
Title:
Code generation aborts if vector of struct is used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Currently TargetLink does not support the usage of user

defined vectors of
structures.
If a vector of a struct is used as substructure in another struct
and none of
the components of the substructure is used, code generation
might abort with an
internal error like:
Fatal #10020: An internal error (LEDA exception: array::entry
index out of
or
Contact dSPACE's
Workaround: Do not use vectors of structures.
ID:
PR20070503-06
Title:
Differences between MIL and SIL for a J-K Flip-Flop block in

an enabled/triggered subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Given is a TargetLink J-K Flip-Flop block that resides in a

triggered subsystem
which is located in an enabled subsystem. In enabled
subsystem the Enable block
parameter "States when enabling" is set to "reset".
In this case a MIL simulation leads to the following wrong
simulation behavior:
If the enabled subsystem changes from Disabled to Enabled
the J-K Flip-Flop
block calculates a new value for output Q without a falling
edge at the CLK
input signal. The calculation of Q on enabling is wrong, cause
it's done without
taken the edge into account.
1050 / 1260
ID:
PR20070508-04
Title:
Warning #20681 wrongly emitted if a Data Store block is

connected to the External Source input of a Discrete Time
Integrator block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Warning #20681: Subsystem/Discrete-Time Integrator The

state's external
initialization value could not be determined. Using zero as
initial value.
is wrongly emitted for a Discrete Time Integrator block with a
Data Store Read
block connected to its External Source input, although
- the Data Store Memory block is well configured and an
initialization value is
given
- the Discrete Time Integrator is initialized with the initial value
of the Data
Store Memory block, but not with Zero in the generated code
Workaround: Ignore the warning.
ID:
PR20070508-07
Title:
Uncompilable code when using an ArgClass at an incremental

subsystem's interface

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If you specify an ArgClass in the variable class of an interface

variable of an
incremental subsystem and the ArgClass has the
RestartFunctionName property set,
then the code generator creates two reinitializations: one
when generating code
for the incremental subsystem and the other when generating
code for the outer
subsystem. The generated code couldn't be compiled when
the specified variable
has no global scope.
1051 / 1260
ID:
PR20070509-14
Title:
CodeSize calculation for HCS12/S12X/Metrowerks does not

count initialized global variables for ROM value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Initialized global variables take up space in RAM and ROM, as

the latter holds
the initial values, which the CodeSize calculation for
HCS12/S12X with
Metrowerks compiler does not take into account. It only adds
the size for this
variables to the RAM size but omits it for the ROM. Thus the
calculated ROM size
is too small if the generated production code contains
intialized global
variables.
ID:
PR20070510-12
Title:
Wrong code for Relay block with static output variable and
calibratable on/off values

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the output variable of the Relay block has scope "static
local", "static
global" or "global" and the output values ("Output On", "Output
Off") are
calibratable, modifications of "Output On" / "Output Off" only
take effect after
the switch points ("Switch On", "Switch Off") are reached.
Modification of
"Output On" takes effect after "Switch On" has been reached.
Modification of
"Output Off" takes effect after "Switch On" has been reached.
- Select a variable class with "Scope" = "local" and "Storage" =
"default" for
the Relay block's output variable.
- If you need a global output variable (e.g. for enable access
by calibration
tools) insert a Gain block behind the Relay block, set Gain
factor to 1 and
choose the variable class you need for the Gain block's output
variable.
ID:
PR20070510-22
1052 / 1260
Title:
Wrong cast leads to quantization error in saturated Abs block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Consider an Abs block whose output is saturated.

If the output of the predecessor block has a variable class with
"Scope" =
"Global" and "Info" != "None", wrong casts are generated. This
leads to wrong
SIL and PIL simulations, because quantization error always
yields to zero value.
Example:
Wrong code with the UInt8 casts if the variable class of the
driving signal in
the Abs block is DISP ("Scope" = "global" and "Info" =
"readonly"):
/* Abs: Subsystem/Abs_DISP */
if (Sa1_InPort >= 0) {
/* Subsystem/Abs_DISP: Omitted upper saturation
Subsystem/Abs_DISP: Omitted lower saturation
# combined # Sink: Subsystem/Sink_out_DISP */
Sa1_Sink_out_DISP = (Int16) (((UInt8) (Sa1_InPort << 7)) /
125);
}
else {
/* Subsystem/Abs_DISP: Omitted upper saturation
Subsystem/Abs_DISP: Omitted lower saturation
# combined # Sink: Subsystem/Sink_out_DISP */
Sa1_Sink_out_DISP = -((Int16) (((Int32) (((Int32) Sa1_InPort)
<< 7)) /
((Int32) 125)));
}
Compared to the correct code using variable "Class" =
"default":
/* Abs: Subsystem/Abs_default */
if (Sa1_InPort1 >= 0) {
/* Subsystem/Abs_default: Omitted lower saturation */
Aux_U32 = (UInt32) (((Int32) Sa1_InPort1) << 7);
if (Aux_U32 > 4095875) {
/* # combined # Sink: Subsystem/Sink_out_default */
Sa1_Sink_out_default = 32767;
}
else {
Sa1_Sink_out_default = (Int16) (Aux_U32 / 125);
}
}
else {
/* Subsystem/Abs_default: Omitted lower saturation */
1053 / 1260
Aux_U16 = (UInt16) (-(((Int32) (((Int32) Sa1_InPort1) << 7)) /

((Int32)
125)));
Sa1_Sink_out_default = C__I16FITU16_SATu(Aux_U16,
32767 /* 31.99902344
*/);
}
Workaround: Do not feed any global or static variable, where the "Info"
property is set
(e.g. != "None"), in an Abs block whose output is saturated.
ID:
PR20070514-07
Title:
Creation of Data Dictionary variable with Property Manager

results in invalid Data Dictionary variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: A Data Dictionary variable object can be created by the

Property Manager when a
.variable (for example, output.variable) property is set to the
name of a Data
Dictionary variable object that does not exist. In this case, the
user is
prompted if a new Data Dictionary variable object with the
specified name should
be created. If confirmed, this variable object receives
properties from the
block variable (for example, the output) that is being edited.
The new Data Dictionary variable object is invalid when
- the block variable has a LSB != 2^0 and/or offset != 0.0
- its data type is a basic integer type
In this case, a ./LocalScaling object must be created that
defines the
variable's scaling. Nevertheless, the variables's "Scaling"
property is set to
./LocalScaling, which results in an invalid reference and an
error message
during subsequent level 4 Data Dictionary validations:
Error #05040: The reference path "./LocalScaling" of reference
property
"Scaling" could not be resolved.
Workaround: Correct Data Dictionary variable object manually with Data
Dictionary Manager.
1054 / 1260
ID:
PR20070516-09
Title:
Initialization problem when using SWC sender and/or receiver

port with bus signals

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In a model a SWC sender and/or receiver port is used with

bus signal which
connects two TargetLink subsystem. It is not possible to
simulate in SIL mode.
The simulation is aborted with the following message:
Initialization commands cannot be evaluated. MATLAB error
message: Bus
components have been changed. Open the block and check
all settings, then apply
the consistent data to the block.
Workaround: Initialize model manually by update diagram (Strg+D) before
starting a
simulation.
ID:
PR20070521-02
Title:
AUTOSAR Runnable port modifies non-double Simulink data

types

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Modelling with AUTOSAR Runnable port can cause problems

with non-double Simulink
data types. The AUTOSAR Runnable port has pass-though
behaviour in MIL mode,
which means that the incoming signal data types should be
left untouched. During
code generation a TargetLink InPort is inserted under the
mask of the Runnable
port to reflect the interface specification. This TargetLink port
contains a
S-function which casts all non-double types to double.
This may effect that the model cannot be initialized for code
generation.
Workaround: Use a Data Type Conversion block to correct the data type.
1055 / 1260
ID:
PR20070521-04
Title:
Cascaded Merge blocks may cause incorrect errors and/or

warnings

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Specifying the block variable properties of a Merge block

inside a cascade of
Merge blocks may cause incorrect error and/or warning
messages, e.g. about name
abiguities.
Workaround: Do not specify block variable properties of a Merge blocks
inside a cascade of
Merge blocks. Leave all settings in the block dialog at their
default values.
Notice:
Merge blocks inside a cascade of Merge blocks do not result
in a variable in
production code. Only the Merge block on the end of a
cascade of Merge blocks or
a single Merge block (without cascade) results in a variable in
production code.
So it makes only sense to specifiy the properties of Merge
block cascade's last
Merge block or of single Merge block.
1056 / 1260
ID:
PR20070521-09
Title:
New Simulink Pre Look-up blocks cannot be converted to

TargetLink

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: With Simulink 6.5 (MATLAB R2006b), new pre look-up table
blocks (Prelookup and
Interpolation Using Prelookup) have been introduced that offer
additional
functionalities. These blocks cannot be converted to
TargetLink. Attempts to
convert result in an error message:
Error #03001: example/Subsystem/Prelookup:
PreLookup block is not supported by TargetLink and no
corresponding block is
defined.
Workaround: 1) Design TargetLink Custom Code block with the same
functionality and have the
pre look-ups replaced by instances of this block. This
approach requires
considerable development efforts.
2) Use the previous Simulink pre look-up blocks, they are still
available,
although might become obsolete in future Simulink versions.
1057 / 1260
ID:
PR20070523-06
Title:
Creating a variable in Data Dictionary and in Property

Manager does not yield the same result

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Creating a variable in Data Dictionary and in Property

Manager does not yield
the same result
Example:
TargetLink Constant block whose value (specified with the
output.value property)
is a vector. If a Data Dictionary variable object is created for
that constant
using the block's dialog, its Width property is not set correctly:
1) If the output.class property is "default", it is set to an empty
matrix, i.e.
not set at all.
2) Otherwise, the Width property is set according to the
block's output.width
property even if output.width does not match the size of the
value.
In both cases, Data Dictionary level 4 validation throws an
error since the Data
Dictionary variable's Width property is incompliant with the
Value property.
However, if the Data Dictionary variable is created with the
Property Manager,
the Width property is set according to the constant value.
Workaround: Use the Property Manager to create Data Dictionary variable
objects whose
properties reflect the settings of a block's variable.
1058 / 1260
ID:
PR20070524-08
Title:
For a Discrete-Time Integrator block an external reset in the

second simulation step is ignored

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code generated for a Discrete-Time Integrator block with

an external reset
port does not recognize a reset condition occuring in the
second simulation
step. On all other simulation steps an occured reset will be
handled correctly.
patches:
TargetLink 3.2p4
1059 / 1260
ID:
PR20070524-10
Title:
Simulink to TargetLink conversion aborts processing Shift

Arithmetic block (Bitwise Logical Operator)

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Given is a TargetLink subsystem that contains a TargetLink

Shift Arithmetic
block, which is a customized TargetLink Custom Code block
originating from
TargetLink's samples. In order to replace Simulink blocks that
had been
inserted, this subsystem should again be converted to
TargetLink, although it is
already a TargetLink subsystem. However, Simulink to
TargetLink conversion
signals an error:
Error #02012:
There is a syntax error in the user-defined hook function
MATLAB interpreter error message was:
.....................................
Error using ==> set_param
TLSAMPLES_BW_LOGICAL_OPERATOR block (mask) does
not have a parameter named
'nBitShiftRight'.
Error #03006: example/ ... /Shift/Shift Arithmetic:
Error in conversion callback function
tlsamples_bw_logical_operator
Nevertheless the subsystem is converted correctly.
ID:
PR20070524-19
Title:
Code genration aborts if an access function is assigned to a

Look-Up Table parameter

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Usage of an access function is not allowed for any Look-Up

Table parameter.
This is a limitation of TargetLink.
1060 / 1260
ID:
PR20070524-31
Title:
AUTOSAR export overwrites package files

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a model contains two or more TargetLink subsystems that

refer to the same
AUTOSAR package, during each code generation step for
one of these TargetLink
subsystems the package XML file is overwritten. As a result,
after the code
generation for a TargetLink subsystem the package XML file
only contains the
AUTOSAR elements referenced by that specific TargetLink
subsystem.
Workaround: If a model contains multiple TargetLink subsystems that share
one or more
AUTOSAR packages, after code generation for all the
individual TargetLink
subsystems perform one AUTOSAR export step that selects
all TargetLink
subsystems with options "Enable package support" and
"Merge software components
with identical names" activated.
ID:
PR20070525-05
Title:
Start of Data Dictionary Manager without valid floating network

licence may yield to unhelpful error message

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Installation/licensing
Description: Starting the Data Dictionary Manager in stand-alone mode

(outside of MATLAB) on
Windows 2000 without a valid floating network license may
yield to an unhelpful
error message like the following:
Debug Error!
Program: C:\dSPACE\dsdd\Bin\DsddMan_1_4_1.exe
DAMAGE: after Normal block (#3751) at 0x012B2480
There is no additional message to note, that a license is
missing.
Workaround: Start Data Dictionary Manager with valid floating network
license.
1061 / 1260
ID:
PR20070529-05
Title:
After document generation different subsystem ist shown in

the Simulink window

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The used MATLAB version is R14 SP3 (or later) and the
property Simulink / Reuse
in MATLAB preferences is set to "replace".
In this case the execution of the document generation
(tldoc_default or
tldoc_rtf) leads to the effect, that the current Simulink model
window doesn't
show the Simulink model root anymore but the contents of a
subjacent subsystem.
Workaround: Change the Simulink / Reuse MATLAB preferences setting to
"mixed" instead of
"replace".
ID:
PR20070530-01
Title:
Error using Assignment, Selector or similar blocks with zero

based indexing and constants as external indices

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Error E17150 is thrown when using an Assignment or Selector

block with
- Zero based indexing
-- and -- external indices and
-- and -- a Constant block with default variable class as external
index.
Workaround: - Use a variable as external index with variable class other
than default
-- or -- Use one based indexing
-- or -- Use internal indices.
1062 / 1260
ID:
PR20070530-11
Title:
Code generation aborts if option "Autoscaling method" and/or

"Scaling reviewed" is set for Stateflow Input and/or Output.

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In general it is possible to set the option "Autoscaling method"

(sf.autoscalingmode) and/or "Scaling reviewed"
(sf.scalingvalid) for a Stateflow
Input and/or Output. The properties can be set by use of
Property Manager and
are evaluated by the Autoscaling tool.
Unfortunately the options are not known by the code
generator, which results in
Error #20895:
"Could not evaluate data tag specified by its description
autoscalingmode/scalingvalid ... "
Workaround: Do not use the autoscaling properties if code is generated.
ID:
PR20070601-04
Title:
Logging may not work correctly if multiple subsystems

configurated for incremental code generation share identical
modules

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If multiple incremental subsystems share identical module and

if in one of these
subsystems no log variables have been selected, it may
happen that variables
selected for logging within others of these incremental
subsystems will not be
logged during SIL/PIL simulation.
Workaround: 1) Generate the production code for the incrementall
subsystem without log
variables before generating a production code for incremental
subsystems with
log variables
2) Specify an incremental subsystem with log variables as an
owner of the shared
module. This can be done via the Function Block, tab
Incremental, entry "List of
modules owned by this function".
1063 / 1260
ID:
PR20070605-03
Title:
Wrong MIL simulation results of TargetLink blocks if they are

connected to a TargetLink Switch block and "Conditional input
branch execution" is active

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Given is a TargetLink Discrete-Time Integrator block which is

connected to the
input of a TargetLink Switch block.
The global Simulink optimization method "Conditional input
branch execution" is
activated. In this case the Discrete-Time Integrator block
yields to wrong
simulation results.
The reason is, that Simulink doesn't support the "Conditional
input branch
execution" optimization for S-functions with states. In this case
the S-function
callback method mdlUpdate is not executed which results in
wrong calculations.
The following TargetLink blocks are affected because their Sfunction contain
the mdlUpdate method:
- J-K Flip-Flop
- Discrete Transfer-Function
- Discrete Filter
- FIR Filter
Workaround: Disable Simulink option "Conditional input branch execution"
(Simulation >
Configuration Parameters... > Optimization > Conditional input
branch
execution).
1064 / 1260
ID:
PR20070611-12
Title:
Code generation aborts on Data Store Write block when using

a variable class with extern scope and macro set to "on"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If you use a variable class with "Scope" = "extern" and

"Macro" = "on" in a Data
Store Write block code generation aborts with the following
error:
Error #20010: Subsystem/Data Store Memory:
The associated data store memory block uses variable class
<...> with attribute
macro. This leads to erroneous code as the data store
memory cannot be written.
The error message is wrong. There are no restriction to use
an external macro.
Workaround: Due to the fact that the specification as macro will fail, please
us the
property "Alias" = "on".
ID:
PR20070613-04
Title:
tl_extract_subsystem does not transfer code generator

options to the new model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: The subsystem extractor "tl_extract_subsystem.m" doesn't

transfer TargetLink
code generator options (e.g. code optimization level) to the
new model.
Workaround: An M-script containing the following lines tranfers the
necessary options after
subsystem extraction:
oldTLMain = <Simulink path of TargetLink main dialog in
original model>;
newTLMain = <Simulink path of TargetLink main dialog in new
model>;
opt = tl_get(oldTLMain);
for i=1:length(opt),
if ~strcmp(opt{i},'date')
tl_set(newTLMain, opt{i}, tl_get(oldTLMain, opt{i}));
end
end
1065 / 1260
ID:
PR20070613-05
Title:
In generated code may be an assignment of relational or logial

operation to variable of width smaller than int

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the code generator option

"NoAssignmentOfBooleanExpressions" is "off", then
the generated production code may assign results of relational
or logical
operation to variable of TargetLink basetype Bool. The
underlying type of Bool
may have a smaller width than the result, which is either a 0 or
a 1 of type int
according to the ANSI C standard. For instance the generated
code may look like
this:
typedef unsigned char Bool;
Bool out;
out = a > b;
This may lead to a compiler warning or error if the compiler
does strict
checking (e.g. the Cosmic HC(S)12/S12X compiler with option
+strict) even though
the code is correct and has well-defined semantics due to the
result range of
relational and logical operators. Further the code violates
MISRA rule 10.1
(Implicit conversion: int to unsigned char).
Workaround: - Activate the option "NoAssignmentOfBooleanExpressions"
(= "on") in
tl_pre_codegen_hook.m.
-- or -- Specify the Bool basetype to be of integer width in
TargetConfig.xml of your
target.
1066 / 1260
ID:
PR20070613-11
Title:
Wrong for loop detection in Stateflow chart leads to incorrect

code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In TargetLink Advanced Practices Guide the preconditions of

for loop are given:
1) The last statement before the loop defines a loop_var
-- and -2) The last action on the loop transition defines the same
loop_var
-- and -3) There are no other other actions or conditions on other
transitions in the
loop, for example the loop consists of only one transition with
loop condition
and action like the example in the advanced practices guide
(source and
destination of the loop transition is the same junction)
The check for this third condition is wrong in the code
generator, so a for loop
is generated ignoring all other actions/conditions. That means
if preconditions
1 and 2 are fulfilled, all transitions between the source and
destination
junction of the loop are ignored and no code is generated for
them.
Workaround: Avoid that preconditions 1 and 2 are fulfilled.
For example if you have an incoming transition into the loop
with following
code:
{ x=1; y=0; }
And the loop transition is:
[loop_condition] { loop_action1; loop_action2; y++; }
Here preconditions 1 and 2 are fulfilled - a foor loop is going to
be generated.
To avoid the for loop detection you can either modify the
incoming transition to
{ y=0; x=1; }
or the loop transition to
[loop_condition] { loop_action1; y++; loop_action2; }
or
[loop_condition] { loop_action1; loop_action2; y++; dummy=1;
/* dummy
assignment to a temporary and optimizable variable */ }
1067 / 1260
ID:
PR20070613-12
Title:
Code generation aborts on elimination of variable used in a for

loop initialization or update statement

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable is assigned in a for loop initialisation and loop

update and is
going to be erased by the optimization (for example because it
is never read
from) the code generator aborts. This can be modelled within
a Stateflow chart.
Example:
for(x=0; b<5; x=1)
{
... /* no reading usage of x */
}
... /* no reading usage of x */
Workaround: - Use the variable in the for loop
-- or -- Delete the superfluous definitions
-- or -- "Protect" the variable by a VariableClass with optimization
property ERASABLE
unset.
ID:
PR20070619-18
Title:
Missing interface variable in Data Dictionary node

/Subsystems/<tl_subsystem>/<function>

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: For a subsystem containing a function block and no

TargetLink InPort and/or
Outport, which specifies the function interface, the
corresponding function's
interface description inside the Subsystems node may be
incorrect for vector
variables. This may lead to MIL/SIL simulation differences.
Workaround: Specify the subsystem's interface by TargetLink InPort and
OutPort blocks.
1068 / 1260
ID:
PR20070619-20
Title:
Support of AUTOSAR COMPU-METHOD elements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR Import/Export Module supports only COMPUMETHOD elements describing
the following types of conversions between internal and
physical values:
- linear converision (LINEAR)
- verbal conversion table (TAB_VERB).
All other conversion types, e.g:
- conversion table with interpolation (TAB_INTP)
- conversion table withput interpolation (TAB_NOINP)
- fractional ration function (RAT_FUNC)
are not supported.
1069 / 1260
ID:
PR20070619-22
Title:
Mode data for events is imported incompletely from

AUTOSAR 2.0 XML file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If an AUTOSAR 2.0 XML file like the following example extract
is imported into a
Data Dictionary, not all data is imported appropriate.
<DATA-RECEIVED-EVENT>
<SHORT-NAME>DataReceivedEvent1</SHORT-NAME>
<DESC>SrInterface1, DataElement1; Ms1Group,
Mode1</DESC>
<MODE-DEPENDENCY>
<DEPENDENT-ON-MODE-IREFS>
<DEPENDENT-ON-MODE-IREF>
<CONTEXT-REFS>
<CONTEXTREF>/Components/RComponent/Port6</CONTEXT-REF>
<CONTEXTREF>/Interfaces/MsInterface1/Ms1Group1</CONTEXT-REF>
</CONTEXT-REFS>
<TARGETREF>/Interfaces/Ms1Group1/ModeDeclaration1</TARGETREF>
</DEPENDENT-ON-MODE-IREF>
</DEPENDENT-ON-MODE-IREFS>
</MODE-DEPENDENCY>
...
<DATA-RECEIVED-EVENT>
The problems are:
- The references - described in the CONTEXT-REF property might not be imported
into Data Dictionary file. It may happen that a CONTEXT-REF
element is missing
in the Data Dictionary after the import.
- The mode data is imported as generic data instead as a
corresponding Data
Dictionary object, which reflects the kind of the data. The data
cannot be used
by TargetLink.
1070 / 1260
ID:
PR20070621-04
Title:
Wrong initialization of lookup axis variable using variant

coding

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If variant coding is used within a lookup table, the initialization

of varianted
axis variables may be wrong.
Generated code:
&(Car_Info_Data_Variants[0].X_Axis) /* x_table: */
Expected code:
&(Car_Info_Data_Variants[0].X_Axis[0]) /* x_table: */
Both expressions although of different types result in the same
address.
That's why the code render correct simulation results (if it was
successfully
compiled).
ID:
PR20070622-01
Title:
Typdefs specified in the Data Dictionary group AUTOSAR are

not exported to AUTOSAR file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If Data Dictionary typedef objects are specified inside the

group
/Pool/Typedefs/Autosar of the AUTOSAR master Data
Dictionary file and an AUTOSAR
XML file is exported from this Data Dictionary using the option
"package
support", then these typdefs are exported to the XML file.
But for import this file should not be used, because the XML
file normally
contains the AUTOSAR standard types. But not importing this
file can lead to
unresolved references inside the DD file.
Workaround: Specify user specific typedefs not inside this predefined Data
Dictionary
typedef group. For example create a Data Dictionary typedef
group
/Pool/Typedefs/MyAutosarTypes and create the typedefs
there.
1071 / 1260
ID:
PR20070622-04
Title:
Access function for static structs leads to error #17054 if

function is not side effect free

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The problem occurs if following conditions hold:

- On the level of the TargetLink root subsystem a static struct
is defined as
TargetLink InPort.
- An access function will be used for this static struct.
- The corresponding function class of the access function has
the optimization
property "SIDE_EFFECT_FREE" set to "off"
The code generation aborts with error #17054
Error #17054:<TL_Subsystem>/Bus Outport:
The variable 'Aux_<Variable>' is implemented with 'module
local scope', but
requires 'global scope'.
Workaround: In function class of access function set optimization property
"SIDE_EFFECT_FREE" to "on"
ID:
PR20070622-10
Title:
The option "Copy left (overwrite)" in AUTOSAR SWC-D Merge

Explorer does not work correctly for the root object

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When the AUTOSAR SWC-D Merge Explorer is open, and

you select the menu "Copy
left (overwrite)" for the root object in the AUTOSAR SWC-D
Merge Explorer, the
tree in the AUTOSAR Diff Merge Explorer does not agree with
the tree in the Data
Dictionary Navigator. This problem especially occurs in the
context of missing
write/read access.
If the "Difference Report" is represented now, it shows these
differences in the
first Data Dictionary.
Workaround: Change the access rights and/or check for differences by
using the "Difference
Report".
1072 / 1260
ID:
PR20070625-02
Title:
AUTOSAR datatypes and COMPU-METHOD elements are

not imported

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: AUTOSAR datatypes and COMPU-METHOD elements are

only imported if the imported
AUTOSAR XML file contains references to these elements.
ID:
PR20070625-03
Title:
AUTOSAR import of COMPU-METHOD with type TAB_VERB

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a PRIMITIVE-TYPE-WITH-SEMANTICS references a

COMPU-METHOD of type TAB_VERB,
the AUTOSAR import sets erroneous ranges at the resulting
Typedef object in the
Data Dictionary.
ID:
PR20070625-09
Title:
AUTOSAR import sets min and max to zero

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a data element is a structure, the AUTOSAR import sets the

min and max ranges
of the structure components in the Data Dictionary incorrectly
to zero.
1073 / 1260
ID:
PR20070625-10
Title:
Erroneous setting of typedef properties Description and

IsBaseType after AUTOSAR import

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: After AUTOSAR import the Data Dictionary typedef properties

"Description" and
"IsBaseType" may contain wrong values for imported
PRIMITIVE-TYPE-WITH-SEMANTICS
and ARRAY-TYPE elements.
ID:
PR20070626-02
Title:
AUTOSAR export creates superfluous COMPU-METHOD

elements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a software component has AUTOSAR interfaces that

reference a typedef with
constraints and a void scaling, the AUTOSAR export may
create superfluous
COMPU-METHOD elements.
1074 / 1260
ID:
PR20070627-01
Title:
Error about unsupported bit operation in Stateflow because of

optimization

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Currently, the operation "bit not" is not possible for constants.
TargetLink's code generation might issue an error if a bit not
operation is
specified for a variable which is replaced by a constant value
during
optimization.
This may happen, when the expression of a bit not operation
in a Stateflow chart
has constant value on all possible executions of that chart. If
this is
dicovered by the optimization, the expression will be replaced
by the constant
value which leads to an error at a later point of code
generation.
Workaround: Use a variable class, where the property Optimization is not
set to "ERASABLE".
If this problem occurs for a formal parameter of a graphical
function (i.e. a
formal parameter of a graphical function is the operand of a
"bit not" operation
inside the function and this function is always called with the
same value for
this parameter) then there are two alternative workarounds:
1) Use a variable class with Scope = "value_param" and
Optimization not set to
"ERASABLE"
2) Use the Option "Export Chart Level Graphical Functions
(Make Global)" in
Stateflow.
1075 / 1260
ID:
PR20070628-02
Title:
Saturation on integer overflow not always taken into account

during Simulink to TargetLink conversion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When the SaturateOnIntegerOverflow parameter of a Simulink

block is set to "on",
Simulink to TargetLink conversion sets the output.checkmin
and output.checkmax
properties of the replacing TargetLink block to 1 if output.type
specifies an
integer data type. However, this fails in the following use
cases:
- Gain, Math, MinMax, MultiPortSwitch, Product, Sum or
Switch block is being
converted
- the OutputScalingMode property of the block specifies
inheritance, for
example, 'Same as same input' or 'Inherit via internal rule'
- the TargetLink type is an integer type
In this case, the output.checkmin and output.checkmax
properties are not set.
Workaround: Write conversion hook functions, or set the properties
manually after
conversion.
ID:
PR20070628-04
Title:
In Custom Code block a Data Dictionary variable is not

selectable for parameter if width specifies a matrix

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: In general matrix parameters are not supported for Custom

Code blocks. Therefore
the block dialog checks if all properties of selected Data
Dictionary variable
are valid and selecting a Data Dictionary variable with width [2
2] for
parameters of Custom Code block dialog results in an error
message:
"Selected variable has a wrong dimension!
<var>.width = [2 2]"
1076 / 1260
ID:
PR20070702-01
Title:
For data varianted property the current data variant item may
not taken into account

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Given is a variable with a data varianted property. During code

generation the
properties are set according to the current data variant items.
It may happen
that a property is not set correctly, due to the fact that the
property is not
considered by the code generator.
Example:
The property DisplayIdentifier is data varianted to realize a
good
identification of the varianted variables inside a calibration
tool.
After code generation and A2L export all properties
DISPLAY_IDENTIFIER are
always equal to the default value.
In Data Dictionary below the node Subsystem the variables
are set according to
the variant items. Some properties are not set correctly,
because only the
default value is set.
Workaround: During code generation the properties of the variables are
copied to the
subsystems area. In some cases it is possible to modify the
properties after
code generation in the Data Dictionary. Either manually or by
script (e.g.
post_codegen_hook).
Otherwise no workaround available.
1077 / 1260
ID:
PR20070703-01
Title:
AUTOSAR export does not handle indirectly referenced units

properly

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A Unit object in the Data Dictionary and in AUTOSAR can be

derived from another
unit, for example,
Unit "ut_mm"
Description "Millimeter"
UnitRef = <meter>
ConversionFactor = 0.001
ConversionOffset = 0.0
Erroneously, the referenced unit ("meter") is not exported, and
the derived unit
("ut_mm") is exported twice.
Workaround: Specify the derived unit as a seperate, non-derived unit.
ID:
PR20070704-01
Title:
Wrong code is generated for a Rate Limiter block if the term

((slew rate lsb * sample time) / output lsb) is whole-numbered

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a non-default variable class is selected for the slew rates of

a Rate Limiter
block, a scaling has to be given for them. The generated code
produces wrong
results, if the term ((slew rate lsb * sample time) / output lsb) is
whole-numbered
For example a slew rate with arbitrary scaling and lsb = 100,
Sample time = 0.01
and output lsb of the rate limiter = 1.
Workaround: Choose a slightly different Slew Rate scaling or use default
variable class for
the slew rates.
1078 / 1260
ID:
PR20070711-04
Title:
Entry of destination block in Standalone Model Manager is not

disabled if more then one TargetLink subsystem are selected

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In Standalone Model Manager the "Destination block for

selected TargetLink
subsystem" edit field is not disabled if multiple TargetLink
subsystems are
selected.
It can still be edited, although its modification has not effect.
This is not
correct and may lead to ambiguities.
According to TargetLink Production Code Generation Guide >
Simulating a Model
and Analyzing Simulation Results > Simulating in Different
Simulation Modes >
How to Prepare the Simulation of Production Code in a
dSPACE Prototyping
Environment > Method, step 8, the correct behavior is
specified as follow:
"The destination block must be set separately for each
TargetLink subsystem. If
more than one TargetLink subsystem is selected, this edit field
is disabled"
Workaround: Do not edit the entry, if more than one TargetLink subsystem
is selected.
ID:
PR20070711-10
Title:
Wrong sample time in Disrete-Time Integrator block in standalone mode

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The problem occurs if a Discrete-Time Integrator resides in a

masked subsystem
where its sample time is specified by a mask variable.
Additionally the
Discrete-Time Integrator must be configured such that the
optional input for a
reset signal is shown. In that case it might be possible that the
connection to
reset port gets lost during model load.
Workaround: If possible, name the mask variable for sample time "dt".
1079 / 1260
ID:
PR20070712-02
Title:
During autoscaling the propagation of worst-case ranges may

fail for Look-Up Table (2D) block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Propagation of worst-case ranges fails for the Look-Up Table

(2D) block, if
- variable class of table row specifies the variable as
calibratable and at
least one constrained limit (minimum or maximum) is unset
-- AND/OR -- variable class of table column specifies the variable as
calibratable and at
least one constrained limit (minimum or maximum) is unset.
The thrown errors are not meaningful, they consist of pairs of
the following
error messages:
Error #03461: autoscaling_lut/ ... /Look-Up Table (2D): Could
not call the
'tl_scale_2dlookup' block function.
Error #00000: autoscaling_lut/ ... /Look-Up Table (2D): The
range evaluation
failed.
ERROR:Output argument "result" (and maybe others) not
assigned during call to
"%DSPACEROOT%\matlab\tl\autoscaling\tl_calculate_ranges.p
(i_CalcBlock)".
Workaround: Please set constraints for calibratable variables, e.g. the
calibratable row
variable.
1080 / 1260
ID:
PR20070716-01
Title:
A structure as call-by-value parameter is not supported in

custom look-up function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Given is a custom look-up function and a user script where the
function
interface is specified in that way, that a struct is passed callby-value
through the function interface. This is currently not supported
and an error
message like the following is issued during code generation:
Fatal #17413: speedmap/Look-Up Table: The
'TLSCRIPT_DEFAULT_VALUE_PARAM_V_C'
variable class is not allowed for the '<variable name>' struct.
The following
properties are wrong: Scope = value_param
Passing a structure as call-by-value parameter was supported
in early versions
of TargetLink.
Applying one of the scripts (test_lookup1d_script.m or
test_lookup2d_script.m)
to test the user script is not sufficient to find the problem,
because the test
script will pass in such case.
Workaround: Pass a structure as call-by-reference parameter.
1081 / 1260
ID:
PR20070719-01
Title:
Wrong access to addresses to non scalar variables using

variant coding

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In some cases the address of vector or matrixes are

generated into the code by
TargetLink, for example in function calls with lookup function
user script or in
the initialization of map structure table and axis data.
If those variables are data varianted the generated code is
wrong.
The generated should be: &VectorVar[0] or &MatrixVar[0][0]
But currently the code looks like: &VectorVar or &MatrixVar
Although this is syntacticly wrong code, the resulting
simulation or calculation
will work fine.
Depending on the compiler a warning might come up when
compiling the generated
code.
ID:
PR20070720-02
Title:
TargetLink Runnable Inport may not open

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: In some constallations it is impossible to open a TargetLink

Runnable Inport
and/or Outport dialog.
The error message is like
Error evaluating 'OpenFcn' callback of TL_RunnableInport
block (mask) 'Runnable
Inport'. Attempt to reference field of non-structure array.
Workaround: Please check if
- the settings of the runnable (inside the green Runnable
block) are consistent
and valid
- the current Data Dictionary fits to the runnable selection
- only one (green) Runnable block configures the runnable
port blocks
Otherwise there is no workaround available.
1082 / 1260
ID:
PR20070724-01
Title:
Broken function hierarchy in A2L file if incremental code

generation is used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The function hierarchy in a A2L file created for a subsystem,

that a production
code has been generated for in one step,
differ from the function hierarchy in a A2L file created for the
identical
subsystem, that a production code has been generated for
incrementally.
Example:
A TargetLink subsystem controller contains one subsystem
"Linearization".
For the subsystem controller the function "Fcn_controller" is
generated, for the
subsystem "Linearization" the function "Fcn_linearization".
If the subsystem "Linearization" was not configurated for the
incremental code
generation, the A2L file function hierarchy looks like:
/begin FUNCTION
Fcn_controller /* Name */
Sa1_sPI /* Identifier */
/begin SUB_FUNCTION
Fcn_Linearization /* Identifier */ <----------------Fcn_Linearization is reffered as subfunction
/end SUB_FUNCTION
/end FUNCTION
/begin FUNCTION
Fcn_Linearization /* Name */
/begin DEF_CHARACTERISTIC
P_Sa2_Gain /* Identifier */
Sa2_Look_Up_Table_z_table /* Identifier */
Sa2_enable_lookup /* Identifier */
/end DEF_CHARACTERISTIC
/end FUNCTION
and is shown in the calibration tool like:
--> Fcn_controller
|
| --> Fcn_linearization
If the subsystem "Linearization" was configurated for the
incremental code
generation, the A2L file function hierarchy looks like:
/begin FUNCTION
Fcn_controller /* Name */
1083 / 1260
Sa1_sPI /* Identifier */
/end FUNCTION
/begin FUNCTION
Fcn_Linearization /* Name */
/begin DEF_CHARACTERISTIC
P_Sa2_Gain /* Identifier */
Sa2_Look_Up_Table_z_table /* Identifier */
Sa2_enable_lookup /* Identifier */
/end DEF_CHARACTERISTIC
/end FUNCTION
and is shown in the calibration tool like:
--> Fcn_controller
l--> Fcn_linearization
ID:
PR20070724-02
Title:
Measurable actual parameter is missing in A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Using the ArgClass property of the VariableClass object it is

possible to
specify the variable class of an actual parameter.
For example if the ArgClass of the FCN_REF_ARG class is
set to DISP, the code
generator defines an actual parameter of variable class DISP.
However such actual parameter does not appear in the
generated A2L file.
1084 / 1260
ID:
PR20070725-01
Title:
No scope reduction of functions whose function class is

remapped via template

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Functions may not be reduced in their scope if their default

function class is
respecified via a function class template in /Pool/Templates.
This problem may
occur if you change the properties TypePrefix, CompilerInline,
Interrupt or
Optimization. All other properties of a function class have no
effect regarding
the scope reduction.
ID:
PR20070725-03
Title:
Missing entry in A2L file for table variable specified in 2D-LUT

user script

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When a user script is applied for 2D Lookup Table block, the
ModelView node of
the subsystem is not generated correctly during code
generation. Due to this
fact the entries for the lookup table axis are empty in the
generated A2L file.
1085 / 1260
ID:
PR20070725-05
Title:
Optimization may cause wrong code for bitwise XOR

operation in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In a Stateflow chart it is possible to use bitwise logical

operands if C-bit
operations are enabled. The use of bitwise Exclusive-OR
(XOR, operator ^) may
lead to wrong production code. The problem may arise, if the
expression which
contains the XOR operation is wrongly discovered to be
constant. This wrong
information may be propagated to other expressions and
variables and this may
cause wrong code.
This problem may occur if following conditions hold:
- the value of an expression which uses bitwise XOR
operations can be discovered
as constant on all possible executions of the chart
- this expression is used as a condition or this expression is
assigned to a
variable which have also read access inside the chart
Workaround: - if the expression contains variables, then you can assign a
variable class
with "Info" property "readwrite" to one of thes variables
-- OR - if the expression is assigned to a variable (and is not also
used as a
condition) you can also assign a variable class with "Info"
property "readwrite"
to the variable
1086 / 1260
ID:
PR20070726-05
Title:
Wrong code is generated for a sum block with '--', where the
1st input is of floating point type, while all other I/Os are
integer

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The problem occurs for a sum block, if

- the operation is set to -- the first input is of floating point type
- the second input and the output is of some integer type
The generated code looks like
integer_out = (int) ((uint) (-float_in) - (uint) (integer_in));
If float_in is positiv, a negativ floating point value is casted to
an unsigned
integer type, which is not defined by ANSI-C specification.
While some compilers
generate code which give the expected result, some generete
code which returns a
Zero for the cast.
Workaround: Switch entries of the sum block to have the floating point type
as the 2nd
input.
1087 / 1260
ID:
PR20070727-01
Title:
No initialization of pointer to table values in restart function if

data variants are applied

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In a custom lookup table script it is possible to specify a table

structure with
a pointer to table values. The initialization of this pointer is not
generated
in the restart function if following conditions hold:
- The pointer is specified to be initialized in a restart function
(property
"InitAtDefinition" is set to "off" and property
"RestartFunctionName" is set to
"default")
-- AND -- Variant coding is applied
-- AND -- The lookup table struct is part of a variant struct.
Neither a warnung nor an error is issued.
Workaround: Do not initialize the pointer components in restart function or
do not use
variant coding with such a struct.
ID:
PR20070727-02
Title:
Wrong signal properties if a block is driven by an Assignment

block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The inheritance of signal properties does not work correctly if

an Assignment
block with enabled "Inherit Properties" drives a block which
has also "Inherit
Properties" enabled. The latter block uses Int16 and a scaling
of 2^0 with
offset 0 instead of the correct inherited values.
Workaround: Disable "Inherit Properties" at the Assignment block or at the
block that is
driven by the Assignment block.
1088 / 1260
ID:
PR20070727-03
Title:
Superfluous function reuse structures and/or components

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink may generate superfluous components or whole

superfluous structures
if persistent variables (i.e. variables that are either global,
static global or
static local) inside an function reuse subsystem have a
variable class with a
non-empty RestartFunctionName property. Note, that you may
assign such a
variable class directly in a block dialog or indirectly by using a
variable
class template.
1089 / 1260
ID:
PR20070727-04
Title:
Nested access functions not supported due to unspecified

behaviour of code generator

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Although it is not a feature of TargetLink, it is possible to

generate nested
access functions for the root interface variables. In general
only simple access
functions are supported, which means that a variable access
is replaced by an
access function. Nevertheless due to the current
implementation of the
replacement algorithm it is possible to get nested acess
functions.
Example:
1) Specify an access function for a variable and make sure
that an auxiliary
variable is generated. Therefore set the optimization property
not to
SIDE_EFFECT_FREE in the corresponding function class.
The generated code should
be like
AUX_Y = Get_Root_Inport(Y);
2) Create a variable class template for default variable class of
auxiliary
variable (e.g. SLStaticGlobal) and specify a variable class that
has an access
function as well. The generated code should be like
AUX_Wrapper(AUX_Y, Get_Root_Inport(Y));
This behaviour of the code generator is random. The
generated code may be
correct, but it cannot be guaranteed.
Therefore it is not recommended to use such modeling type
for nested access
functions.
Workaround: Do not use nested acces functions.
1090 / 1260
ID:
PR20070727-05
Title:
Custom look-up table script may abort if a renamed base type

is referenced which resides in a typedef group

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In general it is possible to use a renamed base type in custom

look-up table
script. It may abort during code generation if the renamed
base type is stored
in a typedef group.
TargetLink custom look-up scripts currently supports only
renamed base types
that are stored in node /Pool/Typedefs
Otherwise an error occurs like the following:
Error #09999: Subsystem/Look-Up Table:
Invalid type 'MY_TYPE' for object "MY_AXIS".
Workaround: Use only typedefs which are stored in node /Pool/Typedefs for
custom look-up
scripts.
ID:
PR20070727-06
Title:
Mapping of AUTOSAR data elements to bus signals

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a bus is connected to the inport of a SWC ReceiverPort

block or to the
outport of a SWC SenderPort block, TargetLink assumes that
the order of the bus
components is similar to the order of the port's interface
DataElement objects
modeled in the Data Dicitonary.
If the order of the bus components does not reflect the order
of the data
elements in the Data Dictionary, SIL and PIL simulation
results are erroneous.
Workaround: Sort components of Simulink busses and DataElement objects
in the Data
Dictionary in alphabetical order.
1091 / 1260
ID:
PR20070731-07
Title:
Addresses of the structure component are wrong

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a structure contains a component which is a bitfield

structure, the address
of the following component ist not correct.
Example:
typedef struct BF1 {
unsigned int Bit1 : 1 /* Description: LSB */;
unsigned int Bit2 : 1;
unsigned int Bit2 : 1;
} Bitfield1;
typedef struct CANInputs {
UInt8 Var1;
Bitfield1 MyBitfield1;
UInt16 Var2;
UInt8 Var3;
UInt8 Var4;
UInt8 Var5;
}
In the example above the addresses of the components Var2
to Var5 will be
incorrect.
Workaround: Move the bitfield structure to the end of the parent structure.
1092 / 1260
ID:
PR20070801-01
Title:
Wrong code for fixed point relational operations with floating

point constant

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The production code for relational operation may be wrong, if

following
necessary conditions hold:
- The first (left hand) operand is given by a Constant block
with default
variable class
-- AND -- The second operand is given by a block with fixed-point
output
Furthermore the following conditions hold too:
- The constant value cannot be represented in the scaling of
the second operand
-- AND -- The one of the relational operations >, <, <= or >= is used.
Example:
A Relational block has an Constant block with default variable
class as first
input and an InPort with Int16 data type an 2^0 scaling as
second input.
Sa1_Relational_Operator = 0 /* 0.6 */ > Sa1_InPort;
if the constant value is 0.6 and the relational operator >.
If the value of Sa1_InPort is 0 then this code will render a
wrong result.
This kind of problem may come up, if a Relational block with a
floating point
constant as first operand is used.
But it may also come up in some cases if a Min/Max block is
used whose inputs
are all default class constants.
Workaround: - Change the order of inputs
-- OR -- Chose a scaling where all constants can exactly be
represented
1093 / 1260
ID:
PR20070802-01
Title:
Erroneous moving of code into conditional branches for

incompatible array element accesses

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: As an example, given is following code pattern

array[Index] = NewVal;
if (cond1) {
b = array[constIndex];
} else {
b = 23 /* 23. */;
}
where "Index" is a variable and "constIndex" is a constant
The pattern is erroneously optimized to
if (cond1) {
array[Index] = NewVal;
b = array[constIndex];
} else {
b = 23 /* 23. */;
}
This situation arises only if modelled directly in a Stateflow
chart or if using
the same variable multiple times via the MERGEABLE
variable class optimization
property in order to change data flow relationships.
Workaround: Choose a variable class for the respective array variables that
has the MOVABLE
optimization property not set.
1094 / 1260
ID:
PR20070803-01
Title:
Real-time application cannot be build for Simulink model

containing stand-alone S-functions

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A Simulink model or subsystem contains at least two standalone S-functions

created for TargetLink subsystems, where following conditions
hold:
- the root function generated for the first TargetLink subsystem
uses global
interface variables, for example Int16 A, Int16 B
- the root function generated for the second TargetLink
subsystem uses
corresponding extern global interface variables, for example
extern Int16 A,
extern Int16 B
The real-time code generated for such Simulink model or
subsystem cannot be
compiled.
An error similar to the following is issued:
<subsystemOne>_sfcn.obj: multiple definition of
_<interface_variable_name>_LSB
<subsystemSecond>_sfcn.obj: multiple definition of
_<interface_variable_name>_Offset
ID:
PR20070809-05
Title:
Default mode for XML import has changed since Data

Dictionary 1.4

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If no mode is specified in Data Dictionary prior version 1.4, the

import mode is
default, and the kind of the XML file is determined by its
structure. If no mode
is specified in Data Dictionary 1.4 and above the import mode
is "simple". This
may lead to an unexpected behavior, if not considered.
Workaround: Specify the import mode explictly. For example via MATLAB
command:
dsdd('Import','format','xml','File','Test.xml','mode','extended')
ID:
PR20070814-01
1095 / 1260
Title:
Compute-through-overflow (CTO) comment missing for Sum

block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the code generation option "PolySpaceSupport" is set to

"on", the generated
code should contain a "/* CTO */" code comment before
operands of additions or
subtractions that might overflow while using compute-throughoverflow
calculation.
This comment might be missing, if
- An addition or subtraction is specified in a sum block
-- AND -- One of the operands is provided by a Constant block with
default variable
class
-- AND -- The constant value is
- added and negative
-- OR -- subtracted and greater zero
-- AND -- The other input of the Sum block has
- a data type that is unsigned and wider
-- OR -- differently signed and equally wide than the data type of the
block's
output.
An arithmetic calculation of kind addition or subtraction can be
calculated
using the data type of the result, even if the operands actually
need a type of
wider bitwidth.
Example:
Modeled operation is out = in - 50000.
The generated code is
Int32 out;
UInt32 in; /* Min = 70000 Max = 80000 */
out = (Int32)(UInt16)((UInt16)in - 50000);
The constraints (Min = 70000 and Max = 80000) of the
variable 'in' are known be
the code generator. The result of subtraction has a range of
[20000, 30000] and
fits into UInt16 (16 bit). Although the range of operands, e.g.
'in', cannot be
represented using UInt16, TargetLink introduces an overflow
by casting 'in' to
UInt16. The upper bits (above bit 16) are not needed to
calculate the result.
Doing this TargetLink makes use of the compute-through1096 / 1260
overflow principle, which

means, that only the lower 16 bits of the operands are
significant as long as
the result of the subtraction fits into 16 bit.
Otherwise, to avoid compute-through-overflow the subtraction
would have to be
calculated using 32 bit data types (unsigned long) instead of
16 bit data types
(unsigned int). This might be less efficient, especially on 16 bit
platforms.
Workaround: Switch the type of non constant input to signed.
ID:
PR20070815-01
Title:
Abnormal termination of TargetLink Signal Comparision

Window after moving scroll bar

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In models which solver type is "Variable-step" it may happen

that the TargetLink
Signal Comparison Window aborts abnormal after moving the
scroll bar.
The following stack trace is displayed in MATLAB command
window:
??? Error using ==> set
Values must be monotonically increasing.
Error in ==> tlds_compare>i_PositionAxes at 619
set(figdata.tableaxes, ...
Error in ==> tlds_compare>i_RefreshYLabels at 775
i_PositionAxes(fig);
Error in ==> tlds_compare at 281
i_RefreshYLabels(fig,figdata);
??? Error using ==> tlds_compare('scroll');
Error using ==> set
Values must be monotonically increasing.
??? Error while evaluating uicontrol Callback
Workaround: Change the solver type to "Fixed-step".
ID:
PR20070816-01
Title:
Incorrect code for direct assignment of scalar result of a

graphical function to a vector or matrix

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
1097 / 1260
Description: If there is an assignment or scalar result of a graphical

function to a
multi-dimensional data element in a Stateflow chart, the
function has to be
called only once and the result has to be assigned to all
elements of the vector
or matrix.
The TargetLink code generator incorrectly generates a call to
the function for
each element of the vector or matrix. Thus, if the function has
side effects,
the behaviour will be incorrect.
Note that wrong code will be generated only if the result of the
function call
is directly assigned.
Example in Stateflow:
Vector int[9] vector1
Global variable int i=0;
function res = GFunction(param1)
{
res = i * param1;
i++;
}
The direct assignment is vector1 = GFunction( var1 );
The right code should look like this:
auxiliary_result = GFunction( var1 );
idx=0;
do
{
vector1[idx] = auxiliary_result;
(idx)++;
}
while ( idx < 10);
but looks like this:
idx = 0;
do
{
vector1[idx] = GFunction( var1 );
(idx)++;
}
while (idx < 10);
Workaround: To solve the problem, avoid direct assignments of scalar
function results to
multi-dimensional data elements. If the function call is
included in an
artificial complex expression, TargetLink is forced to create a
temporary
variable, e.g.
vector1 = GFunction( var1 ) + 0;
1098 / 1260
ID:
PR20070816-02
Title:
Modifying the initial value of a Stateflow object via tl_set

replaces workspace variable name with its value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: A Stateflow object can modified by TargetLink API command

tl_set. If the initial
value of the Stateflow object contains a workspace variable
name, this name is
replaced by its numeric value. The error affects only MATLAB
versions since
R14SP3 because earlier versions do not allow to set the initial
value of
Stateflow objects to an arbitrary workspace variable name.
Workaround: Use Stateflow API function sf to set Stateflow properties. This
workaround is
not sufficient for TargetLink properties.
ID:
PR20070817-01
Title:
Autosar Merge Explorer does not take package structure into

account

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If an AUTOSAR-XML file contains a package structure, the

structure will not be
displayed using the AUTOSAR Merge Explorer of Data
Dictionary Manager.
1099 / 1260
ID:
PR20070817-02
Title:
Missing signal name propagation of AUTOSAR Runnable

Inport may lead to confusing error messages

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Given is a model that contains an AUTOSAR Runnable Inport

that is driven by a
bus signal. During model initialization (update diagram) the
signal names are
propagated to the output signal although the port is specified
as non-virtual.
During code generation process the internal implementation of
the block is
changed and the signal names are lost, which may lead to
confusing error
messages.
Example:
The AUTOSAR port drives a Bus Inport block, where all
properties are properly
specified. The model initialization works without any error. But
during code
generation an error like the following is thrown:
Error #01225:
Error in '<blockpath>/InPos': Initialization commands cannot
be evaluated.
MATLAB error message: Bus components have been
changed. Open the block and check
all settings, then apply the consistent data to the block.
Supposedly the bus in Bus Inport block "InPos" has changed,
which seams to be
right, because the signal names in the Bus Inport block are
not the same. But
after model initialization the signal names are the same as
after opening the
model. It's curious, because it seams that the model is
specified properly. The
main reason of the error is not clear. The missing signal
propagation of the
AUTOSAR Runnable Inport is only active short before code
generation. Therefore a
user has no chance to find the problem.
Workaround: Specify the signal names right after the AUTOSAR Runnable
Inport block, or
switch the block to virtual.
1100 / 1260
ID:
PR20070817-03
Title:
Multiple variable definitions of actual parameter when using


TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is a subsystem where incremental code generation is

specified. A formal
parameter of that subsystem has a variable class, where the
ArgClass is
specified, which is the variable class of the corresponding
actual parameter.
Even if the actual parameter is not used in the incremental
subsystem the
variable is created twice. One variable during code generation
of incremental
subsystem and one during code generation of surrounding
subsystem. Depending on
the specified module of the variable two results are possible:
1) If no module is specified the variable is generated in the
module of the
incremental subsystem as well as in the module of the
surrounding subsystem. Due
to the fact that the variable is defined twice a linker error will
occur.
2) If a module is specified it may cause that the module of the
variable is
generated both at generation of incremental subsystem and at
generation of
surrounding subsystem. If some other parts should be
generated in this module
too (e.g. variables) it may happen, that this parts are missing.
For instance
the surrounding subsystem causes the variable "MyVar" to be
generated in the
same module and the incremental subsystem doesn't need
this variable. During
generation of incremental subsystem the module is generated
without the variable
"MyVar". This yields to compiler errors.
Workaround: Specify the actual parameter to be owned either by the
incremental or by the
surrounding subsystem. Use the module ownership applying
following steps:
- For the actual parameter select a variable class which has
set Module to e.g.
"MyModule".
- Use a TargetLink Function block to assign "MyModule" as
owned module either by
the incremental subsystem or by the surrounding subsystem.
Enter the name of the
module in the entry "List of modules owned by this function"
on Incremental tab
of Function block.
1101 / 1260
ID:
PR20070820-02
Title:
Code generation may abort on complex preprocessor control

conditions using Simulink If block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The Simulink If block can be used to generate preprocessor

statements, if the
block is driven by blocks which output variable classes have
set
'UsePreprocessorIf' to 'on'.
If such Simulink If block is used to generate preprocessor
control flow, complex
If expressions and complex Elseif expressions are currenty
not supported,
although this would be allowed by a C preprocessor.
Workaround: Follow one of the suggestions:
- Take a TargetLink PreprocessorIF block instead of the
Simulink If block.
- Do not use complex expressions (a complex expression is
any expression which
does not constist exclusively of exactly one input parameter
(e.g. u1, u2,
...)).
Note:
Both the Simulink If block, used to generate preprocessor
control flow, and the
TargetLink PreprocessorIF block need to be driven exclusivly
by blocks which
variable classes have set 'OmitCastOfMacroValue' to 'on'.
1102 / 1260
ID:
PR20070821-01
Title:
Definition of a variable may not be encapsulated with


TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A variable which is used as an initializer of a structure

components may
erroneously not be encapsulated with preprocessor control
flow:
1) Instance structures of reused subsystems are not
encapsulated in the
following situation:
- A reused subsystem X resides inside a subsystem which is
called by a
Preprocessor IF block.
- The instance structures of the subsystems called by X are
global or static
global.
2) Table data variables of look-up tables are not encapsulated
in the following
situation:
- A Look-Up Table block or a Look-Up Table (2D) block
resides inside a subsystem
which is called by a Preprocessor IF block.
- The table data variables (Look-Up Table: x-axis, y-axis;
Look-Up Table (2D):
table, row, column) are global or static global.
Workaround: 1) Instance structures of reused subsystems are not
encapsulated:
No workaround available.
2) Table data variables of look-up tables are not
encapsulated:
Apply one of the following suggestions:
- Specify the table data variables to be static local (using a
variable class).
- Specify the missing preprocessor control flow for the variable
definition as
DeclarationStatements (using a variable class).
1103 / 1260
ID:
PR20070823-04
Title:
Wrong error message #17054

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is a block which yields to more than one variable, e.g.
Gain block (output
and gain parameter). One variable is specified through a Data
Dictionary
variable, which has the module property set. One of the other
variables yields
to a local variable (e.g. using variable class "default").
During code generation the following error may be issued:
Error #17054: The variable <varname> is implemented with
'module local scope',
but requires 'global scope'.
TargetLink assumes that the local variable needs a global
scope, because of the
specified module of the other variable. This is wrong.
Workaround: - Remove the module entry in the Data Dictionary variable
-- OR -- Use global variables for the other block variables
1104 / 1260
ID:
PR20070824-01
Title:
Erroneous removal of extern and alias macros at algebraic

simplification

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an operation offers a better algebraic equivalent way of

expression and if
one of the operands is known to have the constant value zero
or one, then it may
be subject of erroneous optimization.
The following variable class preconditions must hold for the
operand to be taken
into account:
- the operand is a macro (or has been replaced by a macro)
- the macro is global and has extern storage or the alias
property
- the initial value is unspecified or zero (or one, respectively)
- the Optimization property ERASABLE is set
- the Info property is not set to ReadWrite or Adjustable
In this case, the operand's initial value is assumed to be the
actual value and
algebraic simplifications are performed.
Examples:
b+a
!b
b > (UInt16)a
b |= a;
are all "optimized" to
a
1
0
b = a;
respectively if "b" is a macro without initial value meeting the
above
conditons.
Workaround: Make sure that one or more of the above preconditions do not
hold.
Ideally, optimization property ERASABLE is switched off. Note
that otherwise,
the specified initial value does not have an impact on the
code, as the macro's definition is outside the known code.
1105 / 1260
ID:
PR20070829-02
Title:
Fixed-point data types (fixpt) in Stateflow may not handled

correctly on MATLAB R14SP3 or newer

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: It may happen that a fixed-point data type in Stateflow is not

handled correctly
on MATLAB versions since R14SP3. The code generation
message like following:
Warning #10601:
No error 'TypedefObject' was found in the data dictionary.
Error #17257: Subsystem/Chart.m_Const:
The data type 'error' is invalid for the variable 'm_Const'.
Workaround: Do not use fixed-point data types in Stateflow. Use TargetLink
fixed-point
settings instead.
1106 / 1260
ID:
PR20070830-01
Title:
Real time code with TargetLink stand-alone S-function cannot

be build within the RTI environment

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a stand-alone S-function is used within a Simulink model,

where a real time
simulation application is to be build for by means of dSPACE
RTI, then following
error occurs during compilation process:
OPUS MAKE: Don't know how to make <Sourec file name
>.<?>. Stop
The error is caused due to wrong RTI user make file
generated by TargetLink's
Standalone Model Manager, which lists additional files to be
compiled.
Workaround: Generate the RTI user make file again in TargetLink's
environment carrying out
the following steps:
1) Open the model containing the TargetLink subsystem,
where a stand-alone
S-Function has been generated for
2) In the TargetLink Main Dialog, Options tab, field: DD
application name read
the name of the application associated with current model
3) Open the Data Dictionary Manager (for example with
dsddman command) and
rename the application object named as the application
associated with the model
4) Build the stand-alone S-Function for the selected
5) Rename back the application object
1107 / 1260
ID:
PR20070830-02
Title:
AUTOSAR import of PRIMITIVE-DATATYPE-WITHSEMANTICS

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A primitive datatype with semantics is not imported into the

Data Dictionary if
all of the following conditions apply:
- Package support is enabled.
-- AND -- The primitive type referenced by the primitive type with
semantics is an
AUTOSAR basetype (i.e. Boolean, UInt8, SInt8, UInt16,
SInt16, UInt32, SInt32,
Float, Double, ...).
-- AND -- The package that contains the definitions of the referenced
AUTOSAR basetypes
is not called "autosar".
Workaround: At the AUTOSAR XML-file to be imported perform the
following modifications:
- Delete the definitions of the AUTOSAR basetypes.
- Replace each reference to an AUTOSAR basetype by the
following reference path:
/autosar/<AUTOSAR baseytpe name> e.g.: /autosar/UInt8
ID:
PR20070830-03
Title:
Autoscaling range propagation fails for Product block, if one

input is less than zero

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In general the range propagation for Product block should

work, if one input is
constant and one input is variable. But the propagation fails if
the constant is
less than zero.
1108 / 1260
ID:
PR20070830-08
Title:
Set of software component port may result in error message in MATLAB command
window

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If a client port is set in AUTOSAR SWC SenderPort it may happen that errors are
issued in MATLAB command window. The error occurs if the port references an
operation, but no operation arguments are specified.
Example of error message:
??? Output argument "child" (and maybe others) not assigned during call to
"D:\dSPACE\matlab\tl\dlg\tl_manage_element_properties.m
(i_AddDataElementSignal)".
Error in ==> tl_manage_element_properties>i_AddDataElementSignal at 791
objAttributes = dsdd('GetAttributes',ddPath);
Error in ==> tl_manage_element_properties>i_AddDataElementSignal at 865
[tree,child] =
i_AddDataElementSignal(tree,parent,compName,ddPath,argumentFilter,removeVoidOper
ations);
Error in ==> tl_manage_element_properties>i_GetSignals at 728
tree =
i_AddDataElementSignal('','',name,ddPath,argumentFilter,removeVoidOperations);
Error in ==> tl_manage_element_properties at 111
[signals,tree] =
i_GetSignals(component,port,interfaceElement,filter,removeVoidOperations);
Error in ==> tl_swc_port_dlg>i_UpdateOptionsPage at 570
[dlgdata.signals,dlgdata.signalData] =
tl_manage_element_properties('Signals',data.component,ports{idx},'',filter,remov
eVoidOperations);
Error in ==> tl_swc_port_dlg>i_ManageOutputPage at 468
dlgdata = i_UpdateOptionsPage(dlgfig,dlgdata,pageNum);
Error in ==> tl_swc_port_dlg at 109
[dlgdata,bModified] = ...
Error in ==> D:\dSPACE\matlab\tl\dlg\dstabdlg.p>dstabdlg at 298
??? Error using ==> dstabdlg('Output',gcbf,'portEdit')
Output argument "child" (and maybe others) not assigned during call to
"D:\dSPACE\matlab\tl\dlg\tl_manage_element_properties.m
(i_AddDataElementSignal)".
??? Error while evaluating uicontrol Callback
Workaround: Assure a correct specification of interfaces and operations in Data Dictionary,
e.g. an operation argument.
1109 / 1260
ID:
PR20070831-06
Title:
Pointer component of look-up structure is not correctly

initialized

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A pointer component of a look-up table structure may not be

initialized
correctly, if the following conditions hold:
- The look-up table struct is specified in a custom look-up
script
-- AND -- The look-up table block resides in a subsystem X which is
specifed for
function reuse
-- AND -- At least two instances of subsystem X are within the model.
Workaround: No workraound available.
ID:
PR20070906-01
Title:
SIL or PIL simulation not possible for TargetLink subsystem

with fixed-point data at the subsystem border

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a Simulink fixed-point data type is propagated through the

TargetLink
subsystem border, the SIL or PIL simulation is not possible.
The build process of the production code simulation S-function
fails with a
compiler error like the following one:
TLSim\<TLSubsystemName>_sf.c(126) : error C2065:
'SS_<FxpTypeName>' :
undeclared identifier
TLSim\<TLSubsystemName>_sf.c(126) : error C2099:
initializer is not a constant
Example:
A TargetLink subsystem, where the problem occurs, may look
like following one: A
Statechart output is specified to have a fixed-point data type.
This output
drives a virtual TargetLink OutPort and the connected
Simulink outport. Thus the
fixed-point data type is fed through the TargetLink subsystem
border.
Workaround: Please do not use fixed-point data types on TargetLink
subsystem border.
Otherwise no workaround available.
1110 / 1260
ID:
PR20070911-03
Title:
Wrong code generated for Trigonometric Function block

(atanh)

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for the
Trigonometric Function block:
- The Trigonometric Function block's property "Function" is set
to "atanh".
-- AND -- The flag "Handle exceptions in production code" is not
activated.
The generated code is wrong, because a call of acos() is
generated instead of
atanh().
Workaround: Activate the flag "Handle exceptions in production code".
ID:
PR20070913-01
Title:
Wrongly generated #include of .c file in <subsystem>_fri.h

leads to compilation errors

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Specifying the SystemTime variable as "static" with an access

function template
leads to the generation of an #include directive of a .c source
file inside the
TargetLink simulation frame file <subsystem>_fri.h. This may
lead to compilation
errors due to multiply defined symbols.
Workaround: - Delete the include line with a post codegen hook function
-- OR -- Do not specify SystemTime to be static
1111 / 1260
ID:
PR20070913-03
Title:
Wrong code if an access function is used in a code pattern

like Aux_ += Input

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Affected are following blocks:

- Sum block with more than two Inputs
- Discrete Time Integrator block
- Discrete Filter block
- Discrete State-Space block
The wrong code will be generated under following
circumstances:
- An input variable for mentioned blocks is associated with an
access function
-- AND -- The corresponding code pattern is like Aux_ += < input
variable>
This leads to wrong but compilable code like <input variable>
= <input variable>
+ <input variable> instead Aux_ += <Access Function of input
variable>.
Workaround: For the block Discrete Time Integrator, Discrete Filter and
Discrete
State-Space:
Insert a TargetLink InPort between the input block with the
access function and
the discrete block.
For Sum block:
The Sum block with more than two inputs expand to a
cascade of the Sum blocks
with two inputs.
1112 / 1260
ID:
PR20070913-05
Title:
Misleading error message #15669 for an Action Port block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink does not support Action Port block on root level of
a TargetLink
subsystem or in a subsystem that is specified for incremental
code generation.
However TargetLink throws the following misleading error
message:
Error #15669: Operational/Action Port The action port is not
connected to a
valid event source.
Workaround: Do not use Action Port block on TargetLink root subsystem or
subsystem that is
specified for incremental code generation.
ID:
PR20070914-06
Title:
Wrong code for an enabled, triggered and enabled or action

triggered subsystem in connection with incremental code
generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for an
enabled, triggered and enabled or action triggered subsystem:
- An enabled, triggered and enabled or action triggered
subsystem X resides
inside a subsystem Y which is configured for incremental code
generation.
-- AND -- The Enable port or Action port of X has "States when
enabling" or "States when
action is resumed" set to "reset".
-- AND -- Y is enabled, triggered and enabled or action triggered or is
called directly
or indirectly by an enabled, triggered and enabled or action
triggered
subsystem/chart Z.
The error is in the code which implements the call of Z: A flag
which indicates
the disabling of X is not set to "disabled".
1113 / 1260
ID:
PR20070918-04
Title:
Wrong Unit specification in Data Dictionary templates files

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
1114 / 1260
Description: In the following Data Dictionary template files the definition of

Unit objects
(/Config/Units) are not correct:
- dsdd_master_advance
- dsdd_master_basic
- dsdd_master_autosar (since TL 2.2)
The following properties are wrong:
- SI_Exponents
The single elements of the this vector correspond to the SI
base unit in the
following order:
1) meter
2) kilogram
3) second
4) Ampere
5) Kelvin
7) mol
8) Candela.
However in the Data Dictionary the elements are permuted:
meter = SI_Exponents[1] --> OK
kg = SI_Exponents[3] --> wrong, correct is SI_Exponents[2]
s = SI_Exponents[2] --> wrong, correct is SI_Exponents[3]
Ampere = SI_Exponents[5] --> wrong, correct is
SI_Exponents[4]
Kelvin = SI_Exponents[4] --> wrong, correct is
SI_Exponents[5]
mol = SI_Exponents[7] --> wrong, correct is SI_Exponents[6]
Candela = SI_Exponents[6] --> wrong, correct is
SI_Exponents[7]
- ConversionFactor und ConversionOffset.
For the ConversionFactor and ConversionOffset following
applies:
Value[inDerivedUnit] = Value[in base unit] * ConversionFactor
+
ConversionOffset
For example:
Value[in mm] = Value[in m] * 1000
--> ConversionFactor = 1000, ConversionOffset = 0;
Value[in Celsius] = Value[in Kelvin] * 1 - 273.15
--> ConversionFactor = 1, ConversionOffset = -275,15
In Data Dictionary for the example above following values are
set respectively:
ConversionFactor = 0.001, ConversionOffset = 0
ConversionFactor = 1, ConversionOffset = 275,15
It means the correct values of ConversionFactor and
ConversionOffset must be
recalculated:
ConversionFactorNew = 1/ConversionFactorOld;
ConversionOffsetNew = ConversionOffsetOld/ConversionFactorOld
Workaround: Please set the SI_Exponents as well as the ConversionFactor
and ConversionOffset
according to the explained format.
1115 / 1260
ID:
PR20070918-07
Title:
Simulink to TargetLink conversion aborts on conversion of Sfunction in library

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: During conversion of a library that contains an S-function for

which no libmap
is defined the following error occurs:
Error in ==> tl_conversion_callback>i_Sfcn2CC at 1425
PortWidths =
BlockStruct.allBlocksWidths(BlockStruct.allBlocks==sfcnHandle);
Error in ==> tl_conversion_callback>i_SL2TL at 106
msgStruct = i_Sfcn2CC(hSLBlock,hTLBlock,BlockStruct);
Error in ==> tl_conversion_callback at 42
[msgStruct,bInheritScaling] =
i_SL2TL(hOldBlock,hNewBlock,bIsR14,BlockStruct);
Error in ==> sl2tl>i_ReplaceBlocks at 2513
[m,bInheritScaling] =
tl_conversion_callback(hBlocks(n),h,1,BlockStruct); % 3rd
parameter indicates
that this is SL-->TL conversion
Error in ==> sl2tl>i_SL2TL at 890
[msgstruct,cnt] = i_ReplaceBlocks( ...
Error in ==> sl2tl at 457
[m,bSuccess,options] = i_SL2TL(options);
Error in ==> sllib2tllib>i_sllib2tllib at 594
[bSuccess,modelMsgStruct] = sl2tl( ...
Error in ==> sllib2tllib at 188
[msgstruct,bSuccess,slLibraryName,backupFile] =
i_sllib2tllib(options);
Workaround: Define a TargetLink compliant custom library and a libmap for Sfunction block.
1116 / 1260
ID:
PR20070918-08
Title:
Code generation aborts on custom look-up function if Data

Dictionary object is referenced that is placed in a group

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the Data Dictionary objects may be gouped, e.g. variables.

If an object that
is located in a group, for example a typedef, is used in a
custom look-up
function script, the code generation aborts with a message like
following:
Error #0000 <block name>: Bad property value for .... .
Workaround: Du not use groups for Data Dictionary objects that are used
within custom
look-up function scripts.
ID:
PR20070919-01
Title:
Preprocessor IF block with #else branch causes creation of

superfluous auxiliary macros

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Preprocessor IF block has an #else or #else if branch, the

definitions of
the functions and the variables used inside the #else or #else
if branch are
encapsulated with preprocessor control flow by using auxiliary
macros although
the use of auxiliary macros may be obviated.
Workaround: In many situations the creation of auxiliary macros may be
obviated by using a
separate Preprocessor IF block for each branch (one for each
connected Action
triggered subsystem).
1117 / 1260
ID:
PR20070920-03
Title:
Wrong simulation behaviour because of missing update of

interface variables in simulation frame

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Due to the fact that the specification of an interface variable of

the root
subsystem may not written in the Data Dictionary during code
generation, the
simulation frame does not contain the code for update of the
value. This results
in a wrong simulation behavior, because no data is written to
the variable. The
problem arises when the interface variable
- Belongs to a function called, but inlined subsystem
-- AND -- Is a struct component
ID:
PR20070921-02
Title:
Code generation may abort due to unconnected Stateflow

function call trigger outport

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: There may occur an internal error during code generation:

TlCChartDDStructParamPreparator692.
This error occurs if all of the following conditions are fulfilled:
- there is a Stateflow chart with an "output to Simulink" event
- this output event has trigger type "Function call"
- this function call output event is thrown inside an exported
graphical
function
- the chart outport which is associated with this function call
output event is
unnconnected.
Workaround: Connect the unconnected Stateflow function call trigger
outport with the
subsystem, which should be function called by this output
event. Or delete the
output event and eliminate the code which throws that event.
1118 / 1260
ID:
PR20070924-01
Title:
Error if custom code S-function is changed during initialization

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: Sometimes it make sense to use the mask initialization of a

Custom Code block to
update the Custom Code block parameters. For instance to
update a property
according to changed Data Dictionary variable or changed
data from preceeding
block. If parameters or the name of the Custom Code Sfunction is changed during
initialization, this leads to errors like
*** E01202: S-FUNCTION NEEDS TO BE REBUILT:
*** The S-function
*** bitwise_and_uint8_flp
*** of the TargetLink Custom Code block
*** BW Logical Operator
*** is incompatible with the block data.
In a TargetLink dialog box, the S-function name is given as
"dummyname".
Workaround: After trying to initialize the concerned block for the first time,
both
parameters and the name are correctly set. On second try the
block is
initializable.
1119 / 1260
ID:
PR20070925-01
Title:
Generation of non-existent macro C__I32FITI32_SAT if

MPC5(5)XX TOM is used

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: It may happen that the superfluous and non-existent macro

C__I32FITI32_SAT is
generated. This is possible if the following conditions hold:
- An arithmetic operation is used (-, +, / or *)
-- AND -- The Target Optimization Module (TOM) for MPC5(5)XX is
applied.
The non-existing macro leads to an error during linking.
Workaround: - Do not use the TOM for MPC5(5)XX.
-- OR -- Try to locate the operation for which the undefined macro is
generated and try
to modify the modeling. For instance set ranges for the
operands and the result
of the operation, or try to use auxiliary variables to store
temporary results.
ID:
PR20070925-02
Title:
Wrong code for multiplication with factor that is almost as

great as the limit of the data type of the second operand

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is a Constant block that feeds a Product or Gain block.

The resulting multiplication might erroneously be reduced to 0
if the following
conditions hold for the Constant block:
- It has the variable class "default"
AND
- it specifies a constant value that has a tolerance different
from 0%
AND
- the constant value is close to the limit of the data type of the
second
operand of the resulting multiplication
AND
- the constant value is close to the limit of the output type of
the Gain or
Product block
The same problem may arise for a Gain block whose gain
value acts like the
Constant block in the description given above.
1120 / 1260
Based on three examples the problem will be described in

following sections:
Example 1:
Given is a Gain block with pi = 3.1415 as gain value. Using
floating-point no
problem occurs and the code is like
out = in * 3.1415.
Using fixed-point arithmetics the representation of the value of
pi is
difficult. A simple code pattern like
out = in * 3,
is inaccurate. A better code pattern will be achieved using an
approximation of
the gain value by a quotient, e.g.
out = (in * 31415) / 10000,
which yields to 3141 for in = 1000. As a drawback, the
calculation has to be
done with extended data type, here 32-bit. More efficient code
is possible to
use onother approximation, which is less accurate, but doesn't
need extented
data types, e.g.
out = (in * 804) >> 8),
wich yields to 3140 for in = 1000.
Using the tolerance of the constant value (Output tab in
Constant block or Gain
tab in Gain block) a user specifies the degree of freedom that
the code
generater can use to find an efficient implementation. The
same approximation is
applied, even if the constant is already an integer value.
Example 2:
Given is a Gain block with 255 as gain value, class = default,
tolerance = 1%,
output type = UInt16
The input of the Gain block is driven by a variable of type
UInt16.
The generated code will be:
out = (UInt16) (in << 8).
According to the given tolerance the gain value is
approximated to 256, where
the multiplication can be represented by a shift operation,
which is more
efficient. Please note that an overflow may occur for an input
value in = 256.
For all other input values less than 256 the output is still
correct. Using an
exact gain value of 255, the output would be correct for in =
256. Therefore the
user must take into account, that a given tolerance may yield
to an extended
value range of the output compared to the exact gain value.
This has to be taken
into account during scaling etc.
Example 3:
Given is a Gain block with 255 as gain value, class = default,
tolerance = 1%,
output type = UInt8.
1121 / 1260
The input of the Gain block is a variable of type UInt8.

The code would be:
out = (UInt8) (in << 8).
If an 8-bit variable is shifted left by 8, always an overflow
occurs (except in
= 0, which is the trivial case). The resulting code pattern is
Out = 0.
The code generator should identify, that the overflow occurs
for any input value
(except the trivial case in = 0). In this case either a warning
should be issued
that the tolerance yields to unintended results or the tolerance
should not be
taken into account to avoid the overflow.
It has to be noted, that a handling is possible only in such
special cases.
In general theoretical overflows occur often in fixed-point
code. Although the
tolerance is used and the output range is extended, the output
values may be
right, because the result depends on the real input values.
Such cases may be
the intended bahaviour.
Workaround: Change tolerance to 0%
OR
Specify a variable class other than "default" for the constant
value.
ID:
PR20070926-06
Title:
Wrong simulation of Interpolation (n-D) using PreLook-Up in

TargetLink Blockset Stand-alone

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: In following cases the simulation of Interpolation (n-D) using

PreLook-Up blocks
is wrong in TargetLink Blockset Stand-alone:
- A 2D-table is used (Number of table dimensions is 2)
-- AND -- The index of an input is equal or greater than the
corresponding table size.
For instance there are 15 breakpoints given for the row and
the input index is
15 or greater than 15. The problem occurs for column as well
as row index input.
1122 / 1260
ID:
PR20070928-08
Title:
Preprocessor directive in custom code file may be wrapped

wrongly in production code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Long lines containing preprocessor directives in custom code

file may be wrapped
in production code, because the line limit is less than the
characters in line
in custom code file. The indentation has to be taken into
account too.
At end of wrapped line no backslash character "\" is inserted
to escape the
new-line character. Thus the preprocessor line ends at newline and the wrapped
line will cause a compiler error.
Workaround: - Increase the line break limit in TargetLink Main Dialog
-- OR -- Insert escaped new-lines in custom code file to shorten the
lines
1123 / 1260
ID:
PR20071002-01
Title:
Code generation aborts on operation in a case command

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a switch case operation is modeled in Stateflow and the

case expression is a
complex operation and not only a simple variable (variable,
constant or macro),
the code generation fails with an access violation.
Example:
If something like this is modeled
switch(i)
{
case MYMACRO-1:
...
}
the code generation aborts with an access violation.
Only for simple expressions (no complex operations) with a
single variable
(variable, constant or macros) the code generation succeeds.
Example for an non-critic modeling:
switch(i)
{
case MYMACRO:
...
}
Workaround: Avoid to model switch case control flow in Stateflow where the
case condition is
a complex operation.
1124 / 1260
ID:
PR20071002-02
Title:
Wrong removing of necessary statements in Stateflow if-else

branches

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Optimization may corrupt the code generated for Stateflow

charts. The problem
results in the removing of necessary statements in if-else
branches.
Such wrong deleting of necessary statements can only take
place in the
then-branch of an if-else control statement. Furthermore only
statements are
affected by this problem for which equal statements exist in
the else-branche of
the coresponding if-else statement.
Example: The correct code should look like this
if (...)
{
a = 0;
b = 1;
c = ...;
...
}
else
{
a = 0;
b = 1;
d = ...;
...
}
But optimization may reduce it to
if (...)
{
c = ...;
...
}
else
{
a = 0;
b = 1;
d = ...;
...
}
1125 / 1260
ID:
PR20071002-03
Title:
Missing connections after Simulink to TargetLink if Simulink

Inport is rotated up

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a Simulink Inport is rotated to point upwards and its outgoing

signal
branches to more than one destination block, all but one of
those signal lines
are lost during Simulink to TargetLink conversion.
Workaround: Rotate the Simulink Inport to have it pointed to the left, to the
right, or
downwards.
ID:
PR20071008-01
Title:
Wrong code generated for Selector block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for a
Selector block:
- The Selector block has set "Source of element indices (E)" to
"External".
-- AND -- The second inport of the block (E) is driven by exactly one
block outport (not
muxed).
-- AND -- The scalings of the elements of the variable of the driving
block's outport
are not equal.
The generated code is wrong, because the different scalings
of the driving
block's output variable are not considered by the code of the
Selector block.
Workaround: Specify equal scalings (LSB and Offset) for the driving block's
outport
variable.
1126 / 1260
ID:
PR20071008-03
Title:
Wrong code if Assignment block resides inside a For or While

subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for an
Assignment block:
- The Assignment block resides inside an iterating subsystem
(For Iterator
Subsystem or While Iterator Subsystem).
-- AND -- The For Iterator or While Iterator has set its property "Index
mode" to
"Zero-based".
-- AND -- The Assignment block has not activated its flag "Omit
dispenseable
initializations".
The generated code is wrong, because the Assignment
block's output variable is
not initialized during the first iteration but during the second
iteration of
the iterating subsystem.
Workaround: Set the For Iterator or While Iterator property "Index mode" to
"One-based".
ID:
PR20071008-06
Title:
MinMax block may not be scaled during worst-case

autoscaling

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The MinMax block is not scaled during autoscaling, if

- scaling information at all inputs is known or calculated
-- OR -- autoscaling is performed using range information
After applying autoscaling a second time in many cases the
block is scaled
correctly.
Workaround: Do autoscaling a second time. Otherwise no workaround
available.
1127 / 1260
ID:
PR20071009-02
Title:
Wrong code generated for Merge block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the following situation wrong code is generated for a Merge

block:
A Simulink Outport which has set "Output when disabled" to
"reset" and an
outport of a Stateflow chart drive the same Merge block.
The generated code is wrong, because the Stateflow chart's
output variable is
not updated with the Simulink Outport's variable after it has
been reset.
ID:
PR20071009-03
Title:
Double generated definition of a macro

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is a macro, where its variable class has the optimization
property set to
"MERGEABLE", and the module property is set.
If the macro is merged with another macro of the same name,
the macro definition
is generated twice. One definition is in the header file, while
the other one is
generated in the related source file.
The generated code is still compilable because the macro
definitions are
identical.
1128 / 1260
ID:
PR20071010-01
Title:
Overflow for positive max value in relational operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An overflow may occur for positive max value in a relational

operation, if the
- both operands are not constant values (i.e. not constants
with a default
variable class)
-- AND -- the value range of one of the operands has as positive max
value that is 128,
256, 32768, 65636, INT32MIN * -1, or UINT32 * -1
-- AND -- the value range of the other operand is smaller
The value range of an operand is the range of values that a
variable or an
expression can have at a certain position in the generated
code. Such a range
can be influenced by specifying Min and Max values.
Example:
Int16 Operand1; // Min = -1.0; Max = 1.0; LSB = 2^-14
const Int8 Operand2; // LSB = 2^-7
The relational operation
Operand1 < Operand2
would be implemented as
(Int8)(Operand1 >> 7) < Operand2
If Operand1 has the value 1.0 which is implemented as
16384, this value will be
shifted right by 7, which results in 128.
Since 128 does not fit into Int8 an overflow will occur and the
result of the
relational operation will most likely be wrong.
Workaround: Change the given Max value in a way that it avoids the critical
values.
For instance in the given example: Make the given range
slightly greater, for
example Min = -1.0 and Max = 1.01.
1129 / 1260
ID:
PR20071011-01
Title:
Missing TargetLink InPorts or OutPort after conversion when

signals are unconnected

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: TargetLink InPorts and/or OutPorts are not inserted during

Simulink to
TargetLink conversion when signals run into or originate from
subsystems where
they end unconnected.
Workaround: Please connect all signal lines before conversion.
ID:
PR20071012-01
Title:
Wrong code for outport of conditionally executed subsystem in

connection with external variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for an
outport X of a conditionally executed subsystem:
- An outport X of a conditionally executed subsystem has
specified an "Initial
output" Y.
-- AND -- X is driven by a block output mapped to a variable Z whose
variable class has
set "Storage" to "Extern" or "Alias" to "on"
-- OR -- X is driven by a subsystem outport mapped to a variable Z of
a subsystem whose
function class has set "Storage" to "Extern" or which is
configured for
incremental code generation.
-- AND -- Z has specified no initial value or Z has specified an initial
value which is
not equal to Y.
Workaround: Make sure that Z has the same initial value as X. If the block
outport which is
mapped to Z is an outport of a conditionally executed
subsystem enter Y as
"Initial output" in its block dialog. Otherwise, create Z as a
Data Dictionary
variable and enter Y as "Value" in the Data Dictionary variable
object.
1130 / 1260
ID:
PR20071017-01
Title:
Wrong code generated for Switch Case block with one outport

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for the
Switch Case block:
- The Switch Case block has exactly one outport.
-- AND -- There is exactly one Case constant specified for the outport.
Workaround: Activate check box "Show default case" in the Switch Case
block's block dialog.
ID:
PR20071017-02
Title:
Enabling incremental code generation in library system

enables "Generate Code" button

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Given is a Function block that resides in a library subsystem.

If such system is
used in a model and the Function block is opened, it is
possible to enable the
incremental code generation (check box). If enabled the
button "Generate Code"
is active. Generation of code using this button may result in
wrong code,
because the settings of the Function block are not saved due
to library link and
the code generator does not take the Function block settings
into account.
Workaround: Change the incremental settings of the Function block in the
library and update
the library.
ID:
PR20071022-06
Title:
Code coverage report may contain cropped source code lines

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
1131 / 1260
Description: If a source code contains custom code pattern, where the less
then character "<"
is used without space characters around, the code coverage
report may contain
cropped lines in browser window, because the statememt is
taken for HTML tag.
Example:
Custom Code pattern:
/* fxp_output_begin */
if( u1<u2 ) {
y = 1;
}
else {
y = 0;
}
/* fxp_output_end */
The code pattern in production code may be:
/* Custom code: Subsystem/Custom Code Block << output
code >> */
{
if(
Sa1_Custom_Code_Block_u<Sa1_Custom_Code_Block_u2 )
{
Sa1_Custom_Code_Block_y = 1;
}
else {
}
}
The code pattern of code coverage report is shown in browser
window as:
/* Custom code: Subsystem/Custom Code Block << output
code >> */
{
if( Sa1_Custom_Code_Block_u
}
else {
}
}
The statement "<Sa1_Custom_Code_Block_u2 ) {" is taken
for an HTLM tag and not
visible in browser window.
Workaround: Use a code formatting with space characters acround less
then character, e.g. "a
< b", instead of "a<b".
1132 / 1260
ID:
PR20071024-02
Title:
Wrong code generated for Saturation block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Whenever the output of an arithmetic block is saturated and

followed by a
saturation block, the generated code may be wrong if for the
driving arithmetic
block a saturated 64bit division is created.
Is this case TargetLink will issue the message
Warning #17352: multest/Divide Implementing 64-bit
operation division.
and the generated code will contain a division macro of the
pattern
C__...DIV...C32_SAT.();
like, for example
C__U32DIVU64C32_SATu(Aux_U32, Aux_U32_a, 10, 9,
4294967286, 4294967295,
Sb1_Out1_);
Saturated 64bit division can result from any saturated
arithmetic block if its
output or one of its operands has an arbitrary scaling. It can
also come up if a
Product block specifying a division is used.
Workaround: - Insert a Gain block between saturated block yielding 64bit
code and the
Saturation block. Set gain value to 1 and data type and
scaling as in Product
block.
- Adapt scaling and/or data types in a way that the 64 bit
division is avoided.
1133 / 1260
ID:
PR20071025-01
Title:
Wrong code generated for Switch block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for a
Switch block:
- The second inport is driven by a signal which has width one.
-- AND -- The "Threshold" value has width greater than one.
Workaround: Make sure that the widths of the second inport and the
"Treshold" value are
equal (adjust the width of the second inport or adjust the width
of the
"Threshold" value).
ID:
PR20071030-02
Title:
Data Dictionary Merge Explorer does not consider Data

Dictionary include files

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If you use the Data Dictionary Merge explorer for Data
Dictionary containing
includes files, these included files are not considered.
This may lead to the following effect:
Includes are done for the currently loaded Data Dictionary,
and this file is
compared to another file, also containing Data Dictionary
include files. Those
are not considered and therefore the corresponding content is
missing in the 2nd
file.
1134 / 1260
ID:
PR20071030-05
Title:
Wrong expansion of name macros $f and $F in declaration

statement of variable class

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: According to the Targetlink documentation, the name macros

$f and $F should be
expanded to the file name in a declaration statement.
However, if specified in a
declaration statement of a variable class, they are expanded
erroneously to the
variable name like macros $v and $V. The documentation text
is wrong and there
is no macro available, to insert the file name.
Workaround: Please do not specify $f or $F name macro for a variable
class and $v or $V name
macros for a function class.
ID:
PR20071031-05
Title:
Included Data Dictionary is saved in wrong folder

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: It may happen that an included Data Dictionary is saved in

wrong folder, if
- The file name of included Data Dictionary is set relative, e.g.
"MyVars.dd"
- An import of an XML file is done
After a save operation the included Data Dictionary resides in
the folder
relative to the folder of the imported XML file, e.g. if the XML
file resides in
a sub folder "XML", then the Data Dictionary "MyVars.dd" is
stored in that
folder.
Workaround: Use the Data Dictionary variable %MainDDDir%, if included
Data Dictionaries are
referenced relative to main Data Dictionary, e.g.
"%MainDDDir%/MyVars.dd"
1135 / 1260
ID:
PR20071106-02
Title:
Code generation aborts for an incremental subsystem with

fcn-call connections

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If there are fcn-call connections into an incremental

subsystem, the code
generation for this subsystem aborts with the fatal error
10007.
Function call connections going into an incremental
subsystem are not supported.
This is correctly checked, if code is generated for the
surrounding subsystem.
But generating code for the incremental subsystem itself,
leads currently to the
fatal error.
Workaround: Do not use function calls into incremental subsystems.
1136 / 1260
ID:
PR20071106-10
Title:
Duplicated signals may cause an internal error during frame

generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If within Simulink subsystem duplicated signals are muxed

(like schematically
shown below)
A -----+----->|
||
+----->|
+--------->( )
B -----+----->| Simulink outport
||
+----->|
Mux
and fed directly, not via TargetLink OutPort block, into a
subsystem, where a
root function will be generated for (for example into a
subsystem externally
called via a function call signal), the frame generation aborts
with an error:
*** E00000: ERROR USING I_GETSOURCESIGNAL
*** Internal Error:
output
signals.
*** Please conntact dSPACE technical support.
Workaround: Place a TargetLink OutPort block between the Mux block and
the Simulink outport
block inside the subsystem where the signals are duplicated.
1137 / 1260
ID:
PR20071109-45
Title:
Wrong code generated for Switch block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for the
Switch block:
- The output of the block has a width greater than one
-- AND -- The second input has a width of one
-- AND -- The Threshold parameter has a width greater than one.
The code is wrong because the second input is not scalar
expanded to the width
of the output.
Workaround: Make that the second input signal as wide as the block output.
ID:
PR20071109-77
Title:
Access violation if For Iterator resides in extern storage /

incremental subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are fulfilled the code generator
may abort
with an access violation:
- A For Iterator block resides in a subsystem whose storage
class is 'extern' or
which is configured for incremental code generation
-- AND -- The For Iterator block has 'Iteration limit source' set to
external.
Workaround: Specify Min / Max values in the block dialog of the block which
drives the For
Iterator block (outside the For Iterator subsystem).
1138 / 1260
ID:
PR20071112-13
Title:
Custom Code block S-function: limited access to matrix

parameters

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Parameters that are matrices (as opposed to vectors and

scalars) can not be
accessed in custom code S-functions using double indexing.
Compilation of custom
code S-functions fails in this case.
Example:
Parameter p whoes value which is a (2,3)-matrix. Accessing a
matrix element with
double indices, as for example
p[1][2]
results in a compiler error when the S-function is being built.
The reason for this limitation is that parameter values are
instance specific
and not known during S-function compile time, and that
parameter sizes can
currently not be specified for custom code S-functions.
Workaround: Use vector notation for matrices, i.e.
p[5]
in said example.
1139 / 1260
ID:
PR20071112-15
Title:
Missing cast operation on integration operation to the state's

data type of Discrete-Time Integrator

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the generated code for a Discrete-Time Integrator block a

final cast
operation to the state's data type is missing. The resulting
implicit downcast
may be warned by a compiler.
In the code you may find a pattern like following:
Int16 X_integrator_state;
...
/* Discrete Integrator: integration */
X_integrator_state = ((Int32) X_integrator_state) + ((Int32) ...);
The update of the state variable is done in extended bit width
to get right
result. Even if the state variable is of type Int16, there is no
cast of the
result done. The right pattern is:
/* Discrete Integrator: integration */
X_integrator_state = (Int16) ((Int32) X_integrator_state) +
((Int32) ...);
Although the calculation is still the same, now the compiler
gets a hint that
the downcast is intended and no warning is issued.
1140 / 1260
ID:
PR20071114-29
Title:
Conversion fails if a converted block modifies the block name during mask
initialization

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The conversion of a block fails, if the following conditions hold for the
replacement block:
- The block modifies its name during mask initialization.
-- AND -- The mask option "Allow library block to modify its contents" is enabled.
During conversion an error like following is issed and the the conversion
aborts:
Invalid Simulink object name:
example_TL/Subsystem/Subsystem/Subsystem/Marmeladedsvyvtrkqo.
Error in ==>
D:\MATLAB_R2006ap\toolbox\simulink\simulink\getfullname.p>getfullname
at 19
type = get_param(Handle, 'Type');
Error in ==> tl_add_block at 39
destpath = [getfullname(varargin{2}) '/Subsystem/' get_param(varargin{2},
'name')];
Error in ==> tl2sl>i_TL2SL at 737
h=
tl_add_block(blockLibmaps(i).slblock,blockname,propvalpairs{7:end});
Error in ==> tl2sl at 471
[msgstruct,bSuccess] = i_TL2SL(blocks,blockLibmaps,options,msgstruct);
Workaround: Do not modify the replacement block's name in its mask initialization. To
display block information, use the block annotation and the tag parameter.
1141 / 1260
ID:
PR20071115-10
Title:
Merge block with one input is not supported

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: In Simulink it is possible to use a Merge block with only one

input. A common
modeling style is, to drive the Merge block with a multiplexed
signal that
comprehends single signals of enabled or action triggerd
subsystems.
Alternatively you can configure the Merge block in such a way
that it gets the
required number of inputs, which makes the Mux block
superfluous.
Currently the model conversion handles a Merge block with
only one input and
substitutes it by a TargetLink Merge block with only one input.
The correct
behavior of conversion routine would be that an unsupported
parameter set is
reported and the conversion fails. However, if you try to
generate code for the
incorrect converted model, the code generation aborts with
following error:
Error #00000:
messages below ...
Cell contents reference from a non-cell array object.
Only based on this message it is not possible to find the main
problem.
Workaround: Eliminate the Mux block and use a Merge block with multiple
inputs instead.
1142 / 1260
ID:
PR20071119-06
Title:
Duplicated typedefs after AUTOSAR import

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a Data Dictionary project file contains a set of Typedef

objects located in a
TypedefGroup assigned to an AUTOSAR package P1, the
import of an AUTOSAR file
containing the same set of types in the same package P1
results in duplicated
Typedef objects of these types at the inappropriate location
directly under
/Pool/Typedefs. This problem only occurs when package
support is enabled.
Workaround: In the Data Dictionary delete the Typedef objects defined both
in the Data
Dictionary and the AUTOSAR file before importing the
AUTOSAR file.
1143 / 1260
ID:
PR20071119-08
Title:
Code generation for LUT with user scripts fails if parameters use the same Data Dictionary
variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is a model that contains a Look-up Table block, which uses a user script.
Code generation aborts if following conditions hold:
- More than one parameter is generated (e.g. row and column)
-- AND -- The parameters reference the same Data Dictionary variable
This leads to the following error during code generation:
Error #05013: Subsystem/Look-Up Table (2-D):
Object need not be created, because there is already such an object.
Object =
/Subsystems/CGTmpData/tlscript_Look_Up_Table__2_D_/Variables/MyDDVariableForRwAn
dColumn
The error is then followed by E10013 and E10014
Example:
In a Look-up Table (2D) block, the row and column vector should use the same
variable. In the user script two objects are generated, which reference both the
same Data Dictionary variable. The problem arises, due to the internal handling
of the objects. In general it is not necessary to create two objects of the same
content.
Workaround: Duplicate the variable in Data Dictionary and reference the original and the
copied variable for the objects (e.g. row and column).
For the name template you can use the same name for both variables, so in the
generated code there is only one variable used.
1144 / 1260
ID:
PR20071119-21
Title:
Wrong code generated for For Iterator and While Iterator

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If all of the following conditions are fulfilled wrong code may
be generated for
a For Iterator or While Iterator:
- The For Iterator or While Iterator has an output which drives
a Simulink
outport of the For Iterator or While Iterator subsystem
-- AND -- For Iterator: 'Iteration limit source' is set to 'external'; While
Iterator:
'While loop type' is set to 'while'.
Workaround: Insert a TargetLink OutPort or a Gain block behind the For or
While Iterator.
ID:
PR20071119-27
Title:
Scaling propagation function not taken into account in reused

subsystems

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Imagine a model containing a reused subsystem from library.

The subsystem
contains a Function block where the property "Scaling
invariant" is set and a
scaling propagation function is given. Nevertheless, the
propagation function is
not taken into account during autoscaling and therefore no
scaling or range
information is propagated through the subsystem.
1145 / 1260
ID:
PR20071120-03
Title:
Misleading error #03051 for Constant block after conversion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Use case: a Constant block whose output is scaled with an

non-power-of-two
(arbitrary) LSB value is converted to TargetLink. Although the
Simulink
subsystem is completely converted to TargetLink, and the
Simulink scaling
parameter of the Constant are correctly mapped to
TargetLink, an error message
is produced:
Error #03051: <block>: 10*2^-3 = 1.25:
TargetLink LSB could not be set to 1.25 (corresponds with
Simulink fixed point
setting): TargetLink API error: New value for property 'lsb'
must be a power of
2, because the arbitrary flag is 'off'!.
Workaround: Ignore the message.
ID:
PR20071120-07
Title:
Wrong code may be generated for Bus Inport or Bus Outport

block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for a
Bus Inport or Bus Outport block:
- One or more of the bus components have activated 'Inherit
properties'
-- AND -- One or more of the bus components are driven by a block
output which has set
'Bitfield' as output data type.
Workaround: Do not activate 'Inherit properties' for a Bus Inport or Bus
Outport block if it
is driven by signals of type 'Bitfield'.
1146 / 1260
ID:
PR20071120-08
Title:
Stateflow variable dialog cannot be opened

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: A Stateflow variable dialog won't be shown if following

conditions hold:
- The variable dialog is opened using the Model Browser View
in the Data
Dictionary Manager
-- AND -- The variable has a non empty value
-- AND -- The variable has no width specified
An error message is issued in the MATLAB command like the
following:
??? Error using ==> mtimes
Inner matrix dimensions must agree.
Error in ==> dsdd_sync_variable>i_SyncSF2DD at 538
sfValue = sfValue*ones(1,width);
1147 / 1260
ID:
PR20071120-09
Title:
Actual parameter of a call-by-reference parameter of an

enabled or triggered system might have wrong init value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the following rare situation a wrong initial value is set for an
actual
paramater:
An enabled (or triggered) system Y is placed inside an
enabled (or triggered)
system X.
The inner system Y contains a Simulink outport with an
TargetLink BusOutport
block as the associated predecessor. In the BusOutport block
several variables
are specified, but not a bus struct. A variable, which is not the
first one, has
scope fcn_ref_arg (call-by-reference). In the Simulink outport
init values have
been specified for these variables. The corresponding init
value of the
fcn_ref_arg parameter is different from the init value of the first
variable.
The outgoing signal is split in system X by a Bus Selector.
Here the first
variable and the fcn_ref_arg parameter are selected. Both
signal lines do end in
non-virtual TargetLink OutPort blocks connected to Simulink
outports of the
system X. There is no block on the signal lines between the
Bus Selector and the
TargetLink OutPort blocks.
In the TargetLink OutPort of the system X the variable
corresponding to the
fcn_ref_arg parameter is specified as in the inner system Y,
except of global
scope. In its associated Simulink Outport the init value of the
first variable
in the inner system Y is specified. So the init value in the
system X is
different to that one in the system Y.
In this case TargetLink takes the variable of the system X as
the actual
parameter of the step function call of system Y. But the actual
parameter in the
production code has a different init value than the one in the
model. This might
lead to differences between MIL and SIL simulation.
1148 / 1260
ID:
PR20071120-10
Title:
Export of AUTOSAR subpackages fails

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the Package property of a Data Dictionary object

(GroupInfo,
SoftwareComponent) specifies an AUTOSAR subpackage, i.
e. contains a
hierarchical path e. g. "package1/subpackage1", the
AUTOSAR export with enabled
package support does not work properly. As a result, the
references in the
generated AUTOSAR XML files might be broken or even the
export might abort.
Workaround: Do not use nested packages. Specify one package name only
without any
subpackages.
ID:
PR20071121-12
Title:
Code generation aborts for user look-up function script, if a

void function is used in an expression that expects a function
return value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a user look-up function script used for a Look-Up block or a

Stateflow
expression specifies a void function that is used in an
expression that expects,
that the function returs a value like e.g. an assigment, the
code generation may
abort without a meaningful error message.
Example:
If a script specifies the function
Void MyFunc(Int16 Param1);
and the function is used in an expression like
out = MyFunc(ActParam);
then the code generation may abort, because the expression
expects, that the
function returns a value, which contradicts the declaration of
the function.
Workaround: Check the user look-up script, whether there are such
inconsistencies.
1149 / 1260
ID:
PR20071122-03
Title:
No loop generated for vector signal at a Rate Limiter block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If loop generation is activated (default), no loop for a Rate

Limiter block is
generated, independent of the option "LoopUnrollThreshold".
ID:
PR20071122-12
Title:
Modification of the target source directory within a

pre_codegen_hook has not effect

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: It is possible to modify code generator parameters in

pre_codegen_hook, but in
rare cases this has no effect.
It is not possible to modify the directory where the file
TargetConfig.xml
resides in (TargetDir), which contains the definition of the
base types to be
used for the production code generation.
During production code generation a message like
Using base types from directory:<modifiedDirectoryName>
is issued, but although the modified directory name is written
in this note, the
file TargetConfig.xml is read out of the directory which is
specified by the
code generator option set in the TargetLink Main Dialog at the
begin of the code
generation process.
The problem is based on the fact, that some parameters are
evaluated before the
hook function.
Workaround: Set the right configuration in TargetLink Main Dialog before
start of code
generation, e.g. via API
tl_set(gcb,'codeopt.target',<...>);
tl_generate_code;
1150 / 1260
ID:
PR20071123-14
Title:
Missing loop generation for init section of Selector block with

external source of element indices

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the first inport (U) of a Selector block with external source of
element
indices is driven by an not well-defined signal, no loops for the
init section
code are generated.
Example:
Given is a combined input signal, which contains two vectors.
/* Selector: Subsystem/Selector - init phase: */
Sa1_Selector_a[0] = Sa1_a[0];
Sa1_Selector_a[5] = Sa1_b[0];
Instead of these single statements, two loops should be
implemented for the code
of the init section.
An input signal is well-defined, if it consists of only one single
vector with
same scaling for all elements.
Workaround: Insert an auxiliary block before the first inport of the Selector
block to avoid
the creation of the auxiliary variable (here Sa1_Selector_a) for
the not
well-defined input signal.
1151 / 1260
ID:
PR20071126-07
Title:
TargetLink inheritscaling property not set for Unit Delay block

that passes a bus signal

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: During conversion from Simulink to TargetLink, the

inheritscaling property of a
Unit Delay block that passes a bus signal must be set to "on"
to enable code
generation. However, conversion fails to detect such Unit
Delay and thus leaves
the inheritscaling property unmodified. Subsequent code
generation results in
errors.
Workaround: Edit the Unit Delay block manually, or set the inheritscaling
property in a
custom post conversion hook script.
ID:
PR20071127-01
Title:
Incorrect implemented range shown in block dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: A wrong implemented range is shown in a block dialog, if the

following
conditions hold:
- An integer type is selected, which has constraints
-- AND -- The constraints specify a scaling of LSB = 2^0 and Offset =
0, as well as a
range of [0, 1]
In this case the type is detected as boolean and the
implemented range of the
integer type is shown, instead of the range [0, 1].
It is only a problem of the display in the dialog.
1152 / 1260
ID:
PR20071128-02
Title:
Arithmetic operation with constant operands ignores fixedpoint overflow if the result is floating-point

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is following example code:

Int16 Out1;
Float32 Out2;
Out1 = In1 + In2;
Out2 = Out1;
If In1 and In2 are constant the result can be precalculated. If
this is done and
the result does not fit into the result type, e.g. Int16, an
overflow occurs.
If Out1 can be eleminated, no overflow may occur.
For example the code pattern above, can be simplified to:
Out2 = In1 + In2;
if In1 = 30000 and In2 = 30000 then Out2 will be 60000
although it should be
-5536 due to the Int16 overflow.
1153 / 1260
ID:
PR20071128-08
Title:
Output data type of Flip-Flop block does not reflect Simulink

behaviour

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: Wheras the output of a Simulink S-R Flip-Flop depends on the

modelwide option
"Implement logic signals as boolan data (vs. double)" the
output signal of the
TargetLink S-R Flip-Flop block in full-featured mode is always
double. There is
no option like "Cast output signal to TargetLink type" which
usually allows the
user to influence the output data type. This may be a problem
connecting this
block to another block that needs a boolean data type at its
input.
Although the output data type behaviour is documented in
TargetLink Block and
Object Reference, it yields to a limitation in modeling and to
the need of
additional Data Type Conversion blocks. In stand-alone mode
the TargetLink S-R
Flip-Flop acts like the Simulink counterpart.
Workaround: - Add a Data Type Conversion block to change the data type
in Simulink.
-- OR -- Uncheck the Simulink configuration parameter "Implement
logic signals as
boolan data (vs. double)".
1154 / 1260
ID:
PR20071129-08
Title:
Formal parameter of an access function has implicit class

SLLocal and can be mapped via a template

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The formal parameter of an access function has the implicit

variable class
SLLocal. Such a variable class can be mapped using a
variable class template.
Applying a template for SLLocal, the class of a formal
parameter of an access
functions can be changed from SLLocal to e.g. SLGlobal.
This may lead to code that cannot be compiled, because the
name of the formal
parameter is changed to make it unique, but the body of the
access function
still contains the original name.
Example:
An access function set member is specified as follows:
Kind = WRITE
FunctionName = "Set$V"
FunctionClass = GLOBAL_MACRO
MacroBody = "SetBit($v, _value)"
TargetLink will generate an access function macros of the
following kind:
#define Set_<variable name>(_value) SetBit(<variable
name>, _value)
Here _value is the formal parameter, which is only visible
within the access
function. If the variable class SLLocal is now mapped to e.g.
SLGlobal,
TargetLink generates a variable of global scope. If there are
more than one of
such access functions, multiple variables are created, which
must have different
names. Therefore TargetLink extends the variable name with
suffix _a, _b and so
on.
In case of two access functions it might look like the following:
#define Set_In1(_value) SetBit(In1, _value)
#define Set_In2(_value_a) SetBit(In2, _value)
The macro name is generated by TargetLink and uses the
global variable name,
whereas in the macro body only the macros like $v are
replaced. The second macro
will cause a compiler error, because _value is not known.
Workaround: Do not use variable class templates for SLLocal if access
functions are used.
1155 / 1260
ID:
PR20071130-16
Title:
Incomplete AUTOSAR interface specification of

SenderReceiverInterface leads to internal error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If no DataElement of SenderReceiverInterface is specified

generate code leads to
internal error, like the following:
E02900 SWC RECEIVER PORT BLOCK MESSAGE
Internal error. Contact dSPACE Support.
OBJECT: ILC_A3/ILC_A3/R_eeprom
E01225 SIMULINK MODEL INITIALIZATION FAILED
Simulation aborted.
There is not hint how to solve the problem.
Workaround: Create "DataElement" in Data Dictionary object which is
related to the error
message, e.g.
/Pool/Interfaces/COP/IF_ILC_A3_eeprom/DataElements
1156 / 1260
ID:
PR20071130-24
Title:
Generation of model-linked code view may fail for custom

code pattern

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The generation of model-linked code view may fail if a macro

is defined out of
TargetLink scope using custom code. Out of TargetLink scope
means, that
TargetLink does not know about the macro. For instance this
is the case in
custom code, because the code pattern is not analyzed and
treated as text that
will be inserted in the code.
A warning like the following will be issued:
*** '<file>.c'
Workaround: It is possible to mask code pattern that should be not taken
into account during
HTML view generation:
Before the pattern insert the following comment:
/*#TL#Custom Code#TL#*/
After the pattern insert the following comment:
/*#TL#End Custom Code#TL#*/
1157 / 1260
ID:
PR20071205-02
Title:
Integer overflow exception during SIL simulation leads to a

MATLAB hang-up

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If an integer overflow exception occurs during a SIL simulation

it causes MATLAB
to hang-up.
Example:
This kind of exception occurs in production code if the result of
the division
of two integer values does not fit into the resulting Int32 output
variable:
Int32 result;
Int32 minInt32 = -2147483648;
result = minInt32/-1; /* 2147483648 value does not fit into the
resulting
Int32 variable! */
The MIL simulation reports an overflow error. In contrast the
SIL simulation
seems to stop, but runs into an endless loop and MATLAB
hangs up.
1158 / 1260
ID:
PR20071206-02
Title:
Missing loop generation for a signal consists of same vector

components and additional signals

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In a mixed vector signal, which consists of different elements

(constants,
scalars, vectors), no loop is generated for that part of the
vector, which
consists of the same vector element. The following examples
describe some cases
for which kind of signals loop generation is missing and single
statements are
implemented:
1) Signal consists of following elements:
[VecVar[n], VecVar[n], ..., VecVar[n], ScalVar, ScalVar, ...,
ScalVar]
A loop is generated for ScalVar, but not for VecVar[n]
[ConstVar, ConstVar, ..., ConstVar, VecVar[n], VecVar[n], ...,
VecVar[n]]
A loop is generated for ConstVar, but not for VecVar[n]
[VecVar[1], VecVar[2], ..., VecVar[m], VecVar[n], VecVar[n],
..., VecVar[n]]
A loop is generated for VecVar elements with increasing
indices, but not for
multiple VecVar[n]
All other mixed signals with constants, scalars and vector
variables lead to
loop generation (if the loop generation conditions are met).
Signals consists only of the same vector element like
[VecVar[n], VecVar[n],
..., VecVar[n]] lead to loop generation as well (if the loop
generation
conditions are met).
Workaround: Insert an auxiliary block for the signal to allow loop generation
for successor
blocks.
1159 / 1260
ID:
PR20071206-03
Title:
Inefficient index offset in assignments within loops

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Within a loop an inefficient index offset may be generated for

an assignment
with constant expression on the right hand side.
Example:
The following code is generated:
for (Aux_S32 = 0; Aux_S32 <= 5; (Aux_S32)++)
{
/* Gain: Subsystem/Gain [3..8] : folded operation multiplication
to
constant value 0.5 */
Sa1_Gain[Aux_S32 + 3] = 0.5F;
}
but would be better without index offset at the iteration
variable:
{
/* Gain: Subsystem/Gain [3..8] : folded operation multiplication
to
constant value 0.5 */
Sa1_Gain[Aux_S32] = 0.5F;
}
1160 / 1260
ID:
PR20071206-05
Title:
Uncorrect syntax of the generated A2L file if identical

measurable variable is used as axis of look-up table and as a
block output

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If an identical variable which is specified to be measurable (for

instance the
variable class is DISP) is associated with the axis parameter
of a Look-Up Table
block (row, column for Look-Up Table (2D) block or x-axis for
Look-Up Table
block) or with break point data parameter of the Index Search
block, and
additional with the output of any TargetLink block, for example
TargetLink
Constant block, in the generated A2L two entries are
generated for this
variable: MEASUREMENT and AXIS_PTS entry.
This is not correct and leads to problems during loading the
generated A2L file
to the 3th part tools, for instance calibration systems.
The same applies if identical measurable variables are
associated with the
y-axis parameter of the 1D Look-Up Table block and with the
output of any
TargetLink block. In this case in the generated A2L file also
two entries will
be generated for this variable: MEASUREMENT and
CHARACTERISTIC.
Workaround: 1) Make this affected variable GLOBAL, instead of DISP.
2) Postprocess the generated A2L file. Please contact
TargetLink technical
support for details.
1161 / 1260
ID:
PR20071206-10
Title:
Import of A2L file on Windows Vista may lead to misleading

error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If on Windows Vista an A2L file is imported into the Data

Dictionary a
misleading error may be issued, e.g. access violation or
parser error.
Workaround: Import the A2L file again.
patches:
TargetLink 2.3.1p7
ID:
PR20071206-13
Title:
RTF documentation generation using tldoc_rtf may fail

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: RTF documentation generation using tldoc_rtl may fail with an

error like the
following:
ERROR USING I_WORD
Error when converting document
C:\dSPACE\Demos\tl\DCMC\doc\DCMC_main.html
with Microsoft Word.
MATLAB error message was:
Invoke Error, Dispatch Exception:
Soruce: Microsoft Word
Description: Falscher Parameter.
Help File: C:\Program Files\Microsoft
Office\OFFICE11\1031\wdmain11.chm
Help Context ID: 9018
The problem occurs during a macro call from
ds_convert_file.m to
ds_convert_file_macro.dot. It depends on the way the macro
is called (compliant
to DDE rules or not).
1162 / 1260
ID:
PR20071207-22
Title:
Code generation terminates with an access violation due to

the use of many and/or large MATLAB workspace variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: MATLAB workspace variables have a contribution to memory

consumption independent
of the fact whether the workspace variables are used in the
model or not. In
case you are using many and/or large MATLAB workspace
variables this can lead to
a access violation during TargetLink code generation,
because suffiencent memory
is unavailable.
Workaround: For the code generation unload the MATLAB workspace
variables not required for
the code generation (variables not used in the model) and
reload them after the
code generation.
ID:
PR20071210-15
Title:
Wrong code may generated for Multiport Switch block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for the
Multiport Switch block:
- The block has exactly one data input (beside its control
input)
-- AND -- The data input is driven by a block output which signal
elements have
different scalings.
The generated code is wrong because the different scalings
are not taken into
acount.
Workaround: If a Multiport Switch block has exactly one data input ensure
equal scalings at
the driving block's output.
1163 / 1260
ID:
PR20071211-05
Title:
Wrong code for multiplication using unsigned output data type

with arbitrary scaling and negative offset

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Wrong code is generated for a multiplication if following

conditions hold:
- The output data type is unsigned
- The output has an arbitrary scaling and a negative offset
Example:
Out = (Const*In - Const*32767)/1000 + 32767
This calculation has an overflow, but compute-throughoverflow is not possible.
(Const*In - Const*32767) is calculated in unsigned and the
result is cast to
unsigned, which is wrong because the result is negative.
The correct code would be
Out = (Const*In)/1000 - (Const * 32767)/1000 + 32767,
where compute-through-overflow is possible and yields to a
correct result.
The problem occurs at a multiplication in Stateflow, at a
Product block with two
operands and at a Gain block whose gain value has a variable
class other than
"default", so that the gain value is the second operand of a
multiplication.
Workaround: Use a signed data type for the Stateflow variable, the Product
block output or
the Gain block output to avoid negative index offsets for their
multiplications.
1164 / 1260
ID:
PR20071212-03
Title:
Limits of values may be wrong rounded in A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The limit values for following elements may be incorrect in

A2L file:
- CHARACTERISTIC
- MEASUREMENT
- AXIS_PTS
- AXIS_DESC
The values may be rounded, which might result in an
extended range.
Example:
Correct limit value | Value in A2L file
-------------------------------------1.984375 | 1.98438
1.9843753 | 1.98438
4294967295 | 4.29497e+009
-1.015625 | -1.01563
This problem is caused by the used format string (%g) during
the output of the
limit value into A2L file.
The possible rounding may occur for lower and/or upper limit
as well as as for
the extended limits.
Workaround: One solution would be a postprocessing of the generated A2L,
otherwise no
1165 / 1260
ID:
PR20071213-11
Title:
Variable with Alias property does not appear in generated

documentation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: An observable variable with variable class attribute Alias =

"on" defined inside
the DataDictionary does not appear in the generated
Documentation and/or
generated A2L file. The code generator is unable to identify
the definition
module of this variable and hence it is not listed in the Data
Dictionary
Subsystems area.
ID:
PR20071217-07
Title:
Multiport Switch or Switch block with constrained range limits

may cause wrong code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Wrong code results from a TargetLink Multiport Switch or

Switch block, if
- Constrained range limits (Min and/or Max values) are
specified for block's
output
-- AND -- The output variable class has the ERASABLE flag set for the
optimization
property
-- AND -- The output is not logged
-- AND -- The output of the succeeding block has no constrained
range limits or greater
constrained range limits (lesser Min value and/or greater Max
value)
In this case the succeeding block inherits the constrained
range limits from
Multiport Switch or Switch block, which is wrong and might
result in wrong code.
Workaround: Use a not erasable or global or static variable class for the
Multiport Switch
and/or Switch block output or remove constrained range limits.
1166 / 1260
ID:
PR20071218-10
Title:
At Gain block the autoscaling tool does not take arbitrary flag
and LSB of gain value into account

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The Autoscaling Tool might calculate wrong scaling

parameters for Gain block
output variable if following conditions hold:
- The variable class of the gain value is default
-- AND -- The gain value is greater than 1
-- AND -- The gain value is not a power of two
-- AND -- The arbitrary flag of output variable is not set
This might result in differences between SIL and MIL
simulation at the output of
the Gain block.
Workaround: Please adapt the scaling of the Gain block output manually.
ID:
PR20071218-13
Title:
Wrong code generated for For / While Iterator block if

maximum number of iterations is zero

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

generated for a
For / While Iterator block:
- "States when starting" is set to "reset"
-- AND -- "Iteration limit source" (For Iterator) is set to "internal"
-- AND -- "Iteration limit" (For Iterator) / "Maximum number of
iterations" (While
Iterator) is set to 0 (zero).
The generated code is wrong, because the call of the
subsystem's init function
is missing.
Workaround: Set "Iteration limit" (For Iterator) / "Maximum number of
iterations" (While
Iterator) to a value not equal to 0.
1167 / 1260
ID:
PR20071218-15
Title:
Number of root level ports is limited

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: The maximum number of Inports or Outports on root level of

the TargetLink
subsystem are limited to 818. The problem occurs during
model conversion of a
Simulink subsystem to TargetLink, if the port number exceeds
the maximum number
of ports. If the TargetLink subsystem already exists and the
maximum is reached
by adding new ports, the problem occurs if the simulation
mode is switched to
SIL.
The problem can be identified by the following error message:
??? Error using ==> set_param
Input bounds are out of range.
Error in ==> tl_check_ports at 308
set_param(hEnableSys,'Position',pos);
Workaround: The number of Inports and/or Outports must be reduced, for
example by using a
Busport.
1168 / 1260
ID:
PR20071220-02
Title:
Wrong code after call of a 64-bit multiplication function

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the generated code contains a call of a 64-bit multiplication

function, the
following code might be wrong.
Such a 64-bit multiplication function can be identified by
searching the code
for a function call, where the function name starts with "F__"
and contains the
string "64" as well as "MUL". The parameters are called-byreference.
The code after the function call might be wrong, because the
expected result
range of this function call is assumed to be greater as it really
is. This can
result in code that does not compile. For example the code
contains a macro or
function call, which name is pattern based like the 64-bit
function name, but
does not exist, which results in a compiler or linker error.
Workaround: Avoid a 64-bit multiplication function by adapting the scaling of
the associated
block or its predecessors.
ID:
PR20071225-01
Title:
Segmentation violation during Simulink to TargetLink

conversion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: On rare occasions, Simulink to TargetLink conversion of a

subsystem in a model
(as opposed to a library) results in Simulink access violations.
The reason for
this bug is that the Simulink API sometimes crashes when
signals are checked if
they are bus signals.
The bug comes only up when the subsystem that is being
converted has bus
signals.
1169 / 1260
ID:
PR20080103-02
Title:
Wrong input overflow warning due to not synchronized

constrained range limits of referenced Data Dictionary variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The input overflow detection doesn't synchronize the

constrained range limits
(Min/Max values) of a referenced Data Dictionary variable
object at simulation
start. This may result in wrong input overflow messages. All
blocks are
affected, which support input overflow detection:
- Look-Up Table blocks
- FIR filter block
- Custom Code block.
Workaround: As a workaround, you can iterate over all affected blocks, read
the
TargetLink-specific settings and set them new.
ID:
PR20080109-10
Title:
AUTOSAR import of COMPU-METHODs with conversion type

TAB_VERB

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR import maps COMPU-METHOD elements with

conversion type "TAB_VERB" to
Scaling objects in the Data Dicitonary. The Scaling object's
ConversionTable and
ConversionStrings properties are used to store the COMPUCONST values and
LIMITS.
If the Scaling objects already exists in the Data Dictionary, the
AUTOSAR import
simply appends the ConversionTable and ConversionStrings
entries again instead
of overwriting it.
Workaround: In the Data Dictionary delete the Scaling objects that directly
correspond to
the COMPU-METHOD elements in the AUTOSAR XML-file
before performing the import.
1170 / 1260
ID:
PR20080114-01
Title:
Multiple use of Client Port block raises fatal error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a TargetLink subsystem contains two or more Client Port

blocks calling the
same operation at the same client port with different settings
of the property
"Show function call trigger port", code generation aborts with
the following
error message:
Fatal #10007: Internal error. ...
Workaround: Deselect "Show function call trigger port" at the respective
Client Port blocks.
Embed those Client Port blocks that shall be triggered in an
additional,
triggered subsystem.
1171 / 1260
ID:
PR20080114-11
Title:
Data type mismatch error during code generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: It may happen that a data type missmatch error is issued by Simulink, which
occurs during code generation, but not during common model initialization, e.g.
update diagram.
Imagine an AUTOSAR model using Simulink fixed-point data types, e.g. as inputs
and outputs of a Stateflow chart. A TargetLink Runnable Inport or Outport is
implemented as a direct signal connaction, thus such block is transparent for
signals with fixed-point data type in MIL simulation. An initialization is
possible. However, when code generation is started, TargetLink changes the
internal implementation of a Runnable port, which may leads to a data type
mismatch errors like
Error #01225:
--> Data type mismatch. Output port 1 of
'data_type_mismatch/controller/Subsystem/controller/Test_Runnable/Read_logical/R
te_Function1/Outport/In' is a signal of data type 'double'. However, it is
driving a signal of data type 'boolean'.
Workaround: It has to be pointed out, that TargetLink currently does not support a MIL
simulation with fixed-point data types. Therefore fixed-point data types may be
the reason for problems in a TargetLink subsystem. This is mainly based on the
fact that many TargetLink blocks cannot handle input signals with a fixed-point
data type. The TargetLink fixed-point types and a SIL and/or PIL simulation with
fixed-point types within the TargetLink code remain unaffected. Only Simulink
fixed-point types, which needs a fixed-point library license, are addressed.
Based on this knowledge a workaround would be to insert Data Type Conversion
blocks before a Runnable port to convert the data type to floating-point or
integer. Another workaround is to make the runnable ports virtual.
1172 / 1260
ID:
PR20080114-20
Title:
Macro C__I64NEGU32 from the DSFxp library calculates

wrong result -1 for input value 0

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The macro C__I64NEGU32 from the DSFxp-library is used to

perform an unary minus
operation on an unsigned 32-bit value. This macro returns -1
for an input value
0, which is wrong.
Typically this macro may be generated for Gain blocks with
32-bit signals and a
negative Gain value or for filter blocks with 32-bit state
variables.
Workaround: Search for the macro within the generated code. Try to avoid
the use of the
macro C__I64NEGU32 by a different way of modelling or
make sure, the input value
of the macro can never become 0.
ID:
PR20080117-05
Title:
Simulation differences if Stateflow outport drives Simulink

outport with different inital values

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the following conditions are fulfilled the SIL and PIL
simulation behavior of
the generated code may differ from Simulink:
- An outport X of a Stateflow chart drives directy or indirecty
an outport Y of
a condionally executed subsystem (e.g. an enabled
subsystem)
-- AND -- The initial values of X and Y differ (Simulink outport: "Initial
output",
Stateflow outport: "Value attribues"->"Initial Value").
- Enter equal inial values for the Stateflow outport and for the
Simulink
outport.
- Insert a Gain block with Gain factor 1 between the Stateflow
outport and the
Simulink outport.
1173 / 1260
ID:
PR20080117-06
Title:
Code coverage count may be inconsistent when using


TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When preprocessor control flow is modeled, TargetLink does

not produce coverage
macros for the control flow branches themselves. However,
when the preprocessor
control flow contains regular control flow statements, the inner
control flow
will be considered for code coverage.
TargetLink may produce a gap in the coverage counter
between these controlflow
statements and the statement following the preprocessor
control flow.
As a consequence, the coverage report may show wrong
results.
Example (extract of code):
TL_CODE_COVERAGE(a, 1);
#ifdef Cond2
if (Sa2_Constant1) {
/* TL_CODE_COVERAGE(a, 3); */
Sa1_Merge = (Int16) (Sa1_InPort << 1);
}
else {
Sa1_Merge = (Int16) (Sa1_InPort << 1);
}
#else
Sa1_Merge = (Int16) (((UInt16) Sa1_InPort) + ((UInt16)
Sa1_InPort2));
#endif
if (Sa1_Constant1) {
The last coverage macro shows a count of 6, but it should be
4, because coverage
macro number 2 and 5 are missing.
1174 / 1260
ID:
PR20080117-07
Title:
Wrong line connection after Simulink to TargetLink conversion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: After Simulink to TargetLink conversion, a signal line that

starts from a
TargetLink Inport that has been inserted is sometimes
connected to the wrong
destination block. The reason for this bug is that a workaround
for a Simulink
shortcoming does not work correctly under rare conditions.
The bug results in an TargetLink subsystem interface that
does not match the
interface of the original Simulink subsystem, and thus in
incorrect code.
Workaround: Please check manually whether all connections emanating
form an inserted
TargetLink Inport block are correct, otherwise no workaround
available.
1175 / 1260
ID:
PR20080117-14
Title:
Errors during A2L export not noticable for user

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: During export of an A2L file, errors may occur, but export
process does not
abort and continues if possible. In this case the generated A2L
file may be
incomplete. However such errors are not reported, neither in
the message
browser, nor in MATLAB command window, nor in the Data
Dictionary Manager
message window. They are only listed in the log file
"a2lexport.log".
If the A2l export is called using an API function like
dsdd('Export', ...) or
dsdd_export_a2l_file, it is difficult to check whether an error
occured or not,
especially due to the fact that the API funtions returns without
an error code.
Workaround: When using the MATLAB API command for A2L export, it is
possible to obtain
messages like errors afterwards.
To do this, following commands must be executed:
msgList = dsdd('GetMessageList'); % get all data dictionary
messages
idx1 = find([msgList.number] > 8600);
idx2 = find([msgList.number] < 8700);
a2lIdx = intersect(idx1,idx2);
a2lMsgList = msgList(a2lIdx);
ID:
PR20080121-11
Title:
Misleading error message #15303 if Inport block port

dimension describes a matrix signal

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: If in an Inport block a port dimension is specified, which

describes a matrix
signal, the code generation aborts with the error:
#15303:. Simulink data corrupted.
This error message is misleading, because in this case the
Simulink data is not
corrupt. Correct is, that TargetLink does not support matrix
signals.
Workaround: Use only port dimensions which describes a scalar or vector
signal. Matrix
signals are not supported by TargetLink.
1176 / 1260
ID:
PR20080121-12
Title:
Name macros $B and $L are not evaluated in message

variable name

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: For a message variables (variables for intertask

communication in multirate
models) the name macros $B and $L are not evaluated
correctly. Neither the block
name ($B) nor the signal name ($L) are taken into account to
create the message
variable name.
Workaround: Do not use the name macros $B or $L for a message variable.
ID:
PR20080121-14
Title:
Faulty macro redefinition

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When generating code for an multirate OSEK model,

TargetLink generates the macro
"OSDEFAULTAPPMODE". It is possible to specify such
macro explicit in the Data
Dictionary in node /Pool/RTOS/ApplicationModes. However, if
this is the case
TargetLink generates this macro twice. One macro is implicit
generated, the
second is the explicit one.
Example:
/***************** Definition of Application Modes
****************************/
#define OSDEFAULTAPPMODE (AppModeType)0u
#define OSDEFAULTAPPMODE (AppModeType)1u
This leads to a compiler warning (MSVC) or an error (LCC)
during a build
process.
Workaround: Delete the Data Dictionary node
/Pool/RTOS/ApplicationModes/OSDEFAULTAPPMODE
ID:
PR20080122-03
Title:
Update statement erroneously moved into control flow branch

1177 / 1260
TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the initially (before optimization) generated code contains a

statement with
both a writing and a reading access to a variable (so-called
update statement)
and this variable is further used in a conditionally executed
control flow
branch, then it is possible, that the statement is erroneously
moved into this
control flow branch.
Example:
Within a Stateflow chart, there is a During directive for a
counter. For a
transition, this counter is only used if a certain condition holds.
This leads
to code like the following on optimization level 0:
static Int32 counter = 0;
counter = counter + 1;
if (c) {
marker = counter;
}
else {
...
}
With higher optimization level, it is possible that following
wrong code might
be generated:
if (c) {
static Int32 counter = 0;
counter = counter + 1;
marker = counter;
}
else {
...
}
Now the counter is incremented if the condition holds instead
of every execution
step of the chart.
This is similarly possible for a function writing to and reading
from one of
their arguments if the function has a function class that has
set MOVABLE
optimization property - in this case, the MOVABLE property
has been set wrongly.
Workaround: Use a variable class without set MOVABLE optimization
property for the variable
in question.
1178 / 1260
ID:
PR20080124-02
Title:
AUTOSAR import ignores EventReceiverComSpec

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR import does not create any

EventReceiverComSpec objects.
EVENT-RECEIVER-COM-SPEC elements are not transferred
to the Data Dictionary.
ID:
PR20080124-08
Title:
Missing optimization in index access of vector component

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In an operation an array index accesses may not be optimized

like in previous
TargetLink versions.
Example:
Sb4_Gain = Sb5_Switch[1 /* 1. */ - 1];
instead of
Sb4_Gain = Sb5_Switch[0];
This occurs mostly for one-based indexing but can also occur
for other
calculations of index values.
Workaround: No complete workaround available.
In some cases it may help to set the code generator option
"DisableFunctionsAsAnalysisBoundaries" to "off".
In other cases it may help to set the code generator options
"DisableFunctionsAsAnalysisBoundaries" to "off" and
"EfficientVectorHandling" to
"off".
Please take into account, that setting these options to "off"
may result in
worse pattern in other parts of the code, e.g. no optimized
vector processing.
1179 / 1260
ID:
PR20080124-09
Title:
On Discrete State Space block matrix coefficients -1, 0 and 1

are eleminated in the generated code even if "keep current
marix structure" is not selected

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A calibratable coefficient, e.g. it has a variable class CAL,

must not be erased
by the code generator. Nevertheless matrix coefficients of the
Discrete State
Space block are not generated if they are set to -1, 0 or 1 and
"keep current
matrix structure" is not selected.
This optimization leads to missing information in the A2L file
as optimization
may remove the respective struct components from the parent
struct type.
Workaround: Several workarounds are possible:
- Set optimization level to 0
- Select "keep current matrix structure"
- Use coefficient values different from -1, 0 and 1 initally.
1180 / 1260
ID:
PR20080125-02
Title:
Incorrect AUTOSAR 2.0 export of path in provided or required

communication specification

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If an interface, which contains a provided or required

communication
specification (com spec), resides in a group, then an incorrect path
to an
operation or data element is exported. This holds for AUTOSAR 2.0
export.
Example:
The following path is exported:
<TARGETREF>/VelocityController/HardwareAbstraction/OP_GET</TARGETREF>
but is should be
<TARGETREF>/VelocityController/IF_EcuSignalVelocity/OP_GET</TARGETREF>
because "HardwareAbstraction" is the group name in the Data
Dictionary and not
the interface name, which is "IF_EcuSignalVelocity".
Workaround: Do not use grouped interface specifications in the Data Dictionary,
or do a
postprocessing of the exported XML file.
ID:
PR20080125-05
Title:
Handling of unconnected Stateflow transition differs between

TargetLink and Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In Stateflow, transitions that have no target junction (shown as

dashed lines)
are not executed. The TargetLink code generator handles
such transitions as if
they would end in a junction with no further outgoing lines.
Thus the transition
becomes part of the generated code.
There are no warnings or errors issued, neither from
TargetLink, nor from
Stateflow.
Workaround: Delete a superfluous transition or connect it to a destination
(state or
function).
1181 / 1260
ID:
PR20080125-07
Title:
Wrong code generated for While Iterator block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the following conditions are fulfilled for case 1 or case2

wrong code is
generated for a While Iterator block:
Case 1:
- "While loop type" is set to "do-while"
-- AND -- "Show iteration number port" is activated
-- AND -- "Maximum number of iterations" is exactly equal to the upper
range limit of
the data type selected as "Output data type", e.g. "Output data
type" = int8 and
"Maximum number of iterations" = 127.
Case 2:
- "While loop type" is set to "do-while"
-- AND -- "Show iteration number port" is not activated
-- AND -- "Maximum number of iterations" is exactly equal to the upper
range limit of of
an integer data type, e.g. "Maximum number of iterations" =
127.
In case 2 TargetLink determines the data type based on the
value of "Maximum
number of iterations". Following the example the value 127 will
fit into a Int8
variable, thus this data type will be used.
The generated code is wrong because the generated iteration
variable may
overflow during run time.
Workaround: - Activate "Show iteration number port" (terminate the output if
not needed).
- Select a sufficient "Output data type". The selected type
must be able to held
values up to "Maximum number of iterations" + 1.
1182 / 1260
ID:
PR20080129-05
Title:
Inconsistent port width after Simulink to TargetLink conversion

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: When an Simulink subsystem is converted to TargetLink, the

port widths of the
Simulink Inports are set to the current signal width. This
results in an
uninitializable model if the subsystem is driven by bus
signal(s), that cannot
pass Simulink Inports with explicit port widths. The conversion
incorrectly
assumes that the port width must be the sum of the widths of
the bus elements.
Workaround: Manually reset port widths of Simulink Bus Inports to "-1" (=
inherited).
Then, open TargetLink Main Dialog to propagate this
modification to the
TargetLink Simulation Frame.
ID:
PR20080130-10
Title:
Wrong MIL simulation of D Flip-Flop if the CLK signal is

vectorized or contains a transition from a negative over zero to
positive value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The TargetLink D Flip-Flop block behaves wrong in the

following cases:
- If the signal connected to the CLK input is vectorized, all
vector elements
except the first one are wrongly evaluated if the CLK signal
value of the last
timestep is smaller than zero and of the current timestep is
greater or equal
zero. This is wrongly not recognized as a trigger condition.
-- OR -- If the CLK signal contains a transition from a negative value
to zero directly
followed by a transition from zero to a positive value.
In both cases, the simulation results of the MIL simulation may
differ to
Simulink.
1183 / 1260
ID:
PR20080130-12
Title:
Erroneous movement of code into conditionally executed

control flow branch

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable is redefined using its old value and this new value
is used in a
conditionally executed control flow branch, then this definition
is erroneously
moved into the control flow branch.
Example for variable "State":
State = A && B && !State;
if (cond) {
if (State) {
...
}
...
} else {
...
}
becomes, erroneously,
if (cond) {
State = A && B && !State;
if (State) {
...
}
...
} else {
...
}
This may for example occur for the LastEvent calculation of a
D FlipFlop.
Workaround: Set optimization level to 0, otherwise no workaround available,
because the
LastEvent cannot be influenced.
1184 / 1260
ID:
PR20080204-07
Title:
Superfluous warning about division by zero protection on

multiplication operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: A superfluous warning about division by zero protection is

issued if the
- A Product block is specified to generate a multiplication
operation
-- AND -- Constrained range limits (Min/Max values) are specified for
the output
-- AND -- The flag "Protect against division by zero in production code"
is set. If a
multiplication operation is specified, the flag is not active, but it
remains
set, if it was set for a division operation and only the operation
was changed
to multiplication.
In this case a warning like the following is issued:
Warning #19523: <block>:
Min/max values and division by zero protection are specified.
In the event of a
division by zero this block's output will be the min/max value.
The warning is superfluous, because a division by zero cannot
occur on a
multiplication operation.
Workaround: 1) Modify "Number of inputs" to "*/"
2) Unset "Protect against division by zero in production code"
3) Set the intended operation in "Number of inputs"
1185 / 1260
ID:
PR20080207-02
Title:
No error message issued if multiple typedef objects are

specified to be the same base type

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If there are multiple typedef objects in the Data Dictionary that
are specified
to be a rename of the same TargetLink base type, no error or
warning is issued.
Example:
The base type Int16 is referenced be two typedef objects that
are specified to
be base types (IsBaseType = 'on').
Typedef object properties of 'Int16':
IsBaseType: 'on'
BaseType: 'Int16'
BaseTypeRename: 'MyInt16'
Typedef object properties of 'MyInt16':
IsBaseType: 'on'
BaseType: 'Int16'
BaseTypeRename: 'MyInt16'
Typedef object properties of 'MyInt16_2':
IsBaseType: 'on'
BaseType: 'Int16'
BaseTypeRename: 'MyInt16_2'
MyInt16 and MyInt16_2 both claim to be base type renames
of Int16. TargetLink
does not issue any warning or error about this. It uses MyInt16
for Int16. If
the user tries to specify MyInt16_2 in a block, MyInt16 will be
used instead.
Workaround: Do not specify multiple base type objects referencing the
same TargetLink base
type.
1186 / 1260
ID:
PR20080207-06
Title:
Wrong AUTOSAR model frame is generated for software

component with ports referencing sender/receiver interfaces
with structured data elements

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: If an AUTOSAR model frame is generated using

tl_generate_swc_model function for
an atomic software component containing ports that reference
sender/receiver
interfaces with structured data elements, the created model
frame is not
correct.
For the ports referencing sender/receiver interfaces with
structured data
element a SWC Receiver Port or a SWC Sender Port blocks is
generated with wrong
number of outports or inports.
Example:
For a port which refers an interface with one data element
consisting of a
structure with 8 elements (that can be modeled in Simulink as
a bus signal) a
SWC Port blocks connected to Bus Selecter with 9 outputs is
created:
|---------|---------|---------+--------+ |---------| |==========|---------+--------+ |---------SWC Port |---------|---------|---------Bus Selector
But correct a SWC Port with one bus outport should be
created:
+--------+
| |==============
+--------+ Bus signal
SWC Port
1187 / 1260
ID:
PR20080207-09
Title:
Comment in production code for Assignment block may

contain wrong index values

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: With optimized vector processing the block code comments in

the generated
production code for the Assignment block may contain wrong
index values if the
Assignment block is feeded with signals emanating from a
Demux block.
For example the following code might be generated:
{
/* Assignment: Subsystem/Assignment - output initialization
[2..7] */
Sa1_Assignment[Aux_S32] = Sa1_Y0[Aux_S32 + 15];
}
The correct comment in this case would be: /* Assignment:
Subsystem/Assignment output initialization [9..14] */
ID:
PR20080213-03
Title:
Error during RTF documentation generation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If Microsoft Word 2007 (Office 2007) is installed and RTF

documentation using
tldoc_rtf is generated two error dialogs may come up:
Microsoft Word
Type mismatch
Error
TargetLink File Conversion Tool requires MS Word Version
2000 or higher.
You are using 12.0!
The problem occurs during the version check in
ds_convert_file_macro.dot.
Workaround: Confirm both dialogs with "OK". The documentation will be
generated.
1188 / 1260
ID:
PR20080214-02
Title:
Logged data of Stateflow machine variable is shown in

different windows for MIL and SIL

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The logged signal data of a Stateflow machine variable is

shown in diffenernt
plot windows for MIL and SIL simulation modes. The logged
data is correct, but
displayed in different plots.
ID:
PR20080214-11
Title:
Erroneous elimination of unscaled Stateflow relational

opperation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A ralational operation in Stateflow might be erroneously

eleminated if following
conditions hold:
- The relational operation consists of an operation on the one
side and a single
variable on other side, e.g. (a >= b * c), or (b * c + d < a)
-- AND -- None of the operands has an LSB != 1.0 or an Offset != 0.0
-- AND -- The single variable is an integer
-- AND -- The single variable is constant with an initial value.
Workaround: Introduce an auxiliary variable for the operation. For example,
(a >= b * c)
becomes (aux = b * c; a >= aux).
1189 / 1260
ID:
PR20080215-02
Title:
Download of production code target application using TSM

DS1603/Diab may fails with the error E02246

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: Following configurations are affected:

RCP and HIL software Release 5.4 with TargetLink 2.2.1
(Download to target using
DS1603/Diab53)
RCP and HIL software Release 5.4 with TargetLink 2.3
DS1603/Diab53)
RCP and HIL software Release 5.4 with TargetLink 2.3
DS1603/Diab53)
Workaround: Use a newer executable file
%DSPACE_ROOT%\exe\crcrpcu.exe from RCP and HIL
software Release 6.0 or newer.
1190 / 1260
ID:
PR20080215-03
Title:
Interface variable of incremental subsystem may be

eleminated in surrounding system

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An interface variable of a subsystem where incremental code

generation is
activated may be removed by optimization in the surrounding
context. This may
occur if the interface variable is not a function parameter and
is not used
outside the incremental subsystem. In this case wrong data is
written to the
Data Dictionary.
Example:
The output of an incremental subsystem is connected to a
terminator block.
Therefore the output is not used, the variable which holds the
output is not
needed in the surrounding system and may be eleminated in
the context of this
surrounding system.
Within the incremental subsystem the variable is used and
therefore defined. As
a result the code will work, because the variable is defined by
the incremental
system but not used by the surrounding one.
The problem arises because the interface that is output to the
Data Dictionary
is not consistent. The interface specification is not correct
when code is
generated for the surrounding system, because the
"superfluous" variable is not
taken into account and missing in the Data Dictionary's
subsystem area.
If this wrong data is used, e.g. in a postprocessing step, errors
or wrong
results may occur.
Workaround: There are different workarounds possible:
1) Use code variants:
- non-ERASABLE variable classes for all potential interface
variables when
generating the surrounding system
- ordinary variable classes when generating the incremental
subsystem
2) Make all potential interface variables non-ERASABLE
3) Use Optimization Level 0
1191 / 1260
ID:
PR20080215-05
Title:
Code generation may abort if Data Dictionary typedef object

has width property set

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a Data Dictionary variable has no width specification and

uses a non scalar
typedef (which is currently not supported), the code
generation might abort. The
code generation starts without a warning of Data Dictionary
validation about
wrong typedef.
Workaround: Do not specify a width in Data Dictionary typedef object.
1192 / 1260
ID:
PR20080218-01
Title:
Script tl_generate_swc_model does not work correctly for

Data Dictionary files with included content

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The script tl_generate_swc_model does not work correcly for

Data Dictionary
files with included content. If the script is called with a Data
Dictionary file
name instead of an XML file name the included Data
Dictionary files are not
loaded.
If for example the content of the node
/Pool/Autosar/SoftwareComponents is
described via an included file, the script
tl_generate_swc_model just creates an
empty subsystem in the model.
Workaround: 1) If possible call tl_generate_swc_model with the name of the
AUTOSAR SWC-file,
instead with the name of the Data Dictionary file to be loaded
2) Load the desired Data Dictionary via Data Dictionary
Manager or MATLAB API
before calling tl_generate_swc_model. In this case do not
specify the name of
the Data Dictionary file to be loaded.
Example:
>> dsdd('Open' ,<DDProjectFile>);
>> tl_generate_swc_model('Model', <ModelName>,
'SoftwareComponents',
<SoftwareComponentName>, 'DestSubsystem',
<DestTLSubsystemName>)
instead of:
>> tl_generate_swc_model('Model', <ModelName>,
'SoftwareComponents',
<SoftwareComponentName>, 'DestSubsystem',
<DestTLSubsystemName>, 'DDFileName',
<DDProjectFile>)
1193 / 1260
ID:
PR20080222-03
Title:
Frame generation for a subsystem may fail

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
API
Description: If code generation is started using the tl_generate_code APIfunction for a

subsystem, which though contains a function block, but is not
configured for
incremental code generation, an error during frame generation
may occur.
Following errors may occur:
1) Matlab error
??? Attempt to reference field of non-structure array.
Error in ==>
tl_generate_prodcode_frame>i_ProceedWithSystemTime at 3036
2) TargetLink error
E05040: OBJECT NOT FOUND:
*** Object =
/Subsystems/<SubsystemName>/<SubsystemName>_fri/Typedefs
To configure a subsystem for incremental code generation use a
Function block
and set the option "Enable Incremental Code Generation" on
Incremental tab of
the block dialog.
Workaround: 1) Open the Function block placed within the subsystem, where
production code
should be generated for
2) Switch to the "Incremental" tab
3) Set the "Enable Incremental Code Generation" check box.
1194 / 1260
ID:
PR20080222-06
Title:
Wrong function prototype in generated documentation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In the generated documentation the prototype of the function

with return values
is not correct.
The function is described as a void function instead of a
function with return
value.
Example:
Description in generated documentation: GlobalStep Void
controller(Void);
Correct description ..................: GlobalStep UInt16
controller(Void);
This problem occurs if an additional variable is generated in
the production
code to hold the return value. There are two cases possible:
1) Within the function a variable is created to hold the return
value, e.g.
return out1;
2) Within the calling function a variable is created and the
return value is
assigned, e.g. out = f(...);
1195 / 1260
ID:
PR20080225-01
Title:
Initialization error due to adverse initialization order of bus

capable blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: During model initialization bus capable TargetLink blocks try

to detect whether
they are driven by a bus or not. This check may fail if the
initialization order
doesn't follow the signal flow. A typical error message reads
as follows
Error in 'example_model/sys/Subsystem/sys/Bus Outport':
Initialization commands
cannot be evaluated.
MATLAB error message: Error using ==> get_param
'example_model/sys/Subsystem/sys/Bus Outport/Bus
Selector' must be connected to
a Bus Creator, Bus Selector or a bus capable block.
A possible cause of this error is the use of a bus capable
block upstream that
is unable to propagate the bus signal. This can happen if the
block does not
meet the conditions for supporting buses or if the input bus
signal(s) are
inconsistent. See the documentation on bus-capable blocks
for information on the
block and signal requirements.
Workaround: As a workaround you could influence Simulinks initialization
order by changing
the name of the bus capable block. Among other criterias the
initialization
order depends on alphabetical sorting of block names. Let the
name of the block
start for instance with "zzz".
1196 / 1260
ID:
PR20080227-01
Title:
Missing cast of look-up table function argument by using data

variants

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Using a Look-Up Table block with varianted axis data may
lead to a missing cast,
if variable classes are used with different qualifiers for a
variant structure
component and the variant structure itself.
For example the axis data of a Look-Up Table block is
varianted and becomes a
component of a variant structure. In case of the look up table
1D and 2D block
the map structure becomes a component of the variant
structure too, if one of
the axis is varianted. If the variant structure has the type
qualifier const and
volatile (e.g. via variable class tamplate) and the axis data or
the map
structure has not set the same qualifiers (e.g. volatile is
missing), there is a
missing cast in the look-up table function call.
Compiling the generated code leads to a compiler error like
the following:
COMPILING FAILED. See myModule.err for details.
".\myModule.c", line xxx: error: argument type does not match
prototype
Workaround: To avoid this problem it is necessary that all of the variant
structures
components (for look up table blocks) have the same
qualifiers.
1197 / 1260
ID:
PR20080228-08
Title:
Wrong warning message for Multiport Switch block if driven by

For or While Iterator block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: If a Multiport Switch block is driven by a For or While Iterator

with specified
property "Iteration Limit" (For Iterator) or "Maximum number of
iterations"
(While Iterator) the minimum / maximum values of the iteration
variable are not
considered by the code generator.
This will lead to the wrong warning message #20743 (The
limits of the control
inport (signal ...) are out of range).
Workaround: Insert a Gain block with gain value 1 or a TargetLink Inport /
TargetLink
Outport behind the For or While Iterator and set the following
constrained range
limits (Min/Max values) for the output of the Gain block or the
TargetLink
Inport / Outport:
- For Iterator:
- Index Mode = One Based:
- Min = 1
- Max = Iteration Limit
- Index Mode = Zero Based:
- Min = 0
- Max = Iteration Limit - 1
- While Iterator:
- Min = 1
- Max = Maximum number of iterations
1198 / 1260
ID:
PR20080228-11
Title:
Code generation may abort on Sum block with operation '--'

driving a relational operation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Code generation may abort with an access violation and Fatal
F99999 if a
relational operator is driven by at least one signal that
contains a complex
operation (multiplication, division, sum).
This may occur for a relational block with the described input
signals as well
as for the corresponding modelling in Stateflow.
Example:
A Sum block with two inports and operation "--" drives a
Relational block.
Workaround: For the example, use a Gain block with gain factor -1 in front
of the sum and
change the Sum block settings accordingly.
1199 / 1260
ID:
PR20080228-12
Title:
Type qualifier "volatile" not taken into account for look-up table
function parameter

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For a look-up table block TargetLink generates a function that

contains the
search and interpolation algorithms. The main reason for
generating a function
is to reuse the function for similar look-up table blocks, which
reduces code
size. The input values, the output values and the block
parameter are parameter
of this look-up table function. Array and structure parameter
are passed by
pointer to this function. The block parameters type is inherited
to the function
parameters, but not the qualifier. The function parameters
qualifier is always
declared with the qualifier const. If the qualifier of the
parameter differs
from the qualifier of the function a cast to const is introduced.
This is
formally not correct, because inside of the function the
compiler may apply
optimizations because of the constantness of the pointers
destination.
Workaround: The most reason to use the qualifier volatile for block
parameters is to link
them to a memory section where it is possible to calibrate
them. This qualifier
is not used to tell the compiler that the parameter is volatile
during runtime
of the look-up table algorithms. In such a situation there is no
problem. For a
TargetLink look-up table function it is assumed that the
function parameters are
constant during the runtime of the function.
The formally correct behaviour would be to generate different
functions for
parameters with different qualifiers, but this leads to a bigger
code size.
Additionally the code pattern of the look-up table function
which takes the
volatile qualifier into account must contain additional code for
save access to
the breakpoint data. This is currently not supported.
The reason to pass the structure and arrays by pointers which
are always pointer
to const is to reuse the look-up table function for blocks with
parameters with
different qualifiers.
1200 / 1260
ID:
PR20080307-02
Title:
Communication timeout error during a PIL simulation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: The PIL simulation may abort with an communication timeout

error when the number
of data bytes which are to be received by the simulation
server in a given
simulation step cannot be completely received during the time
of 1 second.
When the simulation baudrate 38400 is selected (default
setting), 3840 bytes/s
can be received (1 start bit + 8 bit data + 1 stop bit = 10 bits).
Additionally,
some time is needed on target to read the data, prepare it,
and finally to send.
Therefore, depending on target speed, in practice even less
than 3840 bytes/s
can be received.
Please consider the following use case:
If code coverage is applied the problem described above is
very likely to occur.
The production code generated for a TargetLink model
contains e.g. 2600 code
coverage marks. In result, the code coverage data (how many
times every branch
was hit) which is read at the very end of the PIL simulation
counts 2600 code
coverage marks * 2 bytes = 5200 bytes. So, the
communication runs unavoidable
into a timeout error.
Workaround: Increase the simulation baudrate if possible. If not possible or
does not help,
disable the communication timeout, e.g in TargetLink Main
Dialog.
1201 / 1260
ID:
PR20080310-02
Title:
Production code simulation S-function may not be build with

MS VC 6.0 compiler

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: It may happen that the production code simulation S-function

won't build, if the
TargetLink subsystem is connected to bus signals and MS VC
6.0 is used.
In this case following error is issued:
<SubsystemName>_sf.c
.\TLSim\<SubsystemName>_sf.c(<LineNr>) : error C2026:
string too big, trailing
characters truncated
C:\MATLAB6P5P2\BIN\WIN32\MEX.PL: Error: Compile of
'.\TLSim\<SubsystemName>_sf.c' failed.
The problem is caused by the following lines in the generated
S-function file
<SubsystemName>_sf.c:
static const char mvInportsStr[] = "mvInports = {
{{'Signal1',{'Signal2'}}} .... or
static const char mvOutportsStr[] = "mvOutports = {
{{'Signal1',{'Signal2'}}} ....
Depending on the number of inports or outports and on the
buses passing the
TargetLink subsystem boundary these code lines may be very
long.
Workaround: Select one of other supported mex compilers, e.g. LCC,
Watcom 11 or MS VC 8.0.
These compilers were tested with line length of 2500
chararcters.
1202 / 1260
ID:
PR20080318-03
Title:
Error #15515 for reused custom code bitfield variables

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Due to a limitation a variable of a Custom Code block is not

reused. It is
usually shared as a global variable.
But if a reused subsystem contains a Custom Code block,
which specifies a
bitfield variable, then the following error message might be
issued:
Error #15515: .../Custom Code Block The struct type
GBFS_a__tp contains more
than one component with the name <bitfield_name>
A bitfield variable can be specified by using the data type
'BITFIELD' or for
'Bool' variables by setting the option 'Use global bitfields for
Booleans' in
TargetLinks Main Dialog (Advanced tab).
Workaround: Select a mergable variable class for those bitfield variables.
1203 / 1260
ID:
PR20080320-11
Title:
Data Dictionary validation fails for %MainDDDir% macro in file

name specification and "AutoSave" not "off"

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: A Data Dictionary include file can be specified in the FileName

property of a
DDIncludeFile object. The file name can contain the macro
%MainDDDir% to specify
a path relative to the project Data Dictionary. It is only
evaluated during
opening and saving of Data Dictionary files.
However, if the AutoSave property of the Data Dictionary
include is not set to
"off", during validation (both level 3 and 4) the FileName
property is checked
and the %MainDDDir% macro is not evaluated. In most cases,
this leads to an
error message like the following:
Error #06255:
Object "new_DIncludeFile": The FileName property
"%MainDDDir%/../common/dd_files/" of the DDIncludeFile
object "new_DIncludeFile"
specifies a directory "%MainDDDir%/../common/dd_files/"
which does not exist.
Workaround: The are several possible workarounds:
- In FileName property use an absolute path
- Set the AutoSave property to "off"
- Ignore the Data Dictionary error message while code
generation
ID:
PR20080325-02
Title:
Limits of Discrete-Time Integrator block are not taken into

account for range propagation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The limits set for the Discrete-Time Integrator block are not
taken into account
during range propagation. They should taken into account as
min/max values as
long as there are no min/max values specified which constrain
the range even
further.
Workaround: Specify the limits as min and/or max value manually.
1204 / 1260
ID:
PR20080326-08
Title:
Generated code for unary minus may yield to wrong

calculation results

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
1205 / 1260
Description: If an unary minus operation is applied to a negativ value, the

result fits into
an unsigned data type of the same width. If the width of the
result type is
smaller than the register width of the used hardware and the
result is not
assigned to a symbol, but directly used as an operand of
another operation, the
code generated by TargetLink may yield to wrong simulation
results.
Example:
A Constant block with the output of type Int16 with LSB=2^-7
is followed by a
Gain block with the gain value of -1, an output of type UInt16
with LSB=2^-7,
which is followed by an OutPort block with a different scaling
(e.g. arbitrary =
10), the generated code looks like
Sa1_OutPort = (UInt16) ((-((UInt16) Sa1_Constant)) / 1280);
This works fine on a 16-bit target for e.g. Constant=-1 as
-((UInt16) Sa1_Constant)) = -((UInt16) 0xffff)) = -(0xffff) =
0x0001
The same line of code fails on a 32-bit target because of the
unsigned cast
before applying the unary minus:
-((UInt16) Sa1_Constant)) = -((UInt16) 0xffffffff)) = (0x0000ffff) = 0xffff0001
These kind of code pattern can also be observed for the Rate
Limiter block, if a
negativ upper limit is given for the falling slew rate and the
implementation in
the code of both slew rates are the same besides their sign.
Another block to check is the Sum block. If its list of signs
contains only
minus, the first term will implement a unary minus operation. If
the first term
also requires a scale transformation, because the LSB of the
first input is
different from the output LSB of the Sum block, then the
above described
circumstances should be checked for.
Other examples for blocks that may lead to such a unary
minus operation
combination in the generated code are Stateflow, Abs and
Product.
1206 / 1260
Workaround: Use 32-bit types on a 32-bit target

-- OR -Avoid combining the unary minus with other expressions:
- which means in the given Gain block example to choose a
non erasable variable
class for output of Gain block
- and in the given Rate Limiter block example to change
scalings of one slew
rate or do not set a negativ maximum for falling slew rate.
- On Sum block set the same LSB for first input and output.
patches:
TargetLink 2.3.1p7
TargetLink 3.1p5
ID:
PR20080326-10
Title:
Inconsistent treatment of ScopeReducedClass for more than

one WidthSpec in variable class template

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The user documentation states that template variable classes

for the same
default class with different WidthSpecs may differ only in
- Description
- TypePrefix
- DeclarationStatements
- SectionName
If they differ in anything else, then an error is issued. The only
exception is
the ScopeReducedClass property:
Here, no error message is issued and the "first" VariableClass
template's
ScopeReducedClass is used for all widths. The search for the
variable class
templates for the same default class is done in the following
order of the
property WidthSpec:
1) APPLY_TO_BIT
2) APPLY_TO_BITFIELD
3) APPLY_TO_8BIT
4) APPLY_TO_16BIT
5) APPLY_TO_32BIT
6) APPLY_TO_64BIT
Workaround: Do not use variable classes having the ScopeReducedClass
property set for
variable class templates. Therefore copy all variable classes
to be used for
templates, remove the ScopeReducedClass entries in the
copies, and use these
copies for the templates.
1207 / 1260
ID:
PR20080327-08
Title:
Wrong transition action may be executed when transitions are

backtracked

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In contrast to a condition action (enclosed in curly braces), a

transition
action (written after a slash) is only executed if and when the
execution of the
transition actually reaches a state. The path taken is recorded
in transition
flags, which are set when a segment with a transition action is
executed. Upon
reaching the state, the transition actions to be executed are
determined by
examining the flags applicable at that point.
If a path has to be backtracked due to a failed condition, any
corresponding
transition flags are not properly reset. Thus, if a state is
reached, those
flags may be tested and the wrong transition actions may be
executed.
Example:
+-----------+
| State A |
+-----------+
||
| | /T2
|V
|O
| /T1 | [C]
||
VV
+-----------+
| State B |
+-----------+
When A is initially active and condition C is false, the transition
path on the
right is backtracked and state B is reached via the path on the
left. However,
since the flag for T2 is still set, T2 is executed instead of T1.
Workaround: Recast your control flow using condition actions.
1208 / 1260
ID:
PR20080401-01
Title:
Incompatible function interfaces may be generated using


TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the InPorts and/or OutPorts of an incremental subsystem

have no variable
class specified (variable class set to 'default') the function call
may not be
compatible to the interface of the incremental function.
Workaround: Specify explicit a variable class for InPorts and OutPorts of
incremental
subsystems.
1209 / 1260
ID:
PR20080401-02
Title:
Using components of a call-by-reference struct variable at the

interface of an incremental subsystem leads to a type
redefinition compiler error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable with the type IMPLICIT_STRUCT is specified as

call-by-reference
(Scope = ref_param) in the Data Dictionary and one ore more
components of this
variables are used at the interface of an incremental
subsystem, then the struct
type implicitly created by TargetLink for the variable is defined
twice in the
generated code. One definition is in the header file of the
incremental
subsystem and the other definition is in the header file of outer
subsystem.
If the struct variable in the Data Dictionary has an explicitly
defined struct
type a double definition of the struct type is created either if
the struct type
in the Data Dictionary has not the Module property specified.
A double definition of a struct type is also created if an implicit
variable is
specified as ref_param via a Bus Inport block or Bus Outport
block at the
interface of an incremental subsystem.
The double definitions of the struct type leads to compiler
errors like:
.\TLSim\NonBus\HostPC_MSVC\TL_SS.err for details
TL_SS.c
.\INC_SS.h(62) : error C2011: 'tag_DDImplicitStructPtrVarC' :
'struct' type
redefinition
.\INC_SS.h(65) : error C2011: 'myStructType_tag' : 'struct'
type
redefinition
Workaround: In the Data Dictionary create a variable with an explicitly
specified struct
type having the Module property specified. Use the
components of this variable
at the interface of the incremental subsystem.
1210 / 1260
ID:
PR20080402-12
Title:
Rate transition block may lead to wrong code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The rate transition blocks 'Rate Transition' or 'Unit Delay as

rate transition'
may lead to wrong code if not used for rate transition between
tasks, but for
rate transition between subsystems inside the same task.
Workaround: Do not use rate transition blocks. To allow the deletion of rate
transition
blocks set the Tasking mode for periodic sample times option
to 'Single Tasking'
in Simulation > Configuration Parameters... > Solver. Note that
the creation of
intertask communication as 'deterministic data transfer' is not
supported by
TargetLink so far, so the deletion of rate transition blocks does
not have
impact on the generated code but helps to keep MIL
simulation equal to SIL
simulation.
1211 / 1260
ID:
PR20080403-03
Title:
AUTOSAR modelling error issued if Scaling object referred by

CalPrmElement resides in Subgroup of /Pool/Scalings

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: To model the access to the calibration parameters defined by

an AUTOSAR
CalprmComponentType with TargetLink, CalPrmElement
objects and corresponding
Variable objects must be defined in Data Dictionary and
referenced from the
TargetLink blocks (see TLAutosarGuide.pdf, chapter
Preparing SWCs for
Measurement and Calibration According to AUTOSAR).
In the generated production code following RTE API function
call is then
created: Rte_CalPrm_<port>_<CalPrmElementName>.
However if the Scaling object referenced by the
CalPrmElement object via its
Scaling property does not reside direct unter /Pool/Scalings
group, but in a
subgroup of /Pool/Scalings, for example
/Pool/Scalings/MyCalPrmScalings the
required RTE function call will not be generated.
Instead following warnings are shown in the TargetLink
Message Browser after the
production code generation has been finished:
W02918:
The CalPrmElement object
<CalPrmElementPath>
and the corresponding Variable object
<CorresponingVariablePath>
have different properties:
'Scaling'
W02908:
The calibratable parameter <CalPrmElementPath> has not
been correctly defined.
For this parameter no AUTOSAR RTE API access function will
be generated.
Workaround: Use only Scaling objects from node /Pool/Scalings in
combination with
CalPrmElements.
1212 / 1260
ID:
PR20080403-05
Title:
Block diagram based Switch block optimization erroneously

moves incremental subsystem into conditionally executed
control flow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A model contains a subsystem with a Function block, which

specifies incremental
code generation, thus the check box 'Enable Incremental
Code Generation' on the
Incremental tab is enabled. On the Options tab a step function
class is
specified that has the Optimization property MOVABLE set,
but the
SIDE_EFFECT_FREE property is not set. The subsytem does
not contain any block
with states, e.g. no Unit Delay block or Flip-Flop block.
In this case TargetLink moves the function call of the
subsystem's step function
into a conditionally executed control flow branch. But
TargetLink is not allowed
to move this step function call for safety reasons.
The reason is, that typically a state must be calculated in
every simulation
step. Therefore it's not allowed to move the function call into a
conditionally
executed control flow branch. Also TargetLink does not
analyze the contents of
an incremental subsystem for states. So it must assume those
subsystems as
not-SIDE_EFFECT_FREE (worst-case assumption).
- Specify a step function class, which Optimization property is
not MOVABLE
-- OR -- Invoke code generation with the one of the following code
generator options:
- 'EnableBlockDiagramBasedSwitchOptimization' = 'OFF',
- 'SideEffectFreeAnalysisThreshold' = 0
-- OR -- Set the optimization level to 0.
1213 / 1260
ID:
PR20080409-15
Title:
Global logging of all signals fails for AUTOSAR models

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If the TargetLink Main Dialog option "Global logging option" is

set to "log
signal histories" or "log min/max-values", the code generator
generates
non-compilable code for a model that contains AUTOSAR
blocks. Simulation in SIL
and PIL mode is not possible in this case.
Workaround: Set Global logging option to "log according to block data" and
specify the
logging behavior at the individual blocks.
1214 / 1260
ID:
PR20080411-04
Title:
Incorrect code for function-call-triggered subsystem called by

an atomic subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When a function-call-triggered subsystem is called by a

Function-Call Generator
inside an atomic subsystem, the block computation order may
be incorrect.
Depending on the lexicographic order of the inports and the
function-call
trigger port of the system, the system may be called before
the inputs have been
computed.
The exact conditions which yields to this error are:
1. The caller is a Function-Call Generator block (not, for
example, a Stateflow
chart with an output event).
2. The caller is located in an atomic subsystem or in a
hierarchy of nested
atomic subsystems.
3. The outermost atomic subsystem surrounding the caller is
located at the same
hierarchy level as the triggered system.
+------------------+
| Atomic Subsystem |
| [FcnCallGen]--->|------+
|||
+------------------+ |
|
v
+----+ +------()------+
O----|Gain|------>| Triggered |--->
+----+ | Subsystem |
+--------------+
Under these circumstances the algorithm which determines
the block computation
order incorrectly assumes that the subsystem is externally
called. The actual
block computation order is then determined by the names of
the inports of the
triggered subsystem.
Workaround: Rename the ports of the triggered subsystem, such that the
data inport names are
lexicographically less than the trigger port name, for example
"AAA_In" and
"ZZZ_Trigger".
1215 / 1260
ID:
PR20080415-04
Title:
Wrong A2L file is generated if a single element of measurable

variable is fed as an input of MAP or CURVE.

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a single element of a measurable variable is fed as an input

of MAP or CURVE
and for all vector elements of the measurable variable only
one MEASURABLE entry
is generated into the A2L file, the A2L file is not correct.
This situation can happen if following modelling is used:
A component of a vector signal is demuxed and fed into a
Look-up Table block
resp. Index Search block. The vector is specified as
measurable, the table
parameter of the Look-up Table resp. the breakpoint data of
the Index Search
block are specified as calibratable.
Additional for all elements of the measurable vector the same
scaling and
identical min and max values have been specified.
In this case the A2L Generator generates for the measurable
variable one
MEASURABLE entry <VariableName>, for the table
parameter of the Look-up Table
CHARACTERISTIC (MAP or CURVE) and for the breakpoint
data of the Index Search
block an AXIS_PTS entry.
For both, CHARCTERISTIC and AXIS_PTS entry, an input
quantity is generated named
<VariableName>[SelectedVectorElement], but this requires
that in the A2L File
also a MEASUREMENT named
<VariableName>[SelectedVectorElement] exists, but it
doesn't.
Workaround: Possible via postprocessing of the A2L file. Please contact
TargetLink technical
support for details.
1216 / 1260
ID:
PR20080415-16
Title:
Missing plotted signals in SIL in a model containing a system

that is modelled for generation of variable definitions only

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: A model contains several TargetLink subsystems, or one

TargetLink subsystem with
several incremental subsystems. For example, one is called
'param' and the other
one 'main'.
The 'param' subsystem is modelled in such a way, to generate
only a variable
that is external in the other subsystem 'main'.
For example, it contains only a Constant block whose output
signal is directly
terminated by a Terminator block. No logging is specified for
the block inside
this subsystem.
The 'main' subsystem uses this external variable, and this
variable is logged in
this subsystem.
The C file of 'main' does include its own header file after
including the header
of 'param'.
#include "param.h"
#include "main.h"
Typically, this results from the fact that the name of its header
file is from
lower lexicographical order than the name of the other file. In
the example,
'main.h' is from lower lexicopraphical order than 'param.h', so
'param.h' is
included before 'main.h'.
This modelling results in the following faulty behavior: The
variable is logged
in MIL, but not in SIL.
This is based on the fact, that the needed logging macros are
defined as empty
after including 'param.h', because in module 'param' logging is
not enabled. The
necessary logging macros for module 'main' are not redefined
during include of
'main.h'.
Workaround: Specify different file names for code generation, so the name
of the 'main'
subsystem is from higher lexicographical order than the file of
the 'param'
subsystem, e.g. rename 'main' to 'z_main'.
1217 / 1260
ID:
PR20080416-11
Title:
Code generation aborts for a Stateflow output, which is used

as a for loop variable and connected to a Merge block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a for loop is modeled in a Stateflow chart and the loop

variable also is a
Stateflow output connected to a Merge block, code generation
aborts with an
access violation and Fatal F99999.
Workaround: Introduce a distinct Stateflow output that only gets the value of
the loop
variable. See the figure below:
+-----+
||
| |[i<5]{out=i; do_something; i++;}
{i=0;} | |
----------->O<----+
|
|{out=i;}
|
V
The following code will be generated:
for (i = 0; i < 5; i = i + 1;)
{
out = i;
merge = out;
do_something;
}
out = i;
merge = out;
ID:
PR20080421-04
Title:
AUTOSAR Import/Export module throws invalid error

message INCONSISTENT-LIMITS (8766) during import of an
arxml file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The AUTOSAR Import/Export module throws an error during

import of an arxml file
that contains a scaling reference and an integer type. The
scaling must have a
negative offset value and must be connected to an unsigned
integer type. If both
conditions will be fulfilled an invalid error message with the
1218 / 1260
title
INCONSISTETNT-LIMITS (8766) will be thrown. The reason
for this message was the
check of the defined limits by the AUTOSAR Import/Export
module. The check of
unsigned integer types doesn't allow negative offsets for
scaling objects and
throw an error as the result of this combination. This is wrong,
because
negative offset values are valid for unsigned integer types.
The scaling or the COMPU-METHOD in AUTOSAR could look
like this:
<COMPU-METHOD UUID="3410EB50-FBD0-40B6-A8B8A2C0C4CB1C38">
<SHORT-NAME>Test_UInt8_Scaling</SHORT-NAME>
<CATEGORY>LINEAR</CATEGORY>
<COMPU-SCALES>
<COMPU-SCALE>
<COMPU-NUMERATOR>
<V>-80</V>
<V>1</V>
</COMPU-NUMERATOR>
<COMPU-DENOMINATOR>
<V>2</V>
</COMPU-SCALE>
</COMPU-SCALES>
</COMPU-METHOD>
The scaling is defined as f(x) = -40 + 0.5*x, so the offset has a
negative
value.
The associated INTEGER-TYPE could be defined as followed:
<INTEGER-TYPE UUID="F2F9D2C9-51B5-4C7B-AC40DA0C02E3D466">
<SHORT-NAME>test_uint8</SHORT-NAME>
<SW-DATA-DEF-PROPS>
<BASE-TYPE-REF
DEST="SW-BASE-TYPE">/BaseTypeGeneric/uint8</BASETYPE-REF>
<COMPU-METHOD-REF
DEST="COMPUMETHOD">/TestPackage/Test_UInt8_Scaling</COMPUMETHOD-REF>
</SW-DATA-DEF-PROPS>
</INTEGER-TYPE>
1219 / 1260
ID:
PR20080421-07
Title:
The *arimport_hook.m functions will not be used if located on

paths specified in the tl_get_config_path.m

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: For the AUTOSAR Import/Export module the

*post_arimport_hook.m and
*pre_arimport_hook.m files will only be executed from the
Data Dictionary
configuration folder. The directory is located under the
following path:
%TL_ROOT%\Matlab\Dsdd\Config\ImportExport
Hook functions that are located in another directory will not be
executed,
because the AUTOSAR Import/Export module only searches
for hook functions in the
Data Dictionary configuration folder. This behavior is different
compared to the
usage of other hook functions. For example calling
tl_find_hook ('*hook.m')
shows the *arimport_hook.m file even if they are located
somewhere else on the
tl_get_config_path.m file but are not in the TargetLink
installation tree.
Workaround: No workaround available. The *arimport_hook.m functions
must be located in Data
Dictionary configuration directory.
ID:
PR20080422-04
Title:
Initial value of a Data Dictionary variables used as formal

parameter is ignored

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The initial value (property 'Value') of a Data Dictionary variable

which is used
as a formal parameter (Scope = value_param, ref_param or
fcn_return) is ignored
by the code generator. For the corresponding actual
parameter the initial value
is taken from the model (for example from Simulink outport or
Stateflow chart
outport) instead from the Data Dictionary.
1220 / 1260
ID:
PR20080422-13
Title:
Failure during generation of Simulink model using tl_generate_swc_model.m

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If the TargetLink SWC Model Generator will be called with a model name equal to
the destination subsystem name an error will be thrown. The call of the SWC
Model Generator may looks like following:
tl_generate_swc_model(
'Model','TestModel','DestSubsystem','TestModel','SoftwareComponents','TestModel'
,'SwcDescFileNames','TestModel.xml')
The error that will be thrown in the MATLAB command window looks like:
block_diagram does not have a parameter named 'Position'.
Error in ==> tl_generate_swc_model>FcnReplaceTlSubsystem at 1528
destPosition = get_param(destSubsystem, 'Position');
FcnReplaceTlSubsystem(hTlSubsystemFrame, options.destSystemPath,
options.model, options.tlSubsystemId);
Workaround: As a workaround use a destination subsystem name that is not equal to the model
name.
For example:
tl_generate_swc_model(
'Model','TestModel','DestSubsystem','TestModel/TestModel','SoftwareComponents','
TestModel','SwcDescFileNames','TestModel.xml')
-- OR -tl_generate_swc_model(
'Model','TestModel','DestSubsystem','TestModelSubsystem','SoftwareComponents','T
estModel','SwcDescFileNames','TestModel.xml')
1221 / 1260
ID:
PR20080428-01
Title:
No compute-through-overflow comment generated for

unsigned addition with negative constant

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the PolySpaceSupport code generator option is activated,

TargetLink should
generate code comments when purposefully applying
compute-through-overflow
arithmetics. This suppresses unnecessary warnings in
PolySpace.
If, for example, a Sum block has an unsigned output data type
and is used to
substract a value (e.g. supplied by a constant block with
default variable
class) from a signal, instead of substracting the value, the
unsigned
representation of that value is added in the generated code.
Example:
U8Out = U8In - 1
becomes
U8Out = U8In + 255
This makes sure that the addition is implemented by the
compiler in the unsigned
type. It introduces compute-through-overflow arithmetics and
is not marked by
TargetLink.
In general this problem exists for all additions generated by
TargetLink whose
result is unsigned and that has a negative constant value as
operand.
1222 / 1260
ID:
PR20080507-03
Title:
Displayed scaling beneath block icon may not be up to date

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: The output scaling of a block can be displayed beneath the

block icon controlled
by the block property output.show. If the output scaling of a
block has been
changed the displayed scaling beneath the block icon may not
be updated. This is
the case if the scaling is specified via a Data Dictionary object
(i.e. the
output references a variable, an user defined type or a scaling
object) and the
scaling values were changed in the Data Dictionary.
1223 / 1260
ID:
PR20080507-12
Title:
Optimization removes preprocessor if branch in Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In the example below an extract from a stateflow chart is

shown. The variable
pre_pro is a preprocessor variable and its UsePreprocessorIf
and
OmitCastOfMacroValue property of the variable class is on.
[pre_pro] {out = 5;}
o------->O------------->O------------>
|
| { out = 3;}
|
V
O
The expteced code which is created by the code generator
look like this:
#ifdef pre_pro
out = 5;
#else
out = 3;
#endif
But TargetLink generates only:
out = 3;
This happend because the optimization assumes that the
variable pre_pro has a
consant value and so an if branch can be optimized.
Workaround: Set the variable class property Info to adjustable.
ID:
PR20080507-13
Title:
Regular control flow instead of preprocessor-if generated in

Stateflow

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a variable class with the attribute "UsePreprocessorIf" set to

"On" is
selected for a variable that is used as a condition in a
Stateflow chart,
TargetLink will generate a preprocessor directive (#if ...
#endif) instead of a
regular if statement. However, TargetLink will also perform the
AND and OR
1224 / 1260
flowchart transformations described in the documentation (see

Advanced Practices
Guide > Working with Stateflow > Flowchart Style Guide). If
such a condition is
combined with another condition into an AND or OR
expression, it is impossible
to generate preprocessor code, even if each one of the
conditions could be
realized as a preprocessor statement on its own.
Examples:
Let M be a variable that can be used in preprocessor-if
directives, and let C be
an arbitrary conditional expression.
1. Parallel transitions
|
V
O
/\
/\
[C] ( ) [M]
\/
\/
O
| { A; }
V
if (M || C) {
A;
}
instead of
#if M
A;
#else
if (C) {
A;
}
#endif
2. Sequential transitions
----->O---------->O---------->O----------->
[M] [C] { A; }
if (M && C) {
A;
}
instead of
#if M
if (C) {
A;
}
1225 / 1260
#endif
Workaround: Avoid modeling situations that match the patterns for the AND
or OR
transformation if preprocessor-if symbols are involved.
ID:
PR20080507-14
Title:
Erroneous reduction of shared auxiliary variables to minimal

block scope

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: For a constellation where one variable is eligible to variable

sharing (an
auxiliary variable or a block output made eligible via
ExtendedVariableSharing)
is inside a conditionally executed control flow branch and the
other is
completely outside this branch, like
if (...) {
Var1 = ...
... = Var1
... = ... Var1
}
if () {
Var2 = ...
} else {
Var2 = ...
}
... = foo(Var2);
it is possible that after Variable Sharing, the minimal block
scope is
erroneously determined to be the original minimal scope of
Var1, i.e.
if (...) {
T Aux_T;
Aux_T = ...
... = Aux_T
... = ... Aux_T
}
if () {
Aux_T = ...
} else {
Aux_T = ...
}
... = foo(Aux_T);
which leads to compile errors or erroneous use of "implicit int"
by the compiler
which is detrimental if the range of int is less than the range of
T or if T is
a floating point type.
1226 / 1260
Workaround: Reliable workarounds:

- Set the code generation option
'ReduceScopeOfVariablesOnlyDownToFunctionLevel'
to 'on'-- OR -- Set optimization level to 0.
Potential workarounds for single variables:
- Switch ExtendedVariableSharing or
- make for ExtendedVariableSharing=on block output
variables in question
non-ERASABLE or
- obstruct movement into conditionally executed control flow
branches via
non-MOVABLE variable classes.
ID:
PR20080513-01
Title:
Format of the COMPU_METHOD entry is not correct

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In the ASAM MCD 2MC the Format property of the

COMPU_METOD entry is defined as
follows:
"Format: display format in %[length].[layout];
length indicates the overall length; layout indicates the
decimal places. The
format string should never be empty as ""."
In the Format string generated by A2L File Generator however
in the overall
length the decimal point is not taken into account.
It means that Format property with the values like
%<value>.<value>, for example
%15.15 may be generated, whereas %<value>+1.<value> is
correct.
This may lead to problems when loading the A2L file to the 3th
parts tools, as
for example a calibration system.
Workaround: The Format string can be corrected during postprocessing of
the A2L file. Please
contact TargetLink technical support for details.
1227 / 1260
ID:
PR20080513-05
Title:
Global, calibratable and measurable variables as well as

macros are missing in the generated documentation

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The documentation of a function generated by TargetLink

documentation generator
contains a list of all public variables, like global, calibratable
and
measurable variables, and macros used within this function
and generated for
TargetLink blocks placed directly at the root of the Simulink
subsystem that
this function has been generated for (function subsystem) or
within further
virtual subsystems contained in the function subsystem. If in
the function
subsystem an atomic subsystem exists whose production
code is inlined within the
body of the documented functions, the public variables and
macros related to the
TargetLink blocks contained in this atomic subsystem are also
listed.
If however in the atomic subsystem, a further atomic
subsystem eixst with
inlined code, the public variables and macros related to the
TargetLink blocks
contained in the deeper atomic subsystem will not be listed.
Workaround: In the script using for the document generation (for example
tldoc_deafult), set
the property 'AtomicSubsystems' of the tldoc API function
'TargetLink Subsystem'
to 'on'.
In this case the missing public variables still will not be listed
by the
description of the parent function. But in this case a separate
chapter for
atomic subsystem will be generated, where the missing
variables are shown.
1228 / 1260
ID:
PR20080514-03
Title:
Scaling of Data Dictionary type with constraints displayed red

in block dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: In the block dialog the scaling will be displayed in red although
the
specification is ok, if
- the scaling is specified for a type with constraints and
- the name of the scaling has less than four letters.
Workaround: Rename the scaling, that the name contains four or more
letters.
patches:
TargetLink 3.1p5
1229 / 1260
ID:
PR20080514-05
Title:
Data Dictionary object of same name and type is used if origin

object is not available

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an object in the Data Dictionary is moved, e.g. by drag and

drop or cut and
paste, in general the references in the model are not updated
by default. The
reference in the model points to an object, which is not
available any more.
Anyhow it may happen, that the code generator finds another
object that
corresponds with the referenced object's name and type.
This is a fault:
1) No warning or error is issued for the invalid reference.
2) Another object is used, which may has completely different
property values.
This problem exists for the following Data Dictionary objects:
Variables
VariableClasses
FunctionClasses
Typedefs
Scalings
Workaround: You can avoid this problem taking into account the following
hints:
1) Use unique names for objects of the same type
2) If you want to use a name twice for an object of the same
type, you should
place this objects into different groups. Do not place one of
them on the root
node.
1230 / 1260
ID:
PR20080514-08
Title:
TargetLink AUTOSAR export generates two equal UUIDs for AUTOSAR

2.1

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The Data Dictionary export of an AUTOSAR file according to version 2.1
contains
elements with the same UUID. After the export of the AUTOSAR nodes
ATOMIC-SOFTWARE-COMPONENT-TYPE and INTERNALBEHAVIOR, both nodes contain UUID
properties with the same unique identifier. The problem exists in
AUTOSAR files,
exported with the Data Dictionary Manager or with the Data Dictionary
MATLAB
API. No error message is thrown during export.
The first export of an AUTOSAR file doesn't contain the faulty UUID of
the
INTERNAL-BEHAVIOR node. As the
/Subsystems/<Subsystem>/Autosar/SoftwareComponents/<Subsystem>
node contains a
property named UUID with a set identifier, all further export operations
will
contain the error.
Workaround: To export an AUTOSAR file without equal UUIDs clear the UUID
property of the
/Subsystems/<Subsystem>/Autosar/SoftwareComponents/<Subsystem>
node, before
exporting an AUTOSAR XML file.
ID:
PR20080519-06
Title:
Substructs of type IMPLICIT_STRUCT are not supported by

the Struct Variable dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: Substructs of type IMPLICIT_STRUCT are supported by

TargetLink. However if the
type IMPLICIT_STRUCT is set for a component in the Struct
Variable dialog, the
dialog does not allow this setting. In the status line of this
dialog an error
is issued: A type must not set to "IMPLICIT_STRUCT" which
not correct.
Workaround: Create a substruct directly using the nodes in the Data
Dictionary Manager.
1231 / 1260
ID:
PR20080519-08
Title:
Differences between TargetLink D Flip-Flop and Simulink D

Flip-Flop

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
Description: If a D Flip-Flop resides inside an enabled or Action Port

triggered subsystem
the behavior of the TargetLink D Flip-Flop and the behavior of
the generated
code is not equal to the behavior of a Simulink D Flip-Flop in
the same context.
The MIL D Flip-Flop and the generated code behave equal but
the MIL D Flip-Flop
and the generated code does not behave like Simulink.
ID:
PR20080519-13
Title:
State variables with scope ref_param are not re-initialized

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Actual variables of state variables are not re-initialized in init

functions if
they have scope ref_param.
This problem affects the following blocks if they reside in an
enabled or an
action port triggered subsystem which has set 'States when
enabling' or
'States when action is resumed' to 'reset':
- Stateflow
- FIR Filter
- Unit Delay
- Custom Code
- Discrete Transfer Function
- Discrete Filter
- Blocks which need a FirstRun symbol in code.
Workaround: Select global scope for block state variables which have to be
reset or keep
their variable classes set to 'default'. If the FirstRun symbol is
specified via
a template in the Data Dictionary, select here global scope or
keep the variable
class set to 'default'.
1232 / 1260
ID:
PR20080519-16
Title:
MATLAB shutdown can not be cancelled with Cancel button in

Save Data Dictionary dialog

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: When MATLAB is closed and the current Data Dictionary has
been modified, a
dialog opens which asks the user whether the Data Dictionary
should be saved to
file. The dialog presents a Cancel button, however, pressing
this button has no
effect, i.e. MATLAB shutdown is not cancelled.
Workaround: Save current Data Dictionary before shutting down MATLAB.
ID:
PR20080526-01
Title:
Wrong reuse code if different instances use different variable

sizes

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: As a precondition for function reuse the generated code for

each instance has to
be the same. This is almost fully guaranteed because the
reused system has to be
a library system.
But the user can still influence some instance details by using
masked subsystem
and by use of mask variables as initial values inside the
reused system. If this
initial values are different and the variable is not reused an
error is thrown.
But apart from the value the size of variables can also be
influenced with such
masked systems, for example the gain parameter or a LUT
parameter can have
different dimensions in different instances. This different
dimensions are not
found if the variables are not reused (variables class with
Scope ref_param or
value_param). The generated reuse function contains the
correct code for only
one instance, but the code is not correct for all instances.
Workaround: Avoid the use of different variable sizes in a reused
subsystem.
1233 / 1260
ID:
PR20080527-06
Title:
Coefficients of Discrete Transfer Function block are optimized

regardsless of the variable class

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The code pattern of the Discrete Transfer Function block may
be optimized, if
some of the coefficients are -1, 0 or 1.
If such coefficients are present, some arithmetic operations
are superfluous and
can be neglected.
TargetLink applies this optimizations, although this may
contradict with some
variable properties.
Example:
The nominator coefficents are not specified using a Data
Dictionary variable and
have the variable class MERGEABLE_CAL, which means that
the coefficents are
calibratable and may be used more than once in the model.
The variable has to be
generates as a vector of given length and any vector element
must not be
eleminated.
Although TargetLink applies the optimization.
Only if the option 'Keep vector structure' is enabled, the right
vector will be
generated.
In contrast TargetLink generated the right vectors if the same
specification is
done using a Data Dictionary variable. Here the use of the
Data Dictionary
variable implies that a fixed variable has to be generated.
Workaround: Use 'Keep vector structure' or specify variable in the Data
Dictionary.
1234 / 1260
ID:
PR20080528-18
Title:
Wrong saturation limits implemented in the generated code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Wrong saturation limits are generated if

- a block with enabled output saturation drives a Saturation
block
-- AND -- a saturation limit of the Saturation block represented in the
scaling of the
predecessor block does not fit in the output data type of the
Saturation block.
Example:
A Product block drives a Saturation block. The Product block
has LSB = 2^(-13),
data type = UInt16 and output saturation is enabled.
The Saturation block has LSB = 0.004 and data type = UInt8.
Its saturation
limits are specified to be 0 and 1.
The upper saturation limit 1 represented in the scaling of the
product block is
2^13 = 8192. This value is uncorrectly casted to UInt8 (output
type of
saturation block), which leads to zero. This wrong value is
used as upper
saturation for the saturation code.
Workaround: There are two possible workarounds:
- Select an output type of the saturation block where the
rescaled saturation
limits fit (referring to the example use UInt16).
-- OR -- Ensure that the output variable of the predecessor block of
the Saturation
block is not optimized, e.g. by logging or selecting a not
optimizable variable
class.
1235 / 1260
ID:
PR20080529-18
Title:
Calculation of worst-case ranges for Discrete State-Space

block fails

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: Given is a Discrete State-Space block.

If the autoscaling is used to calculate worst-case ranges, the
calculation may
fail for the block with errors like:
*** E03461: ERROR DURING RANGE CALCULATION:
*** Could not call the 'tl_scale_discretestatespace' block
function.
*** E00000: ERROR DURING RANGE CALCULATION:
*** The range evaluation failed.
*** ERROR:Output argument "result" (and maybe others) not
assigned
during call to
"C:\dSPACE\matlab\tl\autoscaling\tl_calculate_ranges.p
(i_CalcBlock)".
ID:
PR20080529-20
Title:
Build host fails due to missing log macro definition

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If a mergeable variable carrying an access function template

is logged more than
once in a TargetLink subsystem, e.g. due to the use of the
"Log time histories"
option, the compile process may fail due to a missing log
struct entry
definition with a message similar to
Error .\subsystem.c: 124 unknown field '_input1' of 'struct
LOG_STRUCT_a'
Workaround: Do not use "Log time histories", avoid logging more than one
block output
carrying the same merged variable with access function class.
1236 / 1260
ID:
PR20080530-14
Title:
No call of a extern Restart Function of a referenced

subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Usually you can enforce the call of a Restart-Function of an

incremental or
extern subsystem by either enabling the Force flag in the
Function block's
dialog or choosing function class that has extern storage.
However this does not
work for a referenced subsystem. The Force flag must be set
explicit.
Workaround: Set the Force flag in the Function block's dialog.
ID:
PR20080602-27
Title:
Problem with signals of Simulink fixed-point data types

outgoing from a TargetLink subsystem under MATLAB
R2008a

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Simulation
1237 / 1260
Description: If signals of Simulink fixed-point data type are outgoing from a

TargetLink
subsystem the SIL/PIL simulation of this subsystem is only
possible with the
Simulink Fixed Point license.
During the frame generation the user is noted about this:
NO BUILD-IN DATA TYPE USED:
*** The output data type of the TL subsystem's Outport block
*** <BlockPath>'
*** is equal <FxpDataTypeName>'.
*** It is not one of the build-in data types. During SIL/PIL
simulation
the Simulink Fixed Point software license will be checked out.
In MATLAB release prior to R2008a Simulink issues this
following errors while
starting the SIL/PIL simulation and the Simulink Fixed Point
software license is
not available:
<TLSubsystemName>_sf requested use of data type
<FxpDataType>'. Use of this data
type requires a fixed-point license, but license checkout failed.
To use this
model without a fixed-point license, select "Fixed-Point
Settings" from the
model's Tools menu. Set the interface's "Select current
system" option to be
the root model. Set "Logging mode" to be "Force off" and
"Data type override" to
be "True doubles." This replaces most uses of fixed-point data
types with
floating-point doubles. In rare cases, a few attempts to use
restricted data
types may still exist. Reconfiguring to use floating-point types
and/or
inserting Typecasts is necessary in these cases.
In Matlab R2008a however only this following Simulink
message is issued:
Error reported by S-function <TLSubsystemName>_sf in
<ModelName>/<TLSubsystemName>/S-function frame/Sfunction':
????E.
In this case the fault is unclear for the user.
Workaround: Without a Simulink fixed point licence do not use Simulink
fixed-point data type
at the Outports of a TargetLink subsystem.
1238 / 1260
ID:
PR20080602-36
Title:
Access function for AUTOSAR structure will not be generated

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: An access function for an AUTOSAR structure such as

Shared-Calibration-Composite-Type or CalPrm-Variable-Composite-Type
will not be
generated. The reason for this behavior is a wrong Initial-ValuePropagation,
which replaces the access to the components of an AUTOSAR structure
with their
initial values.
For example an AUTOSAR structure has to look like this, to be affected of
the
problem:
[-]-+ MyCalPrmStruct
[VariableClass=SHARED_CALPRM_COMPOSITE_TYPE]
|
[+]- MyComp1 [VariableClass=Default]
|
[+]- MyComp2 [VariableClass=Default]
In this example both components MyComp1 and MyComp2 are
referenced in a
TargetLink model as gain factor variables. The TargetLink code generator
doesn't
generate access functions for the structure under the subsystem node.
Additionally the AUTOSAR post processing throws the message:
Warning #02908: / ...
/Variables/Rte_SharedCal_Controller_MyCalPrmStruct:
The calibratable parameter
'//DD0/Subsystems/controller/rte_controller/Variables/Rte_SharedCal_Con
troller_MyCalPrmStruct' has not been correctly defined.
For this parameter no AUTOSAR RTE API access function will be
generated.
Workaround: As a workaround set the variable class of the components to DISP or
CAL, or
define a new variable class with a Info property set to readwrite.
ID:
PR20080603-09
Title:
Elimination of Stateflow input variable ignores scope of

variable used in array indices

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:

1239 / 1260
Description: Seemingly, the scope of a variable is reduced down to

function scope, although
the variable is used in at least two functions.
The variable has a default variable class, therefore there is no
user
specification that results directly in the function local scope.
The following error will be issued:
Error #17054: <Block the Variable stems from>:
The variable '<Variable Name>' is implemented with 'function
local scope', but
requires 'module local scope'.
The variable is used in a second function (stemming from a
Stateflow chart) as
an index, e.g. of a selector access.
Example:
Setting the scope of the variable in question sufficiently high
gives
static MyType VariableInQuestion;
...
Void f(Void) {
...
VariableInQuestion = ...
...
Ca1_Chart();
...
}
Void Ca1_Chart() {
...
/* #combined# .../Chart */
b = a[VariableInQuestion - 1];
...
}
The actual order of the problem is reverse: The scope of the
index variable is
function local prior to the replacement of the Stateflow input
variable by the
output of the dynamic selector. The vector variable's scope is
checked to
determine whether it is sufficient, but the scope of the index
variable is not
checked.
This problem may occur whenever the predecessor of a
Stateflow input is an
element access to a non-constant element of a vector (or
matrix) or becomes so
due to prior optimizations - complex operations involving such
accesses are no
problem. This situation may occur for a dynamic selector, a
Multiport switch
with only one data input vector, or the output of a Stateflow
chart preceding
the input of a Stateflow chart (not counting intermittent
TargetLink ports).
1240 / 1260
Workaround: It is recommended to set explicitly a sufficient scope for the

variable(s) used
in such index access.
Alternatively, set a non-ERASABLE variable class for the
Stateflow input
variable.
ID:
PR20080604-04
Title:
Wrong cast to floating-point introduced by preceding Fcn

block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: TargetLink usually generates floating-point code for the

operations specified in
a TargetLink Fcn block, even if the output of the Fcn block is
fixed-point.
If a Product block implementing a multiplication or a Gain
block whose gain
value has a variable class different from default follows a Fcn
block, the code
for the Product or Gain block may contain an erroneous cast
to a floating point
type.
Workaround: Set a global variable class for the output variable of the Fcn
block or any
other block output between the Fcn block and the affected
Product and/or Gain
block.
1241 / 1260
ID:
PR20080605-19
Title:
Wrong A2L entry when using user look-up table scripts for
equidistant axes

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a look-up table with calibratable table values and equidistant

axis is used
and for the parameters needed to calculate the axis points,
such as start point
(offset) and distance or shift operator no variables have been
defined within
the generated production code, what for example is possible if
user lookup
scripts are used or - since TargetLink 2.3 - the "Generate map
struct" option
has been deactivated, in the generated A2L file entry for this
look-up table the
axis is always describes with with following paramatars: start
point 0, distance
1. The real parameters of the axis are not taken into account.
Workaround: If user lookup script is used, modify it in this manner that for
equidistant
axis paramater, if possible, separate variables are defined.
If possible, activate the "Generate map struct" option.
1242 / 1260
ID:
PR20080609-04
Title:
Incorrect description of Interpolation and Index Search block

combination in generated A2L file

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: In the generated A2L file the Interpolation and Index Search
block combination
are to be combined to one MAP or CURVE description.
This does not work correctly if the Interpolation block and
Index Search block
reside in different subsystems, even if only TargetLink prot
blocks are placed
between the Interpolation and the corresponding Index Search
block.
In this case the Interpolation and Index Search blocks A2L
entries are generated
as follows: For the variable related to the Interpolation block
(table
parameter) a CHARACTERISTIC entry of MAP or CURVE
type and for the variable
related to the Index Search block (break point data parameter)
an AXIS_PTS entry
is generated.
However at the CHARACTERISTIC entry representing the
table paramter of the
Interpolation block only FIX_AXIS are generated, instead of
the COM_AXIS
referring to the AXIS_PTS entries corresponing to the break
point data
parameters of the Index Search blocks connected to the
Interpolation block.
1243 / 1260
ID:
PR20080610-01
Title:
Code generation may abort with fatal #10007: Internal error.

Error code: TlCVectorSignalSliceDescription 189.

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A Stateflow chart with vector inputs or outputs whose widths

are different may
lead to
TlCVectorSignalSliceDescription 189.
This may happen if the Stateflow chart has at least three
different vector
widths greater than the LoopUnrollThreshold considering all
inputs and outports
of the Stateflow chart.
Example:
Given is a Stateflow chart with three outputs of widths 5, 12
and 10. The
LoopUnrollThreshold ist set to its default value (= 5). This
leads to the fatal
error during code generation.
Workaround: - Increase the LoopUnrollThreshold to a greater value than the
width of the
third greatest vector (referring to the example set the
LoopUnrollThreshold to
be greater than 5)
-- OR -- change the order of the inports and outports in a way that the
greatest vector
with a width greater than the LoopUnrollThreshold is the first
port (referring
to the example, an order where the vector with width 5 is not
the first outport
avoids the problem)
-- OR -- ensure that vector inputs and outputs of a Stateflow chart
has not more than
two different widths (or are scalar)
-- OR -- disable vector processing (set code generator option
'EfficientVectorHandling'
to 'off').
1244 / 1260
ID:
PR20080612-22
Title:
Code generation may fail with a LEDA exception (index out of

range) for a non-virtual signal at input of a Demux, Mux or
Data Store Write block

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If the input of a Demux, Mux or Data Store Write block ist an
non-virtual signal
the code generation fails with the error:
Fatal #10020:
An internal error (LEDA exception: array::inf index out of
Workaround: Do not use non-virtual signals as the input of a Demux, Mux or
Data Store Write
block.
1245 / 1260
ID:
PR20080613-04
Title:
Wrong optimization for different vector indices in conditional

branches

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Whenever modeling control logic like:

if (cond)
a[i] = 1;
else
a[j] = 0;
where a is an array variable and these variable is used in both
branches,
TargetLink ignores the different vector indices and optimizes
this to the code
pattern
a[i] = cond;
The same problem occurs when modeling control logic like:
if (cond)
a[i] = 0;
else
a[j] = 1;
These situations typically only occur when modeling with
Stateflow charts.
Workaround: Insert a temporary variable, that cannot be optimized. Modify
the model to get a
code pattern like
if(cond)
tmp = 1
a[i] = tmp;
else
a[j] = 0;
tmp has to be a variable with a non ERASABLE variable
class.
1246 / 1260
ID:
PR20080619-03
Title:
During code generation a wrong "Output file name" may be

emitted in MATLAB command window

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: During the code generation for a TargetLink subsystem the

following note is
emitted in the Matlab command window:
...
Note Output file name : <OutputFileName>
...
The <OutputFileName> emitted in the note should be the
name of the file created
for the TargetLink subsystem code is currently generated for.
This is not the
case if the user has specified a file name for the TargetLink
subsystem
explicitly, e.g. via the Code file property in a Function block or
in the
function class of the step function for the system, which is not
equal to the
TargetLink default file name for the system.
Please consider that only the <OutputFileName> emitted in
the note is not
correct. The generated file has the correct name.
1247 / 1260
ID:
PR20080620-02
Title:
Documentation generation may abort because of missing

property in Data Dictionary

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: If a message variable (variable which is used by intertask

communication) is
removed by code optimization the documentation generation
(TargetLink Main
Dialog -> Tools -> Generate documentation) may abort with
an error message like
the following:
*** E05070: PROPERTY NOT FOUND:
*** The property "VariableRef" does not exist.
*** Object =
/Subsystems/A/RTOS/Messages/Message/MessageVariable
(VariableRef)
- Specify the message variable to be not optimizable (select a
suitable variable
class).
- Check your scalings: In some cases removing of a message
variable is caused by
unsuitable scalings of the message variable and/or the
sending/receiving
subsystem outport/inport. Check if the scalings cause
expressions to become 0.
- If signal lines implemented by intertask communication have
no real source
(e.g. a Ground block instead) or no real sink (e.g. a
Terminator block instead)
the concerning message will also be removed by code
optimization. Check if it is
possible to change the modelling.
1248 / 1260
ID:
PR20080623-01
Title:
Model Conversion aborts on a TargetLink Bitwise Logical

Operator with > 1 input ports

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When a subsystem is converted to TargetLink that contains a

TargetLink Bitwise
Logical Operator block with more than one input port, Model
Conversion replaces
this block with another tlsamples TargetLink Bitwise Logical
Operator block.
Block replacement succeeds, but setting its parameters fails,
and the following
error message is produced:
E02012:
There is a syntax error in the user-defined hook function
tlsamples_bw_logical_operator.
MATLAB interpreter error message was:
.....................................
Error using ==> set_param
TLSAMPLES_BW_LOGICAL_OPERATOR block (mask) does
not have a parameter named
'nBitShiftRight'.
The block that has been inserted is unconnected, and its
parameters are set to
the default values from the tlsamples library.
Note that replacing the block is superfluous, since it is already
a
TargetLink-compliant block. The error does not apply to the
common use case that
a Simulink Bitwise Logical Operator block is processed during
conversion.
Workaround: Make sure there are no TargetLink Bitwise Logical Operator
blocks with more than
one input port in subsystems that should be converted to
TargetLink.
1249 / 1260
ID:
PR20080623-03
Title:
Several optimizations do not work if struct member initializers

are passed as parameters to custom code

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: If an array is used as parameter, state, work or output variable

of a Custom
Code block and at the same time its address is used to
initialize a struct
member, then optimizations including code movement work
no longer for struct and
struct member variables.
Example:
The axes and map of a look-up table function are passed via a
map structure and
are also used in custom code.
Workaround: Get rid of the direct use inside custom code.
ID:
PR20080623-04
Title:
Macro may be replaced by its value

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A Stateflow variable with scope constant and specified as a

macro in TargetLink
may be replaced by its value, even if the macro has properties
as follows:
- Alias = on
-- OR -- Storage = extern
-- OR -- Optimization is not ERASABLE
Workaround: Set Info property of variable class to "adjustable" or
"readwrite" to advice the
code generator that the macro has no fixed value.
1250 / 1260
ID:
PR20080626-03
Title:
Extremely slow code generation for complicated Stateflow

charts

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Modelling
Description: In a Stateflow chart that contains many execution branches

and joins, code
generation may take an extremely long time. If, for example, a
structure such as
the following is modeled using transitions
if (condition1) {
then_action1;
} else {
else_action1;
}
if (condition2) {
then_action2;
} else {
else_action2;
}
...
if (conditionN) {
then_actionN;
} else {
else_actionN;
}
code generation time is exponential in N.
Workaround: Partition the Stateflow chart into several graphical functions.
1251 / 1260
ID:
PR20080626-05
Title:
Undefined overflow behaviour in a signed addition or

subtraction

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: The overflow behavior of two summands is only defined, if

both of them are of an
unsigned data type. Therefore casts to an unsigned data type
have to be
generated for signed summands, if the operation is anticipated
to overflow.
In some cases TargetLink generates assign addition or
subtraction operations for
- Sum block with more than two inputs
- Sum block with only input and an input vector size greater
two
- Discrete State Space block
- Discrete Transfer Fcn block
- Discrete Filter block
- FIR Filter block
If the right hand side operand of this assign addition or
subtraction is signed,
the overflow behaviour of the assign addition or subtraction
can be undefined
because there is no cast to unsigned.
So far no wrong simulation behavior is known, but it may
confuse code checking
tools like POLYSPACE as no comment /* CTO */ is generated.
1252 / 1260
ID:
PR20080701-01
Title:
A static local variable may be merged with not static local

variable

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: In a model there are two variables specified with the following
properties:
- they do have fix names that are identical,
- their properties except for their variable classes are identical,
- their variable classes do have the MERGEABLE
Optimization property set,
- the variable classes' storage properties are set to 'local',
- the variables are specified to be defined in the same
function, e.g. their
blocks are placed in the same subsystem,
- their variable classes are identical except for the scope
properties: the one
is set to 'static', while the other one is left to '<default>'.
In this case, TargetLink merges both variables in the
generated code, though
they differ in scope property. What's even worse is that the
variable's
definition may have or have not the static qualifier, depending
on the
adjustment of the blocks in the model.
Workaround: Specify different names for the variables.
-- OR -Do not specify fix names for the variables.
-- OR -Do not set the MERGEABLE optimization flag in the variable
classes.
1253 / 1260
ID:
PR20080701-03
Title:
Validation error after XML Import of formerly exported file

containing variants and custom properties

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: When using the Data Dictionary XML export and import
feature, invalid Data
Dictionary may be generated.
This occurs if variables or other Data Dictionary objects have
varianted
properties of type String and Float mixed which leads to an
XML file containing
wrong types.
After import of such a XML file the Data Dictionary contains
some variables (or
other Data Dictionary objects) of Type String for the Value and
the Variant
property which leads to an error in level 4 validation.
Workaround: Before importing the corrupted XML file this has to be
corrected. For example
you can try to correct the corrupted file by an m-script with the
following or
similar contents (sample):
xDoc = xmlread(file);
% Find a deep list of all <ddVariantProperty> elements.
allListItems =
xDoc.getElementsByTagName('ddVariantProperty');
%Note that the item list index is zero-based.
for i=0:allListItems.getLength-1
thisListItem = allListItems.item(i);
Type = char(thisListItem.getAttribute('Type'));
if strcmp(Type,'String')
bProblematicConfig = 1;
thisListItem.setAttribute('Type','');
end
end
xmlwrite(file,xDoc);
1254 / 1260
ID:
PR20080701-05
Title:
Wrong constant propagation for macros, whose storage is

extern or whose alias property is on

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: A Stateflow variable that is specified as a macro, whose

storage is extern or
whose option alias is on, may be replaced by its value.
Workaround: Use property Info = adjustable to advise the code generator
that the macro has
no fixed value.
ID:
PR20080701-08
Title:
Parallel Stateflow transitions may be erroneously combined

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
1255 / 1260
Description: In the TargetLink Advanced Practices Guide > Working With

Stateflow > Flowchart
style guide > Conjunctions, a flow chart transformation is
described which
combines parallel conditional transitions into logical-or
expressions. The
transformation algorithm performs additional checking to
ensure semantic
equivalence with the original Stateflow model. This algorithm,
however, contains
a bug, so under certain circumstances the transformation will
be performed
erroneously.
Example:
|
V
O
/\
/\
[C2] ( ) [C1]
\/
\/
O
|
V
O
/\
/\
[C4] / \ [C3] { A; }
OO
| [C5]
V
O
If conditions C1 and C3 are true, and C5 and C4 are false, no
end node or state
has been reached, so the execution has to be backtracked to
the top junction.
After that, C2 has to be tested, so the action A may be
executed again.
The checking algorithm, however, ignores the condition C4, so
it assumes that
path is executed successfully and no backtracking will occur,
so C1 and C2 are
combined to C1 || C2, and A is executed only once.
Workaround: 1) Break up the [C4] transition in two segments, where the first
is
unconditional and the second is labeled with [C4], or
2) Change your modeling to avoid relying on backtracking.
1256 / 1260
ID:
PR20080702-03
Title:
A blocks is colored green without any reason

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
User interface
Description: When selecting a block during a model is loaded it happens

that this selected
block changes the color to green. This happens because the
TargetLink Utility
Blocks set their color depending on the blockset mode to
green for full-featured
or grey for stand-alone mode.
Only the color of the block is affected and no other property.
In the following situtation the color will be set to the wrong
block:
1) Open a model A
2) Change the directory
3) Open another model B from that current directory
A dialog comes up to to select a Data Dictionary project file.
4) While this dialog is open, select a block of the first model A
5) Press Continue in the Data Dictionary dialog
The selected block in model A is colored green.
Workaround: Do not select any block in any model while the Data Dictionary
selection dialog
is open.
1257 / 1260
ID:
PR20080702-06
Title:
Model Conversion aborts when a block named "Function"

resides in an atomic subsystem

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: To match Simulink's RTW settings, Model Conversion inserts

a TargetLink Function
block into subsystems that are atomic und reside underneath
the subsystem that
is being converted (i.e. made a TargetLink subsystem).
However, conversion
aborts if any block in this atomic subsystem is named
"Function". An error
message similar to the following is displayed in the Matlab
Command Window:
Inserting Function block into atomic subsystem ... ??? Error
using ==> add_block
A new block named
'myModel/Subsystem/AtomicSubsystem/Function' cannot be
added.
Error in ==> tl_add_block at 18
The error does not come up when the TargetLink Function
blocks already exists,
and is confined to models (as opposed to libraries).
Workaround: Before starting conversion, make sure atomic subsystems
inside the subsystem
that should be converted have no blocks that are called
"Function".
Alternatively, insert the TargetLink Function block(s) manually
before starting
conversion.
1258 / 1260
ID:
PR20080704-04
Title:
Common access function is not generated in AUTOSAR

model

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: Given is an AUTOSAR model with a subsystem that contains

a Runnable block. This
subsystem contains a subsystem with a Function block and a
variable which access
is specified to use an access function, thus in its variable class
the property
AccessFunctionTemplate is set to an existing access function
template.
Although this variable should be accessed by the specified
access function in
the source code, TargetLink will not generate an access
function, but a direct
access. This is not the expected behavior.
patches:
TargetLink 3.0.1p1
ID:
PR20080707-03
Title:
Code generation for referenced model may fail with interface

validation error

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Description: When using renamed base types in Data Dictionary as well as

user data types with
the CreateTypedef property set to "off", the code generation in
conjunction with
Model Referencing may fail with the following error
*** E08906: SYSTEM INTERFACES VALIDATION:
*** Data mismatch found. Property Name of typedef object
/Subsystems/RefSS/tl_basetypes/Typedefs/MYFLOAT differs
from the origin in the
pool area. Do not edit the subsystems area. If you have edited
the variable
class in the pool, run code generation for the referenced
model RefSS again.
Workaround: Set the CreateTypedef property to "on" for the types in
question.
1259 / 1260
ID:
PR20080711-06
Title:
Very slow code generation when large vector or matrix data is

used by Constant or Look-Up Table blocks

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
Class:
Utility
Description: The code generation process is very time consuming, if the

model contains blocks
with references to workspace variables with many vector
and/or matrix elements
(> 10000). This is the case even if the model contains only a
few blocks (< 10).
Very time consuming in this context means, the code
generation for such a small
model needs significantly more than several seconds on a
current computer
system.
This is due to the used XSLT transformation. Since each
vector and/or matrix
value is processed sequentally over XSLT, there will always
be noticable delay
with XSLT.
TargetLink uses XSLT for transforming the generated code
from XML to C code and
thus giving a possibility to the user to have influence on the
layout of the
generated code.
Workaround: No direct workaround. However sometimes the vector values
could be generated in
a separate file only once. Thus only by the first creation the
delay by a
generation would be significant.
1260 / 1260

dSPACE TargetLinkKnownProblemReport

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

dSPACE TargetLinkKnownProblemReport

Uploaded by

Copyright:

Available Formats

Known Problem Reports for dSPACE

Missing/wrong table entries in A2L file caused by wrong Data

Last Update: 08 Aug 2008

Initialization of TargetLink Function block failed after model

Last Update: 08 Aug 2008

Description: If a subsystem, in a user library, contain a TargetLink Function

Code generation may fail for TargetLink ports after model

Last Update: 08 Aug 2008

Aborted code generation

Description: Since TargetLink 2.0, i.e. even before special TargetLink

Hexadecimal values could not be used for Stateflow objects

Last Update: 08 Aug 2008

Aborted code generation

Description: It is not possible to define values of Stateflow objects as

Model upgrade may lead to Simulink crash

Last Update: 08 Aug 2008

Description: Model upgrade may fail on MATLAB R2006a+, R2006b,

Variable class with RestartFunctionName and Module entry at

Last Update: 08 Aug 2008

Incorrect code/not compilable

Description: A model contains a function-call triggered model referenced

Boolean data type at the output of Gain, Sum or Product block

Last Update: 08 Aug 2008

Description: For blocks of type TL_Gain, TL_Sum or TL_Product it is

Mask parameter containing arithmetic operators cannot be

Last Update: 08 Aug 2008

Description: If one value 'X' inside a masked subsystem is defined as mask

API command 'ddv' cannot be set as initial value of a Constant

Last Update: 08 Aug 2008

Description: If a block output or parameter is linked to a Data Dictionary

Crash when a model with trigger port at root level should be

Last Update: 08 Aug 2008

Error is issued if a referenced model is open in TargetLink's

Last Update: 08 Aug 2008

Missing bus signal label at BusOutport after model upgrade

Last Update: 08 Aug 2008

Description: In the following situation the label of a bus signal is missing

Code generation for Stateflow data with scope 'Data Store

Last Update: 08 Aug 2008

Aborted code generation

Erroneous warning #W02295 during MIL simulation

Last Update: 08 Aug 2008

Description: During MIL simulation the following warning

Stateflow machine variables are not logged during SIL

Last Update: 08 Aug 2008

Description: Stateflow machine variables are not logged during SIL

Upgrade changes MIL semantics of Rate Limiter block

Last Update: 08 Aug 2008

Description: The TargetLink 3.0 Rate Limiter block is implemented as a

Inconsistent matrices after upgrade of a Discrete State-Space

Last Update: 08 Aug 2008

Description: In TargetLink 2.x is it possible to define empty matrices for the

Wrong dereference in the code if a Stateflow data with scope

Last Update: 08 Aug 2008

Incorrect code/not compilable

Description: Normally all TargetLink settings of a Stateflow data with scope

Upgrade of a Bitwise Logical Operator from a user library may

Last Update: 08 Aug 2008

Description: If a model contains a Bitwise Logical Operator block from a

Erroneous detection of scaling data or signal size mismatch

Last Update: 08 Aug 2008

Incomprehensible message about size mismatch

Last Update: 08 Aug 2008