100% found this document useful (1 vote)

7K views

dSPACE TargetLinkKnownProblemReport

Targetlink known problems - very useful

Uploaded by

chandv

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (1 vote)

7K views

dSPACE TargetLinkKnownProblemReport

Targetlink known problems - very useful

Uploaded by

chandv

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 1260

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

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:

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

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:

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

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:

Aborted code generation

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

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:

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

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:

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

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:

API

Description: For blocks of type TL_Gain, TL_Sum or TL_Product it is

ID:

KPR.2008.07.29.007

Title:

Error is issued if a referenced model is open in TargetLink's

stand-alone mode

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:

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

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:

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

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:

Aborted code generation

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

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:

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.
Workaround: No workaround available.

10 / 1260

ID:

KPR.2008.07.30.002

Title:

Stateflow machine variables are not logged during SIL

simulation

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:

Simulation

Description: Stateflow machine variables are not logged during SIL

simulation. The plot
window appears, but there is no signals inside.
Workaround: No workaround available.

ID:

KPR.2008.07.30.004

Title:

Upgrade changes MIL semantics of Rate Limiter block

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:

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

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: 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

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:

Incorrect code/not compilable

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

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: 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

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:

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

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:

Aborted code generation

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

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: 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

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: 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

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: 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

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:

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

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: 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

Last Update: 08 Aug 2008

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

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:

Incorrect code/not compilable

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
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
/* Custom Code <<output code>> */
{
Sa3_CcOut = Sa2_PredVar[Aux_S32][0] +
Sa2_PredVar[Aux_S32][3] +
Sa2_PredVar[Aux_S32][9];
}
}
instead of
/* Custom Code <<output code>> */
{
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:

Incorrect code/compilable

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.
The problem is fixed by using the following patch or later
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

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:

Incorrect code/compilable

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

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:

Aborted code generation

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

Last Update: 30 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:

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

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:

Incorrect code/compilable

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

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 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>
Workaround: No workaround available.

ID:

KPR.2008.08.07.005

Title:

Inconsistant struct data type component names lead to error

F10008

Last Update: 15 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:

Aborted code generation

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
technical support team.
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

Last Update: 15 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:

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

Last Update: 30 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:

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:

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

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:

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

Last Update: 30 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:

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.
Workaround: No workaround available.

38 / 1260

ID:

KPR.2008.09.09.010

Title:

Wrong name shortening of access function name which

Missing rescaling at outport of scaling invariant subsystem

Last Update: 30 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:

Incorrect code/compilable

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

Last Update: 30 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:

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

Last Update: 30 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:

Incorrect code/not compilable

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

Last Update: 30 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:

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

Last Update: 30 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:

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

Last Update: 30 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:

Incorrect code/compilable

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"

Last Update: 30 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:

Aborted code generation

Description: Code generation of TargetLink AUTOSAR model faild with

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

Last Update: 30 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:

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

Last Update: 30 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:

Incorrect code/compilable

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

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:

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

Last Update: 30 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:

Incorrect code/compilable

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

Last Update: 30 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:

Inefficient code/code style

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
function call triggered
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

Last Update: 30 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:

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

Last Update: 30 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:

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).
Workaround: No workaround available.

ID:

KPR.2008.10.16.002

Title:

Code generation aborts with fatal error F99999

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:

Aborted code generation

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

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:

Inefficient code/code style

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.
Workaround: No workaround available.

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

Last Update: 30 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:

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

Last Update: 30 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:

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

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:

Utility

Description: Local Stateflow variables and inputs and outputs of Stateflow

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

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:

Aborted code generation

Description: The Data Dictionary interface validation for a referenced

ID:

KPR.2008.10.27.005

Title:

Scaling invariance combined with pointer to struct results in

incorrect production code

Last Update: 14 Aug 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:

Incorrect code/compilable

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
Workaround: No workaround available.

65 / 1260

ID:

KPR.2008.11.06.001

Title:

Code generation aborts with fatal error F10007 issued by

TlCNameMacroAnalysis

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:

Aborted code generation

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

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:

Incorrect code/not compilable

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

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:

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

Last Update: 11 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: 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

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:

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

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:

Incorrect code/compilable

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.
The problem is fixed by using the following patch or later
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

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:

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

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:

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

Last Update: 11 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:

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');
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p9

73 / 1260

ID:

KPR.2008.11.26.004

Title:

System Checker scales poorly for specific use case

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:

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

Last Update: 18 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:

Incorrect code/compilable

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
The problem is fixed by using the following patch or later
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

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:

Incorrect code/not compilable

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

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: 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

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:

Inefficient code/code style

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.
Workaround: No workaround available.

77 / 1260

ID:

KPR.2008.11.26.009

Title:

Communication mode of interrunnable variables

Last Update: 11 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:

Incorrect code/not compilable

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

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:

Aborted code generation

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

Last Update: 20 Oct 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:

Incorrect code/compilable

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

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:

Aborted code generation

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

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:

Inefficient code/code style

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.
Workaround: No workaround available.

82 / 1260

ID:

KPR.2008.12.05.001

Title:

String in custom code file may be wrapped erroneous in

production code

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:

Incorrect code/not compilable

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

Last Update: 11 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:

Incorrect code/compilable

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'.
The problem is fixed by using the following patch or later
patches:
TargetLink 2.3.1p2

84 / 1260

ID:

KPR.2008.12.10.002

Title:

Inlining may Hide Problems with Insufficient Initial Scope of

Variables

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:

Incorrect code/not compilable

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

Last Update: 11 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:

Aborted code generation

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.
2. The LookupFunctionName property of the
LookupFunctionTemplate is set to a
string containing $S, code generation is possible and the lookup function
wouldn't be reused. You can find one function for each block.
3. The LookupFunctionName property of the
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.>)
-- OR -- the LookupFunctionName property of the used
LookupFunctionTemplate is set to a
fixed name
-- OR -- the LookupFunctionName property of the used
LookupFunctionTemplate is set to
'Prefix$(FunctionName)Suffix'
-- OR -- the LookupFunctionName property of the used
LookupFunctionTemplate is set to
$(FunctionName).

87 / 1260

ID:

KPR.2008.12.18.002

Title:

Superfluous warning about insufficient constant value

representation

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:

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.
Workaround: No workaround available.

88 / 1260

ID:

KPR.2008.12.18.003

Title:

is outside its constrained range

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:

Incorrect code/compilable

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.
Workaround: No workaround available.

ID:

KPR.2009.01.06.002

Title:

Erroneous code for binary bitwise operation in Stateflow with a

constant value as second operand

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:

Incorrect code/compilable

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

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:

Incorrect code/compilable

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.
Workaround: No workaround available.

99 / 1260

ID:

KPR.2009.01.06.005

Title:

Propagation of function calls in function call argument may

lead to wrong execution order

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:

Incorrect code/compilable

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

Last Update: 11 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:

Utility

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

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:

Aborted code generation

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:

TargetLink 2.2 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: 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] = ...;
LOG_VEC(a, _SwitchPred1, 2 /* 2. */, SwitchPred1);
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] = ...;
LOG_VEC(a, _SwitchPred1, 2 /* 2. */, SwitchPred1);
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

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:

Incorrect code/not compilable

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 2.3.1p2

116 / 1260

ID:

KPR.2009.02.19.001

Title:

Netlist creation fails for model containing Goto Tag Visibility

block

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:

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.
Workaround: No workaround available.

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

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:

Incorrect code/compilable

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.
Workaround: No workaround available.

117 / 1260

ID:

KPR.2009.02.22.001

Title:

Erroneous rescaling of inlined pointer to struct / function reuse

component

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:

Incorrect code/compilable

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

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:

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:
Message 8805, Kind Warning
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

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:

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"

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:

Aborted code generation

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

Last Update: 11 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 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

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:

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

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:

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 2.3.1p3

123 / 1260

ID:

KPR.2009.03.02.006

Title:

Unused variables in code for cascade of Merge blocks

Last Update: 23 Jul 2009

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

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:

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

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:

Aborted code generation

Description: If the output of a custom code block is optimized and replaced

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 2.3.1p2

ID:

KPR.2009.03.25.004

Title:

Atomic system boundaries can be erroneously bypassed due

to optimization and inlining

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:

Inefficient code/code style

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

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:

Aborted code generation

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

Last Update: 14 Aug 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:

Incorrect code/compilable

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

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:

Aborted code generation

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

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:

Aborted code generation

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:
Exception: ACCESS_VIOLATION
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
D:\TL_2_3_1_installed\MATLAB\tl\Bin\XcgCVT.dll
25A34EBD 00CE387C 0001:003F3EBD
D:\TL_2_3_1_installed\MATLAB\tl\Bin\XcgCVT.dll
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
The problem is fixed by using the following patch or later
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

Last Update: 27 Aug 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:

Aborted code generation

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

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:

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

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:

Aborted code generation

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".
The problem is fixed by using the following patch or later
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

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:

Inefficient code/code style

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

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:

Incorrect code/compilable

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

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:

Incorrect code/compilable

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.
The problem is fixed by using the following patch or later
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

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:

Simulation

Description: During MIL simulation the error message

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

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:

Aborted code generation

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

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:

Aborted code generation

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
technical support team.
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

Last Update: 11 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:

Incorrect code/compilable

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

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:

Incorrect code/not compilable

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.

system the code
generation may aborts with a fatal error #30016 or an access
violation.
Examples:
Exception: ACCESS_VIOLATION
Fault address: 2422EA45 01:0002DA45
D:\TargetLink\released\TL3.0\Matlab\Tl\bin\XcgExprDes.dll
Call stack:
Address Frame
2422EA45 00D0BC70 0001:0002DA45
D:\TargetLink\released\TL3.0\Matlab\Tl\bin\XcgExprDes.dll
24228289 00D0BCD8 0001:00027289
D:\TargetLink\released\TL3.0\Matlab\Tl\bin\XcgExprDes.dll
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

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:

Incorrect code/compilable

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

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:

TargetLink 2.2 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: 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

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:

Incorrect code/compilable

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
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

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:

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

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:

Incorrect code/compilable

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

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:

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

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:

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.
Workaround: No workaround available.

159 / 1260

ID:

KPR.2009.06.18.010

Title:

Download of application may fail on TSM MPC5554DEMO\GNU

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:

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

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:

Incorrect code/not compilable

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

Last Update: 11 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:

Aborted code generation

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

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:

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

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:

Incorrect code/compilable

Description: An index expression will be calculated incorrect if all the

ID:

KPR.2009.06.22.003

Title:

Instance-specific structures (function reuse) are not initialized

in AUTOSAR software component init functions

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:

Incorrect code/compilable

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 11 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:

Aborted code generation

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

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:

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.
The problem is fixed by using the following patch or later
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

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:

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

Last Update: 11 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:

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.
The problem is fixed by using the following patch or later
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

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:

Incorrect code/not compilable

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

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:

Incorrect code/compilable

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

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:

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

Last Update: 11 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:

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

Last Update: 11 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:

Aborted code generation

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 {
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
Switch[Aux_S32] = in11[Aux_S32];
}
}
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
Out[Aux_S32] = Switch[Aux_S32];
}
the Switch variable is eliminated, leading to
if (cond) {
Out[0] = in1;
...
Out[9] = in10;
} else {
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
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 {
for (Aux_S32 = 0; Aux_S32 < 7; Aux_S32++) {
Switch[Aux_S32] = in11[Aux_S32];
}
for (Aux_S32 = 0; Aux_S32 < 3; Aux_S32++) {
Switch[Aux_S32+7] = in12[Aux_S32];
}
}
for (Aux_S32 = 0; Aux_S32 < 7; 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 {
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
Switch2[Aux_S32] = in11[Aux_S32];
}
}
} else {
for (Aux_S32 = 0; Aux_S32 < 7; Aux_S32++) {
Switch2[Aux_S32] = in11[Aux_S32];
}
...
}
for (Aux_S32 = 0; Aux_S32 < 7; 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

185 / 1260

ID:

KPR.2009.07.13.002

Title:

Data Dictionary MATLAB API SyncType command stops if

Constraints.Min or Constraints.Max are missing

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:

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

Last Update: 11 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:

Incorrect code/not compilable

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

Last Update: 11 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:

Incorrect code/compilable

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

Last Update: 11 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:

Aborted code generation

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

Last Update: 14 Aug 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:

Incorrect code/compilable

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

Last Update: 11 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:

Incorrect code/compilable

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

Last Update: 14 Aug 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:

Incorrect code/compilable

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

Last Update: 11 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:

Aborted code generation

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.
Workaround: No workaround available.

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

Last Update: 14 Aug 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:

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.
Workaround: No workaround available.

192 / 1260

ID:

KPR.2009.07.30.010

Title:

Superfluous preprocessor encapsulation of local variables

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:

Inefficient code/code style

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
...
}
...
}
Workaround: No workaround available.

193 / 1260

ID:

KPR.2009.07.30.011

Title:

Preprocessor macro without module can lead to wrong code

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:

Incorrect code/compilable

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

Last Update: 19 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:

Aborted code generation

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

Last Update: 11 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:

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});
Workaround: No workaround available.

195 / 1260

ID:

KPR.2009.08.04.001

Title:

Imported AUTOSAR units are not valid

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:

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

Last Update: 11 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:

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)

Last Update: 11 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:

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

Last Update: 11 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:

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

Last Update: 11 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:

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

Last Update: 11 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:

Aborted code generation

Description: If a custom-specific C functions is called from Stateflow and at

ID:

KPR.2009.08.10.001

Title:

Missing scaling for constant on the right hand side of a

saturated assignment

Last Update: 14 Aug 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:

Incorrect code/compilable

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

Last Update: 11 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:

Aborted code generation

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

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:

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 2.3.1p3

ID:

KPR.2009.08.13.001

Title:

Code generation aborts with error 02900 for a Client Port

block

Last Update: 11 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: 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

Last Update: 11 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: 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

Last Update: 02 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:

Aborted code generation

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
[3] libmwsimulink.dll:class slsvErrMsgQueue * __cdecl
BuildPortBusStructArrayFromSLbus(struct SLbus_tag const
*,struct mxArray_tag *
*)(0x229996c0 "? ", 0x6f9a1900, 0x20e3e5c0, 59) + 140
bytes
[4] libmwsimulink.dll:class slsvErrMsgQueue * __cdecl
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
[8] libmwsimulink.dll:class slsvErrMsgQueue * __cdecl
get_param_from_index(void const *,int,char const *,struct
mxArray_tag * *,class
SLPrmDesc * *,unsigned int,bool)(0x20e3e5c0, 59,
0x00d3698c "BusStruct",
0x00d36a9c) + 61 bytes
[9] libmwsimulink.dll:class slsvErrMsgQueue * __cdecl
get_port_object_param(void *,char const *,struct mxArray_tag
* *)(59, 0x00d3698c
"BusStruct", 0x00d36a9c, 0x00d36afc "`y"`a"k") + 225
bytes
[10] libmwsimulink.dll:class slsvErrMsgQueue * __cdecl
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

Last Update: 11 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:

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

Last Update: 31 May 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:

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

Last Update: 11 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:

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

Last Update: 11 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:

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

Last Update: 11 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:

Incorrect code/compilable

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

Last Update: 11 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:

Incorrect code/compilable

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

Last Update: 11 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:

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:
Message 8832, Kind 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.
Workaround: No workaround available.

ID:

KPR.2009.09.21.003

Title:

Erroneous Float64 cast in bitwise operation

Last Update: 11 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:

Inefficient code/code style

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

Last Update: 11 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: 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

Last Update: 26 May 2011

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

Last Update: 11 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:

Incorrect code/compilable

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

Last Update: 11 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:

Simulation

Description: A MIL simulation of a TargetLink model may lead to a

MATLAB crash if the model
contains
- non-virtual buses
-- AND -- busobjects
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 11 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:

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

Last Update: 11 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:

Inefficient code/code style

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
#define VC1_Const2 (Int16) 20
/* PreDefinitionBlockStatement VC1 */
/******************************************************************************\
MACRO_VC2: global preprocessor macros
\******************************************************************************/
#define VC2_Const1 (Int16) 30
#define VC2_Const2 (Int16) 40
/* PostDefinitionBlockStatement VC1 */
...
but it should look like this
/*----------------------------------------------------------------------------*\
DEFINES
\*----------------------------------------------------------------------------*/
/* PreDefinitionBlockStatement VC1 */
/******************************************************************************\
MACRO_VC1: global preprocessor macros
\******************************************************************************/
#define VC1_Const1 (Int16) 10
#define VC1_Const2 (Int16) 20
/* PostDefinitionBlockStatement VC1 */
/* PreDefinitionBlockStatement VC2 */

autoscaling if
- simulated ranges should be used
-- AND -- headroom unit is "bit"
-- AND -- headroom value is not 1
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p2

ID:

KPR.2009.11.25.001

Title:

Misleading error message after Data Dictionary upgrade

Last Update: 11 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:

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

Last Update: 11 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:

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

Last Update: 11 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:

Inefficient code/code style

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

Last Update: 11 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: 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

Last Update: 11 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:

Aborted code generation

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

Last Update: 11 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:

Incorrect code/not compilable

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

Last Update: 23 Jul 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:

Incorrect code/compilable

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).
The problem is fixed by using the following patch or later
patches:
TargetLink 2.3.1p6

235 / 1260

ID:

KPR.2009.11.25.011

Title:

Error #17002 although variables have different names

Simulation

"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
Optimization property
(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

Last Update: 11 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:

Incorrect code/compilable

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
for (Aux_S32 = 0; Aux_S32 < 6; Aux_S32++) {
MyConstantVector[Aux_S32] = 17;
}
Aux_U16 = 0;
for (Aux_S32 = 0; Aux_S32 < 6; Aux_S32++) {
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

Last Update: 11 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:

Incorrect code/compilable

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

Last Update: 11 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:

Incorrect code/compilable

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

Last Update: 08 Jul 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:

Incorrect code/not compilable

Description: If an interface variable of a referenced system is specified in

ID:

KPR.2009.12.17.007

Title:

A user defined InitFcn of a model is not executed during code

generation

Last Update: 11 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: 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.
Workaround: No workaround available.

255 / 1260

ID:

KPR.2009.12.17.008

Title:

Segmentation violation during worst case range calculation of

MPC5(x)xx/Diab/GHS

Last Update: 11 Feb 2010

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:

Incorrect code/compilable

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

Last Update: 11 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:

Aborted code generation

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

Last Update: 13 Sep 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

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

Last Update: 11 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:

Incorrect code/compilable

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

Last Update: 11 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

261 / 1260

Class:

Incorrect code/compilable

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
Optimization property
-- 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.
The problem is fixed by using the following patch or later
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

Last Update: 11 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:

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

Last Update: 11 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:

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p5

265 / 1260

ID:

KPR.2009.12.21.004

Title:

calibration interface for a look-up table

Last Update: 25 Oct 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:

Incorrect code/not compilable

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

Last Update: 11 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:

Aborted code generation

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p1

270 / 1260

ID:

KPR.2010.01.08.004

Title:

Wrong display of signal data in busport block dialog

Last Update: 11 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 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.
The problem is fixed by using the following patch or later
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"

Last Update: 11 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:

Inefficient code/code style

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.
Workaround: No workaround available.

271 / 1260

ID:

KPR.2010.01.11.001

Title:

Missing MERGEABLE attributes for CALPRM in AUTOSAR master template

dsdd_master_autosar.dd

Last Update: 11 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:

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

Last Update: 11 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:

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
Workaround: No workaround available.

273 / 1260

ID:

KPR.2010.01.12.001

Title:

Data variant switch variable missing in the generated TRC file

Last Update: 11 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:

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p2

274 / 1260

ID:

KPR.2010.01.12.002

Title:

Block dialog erroneously shows message about inconsistant

data for a parameter

Last Update: 11 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:

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p2

ID:

KPR.2010.01.12.003

Title:

Model initialization fails after upgrade

Last Update: 11 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:

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

Last Update: 11 Feb 2010

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

Last Update: 07 Dec 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:

Incorrect code/compilable

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.
The problem is fixed by using the following patch or later
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

Last Update: 11 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:

Aborted code generation

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

Last Update: 11 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:

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.
Workaround: No workaround available.

ID:

KPR.2010.01.14.004

Title:

Wrong data type at the output of TargetLink subsystem in

SIL/PIL mode

Last Update: 11 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:

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"

Last Update: 15 Dec 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:

Incorrect code/compilable

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

Last Update: 11 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:

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 11 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:

Aborted code generation

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:
An internal error occurred during implementation of function
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

Last Update: 11 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: 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.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p2

ID:

KPR.2010.01.21.001

Title:

Wrong rounding of Float32 value in relational operation yields

incorrect code

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:

Incorrect code/compilable

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

Last Update: 11 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:

Simulation

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

Last Update: 03 Mar 2010

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:

Aborted code generation

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++)
{
Sa1_GainOut[i] = Sa1_GainIn[i] * 42;
}
for(j = 0; j < 8; j++)
{
Sa1_Gain2Out[j] = Sa1_GainOut[j] * 3;
}
is combined to
for(i = 0; i < 8; i++)
{
Sa1_GainOut[i] = Sa1_GainIn[i] * 42;
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).
The problem is fixed by using the following patch or later
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

Last Update: 15 Dec 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:

Incorrect code/not compilable

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

ID:

KPR.2010.02.17.011

Title:

Faulty export of subpackages and AUTOSAR elements in the

same root package

Last Update: 14 May 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 14 May 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:

Incorrect code/compilable

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

Last Update: 31 May 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:

Incorrect code/not compilable

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
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p2

309 / 1260

ID:

KPR.2010.02.18.003

Title:

Wrong treatment of block tag during model upgrade

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

Last Update: 16 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:

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:
*** E00000: ERROR USING I_GETSOURCESIGNAL:
*** Internal Error:
*** Number of source signals does not match the number of
output
signals.
*** Please contact dSPACE technical support.
Workaround: Create an atomic subsystem (with Function block) on root
level as a frame for
all other subsystems.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p2

ID:

KPR.2010.02.26.002

Title:

Order of arguments in operation call may be wrong

Last Update: 16 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:

Incorrect code/compilable

Description: The order of arguments in the generated code of an operation

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

Last Update: 16 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:

Aborted code generation

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).
The problem is fixed by using the following patch or later
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

Last Update: 09 Dec 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:

Incorrect code/compilable

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

Last Update: 16 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:

Incorrect code/compilable

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

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:

Incorrect code/compilable

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".
The problem is fixed by using the following patch or later
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

Last Update: 16 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: 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:

AUTOSAR description files

Last Update: 23 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 16 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:

Incorrect code/compilable

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

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:

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 20 Oct 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:

Incorrect code/not compilable

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

Last Update: 23 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:

Aborted code generation

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 23 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:

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

Last Update: 23 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:

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

Last Update: 23 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:

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.
Workaround: No workaround available.
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

Last Update: 23 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:

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
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p3

337 / 1260

ID:

KPR.2010.05.05.001

Title:

Different results from tl_get_blocks

Last Update: 23 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:

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>.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p3

341 / 1260

ID:

KPR.2010.05.27.002

Title:

Error message 8665 (Invalid DD output) issued during A2L file

export

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:

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.
Workaround: No workaround available.

342 / 1260

ID:

KPR.2010.06.07.003

Title:

Incorrect code for numerical integer function argument

Last Update: 09 Dec 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:

Incorrect code/compilable

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

Last Update: 09 Dec 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:

350 / 1260

ID:

KPR.2010.06.14.002

Title:

Rows in Property Manager's Block Explorer may become

unsynchronized

Last Update: 23 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:

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

Last Update: 23 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:

Utility

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

Last Update: 09 Dec 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:

Inefficient code/code style

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

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:

Incorrect code/compilable

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.
Workaround: No workaround available.

ID:

KPR.2010.06.23.001

Title:

Call to client/server operation without argument cannot be created by the

SWC model generator

Last Update: 08 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:

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.
Workaround: No workaround available.
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

Last Update: 06 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:

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p3

359 / 1260

ID:

KPR.2010.07.01.001

Title:

MODULE IF_DATA does not appear in the generated A2L file

Last Update: 08 Jul 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:

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

Last Update: 09 Dec 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:

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;
Workaround: No workaround available.

360 / 1260

ID:

KPR.2010.07.05.001

Title:

Dialog of Bus Outport block shows wrong properties of a

signal

Last Update: 08 Jul 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: 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.
The problem is fixed by using the following patch or later
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

Last Update: 09 Dec 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:

Inefficient code/code style

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 06 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:

Aborted code generation

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p3

362 / 1260

ID:

KPR.2010.07.05.004

Title:

Aftereffects of inconsistent TargetLink simulation frame

Last Update: 09 Dec 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 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

Last Update: 06 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:

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p4

363 / 1260

ID:

KPR.2010.07.05.006

Title:

Unintended library link resulting from copy action within a

library

Last Update: 09 Dec 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: 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

Last Update: 09 Dec 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:

Incorrect code/compilable

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)
C__I16SATU64_SATb(v_h, v_l, upsatval, losatval)
C__I16SATU64_SATu(v_h, v_l, upsatval)
C__I8SATU64_SATb(v_h, v_l, upsatval, losatval)
C__I8SATU64_SATu(v_h, v_l, upsatval)
Workaround: No workaround available.

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

Last Update: 09 Dec 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:

Incorrect code/compilable

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.
Workaround: No workaround available.

365 / 1260

ID:

KPR.2010.07.16.001

Title:

matrix values from DataDictionary

Last Update: 06 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:

User interface

Description: The block dialog of Discrete State-Space block aborts, if

following conditions
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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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."

Last Update: 06 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:

TargetLink 2.2 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: 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

Last Update: 15 Dec 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:

Incorrect code/compilable

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

Last Update: 15 Dec 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:

Incorrect code/compilable

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
output = foo(input);
something = output + input;
which is wrong.
Workaround: 1) Do not use inputs as temporary variables
2) For Stateflow specification
output = foo(input);
something = output + input;
TargetLink generates
aux_input = input;
output = foo(aux_input);
something = output + input;
which is correct but will be optimized wrongly. You can make
this explicit
by specifying
fooInput = input;
output = foo(fooInput);
something = output + input;
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

Last Update: 15 Jun 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:

Incorrect code/compilable

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

Last Update: 15 Dec 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:

Incorrect code/compilable

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

Last Update: 15 Dec 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:

Incorrect code/compilable

Description: Let A be a variable with a variable vector width, and let M be

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

Last Update: 15 Dec 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:

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

Last Update: 15 Dec 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:

Aborted code generation

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:

output ports to be logged in MIL simulation mode

Last Update: 15 Dec 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:

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

Last Update: 15 Dec 2010

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
Workaround: No workaround available.

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

Last Update: 10 Dec 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:

Aborted code generation

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

Last Update: 15 Dec 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:

TargetLink 2.2 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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p4

395 / 1260

ID:

KPR.2010.09.20.004

Title:

Incorrect code for bitwise operation with operation as operand

in Stateflow

Last Update: 15 Dec 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:

Incorrect code/compilable

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.
Workaround: - Disable the Code Generator option
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

Last Update: 21 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:

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

Last Update: 07 Dec 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:

Incorrect code/compilable

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;
will be implemented as
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".
The problem is fixed by using the following patches or later
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

Last Update: 15 Dec 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: 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

Last Update: 07 Dec 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:

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.
The problem is fixed by using the following patches or later
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

Last Update: 15 Dec 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:

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
The error message is like the following:
?? 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.
The problem is fixed by using the following patch or later
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

Last Update: 15 Dec 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:

Simulation

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.
The problem is fixed by using the following patch or later
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

Last Update: 15 Dec 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:

Simulation

work incorrectly or
aborts if the following conditions are met:
- A stand-alone S-function has been generated for the
TargetLink subsystem
-- 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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p4

408 / 1260

ID:

KPR.2010.11.22.010

Title:

Autoscaling based on user range is wrong for Stateflow inputs

Last Update: 15 Dec 2010

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

Last Update: 15 Dec 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: 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:

Last Update: 15 Dec 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: 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
The problem is fixed by using the following patch or later patches:
TargetLink 3.2p1

ID:

KPR.2010.11.29.004

Title:

Incorrect block execution order in conjunction with Merge

blocks between triggered subsystems

Last Update: 15 Dec 2010

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'."

Last Update: 15 Dec 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 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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 15 Dec 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:

Incorrect code/compilable

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:
for (Sa2_loop_it = 0; Sa2_loop_it <= 16; Sa2_loop_it++)
{
_tmpu_A = GetAIndexed(Sa2_loop_it);
f(&_tmpu_A, I, &_tmpd_D);
SetDIndexed(Sa2_loop_it, _tmpd_D);
}
Actual (incorrect) code:
for (Sa2_loop_it = 0; Sa2_loop_it <= 16; Sa2_loop_it++)
{
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:
for (Sa2_loop_it = 0; Sa2_loop_it <= 16; Sa2_loop_it++)
{
f(&(RetrieveA()[Sa2_loop_it]), I, &(RetrieveD()[Sa2_loop_it]));
}
Actual (incorrect) code:
for (Sa2_loop_it = 0; Sa2_loop_it <= 16; Sa2_loop_it++)
{
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);
_tmp_A[1] = GetAIndexed(1);
_tmp_A[2] = GetAIndexed(2);
_tmp_A[3] = GetAIndexed(3);
_tmp_A[4] = GetAIndexed(4);
/* 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

Last Update: 15 Dec 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:

Incorrect code/compilable

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
Workaround: No workaround available.

ID:

KPR.2010.11.30.004

Title:

Potentially wrong optimization of custom code or function call

in For Iterator subsystem

Last Update: 02 Aug 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:

Incorrect code/compilable

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_Gain[4] = Sa1_In[4];
Sa1_Gain2[0] = Sa1_Gain[0];
...
Sa1_Gain2[4] = Sa1_Gain[4];
TargetLink creates
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
Sa1_Gain[Aux_S32] = Sa1_In[Aux_S32];
}
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
Sa1_Gain2[Aux_S32] = Sa1_Gain[Aux_S32];
}
and combines these loops if possible to
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];
}
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];
}
for (Aux_S32 = 0; Aux_S32 < 16; Aux_S32++)
{
/* Custom code: .... */
{
... /* some custom code */
}
}
This might be optimized to a single loop
for (Aux_S32 = 0; Aux_S32 < 16; Aux_S32++)
{
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

Last Update: 15 Dec 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:

Incorrect code/compilable

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

Last Update: 15 Dec 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:

Incorrect code/compilable

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

Last Update: 15 Dec 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:

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

Last Update: 15 Dec 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:

Aborted code generation

Description: TargetLink does not support duplicate inports. Duplicate

436 / 1260

ID:

KPR.2010.12.03.002

Title:

Upgrade of a model using libraries fails

Last Update: 15 Dec 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: Following error may occur during an upgrade 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:

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.
Workaround: No workaround available.

441 / 1260

ID:

KPR.2010.12.07.006

Title:

Incorrect code for Stateflow switch pattern

Last Update: 15 Dec 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:

Incorrect code/compilable

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++;
}
Workaround: No workaround available.

442 / 1260

ID:

KPR.2010.12.07.007

Title:

Interpolation (n-D) using PreLook-up block calculates wrong

values under certain conditions

Last Update: 15 Dec 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:

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).
The problem is fixed by using the following patches or later
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

Last Update: 15 Dec 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:

Incorrect code/compilable

Description: TargetLink moves calculations that are only needed in a

conditionally executed
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.
The problem is fixed by using the following patch or later
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

Last Update: 15 Dec 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:

Aborted code generation

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.2p1

ID:

KPR.2010.12.07.010

Title:

Uninitialized local variable is used in index operation

Last Update: 09 Dec 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:

Incorrect code/compilable

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
Sa1_Gain[0] = Sa1_In[0];
...
Sa1_Gain[4] = Sa1_In[4];
Sa1_Gain2[0] = Sa1_Gain[0];
...
Sa1_Gain2[4] = Sa1_Gain[4];
TargetLink creates
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
Sa1_Gain[Aux_S32] = Sa1_In[Aux_S32];
}
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
Sa1_Gain2[Aux_S32] = Sa1_Gain[Aux_S32];
}
and combines these loops if possible to
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
446 / 1260

{
Sa1_Gain[Aux_S32] = Sa1_In[Aux_S32];
Sa1_Gain2[Aux_S32] = Sa1_Gain[Aux_S32];
}
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
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
Sa1_OuterGain[Aux_S32] = Sa1_OuterIn[Aux_S32];
}
that feeds a subsystem InnerSubsystem that will be inlined
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
Sa2_InnerIn[Aux_S32] = Sa1_OuterGain[Aux_S32];
}
The InnerSubsystem contains a Gain block
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
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.
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
Sa2_InnerOut[Aux_S32] = Sa2_InnerGain2[Aux_S32];
}
The inlined InnerSubsystem is followed by a Gain in the
surrounding subsystem
447 / 1260

for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)

{
Sa1_OuterGain2[Aux_S32] = Sa2_InnerOut[Aux_S32];
}
The code for this model shall be
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
Sa1_OuterGain[Aux_S32] = Sa1_OuterIn[Aux_S32];
Sa2_InnerIn[Aux_S32] = Sa1_OuterGain[Aux_S32];
Sa2_InnerGain[Aux_S32] = Sa2_InnerIn[Aux_S32] * 42;
}
code of none mergeable block like
Sa2_X = ...
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
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
for(Aux_S32 = 0; Aux_S32 < 5; Aux_S32++)
{
Sa1_OuterGain[Aux_S32] = Sa1_OuterIn[Aux_S32];
Sa2_InnerIn[Aux_S32] = Sa1_OuterGain[Aux_S32];
Sa2_InnerGain[Aux_S32] = Sa2_InnerIn[Aux_S32] * 42;
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.
The problem is fixed by using the following patches or later
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

Last Update: 11 May 2012

Incorrect code/not compilable

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

Last Update: 14 Jan 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:

Inefficient code/code style

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

Last Update: 20 Jan 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:

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:

Aborted code generation

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

Last Update: 14 Jan 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:

Incorrect code/compilable

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

Last Update: 14 Jan 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:

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.
Workaround: No workaround available.
The problem is fixed by using the following patches or later
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

Last Update: 01 Aug 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:

Simulation

Description: If a function-call triggered subsystem resides inside a

Incorrect code/compilable

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);
will be implemented as
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"

Last Update: 04 Feb 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:

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

Last Update: 25 Mar 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:

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.
Workaround: No workaround available.

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."

Last Update: 04 Feb 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 30 Mar 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:

Aborted code generation

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.
The problem is fixed by using the following patches or later
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

Last Update: 18 Mar 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:

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
Optimization property.
- 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

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

Last Update: 18 Mar 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:

Incorrect code/not compilable

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
COMPILING FAILED. See
.\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

Last Update: 30 Mar 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:

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:

Last Update: 05 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:

Utility

TargetLink 2.2 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: 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"

Last Update: 25 Mar 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:

Incorrect code/compilable

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.
The problem is fixed by using the following patch or later
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

Last Update: 30 Mar 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 11 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:

Incorrect code/compilable

Description: If an address mapped macro is used in arithmetic, logical or

489 / 1260

ID:

KPR.2011.03.21.002

Title:

Problems during AUTOSAR import of DATA-CONSTR

elements

Last Update: 30 Mar 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:

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.
Workaround: No workaround available.
The problem is fixed by using the following patches or later
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

Last Update: 05 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:

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.
The problem is fixed by using the following patches or later
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

Last Update: 01 Jun 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:

Inefficient code/code style

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.
The problem is fixed by using the following patch or later
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

Last Update: 11 Nov 2011

Aborted code generation

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

Last Update: 11 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:

Incorrect code/compilable

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

Last Update: 01 Jun 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:

Incorrect code/compilable

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:

Last Update: 26 May 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:

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.
Workaround: No workaround available.
The problem is fixed by using the following patches or later
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

Last Update: 26 May 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 29 Jul 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:

Aborted code generation

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

Last Update: 26 May 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:

Incorrect code/not compilable

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.

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.
Workaround: No workaround available.

504 / 1260

ID:

KPR.2011.04.27.006

Title:

Incorrect code for function call of external Stateflow function in

reused functions

Last Update: 29 Aug 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:

Incorrect code/not compilable

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

Last Update: 14 Dec 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:

Aborted code generation

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:
Internal error. Error code:
[...]\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

Last Update: 26 May 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:

Inefficient code/code style

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.
The problem is fixed by using the following patch or later
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"

Last Update: 11 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:

Aborted code generation

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.
Fatal #10007: Internal error. Error code:
TlCTraceFallThrough.cpp_ 271.
Contact dSPACE's technical support team.
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

Last Update: 26 May 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 09 Dec 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:

Incorrect code/compilable

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.
Workaround: No workaround available.

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]

Last Update: 08 Mar 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:

Incorrect code/compilable

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];
Sa1_OutPort[1] = Ca1_loc[1];
Sa1_OutPort[2] = Ca1_loc[2];
Sa1_OutPort[3] = Ca1_loc[3];
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
ERASABLE Optimization
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

Last Update: 26 May 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:

Incorrect code/compilable

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

Last Update: 26 May 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 02 Dec 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:

Incorrect code/compilable

"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

Last Update: 29 Jul 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:

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.
Workaround: No workaround available.

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

Last Update: 11 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:

Incorrect code/compilable

Description: TargetLink generates wrong production code, which may

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 02 Dec 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:

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:

variable to a function

Last Update: 04 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:

Incorrect code/compilable

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

Last Update: 04 Nov 2011

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:

Incorrect code/compilable

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.
The problem is fixed by using the following patch or later
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

Last Update: 02 Dec 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:

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

Last Update: 02 Dec 2011

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:
/begin CHARACTERISTIC
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

Last Update: 18 Jan 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

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

Last Update: 07 Dec 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:

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.
Workaround: No workaround available.

534 / 1260

ID:

KPR.2011.08.24.009

Title:

Incorrect code caused by recursive function call in if-else or

switch-case statement

Last Update: 16 May 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:

Incorrect code/compilable

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.
Workaround: - Disable the Code Generator option
"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.
The problem is fixed by using the following patches or later
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"

Last Update: 02 Dec 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:

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;
unsigned char bf_2 : 1;
unsigned char bf_3 : 1;
}
UInt16 c_UInt16;
}
struct MyStructOk {
UInt8 c_UInt8;
struct MyBfStruct
{
unsigned int bf_1 : 1;
unsigned int bf_2 : 1;
unsigned int bf_3 : 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

Last Update: 04 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:

Aborted code generation

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

Last Update: 23 Sep 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:

Incorrect code/compilable

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).
The problem is fixed by using the following patch or later
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

Last Update: 04 Nov 2011

Last Update: 04 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:

Incorrect code/compilable

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

Last Update: 18 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:

Incorrect code/compilable

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

Title:

Changes to certain TargetLink global preferences may not

become immediately active

Last Update: 08 Mar 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

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

Last Update: 16 Dec 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:

Aborted code generation

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.
The problem is fixed by using the following patches or later
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:

Incorrect code/compilable

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:

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

Last Update: 27 Jan 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:

Utility

Description: Running the Autoscaling tool based on simulated ranges

aborts with an error
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".
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 16 Dec 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:

Incorrect code/compilable

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.
Workaround: No workaround available.
The problem is fixed by using the following patches or later
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

Last Update: 27 Jan 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:

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

Last Update: 27 Jan 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

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.
The problem is fixed by using the following patch or later
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

Last Update: 27 Jan 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

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.
The problem is fixed by using the following patch or later
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

Last Update: 13 Jan 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:

Aborted code generation

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.
The problem is fixed by using the following patch or later
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

Last Update: 13 Jan 2012

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
.\TLSim\<ModelName>\HostPC_<Compiler>\<ModelName>.dll
into the address space!
This error is issued although the affected file:
.\TLSim\<ModelName>\HostPC_<Compiler>\<ModelName>.dll
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.
The problem is fixed by using the following patches or later
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

Last Update: 04 Apr 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

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.3p2

581 / 1260

ID:

KPR.2012.02.07.002

Title:

Setting of TargetLink PreLook-up Index Search block is lost

Last Update: 08 Mar 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:

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

Last Update: 10 Feb 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

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.
The problem is fixed by using the following patches or later
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

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:

Inefficient code/code style

Description: The code generation time can increase considerably if a

TargetLink subsystem
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

Last Update: 10 Feb 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:

Incorrect code/not compilable

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

Last Update: 14 Jun 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:

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

Outport is fed by muxed signals

Last Update: 08 Mar 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:

Aborted code generation

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:
*** Number of source signals does not match the number of
output signals.
*** Please contact dSPACE technical support.
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

Last Update: 10 Feb 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:

Incorrect code/not compilable

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

Last Update: 14 Jun 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:

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
The problem is fixed by using the following patch or later
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

Last Update: 10 Feb 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:

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
...
/begin LOC_MEASUREMENT
ActualVector[0] /* identifier */
...
ActualVector[N] /* identifier */
/end LOC_MEASUREMENT
/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.
The problem is fixed by using the following patch or later
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

Last Update: 08 Mar 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:

Incorrect code/compilable

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
Workaround: No workaround available.

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

Last Update: 08 Mar 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:

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

Last Update: 04 Apr 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:

Inefficient code/code style

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)
Workaround: No workaround available.

596 / 1260

ID:

KPR.2012.02.28.001

Title:

Symbol Table Parser for LCC compiler does not find all static variables

Last Update: 30 Mar 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

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.
The problem is fixed by using the following patches or later patches:
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

Last Update: 30 Mar 2012

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:
Error #02287: <block path>:
No corresponding Simulink log variable could be found for the
signal connected
to '<block path>'.
Consult the online help for possible reasons and solutions.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.1p10

ID:

KPR.2012.03.06.004

Title:

Incorrect code generated for Access Function on matrix struct

component

Last Update: 30 Mar 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:

Incorrect code/compilable

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

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:

Incorrect code/compilable

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

Last Update: 08 Mar 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:

Aborted code generation

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:
Error #10014: The code generation process failed. Check the
error messages above
for further details.
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

Last Update: 30 Mar 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:

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

Last Update: 08 Mar 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

606 / 1260

Class:

Aborted code generation

Description: If a variable access function is specified for a variable that is

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');.
The problem is fixed by using the following patch or later
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

Last Update: 30 Mar 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:

Incorrect code/compilable

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.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.3p2

611 / 1260

ID:

KPR.2012.03.21.001

Title:

Data Dictionary validation falsely produces error message

#06581

Last Update: 30 Mar 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 04 Apr 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:

Incorrect code/compilable

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.
Workaround: No workaround available.
The problem is fixed by using the following patches or later
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

Last Update: 04 Apr 2012

Inefficient code/code style

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.3p3

617 / 1260

ID:

KPR.2012.05.07.001

Title:

Stateflow bitshift operation on scaled variables

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:

Incorrect code/compilable

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

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:

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.
*** ERROR:Index exceeds matrix dimensions.
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

Last Update: 16 Nov 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:

Incorrect code/compilable

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

Last Update: 27 Jul 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:

API

dSPACE's technical support team.
- For a TL Outport:
Fatal #10007:
Internal error. Error code: TlCSvModelReferenceDDReaderTools 1433. Contact
dSPACE's technical support team.
- For a Bus Inport
Fatal #10007:
Internal error. Error code:
Core\XcgIntermediateView\Sources\XcgIntermediateView\BlockContext\DataBlockConte
xt\TlCBcBusInportContext.cpp_ 627. Contact dSPACE's technical support team.
- For a Bus Outport
Fatal #10007:
Internal error. Error code: TlCBcBusOutportContext 630. Contact dSPACE's
technical support team.
---------------------------------Error Messages in TargetLink 3.2
---------------------------------- For a TL Inport:
Fatal #10007:
Internal error. Error code: TlCSvModelReferenceDDReaderTools 1381. Contact
dSPACE's technical support team.
- For a TL Outport:
Fatal #10007:
Internal error. Error code: TlCSvModelReferenceDDReaderTools 1463. Contact
dSPACE's technical support team.
- For a Bus Inport:
Fatal #10007:
Internal error. Error code:
Core\XcgIntermediateView\Sources\XcgIntermediateView\BlockContext\DataBlockConte
xt\TlCBcBusInportContext.cpp_ 627. Contact dSPACE's technical support team.
- For a Bus Outport:
Fatal #10007:
Internal error. Error code: TlCBcBusOutportContext 630. Contact dSPACE's
technical support team.
---------------------------------Error Messages in TargetLink 3.3
---------------------------------- For a TL Inport:
Fatal #10007:
Internal error. Error code: TlCSvModelReferenceDDReaderTools 1735. Contact
dSPACE's technical support team.
- For for a TL Outport:
Fatal #10007:
Internal error. Error code: TlCSvModelReferenceDDReaderTools 1839. Contact
dSPACE's technical support team.
- For Bus Inports / Bus Outports:
Fatal #10007:
Internal error. Error code: TlCSvModelReferenceDDReaderTools 2697. Contact
dSPACE's technical support team.
625 / 1260

Workaround: No workaround available.

ID:

KPR.2012.05.09.005

Title:

No re-enhancing of Data Type Conversion blocks

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:

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

Last Update: 06 Nov 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 30 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:

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

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:

Aborted code generation

Last Update: 30 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:

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

Last Update: 15 Jun 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 30 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:

Aborted code generation

Description: TargetLink eliminates intermediate variables of vector type

that are used only
in part after their assignments:
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
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

Last Update: 15 Mar 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:

Aborted code generation

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>);
The problem is fixed by using the following patch or later patches:
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

Last Update: 15 Jun 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

TargetLink 2.2 2.2.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.
The problem is fixed by using the following patch or later
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

Last Update: 15 Jun 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:

Incorrect code/compilable

ID:

KPR.2012.07.04.004

Title:

Stateflow temporal logic events may never be executed

Last Update: 07 Dec 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:

Incorrect code/compilable

Description: If the counter argument of a temporal logic event is given by a

TargetLink 2.2 2.2.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.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.3p4

ID:

KPR.2012.07.26.004

Title:

Code generation for Access Functions aborts with a fatal error

#99999

Last Update: 06 Nov 2012

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:

Aborted code generation

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
D:\TargetLink\tl_3_3\Matlab\Tl\Bin\XcgCV.dll
00000000390F28D7 0000000000C22C68
0001:00000000004818D7
D:\TargetLink\tl_3_3\Matlab\Tl\Bin\XcgCV.dll
[...]
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.
The problem is fixed by using the following patch or later
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

Last Update: 02 Aug 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:

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

Last Update: 02 Aug 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:

Incorrect code/compilable

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

Last Update: 06 Nov 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:

Aborted code generation

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

Last Update: 06 Nov 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:

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
generated production
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.
The problem is fixed by using the following patch or later
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

Last Update: 13 Sep 2012

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:

Incorrect code/compilable

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

Last Update: 12 Oct 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:

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
TargetLink 3.3\Matlab\Tl\Bin\XcgCVT.dll
000000003CA0964E 0000000000C253A0
0001:000000000004864E C:\Program Files\dSPACE
TargetLink 3.3\Matlab\Tl\Bin\XcgCVT.dll
000000003CF034DB 0000000000C254D4
0001:00000000005424DB C:\Program Files\dSPACE
TargetLink 3.3\Matlab\Tl\Bin\XcgCVT.dll
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.
Workaround: No workaround available.

670 / 1260

ID:

KPR.2012.08.08.003

Title:

Simulation mat file does not keep unit information

Last Update: 13 Sep 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

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.
Workaround: No workaround available.

ID:

KPR.2012.08.08.004

Title:

AUTOSAR 2.x/3.x import saturates upper limit of linear

CompuMethod to SINT32_MAX

Last Update: 06 Nov 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:

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 31 Aug 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:

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

Last Update: 31 Aug 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:

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

Last Update: 31 Aug 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

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

Last Update: 13 Sep 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

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.
Workaround: No workaround available.

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:

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".
The problem is fixed by using the following patch or later
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

Last Update: 06 Nov 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:

Aborted code generation

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.
The problem is fixed by using the following patch or later
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

Last Update: 13 Sep 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:

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

Last Update: 06 Nov 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:

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]).
The problem is fixed by using the following patch or later
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:

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

Last Update: 22 Nov 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:

Incorrect code/compilable

Description: Starting from TargetLink 3.3, TargetLink analyzes the data

flow relationships
between accesses of variables that are associated with an
AccessFunctionTemplate
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
AccessFunctionTemplate
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

Last Update: 28 Sep 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:

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

Last Update: 12 Oct 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

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

Last Update: 24 Jan 2014

TargetLink 2.2 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: 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_]);
}
...
for (Aux_S32 = 0; Aux_S32 < 12; Aux_S32++)
{
[Aux_S32] = (b[Aux_S32] > g(c[Aux_S32])) && (P[Aux_S32] >
0.);
}
becomes
...
for (Aux_S32 = 0; Aux_S32 < 12; Aux_S32++)
{
[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

Last Update: 12 Oct 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:

Incorrect code/compilable

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

Last Update: 06 Nov 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:

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'.
The problem is fixed by using the following patch or later patches:
TargetLink 3.4p1

693 / 1260

ID:

KPR.2012.10.31.001

Title:

Simulation build process for AUTOSAR aborts with internal

error E90112

Last Update: 06 Nov 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

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:
*** E90112: INTERNAL ERROR:
*** 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
The problem is fixed by using the following patch or later
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

Last Update: 06 Nov 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:

API

- 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.
SIMULINK ERROR MESSAGES:
--> 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.
The problem is fixed by using the following patches or later
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

Last Update: 23 Nov 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

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:
E08763: Error during AUTOSAR 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 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">
Example for AUTOSAR 2.1.4:
<AUTOSAR xsi:schemaLocation="http://autosar.org/2.1.4
autosar.xsd"
xmlns="http://autosar.org/2.1.4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
The file "dummy.armxl" must be the first file selected in the
import dialog.
The problem is fixed by using the following patches or later
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.

Last Update: 22 Nov 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:

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

Last Update: 16 Nov 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:

Incorrect code/compilable

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

Last Update: 23 Nov 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:

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.
The problem is fixed by using the following patches or later
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

Last Update: 14 Dec 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:

Incorrect code/compilable

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
Exception: ACCESS_VIOLATION
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

Last Update: 22 Nov 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:

Aborted code generation

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

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:

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><!--<SUP>1</SUP><SUB>1</SUB>-></DISPLAY-NAME>
The problem is fixed by using the following patches or later
patches:
TargetLink 3.3p5
TargetLink 3.4p2

704 / 1260

ID:

KPR.2012.11.20.002

Title:

Possible simulation differences due to incomplete function

ddv() in packed models

Last Update: 22 Nov 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:

Utility

from AUTOSAR menu crashes
for Data Dictionary files that contain DataTypeMappingSets
with invalid typedef
references. The same error occurs for directly execution of
dsdd_sync_autosar4.m
via API call. The resulting error message in Matlab command
window is:
??? Subscripted assignment dimension mismatch.
Error in ==> dsdd_sync_autosar4 at 113
mappingTable(m,3) = hDDType;
Error in ==> dsdd_call_autosar4_validation at 28
msgStructSync = dsdd_sync_autosar4('DDWorkspace', 0);
Workaround: Check references of all DataTypeMappingSet objects.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p1

ID:

KPR.2013.01.11.004

Title:

AUTOSAR 4.0.x export fails with internal error IE17 for C

module names having capital letters

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:

Utility

Description: If the name of a module (as a sub-node of /Pool/Modules in

the Data Dictionary)
contains capital letters, an error IE17 can be raised while
exporting it to
AUTOSAR 4.0.x.
Workaround: Rename the module object with command "Rename and
Adapt..." to the corresponding
lower-case text.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p1

709 / 1260

ID:

KPR.2013.01.11.005

Title:

If the generated code of a reused system is divided over

several modules an unspecific error message about cyclic
includes appear

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:

Modelling

Description: The default modules for the reuse structure types is the
module into which the
step function of the topmost reused subsystem/chart is
generated. If the reuse
system contains several subsystems/chart which are
generated into different
files, then the code generation may abort with an unspecific
error message about
cyclic includes because the other modules do need the root
reuse module for the
reuse structure type definitions.
Example:
Error #17066: Cyclic includes detected: a_module.h,
b_module.h
Error #10014: The code generation process failed. Check the
error messages above
for further details.
Workaround: Adjust the settings that the code of a reused system is
completly generated into
one file. This can be archieved by eliminating the module
settings at function
classes and function blocks inside the reused system or by
separating the reused
system into several reused systems (reuse in reuse).

710 / 1260

ID:

KPR.2013.01.14.001

RTE simulation frame file for the TargetLink 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: If a variable
- has a variable class with the Optimization property
MERGEABLE activated AND
- this variable is used in a customer-specific function or in a
custom look-up
function AND
- this variable is also specified in another TargetLink block
(like a Constant
block for example) AND
- this variable has a scaling that is defined in the Data
Dictionary,
then
"Warning #17443: <block1> Found mergeable variable
<variable> that is associated
with two different scalings. Possible loss of information.
Scaling1: <block1>,
Scaling2: <block2>."
might erroneously be emitted, although both scalings are
identical.
Workaround: No workaround available.

717 / 1260

ID:

KPR.2013.01.14.008

Title:

No error during code generation for merging of bus structs

with different scalings for components

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:

Incorrect code/compilable

Description: If a model contains at least two of the following blocks:

720 / 1260

ID:

KPR.2013.01.14.012

Title:

Property values entered as hexadecimals in the Data

Dictionary are truncated to [0, 2^31-1]

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: For numeric property values (for example, the Value property
of a Variable
object), the Data Dictionary Manager and its dialogs support
hexadecimal values
such as "0x10000". After having been entered by the user, the
value is then
converted to the corresponding integer. However, the integer
is then always
saturated to the range [0, 2^31-1], which may be incorrect.
For example:
0x7FFFFFFF -> 2147483647
0x80000000 -> 2147483647
0xFFFFFFFF -> 2147483647
Workaround: Enter decimals instead.

721 / 1260

ID:

KPR.2013.01.14.013

Title:

AUTOSAR import fails with internal error IE042 for SW-BASE-TYPE

without BASE-TYPE-SIZE

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:

Utility

Description: When a SW-BASE-TYPE without BASE-TYPE-SIZE is imported

from AUTOSAR (because
size seems to be clear e.g. for BOOLEAN or NONE), the import
might fail with an
error "IE042".
The problematic section SW-BASE-TYPEs of the imported file looks
like this:
<SW-BASE-TYPE>
<SHORTNAME>Encoding_BOOLEAN_NativeDeclaration_boolean</SHORTNAME>
<BASE-TYPE-ENCODING>BOOLEAN</BASE-TYPE-ENCODING>
<NATIVE-DECLARATION>boolean</NATIVE-DECLARATION>
</SW-BASE-TYPE>
<SW-BASE-TYPE>
<SHORTNAME>Encoding_NONE_NativeDeclaration_uint8</SHORTNAME>
<BASE-TYPE-ENCODING>NONE</BASE-TYPE-ENCODING>
<NATIVE-DECLARATION>uint8</NATIVE-DECLARATION>
</SW-BASE-TYPE>
Workaround: If possible add <BASE-TYPE-SIZE>8</BASE-TYPE-SIZE>
manually to the SW-BASE-TYPE
element.
Then it should look like:
<SW-BASE-TYPE>
<SHORTNAME>Encoding_BOOLEAN_NativeDeclaration_boolean</SHORTNAME>
<BASE-TYPE-SIZE>8</BASE-TYPE-SIZE>
<BASE-TYPE-ENCODING>BOOLEAN</BASE-TYPE-ENCODING>
<NATIVE-DECLARATION>boolean</NATIVE-DECLARATION>
</SW-BASE-TYPE>
<SW-BASE-TYPE>
<SHORTNAME>Encoding_NONE_NativeDeclaration_uint8</SHORTNAME>
<BASE-TYPE-SIZE>8</BASE-TYPE-SIZE>
<BASE-TYPE-ENCODING>NONE</BASE-TYPE-ENCODING>
<NATIVE-DECLARATION>uint8</NATIVE-DECLARATION>
</SW-BASE-TYPE>
The problem is fixed by using the following patch or later patches:
TargetLink 3.4p1

722 / 1260

ID:

KPR.2013.01.14.014

Title:

AUTOSAR code generation aborts with error #32013 if a state

chart references a Data Store Memory used as an
interrunnable variable

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:

Aborted code generation

Description: If a state chart has a data object with scope Data Store
Memory AND
- the corresponding Data Store Memory block references a
Data Dictionary
variable as Data Store Memory variable that is specified as an
AUTOSAR
interrunnable variable AND
- the State Chart is (directly or indirectly) placed inside a
subsystem that is
specified as a runnable
then the code generation in AUTOSAR mode fails with the
following message:
"Error #32013:
TL_Controller/Controller_Runnable/Chart1.IRV_pos:
The block references AUTOSAR interrunnable variable
Rte_Irv_Controller_LinPos as
a block variable. This is not permitted for this block."
Workaround: Delete the data object and connect Data Store Read/Write
blocks with the same
Data Store name to inputs/outputs of the state chart instead.

ID:

KPR.2013.01.14.016

Title:

TargetLink dialog for Stateflow data objects incorrectly

displays an arbitrary LSB rounded to power-of-two value

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: The TargetLink dialog for Stateflow data objects incorrectly

displays an
arbitrary LSB rounded to power-of-two value, if the TargetLink
data contains an
arbitrary LSB value without the sf.arb flag set to true.
Workaround: For arbitrary LSB values also set sf.arb = 1 in the TargetLink
data of the
Stateflow data object.

723 / 1260

ID:

KPR.2013.01.14.017

Title:

Compiling SIL/PIL fails due to undefined logging macros for

Merge blocks if 'do not log anything' has been selected

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:

Simulation

Description: If for a Merge block logging is enabled AND

ID:

KPR.2013.01.14.022

Title:

Code generation for Stateflow aborts with fatal error #99003

for 64 bit integer operations in floating-point context

Last Update: 22 Feb 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:

Aborted code generation

Description: If in Stateflow an expression is specified,

- that contains an operation with only integer operands and
whose result range
does not fit 32 bit AND
- that operation is an operand of an operation containing at
least one
floating-point operand AND
- at least one of the operands of the whole statement has a
different TargetLink
than Stateflow data type AND
- none of the operands of the whole statement has an LSB !=
1.0 and/or an Offset
!= 0.0,
then the code generation might abort issuing an error like the
following:
Fatal #99003: <chart> Internal error, error code 99003. Please
contact dSPACE
technical support.
Example:
Float64 outF64; // TargetLink data type = Float64; Stateflow
data type =
double
Float64 inF64; // TargetLink data type = Float64; Stateflow
data type = double
Int32 in1I32; // TargetLink data type = Int32; Stateflow data
type = double
Int32 in2I32; // TargetLink data type = Int32; Stateflow data
type = double
outF64 = inF64 + (in1I32 - in2I32);
Since the worst case range of the subtraction of two Int32
variables cannot be
represented using 32 bit, TargetLink will choose Int64 as
result type for the
subtraction. The following addition will be calculated using
Float64, because
one of the operands is already Float64. Since TargetLink can
currently not
convert a 64 bit intermediate result to floating-point, a fatal
#99003 is
emitted.

728 / 1260

Workaround: (1) Introduce an auxiliary variable for the 64 bit intermediate

integer result.
This way the data type and scaling are specified for the
intermediate result
explicitly and TargetLink does not need to calculate them
internally.
or
(2) Set the TargetLink code generator option
"HandleUnscaledStateflowExpressionsWithTlType" to "off"
(default is "on").
Note: In this case TargetLink will not handle unscaled
Stateflow expressions at
all, which might increase the risk of overflows. Please see the
manual for more
information regarding this option.

ID:

KPR.2013.01.14.024

Title:

Linker error due to identically generated names for global

actual parameters of RTE API functions in different code
generation units

Last Update: 22 Feb 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:

Modelling

729 / 1260

Description: TargetLink generates a call of an RTE API function for an

inport with AUTOSAR
communication. Then for the function call TargetLink uses an
actual parameter
whose default name is the name of the specified data
element/operation
argument/mode element plus a suffix that is generated by the
standard rules for
name macro '$R'.
Depending on the model, TargetLink may further generate the
actual parameter
variable with global scope:
a) the inport drives an inport of an atomic subsystem that is
not enhanced
OR
b) the inport drives an enhanced inport of a function-call
triggered subsystem
that is implemented as a function parameter.
In such a situation the default actual parameter names are
unique in their
current code generation unit, but its possible that these actual
parameter names
are not unique amongst several code generation units.
This could lead to errors when compiling/linking code for all
code generation
units together, e.g. for SIL/PIL simulation or when building the
ECU
application. The exact behavior depends on the compiler.
Possible errors are:
- Linker failure caused by these multiple-defined variables
- Simulation differences
- Incorrect behavior when running the code on an ECU
Workaround: Depending on the modelling that leads to the actual
parameter's global scope:
a) If the port with AUTOSAR communication drives a notenhanced inport, then
enhance the inport, and ensure that the inport is implemented
as a global
variable, e.g. by using a variable class like NOPT_GLOBAL.
b) If the port with AUTOSAR communication drives an
enhanced inport of a
function-call triggered subsystem that is implemented as
function parameter:
Specify the following properties for the inport of the functioncall
triggered subsystem:
- a variable class with the 'ArgClass' property set
- a unique name for the actual parameter by using the colon
separator ':',
e.g. a name with added $N name macro (see the TargetLink
manual for more on
"Configuring Names")

730 / 1260

ID:

KPR.2013.01.16.001

Title:

Code generation aborts for extern function subsystems

containing User Look-Up Tables

Last Update: 22 Nov 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:

Aborted code generation

Description: For a subsystem which contains a User Look-Up Table block

(LUT with user script)
on top level AND
which also contains a function block that specifies an extern
step function
class, the code generation may abort with an exception and
stack trace like the
following:
Exception: ACCESS_VIOLATION
Fault address: 3F8DE6B4 01:000FD6B4
Matlab\Tl\Bin\XcgDDOt.dll
Call stack:
Address Frame
000000003F8DE6B4 0000000000929790
0001:00000000000FD6B4
D:\dSPACE\TL\TL_Xcg\Matlab\Tl\Bin\XcgDDOt.dll
Workaround: 1) Place an additional virtual subsystem frame around the
LUT block.
Or 2) detect the case of running in a extern function
subsystem in and then
early return from the user LUT script.
The problem is fixed by using the following patches or later
patches:
TargetLink 3.3p6
TargetLink 3.4p3

731 / 1260

ID:

KPR.2013.01.16.002

Title:

Linker errors for SIL/PIL when using EXTERN_MACRO class

for root interface variables

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:

Simulation

Description: When using EXTERN_MACRO class for root interface

variables, i.e. for variables
passing the TargetLink subsystem boundaries, possibly
together with a user file
where these variables are defined, the linking of the SIL/PIL
simulation
application may fail due to missing declarations of these
variables in the
Simulation Frame File.
Workaround: Use a Variable Class EXTERN_GLOBAL_ALIAS instead of
EXTERN_MACRO.

ID:

KPR.2013.01.24.001

Title:

Incorrect AUTOSAR 2.x/3.x import of Scaling LinearMin and

LinearMax values

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:

Utility

732 / 1260

Description: A Scaling is imported incorrectly, if a AUTOSAR 2.x/3.x ARXML file

contains a
<COMPU-SCALES> element with multiple <COMPU-SCALE> child
elements and at least
one them does not define <LOWER-LIMIT> / <UPPER-LIMIT> and
is not the first
child.
In this case the <LOWER-LIMIT> / <UPPER-LIMIT> values are
incorrectly taken from
the last ancestor <COMPU-SCALE> element, which has defined the
limit values.
Example:
<COMPU-METHOD>
<SHORT-NAME>CM_MO_Drehzahl_01</SHORT-NAME>
<CATEGORY>SCALE_LINEAR_AND_TEXTTABLE</CATEGORY>
<DISPLAY-FORMAT>%g</DISPLAY-FORMAT>
<UNIT-REF DEST="UNIT">/teste/meter</UNIT-REF>
<COMPU-INTERNAL-TO-PHYS>
<COMPU-SCALES>
<COMPU-SCALE>
<DESC>
<L-2>Fehler</L-2>
</DESC>
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">65535</LOWERLIMIT>
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">65535</UPPERLIMIT>
<COMPU-CONST>
<VT>CxFFFF</VT>
</COMPU-CONST>
</COMPU-SCALE>
<COMPU-SCALE>
<COMPU-RATIONAL-COEFFS>
<COMPU-NUMERATOR>
<V>0</V>
<V>1</V>
</COMPU-NUMERATOR>
<COMPU-DENOMINATOR>
<V>4</V>
</COMPU-DENOMINATOR>
</COMPU-RATIONAL-COEFFS>
</COMPU-SCALE>
</COMPU-SCALES>
</COMPU-INTERNAL-TO-PHYS>
</COMPU-METHOD>
The first <COMPU-SCALE> defines an enum [CxFFFF: 65535]. The
second
<COMPU-SCALE> defines the scaling, the correct Min/Max values
for the scaling
must be defined here.
As the Min/Max values are not defined, the import incorrectly takes
the Min/Max
values from the first <COMPU-SCALE>.

733 / 1260

Workaround: If possible specify or add add the LOWER/UPPER Limits for the
scaling in the
arxml file before import. E.g. in the example:
<COMPU-METHOD>
<SHORT-NAME>CM_MO_Drehzahl_01</SHORT-NAME>
<CATEGORY>SCALE_LINEAR_AND_TEXTTABLE</CATEGORY>
<DISPLAY-FORMAT>%g</DISPLAY-FORMAT>
<UNIT-REF DEST="UNIT">/teste/meter</UNIT-REF>
<COMPU-INTERNAL-TO-PHYS>
<COMPU-SCALES>
<COMPU-SCALE>
<DESC>
<L-2>Fehler</L-2>
</DESC>
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">65535</LOWERLIMIT>
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">65535</UPPERLIMIT>
<COMPU-CONST>
<VT>CxFFFF</VT>
</COMPU-CONST>
</COMPU-SCALE>
<COMPU-SCALE>
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">0</LOWER-LIMIT>
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">65534</UPPERLIMIT>
<COMPU-RATIONAL-COEFFS>
<COMPU-NUMERATOR>
<V>0</V>
<V>1</V>
</COMPU-NUMERATOR>
<COMPU-DENOMINATOR>
<V>4</V>
</COMPU-DENOMINATOR>
</COMPU-RATIONAL-COEFFS>
</COMPU-SCALE>
</COMPU-SCALES>
</COMPU-INTERNAL-TO-PHYS>
</COMPU-METHOD>
The problem is fixed by using the following patch or later patches:
TargetLink 3.4p1

734 / 1260

ID:

KPR.2013.01.24.002

Title:

Simulink error "comma separated list must have exactly one

item" appears during MIL simulation

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:

Simulation

Description: After starting a MIL simulation, the following Simulink error

appears and the
simulation is not run:
"Error evaluating 'StartFcn' callback of block_diagram
<modelname>." and
"comma separated list must have exactly one item."
This problem may occur if all of the following conditions are
fulfilled:
- A Data Dictionary with an Application object and a
Subsystem object specific
to the current model is open AND
- the Data Dictionary Application object contains LogVariable
objects with
references to non existing BlockVariable objects AND
- blocks with several signals (e.g. Bus Port blocks, Custom
Code blocks) are
specified to be logged via Data Dictionary LogVariable objects
AND
- a MIL simulation is performed (SIL and PIL simulations are
not affected).
Workaround: The problem appears only if the Data Dictionary contains
LogVariable objects
with invalid BlockVariable references.
Perform one of the following methods to remove these
inconsistent LogVariable
objects:
- Perform "Build SIL" or "Build PIL" for the current model LogVariable objects
as well as associated Subsystem objects are recreated during
build process.
- Delete all Subsystem and Application objects from the Data
Dictionary. In this
case, only the MIL simulation is available.

735 / 1260

ID:

KPR.2013.01.24.003

Title:

Simulation frame generation aborts with internal error for

externally triggered AUTOSAR Runnables

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:

Simulation

Description: If a TargetLink subsystem contains an externally triggered

AUTOSAR Runnable
subsystem (i.e. which is called from outside the TargetLink
Subsystem), the
simulation frame generation may fail with the following error
message:
"Actual function's argument to be used instead of formal
function's argument
<MyArg> could not be obtained."
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p1

ID:

KPR.2013.01.25.001

Title:

Definition of a server runnable with operation return value is

missing in the generated production code

Last Update: 24 May 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:

Incorrect code/not compilable

Simulation

Description: If
- a Bus Outport of the TargetLink subsystem is not enhanced
AND
- it is driven by an enhanced Bus Outport block (directly or
indirectly via
further not-enhanced bus outports) AND
- the bus contains two succeeding signals whose widths fulfill
the following
inequation: "[1st signal width] > [2nd signal width] + 1 > 1"
AND furthermore, the two signals are specified with one of the
following
settings depending on the enhanced Bus Outport block's
configuration:
1) the block is specified with AUTOSAR sender-receiver
communication and the
data elements to the signals are referencing types with the
same base type.
OR
2) the block is specified with AUTOSAR client-server
communication and the
operation arguments to the signals are components of the
same operation argument
of struct type AND the operation arguments to the signals are
referencing types
with the same base type.
OR
3) the block is not specified with any AUTOSAR
communication at all and the
signals are specified as components of the same bus struct
AND the signals are
referencing types with the same base type.
Then in such a situation building of the SIL or PIL simulation
fails with the
following error message:
Generating simulation frame files ... *** E90108: INTERNAL
ERROR:
*** Internal error. Contact dSPACE technical support.
*** The value of the Element property cannot be greater than
the vector width.
Workaround: Enhance the TargetLink subsystem's bus outport block.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.3p5

741 / 1260

ID:

KPR.2013.02.18.001

Title:

Incorrect code generated for rescheduling of state updates for

outputs of reused functions

Last Update: 14 Mar 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:

Incorrect code/compilable

Description: If the code generator option "ExtendedLifeTimeOptimization"

is activated AND a
function reuse structure has substructures and a struct
component of one of
these substructures is accessed in a state update statement
executed after the
call to the reused function, then it is possible, that TargetLink's
optimization
incorrectly moves the statement to a location prior to the
function call in the
generated code.
Example:
A function from a library block is subject to function reuse.
One of its outputs is reused and drives a Unit Delay or Data
Store Write block.
Without optimization, we arrive at
<reuse substruct type> ISV0 ...;
<reuse struct type> tag_ISV = {
&ISV0,
...
};
...
foo(&tag_ISV);
...
MyOut = ISV0.Output;
Optimization may incorrectly invert this order to
MyOut = ISV0.Output;
...
foo(&tag_ISV0);
Workaround: Deactivate the code generator option
"ExtendedLifeTimeOptimization".

742 / 1260

ID:

KPR.2013.02.18.002

Title:

Duplicated signal path entries in error message E15278

Last Update: 14 Mar 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 a bus passes an enhanced TargetLink InPort or OutPort

block and for one or
more leaf elements of the bus in the TargetLink block dialog of
the block a
width is specified which does not fit to the width of the signal
in Simulink,
TargetLink emits an error E15278. This is correct. The error
message contains
the signal pathes to the leaf elements of the bus the error has
been detected
for. But if the error has been detected for more than one leaf
element in the
bus, the signal pathes for the second, third, forth, ?, leaf
element of the bus
contain duplicated entries. This is not correct.
Example:
Error #15278: Bus Outport:
The output widths of the following bus signals specified in the
block dialog do
not match the actual widths in the busses:
- bus signal 1 (//a_sig), Width 1 is expected
- bus signal 2 (//a_sig//b_sig), Width 1 is expected
- bus signal 3 (//a_sig//b_sig//c_sig), Width 1 is expected
Correct would be:
- bus signal 2 (//b_sig), Width 1 is expected
- bus signal 3 (//c_sig), Width 1 is expected
Workaround: No workaround available.
The problem is fixed by using the following patches or later
patches:
TargetLink 3.3p5
TargetLink 3.4p2

743 / 1260

ID:

KPR.2013.02.19.001

Title:

Aborted code generation or incorrect code if a Stateflow data

with initial value method "Parameter" was changed in its
Stateflow scope

Last Update: 14 Mar 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:

Incorrect code/compilable

Description: If TargetLink runs on MATLAB/Stateflow >= R2010a AND

- a Stateflow data with Stateflow scope "Output", "Local" or
"Temporary" has as
initial value method "Parameter" selected AND
- this data's Stateflow scope is changed later to a scope not
having an initial
value method "Parameter",
then one of the following errors can appear
1) If the scope is changed to Stateflow "Input" a fatal error
#99999 for an
access violation appears during code generation:
Exception: ACCESS_VIOLATION
Fault address: 3A01EFD8 01:0003DFD8 C:\Program Files
(x86)\dSPACE TargetLink
3.4\exe\CmnDsLd62Mt40U.dll
...
2) If the scope is changed to Stateflow "Constant" the
TargetLink code generator
may generate that variable with a wrong initial value.
Workaround: Change the scope of the Stateflow data to "Local", select as
initial value
method "expression" and then change back the scope back to
the value before.

744 / 1260

ID:

KPR.2013.03.05.001

Title:

tl_set() fails for Custom Code blocks having more than one
parameter or state

Last Update: 14 Mar 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:

API

Description: If a Custom Code block has more than one parameter or more
than one state, then
the parameter/state properties cannot be changed using
TargetLink API. An
attempt results in stack trace in MATLAB command window
like the following:
??? Comma separated list must have exactly one item.
Error in ==> tl_ddv_sync at 27
elseif data.(varName).useddvariablevalue
Error in ==> tl_customcode_api at 126
data = tl_ddv_sync(data, props{1}, props{end},
propertyValue);
Error in ==> tl_set>FcnTLSet at 485
[data, errorflag, msg] = fhBlockApiFcn('dynamicSync', data,
extData, d, pn,
PropertyValue);
Error in ==> tl_set at 193
[errorflag(m),msg{m}] = ...
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.3p5

745 / 1260

ID:

KPR.2013.03.06.001

Title:

System Checker incorrectly detects EML functions and thus

aborts with error E03153

Last Update: 14 Mar 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:

Utility

Description: The System Checker is automatically executed when a

system should be prepared
for TargetLink and also before code generation starts. It
reports Simulink
blocks, Stateflow objects and parameters which are not
supported by TargetLink,
as for example Embedded MATLAB Functions (EML
Functions).
However, in the following use case:
- the system contains at least two instances of a Stateflow
Chart block which
originate from a Simulink library AND
- this Chart contains a SF Function
the System Checker erroneously reports that the system
contains an EML function
and thus aborts with error #03153, which makes system
preparation and code
generation unfeasible.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p2

746 / 1260

ID:

KPR.2013.03.12.001

Title:

AUTOSAR production code is not compilable with RTE code

because of a missing header file *_ARfrm.h

Last Update: 31 Jul 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:

Incorrect code/not compilable

Description: If in the Data Dictionary an AUTOSAR Software Component is

specified with two
Runnables AND
- one Runnable is specified with kind "StepFunction" AND
- the other one with kind "RestartFunction" AND
- a nested subsystem in the TargetLink subsystem is specified
as the
"StepFunction" runnable AND
- it contains (directly or indirectly) another subsystem that is
specified as an
Operation Call AND
- the Operation Call subsystem is not specified as a Runnable,
but TargetLink
generates an implementation for the Operation Call for
SIL/PIL simulation only
AND
- one of the variables inside the Operation Call system has a
variable class
with property "RestartFunctionName" = "default" (please note,
that this class
might be taken because a VariableClass template is
respecified in the Data
Dictionary)
Then in this case, the generated AUTOSAR production code
might incorrectly
contain an include directive of a TargetLink internal file that is
generated for
simulation purposes only. The file is called "$N_ARfrm.h/.c"
and is generated in
the TLSim directory only.
As a result, SIL/PIL simulation is possible in TargetLink, but
for the ECU the
generated AUTOSAR code is not compilable with code
generated by an RTE generator
(because of the missing file).
Workaround: 1) Delete the "RestartFunctionName" in the variable's variable
class.
Or 2) specify a "RestartFunctionName" that is different from
"default".
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p3

ID:

KPR.2013.03.12.002

747 / 1260

Title:

Compilation of the generated code fails because of missing

definitions of AUTOSAR RTE API functions called in restart
runnables

Last Update: 22 Mar 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:

Incorrect code/not compilable

Description: If
- in the Data Dictionary an AUTOSAR Software Component is
specified with a
Runnable of kind "StepFunction" and another Runnable of
kind "RestartFunction"
AND
- the "StepFunction" Runnable is modeled as a subsystem in a
TargetLink model
AND
- this runnable calls one of the following RTE API functions
that are modeled in
TargetLink by Data Dictionary variable objects:
* Rte_Pim
* Rte_Calprm
* Rte_Prm
* Rte_CData
* Rte_IrvRead
* Rte_IrvWrite
* Rte_IrvIRead
* Rte_IrvIWrite
- AND the DD variable's (pre-defined) variable class has been
modified by
setting the property "RestartFunctionName" to "default",
then TargetLink generates the Runnable of kind
"RestartFunction" that is calling
the modeled RTE API function, but it does not create any
AUTOSAR access point
for this call. This might lead to the following problems:
1) An exported ARXML file does not contain the access point.
So an AUTOSAR
architecture tool (like SystemDesk) does not generate a
definition of the called
RTE API function. This leads to errors when trying to
compilate TargetLink's
AUTOSAR code with RTE code generated by an AUTOSAR
architekture tool.
2) Since TargetLink 3.4 building SIL/PIL might fail as well. The
make process
aborts complaining that the RTE API function definition could
not be found.

748 / 1260

Workaround: Do not generate the "RestartFunction" runnable by

TargetLink's restart function
mechanism. Generate the runnable by modeling a Runnable
subsystem instead. This
means:
1. Switch the "kind" property of the DD runnable object from
"RestartFunction"
to "StepFunction".
2. Add a new subsystem to the model, and specify this
subsystem as the
Runnable.
3. Model the initializations that should be done by the
runnable manually by
using TargetLink blocks. In particular the Data Dictionary
variable objects that
result in RTE API function calls should be referenced in a
Runnable subsystem.

ID:

KPR.2013.03.12.003

Title:

Building SIL aborts with a compiler error for Min/Max values

for Float32/64 in TargetConfig.xml that are too big

Last Update: 17 Apr 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:

TargetLink 2.2 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: If a Stateflow graphical function is modelled as scaling

invariant and the
output of that function is also flagged as invariant, wrong
generated code may
appear in one of the following situations:
1) if one of the input arguments is not a simple stateflow data
but an
expression - example: u = f( x+y );
2) if the function is not used in an assignment - for example as
transition
condition: [ f( x+y ) > 5 ]
3) if the function is used in an assignment and right-hand side
is a complex
expression. Example: u = y + f( x );
4) if the function is used directly in an assignment where the
Stateflow data on
the left-hand side has a different scaling than the result of the
scaling
invariant script
In these situations the incorrect code may either be wrongly
optimized (in case
of situation 1) or can contain wrong rescaling code (situations
2 to 4).
Workaround: Use scaling invariant graphical function only in simple
assignments:
u = f(y);
And ensure that the scaling of the left-hand side (data "u") is
identical to
results of the scaling invariant script.

ID:

KPR.2013.03.12.007

Title:

Incorrect generated code with erroneous replacement of a

vector function argument

Last Update: 05 Sep 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:

Incorrect code/compilable

753 / 1260

Description: TargetLink eliminates vector arguments of functions, if the

argument is a copy
of a previously defined vector (for input arguments) or a copy
of a subsequently
used vector (for output arguments). If the other vector has
greater width than
the argument, then this optimization must not be performed.
For input arguments, this optimization can erroneously take
place if
- the argument width is greater than or equal to the value of
the code generator
option LoopUnrollThreshold AND
- the right hand side of the copy assignment either
+ has an offset in its index OR
+ consists solely of a variable access to a scalar variable or to
a vector
element (not depending on the loop variable).
Examples:
1) A block output of width 6 drives a Demux block. The first
signal is routed
somewhere different, the other 5 elements are passed to a
function:
for (Aux_S32 = 0; Aux_S32 < 5; Aux_S32++) {
Sa2_In1[Aux_S32] = MyBlock[Aux_S32 + 1];
}
f(Sa2_In1);
After the erroneous optimization, the generated code looks
like
f(MyBlock);
2) A scalar block output drives all 5 inputs of a Mux block
which in turn drives
a function input:
for (Aux_S32 = 0; Aux_S32 < 5; Aux_S32++) {
Sa2_In1[Aux_S32] = MyVar;
}
f(Sa2_In1);
After the erroneous optimization, the generated code looks
like
f(MyVar);

754 / 1260

Workaround: 1) In situations like the example, place a Rescaler block with

"Inherit
properties" activated on the signal line driving the function
input. Set a
variable class without the ERASABLE Optimization property
for the block's output
variable. Or in another way specify a variable "inbetween" with
such a variable
class.
Or 2) Set the "LoopUnrollThreshold" code generator option to
"inf" or the
"EfficientVectorHandling" option to "off".
Or 3) Deactivate the "Optimization" code generator option.

ID:

KPR.2013.03.12.008

Title:

Incorect generated code with erroneous code pattern for

elimination of vector element accesses based on index
vectors

Last Update: 22 Mar 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:

Incorrect code/compilable

755 / 1260

Description: TargetLink eliminates intermediate variables. This usually

means that the
right-hand side of an assignment to a variable is used instead
of the variable.
For example:
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
b[Aux_S32] = a[Aux_S32];
}
f(b);
c = b[index];
for (Aux_S32_a = 0; Aux_S32_a < 10; Aux_S32_a++) {
d[Aux_S32_a] = b[Aux_S32_a] * 5;
}
If "b" is eliminated, this becomes:
f(a);
c = a[index];
for (Aux_S32_a = 0; Aux_S32_a < 10; Aux_S32_a++) {
d[Aux_S32_a] = a[Aux_S32_a] * 5;
}
If the right hand side is based on an index vector, then
TargetLink erroneously
omits this index vector in some cases when replacing
"b[index]" expressions,
i.e.
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
b[Aux_S32] = a[Permutation[Aux_S32]];
}
c = b[index];
incorrectly becomes
c = a[index];
instead of
c = a[Permutation[index]];
A typical situation for this problem to occur is a selector block
SV with vector
output driving a selector block S with scalar output that is
located inside a
For Iterator system and depending on the iteration variable.
Note that SV can be
located inside or outsided the For Iterator system.
If the width of the output of SV is greater than or equal to the
value of the
"LoopUnrollThreshold" code generator option, then this error
may occur.

756 / 1260

Workaround: 1) In a situation as above, place a TargetLink Rescaler block

behind the output
of the Selector block SV. For its output variable, select a
variable class with
scope=global, Storage=static, Optimization.ERASABLE=OFF,
Optimization.SCOPE_REDUCIBLE=ON.
Or 2) Set the "LoopUnrollThreshold" code generator option to
"inf" or the
"EfficientVectorHandling" option to "off".
Or 3) Deactivate the "Optimization" code generator option.

757 / 1260

ID:

KPR.2013.03.14.001

Title:

Incorrect generated code with erroneous rescheduling of state

updates of vectors involving global variables

Last Update: 22 Mar 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:

Incorrect code/compilable

SoftwareComponent that request
the same ModeElement via the same ModeReceiverPort can
erroneously lead to the
multiple definition of the corresponding Rte_Mode... function
in the RTE
simulation frame (in the Rte_<SWC>.c file). The causes a
compiler error during
the "Build SIL/PIL" process. The same holds for
ModeSenderPorts and the
Rte_Switch function.
Example:
You have modeled a single ModeReceiverPort in the Data
Dictionary and two
runnables belonging to the same AUTOSAR
SoftwareComponent. In the TargetLink
model, the two runnable subsystems each have an InPort,
with both InPorts
referencing the same ModeReceiverPort and the same
ModeElement in the Data
Dictionary. Then a "Build SIL" fails due to the multiple
definition of the
Rte_Mode_<SWC>_<ModeReceiverPort>_<ModeElement>
function in the RTE simulation
frame file Rte_<SWC>.c.
Workaround: In the Data Dictionary subsystem area, remove all
ModeAccessPoints
(ModeSwitchPoints) for the same SoftwareComponent leading
to the same Rte_Mode
(Rte_Switch) API call except for one. This step has to be be
performed after the
production code generation and before the compilation, e.g.
using a
post_codegen_hook function. However, this can lead to other
side effects, e.g.
for the AUTOSAR export. Thus code should be generated
again before export to
update the subsystem area again.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p2

763 / 1260

ID:

KPR.2013.04.12.004

Title:

Code generation aborts with error #17299 for an incremental

runnable using a restart function

Last Update: 18 Jul 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:

Aborted code generation

Description: If a TargetLink subsystem contains an incremental subsystem

that represents an
AUTOSAR runnable and if that runnable requires restart code,
code generation
usually aborts with error #17299.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p3

764 / 1260

ID:

KPR.2013.04.15.001

Title:

Wrong logging in SIL/PIL simulation for AUTOSAR ports for a

runnable at TargetLink subsystem root level

Last Update: 29 May 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:

Simulation

Description: If all of the following conditions apply:

1) An AUTOSAR Runnable is modeled at the root level of the
TargetLink subsystem
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: - Create an additional subsystem inside the TL subsystem and
model the runnable
inside this
- and place a Function block at the root level of the TL
subsystem and specify
there a different module as the module into which the
runnable code is to be
generated, for example "dummy_code".
Note: The runnable production code remains unchanged in
this case, the module
"dummy_code" is used only for the SIL/PIL simulation.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p1

ID:

KPR.2013.04.17.001

Title:

Wrong min/max values used for auxiliary interface variable

created for bus structures

Last Update: 19 Apr 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

765 / 1260

Class:

Incorrect code/compilable

Description: For unspecified Simulink Inport/Outport blocks of inner

subsystems TargetLink
implicitly creates auxiliary interface variables if necessary (e.g.
for enabled
subsystems).
If
- TargetLink introduces such an auxiliary interface variable
(name = IF_....)
for a BusPort block AND
- a bundle of consecutive components of the bus structure
have the same base
data type AND
- the first component of that bundle has a constrained data
type with min/max
values,
then TargetLink might create this IF variable as an array
whose elements
represent the components of the bundle and
in which all elements incorrectly will obtain the min/max
constrains from the
first component of the bundle instead of their own min/max.
This can cause confusing error messages about the ranges
and it may even cause
incorrect code being generated.
Note: In TargetLink 2.3x and 3.x the code generator further
aborts with an
access violation:
Fatal #99999: An exception occurred during code generation.
Contact dSPACE
technical support.
Example 1:
Might the bus structure consist of the following bundle of
consecutive
components:
Component 1: Type = UInt8, LSB = 0.01, Offset = 0, Min = 0,
Max = 1.27
Component 2: Type = UInt8, LSB = 3, Offset = 0, Min = 0, Max
= 93
Component 3: Type = UInt8, LSB = 2^2, Offset = 12, Min = 12,
Max = 136
Due to the LSB and offset of the component 3 the element 3
of the auxiliary
interface variable has the implemented range [12 .. 756].
Because the lower
limit of the implemented range is outside the lower limit of the
wrongly used
constrained range [0 ? 1.27], TargetLink issues the following
warning:
"Warning #17251: <object>: For the variable <variable name>
<element> an
upper/lower constrained limit was found that is outside the
implemented range.
766 / 1260

The implemented limit is being used instead."

and then uses the lower limit of the implemented range as
lower limit of the
constrained range. This leads to the new constrained range
[12 ... 1.27] But
now the lower limit of the constrained range is greater than the
upper limit,
which in turn leads to the error message
"Error #17252: <block> Lower limit of constrained range is
greater than upper
limit (signal, <n> of identifier <name>)".
Example 2:
Might the bus structure consist of the following bundle of
consecutive
components:
Component 1: Type = UInt8, LSB = 1, Offset = 0, Min = 1, Max
=3
Component 2: Type = UInt8, LSB = 1, Offset = 0, Min = 0, Max
=3
The element 2 of the auxiliary interface variable is the input If
Block with the
If expression u1 > 0. Because for the element 2 of the
auxiliary interface
variable the constrained range [1 ? 3] is wrongly used,
TargetLink determines
that the If expression is always true. This leads to wrong code
optimizations.
Workaround: Avoid generation of the implicit IF variable by specifying the
interface of the
subsystem explicitly by means of a TargetLink BusPort block
in TargetLink 2.x or
by enhancing the unspecified Simulink Port block to a Bus
Port block in
TargetLink 3.x.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p3

767 / 1260

ID:

KPR.2013.04.17.004

Title:

Erroneous cast to floating point type in boolean operation in

the generated code for Stateflow

Last Update: 23 Aug 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:

Inefficient code/code style

Description: An erroneous floating point cast might be introduced in the

generated production
code for Stateflow, if
- in Stateflow a condition is comprised of more than one
boolean (i.e. logical
or relational) operation AND
- the condition contains at least one operand that has a
different TargetLink
than Stateflow data type AND
- the condition does not contain an operand that has an LSB
!= 1.0 or an Offset
!= 0.0 AND
- a suboperation of the condition has only operands that have
the same
TargetLink as Stateflow data type AND
- one of the operands of that suboperation is has a TargetLink
floating point
data type.
Example:
Float64 in; // Stateflow Type = double
Int16 Var1; // Stateflow Type = double
Float32 Var2; // Stateflow Type = single
Float32 Var3; // Stateflow Type = single
if((in < Var1) || (Var2 > Var3))
resulting generated code:
if(((Float32) (in < Var1)) || (Var2 > Var3))
Workaround: 1) Use the same TargetLink as Stateflow data type for all
operands.
Or 2) Introduce local variables to hold the result of
suboperations that have
only operands that have the same TargetLink as Stateflow
data type.

768 / 1260

ID:

KPR.2013.04.17.005

Title:

Erroneous order of parameters in the generated code for a

customer-specific function

Last Update: 23 Aug 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:

Incorrect code/compilable

Description: In the generated production code the order of the parameters

of the call of a
customer-specific function might be wrong if
- a customer-specific function is called from a Stateflow chart
AND
- additionally in the same model a subsystem with a
TargetLink Function block
exists, that specifies the same function name.
Workaround: Do not use the same name for customer-specific functions
called from Stateflow
and for functions created for subsystems with Function blocks.

ID:

KPR.2013.04.17.006

Title:

Different MIL and PIL simulation results on TriCore for a

TargetLink subsystem with struct interface

Last Update: 07 Jun 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:

Simulation

Description: If a structure is an in- or output of a TargetLink root subsystem

and contains
UInt8 or Int8 arrays, then the TargetLink PIL simulation
calculates incorrect
struct member addresses, which leads to different simulation
results between MIL
and PIL on TriCore boards with the Tasking Compiler version
3.x and 4.x.
Example:
struct tag {
UInt32 A; // ok
UInt8 B[9]; // ok
UInt8 C[9]; // not ok
UInt32 D; // not ok and all following members are also not ok
};
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.3p7

769 / 1260

ID:

KPR.2013.04.17.007

Title:

Code generation incorrectly aborts with error message

#15563 or #31670 if Constant blocks have sample time 'Inf'

Last Update: 25 Oct 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:

Aborted code generation

Description: If an atomic subsystem S1 contains another atomic

subsystem S2 and Constant
blocks which all have a compiled sample time of 'Inf', then the
code generation
may incorrectly abort with the error message #15563 (if code
generation mode is
Standard or AUTOSAR) or #31670 (if code generation mode
is RTOS).
Error #15563: <S2>:
The sample time i (offset o) of the encapsulated system <S2>
is not equal to or
an integral multiple of the surrounding system's <S1> sample
time -1 (offset 0).
This is not supported in the Standard and AUTOSAR code
generation modes.
Error #31670: <S1>:
The subsystem is identified as a cyclic subsystem but a valid
sample time for
the subsystem could not be found.
Workaround: Specify inherited or discrete sample time for the Constant
blocks.

ID:

KPR.2013.04.17.008

Title:

Possibly incorrect code generated for Assignment block with

inherit properties

Last Update: 02 Dec 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:

Incorrect code/compilable

770 / 1260

Description: If inherit properties is activated the code generation for the

output variable
of an Assignment block inherits user-specified constraint
min/max values from
its input Y0 without taking further user-specified min/max
values of the other
input U into account. Therefore, the min/max values of U are
simply ignored even
if they exceed those of Y0. No warning is given. This may lead
to incorrect
production code and unexpected results, e.g. mismatch
between MIL and SIL
simulation.
For example, consider an assignment block whose input Y0 is
a vector of width 3.
Each element of this input vector has min/max values [0 1].
The input U is a
scalar with min/max values [-1 1]. This means that each signal
element of the
output variable (which is also a vector of width 3) has potentially - min/max
values [-1 1] (which one will actually have it depends on the
values of the Idx
input). However, the code generator treats the min/max values
of each signal
element of the output as [0 1] using the min/max values of Y0.
To understand the effects of this phenomenon on the
generated code, suppose that
the output of the assignment block is connected to the input of
a saturation
block with limits [0 1]. In correct code, the saturation logic
should be
generated because each signal element can potentially have
a value of less than
0. However, currently the code generator optimizes away the
saturation logic
because each signal element of the assignment's output is
marked with min/max
values [0 1] which falls within the saturation limits. This means
that the
output of the saturation block can also attain values less than
0 during the SIL
simulation. This is clearly erroneous.
Workaround: 1) Adjust the min/max values of the Y0 input of an assignment
block such that
they match those of the U input. For the above example, the
problem can be
remedied by setting the min/max values of the Y0 input to [-1
1] at the suitable
place (i.e. at the source block whose output is connected to
the Y0 input).
2) Similar such constraint min/max can be specified for the
Assignment output
directly when deactivating inherit properties.

771 / 1260

ID:

KPR.2013.04.17.010

Title:

Relational operation erroneously omitted in the generated

code

Last Update: 28 Aug 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:

Incorrect code/compilable

Description: If all of the following conditions are fulfilled a relational

operation may be
erroneously removed from the generated code by code
optimization:
- One of the operands of the relational operation is a constant
(for example a
Constant block with Class=default, or in Stateflow, a numeric
constant), the
other operand is a variable __AND__
- the variable has an arbitrary scaling __AND__
- the variable has a "Min" or a "Max" value specified __AND__
- the value of the constant is exactly the minimum or
maximum value that can be
represented by the scaling of the variable (implemented
minimum/maximum value of
the variable) __ AND__
- the implemented minimum/maximum value of the variable is
not constrained
already by the specified "Min"/"Max" values of the variable (s.t.
the relational
operation would be irrelevant per se, i.e. always true or false)
__AND__
- the relational operation has one of the following forms:
variable < constant equal to implemented maximum value of
the
variable
variable > constant equal to implemented minimum value of
the
variable
variable >= constant equal to implemented maximum value of
the
variable
variable <= constant equal to implemented minimum value of
the
variable
Workaround: 1) Do not specify "Min"/"Max" values for the variable (neither
"Min" nor "Max").
Or 2) Specify a variable class for the constant. In case of a
Constant block you
have to select a variable class in the block dialog of the
Constant block. In
case of a numeric constant in Stateflow you have to create a
Stateflow data
object with kind=Constant and assign a variable class to the
Stateflow data with
the TargetLink Property Manager.
Or 3) Disable the code generator optimization.

772 / 1260

ID:

KPR.2013.04.18.001

Title:

Simulation does not work if Windows file system behavior for 8dot3 name creation is deactivated

Last Update: 08 Jul 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:

Simulation

Description: If the Windows file system behavior for 8dot3 name creation is switched off, a
long path cannot be converted from
"D:\PROGRAM FILES\TARGETLINK 3.4" to the short 8dot3 form "D:\PROGRA~1\
TARGETLINK 3.4". As current TargetLink versions rely on 8dot3 names for
compiling the simulation, switching it off leads to different errors in
TargetLink, like the following:
===============================
ERROR: The source file
D:\PROGRAM
does not exist. Please generate code first and/or
check the installation
MAKE PROCESS ABORTED
===============================
===============================
GENERATING SYMBOL TABLE...
*** E08124: SYMBOL TABLE IMPORT:
*** Invalid XML file. The error message is:
*** The reading of the schema file
'C:\Programme\dSPACETL3_3\Dsdd\SymbolTabl
eParser' fails. At line 0
===============================
Workaround: Activate the 8dot3 name support in Windows (please see Windows help documents
etc.).
Note: Changing this does not change the files, but it does change the way that
NTFS displays and manages files. So, after enabling 8dot3 name creation
TargetLink must be installed again!

773 / 1260

ID:

KPR.2013.04.30.001

Title:

Code generation aborts for simple AUTOSAR Client-Server

get/set operations with specified application errors

Last Update: 31 Jul 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:

Aborted code generation

Description: For simple get or set operations (with "AUTOSAR

communication kind" set to
"Client-Server" at the block) it is not possible to model the
receive of an
application error with the TargetLink AUTOSAR blockset, so
that code cannot be
generated for this scenario if the PossibleErrorRef property is
set.
This means that if a client runnable is modeled (but not a
server runnable)
which requests a simple get or set operation, TargetLink emits
an error message
similar to the following during the code generation if the
PossibleErrorRef
property at the Operation object in the Data Dictionary points
to an
ApplicationError object:
Error #02947: / ... /Operations/Get:
The PossibleErrorRef property must not be set for operation
object
'/Pool/Autosar/Interfaces/...' at client-server interfaces.
Workaround: If possible unset the PossibleErrorRef property at the affected
Operation
object(s) in the Data Dictionary.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p3

774 / 1260

ID:

KPR.2013.04.30.002

Title:

TargetLink block data not restored during re-preparation

Last Update: 24 May 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:

Modelling

Description: In case that

- a system (subsystem, model or library) is cleared from
TargetLink with the
SaveTLData option set to "on" and
- the system is modified: a TargetLink-enhanceable Simulink
block is inserted
(i.e. the block has no saved TargetLink data) and
- the system is re-prepared for TargetLink with the
RestoreTLData option set to
"on"
then TargetLink partially fails to restore the saved TargetLink
block data: All
blocks that are enhanced before the new block is processed
have their saved data
restored, but the saved TL data of the remaining blocks are
lost.
Workaround: No workaround available.

775 / 1260

ID:

KPR.2013.05.14.001

Title:

Error #00000 for extern C Stateflow symbol variables

(EnableExternCStateflowSymbols=on) used as parameters for
Stateflow customer-specific functions

Last Update: 29 May 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:

Aborted code generation

Description: If extern C Stateflow symbol variables

(EnableExternCStateflowSymbols=on) are
used as parameter for calling Stateflow customer-specific
functions (via
sf_<fcn_name>_script.m) the code generation aborts with an
unspecific error like
the following:
Error #00000: Argument #1 in call of function '<fcn_name>'
does not match
prototype.
Workaround: Do not use extern C Stateflow symbol variables in
combination with Stateflow
custom functions (custom function scripts). Instead either use
extern C
Stateflow symbol variables in combination with extern C
Stateflow symbol
functions or use Stateflow Data with variable classes
storage=extern or alias=on
together with Stateflow custom function scripts.

776 / 1260

ID:

KPR.2013.05.14.002

Title:

AUTOSAR 2.x/3.x export of Scaling objects raises error

E08784

Last Update: 24 May 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:

Utility

Description: The error E08784 is thrown during the export of Scaling

objects with
ConversionType='TAB_VERB' containing ConversionTable
entries with large values
(number of digits >= 9).
E08784:
Error detected in attempt to export COMPU-METHOD
<ScalingName>.
If the conversion type is TAB_VERB, only natural numbers are
supported for lower
and upper limit values.
The exported LOWER-LIMIT and UPPER-LIMIT values of the
corrosponding
Scaling.ConversionTable entries are incorrect and cannot be
imported again into
the Data Dictionary.
Workaround: 1) Do not use large values for ConversionTable entries.
or 2) Correct the the corrosponding LOWER-LIMIT and
UPPER-LIMIT values of the
COMPU-METHOD element in the exported AUTOSAR file.

ID:

KPR.2013.05.14.003

Title:

Code generation aborts with error #30052 for a struct typedef

defined in a Data Dictionary Typedef subgroup

Last Update: 08 Jul 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:

Aborted 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:

Incorrect code/compilable

TargetLink 2.2 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: Compilation of generated code fails, if

ID:

KPR.2013.06.26.001

Title:

TargetLink loses necessary casts if the code generator option

"NoAssignmentOfBooleanIfThenElse" is deactivated

Last Update: 08 Jul 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:

Incorrect code/compilable

795 / 1260

Description: The TargetLink optimization transforms a code pattern like

if (expression) {
out = ... 1;
} else {
out = ... 0;
}
to
out = expression;
Incorrectly TargetLink omits necessary cast to the type of "out"
in this pattern
in the generated code if
- the optimization is activated AND
- the code generator option
"NoAssignmentOfBooleanIfThenElse" is deactivated
(which is the default) AND
- the "... 1" and "... 0" parts are constant expressions with
value 1 and 0,
respectively, AND
- "out" has a non-boolean type.
I.e. in such a case correct would be "out = (out)expression;".
Omitting the cast may lead to compiler warnings/errors or to
incorrect results
being calculated by the code.
Example:
If a switch block
- has a floating-point output AND
- 2 inputs AND
- one input is a default constant with the value 1 AND
- the other input is a default constant with the value 0 AND
- a non-float control input,
the optimization might change the code pattern from
if (bool_control_in) {
float_out = 1.0;
} else {
float_out = 0.0;
}
to
float_out = bool_control_in;
or float_out = !bool_control_in, respectively.
This leads to a compiler warning about an conversion from int
to float.

796 / 1260

Workaround: 1) Generate code with deactivated optimization or

"NoAssignmentOfBooleanIfThenElse"="on".
Or 2) use constants for the pattern that TargetLink is not
allowed to evaluate:
Create a variable class with properties Macro=on and
Optimization={MOVABLE} or
{MOVABLE, MERGEABLE} and set it for the Constant blocks
or Stateflow Parameters
providing the 0 and 1 constants, respectively.
Or 3) if you want to have optimization but need the cast and
have a Boolean
condition, then insert a Rescaler block (or, for TargetLink
versions < 3.0, a
TargetLink Outport block) with the desired output type on the
signal line from
the Switch block (or block ensemble leading to the code
pattern) and assign it
the desired Target type. Assign a Boolean type to the
preceding output variable
and also assign a variable class that has an Optimization
property not
containing ERASABLE.

797 / 1260

ID:

KPR.2013.07.16.001

Title:

Data Dictionary not correctly auto-saved on modifications in

included subtree

Last Update: 18 Jul 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:

Utility

Description: If an additional partial Data Dictionary file was loaded into an

included
subtree which was thus modified, the Data Dictionary should
save the included
file automatically (if AutoSave = OnlyIfModified), or the user
should be
prompted if the included file should be saved (AutoSave =
PromptIfModified).
However, this does not happen, i.e. the included file is not
saved, in the case
that
- A Data Dictionary file contains an included Data Dictionary,
specified with a
DDIncludeFile object with the AutoSave property of the object
is set to
OnlyIfModified, or PromptIfModified.
- AND an additional partial Data Dictionary file is loaded into
an arbitrary
position in the included subtree, either with the Data
Dictionary Manager "Load
object" context menu, or the Data Dictionary MATLAB API
"Load" command.
- AND the Data Dictionary is saved, for example, with the Data
Dictionary
Manager "File/Save" menu, or the Data Dictionary MATLAB
API "Save" command.
Workaround: Save the included subtree manually with the API's "Save"
command, or the Data
Dictionary Manager's "Save" object context menu.

798 / 1260

ID:

KPR.2013.07.18.001

Title:

Code generation aborts with error #90105 for models

containing incremental subsystems from a block library

Last Update: 18 Jul 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:

Aborted code generation

Description: The code generation aborts with an error message and no

code is generated if a
TargetLink subsystem contains a library block, which contains
or is a subsystem
for incremental code generation and the code generation is
started for the
TargetLink subsystem's code generation unit.
Error #90105:
Internal error. Contact dSPACE technical support.
The eval command in tl_get_compiled data failed. See
message below
Error using ==> strcmp
Not enough input arguments.
Workaround: Break the library link of the library block.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p3

ID:

KPR.2013.07.30.001

Title:

Call of non existing FIT macro generated or code generation

aborts with a fatal error #17077

Last Update: 25 Oct 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:

Incorrect code/not compilable

Description: If
- a model contains a block (block A) for which saturation to the
implemented
range is specified (i.e. 'Saturate' is checked in the block
dialog) AND
- for that block saturation to one of the limits (limit A) is not
necessary
because the worst case range value for that limit is
smaller/greater than the
associated implemented limit AND
- saturation to the other limit is necessary AND
- that block feeds directly or not directly another block (block
B) that also
demands saturation to the implemented range and if
- for block B saturation to a limit is not necessary AND
- for block B saturation to that limit would be necessary, if for
limit A the
implemented limit could come up,
799 / 1260

then for the TargetLink versions 3.1 and 3.2:

a call to a non existing saturation macro containing the strings
FIT and _SAT in
its name can be generated or
or for the TargetLink versions > 3.2:
Fatal #17077: <block>: 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 <macro name>
can come up.
Example:
Division block:
UInt8 DivOut; LSB = 2^-1; Saturate upper & lower
Input 1: Constant block with value 1.0 and default variable
class
Input 2: Block with Int16 DivIn2Var; LSB = 2^-16; Max =
0.498046875; Min = 0.0;
feeds first input of
Sum block implementing a subtraction with
UInt16 SumOut; LSB = 2^-1;Saturate upper & lower
Input 2: Constant block with value 1.0, variable class CONST
and LSB = 1.0
In this constellation we have
DivOut = 1.0 / DivIn2Var;
considering scalings implemented as
DivOut = 131072 / DivIn2Var;
The ranges for that expression are
[4 131072] = 131072 / [0 327640] which becomes after
saturation a range of [4
255]
the following subtraction is implemented as
SumOut = DivOut - SumIn2
with the ranges
[2 253] = [4 255] - [2 2]
which means that no saturation for the output of the
subtraction is necessary.
If the output range of the division block however is considered
to be [0 255]
the ranges would be
[-2 253] = [0 255] - [2 2]
and saturation to the lower limit would be necessary.
In this case a call to the non existing FIT macro
C__U16FITU8_SATl is generated.
Workaround: Change the variable class of the output of the first saturated
block (= block A)
to a global or static variable class.
In the example above block A is the Division block.

800 / 1260

ID:

KPR.2013.07.30.002

Title:

Incorrectly placed or missing Post Definition/Declaration

BlockStatements for functions in the generated code

Last Update: 05 Sep 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:

Incorrect code/compilable

Description: When specifying Pre and/or only Post Definition/Declaration

BlockStatements in
FunctionClasses, then in the generated code the Post Block
Statements may
wrongly be placed inside the function body, if the function
contains any local
variables. Further in such a case, also the Post Block
Statement after the last
function of the block is missing in the generated code.
Note that depending on the statement contents, the incorrect
generated code may
be compilable or not compilable.
Workaround: Use Pre/PostDefinition/DeclarationStatements instead of
BlockStatements.

801 / 1260

ID:

KPR.2013.07.31.001

Title:

Not compilable AUTOSAR production code with RTE code

Last Update: 05 Sep 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:

Incorrect code/compilable

Description: The change detection in the first call of a Stateflow chart shall
return always
0 (false). For example if a Stateflow input data is watched with
"hasChanged(in)" the result has to be 0 (false) in the first chart
execution
regardless which value the data "in" has. But the code
generated by TargetLink
returns a 1 (true) if the value of "in" is not 0 in that first
execution. Only
for the following chart exceutions the code calculates the
correct result.
Workaround: 1. Create a chart Local data - for example "FirstRun" - and set
its initial
value to 1.
2. Then modify the action/condition with the hasChanged
operator so that it
delivers always 0 if FirstRun==1 and sets FirstRun to 0.

ID:

KPR.2013.08.06.001

Title:

Missing restart code for reused variables in AUTOSAR code

generation mode

Last Update: 09 Aug 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:

Incorrect code/compilable

Description: If the AUTOSAR code generation mode is chosen AND

- the software component hierachy represented by the
TargetLink model contains a
library subsystem AND
- this library subsystem will be implemented as reused
function AND
- one or more variables that are instance specific to the library
subsystem need
re-initialization in a restart function,
then this re-initialization will be omitted in the generated
production code.
Workaround: No workaround available.

806 / 1260

ID:

KPR.2013.08.06.002

Title:

SIL/PIL simulation plots signals inside wrong plot windows for

AUTOSAR Operation Call Subsystems

Last Update: 03 Dec 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:

Simulation

Description: Due to an incorrect specification inside the Data Dictionary

Subsystem area made
by the TargetLink code generator, the logging and ploting
mechanism may not be
able to map signals which are logged inside AUTOSAR
Operation Call Subsystems to
the correct plot windows. The plot windows are then named
after the variable in
the code and not after the block inside the model. This results
in SIL/PIL
signal differences compared to MIL.
Workaround: Log the signals in question outside of the Operation Call
Subsystem.

ID:

KPR.2013.08.14.001

Title:

Code generator option "Functions for 64-bit operations"

applies only to multiplications

Last Update: 07 Mar 2014

TargetLink 2.2 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: The code generation option 'Generate64BitFunctions' which

also can be accessed
via the "Functions for 64-bit operations" checkbox on the
Advanced page of the
TargetLink Main dialog only applies to 64 bit multiplications.
Workaround: No workaround available.

ID:

KPR.2013.08.20.001

Title:

Erroneous array access for struct components of a struct

variable with AccessFunction template

Last Update: 23 Aug 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:

Incorrect code/not compilable

807 / 1260

Description: If a struct variable has a variable class with an

AccessFunctionTemplate that
contains an AccessFunction object applying to struct (i.e. a
variable access
function), then TargetLink generates accesses to this struct
variable's
components via a call to the access function, for example
Rte_Pim_Foo()->comp[x].
If an access demands using an auxiliary variable, e.g. for calls
to a macro,
then TargetLink inserts the auxiliary variable and copies from /
to the struct
component. Since TargetLink version 3.3, TargetLink always
uses an auxiliary
variable of the same type (and especially width) as the struct
component
variable.
In some contexts, the copy statements for vector and matrix
components
incorrectly take place as if for a scalar component:
/* SLLocal: Default storage class for local variables | Width: 8
*/
uint8 _tmpu[16];
...
_tmpu = Rte_Pim_Foo()->comp[x];
...
/* Use _tmpu[x] */
instead of
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
_tmpu[Aux_S32] = Rte_Pim_Foo()->comp[Aux_S32];
}
...
/* Use _tmpu[x] */
The resulting code does not compile.
To summarize: This error occurs for struct components
- if one of the parent structs has a variable access function
(kind DIRECT,
ADDRESS, DIRECT_BY_PARAMETER,
ADDRESS_BY_PARAMETER) AND
- if the struct component is a vector or matrix AND
- if the struct component is used in a context necessitating an
auxiliary
variable (or if you forced creation of auxiliary variables via the
CreateLocalValueCopy property of the AccessFunction
object).

Dictionary objects is
overwritten with defaults by the AUTOSAR Import, although
no Description is
specified in the ARMXL file.
E.g. this behaviour causes the following warning message, if
AUTOSAR base types
are imported:
Warning 14:44:35 W08836: Warning during AUTOSAR import
The following typedef
objects are specified in compliance to AUTOSAR Master DD
and will be overwritten
by defaults:
/Pool/Typedefs/DataTypes/Double
Workaround: The Description in the ARXML file should be the same as in
the used Data
Dictionary to avoid data loss.
Otherwise a separate merge mechanism can be applied after
the AUTOSAR Import.

812 / 1260

ID:

KPR.2013.08.20.006

Title:

Incremental code generation aborts with a fatal error #08914

Last Update: 20 Dec 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:

Aborted code generation

Description: The following problem may happen for scalings used by structures:
Incremental code generation fails with an error message like the
following:
Fatal #08914:
Corrupted data found. The variable
/Subsystems/SubsystemName/FunctionName/Variables/VariableName
does not reference
a scaling object. Do not edit the subsystem area. Start codegeneration
for
incremental code unit <cgu> again.
The error occurs because the scaling which is referenced by the
variable is not
found, as it was not copied from the Pool area to the Subsystems area
in the
Data Dictionary by the previous (incremental) code generation run.
Workaround: The only workaround is to adjust the Data Dictionary Subsystem after
the code
generation, e.g. by executing a user_post_codegen_hook.m file and
copy the
scaling objects from Pool.
For example when using VOID_SCALING for a structure component,
execute the
command:
dsdd('Copy','source', '/Pool/Scalings/VOID_SCALING', 'destination',
'/Subsystems/SubsystemName/Scalings', 'access', 'rwrw');
The problem is fixed by using the following patch or later patches:
TargetLink 3.4p5

813 / 1260

ID:

KPR.2013.08.20.007

Title:

Missing Variable Classes in generated documentation

Last Update: 05 Sep 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:

Incorrect code/compilable

815 / 1260

Description: Incorrect code is generated for a Saturation block if

- a lower or upper saturation limit lies outside the implemented
range of the
block output AND
- the limit has variable class != default but not calibrateable,
e.g. with Info
property == none or readonly AND
- (scaling of saturation limit != output scaling) OR (input type of
the
Saturation block != type of saturation limit) AND
- width of input type > width of output type AND
- (scaling of saturation limit != output scaling) OR (type of
saturation limit
!= output type).
Example:
Saturation block whose output is Int16. Lower limit = -32850,
upper limit =
32800, variable class != default and not calibrateable.
Although warning #20501 is emitted for each limit, saying that
the init value
for the limit is outside the implemented range of the output,
the following
wrong code is generated:
Int32 Sa1_Saturation_upper = 16400 /* 32800. */ /* LSB: 2^1
OFF: 0 MIN/MAX:
32800 .. 32800 */;
Int32 Sa1_Saturation_lower = -65700 /* -32850. */ /* LSB: 2^1 OFF: 0 MIN/MAX:
-32850 .. -32850 */;
Int16 Aux__a;
Int16 Aux__b;
/* Saturation: Subsystem/Saturation */
Aux__a = (Int16) (Sa1_Saturation_upper << 1); ==> wrong
because overflow appears
Aux__b = (Int16) (Sa1_Saturation_lower >> 1); ==> wrong
because overflow appears
Sa1_Saturation = C__I16SATI32_SATb(Sa1_InPort1,
Aux__a, Aux__b);
The expected behaviour would be an error message of the
code generator.
Workaround: 1) Avoid to specifiy saturation limits outside the implemented
range of the
block output
Or 2) use a calibrateable variable class if desired.

ID:

KPR.2013.08.27.002

Title:

Wrong computation order of a function-call triggered

subsystem in the generated code

Last Update: 10 Mar 2014

816 / 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: Let T1, T2, ..., Tn be atomic subsystems, where T1 triggers

T2, T2 triggers T3
and so on by function-call. T1 is not triggered by another
subsystem. Let A be a
block or a subsystem which has a data signal path to the
function-call triggered
subsystem Tn, where A must be computed before Tn. Let B
the last block on this
signal path (if there is no block on the path from A to Tn then
set B = A): A->
... ->B->Tn.
For identifying the problematic situation imagine that the
signal B->Tn is
removed and replaced by a new signal B->T1. If this
(imaginary) change of the
model results in a signal loop (which must not be an algebraic
loop) with A and
T1 on this loop T1->...->A->...->B->T1, then the generated
production code may
be wrong but compilable: Tn might be computed before A
(and all following blocks
including B) are computed.
Example:
With two atomic subsystems T1, T2 and a Unit Delay U and a
Gain A:
T1 triggers T2 by function-call
and T1->U->A->T2.
Now imagine A->T2 is changed to A->T1, which means there
is a (non-algebraic)
loop T1->U->A->T1. Note the model itself is not changed. I.e.
in mind think of
the ingoing data signals of the triggered subsystem T2 to be
ingoing into the
trigger source subsystem T1 instead.
Correct calculation order for above example would be "A, T1,
T2", but
incorrectly in the generated code may become "T1, T2, A".

817 / 1260

Workaround: 1) Try to change your model in a way that clearly forces the
computation of A
before Tn, e.g. by a Stateflow chart which triggers first A and
then T1 by
function call output events.
Or 2) If the above described model situation is located inside
an atomic
subsystem, then add a branch line connection from ..->Tn to a
new Simulink
outport (having the highest port number) and just terminate
the port outside of
the atomic subsystem.
The problem is fixed by using the following patches or later
patches:
TargetLink 3.3p6
TargetLink 3.4p5

ID:

KPR.2013.08.28.003

Title:

Stateflow auxiliary functions in AUTOSAR Runnables

Last Update: 25 Oct 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:

Incorrect code/compilable

Description: For Stateflow charts, there are several kinds of auxiliary

functions that are
generated for correct code and often vanish due to inlining
and optimization in
the final form of the generated code. Incorrectly TargetLink
loses information
about an AUTOSAR Runnable inside such auxiliary functions.
Thus if there is an
access to a variable with a variable class referencing an
AccessFunctionTemplate
object which contains at least one AccessFunction object with
its BelongsTo
property set to RTE API or custom RTE API, e.g. a calibration
or
PER-INSTANCE-MEMORY variable or struct component, then
the TargetLink code
generator either aborts with an unspecific fatal error or
generates wrong code.
The generated code either contains a wrong RTE API call leading to a compile
time error - or an access to a TargetLink simulation frame
variable that must
not be accessed by the production code, but which may
compile.
Workaround: Introduce additional variables (Stateflow data) in order to
avoid RTE API
accesses in Stateflow auxiliary functions.
Else no workaround available.

ID:

KPR.2013.09.26.001

Title:

Code generation does not terminate for code situations

involving loop between function call and copy of actual
parameter

Last Update: 25 Oct 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:

Aborted code generation

823 / 1260

Description: TargetLink code generation may not terminate if all conditions

in the in the
following descriptions are fulfilled:
1) If a function call with out parameter precedes a useless
scalar assignment
2) which IMMEDIATELY precedes a loop
3) that precedes the copy statement of the out parameter to
another variable,
Code Example:
f(out_b);
...
useless = ...
do {
...
} while (...);
...
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
MyVector[Aux_S32] = out_b[Aux_S32];
}
For this to go wrong, there is an additional precondition:
4) TargetLink does not immediately recognize the out
parameter as "guaranteedly
defined" inside the function and initial value and persistence
preconditions do
not allow for optimization otherwise.
Modeling example:
A For Iterator subsystem directly contains a function block and
has a TargetLink
outport with call-by-reference semantics for a vector output.
This subsystem is
"f()".
In the calling subsystem, f()'s output drives a Unit Delay block
which in turn
drives f()'s input (directly or indirectly). A second output drives
an output of
the calling subsystem (directly or indirectly).
The calling subsystem also contains a Relation block with one
vector and one
scalar input (and vector output, giving rise to a loop) that
drives a Terminator
block. The scalar input is driven by some calculation.

824 / 1260

code generator
for code generation (e.g. "DisplayIdentifier") and that are
specified at struct
component Variable objects in the Data Dictionary Pool area
do not appear in
Subsystems area after code generation, whereas such
additional properties set at
plain Variable objects are copied from Pool to Subsystem
area.
Workaround: Postprocess the DD Subsystem in a *_post_codegen_hook.m
wich copies the missing
properties of struct variables from the /Pool area to the
correspondig Subsystem
object.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.4p5

ID:

KPR.2013.10.22.001

Title:

SIL compilation fails for multiple instantiation of AUTOSAR

software components

Last Update: 02 Dec 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:

Simulation

Description: If a Runnable R contains an incremental system which

Last Update: 02 Dec 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:

Simulation

Description: The TargetLink code generator doesn't generate stub code (.c
file) for a
variable with access function (macro).
This leads to SIL/PIL build process failures (linker fails with
unresolved
externals).
Workaround: Generate production code for a such variable for the
simulation build process.
E.g. generate code for all code generation units at once or
adjust module
ownership for the variable's module.

ID:

KPR.2013.10.30.001

Title:

AUTOSAR 4.x export does not export Variable Category if a

Variable is used as InitialValue

Last Update: 20 Dec 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:

Utility

Description: If a Variable object is used as InitialValue by an AUTOSAR

ComSpec Object, the
property Category of the Variable object is not exported.
This happens only if the Variable is typed by
ApplicationDataType.
This means either the property ApplicationDataTypeRef is set
to an
ApplicationDataType or the ImplementationDataType set at
the property Type is
mapped to an ApplicationDataType in DataTypeMap object.
Workaround: No workaround available.
The problem is fixed by using the following patches or later
patches:
TargetLink 3.3p7
TargetLink 3.4p5

830 / 1260

ID:

KPR.2013.11.06.001

Title:

SIL/PIL compilation fails due to RTE simulation frame code

having re-defined functions

Last Update: 20 Dec 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:

Simulation

Description: If a server runnable is referenced by more than one

OperationInvokedEvent in the
Data Dictionary, a SIL or PIL simulation application cannot be
built ("MAKE
PROCESS ABORTED") in the AUTOSAR code generation
mode because of multiply
defined functions in the generated RTE simulation frame files
Rte.c/h.
Workaround: The problem can be circumvented by deleting all
OperationInvokedEvents
referencing the same server runnable except for one. This
step can also be
performed after the code generation, e.g. using a
post_codegen_hook function.
Please note that such a deletion of OperationInvokedEvents
will affect the
AUTOSAR XML export.

ID:

KPR.2013.11.06.002

Title:

AUTOSAR 3.2.2 TEXTTABLE COMPU-METHODs with UNITREF are not imported

Last Update: 20 Dec 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:

Utility

Description: The error E08756 is thrown during the import of a COMPUMETHOD with
CATEGORY=TEXTTABLE and a UNIT-REF. Such COMPUMETHODs are not imported.
While this behaviour is correct for AUTOSAR < 3.2.2, it is
erroneous for AUTOSAR
3.2.2 which allows a UNIT-REF for TEXTTABLE COMPUMETHODs.
A message like the following will be emitted by the Data
Dictionary:
Error 10:42:19 E08756: Error during AUTOSAR import Error
detected in attempt to
import COMPU-METHOD <ScalingName>.
No UNIT-REF is allowed if the conversion type is
TEXTTABLE.
Workaround: No workaround available.

831 / 1260

ID:

KPR.2013.11.15.001

Title:

Code generation aborts with fatal error 10008 because of

erroneously merged loop from inlined function

Last Update: 07 Mar 2014

TargetLink 2.2 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: If all of the following conditions are fulfilled:

- function f() is inlined into function g() AND
- the first statement of function f() is a loop AND
- the statement preceeding the (inlined) call of f() in g() is a
loop of the
same size AND
- the last statement in f() is a call to an empty function that is
also inlined
AND
- function f() contains further loops that do not directly follow
the first loop
then the code generation might fail issuing
Fatal #10008: <block> Internal error. Error code:
TlCVSQSOReplacer xxx. Contact
dSPACE's technical support team
Note that loops in the generated code often result from none
scalar, i.e.
vector, signals.
Example:
Subsystem 'Subsy' contains a Stateflow chart 'Chart' that
triggers another
subsystem 'TriggeredSubsys'.
Then the init function of Subsys (InitSubsys()) calls the init
function of Chart
(InitChart()) which calls the init function of the triggered
subsystem
(InitTriggeredSubsys()).
The resulting code without inlining would, for example, be:
void InitSubsys(void)
{
for(Aux_=0; Aux_ < 6; Aux_++)
{
Var[Aux_] = 0;
}
InitChart();
}
void InitChart(void
{
for(Aux_=0; Aux_ < 6; Aux_++)
{
Var2[Aux_] = 0;
}
ScalarVar = 0;
832 / 1260

for(Aux_=0; Aux_ < 6; Aux_++)

{
Var3[Aux_] = 0;
}
InitTriggeredSubsys();
}
void InitTriggeredSubsys(void
{
}
For this constellation the fatal error happens because the loop
(around Var) in
InitSubsys is merged with the first loop of InitChart (around
Var2) after
InitChart has been inlined and because InitChart contains the
call to the empty
init function InitTriggeredSubsys.
In this constellation the problem can be avoided by changing
the function class
of InitChart to a function class with the CG_NO_INLINING
optimization attribute.
Note that, if no inlining attribute for the optimization property of
a function
class is set, TargetLink assumes CG_NO_INLINING.
Workaround: Analysis to identify the problem:
Disable inlining (Set the Inlining Threshold to '0' on the
Advanced tab of the
TargetLink MainDialog).
If the fatal disappears, search the generated code for the
constellation
described above.
Note that in some cases calls of empty functions (like init
functions) can be
omitted even if the inlining is disabled.
Workaround:
If a constellation like discribed above was found, suppress the
inlining of the
affected functions by changing their function class to a class
with the
CG_NO_INLINING Optimization attribute. If the function class
cannot be accessed
directly try applying a function class template or a function
template.

833 / 1260

ID:

KPR.2013.11.18.001

Title:

Generation of the PDF documentation for AUTOSAR code

fails if multiple interfaces with identical names are defined

Last Update: 02 Dec 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:

Utility

Description: The generation of the PDF documentation fails with the error
[ERROR] file:<filePath> The id
"anchor_<subsystemName>_<interfaceName>_AUTOSAR"
already exists in this document
*** E09999: ERROR USING DS_DOS:
*** Error when trying to invoke the command <command>
*** See log file <command>
if following conditions apply:
1) The production code to be documented was generated in
AUTOSAR mode AND
2) in the AUTOSAR software components interfaces with
identical names, but in
different Interface-Groups/Packages are defined.
For example (Data Dictionary excerpt):
AR
|--> Interfaces
|
|--> MyInterfaceGroup
|
|--> MyInterface
|
| --> MyInterface
Workaround: For PDF documentation generation no workaround is
available. However, the
generation of documentation in HTML or RTF format works.
The problem is fixed by using the following patch or later
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

Last Update: 02 Dec 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:

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.
The problem is fixed by using the following patch or later
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

Last Update: 20 Dec 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:

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

Last Update: 28 Feb 2014

TargetLink 2.2 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

Last Update: 02 Dec 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:

Simulation

Description: Performing a SIL/PIL simulation leads to an abnormal

MATLAB termination, if the
following conditions are fulfilled:
- 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:

of inclusion to is read-only"

Last Update: 28 Feb 2014

TargetLink 2.2 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

Last Update: 28 Feb 2014

TargetLink 2.2 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

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.
The problem is fixed by using the following patch or later
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

Last Update: 31 Jan 2014

TargetLink 2.2 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

Last Update: 24 Jan 2014

TargetLink 2.2 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
}
Workaround: No workaround available.
The problem is fixed by using the following patch or later
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

Last Update: 14 Mar 2014

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.
Workaround: No workaround available.

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

Last Update: 28 Feb 2014

TargetLink 2.2 2.2.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

Last Update: 14 Mar 2014

TargetLink 2.2 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: 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

Last Update: 24 Mar 2014

TargetLink 2.2 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

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.

ID:

PR20030715-06

Title:

Errors after closing a model when

Class/Type/Variable/Scaling selection dialog is open

Last Update: 02 Feb 2005

TargetLink 2.2 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

Last Update: 02 Feb 2005

TargetLink 2.2 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.
Workaround: No workaround available.

860 / 1260

ID:

PR20031113-20

Title:

Difference between MIL and SIL simulation if variable step

size and inherit sample time selected

Last Update: 02 Feb 2005

TargetLink 2.2 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.
Workaround: No workaround available.

ID:

PR20040109-08

Title:

MIL mode logging in loops may be wrong and differ from SIL
or PIL mode logging

Last Update: 11 Jan 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: 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

Last Update: 14 Dec 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:

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

Last Update: 02 Feb 2005

TargetLink 2.2 2.2.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
Workaround: No workaround available.

ID:

PR20040312-19

Title:

Initialization code in for loop not optimal

Last Update: 02 Feb 2005

TargetLink 2.2 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: 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

Last Update: 17 Jul 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:

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.
Workaround: No workaround available.

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

Last Update: 02 Feb 2005

TargetLink 2.2 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

Last Update: 02 Feb 2005

TargetLink 2.2 2.2.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

Last Update: 02 Feb 2005

TargetLink 2.2 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: 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

Last Update: 02 Feb 2005

TargetLink 2.2 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

Last Update: 11 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:

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

Last Update: 02 Mar 2007

TargetLink 2.2 2.2.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

Last Update: 23 Feb 2007

TargetLink 2.2 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

Last Update: 17 Jul 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:

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.
Workaround: No workaround available.

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

Last Update: 02 Mar 2007

TargetLink 2.2 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

Last Update: 02 Feb 2005

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20041110-13

Title:

State variables with local scope are not re-initialized

Last Update: 01 Mar 2007

TargetLink 2.2 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: 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
- Discrete State-Space
- Discrete-Time Integrator
- Custom Code
- Discrete Transfer Function
- Discrete Filter
- Unit Delay Reset Enabled
- 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

Last Update: 17 Jul 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:

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

Last Update: 02 Dec 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:

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

Last Update: 22 Nov 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:

Incorrect code/compilable

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

Last Update: 23 Feb 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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

Last Update: 13 Apr 2006

TargetLink 2.2 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.
Workaround: No workaround available.

878 / 1260

ID:

PR20050621-13

Title:

Osek message with more than one sender created

Last Update: 23 Feb 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20050628-20

Title:

TOM TriCore/Task23: Renaming of sections does not comply

with syntax of Tasking 2.3 compiler

Last Update: 11 Jan 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:

Incorrect code/not compilable

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
Workaround: No workaround available.

879 / 1260

ID:

PR20050712-07

Title:

Wrong datatype conversion to boolean during MIL/SIL

simulation

Last Update: 26 Feb 2007

TargetLink 2.2 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

Last Update: 26 Feb 2007

TargetLink 2.2 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: 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"

Last Update: 02 Mar 2007

TargetLink 2.2 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

Last Update: 13 Apr 2006

TargetLink 2.2 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

Last Update: 08 Sep 2005

TargetLink 2.2 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"

Last Update: 05 Mar 2007

TargetLink 2.2 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

Last Update: 26 Feb 2007

TargetLink 2.2 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: TargetLink may generate an unnecessary task if all of the

following conditions
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
TargetLink subsystem
- 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

Last Update: 30 Aug 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:

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
TargetLink subsystem
the SIL/PIL simulation is not correct, although the generated
production code is
correct.
Workaround: No workaround available.

886 / 1260

ID:

PR20050809-07

Title:

Nonpersistent variable in multirate production code

Last Update: 26 Feb 2007

TargetLink 2.2 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: 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
following conditions are fulfilled:
- 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

Last Update: 26 Feb 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20050823-05

Title:

Compilation fails if two-dimensional array is address-mapped

Last Update: 15 Dec 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:

Incorrect code/not compilable

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

Last Update: 23 Feb 2007

TargetLink 2.2 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.
Workaround: No workaround available.

ID:

PR20050831-02

Title:

#ifdef support: missing include of macro definition

Last Update: 02 Mar 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

889 / 1260

ID:

PR20050916-01

Title:

Matlab R13 crashes during "Create Subsystem"

Last Update: 17 Jul 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:

User interface

Description: Update sections with the keyword "common" are created

multiple times (one for
each instance in the model) in the step function of the
TargetLink subsystem.
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.
Workaround: No workaround available.

891 / 1260

ID:

PR20051005-05

Title:

Inherited data types of Stateflow objects

Last Update: 17 Jul 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:

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:

Last Update: 27 May 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:

Inefficient code/code style

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

Last Update: 26 Feb 2007

TargetLink 2.2 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: 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

Last Update: 26 Feb 2007

TargetLink 2.2 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.
Workaround: No workaround available.

896 / 1260

ID:

PR20051214-05

Title:

Document generation produces wrong subsystem snapshot

Last Update: 26 Feb 2007

TargetLink 2.2 2.2.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

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 02 Mar 2007

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

Last Update: 02 Mar 2007

TargetLink 2.2 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:

- 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

Last Update: 26 Feb 2007

TargetLink 2.2 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.
Workaround: No workaround available.

ID:

PR20060306-03

Title:

Erroneous message about defining different types with the

same name in custom look-up table script

Last Update: 22 Dec 2006

TargetLink 2.2 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: 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

Last Update: 27 Feb 2007

TargetLink 2.2 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".

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:
/* SLLocal: Default storage class for local variables | Width: 16
*/
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

Last Update: 26 Feb 2007

TargetLink 2.2 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.
Workaround: No workaround available.

ID:

PR20060323-11

Title:

Wrong base type rename

Last Update: 12 Oct 2006

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

Last Update: 21 Dec 2006

TargetLink 2.2 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

PR20060403-11

Title:

Wrong code is generated if the FIR Filter block using TriCore

Target Optimization Module

Last Update: 26 Feb 2007

TargetLink 2.2 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: 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:

or Discrete Transfer Fcn block, their signs are not handled
correctly

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20060407-09

Title:

In discrete blocks with variant coefficients the appearance of

coefficients in code can not be influenced

Last Update: 26 Feb 2007

TargetLink 2.2 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).
Workaround: No workaround available.

916 / 1260

ID:

PR20060410-06

Title:

In Data Dictionary Manager the Data Dictionary Navigator

does not display huge amount of objects properly

Last Update: 02 Mar 2007

TargetLink 2.2 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.
Workaround: No workaround available.

ID:

PR20060412-11

Title:

Data type mismatch after Simulink to TargetLink conversion

Last Update: 22 Dec 2006

TargetLink 2.2 2.2.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

and "Interpolation (n-D)using PreLook-Up" block using
Standalone Blockset

Last Update: 26 Feb 2007

TargetLink 2.2 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

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:
*** E00000: INTERNAL ERROR:
*** Error while attempt to access the data dictionary.
Workaround: No workaround available.

ID:

PR20060609-02

Title:

Code generator aborts for Stateflow chart containing floating

point index variable

Last Update: 22 Dec 2006

TargetLink 2.2 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: 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

Last Update: 26 Feb 2007

TargetLink 2.2 2.2.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.
Note #03430: <block>:
Parameter y-axis scaled according to current value.
Note #03439: <block>:
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

Last Update: 27 Feb 2007

TargetLink 2.2 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.
Workaround: No workaround available.

923 / 1260

ID:

PR20060619-69

Title:

Undefined variable initialized in restart function leads to

compiler error

Last Update: 21 Dec 2006

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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:

Renaming custom property to an already existing custom

property name leads to content deletion

Last Update: 13 Jul 2007

TargetLink 2.2 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.
Workaround: No workaround available.

ID:

PR20060710-05

Title:

Required initialization for struct variable may be suppressed in

generated code without warning

Last Update: 27 Feb 2007

TargetLink 2.2 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".
Workaround: No workaround available.

ID:

PR20060710-06

Title:

Sum block with more than two inputs can result in

nonoptimizable auxiliary variables

Last Update: 13 Jul 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:

Inefficient code/code style

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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 21 Dec 2006

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20060717-06

Title:

Switching simulation mode fails if TargetLink subsystem uses

more than 466 root level ports

Last Update: 13 Jul 2007

TargetLink 2.2 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.
Workaround: No workaround available.

929 / 1260

ID:

PR20060721-03

Title:

Warning #20681 for Discrete Time Integrator block in

combination with an Unit Delay Reset Enable block

Last Update: 27 Feb 2007

TargetLink 2.2 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

Last Update: 27 Feb 2007

TargetLink 2.2 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: 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

Last Update: 22 Dec 2006

TargetLink 2.2 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: 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

Last Update: 17 Jul 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:

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

Last Update: 27 Feb 2007

TargetLink 2.2 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: 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

Last Update: 27 Feb 2007

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
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:

Incorrect code/compilable

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

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 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 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

Last Update: 17 Jul 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: 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

Last Update: 22 Dec 2006

TargetLink 2.2 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: You may use components of DataDictionary struct variables

ID:

PR20061017-05

Title:

The generation of model-linked code view fails when

comments contains control characters

Last Update: 02 Mar 2007

TargetLink 2.2 2.2.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

Last Update: 13 Jul 2007

TargetLink 2.2 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).
Workaround: No workaround available.

ID:

PR20061020-06

Title:

String containing ",", "{" or "}" will be split by XML

Import/Export and inplace edit of Data Dictionary Manager

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 22 Dec 2006

TargetLink 2.2 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: 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

Last Update: 27 Feb 2007

TargetLink 2.2 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: 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
following conditions hold:
- 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

Last Update: 14 Feb 2007

TargetLink 2.2 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: 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.
The problem is fixed by using the following patch or later
patches:
TargetLink 2.3.1p2

942 / 1260

ID:

PR20061101-03

Title:

Wrong code may be generated for Merge block in an enabled

subsystem

Last Update: 27 Feb 2007

TargetLink 2.2 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

ID:

PR20061107-10

Title:

Not compilable code caused by an actual parameter of a

subsystem/chart that is called internally and externally

Last Update: 02 Mar 2007

TargetLink 2.2 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 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

Last Update: 17 Jul 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 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.
Workaround: No workaround available.

ID:

PR20061109-15

Title:

Autoscaling fails for blocks from the AUTOSAR library

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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.
Workaround: No workaround available.

949 / 1260

ID:

PR20061109-16

Title:

Autoscaling fails with fatal error F03468 if blocks with a non

scalar output scaled with simulation data

Last Update: 21 Dec 2006

TargetLink 2.2 2.2.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

Last Update: 13 Jul 2007

TargetLink 2.2 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.
Workaround: No workaround available.

ID:

PR20061109-21

Title:

Stateflow action language: wrong precedence for shifts

Last Update: 13 Jul 2007

TargetLink 2.2 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:

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

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:

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:
MAKE PROCESS ABORTED
*** 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.
Workaround: No workaround available.

951 / 1260

ID:

PR20061110-01

Title:

Exported OIL file contains wrong accessname in accessor

definition

Last Update: 22 Dec 2006

TargetLink 2.2 2.2.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

Last Update: 13 Jul 2007

TargetLink 2.2 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: TargetLink may uses wrong initial value outputs of

conditionally executed
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.

Aborted code generation

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.

Last Update: 27 Feb 2007

TargetLink 2.2 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.
Workaround: No workaround available.

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.

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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

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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

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:

Inefficient code/code style

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.
Workaround: No workaround available.

ID:

PR20061122-06

Title:

Wrong code in simulation frame for extern global macro

accessible by an access function

Last Update: 05 Jan 2007

TargetLink 2.2 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

Last Update: 02 Mar 2007

TargetLink 2.2 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: 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

Last Update: 27 Feb 2007

TargetLink 2.2 2.2.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.
*** W04301: CODE VIEW FILE CANNOT BE GENERATED:
*** The HTML code view file for the production code file
*** '<file>.c'
*** could not be generated completely.
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:

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

Last Update: 02 Mar 2007

TargetLink 2.2 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

Last Update: 22 Dec 2006

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20061207-01

Title:

Unnecesary ANSI-C or resp. incorrect TOM MPC5(5)xx/Diab

64-Bit code for multiplications is generated

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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) {
/* # combined # TargetLink outport: subsystem/OutPort */
Sa1_OutPort = -32768;
}
else {
/* # combined # TargetLink outport: subsystem/OutPort */
Sa1_OutPort = (Int16) (((UInt16) Aux_S32) + 1464492);
}
}
The TL2.2 generic ANSI code is:
/* Math: subsystem/Math1 */
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:
/* Math: subsystem/Math1 */
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

Last Update: 13 Jul 2007

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

Last Update: 13 Mar 2007

TargetLink 2.2 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 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

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 2.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 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

Last Update: 22 Mar 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20070109-03

Title:

Code generation aborts, because Discrete State Space block

does not support matrices with non-external macro variable
class

Last Update: 13 Mar 2007

TargetLink 2.2 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: 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

Last Update: 01 Mar 2007

TargetLink 2.2 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

Last Update: 16 Aug 2007

TargetLink 2.2 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.
Workaround: No workaround available.

977 / 1260

ID:

PR20070111-04

Title:

Code generation aborts if legacy function script specifies a

pointer to a structure within a structure

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20070112-02

Title:

Missing optimization of unnecessary saturation statements

Last Update: 13 Jul 2007

TargetLink 2.2 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 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;
}
Workaround: No workaround available.

978 / 1260

ID:

PR20070112-03

Title:

Linker error while building a stand-alone S-function

Last Update: 19 Nov 2007

TargetLink 2.2 2.2.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

Last Update: 13 Jul 2007

TargetLink 2.2 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: The code generation for integrator block aborts with error
E99003 if all of the
following conditions hold:
- 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: Saturation statements might be eleminated even though the

ID:

PR20070118-03

Title:

Variable described as AXIS_PTS as well as as

CHARACTERISTIC in same A2L file

Last Update: 13 Jul 2007

TargetLink 2.2 2.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:
/begin CHARACTERISTIC
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

Last Update: 13 Mar 2007

TargetLink 2.2 2.2.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.
Workaround: No workaround available.

ID:

PR20070118-07

Title:

Ports of subsystems in simulation frames are not connected

Last Update: 13 Mar 2007

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 12 Mar 2007

TargetLink 2.2 2.2.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

PR20070130-04

Title:

Error message if a renamed basetype is selected in the

Relational or Logical Operator block dialog

Last Update: 22 Apr 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:

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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 12 Mar 2007

TargetLink 2.2 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: "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

Last Update: 13 Mar 2007

TargetLink 2.2 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

Last Update: 07 Mar 2007

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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.
Workaround: No workaround available.

ID:

PR20070207-02

Title:

Code generaten aborts using PowerPC TOM with assembler

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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:
Generating simulation frame files ...
*** E90111: INTERNAL ERROR:
*** Internal error. Contact dSPACE technical support.
*** 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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.
Workaround: No workaround available.

998 / 1260

ID:

PR20070208-04

Title:

Option "Use Prefix for AR-Elements" is ignored during export

of AUTOSAR SWC-description files

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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',....).
Workaround: No workaround available.

ID:

PR20070209-02

Title:

Difference between output signal and logged signal if option

"Cast output signal to TargetLink type" is selected

Last Update: 13 Jul 2007

TargetLink 2.2 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
Workaround: No workaround available.

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

Last Update: 13 Mar 2007

TargetLink 2.2 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

Block Explorer

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20070214-04

Title:

Production code for sin/cos with 64/32 bit input and 16 bit
result calculates wrong results

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

1003 / 1260

ID:

PR20070215-06

Title:

Wrong production code may be generated for

addition/subtraction with saturation

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20070215-10

Title:

RTW code generation aborts for Look-Up Table block in

TargetLink Blockset Stand-Alone

Last Update: 16 Aug 2007

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20070220-07

Title:

Wrong number of iterations output by production code for

subsystem containing For/While Iterator Block

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 01 Jul 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:

Inefficient code/code style

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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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 input is 32 bit wide and
- 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

Last Update: 07 Mar 2007

TargetLink 2.2 2.2.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

Last Update: 13 Jul 2007

TargetLink 2.2 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

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.
Workaround: No workaround available.

ID:

PR20070301-16

Title:

Variable definition is omitted, although variable is used as

array index

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 22 Mar 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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

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

Last Update: 17 Jan 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:

Aborted code generation

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

Last Update: 13 Jul 2007

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

Utility

TargetLink subsystem
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
TargetLink subsystem.
- [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

Last Update: 30 Mar 2007

TargetLink 2.2 2.2.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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20070321-03

Title:

Simulink error message (TLDS error: Error -66) may occur during
MIL simulation

Last Update: 13 Jul 2007

TargetLink 2.2 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.
Workaround: No workaround available.

1021 / 1260

ID:

PR20070322-02

Title:

Components of extern structures do not appear in restart

functions

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

ID:

PR20070322-03

Title:

Warnings 15353 ... 15363 may be thrown unnecessarily

Last Update: 20 Apr 2007

TargetLink 2.2 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: 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).
Workaround: No workaround available.

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

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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.
Workaround: No workaround available.

1023 / 1260

ID:

PR20070323-04

Title:

Overflow of partially saturated assignment

Last Update: 13 Jul 2007

TargetLink 2.2 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

following conditions
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.
The generated code will be
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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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
TargetLink Main Dialog
or if the functions is invoked with a model handle as argument.
Workaround: No workaround available.

ID:

PR20070326-02

Title:

Simulation aborts if component of function argument struct is

initialized in init function

codefile property

Last Update: 13 Jul 2007

Aborted code generation

Description: Code generation may abort with an error message E15553 if

all following
conditions hold:
- The TargetLink subsystem contains only extern called
function call triggered
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
TargetLink subsystem
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

Last Update: 06 Aug 2007

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
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:

Incorrect code/compilable

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

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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.
Workaround: No workaround available.

ID:

PR20070416-02

Title:

Erroneous message during autoscaling with simulation ranges

and "inherit properties" active

Last Update: 17 Jul 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 17 Jul 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:

Aborted code generation

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:
Fatal #10007: Internal error. Error code: ExprLocAr93.
Contact dSPACE's
technical support team.
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).

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

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 15 Aug 2007

TargetLink 2.2 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: If an outport of a reused subsystem drives an outport of a

conditionally
subsystem code generation may abort with a fatal error.
Workaround: Follow one of the following suggestions:
- 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

Last Update: 06 Aug 2007

TargetLink 2.2 2.2.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.
Workaround: No workaround available.

ID:

PR20070420-01

Title:

Initializations of variables in restart functions are not

encapsulated with preprocessor directives

Last Update: 07 May 2007

TargetLink 2.2 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: 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

Last Update: 17 Jul 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:

Incorrect code/compilable

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

Last Update: 07 May 2007

TargetLink 2.2 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 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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

Last Update: 13 Jul 2007

TargetLink 2.2 2.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

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

Last Update: 13 Jul 2007

TargetLink 2.2 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: If all of the following conditions are fulfilled wrong code is

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

Last Update: 25 May 2007

TargetLink 2.2 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 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

Last Update: 25 May 2007

TargetLink 2.2 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: 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
range) has occurred.
or
Fatal #10007: Internal error. Error code: ExprLocAr93.
Contact dSPACE's
technical support team.
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

Last Update: 13 Jul 2007

TargetLink 2.2 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.
Workaround: No workaround available.

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

Last Update: 17 Jan 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:

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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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.
Workaround: No workaround available.

1051 / 1260

ID:

PR20070509-14

Title:

CodeSize calculation for HCS12/S12X/Metrowerks does not

count initialized global variables for ROM value

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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.
Workaround: No workaround available.

ID:

PR20070510-12

Title:

Wrong code for Relay block with static output variable and
calibratable on/off values

Last Update: 25 May 2007

TargetLink 2.2 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: 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.
Workaround: Follow one of the following suggestions:
- 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

Last Update: 13 Jul 2007

TargetLink 2.2 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: 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 {
/* # combined # Sink: Subsystem/Sink_out_default */
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)));
/* # combined # Sink: Subsystem/Sink_out_default */
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

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 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

PR20070524-19

Title:

Code genration aborts if an access function is assigned to a

Look-Up Table parameter

Last Update: 05 Jul 2007

TargetLink 2.2 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: Usage of an access function is not allowed for any Look-Up

Table parameter.
This is a limitation of TargetLink.
Workaround: No workaround available.

1060 / 1260

ID:

PR20070524-31

Title:

AUTOSAR export overwrites package files

Last Update: 06 Aug 2007

TargetLink 2.2 2.2.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

Last Update: 13 Mar 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:

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

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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

Last Update: 25 Jun 2007

TargetLink 2.2 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: 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.

Last Update: 13 Jul 2007

Aborted code generation

Description: If you use a variable class with "Scope" = "extern" and

ID:

PR20070619-18

Title:

Missing interface variable in Data Dictionary node

/Subsystems/<tl_subsystem>/<function>

Last Update: 13 Jul 2007

TargetLink 2.2 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

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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

Last Update: 30 Mar 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:

Aborted code generation

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

Last Update: 13 Jul 2007

TargetLink 2.2 2.2.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

Title:

Erroneous setting of typedef properties Description and

IsBaseType after AUTOSAR import

Last Update: 06 Aug 2007

TargetLink 2.2 2.2.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.
Workaround: No workaround available.

ID:

PR20070626-02

Title:

AUTOSAR export creates superfluous COMPU-METHOD

elements

Last Update: 06 Aug 2007

TargetLink 2.2 2.2.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.
Workaround: No workaround available.

1074 / 1260

ID:

PR20070627-01

Title:

Error about unsupported bit operation in Stateflow because of

optimization

Last Update: 05 Jul 2007

TargetLink 2.2 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: 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.

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

Last Update: 06 Aug 2007

TargetLink 2.2 2.2.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

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:

Incorrect code/compilable

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

Last Update: 15 Aug 2007

TargetLink 2.2 2.2.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

Last Update: 19 Nov 2007

TargetLink 2.2 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

Last Update: 02 Nov 2007

TargetLink 2.2 2.2.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

Last Update: 15 Aug 2007

TargetLink 2.2 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

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:

Incorrect code/compilable

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.
Workaround: No workaround available.

ID:

PR20070720-02

Title:

TargetLink Runnable Inport may not open

Last Update: 15 Aug 2007

TargetLink 2.2 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

Last Update: 15 Aug 2007

TargetLink 2.2 2.2.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 */
"" /* LongIdentifier */
/begin LOC_MEASUREMENT
Sa1_sPI /* Identifier */
/end LOC_MEASUREMENT
/begin SUB_FUNCTION
Fcn_Linearization /* Identifier */ <----------------Fcn_Linearization is reffered as subfunction
/end SUB_FUNCTION
/end FUNCTION
/begin FUNCTION
Fcn_Linearization /* Name */
"" /* LongIdentifier */
/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

"" /* LongIdentifier */
/begin LOC_MEASUREMENT
Sa1_sPI /* Identifier */
/end LOC_MEASUREMENT
/end FUNCTION
/begin FUNCTION
Fcn_Linearization /* Name */
"" /* LongIdentifier */
/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
Workaround: No workaround available.

ID:

PR20070724-02

Title:

Measurable actual parameter is missing in A2L file

Last Update: 15 Aug 2007

TargetLink 2.2 2.2.1 2.3 2.3.1 3.0 3.0.1 3.1 3.2 3.3 3.4 3.5
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:

Incorrect code/compilable

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

Last Update: 15 Aug 2007

TargetLink 2.2 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: 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

Last Update: 19 Nov 2007

TargetLink 2.2 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: 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

Last Update: 19 Nov 2007

TargetLink 2.2 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: 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

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:

containing stand-alone S-functions

Last Update: 15 Aug 2007

TargetLink 2.2 2.2.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
Workaround: No workaround available.

ID:

PR20070809-05

Title:

Default mode for XML import has changed since Data

Dictionary 1.4

Last Update: 27 Aug 2007

TargetLink 2.2 2.2.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

PR20070816-02

Title:

Modifying the initial value of a Stateflow object via tl_set

replaces workspace variable name with its value

Last Update: 09 Nov 2007

TargetLink 2.2 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

1103 / 1260

ID:

PR20070823-04

Title:

Wrong error message #17054

Last Update: 19 Nov 2007

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
TargetLink subsystem
5) Rename back the application object

1107 / 1260

ID:

PR20070830-02

Title:

AUTOSAR import of PRIMITIVE-DATATYPE-WITHSEMANTICS

Last Update: 19 Nov 2007

TargetLink 2.2 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: 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

Last Update: 02 Nov 2007

TargetLink 2.2 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: 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

Last Update: 19 Nov 2007

TargetLink 2.2 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: 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

Last Update: 12 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:

Incorrect code/compilable

Description: If all of the following conditions are fulfilled wrong code is

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".
Workaround: No workaround available.

1113 / 1260

ID:

PR20070918-04

Title:

Wrong Unit specification in Data Dictionary templates files

Last Update: 19 Nov 2007

TargetLink 2.2 2.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

Last Update: 09 Nov 2007

TargetLink 2.2 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:
??? Index exceeds matrix dimensions.
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

Last Update: 02 Nov 2007

TargetLink 2.2 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: 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

Last Update: 09 Nov 2007

TargetLink 2.2 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 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

Last Update: 19 Nov 2007

TargetLink 2.2 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
Workaround: No workaround available.

ID:

PR20070921-02

Title:

Code generation may abort due to unconnected Stateflow

function call trigger outport

Last Update: 02 Nov 2007

TargetLink 2.2 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: There may occur an internal error during code generation:

Fatal #10007: Internal error. Error code:
TlCChartDDStructParamPreparator692.
Contact dSPACE's technical support team.
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

Last Update: 19 Nov 2007

TargetLink 2.2 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

Last Update: 19 Nov 2007

TargetLink 2.2 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: 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

Last Update: 10 Oct 2007

TargetLink 2.2 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: 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

Last Update: 19 Nov 2007

TargetLink 2.2 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.
Workaround: No workaround available.

1122 / 1260

ID:

PR20070928-08

Title:

Preprocessor directive in custom code file may be wrapped

wrongly in production code

Last Update: 19 Nov 2007

TargetLink 2.2 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: 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

Last Update: 19 Nov 2007

TargetLink 2.2 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: 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

Last Update: 19 Nov 2007

TargetLink 2.2 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: 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 = ...;
...
}
Workaround: No workaround available.

1125 / 1260

ID:

PR20071002-03

Title:

Missing connections after Simulink to TargetLink if Simulink

Inport is rotated up

Last Update: 09 Nov 2007

TargetLink 2.2 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

Last Update: 09 Nov 2007

TargetLink 2.2 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: If all of the following conditions are fulfilled wrong code is

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

Last Update: 09 Nov 2007

TargetLink 2.2 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: If all of the following conditions are fulfilled wrong code is

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

Last Update: 02 Nov 2007

TargetLink 2.2 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

Description: An overflow may occur for positive max value in a relational

operation, if the
following conditions hold:
- 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.

ID:

PR20071030-02

Title:

Data Dictionary Merge Explorer does not consider Data

Dictionary include files

Last Update: 19 Nov 2007

TargetLink 2.2 2.2.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.
Workaround: No workaround available.

1134 / 1260

ID:

PR20071030-05

Title:

Wrong expansion of name macros $f and $F in declaration

statement of variable class

Last Update: 19 Nov 2007

TargetLink 2.2 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: 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:

Incorrect code/compilable

Description: If all of the following conditions are fulfilled wrong code is

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

Last Update: 11 Jan 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:

Aborted code generation

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

Last Update: 11 Jan 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: 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

Last Update: 11 Jan 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:

Inefficient code/code style

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.
Workaround: No workaround available.

1140 / 1260

ID:

PR20071114-29

Title:

Conversion fails if a converted block modifies the block name during mask
initialization

Last Update: 11 Jan 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:

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:
??? Error using ==> get_param
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

Last Update: 13 Mar 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:

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:
The eval command in tl_get_compiled data failed. See
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

Last Update: 28 Mar 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: 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

Last Update: 11 Jan 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:

Aborted code generation

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

Last Update: 11 Jan 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:

Incorrect code/compilable

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

Last Update: 11 Jan 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: 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.
Workaround: No workaround available.

1145 / 1260

ID:

PR20071120-03

Title:

Misleading error #03051 for Constant block after conversion

Last Update: 11 Jan 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: 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

Last Update: 11 Jan 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:

Incorrect code/compilable

Description: If all of the following conditions are fulfilled wrong code is

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

Last Update: 13 Mar 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:

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);
Workaround: No workaround available.

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

Last Update: 28 Mar 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:

Incorrect code/compilable

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.
Workaround: No workaround available.

1148 / 1260

ID:

PR20071120-10

Title:

Export of AUTOSAR subpackages fails

Last Update: 28 Mar 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: 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

Last Update: 11 Jan 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:

Aborted code generation

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

Last Update: 13 Mar 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:

Inefficient code/code style

Description: If loop generation is activated (default), no loop for a Rate

Limiter block is
generated, independent of the option "LoopUnrollThreshold".
Workaround: No workaround available.

ID:

PR20071122-12

Title:

Modification of the target source directory within a

pre_codegen_hook has not effect

Last Update: 11 Jan 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: 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

Last Update: 13 Mar 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:

Inefficient code/code style

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[1] = Sa1_a[1];
Sa1_Selector_a[2] = Sa1_a[2];
Sa1_Selector_a[3] = Sa1_a[3];
Sa1_Selector_a[4] = Sa1_a[4];
Sa1_Selector_a[5] = Sa1_b[0];
Sa1_Selector_a[6] = Sa1_b[1];
Sa1_Selector_a[7] = Sa1_b[2];
Sa1_Selector_a[8] = Sa1_b[3];
Sa1_Selector_a[9] = Sa1_b[4];
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

Last Update: 28 Mar 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:

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

Last Update: 11 Jan 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:

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.
Workaround: No workaround available.

1152 / 1260

ID:

PR20071128-02

Title:

Last Update: 13 Mar 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:

Inefficient code/code style

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:
for (Aux_S32 = 3; Aux_S32 <= 8; (Aux_S32)++)
{
/* Gain: Subsystem/Gain [3..8] : folded operation multiplication
to
constant value 0.5 */
Sa1_Gain[Aux_S32] = 0.5F;
}
Workaround: No workaround available.

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

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: 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

Last Update: 13 Mar 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: 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.
The problem is fixed by using the following patch or later
patches:
TargetLink 2.3.1p7

ID:

PR20071206-13

Title:

RTF documentation generation using tldoc_rtf may fail

Last Update: 28 Mar 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: 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).
Workaround: No workaround available.

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

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:

Aborted code generation

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

Last Update: 13 Mar 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:

Incorrect code/compilable

Description: If all of the following conditions are fulfilled wrong code is

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

Last Update: 13 Mar 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:

Incorrect code/compilable

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

Last Update: 14 Mar 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 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
workaround available.

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

Last Update: 13 Mar 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:

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

Last Update: 13 Mar 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:

Incorrect code/not compilable

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

Last Update: 28 Mar 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:

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.
Workaround: No workaround available.

1169 / 1260

ID:

PR20080103-02

Title:

Wrong input overflow warning due to not synchronized

constrained range limits of referenced Data Dictionary variable

Last Update: 13 Mar 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: 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

Last Update: 28 Mar 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 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

Last Update: 28 Mar 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:

Aborted code generation

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

Last Update: 13 Mar 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: 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); */
TL_CODE_COVERAGE(a, 3);
Sa1_Merge = (Int16) (Sa1_InPort << 1);
}
else {
/* TL_CODE_COVERAGE(a, 4); */
TL_CODE_COVERAGE(a, 4);
Sa1_Merge = (Int16) (Sa1_InPort << 1);
}
#else
Sa1_Merge = (Int16) (((UInt16) Sa1_InPort) + ((UInt16)
Sa1_InPort2));
#endif
if (Sa1_Constant1) {
/* TL_CODE_COVERAGE(a, 6); */
TL_CODE_COVERAGE(a, 6);
The last coverage macro shows a count of 6, but it should be
4, because coverage
macro number 2 and 5 are missing.
Workaround: No workaround available.

1174 / 1260

ID:

PR20080117-07

Title:

Wrong line connection after Simulink to TargetLink conversion

Last Update: 28 Mar 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:

Incorrect code/compilable

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

Last Update: 14 Mar 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: 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

Last Update: 13 Mar 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:

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

Last Update: 13 Mar 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:

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

Last Update: 13 Mar 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:

Incorrect code/compilable

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

Last Update: 13 Mar 2008

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:

Incorrect code/compilable

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

Last Update: 28 Mar 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 AUTOSAR import does not create any

EventReceiverComSpec objects.
EVENT-RECEIVER-COM-SPEC elements are not transferred
to the Data Dictionary.
Workaround: No workaround available.

ID:

PR20080124-08

Title:

Missing optimization in index access of vector component

Last Update: 28 Mar 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:

Inefficient code/code style

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

Last Update: 28 Mar 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:

Inefficient code/code style

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

Last Update: 13 Mar 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: 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

Last Update: 13 Mar 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:

Incorrect code/compilable

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:

Erroneous movement of code into conditionally executed

control flow branch

Last Update: 28 Mar 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:

Incorrect code/compilable

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

Last Update: 13 Mar 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:

Modelling

Description: A superfluous warning about division by zero protection is

issued if the
following conditions hold:
- 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

Last Update: 13 Mar 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:

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

Last Update: 14 Mar 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:

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
Workaround: No workaround available.

1187 / 1260

ID:

PR20080207-09

Title:

Comment in production code for Assignment block may

contain wrong index values

Last Update: 13 Mar 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:

Inefficient code/code style

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:
for (Aux_S32 = 9; Aux_S32 <= 14; (Aux_S32)++)
{
/* 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] */
Workaround: No workaround available.

ID:

PR20080213-03

Title:

Error during RTF documentation generation

Last Update: 28 Mar 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: 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

Last Update: 14 Mar 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: The logged signal data of a Stateflow machine variable is

1193 / 1260

ID:

PR20080222-03

Title:

Frame generation for a subsystem may fail

Last Update: 14 Mar 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:

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:
*** The specified object does not exist.
*** 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

Last Update: 14 Mar 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: 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(...);
Workaround: No workaround available.

1195 / 1260

ID:

PR20080225-01

Title:

Initialization error due to adverse initialization order of bus

capable blocks

Last Update: 28 Mar 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:

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

Last Update: 28 Mar 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:

Incorrect code/not compilable

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

Last Update: 13 Mar 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:

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

Last Update: 28 Mar 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:

Aborted code generation

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

Last Update: 28 Mar 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:

Inefficient code/code style

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

Last Update: 13 Mar 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: 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

Last Update: 28 Mar 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: 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

Last Update: 01 Apr 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:

Aborted code generation

Description: Due to a limitation a variable of a Custom Code block is not

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

1210 / 1260

ID:

PR20080402-12

Title:

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-INTERNAL-TO-PHYS>
<COMPU-SCALES>
<COMPU-SCALE>
<COMPU-RATIONAL-COEFFS>
<COMPU-NUMERATOR>
<V>-80</V>
<V>1</V>
</COMPU-NUMERATOR>
<COMPU-DENOMINATOR>
<V>2</V>
</COMPU-DENOMINATOR>
</COMPU-RATIONAL-COEFFS>
</COMPU-SCALE>
</COMPU-SCALES>
</COMPU-INTERNAL-TO-PHYS>
</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>
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">0</LOWERLIMIT>
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">255</UPPERLIMIT>
</INTEGER-TYPE>
Workaround: No workaround available.

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

Last Update: 17 Jul 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: 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

Last Update: 17 Jul 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:

Incorrect code/compilable

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.
Workaround: No workaround available.

1220 / 1260

ID:

PR20080422-13

Title:

Failure during generation of Simulink model using tl_generate_swc_model.m

Last Update: 17 Jul 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: 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:
??? Error using ==> get_param
block_diagram does not have a parameter named 'Position'.
Error in ==> tl_generate_swc_model>FcnReplaceTlSubsystem at 1528
destPosition = get_param(destSubsystem, 'Position');
Error in ==> tl_generate_swc_model at 468
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

Last Update: 27 Jun 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:

Inefficient code/code style

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.
Workaround: No workaround available.

1222 / 1260

ID:

PR20080507-03

Title:

Displayed scaling beneath block icon may not be up to date

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:

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.
Workaround: No workaround available.

1223 / 1260

ID:

PR20080507-12

Title:

Optimization removes preprocessor if branch in Stateflow

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:

Incorrect code/compilable

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

Last Update: 30 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:

Inefficient code/code style

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
The generated code will be
if (M || C) {
A;
}
instead of
#if M
A;
#else
if (C) {
A;
}
#endif
2. Sequential transitions
----->O---------->O---------->O----------->
[M] [C] { A; }
The generated code will be
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

Last Update: 17 Jul 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:

Incorrect code/not compilable

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

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: 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

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 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

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:

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.
The problem is fixed by using the following patch or later
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

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:

Incorrect code/compilable

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

Last Update: 17 Jul 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 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

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:

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

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:

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.
Workaround: No workaround available.

ID:

PR20080519-13

Title:

State variables with scope ref_param are not re-initialized

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:

Incorrect code/compilable

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
- Discrete State-Space
- Discrete-Time Integrator
- Custom Code
- Discrete Transfer Function
- Discrete Filter
- Unit Delay Reset Enabled
- 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

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:

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

Last Update: 17 Jul 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:

Incorrect code/compilable

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

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:

Inefficient code/code style

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

Last Update: 17 Jul 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:

Incorrect code/compilable

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

Last Update: 17 Jul 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: 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)".
Workaround: No workaround available.

ID:

PR20080529-20

Title:

Build host fails due to missing log macro definition

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:

Incorrect code/not compilable

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

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:

Incorrect code/compilable

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

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:

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

Last Update: 11 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:

Incorrect code/compilable

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

Last Update: 17 Jul 2008

PR20080609-04

Title:

Incorrect description of Interpolation and Index Search block

combination in generated A2L file

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: 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.
Workaround: No workaround available.

1243 / 1260

ID:

PR20080610-01

Title:

Code generation may abort with fatal #10007: Internal error.

Error code: TlCVectorSignalSliceDescription 189.

Last Update: 17 Jul 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:

Aborted code generation

Description: A Stateflow chart with vector inputs or outputs whose widths

are different may
lead to
Fatal #10007: Internal error. Error code:
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:

Inefficient code/code style

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

Incorrect code/compilable

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

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:

Incorrect code/compilable

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

Last Update: 17 Jul 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:

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

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: 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

Last Update: 17 Jul 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:

Incorrect code/compilable

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.
Workaround: No workaround available.
The problem is fixed by using the following patch or later
patches:
TargetLink 3.0.1p1

ID:

PR20080707-03

Title:

Code generation for referenced model may fail with interface

validation error

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:

Aborted code generation

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

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 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

HiL Testing Questions
100% (1)
HiL Testing Questions
1 page
UDS Protocol - PPT
No ratings yet
UDS Protocol - PPT
46 pages
Interview Questions & Answers
100% (1)
Interview Questions & Answers
8 pages
Accenture Dot Net Interview Questions
100% (2)
Accenture Dot Net Interview Questions
13 pages
Data Driven System Engineering: Automotive ECU Development
From Everand
Data Driven System Engineering: Automotive ECU Development
James Wen
No ratings yet
CANoe QuickStartGuide PDF
100% (1)
CANoe QuickStartGuide PDF
80 pages
TargetLink - 3.3 - Model Description
No ratings yet
TargetLink - 3.3 - Model Description
48 pages
Ecu Test
100% (1)
Ecu Test
3 pages
SDA SW Block Description
No ratings yet
SDA SW Block Description
149 pages
Com Stack Configuration PDF
100% (1)
Com Stack Configuration PDF
99 pages
AUTOSAR and Functional Safety PDF
No ratings yet
AUTOSAR and Functional Safety PDF
26 pages
CANoe Manual en
No ratings yet
CANoe Manual en
209 pages
CANoe ProductInformation en
75% (4)
CANoe ProductInformation en
43 pages
ISO 26262 Complete Self-Assessment Guide
From Everand
ISO 26262 Complete Self-Assessment Guide
Gerardus Blokdyk
3/5 (2)
Automotive Embedded Systems Complete Self-Assessment Guide
From Everand
Automotive Embedded Systems Complete Self-Assessment Guide
Gerardus Blokdyk
2/5 (1)
Bosch Plena Amplifier Datasheet
No ratings yet
Bosch Plena Amplifier Datasheet
3 pages
TargetLink Product-Information
No ratings yet
TargetLink Product-Information
48 pages
Simulink Coder 8.0: Generate C and C++ Code From Simulink and Stateflow Models
No ratings yet
Simulink Coder 8.0: Generate C and C++ Code From Simulink and Stateflow Models
6 pages
MATLAB Questions
No ratings yet
MATLAB Questions
17 pages
Simulink-Targetlink Datatypes Defnt Problem
No ratings yet
Simulink-Targetlink Datatypes Defnt Problem
16 pages
Autosar Notes
No ratings yet
Autosar Notes
25 pages
Stateflow: What Is Stateflow Examples Extended Uses Semantics and Problems
No ratings yet
Stateflow: What Is Stateflow Examples Extended Uses Semantics and Problems
36 pages
Sample Responsibilties of HIL Test ENgineer
0% (1)
Sample Responsibilties of HIL Test ENgineer
1 page
Update UDS - FLASH
No ratings yet
Update UDS - FLASH
2 pages
VTESTstudio ConceptManual en
67% (3)
VTESTstudio ConceptManual en
48 pages
AUTOSAR Diagnostic
No ratings yet
AUTOSAR Diagnostic
28 pages
Comprehensive Workflow For Autosar Classic and Adaptive Using Model Based Design
No ratings yet
Comprehensive Workflow For Autosar Classic and Adaptive Using Model Based Design
45 pages
HIL Testing of ADAS Features
No ratings yet
HIL Testing of ADAS Features
4 pages
Mil Sil Pil Hil
0% (1)
Mil Sil Pil Hil
6 pages
Function Calls EcuM
No ratings yet
Function Calls EcuM
13 pages
CANoe Basic Training
No ratings yet
CANoe Basic Training
33 pages
Autosar Sws Candriver
No ratings yet
Autosar Sws Candriver
110 pages
Overview of MIL, SIL, HIL, Testing Theories & Coverage Metrics
No ratings yet
Overview of MIL, SIL, HIL, Testing Theories & Coverage Metrics
10 pages
Compiler (Very Imp.)
No ratings yet
Compiler (Very Imp.)
10 pages
Cap L Function Reference Manual
100% (1)
Cap L Function Reference Manual
179 pages
Hardware in The Loop Simulator
No ratings yet
Hardware in The Loop Simulator
40 pages
Vector Safety Solution
No ratings yet
Vector Safety Solution
53 pages
Implementing Bootloaders On Renesas MCUs
No ratings yet
Implementing Bootloaders On Renesas MCUs
37 pages
Dspace-Paper Hil Overview Waeltermann e 160405 PDF
No ratings yet
Dspace-Paper Hil Overview Waeltermann e 160405 PDF
14 pages
Uds - Iso14229-1
No ratings yet
Uds - Iso14229-1
15 pages
CANdb Manual EN
No ratings yet
CANdb Manual EN
32 pages
CAN Questions
100% (2)
CAN Questions
4 pages
Interview Questions-1
100% (2)
Interview Questions-1
41 pages
GWM Interview Questions
No ratings yet
GWM Interview Questions
1 page
CANoe ProductInformation EN
No ratings yet
CANoe ProductInformation EN
57 pages
UDS Protocol Implementation in Automotiv PDF
No ratings yet
UDS Protocol Implementation in Automotiv PDF
6 pages
Capl
No ratings yet
Capl
4 pages
Vector Webinar AUTOSAR Testing 20111115 en
100% (1)
Vector Webinar AUTOSAR Testing 20111115 en
32 pages
Ramu Resume IVI Test Engineer
100% (1)
Ramu Resume IVI Test Engineer
2 pages
2011 - A HiL Test Bench For Verification and Validation Purposes of Model-Based Developed Applications Using Simulink and OPC DA Technology PDF
No ratings yet
2011 - A HiL Test Bench For Verification and Validation Purposes of Model-Based Developed Applications Using Simulink and OPC DA Technology PDF
6 pages
CANape Basics WhitePaper en
0% (1)
CANape Basics WhitePaper en
15 pages
AUTOSAR LayeredSoftwareArchitecture
No ratings yet
AUTOSAR LayeredSoftwareArchitecture
46 pages
DOCU-738 - Integration of Cyclic BSW Mainfunctions
No ratings yet
DOCU-738 - Integration of Cyclic BSW Mainfunctions
36 pages
AUTOSAR Guide Book by ANCIT
No ratings yet
AUTOSAR Guide Book by ANCIT
18 pages
Diagnostic Communication Manager Module in AUTOSAR
100% (1)
Diagnostic Communication Manager Module in AUTOSAR
7 pages
Model Based Testing
No ratings yet
Model Based Testing
43 pages
CAN Canalyser Manual
No ratings yet
CAN Canalyser Manual
155 pages
CAN Interview Questions 1703996791
No ratings yet
CAN Interview Questions 1703996791
13 pages
Unified Diagnostics Services Is The Diagnostics Communication Protocol in The ECU
No ratings yet
Unified Diagnostics Services Is The Diagnostics Communication Protocol in The ECU
6 pages
Autosar Basics
100% (1)
Autosar Basics
13 pages
Autosar PPT
100% (1)
Autosar PPT
10 pages
AUTOSAR Complete Self-Assessment Guide
From Everand
AUTOSAR Complete Self-Assessment Guide
Gerardus Blokdyk
3/5 (2)
C# in A Nutshell - Code Listings - 4
No ratings yet
C# in A Nutshell - Code Listings - 4
4 pages
IR Sensor PDF
No ratings yet
IR Sensor PDF
4 pages
Instruction Set and Assembler Directives
No ratings yet
Instruction Set and Assembler Directives
19 pages
Quick Charge Device List
No ratings yet
Quick Charge Device List
23 pages
Mall Managent and Security
No ratings yet
Mall Managent and Security
20 pages
Gen Diff Protpdf
No ratings yet
Gen Diff Protpdf
55 pages
13-POWER DIVIDERS CIRCULATORS-07-Aug-2019Material - I - 07-Aug-2019 - Lecture - 15 - Power - Dividers - Part-1
No ratings yet
13-POWER DIVIDERS CIRCULATORS-07-Aug-2019Material - I - 07-Aug-2019 - Lecture - 15 - Power - Dividers - Part-1
31 pages
Eoffice User Reference Guide
No ratings yet
Eoffice User Reference Guide
62 pages
Philips Chassis-L01.1uac
No ratings yet
Philips Chassis-L01.1uac
24 pages
Arcserve® Backup Patch Manager For Windows: User Guide
No ratings yet
Arcserve® Backup Patch Manager For Windows: User Guide
77 pages
DS_AP530Series-unlocked
No ratings yet
DS_AP530Series-unlocked
10 pages
Networks
No ratings yet
Networks
31 pages
ch16 High Performance PDF
No ratings yet
ch16 High Performance PDF
22 pages
Advanced Power Electronics Corp.: N-Channel Enhancement-Mode Power MOSFET
No ratings yet
Advanced Power Electronics Corp.: N-Channel Enhancement-Mode Power MOSFET
6 pages
Swift Level 1
No ratings yet
Swift Level 1
49 pages
Lesson 7 Networking Devices
No ratings yet
Lesson 7 Networking Devices
4 pages
Starting and Stopping SAP HANA
No ratings yet
Starting and Stopping SAP HANA
2 pages
Micom Alstom P342, P343, P344, P345 & P391: Generator Protection Relay
No ratings yet
Micom Alstom P342, P343, P344, P345 & P391: Generator Protection Relay
66 pages
G9SE Brochure
No ratings yet
G9SE Brochure
9 pages
operating system notes class 10
100% (1)
operating system notes class 10
2 pages
Cen Wandl Patch Update Poa
No ratings yet
Cen Wandl Patch Update Poa
3 pages
Class 3 - REVISION ASSIGNMENT - PT-1
No ratings yet
Class 3 - REVISION ASSIGNMENT - PT-1
3 pages
Cs304: Game Programming: Lecture: Guis, Menus
No ratings yet
Cs304: Game Programming: Lecture: Guis, Menus
27 pages
1 - Basics of Erp, Sap, Abap
No ratings yet
1 - Basics of Erp, Sap, Abap
71 pages
CV Odorovic
No ratings yet
CV Odorovic
4 pages
Audiocodes Mediant800 V6 4 SAS OmniPCXEnterpriseR10 1 IWR
No ratings yet
Audiocodes Mediant800 V6 4 SAS OmniPCXEnterpriseR10 1 IWR
98 pages
Light Grid Data Sheet
No ratings yet
Light Grid Data Sheet
4 pages
DF A0114 Version 1.4
No ratings yet
DF A0114 Version 1.4
3 pages