Release Note Developer Software

®
OpenECU Developer Software

Installation and Release Note
Release 2.8.0 (r2019-1)
Copyright © 2019 Pi Innovo

Table of Contents
1. Release details ...................................................................................................... 1
1.1. Introduction ................................................................................................. 1
1.2. Summary of releases ................................................................................... 1
2. Installation ............................................................................................................ 11
2.1. Introduction ............................................................................................... 11
2.1.1. Third party tool requirements ........................................................... 11
2.1.2. Third party tool requirements — C-API ............................................. 11
2.1.3. Third party tool requirements — Simulink-API ................................... 12
2.1.4. Third party tool requirements — installation ...................................... 12
2.1.5. Third party tool requirements — compatibility .................................... 13
2.2. Installing OpenECU ................................................................................... 15
2.3. License setup ............................................................................................ 22
2.3.1. Floating license ............................................................................... 22
2.3.2. Node-locked license ........................................................................ 24
2.4. Removing OpenECU ................................................................................. 24
2.5. Integration notes for third party tools ........................................................... 25
2.5.1. Microsoft Windows 10 ..................................................................... 25
2.5.2. Microsoft Windows 7 ....................................................................... 25
2.5.3. Microsoft Windows XP .................................................................... 26
2.5.4. MATLAB ......................................................................................... 26
2.5.5. PiSnoop ......................................................................................... 27
2.5.6. ATI Vision ...................................................................................... 27
2.5.7. ETAS INCA calibration tool .............................................................. 28
2.5.8. Vector CANape ............................................................................... 29
2.5.9. Wind River (Diab) C Compiler v5.5.1.0 ............................................. 29
2.5.10. Wind River (Diab) C Compiler v5.8.0.0 ........................................... 31
2.5.11. Wind River (Diab) C Compiler v5.9.0.0 ........................................... 31
2.5.12. GCC Compiler v4.7.3 .................................................................... 32
2.5.13. Python .......................................................................................... 33
3. Change log .......................................................................................................... 35
3.1. Feature sets .............................................................................................. 35
3.2. Version numbering ..................................................................................... 35
3.3. Product marked as deprecated or end-of-life ............................................... 36
3.3.1. Deprecated items ............................................................................ 36
3.3.2. End-of-life items .............................................................................. 38
A. Contact information ............................................................................................ 366
Copyright 2019, Pi Innovo ii

Chapter 1. Release details
1.1. Introduction ......................................................................................................... 1
1.2. Summary of releases ........................................................................................... 1
This document details generic release version 2.8.0 (r2019-1) of the OpenECU developer
software and related tools, created on 15-Jan-2019. Some changes may not be backwards
compatible with older versions; please review the release notes to determine if there are
enhancements, bugs, or compatibility considerations in this release that impact you.
1.1. Introduction
This document is split into sections which detail how to install OpenECU, integrate OpenECU
with supporting tools, what changes have been made to OpenECU software, and how to
contact OpenECU technical support.
• Procedural steps to install the OpenECU software are given in the Installation section.
Review the installation steps to become familiar with the options available when OpenECU
is installed. In some cases, it is beneficial to have installed other packages before
OpenECU but this is not essential. Integration with other software packages is described
next.
• Integration with various third party applications supplied by other companies are detailed
in the Third party tools requirements and Integration notes for third party tools section.
Review the integration notes to become familiar with what tools OpenECU requires and
how OpenECU integrates and uses these tools. In some cases, you must change the
environment or tools before using OpenECU.
• A detailed change log to each release version of the OpenECU developer software is given
in the Change log section. A summary of each release is given in the Summary of releases
section.
Review the release notes to determine if there are enhancements, bugs, or compatibility
considerations in this release that impact you.
If you are upgrading from a software version other than the most recent one, review the
current release notes and all interim versions. For example, when you upgrade from v1.2
to v1.4, review the release notes for v1.3 and v1.4.
• A full User Guide and associated set of help files are installed as part of this install package
and can be accessed through Window's Start Menu, via an HTML browser or through the
MATLAB help browser.
• If you find an issue with OpenECU or require technical support, contact details can be
found in the Contact information section.
1.2. Summary of releases

This table provides quick access to what's new and changed in each version of OpenECU.
Release
The version, and sometimes name, assigned to the release. A
description of version numbering is given in the Version numbering
section.
Copyright 2019, Pi Innovo 1

Release details
New Features
New features introduced by this version, or significant changes to
existing features. New features are grouped into similar functional areas
making it easier to find related changes.
Fixes and Improvements

Fixes or improvements to existing features with details of why they were
previously wrong. As with new features, fixes and improvements are
similarily grouped into functional area.
Backwards compatible
Whether the changes in the release retain backwards compatibility
with the immediately prior release. If the release is not backwards
compatible, review the changes which affect backward compatibility to
determine if the release affects your application.
Firmware upgrade
Whether there is a change in the release which might require a firmware
upgrade. The firmware of the ECU makes up the boot, reprogramming
and, in some cases, other permanently resident functionality of the ECU.
If the release indicates the need for for a firmware upgrade, review the
changes which affect the firmware to determine if the new or changed
features affect you.
Table 1.1. Summary of releases

Release New features Fixes and improvements Backwards Firmware
compatible upgrade
2.8.0 Application programming Application programming No Yes
(r2019-1) interface [41] interface [41],
Calibration [42],
Code generation [42],
Communications [43],
User
documentation [47],
Input/output
drivers [44],
Target ECU [46]
2.7.0 User Application programming No Yes
(r2017-1) documentation [53], interface [54],
Input/output Code generation [54],
drivers [52], Communications [55],
Third party tool Diagnostics
support [53] (communications and fault
handling) [56],
User
documentation [59],
Examples [56],
Input/output
drivers [56],
Target ECU [58],
Third party tool
support [58]
(r2016-1) interface [60], interface [63],
Calibration [61], Calibration [64],
Communications [61], Code generation [65],

Release details

compatible upgrade
User Diagnostics
documentation [63], (communications and fault
Input/output handling) [67],
drivers [61], User
Target ECU [63], documentation [69],
Third party tool Input/output
support [63] drivers [67],
Target ECU [69]
Code generation [72], Calibration [76],
User Code generation [76],
documentation [75], Diagnostics
Examples [73], (communications and fault
Installation [73], handling) [77],
Input/output User
drivers [73], documentation [79],
Real-time operating Examples [77],
system [73], Input/output
Target ECU [74], drivers [78],
Third party tool Target ECU [78],
support [75] Third party tool
support [79]
2.4.1 Input/output drivers [81] Application programming Yes Yes
(r2015-1- interface [82],
sp1) Code generation [82],
Firmware (boot and
reprogramming) [83],
Input/output drivers [83]
Diagnostics Calibration [97],
(communications and fault Code generation [97],
handling) [86], Communications [98],
User Developer and
documentation [94], supporting scripts/
Firmware (boot and documentation [98],
reprogramming) [88], Diagnostics
Installation [91], (communications and fault
drivers [88], User
Target ECU [91], documentation [103],
Third party tool Examples [100],
support [93] Firmware (boot and
Input/output
drivers [101],
Non-volatile
storage [102],
Real-time operating
system [103],
Third party tool
support [103]

Release details

compatible upgrade
Code generation [105], Code generation [111],
Developer and Developer and
supporting scripts/ supporting scripts/
documentation [107], documentation [111],
Diagnostics Diagnostics
(communications and fault (communications and fault
handling) [107], handling) [112],
User User
documentation [109], documentation [118],
Firmware (boot and Examples [114],
reprogramming) [109], Installation [116],
Installation [109] Input/output
drivers [114],
Non-volatile
storage [116],
Real-time operating
system [117],
Target ECU [117]
Communications [124], Communications [134],
Desktop Diagnostics
integration [125], (communications and fault
Diagnostics handling) [136],
(communications and fault User
handling) [125], documentation [139],
User Firmware (boot and
documentation [130], reprogramming) [137]
Examples [127],
Firmware (boot and
Target ECU [128]
Diagnostics Communications [156],
(communications and fault Diagnostics
handling) [145], (communications and fault
User handling) [156],
documentation [150], User
Installation [150], documentation [166],
Input/output Examples [158],
drivers [145], Firmware (boot and
Target ECU [150] reprogramming) [159],
Installation [166],
Input/output
drivers [160],
Target ECU [166]

Release details

compatible upgrade
Desktop Calibration [174],
integration [169], Code generation [175],
User Communications [176],
documentation [171], Desktop
Examples [170], integration [176],
Target ECU [171] Developer and
supporting scripts/
documentation [176],
Diagnostics
(communications and fault
handling) [176],
User
documentation [184],
Firmware (boot and
Installation [182],
Input/output
drivers [179],
Non-volatile
storage [182],
Target ECU [183]
1.9.2 Target ECU [186] Calibration [186], No Yes
Diagnostics
(communications and fault
handling) [188],
Input/output
drivers [188],
Non-volatile
storage [189],
Target ECU [189]
interface [190], interface [196],
Communications [191], Calibration [196],
Diagnostics Code generation [197],
(communications and fault Communications [197],
handling) [191], Diagnostics
Input/output (communications and fault
drivers [195], handling) [198],
Target ECU [195] Firmware (boot and
Input/output
drivers [203],
Target ECU [203]
Desktop
integration [210],

Release details

compatible upgrade
Diagnostics Developer and
(communications and fault supporting scripts/
handling) [210], documentation [227],
Firmware (boot and Diagnostics
reprogramming) [215], (communications and fault
drivers [218], User
Non-volatile documentation [238],
storage [221], Examples [233],
Target ECU [222] Firmware (boot and
Installation [236],
Input/output
drivers [235],
Target ECU [237]
1.8.6 No Input/output drivers [238] Yes No
1.8.5 Application programming Application programming No No
Calibration [239], Code generation [240],
(communications and fault Input/output drivers [241]
handling) [239],
1.8.4 Communications [242] Application programming Yes Yes
interface [243]
Diagnostics Calibration [250],
(communications and fault Code generation [251],
handling) [245], Communications [251],
Firmware (boot and Input/output
reprogramming) [245], drivers [252],
Input/output Real-time operating
drivers [247], system [253],
Real-time operating Target ECU [254]
system [248],
Target ECU [248]
interface [255] interface [256],
Input/output
drivers [257],
Non-volatile
storage [258],
Target ECU [258]
Code generation [261], Calibration [265],
Input/output Examples [266],
drivers [263], Input/output
drivers [266],

Release details

compatible upgrade
Real-time operating Target ECU [267]
system [263],
Target ECU [264]
1.8.0 Application programming Calibration [270], No No
interface [267], Code generation [271],
Target ECU [268] Examples [271],
Target ECU [272]
1.7.5 Application programming Code generation [274], No No
interface [272], Communications [275],
Input/output drivers [274] Non-volatile
storage [275]
1.7.4 Target ECU [276] No Yes No
Target ECU [278] Calibration [279],
Examples [280],
1.7.2 No No Yes No
interface [281] interface [282],
Target ECU [282]
1.7.0 Calibration [283], Communications [284], Yes No
Input/output Input/output drivers [285]
drivers [283],
Target ECU [284]
1.6.4 Code generation [286] Calibration [286], Yes Yes
Input/output
drivers [287],
Target ECU [288]
1.6.3 No Input/output No No
drivers [289],
Memory emulation [289],
Target ECU [289]
1.6.2 Communications [290], Calibration [292], No Yes
(communications and fault Examples [293],
handling) [291] Installation [294],
Input/output
drivers [294],
Non-volatile
storage [294],
Target ECU [295]
1.6.1 Target ECU [296] Application programming Yes Yes
interface [296],
Target ECU [297]
1.5.9 No Application programming Yes No
interface [298],

Release details

compatible upgrade
Calibration [298],
Examples [299],
Memory emulation [300],
Target ECU [300]
interface [300],
Installation [301],
1.5.7 No Calibration [301] Yes No
interface [302],
1.5.5 No Non-volatile Yes No
storage [303]
1.5.4 Memory emulation [303] Calibration [304], Yes No
Installation [304],
Target ECU [305]
1.5.3 No Calibration [305], Yes No
Communications [305]
1.5.2 No Communications [306] Yes No
1.5.13 Calibration [307], Application programming No Yes
Code generation [307], interface [309],
Communications [307], Calibration [309],
Input/output Communications [310],
drivers [308], Input/output
Non-volatile drivers [311],
storage [308] Memory emulation [312],
Non-volatile
storage [312],
Target ECU [313]
interface [314],
Installation [314],
Target ECU [315]
1.5.11 No Non-volatile Yes No
storage [315]
1.5.10 Calibration [316], Application programming Yes No
Code generation [317], interface [318],
Examples [317], Calibration [319],
Target ECU [318] Code generation [320],
Installation [321],
Input/output
drivers [320],
Target ECU [321]
1.5.1 No Communications [322] Yes No

Release details

compatible upgrade
Communications [327], Code generation [331],
Installation [328], Communications [332],
Input/output drivers [327] Examples [333],
Input/output
drivers [333],
Non-volatile
storage [334],
Target ECU [334]
1.4.0 Application programming Application programming Yes No
Input/output Input/output drivers [339]
drivers [337],
Non-volatile
storage [337]
1.3.1 No Calibration [340], Yes No
Installation [341]
1.3.0 Application programming Input/output drivers [342] Yes No
interface [341]
1.2.0 Application programming Calibration [343], Yes No
interface [342], Code generation [343],
Code generation [342], Examples [344],
Target ECU [343] Input/output drivers [344]
1.1.0 Calibration [344], Application programming Yes Yes
Communications [345], interface [346],
Examples [345] Calibration [346],
1.0.9 Communications [348], Application programming Yes No
Target ECU [348] interface [349],
Communications [349]
1.0.8 Application programming Code generation [350] Yes No
interface [350]
1.0.7 Input/output Code generation [351], No No
drivers [351], Communications [351],
Target ECU [351] Input/output
drivers [352],
Target ECU [352]
1.0.6 Input/output drivers [353] No Yes No
1.0.5 Communications [354], Input/output drivers [355] Yes No
1.0.4 Calibration [356], No Yes Yes
Input/output
drivers [357],
Target ECU [358]

Release details

compatible upgrade
interface [358],
1.0.2 Input/output Calibration [360], Yes No
drivers [359], Examples [361],
Target ECU [360] Input/output drivers [361]
1.0.12 No Communications [362], Yes No
1.0.11 No Code generation [363] Yes No
1.0.10 Input/output drivers [364] No Yes No
1.0.1 No Input/output drivers [364] Yes No
1.0.0 No No Yes No

Chapter 2. Installation
2.1. Introduction ....................................................................................................... 11
2.1.1. Third party tool requirements ................................................................... 11
2.1.2. Third party tool requirements — C-API ..................................................... 11
2.1.3. Third party tool requirements — Simulink-API ........................................... 12
2.1.4. Third party tool requirements — installation .............................................. 12
2.1.5. Third party tool requirements — compatibility ............................................ 13
2.2. Installing OpenECU ........................................................................................... 15
2.3. License setup .................................................................................................... 22
2.3.1. Floating license ....................................................................................... 22
2.3.2. Node-locked license ................................................................................ 24
2.4. Removing OpenECU ......................................................................................... 24
2.5. Integration notes for third party tools ................................................................... 25
2.5.1. Microsoft Windows 10 ............................................................................. 25
2.5.2. Microsoft Windows 7 ............................................................................... 25
2.5.3. Microsoft Windows XP ............................................................................ 26
2.5.4. MATLAB ................................................................................................. 26
2.5.5. PiSnoop ................................................................................................. 27
2.5.6. ATI Vision .............................................................................................. 27
2.5.7. ETAS INCA calibration tool ..................................................................... 28
2.5.8. Vector CANape ....................................................................................... 29
2.5.9. Wind River (Diab) C Compiler v5.5.1.0 ..................................................... 29
2.5.10. Wind River (Diab) C Compiler v5.8.0.0 ................................................... 31
2.5.11. Wind River (Diab) C Compiler v5.9.0.0 ................................................... 31
2.5.12. GCC Compiler v4.7.3 ............................................................................ 32
2.5.13. Python .................................................................................................. 33
2.1. Introduction
This chapter describes the installation process for the OpenECU Simulink Blockset package,
C-API package, and its dependencies.
2.1.1. Third party tool requirements

OpenECU developer software has been tested to work with Windows 10. OpenECU is
compatible with Windows 7 SP1 (32-bit and 64-bit) and Windows XP SP3, but support for
these operating systems is deprecated. OpenECU is not compatible with Windows Vista or
Windows 8.
2.1.2. Third party tool requirements — C-API

For C based development, OpenECU requires (at a minimum) one of the following compiler
tools:
• Wind River Diab compiler
• GCC Compiler
Note
GCC is an optional component in the OpenECU installation (installed by default).
Additionally, GCC support is currently in a beta stage. As such, there a number of
known limitations for compiling an OpenECU application with GCC. Please see the

Installation
“Integration notes for third party tools” of the “Release notes” for a list of known issues
building with GCC for further details.
To program and calibrate an OpenECU with an application, OpenECU integrates with the
following calibration tools. Only one calibration tool is required:
• PiSnoop
• ATI VISION
• ETAS INCA
• Vector CANape
2.1.3. Third party tool requirements — Simulink-API

For Simulink model based development, OpenECU requires (at a minimum) the following
MathWorks tools:
• MATLAB (base product)
• Simulink (to develop the models)
• Simulink Coder (to generate C code from the models)
• MATLAB Coder (Simulink Coder depends on this)
In addition, if you need to add state diagrams to the model, then you will also need:
• Stateflow (to develop state flow diagrams inside your model) Simulink Coder generates C
code from the state flow diagrams inside your model.
Simulink Coder generates C code which does not lend itself to efficient repeatable testing.
When creating a production version of your product, you may need better control of the
structure of the C code generated from the model to reduce the cost of testing the C code
against any industry standards. Under these circumstances you will also need:
• Embedded Coder (to generate C code from the models)
To compile the generated C code (from either Simulink Coder or Embedded Coder), you will
need one of the following compilers:
• Wind River Diab compiler
• GCC compiler (free compiler but with known issues)
To program and calibrate an OpenECU with an application, OpenECU integrates with the
following calibration tools. Only one calibration tool is required:
• PiSnoop
• ATI VISION
• ETAS INCA
• Vector CANape
2.1.4. Third party tool requirements — installation

OpenECU works with a number of applications (both required and optional) supplied by other
companies. If you intend to use OpenECU with one of the following tools, it is best to install
them before OpenECU. The installer will then integrate the OpenECU developer software
with these applications.

Installation
• MATLAB versions:
32-bit: R2013a, R2013b, R2014a, R2014b, R2015a, R2015b

64-bit: R2013b, R2014a, R2014b, R2015a, R2015b, R2016a, R2016b, R2017a, R2017b,
R2018a, R2018b
• ETAS INCA calibration tool (version 7.2)
OpenECU works with a number of other applications, but these need not be installed prior
to the OpenECU developer software.
• Simulink Coder, formerly Real-Time Workshop, (optional) versions:

R2018a, R2018b
• Embedded Coder, formerly Real-Time Workshop Embedded Coder, (optional) versions:

R2018a, R2018b
• Stateflow versions:

R2018a, R2018b
• Wind River (Diab) C compiler (versions 5.5.1.0, 5.8.0.0 and 5.9.0.0) for M110, M220, M221,
M250, M460 and M461 targets
• Wind River (Diab) C compiler (version 5.9.0.0) for M670 target
• GCC Compiler (version 4.7.3 free compiler option) for M110, M220, M250, M460, M461
and M670 targets
Note
GCC is an optional component in the OpenECU installation (installed by default)
• PiSnoop (any version)
• ATI Vision calibration tool (version 2.5 through 4.0)
• Vector CANape calibration tool (version 8.0 through 13.0)
The applications above have been listed with a version or release number. These are the
versions or releases that OpenECU has been tested against. It may be that OpenECU will
work with other versions of these applications, but it is recommended against and Pi may not
provide technical support if these versions or releases are not used.
2.1.5. Third party tool requirements — compatibility

In summary, the following third party tools are compatible with this version of OpenECU:
Table 2.1. Third party tool compatibility

Third party tool Compatible versions
Operating systems

Installation
Third party tool Compatible versions

a
Microsoft Windows Win10 (64-bit)
Win7 SP1 (32-bit) (deprecated)
Win7 SP1 (64-bit) (deprecated)
XP SP3 (32-bit) (deprecated)
Modelling and code generation tools
MathWorks MATLAB R2013a, R2013b, R2014a, R2014b, R2015a, R2015b (32-bit)
R2013b, R2014a, R2014b, R2015a, R2015b, R2016a, R2016b,
MathWorks Simulink
R2017a, R2017b, R2018a, R2018b (64-bit)
MathWorks MATLAB Coder
b
MathWorks Simulink Coder
MathWorks Embedded Coder
c
Compiler tools
Wind River Diab C compiler v5.5.1.0, v5.8.0.0, v5.9.0.0 for M110, M220, M221, M250, M460
and M461 targets
v5.9.0.0 for M670 target
d
GCC Compiler v4.7.3 for M110, M220, M250, M460, M461 and M670 targets
e
Reprogramming, data logging and calibration tools
PiSnoop Any version
fg
ATI Vision v2.5 through v5.1.2
ETAS INCA v7.2.7
Vector CANape v8.0 through v16.0
a
OpenECU developer software has been tested to work with Windows 10. OpenECU is compatible with Windows 7 SP1 (32-
bit and 64-bit) and Windows XP SP3, but support for these operating systems is deprecated. OpenECU is not compatible with
Windows Vista or Windows 8.
OpenECU developer software may not function correctly on encrypted drives. OpenECU developer software must be able to
create files on the host file system. If using an encrypted drive, be sure that permission settings will allow OpenECU to create
files. Pi Innovo cannot provide support for issues with encrypted drives.
b
Mathworks Simulink Coder includes functionality of RTW and Stateflow Coder.
c
All OpenECU targets use Freescale PowerPC microcontrollers. The M110, M220, M221, M250, M460 and M461 use an
MPC5534 microcontroller, the M670 uses an MPC5674F microcontroller. The M560 and M580 use an MPC5746C for the primary
microcontroller and SPC560P34 for the secondary microcontroller.
See the Technicical Specification for your target for more information.
d
OpenECU has only been tested using GCC Compiler version 4.7.3 and is in the beta stage. As such, there are a number of
known issues to keep in mind when compiling an OpenECU application using GCC. For further details, please see "Integration
notes for third party tools" for a list of known issues.
e
These tools have been tested for reprogramming, data logging, and calibration. Some of them have many other features which
have not been tested with OpenECU.
f
The OpenECU method of configuring ATI Vision uses standardised ASAP2 files. As a result, all future versions of Vision are
expected to be backwardly compatible (e.g., version 3.7 and version 4.0 are known to be compatible).
g
The following Vision toolkits are typically used when working with OpenECU: Data Acquisition Toolkit, Calibration Toolkit,
Universal ECU Interface Standard Toolkit, APOLLO Data Analysis Toolkit, CAN Interface Toolkit and HORIZON Scripting/Remote
API Toolkit. In particular, the HORIZON Scripting/Remote API Toolkit is required if OpenECU builds are to generate Vision strategy
files (.vst).
Some third party tools have been marked deprecated and support for these tools will be
removed in a future release of OpenECU.
Third party tool Replacement

MathWorks MATLAB R2013a MATLAB latest version (see Pi Innovo's website [http://www.pi-
innovo.com/support-center/compatibility] for a complete list of
MathWorks MATLAB R2013b
supported versions of MATLAB).
MathWorks MATLAB R2014a

Installation

WindRiver Diab 5.5.1.0 WindRiver Diab 5.8.0 and 5.9.0
2.2. Installing OpenECU

The installer program, openecu_platform_2_8_0_r2019-1.exe, installs all the
necessary files for the OpenECU platform. This file can be obtained from the Pi Document
and Download Center web page [http://www.pi-innovo.com/downloads].
The installation process for the OpenECU developer software is performed by a wizard. To
run the wizard, execute the appropriate installer program. The installation can be stopped at
any point by selecting the Cancel button.
The installer requires that the user has administrative rights to make changes on the
computer. If a user without rights is trying to execute the installer a dialog box will be
displayed and the installation stops. Login with an administrator account or contact your
network administrator and try again.
If a version of an OpenECU installer is already running, a dialog box will appear saying so.
Select OK (which stops the current installer) and change to the other OpenECU installer to
continue.
If a version of MATLAB is running, a dialog box will appear saying so. Quit all instances of
MATLAB, then select OK to continue installation.
The installation process starts with an introduction. Select Next to continue.

Installation
The next windows to appear present the license agreement for using OpenECU developer
software and related software. Read the license agreements and if acceptable, select I accept
the terms of the License Agreement and then Next. If not acceptable, do not install the
software.

Installation
The next window to appear provides a number of components that can be installed or
patched.
The following table breaks out each of the components:
Table 2.2. Install components

Component Required Installed Description
by default
Platform Yes Yes A selection of packages to install, including the
C-API and Sim-API components.
OpenECU Yes Yes Install the Simulink interface to OpenECU,
Sim-API documentation and support packages.
Blockset Yes Yes Install the OpenECU blockset.

Installation
Component Required Installed Description

by default
Sim-API (optional) Yes Install the OpenECU blockset, ECU Technical
Manuals Specifications and other documentation in
(HTML) HTML format.
Sim-API (optional) Yes Install the OpenECU blockset, ECU Technical
Manuals Specifications and other documentation in PDF
(PDF) format.
Sim-API (optional) Yes Install some examples of how to use the
Examples OpenECU blockset.
OpenECU C- Yes Yes Install the OpenECU C-API files and libraries.
API
C-API Yes Yes Install the C interface to OpenECU,
documentation and support packages.
C-API (optional) Yes Install the OpenECU C-API User Guide,
Manuals ECU Technical Specifications and other
(HTML) documentation in HTML format.
C-API (optional) Yes Install the OpenECU C-API User Guide,
Manuals ECU Technical Specifications and other
(PDF) documentation in PDF format.
C-API (optional) Yes Install some examples of how to use the
Examples OpenECU C interface.
Extended (optional) No Install the On-Board Diagnostic (OBD) library.
Diagnostics This library is available at extra cost.
Features
Python Yes Yes Install the Python application. This application is
used to provide build support when generating
and compiling the model source code.
Tools (optional) No Installs additional OpenECU tools.
GCC (optional) Yes Installs the GNU Compiler Collection (v4.7.3)
and related tools for OpenECU targets.
lmadmin (optional) No Installs the installers for the lmadmin license
installer server from flexera.
FreeCCP (optional) No Installs the FreeCCP programming tool (note
that this tool is provided without support or
warranty).
Integration (optional) Yes Options to have the OpenECU installer integrate
OpenECU with third party tools, like MATLAB
and INCA.
MATLAB (optional) Yes During installation, the OpenECU blockset is
Integration integrated into MATLAB's PATH.
INCA-ProF (optional) No During installation, INCA-ProF is update to
Integration understand how to program an OpenECU.
Start Menu (optional) Yes During installation, the Window's Start menu
Shortcuts is updated to include shortcuts to installed
components.
Adjust the component selection as required (especially if you require the installer to update
an installed copy of ETAS INCA) and select the Next button.

Installation
The next window asks for a destination path to be specified. By default, the installer presents
a path to your local drive.
Warning
If the default path is changed, ensure that only digits, upper and lower case letters and
the _ character are used to specify directory names. An installation path that includes
any space characters will cause problems later on.
If the MATLAB integration component was selected, the next window presented provides a
list of installed and compatible versions of MATLAB. The example here shows that OpenECU
should be integrated with MATLAB R2008b.
Select which versions of MATLAB will be used with OpenECU and select the Next button.
If no version should be updated select None.

Installation
If no compatible versions of MATLAB were found, the next window presents the command
to run to add OpenECU to MATLAB (more details given in Section 2.5.4, “MATLAB”).
If the INCA-ProF integration component was selected, the next window presented provides
a list of installed versions of INCA.
Select which versions of INCA will be used with OpenECU and select the Next button. If no
version should be updated select None.
Note
If any version of INCA is selected, then the installer will add OpenECU integration to
all versions of INCA. This is simply a consequence of the way INCA works.

Installation
If no versions of INCA were found, the next window presents details on how to achieve this
by hand (more details given in Section 2.5.7, “ETAS INCA calibration tool”). The instructions
should be carried out when INCA-ProF runs.
If the Start Menu Shortcuts component was selected, then the next window presented asks
the user to select where in the Start menu the OpenECU items will be added. During install,
the installer adds short cuts to the documentation components selected and to the OpenECU
uninstall application.
Once installation has completed, the user is provided an option to read the getting started
guide, the release notes and to visit the OpenECU web site.

Installation
Getting started guide

If you are a first time user of OpenECU, it is strongly recommend following the
getting started guide, which covers what tools can be used with OpenECU and how to
configure OpenECU and those tools to work together.
Release notes
If you are installing a new version of OpenECU, it is strongly recommended that
you read the release notes. Some releases of OpenECU change the functionality of
features which may have an impact on existing applications.
2.3. License setup

Machine identification generated by the license tools is required to activate an OpenECU
platform license.
This section is a quick setup guide to get OpenECU working with your license. Consult
the license administration guide for more information on license management and
administration. This document is provided with the installation at "[install path]\doc_user
\License-Administration-Guide.pdf".
2.3.1. Floating license

To setup a floating license, the vender daemon will have to be run on the designated license
server as well as have a license file on that machine. This section describes setting up the
vendor daemon for a floating license.
2.3.1.1. Server
• After installing the platform, copy the files in "[install path]\tools\flexera\i86_n3\" to your
designated license server. On that machine, run lmtools.exe.

Installation
• Select the "System Settings tab", check "Include Domain", and press the button that says
"Save HOSTID Info to a File".
• Email the file to Pi Innovo with the purchase order. When the purchase is complete, Pi will
send you a valid license file. (Or if you have already completed the purchase, reply to the
welcome email with this information)
• It is recommended that lmadmin license server manager be used to serve licenses. Run
the lmadmin installer to install the software. Once the installation is complete, copy the
vender daemon, openecu.exe, into the install directory, "C:\Program Files (x86)\FlexNet
Publisher License Server Manager\".
• Start the license server manager. You can then use the web interface to upload the license
file and start serving your license.
Note
If a license has not yet been purchased, email the file to Pi Innovo with the purchase
order. When the purchase is complete, Pi will send a valid license file. If the purchace
has already been completed, reply to the welcome email with this information.
• It is recommended that lmadmin license server manager be used to serve licenses. Run
the lmadmin installer and start the license server manager. The web interface can then be
used to upload the license file and start serving your license.
Note
Details on installing and using the lmadmin tool are in Chapter 9 of the License
Administration Guide, "[install path]\doc_user\License-Administration-Guide.pdf".
Note
lmgrd is also provided with the platform as an alternative to lmadmin; consult Chapter
10 of the License Administration guide for details on its use.

Installation
2.3.1.2. Client
• On the user development machine, set the environment variable
OPENECU_LICENSE_FILE to <port>@<hostname>to tell the OpenECU platform to look
for a floating license from the license server.
2.3.2. Node-locked license

To setup a node-locked license, a license file must be placed on the development machine.
• After installing the platform, run the file: '[install path]\tools\flexera\i86_n3\lmtools.exe'
• Select the "System Settings tab", check "Include Domain", and Press the button that says
"Save HOSTID Info to a File" (see screen shot above)
• Email the file to Pi Innovo with the purchase order. When the purchase is complete, Pi will
send you a valid license file. (Or if you have already completed the purchase, reply to the
welcome email with this information) If a license has not yet been purchased, email the
file to Pi Innovo with the purchase order. When the purchase is complete, Pi will send a
valid license file. If the purchace has already been completed, reply to the welcome email
with this information.
• Copy the file to the directory "C:\openecu" or update the OPENECU_LICENSE_FILE

environment variable with the location of your file.
2.4. Removing OpenECU

Navigate through the Windows All Programs Start Menu shortcuts and find the OpenECU
Developer Software directory. Select the version of OpenECU to remove and run the
uninstaller.
The uninstaller requires that the user has administrative rights to make changes on the
computer. If a user without rights is trying to execute the uninstaller a dialog box will be
displayed and the uninstaller stops. Login with an administrator account or contact your
network administrator and try again.
If a version of an OpenECU uninstaller is already running, a dialog box will appear saying
so. Select OK and change to the other OpenECU uninstaller to continue.
The uninstaller presents the location of the previous install to remove. Select the Uninstall
button to continue (this will remove that version of OpenECU) or select the Cancel button
to stop the uninstall.

Installation
When uninstalling, if this version of OpenECU is present in MATLAB's PATH, then the
uninstaller will not remove the reference. Next time MATLAB is started, it will try to gain
access to the deleted OpenECU directory and will raise an error. When this occurs, manually
remove the OpenECU directories by selecting MATLAB's menu option File->Set Path....
Note
The OpenECU uninstaller does not remove the INCA-ProF configuration files for CCP.
2.5. Integration notes for third party tools

2.5.1. Microsoft Windows 10
2.5.1.1. Integration
The installer integrates the OpenECU package with Windows 10 by modifying the Start menu,
by modifying some registry items and by copying files to a local drive.
2.5.1.2. Known defects/issues

OpenECU developer software may not function correctly on encrypted drives. OpenECU
developer software must be able to create files on the host file system. If using an encrypted
drive, be sure that permission settings will allow OpenECU to create files. Pi Innovo cannot
provide support for issues with encrypted drives.
2.5.2. Microsoft Windows 7

The installer integrates the OpenECU package with Windows 7 SP1 by modifying the Start
menu, by modifying some registry items and by copying files to a local drive.

Installation

2.5.3. Microsoft Windows XP

The installer integrates the OpenECU package with Windows XP SP3 by modifying the Start
menu, by modifying some registry items and by copying files to a local drive.

2.5.4. MATLAB
The installer integrates the OpenECU package with MATLAB and Simulink. However, if for
any reason the installer could not find an installed version of MATLAB, the user can manually
integrate the OpenECU blockset by issuing the following MATLAB commands:
addpath '[install path]\openecu'

addpath '[install path]\openecu\rtw\c\openecu_ert\code_templates'
addpath '[install path]\openecu\rtw\c\openecu_ert'
addpath '[install path]\openecu\rtw\c\openecu_grt'
addpath '[install path]\openecu\rtw\c\openecu_grt_rsim'
addpath '[install path]\openecu\mex_r<release>'
addpath '[install path]\openecu\mfile'
addpath '[install path]\openecu\model'
Note
where the text [install path] is replaced by the installed location of the OpenECU
blockset, e.g., c:\openecu\platform\1_9_2; and the text <release> is replaced
with the major version of MATLAB (e.g., 2013b or 2013b_64 for 64-bit versions of
MATLAB).
Once the path has been added, the user can check the OpenECU version by issuing the
following MATLAB command:
ver openecu
A correct response will look something like:
OpenECU Blockset (Pi Innovo) Version <number> <date>
If nothing is printed, or an error message is returned, then the path specified by the addpath
command was incorrect and should be changed.

Installation
2.5.4.2. Known issues

• Open: When loading an OpenECU model in Simulink R2012a and later, Simulink may
issue warnings similar to this:
Warning: Model '...' was last saved using an old version (...) of Simulink.
For advice on upgrading this model to the current version of Simulink, see
the Upgrade Advisor.
> In oe_test_required_platform_vers at 26
In oe_make_rtw_hook at 153
In openecu_make_rtw_hook at 6
In general\private\openmdl at 13
In open at 159
In uiopen at 167
Workaround: Turn off the Notify when loading an old model option in Simulink's
preferences:
2.5.5. PiSnoop
Unlike some other calibration tools, during installation there is nothing special to be done
when integrating PiSnoop and OpenECU.

None.
2.5.6. ATI Vision

when integrating Vision and OpenECU.

Installation

• Open: integration issues with OpenECU while creating a Vision VST (strategy) file.
There have been integration issues between Vision and OpenECU, when the user
requests a build create a Vision VST (strategy) file. If OpenECU cannot create a strategy
file, then it may be necessary to register the COM interface for Vision by running the
RegisterCOMInterface.bat file included in the install of ATI Vision.
• Open: does not operate correctly with encrypted hard drives.
There have been reports of Vision interacting poorly with encrypted hard drives. At the
moment, it is not clear what the problem might be. On one occasion, Pi worked with ATI
and a customer and determined a work around that is not understood. The work around
was to rename the executable file for Vision to something longer than 11 characters.
• Open: some earlier versions do not support CCP seed/key correctly.
ATI Vision 2006 (v3.2) is the earliest version for which CCP seed/key security has been
validated by Pi Innovo. Earlier versions may support CCP seed/key security (see the
relevant Vision documentation) but bugs in the CCP implementation on various targets
are known to exist. ATI have recommended that earlier versions should not be used, or
should be used with caution.
2.5.7. ETAS INCA calibration tool

The installer integrates the OpenECU package with the ETAS INCA tool. However, if for
any reason the installer could not find an installed version of INCA, the user can manually
integrate the necessary ProF component.
The INCA-ProF tool programs OpenECU over CCP using a set of configuration files. In order
to manually integrate these configuration files, the user must run INCA, open an experiment,
select manage memory then flash programming.
The user is then presented with a dialog box to browse ProF configurations, or a ProF settings
dialog box (in which case the user must select Configure...).
With the browse ProF configurations dialog box, select the "Install..." button and browse to
the install location of OpenECU:
[install path]\tools_integration\inca_prof
and select OK. This will have manually installed the INCA-ProF configuration file for
OpenECU.
Note
If manually integrating and the ProF files cannot be found in the location above, then re-
run the OpenECU installer and select the Integration -> INCA-ProF Integration option
and try again.

None.

Installation
2.5.8. Vector CANape

when integrating CANape and OpenECU.

None.
2.5.9. Wind River (Diab) C Compiler v5.5.1.0

2.5.9.1. Installation
The Wind River (Diab) compiler 5.5.1.0 can be installed by running the file setup.exe from
the supplied media — several options will be presented during the compiler install and the
following responses should be used:
• On Choose your Activation Type window, select one of the following options:
• Permanent activation if you have been assigned with a license file from Wind River,
usually named WRSLicence.lic. The full path should point to the license file.
• Temporary activation if you wish to use the Wind River (Diab) compiler on an evaluation
basis, or temporary basis until a permanent license is provided.
• A reboot may be required to complete installation of the Wind River (Diab) compiler.
• If using one version of the Wind River (Diab) compiler, either setup the
OPENECU_DIAB_5_5_1_0 environment variable as described in the next point, or adjust
Window's system path to include the absolute path to the compiler's bin directory.
• If using more than one version of the Wind River (Diab) compiler (for instance, when you
are using two or more versions of OpenECU which require different versions of the Wind
River (Diab) compiler), the environment variable OPENECU_DIAB_5_5_1_0 must be set
to the absolute path to the compiler's bin directory. This macro must terminate in a “\”
and must use the DOS 8.3 short naming convention.
E.g., D:\Progra~1\diab\5_5_1_0\win32\bin\
2.5.9.2. Known defects

• Closed: incorrect generation of object code for “float <= float” comparisons.
The compiler incorrectly generates object code for “float <= float” comparisons, turning
the comparison into “float > float”. This issue has been resolved by removing the -
Xieee754-pedantic command line option to the compiler command line option to the
build configuration files.
• Open: incorrect generation of object code for long C functions.
The compiler incorrectly generates jump instructions in the object code if the jump
destination address differs from the address of the jump instruction by more than 15 bits
(signed). No warning or error is generated by the compiler. The result is a model which
does not behave as expected when run on target (usually the ECU appears as if it is
continually resetting).
To alert the user to this risk, an OpenECU build checks for large functions and issues a
warning message if any are found. The message takes the form:

Installation
Warning: Function foo is very large (0x000abcdef).

The generated object code may be susceptible to a known compiler defect.
Refer to the OpenECU user guide for further details.
Workaround (C-API): Break up large functions into small sub-functions.
Workaround (Simulink): RTW generates just a couple of C functions for the model, rather
than splitting major sub-systems into their own functions. Hence those functions can
become large enough to hit this compiler problem if the model is large. This can be
avoided by applying the atomic subsystem option to key subsystems in the model. RTW
generates a different C function for each atomic subsystem, where each resulting function
corresponds to just part of what would have been one large function. You should split any
large model up like this to avoid any one C function becoming large enough to hit this
compiler problem.
• Open: generation of non-existent labels.
The compiler can generate non-existent labels such as ".L1013" when compiling code
involving large structures, such as those generated by TargetLink. The code then fails to
link because the labels are not defined. This has not yet been seen with Simulink builds
but it may possibly be seen in future.
Workaround: if this problem is encountered, a patched version of the compiler is available

from Wind River for customers who have compiler support (quote service request
1054126).
• Open: incorrect rounding on conversion from float to integer types.
The compiler rounds values when converting from floating point to integer, e.g. from "float"
to "signed long" (in terms of native types, otherwise known as F32 and S32 in the OpenECU
environment). For example, 3.6 as a float is rounded to 4 as an integer, but the C standard
requires that the fractional part is truncated, so a converted value of 3 would be correct.
Similarly -3.6 is rounded to -4 instead of being truncated to -3. This defect is fixed in version
5.8.0.0 of the compiler.
Workaround: if this problem is encountered, a patched version of the compiler is available

from Wind River for customers who have compiler support (quote service request 864470).

• Closed: Can't use Simulink look up blocks
There has been a known issue which restricts the compiler to use Simulink lookup block.
When using Simulink lookup blocks, the Diab compiler would stop compilation with this
error message:
'[model-name].c', line [line-num]: warning (dcc:1792):

trying to assign 'ptr to volatile' to 'ptr'
This has now been fixed, see F-CR 13325 in the release notes.
• Closed: compiling the main model file can take a long time.
Small models compile in a short period of time, but once the code presented to the compiler
exceeds a limit, the compiler takes a long time to compile the main model file (model-
name.c).
Workaround: the compiler sets aside an amount of memory for the compilation phase
and if the size of the model code exceeds the limit, the compilation slows down. This can
be avoided by increasing the size of the compiler's buffer using a command line option.

Installation
Add the pcomp_CompileOptions block to the model, set the mode parameter to Add
to options and set the compiler options parameter to -Xparse-size=100000. If the
compilation is still slow, increase the option value further.

• Follow the guidance given in Section 2.5.9, “Wind River (Diab) C Compiler v5.5.1.0”.
• If using a single version of the Wind River (Diab) compiler, either setup the
OPENECU_DIAB_5_8 environment variable as described in the next point, or adjust
• If using multiple versions of the Wind River (Diab) compiler (for instance, when you are
using two or more versions of OpenECU which require different versions of the Wind
River (Diab) compiler), the environment variable OPENECU_DIAB_5_8 must be set to the
absolute path to the compiler's bin directory. This macro must terminate in a “\” and must
use the DOS 8.3 short naming convention.

None identified.

error message:


• Follow the guidance given in Section 2.5.9, “Wind River (Diab) C Compiler v5.5.1.0”.
• If using a single version of the Wind River (Diab) compiler, either setup the
OPENECU_DIAB_5_9 environment variable as described in the next point, or adjust
• If using multiple versions of the Wind River (Diab) compiler (for instance, when you are
using two or more versions of OpenECU which require different versions of the Wind
River (Diab) compiler), the environment variable OPENECU_DIAB_5_9 must be set to the

Installation
absolute path to the compiler's bin directory. This macro must terminate in a “\” and must
use the DOS 8.3 short naming convention.

None identified.

error message:

• Open: Error message 0169
The Diab 5.9.0.0 compiler generates object files that cause the Diab
ddump
command to generate the following error message during an application build.
Error 0169 at offset NNNNNNNN: Unexpected EOF.
The error appears to be benign and can be ignored. Currently, there is no known
workaround.
2.5.12. GCC Compiler v4.7.3

GCC, also known as the GNU Compiler Collection, is a free compiler system produced by
the GNU Project supporting various programming languages. The Free Software Foundation
(FSF) distributes GCC under the GNU Public License (GNU GPL). GCC has been adopted
as the standard compiler by most modern Unix-like computer operating system and has also
been ported to a wide variety of processor architectures and is available for most embedded
platforms.
GCC is used with permission under the GPL Version 3. If GCC is installed with OpenECU, the
license file can be found in the [install path]\tools\gcc\ppc\docs directory of the
OpenECU install. If desired, a copy of the GCC source code can be found and downloaded
from the Pi Innovo website.
Support for GCC is currently in beta and as such, the user may run into issues which can
cause an application to fail to build or run correctly on target. Listed below are a set of known
issues when building an application using GCC. See Appendix A, Contact information for
details on how to get in contact with OpenECU support if support is needed for using GCC.
GCC is not recommended for production programs at this time.
GCC is an optional component in the OpenECU installation and is installed by default.

Installation

None identified.

• Open: Applications built with the GCC compiler do not support the diagnostics feature at
this time. Applications using the diagnostics feature will not compile.
• Information: compiler warnings when using Simulink look up blocks.
When building a model that uses Simulink look up blocks, the compiler will emit diagnostic
messages similar to the following. These can be ignored.
[file-line]: warning: passing argument 2 of '[lookup function]'

discards 'volatile' qualifier from pointer target type
[enabled by default]
[file-line]: note: expected 'const real_T *' but argument is of type
'const volatile real_T *'
• Information: GCC only supports non-VLE code. Therefore, the compiled code will be larger.
In general, GCC applications will be about 50% bigger than code generated by Diab.
• Information: The GNU linker locates data slightly differently than the Diab linker in the
final images. RAM and Flash memory utilization may be different for the same application
compiled by different compilers.
• Open: Applications built with GCC in general exhibit higher CPU loading than applications
build with Diab.
2.5.13. Python
Python is general purpose, high level interpreted programming language, distributed under
the PSF license which allows use in non open-source commercial applications. The license
can be found in the [install path]\tools\python\license.txt file.
Python is a required component of the OpenECU installation.

None identified.

• Open: When using OpenECU, Python may raise an error about an incorrect DLL. For
example, “The procedure entry point for X could not be located in the dynamic link library
py[name].dll”. This can occur if another application installed on the same machine as
OpenECU has also installed Python (for instance, dSpace ControlDesk).
Workaround: Browse to the Windows system directory. Depending on the version of

Windows, this will be one of:
c:\windows\system32; or
c:\windows\syswow64
Locate the DLL referred to in the error message. The file will start with the characters “py”
and end with “.dll”. Group all Python DLLs and move them to a temporary location, then
restart OpenECU.

Installation
Temporarily moving DLLs will cause the other application to run incorrectly (and if DLLs
unrelated to Python are inadvertantly moved, then the applications that rely on those DLLs
may not run correctly). You can resolve this by returning the moved DLLs to their original
location, or possibly moving the DLLs to the location of the installed applications.
Note
The OpenECU installation of Python does not write files to the Windows directories,
or modify global registry entries relating to Python. As such, the OpenECU
installation of Python is entirely local to OpenECU and will not affect other packages.

Chapter 3. Change log
3.1. Feature sets ...................................................................................................... 35
3.2. Version numbering ............................................................................................. 35
3.3. Product marked as deprecated or end-of-life ....................................................... 36
3.3.1. Deprecated items .................................................................................... 36
3.3.2. End-of-life items ...................................................................................... 38
Use these release notes, a log of changes to the software packages over time, when
upgrading to a newer version to learn about:
New Features
New features introduced by this version, or significant changes to
existing features;
Fixes and Improvements

Fixes or improvements to existing features with details of why they were
previously wrong;
Outstanding Issues
Any issues known to cause problems in the latest release.
3.1. Feature sets

As described in the installation section, some features are provided as standard and some
features are optional (for instance, the On-Board Diagnostic (OBD) library). The release note
details changes for all feature sets, standard and optional, regardless of the feature sets
selected during installation.
Optional feature sets include:
• Firmware support for ISO reprogramming
• Firmware support for J1939 reprogramming
• ISO 15765 messaging support for J1979, KPW2000 and UDS
• J1939 messaging support for various DMs (DM1 and DM2 transmit and decode included
as standard)
• Extended diagnostic trouble code support (basic DTC support included as standard)
• In-use performance ratio, diagnostic test monitoring and entity support
• Freeze frame capture and storage support
3.2. Version numbering

Each software release has a version number and an optional tag. Each combination of
version number and tag is unique.
Version number
A version number consists of three numbers, separated by periods:
major, minor and sub-minor. For instance, the version number 1.8.3 has
a major number of 1, a minor number of 8, and a sub-minor number of 3.

Change log
A version number is more recent than another, when its numerical value
is larger. For instance, version 1.8.3 is more recent than version 1.7.5.
Version tag
A version tag is a textual string used to identify development versions
of the software, and typically ends with a tag number. For instance, the
version tag pre-dev-2 would indicate the second development release
of the software.
Tags which start with pre indicate that the software is based on an earlier
version and that the final release of the software is likely to have the
same version number. For instance, the version number and tag 1.8.3-
pre-dev-3 indicates that the software is based on a version earlier than
1.8.3 and the final version of software will be 1.8.3.
Tags which start with post indicate that the software is based on the
same version and that the final release of the software is likely to have
the next version number. For instance, the version number and tag
1.8.3-post-dev-3 indicates that the software is based on the release
version of 1.8.3 and the final version of software will be 1.8.4.
3.3. Product marked as deprecated or end-of-

life
From time to time, Pi will announce when parts or features of the product become deprecated
or have reached their end-of-life. This section details deprecated and end-of-life items
identified prior to this release. An up-to-date list can be found on the Pi Innovo website (http://
www.pi-innovo.com/support-center/compatibility [http://www.pi-innovo.com/notifications]).
Deprecated
Features of the product that will no longer be available or supported in
the future. Announcement of deprecation indicates features that should
be avoided. Features may become deprecated for different reasons. For
instance, an ECU may become redundant due to component availability.
Or it may be that a feature is considered extraneous and may be
removed to simplify the product.
Deprecated features remain available for a limited period of time to

allow transition to a replacement (if one is appropriate). For example,
if a Simulink model is developed using MATLAB R2008b and support
for MATLAB R2008b becomes deprecated, then support for MATLAB
R2008b will continue for a period of time to allow the model to be
transitioned to another version of MATLAB.
End-of-life
Announcement of end-of-life follows deprecation, indicating features
that are no longer available or supported. For instance, an ECU that
is announced end-of-life will no longer be available for purchase.
Requesting support for a version of the developer software marked end-
of-life will result in a request to upgrade to a supported version of the
software.
3.3.1. Deprecated items

ECU
The following ECUs are marked deprecated and will become
unavailable for purchase or repair in the future:

Change log
ECU Replacement
M460 no replacement
M461 no replacement
M220 (revision 3) M220 (revision 4 or 5).
Developer software features

The following Sim-API developer software features will be removed in
a future release:
Block Replacement
pcx_CANStatus Replaced by the pcx_BusStatus block in version 1.8.4.
The following C-API developer software features will be removed in a

future release:
Function Replacement
pax_set_input_update_rate() No replacement, no longer required since version
1.8.0.
pax_set_output_update_rate() No replacement, no longer required since version
1.8.0.
pcfg_softswitch_m460() Replaced by pcfg_setup_m460() in version
1.8.0.
pcx_is_bus_unavailable() Replaced by pcx_get_bus_state() in version
1.8.4.
pdx_set_input_update_rate() No replacement, no longer required since version
1.8.0.
pdx_set_output_update_rate() No replacement, no longer required since version
1.8.0.
pj1939_pg_transmit() Replaced by pj1939_pdu1_transmit() and
pj1939_pdu2_transmit() in version 2.2.0
(r2013-2).
pss_set_switch() Replaced by pss_set_safety_switch() in
version 1.7.3.
Declaration Types Replacement

volatile const Replaced by the OE_CAL macro in v2.2.0 for
cross compiler compatibility when declaring or
defining calibrations. Other variable types should
not change the use of those qualifiers.
The following supporting software will be removed in a future release:
Tool Replacement
FreeCCP Replaced by PiSnoop [http://www.pisnoop.com]
(demo or trial available on request).
RSIM Replaced by RTMODEL, RSIM is still included but
may not work with Matlab 2018a and above.
Third-party tools
The following third-party tool support will be removed in a future release.

Change log

MathWorks MATLAB R2013a MATLAB latest version (see Pi Innovo's website [http://
www.pi-innovo.com/support-center/compatibility] for a
complete list of supported versions of MATLAB).
MathWorks MATLAB R2014a
WindRiver Diab 5.5.1.0 WindRiver Diab 5.8.0 and 5.9.0
3.3.2. End-of-life items

ECU
The following ECUs are marked end-of-life and are no longer available
for purchase or repair.
ECU Replacement
A450 Replaced by M460 in version 2.1.0 (r2013-1).
G400 Replaced by G850 in version 2.1.0 (r2013-1).
G800 Replaced by G850 in version 2.1.0 (r2013-1).
G850 Replaced by M670 in version 2.4.0 (r2015-1).
M001 Replaced by X221 in version 2.1.0 (r2013-1).
a
M250 (revision 1) Replaced by M250 (revision 2) in version 2.1.0 (r2013-1).
M250-00H No replacement.
U82 No replacement.
X221 No replacement.
X657 No replacement.
a
If you have a revision 1 M250 ECU please contact Pi for details regarding replacement.
Developer software
The following developer software releases are marked end-of-life and
are no longer supported.
Developer software Replacement

Up to version 2.0.0 (r2012-1) Version 2.1.0 (r2013-1) or later.
Developer software features

The following Sim-API developer software features are marked end-of-
life and have been removed from the developer software package:
Block Replacement
pan_AngularAnalogInput Replaced by the pan_AngularAnalogInputVariable and
pan_AngularAnalogInputVariableAbs blocks in version 2.1.0
(r2013-1).
pan_AngularAnalogInputFixed Replaced by the pan_AngularAnalogInputVariable and
pan_AngularAnalogInputVariableAbs blocks in version 2.1.0
(r2013-1).
pdx_PeriodInput Replaced by the pdx_PwmInput block.
pdx_StepperMotorOutput No replacement.
pdx_SteppedOutput No replacement.

Change log
Block Replacement
pdx_TLE4953_Input No replacement.
pem_AddRateForATIEmulator No replacement.
ppp_Configuration No replacement.
put_BitwiseOp Replaced by the bitwise operator blocks supplied by
MathWorks as part of their Simulink block set.
put_Calmap1dTune No replacement.
put_Calmap2dTune No replacement.
put_CalValTune No replacement.
put_Config_M460 Replaced by the pcfg_Config_M460 block in version 1.8.1.
put_DisplayRates Replaced by Simulink's Sample Time Legend menu option in
version 2.5.0 (r2015-2).
The following C-API developer software features are marked end-of-life

and have been removed from the developer software package:
Function Replacement
pan_config_angular_ad() Replaced by pan_config_angular_ad_fxd()
and pan_config_angular_ad_var() in
version 1.8.7.
pan_get_angular() Replaced by
pan_get_angular_ad_avg_fxd() in version
1.8.6.
pan_get_angular_ad_avg() Replaced by
pan_get_angular_ad_avg_fxd() and
pan_get_angular_ad_avg_var() in version
1.8.7.
pan_get_angular_ad_samples() Replaced by
pan_get_angular_ad_samples_fxd() and
pan_get_angular_ad_samples_var() in
version 1.8.7.
pan_config_angular_ad_fxd() Replaced by pan_config_angular_ad_var()
in version 2.4.0.
pan_get_angular_ad_avg_fxd() Replaced by
pan_get_angular_ad_avg_var() in version
2.4.0.
Replaced by pan_config_angular_ad_var()
pan_get_angular_ad_samples_fxd()
in version 2.4.0.
pdx_period_input() Replaced by pdx_pwm_input().
pdx_stepper_output() No replacement.
pdx_stepped_output() No replacement.
pdx_tle4953_input() No replacement.
pj1939_dm1_decode() Replaced by pj1939_dm1_receive() and
pj1939_dm1_decode_dtc() in version 2.6.0
(r2016-1).
pj1939_dm2_decode() Replaced by pj1939_dm2_receive() and
pj1939_dm2_decode_dtc() in version 2.6.0
(r2016-1).

Change log
The following C-API developer software tools are no longer supported

and have been removed:
Tool Replacement
Pop-header tool (pop_header.py) C-API interface tool (capi.py) option: --
output-s-rec in version 2.2.0.
Third-party tools
Support for the following third-party tools are marked end-of-life and
have been removed from the developer software package.

MATLAB R12.1 By R2006b in version 1.9.0.
MATLAB R13 (SP1)
MATLAB R14 (SP2)
MATLAB R2006b By R2007b in version 2.1.0 (r2013-1).
MATLAB R2007b By R2008b in version 2.1.1.
MATLAB R2008a
MATLAB R2008b
MATLAB R2009a By R2011a in version 2.5.0 (r2015-2).
MATLAB R2010a
MATLAB R2010b
MATLAB R2011b
MATLAB R2012b
Wind River Diab compiler By Diab compiler 5.5.1.0 in version 2.1.0 (r2013-1) (see Pi
4.4b Innovo's website [http://www.pi-innovo.com/support-center/
compatibility] for a complete list of supported versions of
Wind River compiler).
GCC compiler 4.7.2 By GCC compiler 4.7.3 in version 2.3.0 (r2014-1) (see Pi
Innovo's website [http://www.pi-innovo.com/support-center/
compatibility] for a complete list of supported versions the
GCC compiler).
3.4. Release 2.8.0 (r2019-1)

Release labelled release-2.8.0-r2019-1 from 15 January 2019. This release is marked
as general meaning the release has been regression tested and is intended for general use.
The following table provides quick access to each of the changes.
Table 3.1. Release summary for v2.8.0-r2019-1

Package New features Fixes and improvements Backwards Firmware
compatible upgrade
C-API No CRs 20435 (F), 20431 (F), Yes Yes, see:
20429 (F), 20429 (F), 18630 (F)
20392 (F), 20339 (F),
20334 (F), 20151 (F),

Change log

compatible upgrade
20151 (F), 20151 (F),
19918 (F), 19537 (F),
19126 (F), 18711 (F),
18630 (F), 18566 (F),
18444 (F), 18359 (F),
18354 (F), 18237 (F),
18208 (F), 18177 (F),
15737 (F), 15414 (F),
15406 (F)
Sim-API 20499 (F) 20435 (F), 20431 (F), No, see: Yes, see:
20429 (F), 20429 (F), 20499 (F) 18630 (F)
20392 (F), 20339 (F),
20334 (F), 20151 (F),
20151 (F), 20151 (F),
19918 (F), 19851 (F),
19537 (F), 19317 (F),
19126 (F), 18711 (F),
18630 (F), 18616 (F),
18566 (F), 18444 (F),
18359 (F), 18354 (F),
18237 (F), 18208 (F),
18177 (F), 15737 (F),
15679 (F), 15523 (F),
15414 (F), 15406 (F),
15331 (F)
3.4.1. New features

New features introduced by this version, or significant changes to existing features.
Application programming interface
The programming interface for linking the application to each ECU.

OpenECU developer software presents two interfaces, one for C and one
for Simulink. See the third party tool requirements section for a list of C
compilers, their versions and versions of Simulink supported by OpenECU
developer software.
• Added support for MATLAB R2017a and R2017b
CR 20499 (F), affects Sim-API
OpenECU now integrates with MATLAB R2017a and R2017b. Support for
R2008b, R2012a, and R2012b has been removed.
3.4.2. Fixes and improvements

Fixes or improvements to existing features with details of why they were previously wrong.

developer software.

Change log
• Put_identification block no longer modifies data dictionary

unintentionally
Previously, the put_idnetification block could modify the data dictionary

unintentionally due to an error where the value stored in the configuration
set was changed when opening the model. This issue is now fixed.
• Fix error messages when opening put_Identification with Simulink

data dictionary
Previously, a list of error messages would be raised when opening the

put_Identification block in a model using a Simulink data dictionary. This
has been resolved.
Calibration
Integration with calibration tools (such as ATI Vision) and mechanisms to

read application data and write application calibration in real-time whilst
the application runs. See the systems requirements section for a list of
calibration tools and their versions supported by OpenECU developer
software.
• Fix Simulink ASAP2 generation with embedded coder and

RTMODEL
Previously, an error would be generated when using Simulink ASAP2

generation with embedded coder and RTMODEL. This has been fixed.
• Fixed global byte order for CANape a2l generation.
CR 18359 (F), affects Sim-API and C-API
• Correction to ASAP2 generation for enumerations in a Simulink data

dictionary
Previously, any ASAP2 file generated through Simulink would set the data
type of any enumeration to LONG. If the data type of the enumeration in
the Simulink data dictionary differed, the ASAP2 file would be incorrect.
This has been fixed.
Code generation
Integration with code-generation tools, such as MathWorks Real-Time

Workshop for Simulink, and the C-API tool for OpenECU.
• Models with long names not building with RTMODEL
A problem with the code generation files has meant that models with
names exceeding 22 characters in length will not build with the RTW-
RTMODEL autocoder. This has now been corrected
• A2L.err file is no longer removed on failed builds

Change log
Previously, the A2L.err file was removed on a failed build. This file contains
useful information and is no longer removed on failed builds.
Communications
External communication mechanisms and protocol support for both

reprogramming and application mode, including CCP, SAE-J1939 and
ISO-15765 over CAN.
• Increase the limit on number of CAN messages
Previously, the number of CAN messages was limited to 100 transmit

and 100 receive. Now, the number of CAN messages is limited to 32767
transmit and 32767 receive. This limit is based on the maximum value of
the data type used for CAN message handles (signed 16-bit). The actual
message limit will depend on CPU and memory resources.
• Remove ECU limit of total number of CCP ODTs
Previously, a build error would be raised if the total number of CCP

ODTs exceeded the default number of ODTs for an ECU. Although CAN
bandwidth will limit the number of ODTs that can be transmitted, the limit
of ODTs imposed by the CCP standard is 254. Now, a build error will be
raised if the total number of CCP ODTs exceeds 254.
• Fixed errata for MCP2515 CAN transponder on M110.
Previously, some messages sent though an MCP2515 could become

corrupted by the MCP2515 depending on timing and priority. Prioritization
and timing are now managed within the processor.
• M670 Current Drivers Offset
Corrected an error in the constant current driver auto zero function that in
most circumstances the channel that was zeroed would not be the same
channel that the application requested to zero.
• Issue building with 2-D and n-D lookup tables (A2L generation)
Corrected an error in the platform that prevented the ASAP2 2D and ND

lookup tables
• Build Warnings
Added the ability for customers to turn off the build warnings for openecu
variables exceeding variable character limit

Change log
• CPU Loading Optimization
For this specific use case a CPU loading optimization had to be complted
in relation to the constant current blocks.
Input/output drivers
Each target ECU is designed with a different set of input and output
conditioning circuitry. Interfaces provide access, from simple low-side digital
output drive to stepper motor output drive and crank trigger wheel input
decoding.
• Correction to UEGO device initialisation
Previously, when the air/fuel mixture became too rich, the UEGO device
would provide a lambda reading (UA) of approximately 1V instead of the
saturated 0.65V. The root cause was traced to the initialisation of the
UEGO device. This change adjusts the initialisation and provides some
internal calibrations to further adjust initialisation without further changes
to the OpenECU platform library.
• Correction to UEGO device initialisation
Updated internal calibrations for UEGO devices based on feedback from

customer.
• Removed SENT function from pin Z13 on M670, re-enabling Z13 as

a digital input
Previously, as part of case CR 14477 (F), SENT functionality was added

to pin Z13 on the M670 ECU. Unfortunately this inadvertently disabled
the use of Z13 as a digital input. This change removes SENT functionality
from pin Z13 and re-enables pin Z13 as a digital input.
• Correction to missing port injection pulses when the end-of-intake

angle crosses crank zero degrees
The pan_Injection_GPI Sim-API block and pan_set_injection_gpi

C-API function allows the end-of-intake angle to be set at the same time
as other injection schedule parameters, such as start-of-injection. Like
the start-of-injection angle, the end-of-intake angle is specified relative to
the cylinder's TDC-firing angle. Adding the cylinder's TDC-firing angle to
the cylinder's end-of-intake angle results in crank absolute angle, relative
to crank zero degrees. If the application adjusted a cylinder's end-of-
intake angle to transition crank zero degrees, then the ECU could miss
generating an injection event.
• Correction to missing port injection pulses when the end-of-intake

angle crosses crank zero degrees

Change log
Various changes to the port injection functionality have been introduced

in an effort to avoid missing injection pulses.
• Previously, the pan_Injection_GPI block would accept a SOI angle in

the range [-720, 720), and an end-of-intake angle in the range [0, 720).
Outside this range, the injection request would be discarded. Due to the
way the blockset attempted to wrap the injection request angles to the
current cylinder cycle, it was possible for the blockset to switch the order
of SOI angle and end-of-intake angle, resulting in a missed injection
event.
Now, the pan_Injection_GPI block accepts an end-of-intake angle in

the range [-720, 720) (matching the range of the SOI angle). When
wrapping the angle into the current cylinder cycle, the blockset ensures
that the relationship between SOI angle and end-of-intake angle is
preserved (i.e., if SOI angle is first and end-of-intake angle second, then
the blockset won't change that relationship).
However, to accomodate an end-of-intake angle that is # 720 degrees,

the the range check against the end-of-intake angle has been
temporarily removed. If the absolute difference between end-of-intake
angle and SOI angle is large enough, it would be possible to introduce
missed injection event. In a future release, there will be an additional
check to ensure that the end-of-intake angle is never more than +- 720
degrees from the SOI angle. For now, applications must ensure the
absolute difference between the end-of-intake angle and SOI angle is
less than 720.
In addition, if an application adjusted the end-of-intake angle to adhere

to the [0, 720) range, then the model must be updated to remove the
adjustment. For example, if the application calculated end-of-intake
angle as -725 degrees, rather than adjust to -5 degrees, the application
would pass -725 to the wrapper model.
• Previously, the underlying eTPU microcode would apply some logic

for scheduling injection events in half-engine sync mode (crank sync
achieved, but not cam sync) when scheduling injection events in full-
engine sync mode (crank and cam sync achieved). Specifically, the
microcode would attempt to schedule an injection event in the previous
cylinder cycle if the SOI angle were less than the previous end-of-
intake angle relative to crank-zero-degrees. This could result in missed
injection events.
Now, the half-engine sync mode logic is only applied when running in
half-engine sync mode.
• Previously, the underlying eTPU microcode would use signed data

types and arithmetic for some angle variables, and unsigned data types
and arithmetic for others. This could result in missed or extra injection
events.
Now, all eTPU microcode angle variables use signed data types and
arithmetic to avoid missing and extra injection events.
• Correction to missing port injection pulses

Change log
A further correction to calculations that convert on-angle from relative-to-

TDC-firing to relative-to-crank-zero-degrees.
• Correction to generation of port injection drive signals
Previously, if the port injection schedule was not set by the application
within the first second or so of the crank wheel starting to move, then port
injection pulse generation would occur but at the wrong angle. This has
been corrected.
• Correction to pan_CrankWheelDecodeState block help
Previously, selecting help for the pan_CrankWheelDecodeState block

would result in an error message, rather than the help page for the block.
This has been corrected.
• Constant current measurement validity flag
Previously, the valid flag for constant current measurements would not be
set in some configurations. Now, the flag is correctly set to indicate that
valid measurement data is available.
• Correction to 24-bit counter behaviour
A number of counters are specified as 24-bit counters, so that they

increment from 16777215 (0x00FFFFFF) to zero. However, it was found
that these were being sign-extended to a (signed) 32-bit variable. Thus
from 8388607 (0x007FFFFF) they would increment to 4286578688
(0xFF800000) instead of 8388608 (0x00800000). This has now been
corrected.
• Correction to spark pulse generation during loss of crank

synchronisation
Previously, when loss of crank synchronisation occurred, the logic driving

the spark pins would not be notified. If crank synchronisation was lost
during the generation of a spark pulse then the result would leave the
spark pin driven on. This has been fixed.
Target ECU
OpenECU software supports a number of ECUs. Each target ECU has

differing capabilities across connectors, input/output conditioning circuitry,
memory, processors and architectures.
• Unstable reset counter is not incremented after a power cycle.

Change log
Power cycling no longer triggers the unstable reset counter, This allows
the ECU to go to sleep and wake up without being held in reset due to
repeated resets.
Note
To enable this functionality, the ECU's firmware must be upgraded
to revision 2.8.0-r2019-1 or later. To upgrade the ECU's firmware
please contact OpenECU technical support as described in
Appendix A, Contact information.
User documentation
User documentation covers technical specifications for each ECU, user

guides or reference manuals, installation guides and release notes, in HTML
and PDF formats.
• Removed IMU references from tech spec for M250
Removed the references to IMU for the M250.
• Fixed M110 tech spec error with pin B11
The tech spec stated pin B11 was populated with SENT by default, but
pin B11 B11 is not populated with SENT by default. The tech spec has
been updated.
• Added warning to M670 tech spec for Vref pulse
The m670 tech spec now has a warning stating Vref values can't be relied
on during a reset.
• Updated voltage ranges in m110 tech spec
Fixed some incorrect voltage ranges in the m110 tech spec.
• Added a clarification for the M110 tech spec
Added a clarification to the M110 tech spec for Pin A5 to clarify that the
pin has 2 default functions.
3.4.3. Outstanding issues

• Errors integrating with ETAS INCA calibration tool during OpenECU
installation
When integrating OpenECU with the ETAS INCA calibration tool during
OpenECU installation, there is a problem with part of the installation

Change log
procedure. Selecting the Integration -> INCA-ProF Integration option

when choosing components to install is necessary to generate the target-
specific ProF configuration files in the OpenECU installed directory (under
tool_integration\inca_prof).
However, when later in the installation process the user is invited to

“Choose INCA Updates” (with a list of any currently installed versions of
INCA), the user should select "None". This step copies the ProF files into
the ETAS INCA installed location, however it does not correctly adjust the
paths to those files. This causes errors when attempting to use these ProF
files.
Instead the ProF files should be installed directly using the ETAS INCA tool
(after installing OpenECU) using the procedure described in the Appendix
of the OpenECU User Guide on how to use INCA with OpenECU (under
section “Supporting Tools”).
• Manufacturing data retrieval disabled while in reprogramming mode
The firmware is unable to retrieve manufacturing data via an

EXCHANGE_ID request while in reprogramming mode. This feature
has been temporarily disabled while ECC recovery is enabled in
reprogramming mode.
Note
• Peak and hold injector outputs fails when an out of range current or
frequency request is made by the application
CR 8766 (W), affects Sim-API and C-API
Current or frequency requests in the range specified by the user guide are
correctly generated.
• Cannot generate a peak current for a shorter duration that the

minimum duty cycle
• J1939 PG transmit and PG receive interfaces do not correctly

determine the CAN bus off condition
Both the PG transmit and PG receive interfaces will report an error if the
CAN bus is detected as bus-off when the interface runs (as well as other
conditions). During testing, it has been shown that the bus-off condition is
not detected correctly and thus any bus-off condition does not contribute
to the error report. The application must determine the bus-off condition
using the CAN status interface rather than relying on the PG transmit and
receive interfaces for full error reporting.
• Cannot define a DME without an associated DTE

Change log
The ppr_DiagnosticMonitorEntity block to update the numerator,

denominator and ratio outputs incorrectly assumes that at least one DTE
will be found belonging to that DME. Otherwise it returns an error, and
the values for the numerator, denominator and ratio are indeterminate and
should not be relied on. As a work around, an application must assign at
least one DTE to every DME.
• Application scheduled tasks immediately after software

initialisation completes can be delayed by up to 11 milliseconds
Thereafter, the task schedule continues as expected.
• DM30 test result reporting is not currently correct
CR 8630 (W), affects Sim-API
DM30 does not currently report results correctly for DM7 TIDs 248-250.
All DM30 results are reported as if TID 247 (return all scaled test results
for one SPN) was requested, instead of reporting a single test result. The
suggested work around is for single tests to be reported via the generic
j1939_PGTransmit block.
• The adaptive blocks do not generate properly on the Real-Time

Workshop Embedded Coder target when Global data is placed in a
seperate file
The default values of adaptive parameters are stored in a defined section

of memory in the calibration region. When these calibrations are defined
in a seperate file, the compiler does not place them in the proper region of
memory, and thus they are disabled. The workaround is to place all global
data in the same file as the source file.
• Negative responses to J1979 services not supported for physically

addressed requests
J1979 SEP2010 section 6.2.4.3.7 specifies that if any of services $00 to

$0F are not supported, the ECU shall not respond. However, the ECU
does give a negative response here for physically addressed requests.
• Negative responses to incorrectly formatted J1979 messages
On certain J1979 ISO 15765-4 services, the ECU generates a negative

response to incorrectly formatted request messages in contradiction to the
standard. No response is preferred in this situation. This affects services
$03, $06, $07 and $0A. See also CR8153.
• Avoiding processor exceptions if NULL dereferenced in customer

application during flash erase
CR 8211 (F), affects C-API

Change log
See CR 8211 (F) for detail. It is still possible for a bad access to cause
an exception which will continue to occur until the flash operation has
completed. If it does, a continuous loop is effectively entered until the flash
operation is over. If that operation is an erase, it may take long enough for
a watchdog exception to take place. Therefore this issue remains open
for further action in future to address this scenario. Note however that this
type of exception pattern occurs only very rarely even if NULL is repeatedly
read during flash operations, so it is now very much less probable that a
customer application will cause a reset in the manner described.
• The pan_AngularAnalogInputConfig block does not dynamically

change the I/O channel drop down selection, when the group drop
down selection is changed
Work around this issue by selecting the required group, closing the block
mask parameter dialog, opening the block mask parameter dialog again,
then select the required I/O channel.
• Incorrect flagging of duplicate PGN information
During the build process, checks are performed in case any PGNs have
been duplicated. Unfortunately, these checks sometimes flag duplications
erroneously.
• Channel checking for synchronised PWM output blocks
The Simulink interface does not prevent an application model from using
the same channels in both a Synchronised PWM output block and in
another PWM output block. It is up to the developer to avoid this erroneous
double assignment.
• Check for initial frequency does not allow for clock source
The check for initial frequency for Peak and Hold Injector, PWM and
SPWM blocks does not yet take into account the clock source selected.
So, for example, if the slow clock is selected and an initial frequency of
greater-than 40Hz is selected, an error will not be generated when the
model is updated. The frequency will however be clipped to the allowed
range at run-time.
• Warnings about the pan_InjectorCompConfigDI and

pan_SparkConfig blocks
MATLAB may print a set of warnings relating to instatiating these blocks,

referring to an invalid setting. The warnings will not affect the use of the
blocks once placed in a model and configured.
• Partially verified synchronised PWM functionality

Change log
The synchronised PWM functionality is designed for driving injectors with

peak and hold current. As such, it has only been validated with master
frequency equal to slave frequency. Further testing needs to be performed
to characterise the functionality.
• Some J1939 functionality does not adhere to the J1939 standard
There are several known issues with the J1939 protocol stack
implemented in the OpenECU platform, these are detailed below:
The J1939 feature assumes that it will be running on a fixed address

network. Incorrect operation may occur if address claiming is used by
other ECUs on the bus.
The feature doesn't implement some timeout periods that are defined in
the J1939 specification.
Requests to pause transfers via a CTS message are not honoured.
Requests to re-transmit messages via a CTS message are not honoured.
The feature is unable to handle simultaneous BAM and RTS/CTS

sessions from the same source.
• Support for ETAS INCA v5.1.2 has not been fully verified
The last time integration of OpenECU with INCA was tested was some
time back, when support for INCA was first introduced. Since then, ETAS
have produced newer versions of INCA but no further work to validate
integration has taken place.
3.5. Release 2.7.0 (r2017-1)

Release labelled release-2.7.0-r2017-1 from 12 May 2017. This release is marked as
general meaning the release has been regression tested and is intended for general use.

compatible upgrade
C-API 17945 (F), 14965 (F), 18373 (F), 18193 (F), No, see: No
14964 (F), 14955 (F) 17974 (F), 17968 (F), 14955 (F)
17956 (F), 17923 (F),
17864 (F), 15748 (F),
15522 (F), 15416 (F),
15408 (F), 15394 (F),
15389 (F), 15296 (F),
15295 (F), 15251 (F),
15224 (F), 14941 (F),
12324 (F)
Sim-API 17945 (F), 14965 (F), 18373 (F), 18359 (F), No, see: No
14964 (F), 14955 (F), 18193 (F), 18113 (F), 15361 (F),
14851 (F) 14955 (F)

Change log

compatible upgrade
18110 (F), 17980 (F),
17974 (F), 17968 (F),
17967 (F), 17956 (F),
17923 (F), 17864 (F),
15788 (F), 15748 (F),
15663 (F), 15635 (F),
15522 (F), 15416 (F),
15408 (F), 15394 (F),
15389 (F), 15361 (F),
15340 (F), 15340 (F),
15296 (F), 15295 (F),
15251 (F), 15224 (F),
14941 (F), 12324 (F)
3.5.1. New features

decoding.
• Added injector and spark schedule feedback interfaces
The pan_InjectionFeedback_DI, pan_InjectionFeedback_PI and

pan_SparkFeedback blocks, and
pan_get_injection_di_feedback(),
pan_get_injection_pi_feedback() and
pan_get_spark_feedback() functions have been added to provide
feedback about generated injection and spark pulses. The feedback can
be used by the application to confirm that the requested events have
occurred. It can also be used to better track the quantity of fuel delivered.
• Allow the drop-dead angle to be updated when setting the direct

injection schedule
Previously, the direct injection drop dead angle was specified through a
C-API function or Sim-API block during initialisation of the application, and
could not be changed whilst the application was running. This has been
changed to allow the application to modify the drop dead angle at any time.
• Changes to angular functionality
To better support different engine configurations, the angular functionality

has been changed in places.
• The crank interfaces have changed to better support crank trigger

wheels with multiple gaps. Support has been added for extra teeth as

Change log
synchronisation points. Interfaces have been added to extract the state

of signal decoding and accumulated errors whilst decoding.
• The cam interfaces have been changed to remove synchronisation

detection. Engine synchronisation is now handled by the application.
• The engine interfaces have been changed to require the application

to declare synchronisation. The application must look at crank and
cam information, or possibly other information such as the acceleration
profile, to determine the overall engine position. Support has been
added to allow the application to move between engine synchronisation
modes, such as half or full.
• The application provides the engine position to the platform and in turn,
individual functions, such as analogue input sampling or injection pulse
generation, reschedules events at appropriate times. The adjustment
in engine position can range from a complete crank cycle, e.g., 360
degrees, to smaller than a crank tooth, e.g., 0.5 degrees.
These changes break backwards compatibility. See the Angular section

in the user guide for an overview of the engine functionality and how
the interface must interact. An example application is available to show
the interfaces should be used. Further help is available from OpenECU
Technical Support.
Third party tool support
OpenECU builds on, and utilises, various tools from third parties, including
C compilers, calibration tools and operating systems. See the third party tool
requirements section for a complete list of required and options software,
and the versions supported.
• Added support for Mathworks MATLAB release R2016a and R2016b

(64-bit)
OpenECU has been extended to support the MATLAB release R2016a

and R2016b. Support for previously deprecated MATLAB versions
R2011a and R2011b has been removed. Support for MATLAB R2012a
and R2012b have been marked deprecated. Support for R2012a and
R2012b will be removed in a future release.
User documentation

and PDF formats.
• Added information about when DTCs are cleared after

reprogramming
The documentation for the pdtc_Memory Simulink block has been

expanded to describe the circumstances under which pre-existing DTC
information is cleared when the ECU is reprogrammed.
The C-API documentation has also been expanded to clarify this.

Change log


developer software.
• Correction to creating an OpenECU model
Previously, when creating an OpenECU model using the

oe_create_model command, the command would complete by
generating a new model but Simulink would generate two warning
messages, similar to the text below. This has been corrected.
Warning: In instantiating linked block 'plat_lib/Input Drivers/

pdx_SentInput' : Invalid setting in SENT_INPUT block (mask)
'pdx_SentInput' for parameter 'pdxl_senti_chan'.
> In oe_find_system at 74 [...]
• pj1939_PgReceive block error
The pj1939_PgReceive Simulink block was sometimes reporting an error

even when all the mask parameters were correct. That has now been
fixed.
• Added support for logical type in Default state of pdx_DigitalOutput

block
The supported types for the Default state mask parameter of the
pdx_DigitalOutput Simulink block were limited to numeric types which
therefore excluded the boolean type (which is classed as logical and
hence non-numeric by Simulink). This has been changed to allow logical
(boolean) types as well.
• Correction to model load message about 'dummy_marque_06'
Previously, a warning message about dummy_marque_06 would be

raised when a model was loaded. This has been resolved.
Code generation

• Correction to allow referenced models to build with 64-bit versions

of MATLAB

Change log
• Correction to oe_create_model command for the M550 and M670

targets
Previously, when the oe_create_model command was used to create

a model for the M550 or M670 target, an incompatible compiler would be
assigned to the model's configuration parameters. When the model was
built, an error message would be raised about the compiler. This has been
fixed.
• Correction to application builds using GCC
Previously, the supporting makefile for building Simulink based OpenECU

models with GCC would incorrectly generate the application ELF file twice.
This could result in an error message during the application build, about
failing to parse the map file. This has been corrected and the application
ELF is generated once during a model build.
• Fixed nuisance 'UNNAMED' and

'mpl_tt_pcx_queue_emptier_sporadic' warning during A2L
generation
Two nuisance warnings are emitted by the A2L generation tools stating:
• That group name “” is not valid and will be replaced with UNNAMED.
• That the automatic ASAP2 entry

“mpl_tt_pcx_queue_emptier_sporadic” is too long for the default
ASAP2 name length of 31 characters, and has been automatically
shortened.
These issues have been fixed.
• Fixed ASAP2 compliance issue with A2L files generated using

Simulink based A2L generation
Previously, the ASAP2 module name could contain an a character

prohibited by ASAP2. Now, the ASAP2 module name is fully compliant.
Communications

ISO-15765 over CAN.
• Support for J1939 PGNs with non-zero Data Page
It was found that PGNs with non-zero DP bits were not being reported to
the application. This has now been addressed.
• Improvements to M110 CAN performance

Change log
The M110 has some known performance limitations on CAN buses C

and D due to the use of a SPI to CAN device for these channels. This
CR improves the reliability of the CAN transmit rate on these buses, and
reduces the CPU usage with some software optimizations.
Diagnostics (communications and fault handling)
Diagnostic trouble codes and read/write parameter IDs are supported over
the ISO-15765 and SAE-J1939 protocols.
• Correction to application use of the processor watchdog
Previously, if the application made use of the extended diagnostics

CVN functionality and the core library watchdog functionality, then the
application would not be able to invoke a watchdog reset of the ECU. This
was because the extended diagnostics library would clear the watchdog
timer periodically.
Now, neither the extended diagnostics or core libraries clear the watchdog
timer periodically and the application can induce watchdog resets.
Examples
To help introduce OpenECU applications, the software is provided with a

number of examples. There are sets of examples for each interface, one set
for C and one set for Simulink.
• Removed obsolete comment from example models
The two_pot_demo_w_sfunction example models contained notes stating

that only Diab 5.5.1 was supported, which is not correct. These notes have
now been deleted.
• General tidy up of Sim-API examples
Previously, the examples exhibited various issues, from not being able to
load a model, to error emitted about I/O channel names, to missing library
links to spelling mistakes.
decoding.
• Failure to allocate stack correctly on Time Processing Unit
For those ECUs (e.g. M670) endowed with a twin-engine enhanced Time
Processing Unit (eTPU), a problem was identified whereby the stack
for the second engine was not being properly accounted for, resulting

Change log
in possible corruption of some eTPU parameters. This has now been

rectified.
• Correction to analogue input sampling for long application

initialisations
Previously, when memory was being accessed under high load, the
analogue input conversions could be applied to the wrong channel
assignments. This has been resolved.
• Changes made to M670 analogue input channels relating to knock

processing
With reference to CR (?), changes have been made to the channel names
of M670 knock processing pins.
From To
AIN (pin Y51) AIN (pin Y51 / build option)
AIN (pin Y51+Y52) AIN (pin Y51+Y52 / build option)
AIN (pin Y52) AIN (pin Y52 / build option)
AIN (pin Z48) AIN (pin Z48 / build option)
AIN (pin Z48+Z49) AIN (pin Z48+Z49 / build option)
AIN (pin Z49) AIN (pin Z49 / build option)
When an OpenECU model is loaded and the model uses any of these
channel names in a block, then for each block Simulink will generate a
warning message about an invalid channel name, and alter the block's
channel selection to be the first in the channel drop down. To correct this,
the user must update the block identified in each warning message to
select the required channel.
• Fixed scaling issue on M670 constant current output dither step size
The dither step size parameter of the pax_CcConfigTle8242 block was not
scaled correctly for the current sense resistor, resulting in a larger than
expected dither amplitude.
• Correction to some output drivers for the M670
Previously, some outputs on the M670 would become non-operational

depending on the setup order of those output channels. This has been
resolved.
• Correction to avoid missing direct injection pulses
Previously, if an application request to update the direct injection schedule

occured before the previously scheduled injection, and the updated
injection schedule would have occured in the past for the current cycle,

Change log
then the ECU would determine that the new schedule could not be met
but ignore the old schedule, resulting in a missed injection for one cycle.
Now, in the same circumstances, the ECU will determine that the new
schedule cannot be met but reuse the old schedule for the current cylinder
cycle, then switch to the new schedule for the next cylinder cycle. This
avoids a missing injection for one cycle.
• Correction to avoid recording camshaft trigger wheel tooth

information too early in the synchronisation process
Previously, if the ECU detected camshaft trigger wheel teeth prior to

declaring crankshaft trigger wheel synchronisation, the ECU would report
the cam teeth but with incorrect angle information.
Now, until crankshaft trigger wheel synchronisation has been achieved,

no information about camshaft trigger wheel teeth is reported.
Target ECU

• M110 repeated resets with certain applications
Certain applications would cause the M110 target to repeatedly reset, and
then sit in reprogramming mode flashing 1-1-7. The cause of this has been
identified and fixed.
• Build process failing to clean up archives after quick appends
During the build process, the archive files generated by referenced models
were not being cleaned up after rebuilt object files were appended, so that
older object files were retained that might be linked to erroneously. This
has now been fixed.
• Update to allow the OpenECU library blockset to show in more

recent versions of MATLAB
Previously, Simulink would report a message about repository information

being missing for the OpenECU library when Simulink's library browser
was opened. Now, the repository information is generated in memory and
there is no warning message.
If the library does not show then try running

sl_refresh_customizations.

Change log
User documentation

and PDF formats.
• Updated the M670 Technical Specification regarding the use of the

UEGO at 24V
• Added information about crimp tools to the M220 and M250

Technical Specifications
• Updated the M110 Technical Specification to note that ignition-less

reprogramming is not supported
The M110 supports wake-on-CAN functionality but it does not support

ignition-less reprogramming. This has been noted in the relevant section
of the M110 technical specification.
• Corrected errors in the M110 Technical Specification block diagram
The M110 Technical Specification block diagram contained some errors.

The pins A19, A17 and A18 in the bottom right-hand corner should have
read B19, B17 and B18. This has now been corrected.
• Clarifications to M670 tech spec
The following has been added to the M670 Technical Specification to

clarify the ECU's behavior.
• Added description of power relay pin Z19.
• Added description of ECU's power hold behaviour while in

reprogramming mode.
• Fixed typo in TLE8242 description.
• Specified that analog inputs on pins Y51, Y52, Z48, and Z49 are only
available as a hardware change option (see also CR 15361 (F)).
• Clarified how CCP privilege levels can be enabled or disabled

independently
Previously, the user documentation stated that there was an imposed

order to accessing each of the CCP privilege levels. That was not the case,
in that each privilege level could be individually enabled or disabled. The
documentation has been clarified.

Change log
3.6. Release 2.6.0 (r2016-1)

Release labelled release-2.6.0-r2016-1 from 11 August 2016. This release is marked

compatible upgrade
C-API 14915 (F), 14800 (F), 15238 (F), 15175 (F), No, see: Yes, see:
14793 (F), 14477 (F), 15173 (F), 15171 (F), 15171 (F), 15161 (F)
14410 (F), 14165 (F), 15166 (F), 15161 (F), 14953 (F),
14163 (F), 13685 (F), 15005 (F), 14995 (F), 13685 (F),
13580 (F), 13476 (F), 14993 (F), 14988 (F), 11886 (F)
11972 (F), 11886 (F), 14953 (F), 14880 (F),
10766 (F) 14869 (F), 14866 (F),
14848 (F), 14819 (F),
14757 (F), 14750 (F),
14746 (F), 14720 (F),
14719 (F), 14700 (F),
14691 (F), 14671 (F),
14661 (F), 14639 (F),
14517 (F), 14486 (F),
14356 (F), 14136 (F),
12730 (F), 12656 (F),
11696 (F), 11273 (F),
10992 (F), 9630 (F)
Sim-API 14915 (F), 14800 (F), 15238 (F), 15175 (F), No, see: Yes, see:
14793 (F), 14477 (F), 15173 (F), 15171 (F), 15171 (F), 15161 (F)
14410 (F), 14165 (F), 15166 (F), 15161 (F), 14953 (F),
14163 (F), 13685 (F), 15005 (F), 14995 (F), 13685 (F),
13580 (F), 13476 (F), 14993 (F), 14988 (F), 11886 (F)
11972 (F), 11886 (F), 14953 (F), 14880 (F),
10766 (F) 14869 (F), 14866 (F),
14848 (F), 14819 (F),
14778 (F), 14757 (F),
14754 (F), 14750 (F),
14748 (F), 14746 (F),
14732 (F), 14720 (F),
14719 (F), 14700 (F),
14691 (F), 14671 (F),
14661 (F), 14639 (F),
14517 (F), 14486 (F),
14384 (F), 14356 (F),
14136 (F), 14090 (F),
12730 (F), 12656 (F),
11696 (F), 11328 (F),
11273 (F), 10992 (F), 9630
(F)
3.6.1. New features


Change log

developer software.
• Added CPU loading calculation performed each second
See the automatic ASAP2 variable mpl_cpu_loaded_1000ms and

mpl_max_cpu_loaded_1000ms.
• Added interfaces to read the loading of each eTPU device
Interfaces similar to reading the CPU loading have been added for
the eTPU. For more detail, see the C-API psc_get_etpu_loading()
and psc_get_max_etpu_loading() functions, and Sim-API
psc_EtpuLoading block, in the user guides.
Calibration

software.
• Support for ETAS XETK-V2.0A emulator test probe
Platform support has been added for the ETAS XETK-V2.0A emulator test
probe. It can be used for measurement, calibration, and reprogramming
of OpenECU M670 modules.
• Added application defined CCP DAQ raster sizes
With the raster {} C-API interface file statement, or with the

pcp_RasterConfig Sim-API block, the application can define the size and
rate of each supported CCP DAQ raster.
Communications

ISO-15765 over CAN.
• Added support for M110 CAN C and D
The M110 now supports 4 CAN buses, CAN C and D use a mcp2515 CAN
controller with SPI interface.

Change log
decoding.
• Enabled SENT functionality for some M670 inputs
SENT functionality has been enabled for several M670 inputs. The SENT
channels will only function correctly if the ECU has been optioned for
SENT.
• Added support for H-bridges on the M670 H-bridge and SENT

daughterboard
See the M670 Technical Specification for details about the H-bridge and
SENT daughterboard.
• Added support for SENT sensors on the M670 H-bridge and SENT
daughterboard
When using the H-bridge and SENT daughterboard (for more details, see
the M670 Technical Specification), support for SENT sensors has been
added.
Support for fast channel data is available through the Sim-API

pdx_SentInput block and C-API pdx_sent_in() function. Support for
short serial messages and enhanced serial messages (both formats)
is available through the Sim-API pdx_SentSerialInput block and C-API
pdx_sent_serial_input() function.
• Extended generic angular output to support multiple pulses
Previously, the pan_set_angular_output() C-API function or

pan_AngularOutput Simulink block could only schedule one event at a
time, requiring multiple calls per engine cycle for multiple pulses. Now, the
pan_set_angular_output() C-API function and pan_AngularOutput
Simulink block have been updated to accept an array/vector of start
actions, end actions, start angles, and durations to allow for multiple
events per scheduling of events. The events can also now be set to
repeat automatically every engine cycle. See the C-API and Sim-API User
Guides for further details.
• Extended electrical diagnostics for the M670 smart ignition outputs

for use with GPI and DI injectors
When the M670 spark outputs (pins Y37, Y38, Y39, Y40, Y44,
Y45, Y49, Y50) are used as GPI or DI injector outputs, the
pdx_digital_monitor_input() C-API function or pdx_Monitor
Simulink block can now be used to configure and retrieve electrical
diagnostic information, where previously this was only available when
these outputs were used as PWM or spark outputs.

Change log
Target ECU

• Added support for the M110 target ECU
Support has been added for the M110 target ECU.
• Added support to build M670 applications using GCC
The OpenECU developer software has been extended to support

application builds for the M670 target using the GCC compiler.
User documentation

and PDF formats.
• Added M110 Technical Specifications
File is released as 29T-068883TK-xx-M110-Technical-Specification.


developer software.
• Fixed issue in pj1939_PgReceive block, where outport signals can

get disconnected
In order to use pj1939_PgReceive, the model must also contain a

pj1939_Configuration block. If the pj1939_PgReceive block is in a library
model while the pj1939_Configuration block is in a different library or in
the root model, this can cause an error when the model is built, resulting

Change log
in the outports of the pj1939_PgReceive block being disconnected from

the signals. This software change fixes that problem.
• Removed deprecated DM1 and DM2 interfaces
pj1939_Dm1Decode and pj1939_Dm2Decode Simulink interfaces and

pj1939_dm1_decode and pj1939_dm2_decode C-API interfaces were
deprecated in the 2.4.0 OpenECU platform release. These interfaces
have been removed. The new interfaces pj1939_Dm1Receive and
pj1939_Dm1DecodeDtc should be used in place of pj1939_Dm1Decode
for DM1 reception. The new interfaces pj1939_Dm2Receive and
pj1939_Dm2DecodeDtc should be used in place of pj1939_Dm2Decode
for DM2 reception.
• Removed the Sim-API block 'put_displayRates'
As the Simulink Sample Time Legend feature was more accurate than
the put_DisplayRates block, the put_DisplayRates block was marked
deprecated in version 2.3.0 (r2014-1), and has now been removed. The
block is no longer available and will show as bad link in Simulink models.
• Increased fuel rail pressure injector compensation map size from

10x10 to 15x15 for M670
Calibration

software.
• Fixed DDE generation to correctly handle spaces and tabs in the

description field
Previously, including a new line or tab in the description field of Simulink

DD entry would cause the build to fail with a cryptic error. Now, the platform
replaces the characters with escape sequences.
• Fixed an issue with CCP DAQ security
Previously, CCP DAQ security would not apply to the simple memory
upload commands. Now, CCP DAQ security applies to simple upload
commands as well as DAQ lists.
Note

Change log

• Fixes to data dictionary processing for fixed-point value support
Previously, for values of integer type, the platform would ignore the
accuracy setting in the data dictionary and deffault to 0 decimal places.
This would cause problems for scaled fixed-point values. Now, all numeric
values support up to 6 decimal places.
Additonally, documentation has been added for the Scale and offeset
columns in data dictionaries. Please see the user guide for more
information.
Code generation

• Removed large function warning during build process when the

compiler is not Diab 5.5.1.0
When the model build process creates a very large function, there is a
known issue with Diab 5.5.1.0 in which the object code may not have
been generated correctly. The build system would generate a warning
whenever a function exceeds the size limit, regardless of which compiler
was being used. This change removes the warning when the compiler is
not Diab 5.5.1.0.
• Removed large image creation from Simulink model make files
Large image creation has been removed from the Simulink model make
files. The large images were necessary for older versions of calibration
tools, but the versions that required these files are no longer supported
by OpenECU.
• Updated Simulink-API-Examples
Updated all existing models and directories to follow snake_case naming

format. Updated all loom models to properly reflect changes made on
edited models. Updated examples.mdl to properly link to all edited/
renamed example files. Ensured each model properly built after edits, and
all outdated links were removed.
• Improved code generation with block reduction optimization

enabled for various blocks
If certain blocks inherited a constant sample time, then block reduction

optimization option would prevent the code from being generated.
Now, the appropriate blocks are prevented from inheriting a constant
sample time. Additionally, blocks that provide an output that need only

Change log
be fetched during initialisation have been changed so that they do

not fetch the value during each iteration of the model. The following
blocks have been updated: psc_BootBuildDate, psc_PrgBuildDate,
psc_AppBuildDate, psc_PlatformBuildDate, psc_BootVersion,
psc_PrgVersion, psc_AppVersion, psc_PlatformVersion,
psc_BootPartNumber, psc_PrgParNumber, psc_PlatformPartNumber,
preg_RetrieveKey.
• Fixed a problem with GCC model builds that used shared source
libraries
Previously, there was a problem creating the shared source target archive
when the model used GCC. Now, the problem has been fixed.
• Updated supporting scripts to prevent A2l generation failure when

a model contains unnamed subsystems
Previously, simapi builds would fail if the model contained subsystems

that were named exclusively with whitespace. Now, the supporting scripts
have been updated to substitute a default name for these unnamed
subsystems.
• Fixed GCC support with Simulink model referencing
Previously, simapi builds would fail if GCC was selected as the compiler
and the model used model referencing. Now, the makefile has been
updated so that the builds do fail.
• Fix to Simulink Data Dictionary handling of 2D arrays
Previously, during the build process for a model configured to use Simulink
Data Dictionaries which also uses 2D maps with different size X and Y
axis, an internal error would lead to missing ASAP2 entries in the A2L
file. Now, the internal error has been fixed and a warning message is
generated for unexpected issues.
Communications

ISO-15765 over CAN.
• Fixed accidental limitation of CCP ODTs
The number of ODTs available for the M670 target was inadvertently set
to 15. This has been changed back to 30.
• Added check on number of CCP configuration blocks in application

model

Change log
Previously, an application model would complete a build if it contained

more than two pcp_CcpConfiguration blocks. However, support is
provided for only one instance of the pcp_CcpConfiguration block. Now,
an error is raised if more than one configuration block is present in an
application model at build time.
• Improved robustness of freeze frame feature against uncontrolled

shutdown
Previously, an uncontrolled shutdown could leave the freeze frame feature

in a state such that it would not properly capture the next freeze frame.
Now, the freeze frame feature is more robust to uncontrolled shutdown.
• Diagnostics bug fixes
Fixed bug that could cause ECU to get stuck in a state where it constantly
tries to delete Freeze Frame data after clearing NVM.
Fixed issues with handling of NULL pointers, which could cause ECU to
reset.
Fixed byte-order bug in J1939 DM20 transmission.
Fixed timing issue in J1939 DM35 and DM37 messages.
Fixed in detecting RESPONSE_TOO_LONG error code
• Correction to DM40 B1 active timer resolution
J1939-73 specifies the resolution of the DM40 B1 timer, but not the
accuracy. Therefore, previously the DM40 B1 timer used an accuracy of
0.2 hr/count. This change improves the DM40 B1 timer to be 0.1 hr/count,
which is the same as the resolution.
decoding.
• Fixed an issue with the reported edge angles with multiple cam
inputs on M670
Previously, if multiple cam inputs were configured for the M670, the cam
edges returned by the pan_get_cam_wheel_teeth_angles() C-API
function or pan_CamWheelToothEdgeAngles Simulink block could be
incorrect even if the cam input has acheived synchronization after losing

Change log
sync with the crank wheel. A power cycle would be required to recover
from the issue. Now the cam input correctly reports the edge angles and
recovers after loss of crank sync.
• Extend SENT support for daughterboard to M670-N
Previously, support for the daughterboard SENT and H-bridge was

functional for M670-B variants but not M670-N variants. Now, SENT is
supported for both.
Previously, support for the daughterboard SENT functionality supported

pins XF3, XA2, XA3 and XA4. Now, to match the latest ECU design, pin
XF3 has been change to XA1. This change is not backwards compatible.
On loading a Simulink model that used XF3 for SENT, Simulink will emit
the following warning:
Warning: [...] Invalid setting in SENT_INPUT block (mask) 'pdx_SentInput'

for parameter 'pdxl_senti_chan'.
Simulink will replace the XF3 channel in the SENT block referred to in the
warning message to the default. To ensure the correct pin is selected, the
user must update the model to select XA1 where pin XF3 was used.
• Knock valid flag not updated if knock window end angle is before
start angle
Previously, if the application set the knock window end angle before the
knock window start angle, a knock window would not be generated. Since
the knock valid flag was updated in the eTPU knock window code, the
knock valid flag would remain at 1 (valid) even though no knock data was
being generated. This has been fixed such that the knock valid flag will
now be 0 in this situation.
• Make timeout parameter in pdx_PwmInput and pdx_FrequencyInput

calibratable online
Inputs which use an eTPU channel only updated the calibration value at
initialization, which allowed the timeout value to be calibrated offline, but
not online. This software change allows the timeout value to be calibrated
online.
• Fix incorrect injection duration for DI injections on M670
Previously, on the M670 targets, DI injections requested in the ranges N

* [15.88727, 16.38375] ms, where N is [1, 62] would result in an actual
injection clipped to the lower limit of the range. For example, if a 16.0 ms
injection was requested, then the actual injection would be set to 15.88727
ms. Similarly if a 32.0 ms injection was requested, then the actual injection
would be set to 31.77454 ms. Now, DI injections within the previously
mentioned ranges are not clipped, and should be set to the requested
value.
• Added M110 Technical Specifications

Change log
File is released as 29T-068883TK-xx-M110-Technical-Specification.
• Increase number of cam wheel teeth supported in

pan_CamWheelConfig
Previous limit was 8 cam teeth. This change increases the limit to 13.
• Clarified instructions on installing vendor daemon for lmadmin
The vender daemon executable must be added to the LmAdmin

installation directory in order to run. This has been added to the installation
instructions.
• Correction to synchronised PWM output with an out of range

frequency value
Previously, if an out of range frequency was used in the Sim-API

pdx_PwmSynchronisedOutput block or C-API pdx_spwm_output()
function, the output channel would not be initialised or driven correctly.
This could result in the wrong generation of PWM signals, or no PWM
signal at all. This has been corrected.
Target ECU

• Adjusted linker allocations such that .sbss variables are less likely
to be in external RAM
Previously, adaptive and diagnostic data would be allocated before

some .sbss variables. Now, all .sbss variables are allocated before
adaptive and diagnostic data. This reduces the chances of a problematic
eDMA transaction in external RAM.
• Fixed M221 operation with GCC compiler
Previously, M221 would build with GCC but would not run on target as the
non-VLE instructions used by GCC would cause the ECU to reset. This
issue has been fixed.
User documentation

and PDF formats.
• Fixed broken link in host ID pop-up

Change log
After OpenECU finishes installing, a web browser pops open with

hostid.html, which explains to the user how to request a license file.
hostid.html contains a link to the release note, but the link was not correct
for the installed filed locations. This issue has been fixed.
• Added clarification in M670 technical specification regarding turbo

speed inputs
Clarified in the M670 technical specification that pins Y20 and Y21 can be
used for any high-speed frequency input, not just turbo speed.
• Updated M670 technical specification ECU part numbers to latest

HW release
The ECU part numbers were updated to the latest released hardware part
numbers in the M670 technical specification.
• Updated M670 technical specification UEGO connection table
Previously, the M670 tech spec UEGO connection table listed UEGO
parts that are not supported by M670 without hardware options. To reduce
confusion, these UEGO sensors were removed from the table and a note
was added to contact OpenECU Support if a different sensor is required.
• Updated model appearance recommendations
Previously, the model appearance recommendations identified specific

blocks to avoid using. Now, a reference to the MAAB guidelines has been
added. Additionally, an outdated note about using calibrations has been
removed.
• Correction to M670 technical specification for resetting diagnostics

for Y1 and Y5
Previously, the M670 technical specification stated that toggling just the
DOT reset channel for pins Y1 and Y5 would clear the diagnostic monitor
faults. This has now been updated to state that the Y1 and Y5 outputs
must also be set low for 325ms to clear the faults, and to reset the device
to the default state.
• Fixed several minor errors found in OE version 2.5.0 release
Removed references to obsolete target ECU's X221 and G850.
Fixed broken links to the Pi Innovo website in user documentation .
Removed issue number from Technical Specification footer.

Change log
• Knock detection interface documentation improvement
The knock detection interface documentation was previously not

complete, and sometimes not very clear. This documentation has been
completed and clarified.
• Moved modeling and design section ahead of software detail in Sim-

API user guide
The modeling and design section contains a lot of useful information (such
as data dictionary naming rules) that will help the user get their models
correct the first time. This section was moved to the before the software
detail section at the recommendation of a customer.
• Corrected dimensions in M670 mechanical drawing
The dimensions shown in the M670 mechanical drawing in the M670

technical specification were previously incorrect due to the way the
software package converted the CAD file. This issue has been corrected,
and the dimensions in the drawing are now correct.
• Added injector resolution to user guides
The timing resolution of injection durations was added to the C-API and
Sim-API user guides.
• Diagnostic lamp interface documentation corrected
The documentation for the lamp input ports of

pdtc_DiagnosticTroubleCode and lamp output ports of
pj1939_Dm1Receive and pj1939_Dm2Receive were incorrectly specified
as Boolean data types. The data type for those ports have been corrected
to be Integer, and the encoding of those ports is now documented.
3.7. Release 2.5.0 (r2015-2)

Release labelled release-2.5.0-r2015-2 from 18 February 2016. This release is
marked as general meaning the release has been regression tested and is intended for
general use. The following table provides quick access to each of the changes.

compatible upgrade
13710 (F), 13710 (F), 14548 (F), 14545 (F), 13710 (F), 14428 (F),
12209 (F), 12174 (F), 14544 (F), 14460 (F), 13710 (F) 12174 (F)
10780 (F), 4257 (F), 14428 (F), 14388 (F),
4239 (F)

Change log

compatible upgrade
14382 (F), 14341 (F),
14338 (F), 14241 (F),
14075 (F), 14028 (F),
14027 (F), 14019 (F),
13601 (F), 13572 (F),
12626 (F), 12341 (F),
9400 (F), 8784 (F)
13769 (F), 13742 (F), 14548 (F), 14545 (F), 13710 (F), 14428 (F),
13710 (F), 13710 (F), 14544 (F), 14460 (F), 13710 (F) 12174 (F)
12209 (F), 12174 (F), 14428 (F), 14388 (F),
10780 (F), 4257 (F), 4239 14382 (F), 14341 (F),
(F) 14338 (F), 14285 (F),
14241 (F), 14075 (F),
14044 (F), 14028 (F),
14027 (F), 14019 (F),
13944 (F), 13601 (F),
13572 (F), 12626 (F),
12341 (F), 9400 (F),
8784 (F), 8586 (F), 8586
(F)
3.7.1. New features


developer software.
• Extended CCP to support 29-bit CAN identifiers
The platform now has the ability have CCP messages configured with 29
bit CAN identifiers.
The pcp_CCP_Configuration block has options available to select

extended ID mode for either the CRO or DTO messages.
The ccp-messaging group in the capi file has new flags, cro-ext-id
and dto-ext-id, to select extended ID mode for either the CRO or DTO
messages.
See the user guides for more details.
Code generation

• Added instructions on integrating a TargetLink model into

OpenECU

Change log
The new document openecu_targetlink_model_integration

describes the process of taking code generated from a TargetLink model
and building it into OpenECU.
Examples

• Added an example that uses model referencing
A simple example has been added to demonstrate model referencing with

OpenECU.
decoding.
• Addition of resistance based analog output for the M221 target
An analog output pin (A3) has been added to M221. The output creates a
variable resistance using a digital potentiometer. The C-API and Simulink
API have been updated for this new output.
Injector inputs and outputs have been repurposed as general purpose

digital IO.
Installation
OpenECU software is packaged with a simple installer and uninstaller. The

installation software can integrate OpenECU with supported applications,
such as MATLAB/Simulink and INCA, if those applications are first installed
before OpenECU.
• Unified OpenECU platform installers
Previously, there were two versions of the platform installer for 32bit and
64bit development environments.
Now, there is a single install wizard for all development environments.
Real-time operating system
The real-time operating system organises the sequence of application tasks,

task pre-emption and sharing of data between tasks, as well as sundry
functions, such as recording the duration of tasks.
• Added C and Simulink interfaces to record over-runs of periodic

tasks

Change log
The platform now counts instances of periodic task overruns. The C-API
function pkn_get_task_overrun_count() and Simulink-API block
pkn_TaskPeriodOverruncan be used to obtain the number of times a task
has overrun its period.
Target ECU

• Removed support for deprecated ECU targets
The following ECU targets are obsolete and longer supported:
• G850
• U82
• X221
• X657
• Removed support for obsolete interfaces
The following Simulink blocks are no longer supported by any ECU and
have been marked end-of-life:
• pem_AddRateForATIEmulator
• pan_AngularAnalogInput
• pan_AngularAnalogInputFixed
• pdx_PeriodInput
• pdx_StepperMotorOutput
• pdx_SteppedOutput
• pdx_TLE4953_Input
• ppp_Configuration
• put_Calmap1dTune
• put_CalValTune
The following C-API functions are no longer supported by any ECU and
have been marked end-of-life:
• pan_config_angular_ad()
• pan_config_angular_ad_fxd()

Change log
• pan_get_angular()
• pan_get_angular_ad_avg()
• pan_get_angular_ad_avg_fxd()
• pan_get_angular_ad_samples()
• pan_get_angular_ad_samples_fxd()
• pdx_period_input()
• pdx_stepper_output()
• pdx_stepped_output()
• pdx_tle4953_input()
• Use dedicated flash code sequence for memory test failure
Previously, a memory check failure led to a flash code of 1-2-1, i.e.

unknown error. This is now changed to use a new flash code of 1-2-8
indicating a memory check failure.
Note
• Added support for Mathworks MATLAB release R2015b (32-bit and

64-bit)
OpenECU has been extended to support the latest Matlab release.

Support for deprecated Matlab versions R2009b, R2010a, and R2010b
has been removed. Support for Matlab R2011a and R2011b have been
marked deprecated. Support for R2011a and R2011b will be removed in
a future release.
User documentation

and PDF formats.
• Add links from error codes to user documentation

Change log
Error and Warning codes are displayed while reading data dictionaries
and during the build process. This change adds links from the error codes
to the user documentation where each code is explained.


developer software.
• Fixed pnv_AdaptiveMap1d Simulink simulation behavior
Previously, the pnv_AdaptiveMap1d block would not correctly simulate in

Simulink. This has been resolved.
• Fixed unnecessary parameterisation of links to libraries
Previously, unnecessary parameterised links would be created to some

libraries that contained OpenECU blocks. Now, the initialisation behavior
has been changed such that links are only parameterised when
necessary.
Calibration

software.
• Fixed platform constants erroneously defined as calibrations
The platform software had some constants incorrectly defined as

calibrations. This has now been corrected.
Code generation

• Fix to name length limit for Units, Enums/Constants, and Lookup

variables in dde files
Previously, an error would be raised if the number of characters used

for units, enums, constants, or lookup variables exceeded 31 characters,

Change log
which could not be modified using the Simulink Model Configuration

Option 'Maximum data dictionary entry name length', or using the C-API
interface tool command line option '-n' or '--name-length'. Now the limit
can be modified using the previously mentioned options, which maintain
a 32 character limit by default.
• Fixed an issue which caused a misleading warning to be displayed

upon build failure
Previously, a cryptic warning (function restore_model not found) would

be printed when a build failed as a result of of an inaccessible s-record
or hex file. The warning obfuscated the true error message. Now, the
unnecessary call to restore_model has been removed and does not result
in a warning.
• Fixed type mismatch errors raised during model builds
Type overrides have been added to the compilation stage to prevent type
conflicts with OpenECU library types that have the same width as Simulink
types.
• Diagnostics updates to DTC fault status bits and positive response

suppression bit
Previously, the DTC Confirmed Fault bit was only set when a DTC was
active. Now, the Confirmed Fault bit is set when a DTC is active OR was
previously active.
DTC status bit 7 was previously unused. Bit 7 (UDS

warningIndicatorRequested) is now TRUE if the fault is active and is
configured to turn on any of the lamps.
There was a bug in the positive response suppression which would cause
a negative response to be transmitted in response to commands with the
suppression bit set, even if the diagnostic command was valid.
Examples

• Renamed extended_diagnostic_example
Previously, the extended diagnostics example would not build with

RTMODEL because the model name was too long. Now, the model
name has been shortened to ext_diag_example and can be built with
RTMODEL.

Change log
decoding.
• Optimized injector high side drive on the M670B module to reduce

faults
The injector outputs on an M670B module when driving large currents,

especially when injectors are overlapped across banks, can cause noise
internal to the ECU which can induce unexpected faults in the injector
driver ASICs (e.g. checksum faults). The injector outputs have been
optimized to reduce these faults.
• M670 injector SPI robustness changes
The SPI communications to the MC33816 devices internal to the M670

are susceptible to noise due to the high currents driven from the device.
Some changes have been made to improve the robustness of the SPI
communications with the MC33816 devices, and to recover from errors
more gracefully.
• M670 H-bridge over-current strategy improvement
The previous overcurrent strategy would disable the BTN8962TA H-

bridges if a single sample exceeded 10A. The new strategy heavily filters
the current and disables the BTN8962TA H-bridge if the heavily filtered
current exceeds 10.5A. This allows the H-bridge to remain enabled during
in-rush current transients.
Target ECU

• Fixed reprogramming driver sequence and timeout errors
Prior to this fix, the erase timeout did not scale with the erase size.
As a result, large erase operations could be prematurely terminated.
Additionally, a sequence error in the reprogramming driver could cause a
reprogramming timeout to go unreported.
Note

Change log
• Corrected M670 target platform library version
Previously, the platform library version for the M670 target was incorrectly
specified as 290. This would cause the incorrect major version to show in
some applications. Now, the target version is 500.
• Removed spaces from the name field in the INCA-ProF files for
OpenECU targets
Previously, the names for the OpenECU profiles contained spaces. The
name is used by INCA as a directory name during installation. On
some systems, spaces in the directory names have caused integration
problems. Now, the profile names do not contain spaces.
User documentation

and PDF formats.
• M220 H-bridge ready signal clarification.
The M220 technical specification did not adequately describe the H-bridge
ready signal. The M220 technical specification has been updated with the
full details of this signal.
• Clarified Hall/VR crank sensor build options in M670 technical

specification
In the previous version of the M670 technical specification, it was not clear
that the correct build option must be specified when ordering an M670.
This has been clarified, along with stating that the Hall-effect option is the
standard build option.
• Corrected revision and pull-up information in M670 technical

specification
The M670 technical specification has been updated with the correct pull-
up information on the spark outputs. The standard build versions that are
listed in the technical specification have also been updated to match the
lastest build package.
• Improved documentation of CANdb limitations

Change log
User documentation has been improved to specify the limitations of

OpenECU CANdb interfaces regarding multiplexed messages.
• Addressed M220 current monitor ambiguity
The M220 current monitors are not populated in the standard build, and
this was not clear from the technical specification. The M220 technical
specification was update to make it clear that the current monitors are not
standard, and a link was added to to the build options section.
• Added installation guide note about hard-drive encryption with

OpenECU
Some customers have experienced issues using OpenECU on encrypted

hard drives. A note has been added to the installation guides to provide
some guidance.
• Replaced OpenECU support email with link to the openECU support

webpage
Previously, all contact information directed the user to email Pi-Innovo with
any questions with regards to OpenECU support, but as of this time we
now have a support page detailing most common issues with OpenECU
and have decided to direct customers to there first.
• Removed all instances of UK-Office contact information from

contact sections of documents
In previous versions our contact information referenced the UK-Office

which is no longer a part of Pi-Innovo, and therefore was removed from
the contact section of the documents.
• M220 high-speed digital input filter frequency updates.
Corrected the filter corner frequencies for the high-speed digital inputs in
the M220 technical specification.
• Document inversion of crank input edge in M670 technical

specification.
The crank signal at the micro pin in the M670 ECU is inverted from the
signal at the connector. This inversion is now documented in the technical
specification.
• Improved documentation of CAN termination details

Change log
Example application loom diagrams have been updated to specify CAN

termination details.
• M220 output warning for power supply under/over voltage.
Added a warning to the M220 technical specification to state that digital

output behavior cannot be guaranteed if the power supply voltage is
outside of 7 - 32 V.
• M250 output warning for power supply under/over voltage.
Added a warning to the M250 technical specification to state that digital

output behavior cannot be guaranteed if the power supply voltage is
outside of 7 - 32 V.
3.8. Release 2.4.1 (r2015-1-sp1)

Release labelled release-2.4.1-r2015-1-sp1 from 2 November 2015. This release is
Table 3.5. Release summary for v2.4.1-r2015-1-sp1

compatible upgrade
C-API 14066 (F), 14065 (F) 14168 (F), 13937 (F), Yes Yes, see:
13926 (F), 7095 (F) 14168 (F),
14065 (F)
Sim-API 14066 (F), 14065 (F) 14210 (F), 14168 (F), Yes Yes, see:
14097 (F), 13937 (F), 14168 (F),
13926 (F), 7095 (F) 14065 (F)
3.8.1. New features

decoding.
• Added injector high side voltage monitors for M670
Voltage monitors for the injector high side output pins (Z1 and
Z5) were added for the M670B (01T-068787-03M00-000), M670N
(01T-068803-02M00-000), and M670S (01T-068850-02M00-000) and
later hardware targets. These inputs will not return valid results on
previous revisions of the M670 hardware.

Change log
• Updates to M670 I/O for recent hardware changes
The Z36 and Z37 pins on the M670B (01T-068787-03M00-000),

M670N (01T-068803-02M00-000), and M670S (01T-068850-02M00-000)
hardware targets have been internally remapped. This remapping is
handled transparently to the application, so no API changes are required,
however, the application must be rebuilt using a platform software release
of v2.4.1 or greater.
Note
to revision 2.4.1-r2015-1-sp1 or later. To upgrade the ECU's
firmware please contact OpenECU technical support as described
in Appendix A, Contact information.


developer software.
• Fixed an issue which caused warnings when a model was reopened

without clearing the workspace
Previously, an issue existed wherein some blocks would not be be

initialised if the model was opened, closed, and then reopened without
clearing the Matlab workspace. The issue has been fixed.
Code generation

• Fix Simulink model builds to include application checksum (CRC)

by default
Prior to the 2.2.0-r2013-2 release, Simulink model builds would, by default,

add a checksum (CRC) of the executable portion of the application to the
application image header. This would be checked by the firmware before
attempting to run the application. This checksum was incorrectly removed
by default in the 2.2.0-r2013-2 release. Beginning with the 2.4.1-r2015-1-
sp1 release, the generation of the checksum has been added back by
default to Simulink model builds.
Communications

Change log

ISO-15765 over CAN.
• Added documentation about how reprogramming inhibiting works

when the application does not use the inhibit functionality
Firmware (boot and reprogramming)
Each target ECU is delivered with firmware that enables various

functionality. Boot firmware determines what application to run on power-
up or reset. Reprogramming firmware allows the ECU to be reprogrammed
over various communication protocols. Test firmware allows the ECU to be
tested during manufacturing and return. Some changes to OpenECU require
the firmware to be updated. To upgrade the ECU's firmware please contact
OpenECU technical support.
• Fix to non-correctable Flash errors (ECC) on power-on for M670

ECUs
If power is removed during a reprogramming session, or while the non-

volatile data is being written to Flash, then the Flash can be left in an
indeterminate state. For the M670 ECU, it was previously possible for this
error to cause the firmware to enter a repeated reset state, which could
not be reprogrammed over CAN. The ECU would need to be returned
to OpenECU support for recovery. Now, the M670 firmware does not
enter the repeated reset state, and the non-correctable Flash error can be
properly erased and reprogrammed over CAN.
Note
to revision 2.4.1-r2015-1-sp1 or later. To upgrade the ECU's
firmware please contact OpenECU technical support as described
in Appendix A, Contact information.
decoding.
• Correction to M670N Z18 and Z29 waveforms set with the wrong
channel
The waveform for pins Z18 and Z29 can be left uninitialized due to a bug
in the platform where the waveforms for Z6 and Z17 are used for Z18 and
Z29. If the application never calls the prop_WaveformSetChannel block
for Z6 and Z17, the waveforms are left at all zeros.
• Fixed issue with H-bridge current-trip on M670

Change log
Previously, the M670 5A H-bridge would trigger a false current trip if invalid
parameters were supplied. This issue has been fixed.
3.9. Release 2.4.0 (r2015-1)

Release labelled release-2.4.0-r2015-1 from 13 July 2015. This release is marked as

compatible upgrade
13499 (F), 13019 (F), 13781 (F), 13720 (F), 13099 (F), 13099 (F),
12978 (F), 12906 (F), 13690 (F), 13647 (F), 12672 (F), 13019 (F),
12905 (F), 12723 (F), 13573 (F), 13519 (F), 11683 (F), 12905 (F),
12679 (F), 12672 (F), 13468 (F), 13256 (F), 11679 (F), 12841 (F),
12671 (F), 12463 (F), 13099 (F), 12841 (F), 11559 (F), 12463 (F),
12349 (F), 12345 (F), 12458 (F), 12200 (F), 8678 (F) 12200 (F)
12281 (F), 12279 (F), 11891 (F), 11706 (F),
12087 (F), 11969 (F), 11559 (F), 11298 (F),
11683 (F), 11680 (F), 11058 (F), 10778 (F),
11679 (F), 11678 (F), 10395 (F)
11677 (F), 11674 (F),
11594 (F), 10382 (F), 9683
(F), 9657 (F),
8678 (F)
13499 (F), 13309 (F), 13829 (F), 13781 (F), 13099 (F), 13099 (F),
13019 (F), 12978 (F), 13720 (F), 13690 (F), 12672 (F), 13019 (F),
12906 (F), 12905 (F), 13656 (F), 13647 (F), 11683 (F), 12905 (F),
12723 (F), 12686 (F), 13573 (F), 13519 (F), 11679 (F), 12841 (F),
12685 (F), 12684 (F), 13468 (F), 13325 (F), 8678 (F) 12463 (F),
12679 (F), 12672 (F), 13256 (F), 13170 (F), 12200 (F)
12671 (F), 12463 (F), 13099 (F), 12841 (F),
12349 (F), 12345 (F), 12773 (F), 12458 (F),
12281 (F), 12279 (F), 12200 (F), 12010 (F),
12087 (F), 11969 (F), 11891 (F), 11706 (F),
11683 (F), 11680 (F), 11299 (F), 11298 (F),
11679 (F), 11678 (F), 11058 (F), 11037 (F),
11677 (F), 11674 (F), 10778 (F), 10395 (F),
11594 (F), 11552 (F), 9682 (F), 9586 (F), 4440
10942 (F), 10382 (F), (F)
9683 (F), 9657 (F), 8678
(F)
3.9.1. New features



Change log

developer software.
• Added platform interfaces for the application to retrieve stable and

unstable reset counts
The free running counter of powered resets and the limited unstable reset
counter have been made accessible to the application through both C-API
functions and Sim-API blocks.
• Added support for Simulink Data Dictionary files for MATLAB

R2015a and later.
Support for Simulink Data Dictionary files has been added in R2015a
and later. Support for text based data dictionary files is maintained
for backwards compatibility. A model configured to use a Simulink
Data Dictionary can be configured to disable the naming convention
requirements, while still providing support for generating ASAP2 files, with
either OpenECU or Simulink's built-in ASAP2 support. For full details, see
the OpenECU Sim-API user guide.
• Added license checks when simulating or building models for 64-

bit Simulink
• Added continuously running memory tests for the primary

processor's eTPU peripheral
The platform tests eTPU code and data memory at platform initialisation
time. If the memory is faulty, the platform will raise an unrecoverable error
and reset.
The MISC feature has been enabled in the eTPU engine. If the eTPU
encounters a MISC error, then the platform will raise an unrecoverable
error and reset.
The platform checksums background parameter values, that are not under
control of the application. If a checksum error occurs, then the platform
will increment the associated fault counter. This is done for direct and port
injection functions.
New Simulink blocks and C-API functions have been added to read back
eTPU function parameters so that the application can verify the values are
correctly written to memory.
eTPU function Simulink block C-API function

Direct injection pan_InjectionSetpoint_DI pan_get_injection_di_setpoint()
Port injection pan_InjectionSetpoint_GPI pan_get_injection_gpi_setpoint()
• Added continuously running memory tests for the primary

processor

Change log
Continuously running internal RAM and ROM tests have been added for
the primary processor. Interfaces have been added to report the status
of the memory tests. The psc_decode_reset() C-API function and
put_Reset Simulink block have been modified to report memory corruption
as a potential reason for reset.
• Extended build-list handling of data dictionaries
A build-list may contain reference to a directory that does not contain a

data dictionary file. The directory is added to MATLAB's path, allowing the
directory to contain one or more library models that do not have their own
data dictionaries.
• J1939-73 (2013) specification update — new DM7 option added to

get all OBD test results for all required monitors
The option to obtain all the test results for all SPNs has now been added
(special TID 246) in line with the 2013 version of SAE J1939-73.
The interface to the pj1939_Dm30Transmit block and its corresponding C-

API function pj1939_dm30_transmit have also been revised to allow
a specific SPN and FMI for the given TID to be handled.
• J1939-73 (2013) specification update — Euro VI malfunction

indicator activation
The MI activation mode, the B1 counters and MI illumination counter are

now made available for the application to use in the J1939 DMs 36, 37
and 39. The MI activation mode can be used by the application to activate
the MIL appropriately as per UN-ECE Regulation No.49, Addendum 48.
New C-API functions are provided together with new optional outputs from
the pdtc_Status Simulink block.
• ISO 14229 (2013) specification update
The Negative Response Codes for various services now updated to match
those specified in the standard.
Multiple updates to conform to UDS services being allowed or otherwise

in the Default Diagnostic session.
Updates for systematic handling of suppress positive response bit for all
UDS services.
Updates for change in conditions to change state of DTC from Pending

to Clear.

Change log
Updates to exit from extendedDiagnosticSession upon receipt of a J1979

service request.
Updates to continue DTC settings which may have been turned off by
service $85, when we return to the Default Diagostic session.
Note
• Added definition of functional receive ID in piso_Configuration

block
Previously, no interface was provided for specifying the functional receive

message ID shared by all ECUs participating in OBD on a vehicle.
However, this defaulted to 0x7DF or 0x18DB33F1 as appropriate (the
standard OBD values from ISO 15765-4) depending on whether the option
was selected to use a 29-bit physical request ID.
Now a block parameter in the piso_Configuration block is provided so that

the user may specify the functional receive address explicitly, in line with
the C-API interface. The default block parameter values have also been
updated.
• Replaced interface for receiving and decoding J1939-73 DM1 and

DM2 messages
This change adds new C-API and Simulink interfaces for receiving and
decoding J1939-73 DM1 and DM2 messages. The old interface used a
single block to both indicate message reception and report the states of
a particular DTC. However, the message receive status was ambiguous
if multiple blocks were used to decode several DTCs from the same
message.
The new interface splits the decode functions into two C-API functions:
pj1939_dm1_receive to provide the overall message status, and
pj1939_dm1_decode_dtc for the values from each individual DTC of
interest (and DM2 equivalents).
Similarly the Simulink interface now has pj1939_Dm1Receive which

should be used just once to obtain the message receive status of a DM1
from some source, while multiple pj1939_Dm1DecodeDtc blocks can be
used to obtain values for different DTCs in the same message. Again,
DM2 equivalents are also provided.
Note that the functions pj1939_dm1_decode and

pj1939_dm2_decode or the blocks pj1939_Dm1Decode and
pj1939_Dm2Decode are kept for backwards compatibility but should not
be used. Also, the use of the new interface in conjuction with the old
interface in the same application can result in loss of status information.

Change log

• Modified M670 firmware for B, N and S variants to support both B-

sample and C-sample
Note
• Improved checksum tests for boot and reprogramming modes
Note
decoding.
• Extended support for up to 12 cylinders on the M670
• Extended support for up to 16 injector outputs on the M670
The M670 was previously limited to driving 8 outputs as injectors. This

has been extended to 16, covering both the 8 injector outputs and 8 spark
outputs.
• Changed I/O reconfiguration to allow more M250 channels to drive

sparks
Additional I/O channels have been assigned for spark use on M250 to
drive smart coil drivers.

Change log
• Added PDD digital data feature
A new Simulink block, pdd_DataInput and new C-API function,

pdd_digital_data_input(), have been added to read numerical
input values to the application. See the the user guide documentation on
this feature for more details.
• Changed I/O reconfiguration to use M220 as 4-cylinder gasoline

engine management system
Additional I/O channels have been assigned for injector and/or spark use
on M220 to determine if 4-cylinder gasoline engine control is feasible.
• Added support for angular digital outputs
For Sim-API, a new Simulink block, pan_AngularOutput has been added,

along with an associated pan_AngularOutputConfig block, to control an
angular output in a fairly generic way.
For C-API, a new function pan_set_angular_output() has been

added, along with an associated pan_config_angular_output()
function, to allow an output to be controlled in the angular domain in a
reasonably generic manner.
• Enhanced platform protection of output circuitry for M670 target
Additional protection has been added to the platform software functionality

to limit the time that output devices spend close to maximum temperature.
When devices exceed their operational temperature, the platform software
now disables those outputs for a minimum duration to allow them to
cool down. Details for specific outputs are set out in the M670 technical
specification.
• Added electrical diagnostics for the M670 smart ignition outputs
When the M670 spark outputs (pins Y37, Y38, Y39, Y40, Y44,
Y45, Y49, Y50) are used as PWM outputs or smart spark outputs,
the pdx_digital_monitor_input() C-API function or pdx_Monitor
Simulink block can be used to configure and retrieve electrical diagnostic
information.
When the same pins are used as smart injector outputs, there are no
electrical diagnostics available.
• Added support for wasted spark operation in M670 and other

MPC5xxx targets
Previously, spark ignition on targets other than G850 was limited to a

separate spark channel per cylinder, and sparks only began when full cam/
crank synchronisation had been attained.

Change log
Now, MPC5xxx targets such as M670 support shared-coil wasted spark

configurations, in which each ignition coil drives two spark plugs in series
(one for each of a pair of cylinders), where one spark achieves firing while
the other is a benign 'wasted' spark on the exhaust stroke in the paired
cylinder.
Additionally, 360 degree mode 'wasted spark' is also supported

(regardless of whether shared coils are in use). This means that sparks
begin on a 360 degree pattern before full cam/crank synchronisation is
attained. On average half the sparks will be 'wasted' in the exhaust stroke
but the other half will initiate firing. Overall this improves engine start by
causing firing before the engine has turned over enough times to confirm
full synchronisation. This is optional (except on G850 where it is always
done) as it is not suitable for certain engine configurations.
For non-G850 targets, it is no longer necessary to schedule every spark

before its on angle using the angular task, though that provides optimal
control of the timing. Spark angles may be updated at any time, but the
platform will produce only 4 sparks per channel before awaiting a new
update, so either a sufficiently fast periodic task or the angular task must
be used to ensure continual sparks are emitted.
• Enhanced port injection functionality on M220, M250 and M670

targets
The port injection functionality on the M220, M250 and M670 targets
has been extended to better match that of the G850 target. In particular,
an initial priming pulse is now supported, and split-fuel pulses are now
generated modulo 360 degrees after crank synchronisation but before full
engine synchronisation (i.e. before cam sync has been achieved).
For Sim-API, the initial priming pulse can be generated using the
pan_InitialInjection_GPI Simulink block, as for the G850. However the
interface differs slightly from the G850 in having an “enable” inport that
the application must use to actively request a pulse, and do so for each
instance of such a pulse.
The existing pan_Injection_GPI and pan_UpdateInjection_GPI Simulink

blocks have been extended with the addition of a “split_fuel_factor”
inport that dictates what fraction of the flow-time to use when not fully
synchronised. Again this differs slightly from the G850 target, which
always uses a fraction of a half.
For C-API, the initial priming pulse can be set up using

the pan_set_initial_injection_gpi() C-API function, as
for the G850. However unlike the G850, the pulse must
be actively invoked for each occurrence by calling the
pan_enable_initial_injection_gpi() C-API function.
The existing pan_set_injection_gpi() and

pan_update_injection_gpi C-API functions have been extended
with the addition of a panf_split_fuel_factor parameter that
dictates what fraction of the flow-time to use when not fully synchronised.
For the G850 target, a fraction of a half is always used and the argument
passed to this parameter is ignored.
• Added support for multiple cam wheels on M220 and M670 targets

Change log
It is now possible to configure and obtain angle, status and speed

information from more than one cam wheel with the M220 and M670
ECUs. Only one may be used to confirm engine cycle synchronisation,
and is considered the primary cam wheel. Reading the secondary cam
wheel(s) may be essential in variable valve timing applications should
angle feedback be required for a camshaft with variable phase.
• Added support for secondary crank wheels on M670 target
It is now possible to synchronise to multiple crankshaft wheels with the

M670 ECU, although the primary crankshaft wheel is still the only source
of crank angle. Crank movement, most recent crank tooth and crank speed
information is available for any secondary crankshaft wheel, as is the
phase angle between a secondary wheel and the primary wheel.
• Added ability to read A6, A38, A39 and A42 as PWM inputs on M220
(if populated in PCB build)
For the M220 target, the C-API and Sim-API now support reading pins
A38, A39 and A42 as PWM inputs. Pin A6 is also supported for PWM input
functionality as a build option, but this is not available by default. Contact
Pi for more details about build options on the M220.
• Added VR and Hall-effect mode select signals for the M220
The M220 hardware has input conditioning chips capable of processing

signals from both variable reluctance and Hall-effect sensors.
Previously, the internal signals required to switch from VR to Hall-effect

mode for these inputs were not available and they defaulted to VR mode.
Now, internal digital outputs have been made available to configure the
devices as desired, with one per ECU pin to select VR versus Hall-effect
mode and another to adjust the Hall-effect input voltage threshold.
Installation

before OpenECU.
• Added generation of license information to installer
Upon installation, a new file will appear containing the license HOSTID
information as well as instructions on retrieving a license.
Target ECU


Change log
• Added support for the M670 target ECU
Support has been added for the M670 target ECU, which comes in three
varieties:
ECU Build option

M670B Non-overlapping boosted peak and hold
01T-068787-000 Issue 2 solenoid injectors
M670N Overlapping non-boosted peak and hold
01T-068803-000 Issue 1 solenoid injectors
M670S Overlapping saturating solenoid injectors
01T-068850-000 Issue 1
The M670 ECU is a versatile, high performance electronic control module

designed for multi-cylinder (up to 8) engine management. There are three
main varieties of the M670 ECU but others are possible through build
options.
The design and architecture allow the ECU to be agnostic to fuel type
(diesel, gasoline, natural-gas, heavy-fuel, dual fuel), fuel injection type
(PFI, GDI, CRDI) and engine combustion cycle type (CI, SI, spark-assisted
CI).
The M670 supports a range of automotive sensors and actuators required

for precise engine management to meet the latest emissions standards
including Euro V and Tier 4. This includes support for advanced EGR and
aftertreatment controls.
In addition to the standard I/O, this powerful engine control module has
hardware support for the following advanced features that are critical to
modern day engine controls:
• Multiple injections per stroke
• Software configurable injector current profiles
• Software configurable injector boost power supply
• Dual intake and dual exhaust cam-shaft VVT control
• Measurement of inputs in the time and angular domains
• Precision constant current outputs
• E-GAS monitoring architecture for safety including secondary

microprocessor
Some functionality of the M670 can be adjusted by changing the PCB

population, changing the enclosure and designing daughter cards.
• Analogue and digital Pull up/down selection
• Fuel cooled (for higher power or temperature operation)
• LIN communications daughter board
• FlexRay communications daughter board

Change log
• Analogue output daughter board
Typical applications include:
• Stand alone engine control — heavy duty and light duty
• Diesel after-treatment controller for DOC-DPF and Urea-SCR

applications
• Engine plus hybrid supervisory controller in one module
• Stand-alone hybrid supervisory controller
• Stationary power engine controller
• Automatic transmission control
• Non-Powertrain applications
• Vehicle stability controller (ABS, TCS, ESC)
• Active chassis controller (Suspension, Ride Height)
• Advanced vehicle control and automation
Subsequent releases are expected to add support for the following

features:
• Compiler support — support for the GNU GCC compiler when targeting
the primary processor (MPC5674F) and support for Freescale's S12
compiler when targeting the secondary processor (S12G).
• Secondary processor — support to develop applications for the

secondary processor in the same manner as the primary processor.
Currently, the secondary processor has no effect on the ability of the
primary processor to drive outputs.
• Target M220 revision 3 is marked deprecated; support will be

removed in a future release of OpenECU software
• Added support for Mathworks MATLAB release R2015a (32-bit and

64-bit)
• Added support for Mathworks MATLAB release R2014b (32-bit and

64-bit)
• Added support for Mathworks MATLAB release R2014a (32-bit and

64-bit)

Change log
User documentation

and PDF formats.
• Updated terms of the license agreement
The license agreement is included with the installer (must be

accepted to install) and installed along with the developer software as
OpenECU_Developer_Software_License_Agreement.rtf.
• Removed technical specifications from user guides
The technical specifications have been removed from the C-API and Sim-
API user guides. The technical specifications continue to be available from
the Windows Start button, in both HTML and PDF formats.


developer software.
• Default stack size increased to 8192 bytes
The default stack size has been increased from 5120 to 8192 bytes. Note
that the amount of stack required depends on the application, and it is
strongly recommended that the actual stack use for any given application
be monitored, and the stack size be adjusted accordingly. Note also that
the stack use may change depending on the version of MATLAB used to
build the model, and various MATLAB build options.
The stack use can be monitored over CCP by reading the automatic
variable mpl_max_used_stack that is defined in the A2L file produced
when building the application. Within the application, it can be monitored
using the OpenECU psc_StackUsed block. This gives a high-water mark
of stack use, i.e. the maximum depth of stack since the ECU was powered
on or reset.
If the stack size is not large enough for the application, an access
exception will occur when the application is running. This can be checked
by monitoring the “access_reset” output of the OpenECU put_Reset
block. If such an exception occurs repeatedly (for example if the stack

Change log
consistently overflows within 60 seconds of powering on the ECU) then

the ECU will subsequently remain in bootloader mode, flashing 1, 1, 7 on
the flash code output. If this happens then increasing the stack size is
recommended as a likely solution.
The amount of memory allocated to the stack can be set explicitly

using the “OpenECU code generation options” page of the Configuration
Parameters or Model Configuration Parameters (Ctrl+E) window in
Simulink. See the Sim-API User Guide for further details.
• Example applications' stack size increased to 8192 bytes
The stack size used in the example applications (included in the installer
package) has been increased from 5120 to 8192 bytes. Note that the
amount of stack required depends on the application, and it is strongly
recommended that the actual stack use for any given application be
monitored, and the stack size be set accordingly.
For C-API, the stack use can be monitored over CCP using the
automatic variable mpl_max_used_stack that is defined in the A2L file
produced when building the application. It can also be monitored within
the application by calling the psc_get_used_stack_size() C-API
function. This gives a high-water mark of stack use, i.e. the maximum
depth of stack used since the ECU was powered on or reset.
If the stack size is not large enough for the application, an

access exception will occur when the application is running. This
can be checked through the pscf_access_reset parameter of the
psc_decode_reset() C-API function. If such an exception occurs
repeatedly (for example if the stack consistently overflows within 60
seconds of powering on the ECU) then the ECU will subsequently remain
in bootloader mode, flashing 1, 1, 7 on the flash code output. If this
happens then increasing the stack size is recommended as a likely
solution.
The amount of memory allocated to the stack (in bytes) must be set
explicitly through the stack-size statement in the capi file. See the C-
API User Guide for further details.
• Fixed undefined outputs and possible high CPU load from cam
wheels that have failed configuration
A cam wheel can be left unconfigured if certain rules are broken, such
as the acceptance window straddling the missing hole region. Previously,
accessing cam information such as the synchronisation status, speed, or
edge angles for such a cam wheel gave ill-defined results, and could result
in high CPU load.
Now, any attempt to access cam information for an unconfigured cam

wheel results in well-defined zero values, and (for C-API users) a suitable
error code. The related high CPU load condition has also been addressed
by this change.
• Changed the enumeration type for H-bridge drive modes

Change log
The new enumeration type to use is PIO_HBRIDGE_MODE_T from

C include file pio.h. This replaces PDX_HBRIDGE_MODE_T from
C include file pdx.h. Customer applications must be modified to
use the new enumeration. All four names of the enumeration
values have also changed. See the C-API user guide for function
pdx_hbridge_output().
• Added temporary work around for conflict between MATLAB and

OpenECU for a system called “pan”
OpenECU includes a library model named pan.mdl. This clashes with

a MATLAB file named pan.m. Running which -all at MATLAB's
command prompt shows that MATLAB treats pan.m as shadowed after
OpenECU in installed.
[...]\openecu\model\pan.mdl
[...]\toolbox\matlab\graph2d\pan.m % Shadowed
And when pan.m is invoked, a number of errors can occur.
Error using putdowntext (line 157)

Simulink model 'pan' was called with incorrect number of arguments
Error while evaluating uitoggletool ClickedCallback
As a temporary work around, there is now a MATLAB script included

with OpenECU called oe_adjust_model_path.m. The script can be
used to manually avoid MATLAB raising an error about a conflict between
pan.mdl and pan.m.
The script works by reordering entries in MATLAB's path. Specifically the

path to OpenECU library models can be moved from the beginning of the
list of paths (where it is normally situated) to the end of list of paths, and
back again. To set the OpenECU library model folder at the beginning
of the path, and hence give the pan.mdl higher precedence, run the
command.
oe_adjust_model_path('begin')
To set the OpenECU library model folder at the end of the path, and
hence give the internal MATLAB pan.m function higher precedence, run
the command.
oe_adjust_model_path('end')
We have found during testing, that if the OpenECU library model folder
is left at the end of the path, it was possible to open and build OpenECU
models, even though warnings were displayed about the “pan” shadowed
file. If you are able to still build with the model path at the end, then you
might be able to just leave it at the end of the path.
If not, then the oe_adjust_model_path script must be used to load and

build models as follows:
To open an OpenECU model:

Change log
oe_adjust_model_path('begin'); open('model');
To build an OpenECU model:
oe_adjust_model_path('begin'); rtwbuild('model');
This temporary work around will be replaced in a subsequent version of

OpenECU.
Calibration

software.
• Fixed use of propagated signal names for map lookup points during
ASAP2 generation
• Increased number of 4-byte CCP parameters from 60 to 120 for M670

target only
This change temporarily reduces the amount of workspace RAM available

to the application by 2096 bytes.
A subsequent version of OpenECU will add the ability for the application
to define the number of CCP DAQs and ODTs.
Code generation

• Fixed issue when using the large image from a model build using
the GNU GCC compiler
Previously, an issue was identified whereby the OpenECU platform would

generate incomplete large memory images during Simulink builds, when
using GCC as the target compiler. This would lead to repeated application
resets when an ECU was programmed using with the large memory
image. This issue is now fixed.
• Corrected maximum DDE length option for ASAP2 generation from

Simulink
Previously, the maximum data dictionary entry name length option in

Simulink models would not be used during ASAP2 generation, resulting in
truncated ASAP2 variables at 31 characters no matter what size was used

Change log
in the model. Now the maximum length should be correctly used from the
Simulink model option.
• Fixed use of inherited sample time in triggered subsystems for some

blocks
Previously, an issue was identified whereby the OpenECU platform would

not correctly inherit the sample time during Simulink builds when using
any of the following blocks within a triggered subsystem, leading to failed
application builds.
• pai_AnalogInput
• pdx_DigitalInput
• put_FaultCheck
• put_SlewRateCheck
Communications

ISO-15765 over CAN.
• Corrected some general parsing issues of CANdb files
Previously, an issue was identified whereby the CANdb blocks would emit
errors when reading a CANdb database that had reserved words in the
node names or signal names. Additionally, the blocks would emit errors
when multiple senders were specified for the same frame in the the CANdb
file. These issues have been fixed.
• Corrected parsing of floating point numbers in CANdb files
In certain cases, the platform would raise an error when trying to parse a
negative floating point number in CANdb files. This problem has be fixed.
• Corrected packing of negative values into CANdb transmit

messages
Previously, data values passed into the C-API pcx_vdb_pack_msg()

function or Simulink-API pcx_CANdb_TransmitMessage block could
become erroneously clipped to a large positive or negative integer
depending on the sign of the data and its scale and offset parameters from
the CANdb file. This has been fixed.
Developer and supporting scripts/documentation
Changes related to OpenECU's development environment.
• Disabled Diab compiler error when using Simulink lookup blocks

Change log
When building a model that uses Simulink lookup blocks, the Diab
compiler raises an error about a mismatch between Mathworks' lookup C
function prototypes and OpenECU calibrations. The Diab compiler options
have now been enhanced to turn the error into a warning that allows
compilation to continue. However, the Diab compiler continues to emit a
message:
'[model].c', line [line]: warning (dcc:1792):

The message should be ignored.
• Extended diagnostics example model and related library fixes
The extended diagnostics example model has been modified to no longer

emit a J1939 ACK when it also sends a full reply, and the TID/SPN/FMI IDs
used in the DM7/DM30 section have been modified to give more useful
responses.
The platform library has been modified so that the logic which clears
active, or inactive, faults intended to be called in response to J1939
requests now clears faults which any matching type, not just pure J1939
type as before.
Diagnostic Test Entity (DTE) results are now cleared when pdtc_ClearAll
is used, as appropriate for a J1939 DM11 request. Additionally, DME
status values (monitor run, monitor readiness) are also now cleared
automatically, whereas previously this was done only by the user
application making use of the "force incomplete" option.
The pdtc_TableCleared block also now correctly reports when DTCs are
cleared via pdtc_ClearAll.
• Corrected handling of corner cases in ISO 15765-2 protocol
A few instances of behaviour that did not strictly conform to ISO 15765-2
were identified. For example, ignoring unexpected frame types from the
test tool (while continuing to receive or send a segmented message) and
ignoring zero-length messages. These were corner cases that would not
normally be apparent with a real test tool. These issues have now been
fixed.
The implementation of the PISO feature is used in the reprogramming

firmware for UDS reprogramming, so to that extent it is also affected.
Note

Change log

• Updated how the calculation of CVN is handled
Changes made to take care of the difference in handling of request for

CVN in the September 2013 update of the ARB specification containing
the heavy duty OBD regulation order 1971.1. The platform now maintains
a copy of the latest calculated CVN in NVM. This enables the platform
to immediately report the CVN as computed in a previous power cycle,
rather than having to emit a pending response if it is asked for it before
the computation in the current run has finished.
• Corrected handling of exception when a DME or DTE is set to neither

J1939 nor ISO type
Updated to check for DTE and DME types to be either ISO or J1939 or
both and raise error if none of the choices are selected. Previously a build
exception occurred which did not usefully describe what was wrong.
• Corrected handling of received J1939 PGNs when also using the

DM1 or DM2 decode blocks
Previously, a Simulink application with a generic J1939 receive block that

also had DM1 or DM2 decode blocks, would incorrectly decoded received
PGNs of 0xFECA (DM1) or 0xFECB (DM2). This has been fixed.
Examples

• Correction to the M220 NVM example
Previously, the M220 NVM example incorrectly set the power hold state
during shutdown. This issue has been fixed.

• Corrected handling of CCP security in development mode

Change log
Previously, an issue was identified whereby the firmware would not honour
FEPS override of CCP security settings when CCP development mode
had been enabled in the application. This issue is now fixed.
Note
• Corrected firmware issue that could leave ECU non-communicative
Previously, if the application or calibration areas of flash memory were left

improperly programmed, the firmware (boot loader) could get stuck in an
infinite reset loop, even if positive or negative FEPS was correctly applied.
Such improper programming could result for example from ECU power
being lost during flash reprogramming.
The M220 was particularly vulnerable to this problem, because the power
hold function was enabled by default in application mode, such that ignition
voltage could be removed and the ECU would keep itself powered from
the Vpwr input. However, if flash reprogramming was initiated in that
state, power hold was disabled on the transition to programming mode,
and the ECU stayed powered just long enough to begin the flash erase
(at least at higher supply voltages) before powering down. This made
misprogramming of the flash relatively likely to occur.
The reset loop issue has now been fixed and M220 now defaults to leaving
power hold disabled in application mode.
Note
decoding.
• Correction to DI and GPI functions for schedule update close to on

angle
Previously, if the schedule for a DI or GPI output was updated near the
on angle for the first pulse in the schedule, it was possible for either the
schedule to be skipped for the next engine cycle, or for the injector output
to be turned on for the duration of the next engine cycle. This issue has
been fixed.

Change log
• Correction to crank input processing of noisy trigger wheel inputs
Previously, it was possible for a noise pulse, occurring around the

transition of the last tooth before the crank gap, to cause the crank input
to stop processing further teeth and generating angular event tasks. All
angular events would essentially stop when this occurred. Now, the crank
input is more robust to noise pulses, which should not cause the crank
function to stop processing teeth, or generating angular tasks, but may
still cause the crank to stall.
• Corrected reset of ECU if crank speed increases too quickly
Previously, a bug existed where the ECU would reset if the crank input
RPM increased by too high an amount in a single step. This issue is now
fixed.
• Corrected handling of PWM output when changing from non-zero

duty to zero duty
A problem was identified when changing the PWM output from a non-zero
to a zero duty. If such a change was made when the output was in its active
state (i.e. during the duty stage), then for one period after the change the
output would go into its active state, before becoming inactive to reflect
the new duty. This problem has now been addressed.
Non-volatile storage
Storage of data across power cycles, including 1-d and 2-d adaptive map
updates using reverse interpolation.
• Removed compiler warning when building some applications that

use adaptive variables
Previously, when compiling some applications that used adaptive

variables using the Diab compiler, the compiler would issue this warning:
[...]: Quoted section name can't be empty, set to: .text
This issue was likely to occur when using Simulink Embedded Coder and
Diab 5.9. The warning message would not affect the operation of the
model when running on target.
• Corrected non-volatile memory block mask parameter issues and

documentation
Previously, if non-volatile memory blocks were used inside a masked

subsystem, and used parameters from the mask, the resulting model
would not build. This has been fixed.
Additionally, the user documentation for the pnv_AdaptiveChecksum and

pnv_Status blocks has been updated to better reflect the usual non-

Change log
volatile memory storage option now being flash, rather than battery-
backed RAM.

• Corrected application reset if pan_EngineConfig block is present

with no angular task logic for G850 target
An application will no longer reset when a TDC task event is generated

if the model has a pan_EngineConfig block with the 'Provide TDC calc
trigger?' box unchecked.
• Fixed warnings about shadowed files from MATLAB R2013b when

a model build-list contains relative path entries
Previously, with MATLAB R2013b, if a model build list included relative

build list entries, for instance, ..\test_library\tll, MATLAB would
emit warnings about shadowed models when no model was shadowed.
This issue would not occur with MATLAB R2008b.
Now, the oe_read_build_list script works around this issue when

adding build list entries to MATLAB's path by resolving the relative parts
to absolute paths.
User documentation

and PDF formats.
• Corrected M220 technical specification for digital input A11
The information for the M220 digital input on pin A11 has been updated
to reflect changes to the hardware from rev 4 onwards. The input is now
inverted, and the thresholds for high and low values are slightly different
to what was previously published.
• Corrected documentation for the PWM output blocks (removal of

“sample time” mask parameters)
• Documented that the M461 default CCP settings differ from normal
(250 kBps rather than 500 kBps)

Change log
3.10. Release 2.3.0 (r2014-1)

Release labelled release-2.3.0-r2014-1 from 28 October 2014. This release is marked

compatible upgrade
11497 (F), 11475 (F), 12365 (F), 12271 (F), 10987 (F) 11427 (F),
11427 (F), 11355 (F), 12259 (F), 12244 (F), 11222 (F),
11320 (F), 11234 (F), 12189 (F), 12144 (F), 11220 (F),
11222 (F), 11221 (F), 12101 (F), 12097 (F), 11219 (F),
11220 (F), 11219 (F), 12089 (F), 12004 (F), 11086 (F)
11086 (F), 10987 (F) 12000 (F), 11928 (F),
11918 (F), 11623 (F),
11602 (F), 11572 (F),
11554 (F), 11479 (F),
11205 (F), 11072 (F),
11047 (F), 11035 (F),
10680 (F), 8758 (F), 6811
(F), 4197 (F),
2786 (F)
11497 (F), 11475 (F), 12638 (F), 12559 (F), 10987 (F) 11427 (F),
11427 (F), 11355 (F), 12365 (F), 12271 (F), 11222 (F),
11320 (F), 11234 (F), 12259 (F), 12244 (F), 11220 (F),
11222 (F), 11221 (F), 12189 (F), 12144 (F), 11219 (F),
11220 (F), 11219 (F), 12101 (F), 12097 (F), 11086 (F)
11086 (F), 10987 (F), 12089 (F), 12014 (F),
10739 (F), 10724 (F), 12004 (F), 12000 (F),
9721 (F), 7309 (W) 11928 (F), 11918 (F),
11894 (F), 11627 (F),
11623 (F), 11602 (F),
11572 (F), 11554 (F),
11479 (F), 11458 (F),
11205 (F), 11072 (F),
11047 (F), 11036 (F),
11035 (F), 10680 (F),
10488 (F), 9640 (F), 8758
(F), 6811 (F),
4197 (F)
3.10.1. New features


developer software.

Change log
• Add new CCP interface to count receive messages
Added new C-API function pcp_get_rx_count() and Simulink block

pcp_CCPRxCount to obtain the number of CCP messages received by
the ECU since the most recent reset.
• The put_DisplayRates block is deprecated
The put_DisplayRates block does not always display the correct rates.
This block is now deprecated and will be removed in a future release.
Please use the Simulink Sample Time Legend instead.
Calibration

software.
• Added a CCP security algorithm development mode of operation

and CCP security functionality for applications built with GCC
Simulink and C-API interfaces have been added for enabling CCP security
algorithm development mode. In this mode, security is disabled when the
ECU enters reprogramming mode as a result of application of FEPS during
startup. This mode allows customers to recover from a flawed security
routine.
Support has been added for CCP security in applications built with GCC.
If the security algorithm is supplied as an object file and the compiler is
GCC, then the object file must not use Variable-Length Encoding (VLE).
Note
Code generation

• GCC builds now support DTCs and extended diagnostics
The platform libraries, build settings, and necessary support files have
been updated to allow applications which utilise the DTC and extended
diagnostics features to be built with the GCC compiler.
• Support extended memory configurations for GCC builds

Change log
The linker scripts, checksum calculation, capi utility s-record output,

and MMU mappings have been revised to support a common alternate
memory configuration scheme that is compatible with both Diab and GCC.
• Support for adaptive variables to GCC builds
Applications which use adaptive parameters can now be built with GCC.
• New option to control ATI Vision flash voltage setting
The RTW configuration dialogs now have a check box to control if the
generated ASAP2 file for ATI Vision sets the flag to require flash voltage.
The CAPI tool now supports the --need-flash-voltage command-

line option to indicate the flag is set.
The default setting for builds no longer sets this flag; G850 users should
be aware that they need to manually check the box in RTW or add the flag
to their build scripts for C-API.
• Added warning messages when the data type of a DDE differs from
the generated C code
It is possible for Simulink Coder to generate code from a model that uses a
different data type for a signal, than the type defined by the corresponding
data dictionary.
A common example involves the Boolean data type. When using Simulink
Coder with either of RSIM or RTMODEL, the data dictionary can specify a
signal should have type Boolean, but the generated code can have data
type real_T (representing the signal type double). The generated code
will use four data bytes to store the signal but the generated ASAP2 file
will expect a single data byte to be allocated. When the calibration tool
attempts to read the signal, it will read the first data byte of four, showing
the wrong value on screen (usually 0 and 63, instead of 0 and 1).
The same is not true when using Embedded Coder. Embedded Coder will
check the data type of the signal against the data type of the corresponding
variable in MATLAB's workspace. When a mismatch is found, Embedded
Coder emits an error message and does not complete building the model.
To provide a similar check when using Simulink Coder with either RSIM or
RTMODEL, OpenECU will now check the data type generated by Simulink
Coder against the type in the data dictionary. When a mismatch is found,
a message is generated at the end of the model build. The message is
only a warning, allowing existing models with mismatches to continue to
build as before.
• Allow inclusion of library models and data dictionaries via relative

paths

Change log
The oe_read_build_list.m script has been enhanced to allow directories

to be referenced using a relative path, e.g. ../../my_lib/lib. This
facilitates re-using common model elements between different OpenECU
application builds.
• Updated GCC support from version 4.7.2 to 4.7.3
Previously, OpenECU distributed and supported GCC version 4.7.2 built

for the powerpc-eabi target. The GCC cross compiler for the powerpc-eabi
target does not generate code with SPE instructions. SPE instructions
provide hardware support for floating point operations in the PowerPC
e200 core microprocessor family.
Now, OpenECU distributes and supports GCC version 4.7.3 built for
the powerpc-eabispe target. The GCC cross compiler for the powerpc-
eabispe target generates code with SPE floating point instructions. This
minimises the use of software floating point routines, thereby decreasing
the code size and execution time of OpenECU applications that are built
with GCC.
• Added UDS $19 ExtendedDataRecord support
Diagnostic support for UDS service $19 has been expanded to

support subfunction $06 reportDTCExtendedDataRecordByDTCNumber.
The additional sub-function necessitated the addition of a new Simulink
block and corresponding C-API tool options.
• Added support for application routines for UDS routineControl

service $31
Previously, UDS $31 routineControl was only supported for platform

routines. Now, routines can be defined in the application that can be
controlled by routineControl requests.
A new pgd_RoutineControl has been added to facilitate the interface

between a Simulink application and the diagnostic tool.
For C-API applications, two new interface functions have been added to
facilitate communications between the application and the diagnostic tool.
Note

Change log

• Added controlEnableMask handling for UDS $2F

InputOutputControlByIdentifier
Diagnostic PIDs can now be configured to accept the optional

controlEnableMask field in UDS $2F requests to “override” the PID. The
number of bytes of such data and their values are now made available
via both the Simulink block and C-API interfaces. The user application is
responsible for any use of these bytes, e.g. to selectively apply override
data only to certain devices.
• Added support for UDS services $2A and $2C
UDS service $2A allows the test tool to request that the ECU begin
automatic periodic transmission of one or more PIDs in a predefined range
until further notice.
UDS service $2C allows the test tool to define a new PID in terms of other
PIDs (or parts of them) and/or direct memory accesses.
These new services are now both supported by the platform library,
with new configuration items to control the memory reserved for these
functions.
Note
• Added support for UDS service $24 ReadScalingByIdentifier
UDS service $24 ReadScalingByIdentifier allows a test tool to determine

from the ECU how to interpret the raw data bytes returned by service $22
ReadDataByIdentifier for some data item (PID). This includes the scaling,
data size and real-world units for each value.
The ppid_Pid Simulink block has now been enhanced to allow the user
to configure the information that should be returned for that PID if service
$24 is used to request the scaling information. The raw data to be returned
for a $24 request can also be set as a C-API configuration file item.
The correct preparation of suitably-scaled value bytes for each PID

remains the responsibility of the application, and is not affected by this
change.

Change log
Note

• Add flash code to indicate last reset was due to the watchdog
A new flash code, 123, has been added to indicate if the last reset was due
to a watchdog over-run. The flash code is active for both reprogramming
mode and application mode. See the technical specification for your ECU
for more information about flash codes.
Note
Installation

before OpenECU.
• Add installation guide note about a known issue with Python
If another package installs Python globally to the Windows system

directories, this may cause the OpenECU installation of Python to fail. The
note in the installation guide details a work around.
User documentation

and PDF formats.
• Added document that provides an overview of the OpenECU Sim-

API

Change log
The document contains a short summary of the available blockset.

The document is available with other OpenECU documentation, via the
Windows start menu.


developer software.
• Corrected block checking of target ECU
Previously, not all blocks would correctly check whether they were
supported by a target ECU. This lead to situations where a build of a
model containing a block that was not supported, would lead to a linker
error, sometimes using a name unrelated to the block. For instance, on the
M220, the pss_OutputControl block failed the target check, and emitted
the following error when included in a model build:
[model], line [num]: warning (dcc:1500):

function pss_set_safety_switch has no prototype
dld: warning: Undefined symbol 'pss_set_safety_switch' in file [model]
dld: error: Undefined symbols found - no output written
Now, all blocks perform a target ECU test before allowing a model build
to proceed.
• Improved error messages on invalid ECU issue number
Previously, selecting an invalid issue number (e.g. issue 1 for M250) in

the put_Identification block could cause a large number of error messages
from dependent blocks, without making the root cause obvious.
Now a specific error message is emitted if an unsupported issue number is

used, to make it easier for the user to understand and rectify the problem.
• Change to checks on pan_CamWheelConfig block to ignore number

of cam teeth when not relevant
The pan_CamWheelConfig block has a mask parameter Wheel teeth

which is only displayed when the Wheel type parameter is set to “Multiple
teeth”. However the block was still checking this field for other wheel
types where it was not relevant, resulting in an unhelpful error message
relating to a hidden parameter. Those unnecessary checks have now
been removed.

Change log
• Clarified C-API user documentation for H-bridge and TLE-4953

functions
Calibration

software.
• FreeCCP invocation from MATLAB fixed, but now deprecated
Previously, using FreeCCP to flash an ECU from the MATLAB command

line failed due to a missing space in the oe_freeccp.m script. This has now
been fixed.
FreeCCP has however been marked as deprecated in both the Simulink

and C-API user guides. A warning has also been added that it does not
work with Vector interfaces under 64-bit Windows 7. Please request a free
trial of PiSnoop to get started with OpenECU unless you have another
calibration tool to use.
• Fix to DDE comment parsing
Previously, if a data dictionary file was saved such that comments are
wrapped in quotes by the editing tool, the platform would not detect it as
a comment and throw an error.
This has be fixed such that comments are parsed as expected.
Code generation

• Correction to remove duplicate compilation of model sources
Previously, model builds resulted in duplicate compilation and linking of

model source files. This has been fixed.
• Correction to GCC ELF/DWARF parsing for ASAP2 generation
Previously, if the last entry in a GCC DWARF DIE list was an array then
the C-API tool would generate an error about an array index during ASAP2
generation and prevent an application build from completing. This has
been resolved.
The C-API tool worked correctly in the same circumstances with a Diab
ELF/DWARF file.

Change log
• Unify GCC and Diab linker script generation
Provided common linker script generation mechanisms for both Diab

and GCC OpenECU application builds. This is particularly relevant for
extended memory configurations and CCP security.
• Correction to pdg_ExtendedDataRecord block mask
Previously, the pdg_ExtendedDataRecord block did not correctly show the

failed drive cycle count option. This has now been corrected. The issue
only affected customers with special releases of the library made since
v2.2.0 (r2013-2).
• Return to defaultSession on ISO diagnostic session timeout
Previously, if no communications with the tester were exchanged for the

duration of the S3(Server) timeout of 5 seconds, PID overrides were
cancelled and the security status was reset, but there was no automatic
transition from extendedSession to defaultSession. That transition is
implied in the ISO 15675-3 description of S3(Server). Now that transition
is made.
Note that an exit from programmingSession was already made after the
5 second timeout (causing a reset back into application mode and the
defaultSession), but only if at least one tester request had been made, or
if reprogramming mode was entered as a result of a programmingSession
request in the first place. That strategy is unchanged, and ensures that if
reprogramming mode is entered for some other reason (e.g. FEPS start
or CCP reprogramming) there is no automatic reset.
• Fixed support for reporting the diagnostic session type with a

special ISO PID
Changes for CR 11220 (F) inadvertently broke the mechanism for

reporting the current diagnostic session type with a special PID. It has
been repaired.
• Fixed Simulink block pdtc_DiagnosticTroubleCodeExt issues
Previously, there was a mismatch between certain Simulink block

pdtc_DiagnosticTroubleCodeExt checkboxes being ticked and the
corresponding fields being made visible, and one parameter at the bottom
was visible in error. Those problems are now fixed.

Change log
These problems were introduced after release v2.2.0 (r2013-2) and so

were visible only to selected customers using bespoke releases of the
platform library.
• Correction to assignment of diagnostic related blocks to licenses
To match previous releases, the following diagnostic C-API functions and

Sim-API blocks are available through a standard license.
C-API Sim-API
pdtc_update_j1939_dtc() pdtc_DiagnosticTroubleCode
pdtc_clear_all() pdtc_ClearAll
pdtc_clear_all_if_active() pdtc_ClearAllIfActive
pdtc_clear_all_if_inactive() pdtc_ClearAllIfInactive
pdtc_commit_to_store() pdtc_Memory
pdtc_is_store_intact()
- pdtc_Table
pdtc_enable_periodic_lamp_updates() pdtc_EnablePeriodicLampUpdates
- pj1939_Configuration
pj1939_dm1_decode() pj1939_Dm1Decode
pj1939_dm1_transmit() pj1939_Dm1Transmit
pj1939_dm2_decode() pj1939_Dm2Decode
pj1939_dm2_transmit() pj1939_Dm2Transmit
pj1939_was_pgn_requested() pj1939_PgRequested
pj1939_pg_receive() pj1939_PgReceive
pj1939_pg_transmit() pj1939_PgTransmit
pj1939_pdu1_transmit()
pj1939_pdu2_transmit()
pj1939_inhibit_reprogramming() pj1939_InhibitReprogramming
Other diagnostic C-API functions and Sim-API blocks are available with
an extended-diagnostics license.
• Fixed Simulink block pdtc_DiagnosticTroubleCodeExt errors in

MATLAB R2011b
Previously, errors were generated when a fresh

pdtc_DiagnosticTroubleCodeExt Simulink block was double-clicked in
certain MATLAB versions including R2011b, relating to empty numeric
parameter values. That has now been fixed.
• Fixed performance issue on clearing DTCs
Previously, applications built with very large numbers of DTCs and with
generous freeze frame allocations showed a slow response to diagnostic

Change log
commands such as UDS $14 ClearDiagnosticInformation. The response

could take longer than the 50 milliseconds required by ISO 15765-4.
The process of clearing DTCs with associated freeze frame support has
now been made fast enough to meet the required UDS response time. An
application with 450 DTCs with up to 20 freeze frame records of each of
the available three types now shows a maximum response time of about
25 milliseconds to service $14 with around 20 DTCs active or pending.
• Fix to UDS service $19 reporting of statusOfDtc
Previously, only the lower 3 bits of statusOfDtc were supported by

OpenECU, as reported by the DTCStatusAvailabilityMask value. Those
three bits were mapped to the processed DTC active, inactive and pending
DTC states, which did not all align well to the descriptions tabulated in
Annex D of ISO 14229-1.
Now, bit 3 confirmedDTC is additionally supported by the platform library,

and the setting of all bits has been aligned with ISO 14229-1 such that
the instantaneous test passed/failed state within the current drive cycle is
taken account of where relevant.
Examples

• Modified example models to use first CAN bus for CCP
In the CANdb example model, CCP was configured for the second CAN
bus. When the example model was programmed into the ECU for the first
time, the CCP bus would change and look as if the ECU was no longer
communicating. To prevent this situation, all example models configure
CCP to use the first CAN bus.
• Non-inlined S-Functions can now be built using Embedded Coder
Previously, non-inlined S-Functions would not build using Embedded

Coder. This was because of a data-type mismatch between Simulink types
and OpenECU types. This data-type mismatch problem has been fixed.
decoding.
• Fixed polarity of PWM on H-bridge driver for M220 and U82 target
ECUs
On targets that support the MC33886 H-bridge device, a bug was

introduced that inverts the PWM signal such that driving a duty cycle of

Change log
0.25 would cause the H-bridge to be on with a duty cycle of 0.75 (and
vice versa).
This has been fixed such that the H-bridge driver produces the correct
duty cycle.
• Updated support for M221 family injector output short-to-battery

detection
Added additional internal signal to force a refresh of the injector diagnostic

flags without application intervention. This means an application polling
the state of the injector diagnostic flags faster than firing frequency can
get per-injector diagnostics.
• Correction to angle-based analogue input sampling
The angle-based sampling of analogue inputs was inaccurate close to the

start of an engine cycle. The samples supposedly taken at 3 degrees, 9
degrees, 15 degrees, 21 degrees and (at engine speeds less than about
500 RPM) 27 degrees relative to the engine cycle (where 0 degrees is the
measured edge of the first tooth on the crank wheel) were actually being
taken at roughly one degree intervals starting close after the 717 degree
(four-stroke) or 357 degree (two-stroke) sample, i.e. at approximately
-3, -2, -1, 0 and 1 degrees respectively. This behaviour has now been
corrected.
• Angular samples not correctly accessed when cylinder order does

not match firing order
When accessing angle-based analogue input samples using

the pan_AngularAnalogInputVariable Simulink block, or the
equivalent C-API functions pan_get_angular_ad_avg_var() and
pan_get_angular_ad_samples_var(), the cylinder input was
incorrectly being used to access data ordered by TDC angle. Thus if
the firing order were 630, 270, 450, 90 degrees for cylinders 1 to 4
respectively, then passing cylinder 1 as input would actually return the
correct data for cylinder 4 (i.e. the first cylinder when the TDC angles are
sorted); passing cylinder 2 as input would return the correct data, since
this is still the second cylinder when the TDC angles are sorted; similarly
passing cylinder 3 would return the correct data, but passing cylinder 4
would return the data for cylinder 1.
This behaviour has been corrected, so that the data returned always
match the specified cylinder.
• Corrected range check for number of teeth on multiple-tooth cam

wheel configuration
The range check logic for number of cam teeth when

using the pan_config_cam_wheel_mt() C-API function or
pan_CamWheelConfig block with wheel type 'Multiple Teeth' selected now
correctly allows the full range of supported cam teeth.

Change log
• Cam synch behavior is now correct with cam window in [0,360)
The platform software will now correctly synchronise with an engine with
the cam window in the range [0,360) (crank).
• Update documentation for certain angular functions
The documentation for the pan_CurrentCylinder Simulink block and

pan_get_engine_cyl() C-API function have been improved.
Installation

before OpenECU.
• Addition of Microsoft shared run-time library for Python
Previously, the msvcr71.dll shared run-time library from Microsoft was

not included with the installer. This has been found to cause an issue
with some new PCs which have yet to have the same file installed by
another application. This could cause Simulink models to fail to properly
load data dictionaries (with a message about a missing MATLAB .m file)
and application builds could fail.
Now, the msvcr71.dll library is included with the OpenECU installer.
• Non-volatile memory storage CPU issue fixed on X657
Previously, an issue was identified whereby the file system, responsible

for non-volatile storage, could consume more CPU than expected when
writing files (which should not affect real-time execution). This was only
observed on the MPC5565-based X657, when a single flash program
operation could complete unexpectedly quickly, after which the file system
incorrectly started further memory “program” operations in the same task
iteration until a whole file was written instead of just a small part of it. This
issue is now fixed.
• NVM storage file renumbering fix
Previously, an issue was identified whereby the PFS feature, responsible

for NVM storage, could determine the latest available revision number
of any file stored incorrectly, when the latest revision number exceeded
32767. This would lead to the next revision bumping up to zero, which
would not affect storage. But also a file delete record could potentially be

Change log
read out of order from the file to which it referred, which could conceivably
lead to a deleted file reappearing in the filesystem. This issue is now fixed.
• Non-volatile memory storage made robust against unexpected

runtime errors
Previously, an issue was seen whereby nonvolatile data was occasionally

lost in one particular application which uses high CPU and memory
resources. This was possibly related to an intermittent ECU power supply.
In principle, repeated power loss very soon after startup could have led to
non-volatile memory data loss in certain scenarios.
Now, the file system avoids background file “defragmentation” moves until
the program has been running safely for a few seconds, unless any write
requests have been made by the application or platform.
Furthermore, additional defensive code has been added to guard against

conceivable run-time errors in file alignment in memory.

• Increase in application watchdog task rate
Previously, for applications with high CPU loading, the period of the low
priority watchdog task could cause the watchdog to trigger unnecessarily.
To resolve this, the rate of the library controlled watchdog task has been
increased. As before, and if necessary, the application can take control of
the watchdog from the library through a build option.
• Correction to allow repeated watchdog resets in the application to

be trapped by the firmware
Previously, if the application reset up to 5 times in quick succession due

to watchdog timeouts, the firmware would not force reprogramming mode
(as the firmware does for other types of resets). This has been corrected.
Target ECU

• Reliably clear pin A45 overcurrent trip reset on M220 power-up
Pin A45 on the M220 has the hardware capability of controlling current
to software-configured thresholds, although this is not currently exposed
at the library level. To clear the overcurrent trip reset reliably, those
thresholds need to be set to reasonably high levels (as PWM signals)
before the trip reset occurs. Before this change, the delay was too short,

Change log
and the trip started in a latched “tripped” state on some ECUs but not on
others.
Now, a suitable delay has been introduced (~2 milliseconds) during the
boot process such that the A45 overcurrent trip is reliably cleared before
the application software is started.
Additionally, the user guide and technical specification now warn that the
M220 pin A45 overcurrent trip may occur at unexpectedly low current if a
strong load is driven within ~18 milliseconds of application start-up.
User documentation

and PDF formats.
• Fixed error where some files would not be included in the chunked
Simulink user guide.
Before, some files such as auto-coders.html and auto-

coders_selection.html were erroneously not included in the install
package making those sections inaccessible form the MATLAB help.
This has been fixed so that the files are now included.
• Updated the list of supported versions of third party calibration

tools
• Missing help for pan_EngineSync block
The pan_EngineSync block help was missing. This has now been added.
• Documentation for crank tooth edge polarity selection in the

pan_CrankWheelConfig block
The Tooth edge polarity mask parameter of the pan_CrankWheelConfig

Simulink block has now been added to the user guide documentation and
block help page.
• Updated documentation for CAN receive functions
Documentation has been updated for the pcx_CANReceiveMessage and

pcx_CANdb_ReceiveMessage Simulink blocks and pcx_receive() C-
API function to clarify behavior and return values.
3.11. Release 2.2.0 (r2013-2)

Release labelled release-2.2.0-r2013-2 from 19 December 2013. This release is

Change log

compatible upgrade
11319 (F), 11229 (F), 11293 (F), 11242 (F), 11319 (F), 11320 (F),
11218 (F), 11216 (F), 11233 (F), 11055 (F), 11319 (F), 11319 (F),
11204 (F), 11196 (F), 10997 (F), 10978 (F), 11153 (F), 11319 (F),
11153 (F), 11016 (F), 10926 (F), 10899 (F), 10735 (F), 11218 (F),
10875 (F), 10849 (F), 10870 (F), 10857 (F), 10423 (F), 11016 (F),
10836 (F), 10836 (F), 10838 (F), 10798 (F), 10412 (F) 10870 (F),
10773 (F), 10744 (F), 10761 (F), 10760 (F), 10857 (F),
10735 (F), 10617 (F), 10746 (F), 10736 (F), 10761 (F),
10423 (F), 10420 (F), 10723 (F), 10696 (F), 10760 (F),
10412 (F), 10318 (F), 10606 (F), 10351 (F), 10746 (F),
10279 (F), 10278 (F), 10350 (F), 10349 (F), 10278 (F)
9650 (F), 9582 (F), 9429 10348 (F), 9552 (F), 9101
(F), 9412 (F), (F), 8915 (F),
8337 (F), 7758 (F), 4248 8687 (F), 8608 (F), 8458
(W) (F), 4997 (F),
4580 (F), 2254 (F)
11319 (F), 11229 (F), 11443 (F), 11438 (F), 11319 (F), 11320 (F),
11218 (F), 11216 (F), 11293 (F), 11245 (F), 11319 (F), 11319 (F),
11204 (F), 11201 (F), 11242 (F), 11233 (F), 11153 (F), 11319 (F),
11196 (F), 11153 (F), 11156 (F), 11066 (F), 10735 (F), 11218 (F),
11020 (F), 11016 (F), 11055 (F), 10997 (F), 10423 (F), 11016 (F),
10936 (F), 10935 (F), 10978 (F), 10926 (F), 10412 (F), 10870 (F),
10875 (F), 10849 (F), 10917 (F), 10899 (F), 3672 (W) 10761 (F),
10836 (F), 10773 (F), 10870 (F), 10838 (F), 10760 (F),
10744 (F), 10735 (F), 10798 (F), 10761 (F), 10746 (F),
10687 (F), 10617 (F), 10760 (F), 10746 (F), 10278 (F)
10423 (F), 10420 (F), 10736 (F), 10723 (F),
10412 (F), 10318 (F), 10722 (F), 10696 (F),
10278 (F), 9713 (F), 10632 (F), 10621 (F),
9650 (F), 9582 (F), 9553 10608 (F), 10606 (F),
(F), 9429 (F), 10351 (F), 10350 (F),
9412 (F), 7758 (F), 4248 10349 (F), 10348 (F), 9552
(W), 3672 (W) (F), 9544 (F),
9101 (F), 8608 (F), 8458
(F), 7759 (F),
4997 (F), 4580 (F), 4401
(F), 2254 (F)


developer software.
• Added support for Mathworks MATLAB release R2013b (32-bit)

Change log
• Remove deprecated blocks
The following deprecated blocks have been marked end-of-life and

removed:
• put_BitwiseOp
• put_Config_M460
• Added support for Mathworks MATLAB release R2013b (64-bit)
• Added support for Mathworks MATLAB release R2013a
• Added support for the M250-00Z IMU
Recently, software support has been added for an IMU (accelerometer +

three gyroscopes) on the M250. Software support has been added to read
acceleration values, gyroscope X, Y, and Z axis values, gyroscope X, Y
and Z temperatures and gyroscope X, Y, and Z angles.
Reading the acceleration and gyroscope values (temperatures and

angles) can be done using the pax_adc_input() function using C-API
or by using the pai_AnalogInput or the pai_BasicAnalogInput blocks in
Simulink.
An additional feature of the M250-00Z IMU is that the user can adjust the
sample rate of the data coming off of the accelerometer and gyroscopes.
These devices automatically have a default value set in place, but can
be changed, if desired, by calling pcfg_imu_rate() in the C-API or by
calling the pcfg_Config_IMU_M250 block.
In addition to reading the basic values off of the IMU, the user can also run
a self-test on the gyroscopes and the accelerometer to determine reliability
of the devices.
Please see the M250 Technical Specification for further detail on reading
IMU channels, and running self-test sequences.
• Make J1939 node address calibratable
The J1939 node address for the ECU can now be altered by calibration.
An automatic ASAP2 parameter is generated to define it.
Note
The node address is configured at power-up time. To have any
effect, the altered calibration value must be stored in flash and the
ECU rebooted.

Change log
• Added functionality to pai_AnalogInput block
The Raw data units parameter has been added to the pai_AnalogInput
block.
The Transfer function type parameter has been added to the

pai_AnalogInput block along with the Transfer function scale, Transfer
function x offset, and Transfer function z offset parameters.
The Separate min/max values parameter has been added to the

pai_AnalogInput block along with the Minimum engineering value,
Maximum engineering value, Minimum raw value, and Maximum raw
value parameters.
• J1850 checksum utility available and now optional on CANdb

transmit and receive
The SAE-J1850 standard includes the definition of an 8-bit CRC algorithm.

This algorithm is now available in the C-API as the new function
put_calc_crc_j1850.
Additionally, an option as been added to the

pcx_CANdb_TransmitMessage block to apply the J1850 checksum to
a transmit message, placed in the last byte of the message and being
computed over all the bytes prior to that.
Similarly, an option as been added to the pcx_CANdb_ReceiveMessage

block to validate a receive message using the J1850 checksum.
• Updates to C-API interface tool
A new option --output-s-rec has been added to the C-API interface

tool. This integrates the functionality of the pop_header.py tool into
the C-API interface tool. Please see the C-API user guide for usage
information (Section "Running the interface tool").
The pop_header.py tool is obsolete and has been removed from this
release.
The C-API interface tool is now packaged as compiled binary (*.pyc) files.
The capi.py file is still included as an entry point, so that command line
calls to capi.py still work.
• A choice of three different user selected templates has been added

to the oe_create_model command
The oe_create_model command has been updated to generate an

OpenECU model from one of three templates. The choices of template
includes basic, basic-bussed and minimal. The command parameters
have changed For more information, run the following at MATLAB's
command prompt:

Change log
help oe_create_model
Calibration

software.
• OE_CAL replaces volatile const for calibrations
To support the GCC compiler, how calibrations are declared and defined
has changed. Each calibration must use the OE_CAL macro instead of the
deprecated use of volatile const or const volatile.
As an example, the following declaration in file.h:
extern volatile const F32 mbec_calibration;
And definition in file.c:
volatile const F32 mbec_calibration = 15.0F;
should be changed to:
extern OE_CAL F32 mbec_calibration;

/* ... */
OE_CAL F32 mbec_calibration = 15.0F;
to be compatible with both Diab and GCC compilers. See the C-API
examples installed with OpenECU for further examples.
Note
For the moment, use of volatile const or const volatile will
continue to work correctly with the Diab compiler. This may change
in a future version of OpenECU.
Note
Other variable declarations that are not calibrations, that already use
the volatile and/or const qualifiers should continue to do so.
The change to use OE_CAL should only occur for calibrations.
• OpenECU application issues warning about unregistered COM

Interface while creating strategy file if RegisterCOMInterface.bat
is not executed on ATI Vision
Previously the OpenECU application couldn't create a strategy file if the

COM interface for Vision was unregistered. Now,when the COM interface

Change log
is unavailable, an OpenECU build will display some text in the MATLAB

command windows to help direct the user solve the problem with Vision
• Remove restriction on number of characters a data dictionary entry

can have
Previously, a data dictionary entry with more than 31 characters was

not supported during ASAP2 generation on Simulink. This now has
been updated whereby a user can specify the maximum data dictionary
entry name length. The range of the maximum length being 31 to 255
characters. If a data dictionary identifier exceeds the maximum length then
a warning will be generated and the name will be shortened during the
ASAP2 generation. If length is given a value of 0, then there will be no
limit on identifier length.
Code generation

• Generation of unsupported characters in accordance to ASAP2

standards in ASAP2 file
The application name generated in the ASAP2 file contained

characters that were unacceptable in accordance to ASAP2 standards.
The calibration tool Vector CANape doesn't support use of such
ASAP2 files. The C-API interface tool has been updated to optimise
application name in the ASAP2 files that are in accordance with the
standards.
• Added support for ASAP2 Canonical Support PSP
Previously, when using multiple instances of one model based referenced

block within a model, the global signals and parameters within the model
based reference blocks would not be generated in the ASAP2 file, when
using RTW/Simulink-Coder based ASAP2 generation. Full support for
generating these signals and parameters is scheduled to be included in
a future MATLAB/Simulink release. Support for a backport of this feature
for earlier versions of MATLAB/Simulink is included with this release.
By default, the ASAP2 Canonical Support PSP support is not enabled.

Support must be enabled by defining a TLC option in each top level and
model reference model in the application.
This can be done by running the commands:
cs = getActiveConfigSet(bdroot);
set_param(cs, 'TLCOptions', '-aASAP2CanonicalSupportPSPEnable=1');
on each top-level model and model reference in the application. Or

manually by adding the string "-aASAP2CanonicalSupportPSPEnable=1"
to the 'TLC Options' field in the model Configuration Parameters dialog
under 'Real-Time Workshop' or 'Code Generation' in later versions of
MATLAB/Simulink.

Change log
• Added GCC compiler support
Added support to build applications using GCC 4.7.2 and binutils 2.23.1.
The necessary scripts and tools are now included with the OpenECU
platform installation.
Part of this change includes new options to support GNU objdump

files and GCC mapfiles. These new options are needed when building
applications with C-API batch files. The options --gcc-objfile to input
GNU objdump files and --gcc-mapfile to input GCC mapfiles are
described further in the C-API user guide section "Interface and DDE tool"
for further information.
Additionally, GCC is included in the OpenECU install process. This

is to ensure that the correct version of GCC is used when building
applications since no other version of GCC is supported. Upon installation
of OpenECU, the GCC tool is installed by default but can be unselected
in the "Tools" section of the installer selection screen if the customer does
not intend to use GCC and wants to save installation space.
Currently, support for building applications using GCC is limited. See list
below for details.
• Adaptives are not supported
• Diagnostics are not supported
• Tunes are not supported
• Only targets M220, M250, M460 and M461 are supported
• Alternate memory configurations are not supported
Several other issues have been identified as well:
• The code size generated by GCC is about 50 percent larger than code
built with the Diab compiler
• CPU loading on the ECU has increased
• Removed support for Matlab 2007b.
• Build error when code size exceeds space available
The mechanism for generating a build error when the code size exceeds
the space available was not completely robust. A small section of RAM
variable initialisation data is added to the end of the code proper, and this
was not being taken into account, so that if the code proper was just able
to fit but the initialisation data pushed the total memory use over the limit,
no error would occur and an image file would be generated. This would
then create an error when attempting to download. That has now been
rectified.
Communications

Change log

ISO-15765 over CAN.
• Added support for application specified string for CCP message

EXCHANGE-ID
In application mode, CCP support for the EXCHANGE-ID message has

been extended to allow the application to specify the string the message
refers to. Previously, the string was fixed to “OPENECU-[target]”. Now,
the string is specified by the application. The C-API and Sim-API support
this change in a similar fashion:
For the C-API, the C-API interface file name statement is used as the
string refered to by the EXCHANGE-ID message. The C-API tool has
been extended to support string translations. For example, this allow the
application to specify a string such as “Application for %target%”
and the C-API tool will convert %target% into the target ECU name. For
a complete list of translations, see the C-API user guide.
For the Sim-API, the put_Identification block has been updated to include
a new mask parameter for the application name. The format of the string
for this mask parameter is identical to the C-API name statement. See the
Sim-API user guide for details.
In reprogramming mode, the EXCHANGE-ID message is unchanged and

continues to refer to the string “OPENECU-[target]”.
Desktop integration
OpenECU software, examples and documentation are accessible through

the desktop, from the Windows Start button.
• Adding support for Windows 7 64-bit
OpenECU now supports the Windows 7 64-bit operating system.
• Added support for multiple UDS security levels with Simulink

configuration
Previously, UDS SecurityAccess ($27) was supported in C-API

applications, but the services which depended upon it were either all
allowed if security had been passed or all disallowed if not.
Now, the security level attained can be used to decide whether flash
reprogramming or ReadMemoryByAddress ($23) are each allowed
independently, giving finer control over what different types of end-user
are permitted to do.
A new pdg_Permissions block has been added to allow UDS security

options to be controlled in Simulink applications. This also allows the

Change log
run-time control of UDS reprogramming, so that it can be inhibited (for

example) if the engine is running. Previously these things only had C-API
interfaces.
Note
• UDS service $19 SnapshotData support
Diagnostic support for UDS service $19 has been expanded to support
subfunction $03 reportDTCSnapshotIdentification and sub-function $04
reportDTCSnapshotRecordByDTCNumber. The additional sub-functions
necessitated the addition of new Simulink block parameters and
corresponding C-API tool options.
• Added support for new UDS $14 and $19 subfunctions
For KWP2000/UDS service $14, valid values of groupOfDTC other than

"all DTCs" are now accepted.
For UDS service $19, the new subfunctions supported are $07, $08,
$09, $0B, $0C, $0D, $0E, $12 and $13. The UDS severity-related
services necessitated the addition of a new Simulink block parameter and
corresponding C-API tool option to allow the UDS severity of each DTC
to be specified. This can also be calibrated.
The memory footprint of DTCs and some other records was reduced
however, by improved packing of the structured data.
• Changed rate and priority of the PDTC task
The platform periodic pdtc task has had its period increased to 100ms and
its task priority reduced to just below the lowest-priority application task.
• Added method to enable or disable periodic processing of DTC lamp

information
Created new functions for both C-API and Simulink interfaces

to allow an application to control if the periodic update of
DTC lamp information occurs. This is done through either the
pdtc_enable_periodic_lamp_updates() C-API function or the
pdtc_EnablePeriodicLampUpdates Simulink block.
This function operates in real-time, meaning that the application can

enable or disable the processing during application execution.
If these functions are not used, periodic processing of DTC lamps is

enabled by default to maintain backward compatibility.

Change log
• Performance improvements
Several performance enhancements were made in routines for accessing

timers, CAN-db based messaging, CAN drivers, and utility functions.
These reduce the amount of CPU overhead for frequently-used functions.
• Support for types other than U8 on data inport to

pj1939_Dm16Transmit block
The data inport to the pj1939_Dm16Transmit Simulink block now supports

a range of data types rather than just unsigned 8-bit data.
• Support for malfunction classification in priorities for storing freeze

frames
The platform has been updated to delete a lower emissions severity

DTC's freeze frame to make way for one of higher severity.
The behaviour is selectable via calibration defined at build time
- pff_dtc_sev_overrides_ff_age. This was done to satisfy Euro 6
regulations. Also, in the DM25 message, if the J1939 transmit buffer is not
large enough, then lower emissions severity DTC's freeze frame(s) will be
discarded to make space for higher severity ones.
Examples

• Updated oe_create_model to create a sample units files
Previously, oe_create_model would create a data dictionary with units

omitted. Now, oe_create_model creates an example units file and
populates a data dictionary with example units.

• Add support for ignition-less wake-on-CAN reprogramming
To support modules that do not have an ignition enable and use wake-
on-CAN to control sleep state, the boot programming mode code has
been modified. If the module is in programming mode and CCP messages
cease for more than a timeout, the module will power itself down
automatically.

Change log
Note
• Added new firmware for M221 family of modules
This is the initial release of firmware for the M221 target.
Note
• Updates to the Extended EXCHANGE_ID CCP message handling to

extract manufacture information
Previously, the ECU would simply set the MTA to a string representing the
ECU type when the ECU received a EXCHANGE_ID_CCP message.
Now, the ECU uses information from the master device part of the
EXCHANGE_ID message to set the MTA to various bits of information,
including the ECU type, manufacturing data (including the serial number
and part number) and an application defined string. See the CCP
compliance section in the user guide for details.
Note
• Added version numbers for each software component to firmware

release notes
Target ECU

• Added new build target for M221 family of modules, includes

updated firmware

Change log
Support for the M221 target ECU has been added for the Simulink
interface. The M221 technical specification provides an overview of the
supported ECU features. This is an interim release of software for M221
support and as such, some issues remain open which will be resolved
over subsequent releases. The known issues are listed below.
The known issues are as follows:
1. The "Monitor (d) (pin A3)" fault detection input and "DOT fault-latch (pin
A3)" clear fault output for pin A3 have not yet been tested.
2. The "DIN injector-batt-fault (internal)" injector overcurrent fault

detection input and "DOT injector-batt-fault-latch (internal)" injector
overcurrent fault clear output for pins A16, A32, A33, A34, A35, A36,
A37, A38, A39, and A45 have not yet been tested.
3. The state of all output pins in reprogramming mode has not yet been
verified.
Other functionality
• The following analogue input channels are available in software, but

not in the hardware: "AIN VREF (internal)", "AIN internal-ecu-temp
(internal)", and "AIN 5VD (internal)". Reading them will always return
0 volts.
Documentation
• The M221 technical specification is still in progress. For questions

regarding missing or incomplete information, please contact OpenECU
Support.
Note
• Removed deprecated ECU target
The target M250-00H is no longer supported.
The bldc features are no longer supported.
• New flash code for licensing
The flash code "222" has been added to the firmware to indicate when the
loaded application is not validly licensed
Note

Change log

• Added facility to output the entire adapted array
The Simulink block pnv_array now has an optional outport that will output
the entire adapted array contents.
A new C-API function pnv_array_dump() allows one to output the entire

contents of the adapted array identified by the function arguments.
• Added support for memory configuration
The facility to select different memory configurations has been added for
targets M220, M250, M460 and M461.
User documentation

and PDF formats.
• Updated third party tools documentation to include MATLAB coder
The user documentation has been clearafied about the change of

Mathworks tools between R2010b and R2011a: MATLAB Coder is
required in R2011a and later, Stateflow Coder is not required in R2011a
and later, RTW has been renamed to Simulink Coder, and RTW-EC has
been renamed to Embedded Coder.


developer software.
• Added error message when adaptives or DTCs are used with GCC
Neither Adaptives nor DTCs are supported by GCC. If the user attempts
to use them then the following error messages will be emitted:
Warning: DTCs are not yet supported by GCC-4.7.2 and will not be
enabled in this application.
Warning: To enable DTC functionality, please use a compiler that
supports it.
Warning: Adaptives are not yet supported by GCC-4.7.2 and will not be

Change log
enabled in this application.

Warning: To enable adaptive functionality, please use a compiler that
supports it.
<model>_api.h:29:2: error: #error "Error: Adaptives are not yet

supported by GCC and will not be enabled in this application.
To enable adaptive functionality, please use a compiler that supports
it."
<model>_api.h:44:2: error: #error "Error: DTCs are not yet supported by

GCC and will not be enabled in this application.
To enable DTC functionality, please use a compiler that supports it."
See the third-party tools compatibility document for more information on

feature support.
• Correction to mask display for the pan_CurrentCrankAngle,

pan_CurrentCrankTooth, pan_CurrentCylinder and
pan_CurrentEngineAngle blocks
• Correction to how some blocks display in MATLAB R2010b or later
The pcp_CcpSecurity, pnv_AdaptiveMap1d and pnv_AdaptiveMap2d

blocks would incorrectly display with MATLAB R2010b or later. This has
been corrected.
• X657 multiplex monitors could affect analogue input readings
The X657 has monitor signals which can be read internally to check
whether the analogue multiplexer chips are being signalled correctly.
However, those monitor signals were being internally configured in such
a way that some delay or cross-talk artefacts could be caused when
sampling analogue inputs routed through those multiplexers. This has now
been fixed.
The two signals previously available as PWM/frequency input (PIN/FIN)

MA0 and MA1 are now only available as plain digital input (DIN).
• Added details on supported part numbers to the oe_create_model

MATLAB support script
Previously, when the oe_create_model command was used to create

a MATLAB model, the user was given no help regardling supported part
and issue numbers.
Now, the help oe_create_model will display the ECU name, part and
issue number of all supported targets.
• Correction to handling of different data dictionary types
Previously, a subset of the blocks would make assumptions that data

dictionary elements used for mask parameters must be of Simulink

Change log
double. If a different data type were used for the mask parameter, it was
possible for incorrect values to be created during code generation.
Now, blocks either explicitly test mask parameter types and raise an error
if incorrect, or blocks automatically take the type of the mask parameter
into consideration when generating code.
• Fixed Python module import failures when PYTHON* environment

variables exist
Previously, when a python tool was called using the platform installation
of python but with PYTHON* environment variable set, errors could occur
to mismatched or non-existent paths.
This has been fixed by using the python -E option in all cases where the
platform calls python.
• Error reporting of CANdb blocks improved
Previously, errors in CANdb file parsing would cause

the pcx_CANdb_TransmitMessage and pcx_CANdb_ReceiveMessage
blocks to remove their CAN signal inports or outports, but there was no
real explanation of the problem that had been found. Now error information
is passed up and reported in the build information dialog, for example
specifying the DBC file line number at which an error was found.
• Added license management system to OpenECU developer

Software
The license manager must be able to detect your license at build and
simulation times in order to complete successfully. Contact Pi Innovo if
you need to obtain a license.
Calibration

software.
• Corrected errors in the ProF configuration files for the M220 target
affecting integration with ETAS INCA
Some mistakes in the ProF configuration files for the M220 target meant
that these files did not install correctly on the the ETAS INCA calibration
tool, resulting in errors when trying to use that tool with the M220. Those
mistakes have now been corrected.
• Restore automatic ASAP2 entries for the ram copies of adaptive

variables.

Change log
Previously, in CR 8499 (F), support for automatic ASAP2 entries for the
RAM copies of adaptives was removed for both the C-API and Simulink
targets not using RTW based ASAP2 generation. Now support for these
automatic ASAP2 entries has been restored. Each adaptive parameter will
now behave as before with an automatic ASAP2 entry added matching
the name of the default value except for the insertion of an 'a' character
for the fifth character of the variable.
• Fix for automatic ASAP2 entries for task timing information
The previous change to the priority of the PDTC task in CR 10423 also
affected the automatic ASAP2 entries for task timing information. After
that change the variables named mpl_tt_xxx and mpl_mtt_xxx were
incorrectly generated such that one entry might reflect the time of a
different task. Now, automatic ASAP2 entries for task times correctly
match their respective tasks.
Code generation

• Fix to oe_update_model_for_ddes for Embedded Coder
Originally, when using Embedded Coder (ERT) in a Simulink model

with library links, the build process would get the coder settings wrong,
resulting in an error where a signal was being set to ExportedGlobal in
the library model when the signal should have actually been set to Signal
name must resolve to Simulink object. This was due to the
oe_update_model_for_ddes script searching the library link for the
type of coder, when it should have been searching the parent model for
type of coder. This has been fixed.
• Correction to oe_switch_version command to allow switching

between platform versions
• Fix to oe_update_model_for_ddes.m to account for inherited

signal names within a library link in a main model
Previously, the oe_update_model_for_ddes.m script would update all

of a library, rather than just the subset referred to by the top level model
by links. This caused the script to call out signal names as duplicates and
to be ignored by the ASAP2 file even though the signal names were not
duplicated. This has been fixed.
• Fixed bug in C-API interface tool
There was a bug that caused capi_visitor_dde_gen_asap2.py to

raise an error in some cases. This has been fixed.

Change log
• Correction to SimulinkCoder build directory naming
Previously, when building a model, the directory created to hold the

temporary build files would include the string “unknown” instead of the
type of SimulinkCoder selected (for instance “rsim” or “ec”). This has been
fixed.
• Fix to put_FaultCheck to reset state inside Enabled Subystems
Previously, if the put_FaultCheck block was used inside of an Enabled

Subsystem with the 'States when enabling' parameter of the Enable block
set to 'reset' the block would not reset the internal fault state, resulting in
an immediate fault trip when the block was re-enabled after confirming a
fault. Now, the block will correctly reset the internal state when configured
to 'reset' inside of an Enabled Subystem.
• Correction to data dictionary file parsing
Previously, a blank line in a data dictionary file, consisting of TAB

characters would result in an incorrect error message about element class:
'' is an invalid Class for a data dictionary entry (must be one of....
This has been corrected.
• Build time optimisation for the oe_update_model_for_ddes

OpenECU internal m-script function
Previously a model with disabled library links could take a considerable

amount of time to build due to the oe_update_model_for_ddes
OpenECU m-script. Now this m-script has been optimised and should
take a considerably less amount of time to execute. This should be most
noticeable on large models with numerous disabled library links.
• Fix for errors during model update for the CANdb blocks.
Previously during the update stage of a Simulink model containing

pcx_CANdb_ReceiveMessage or pcx_CANdb_TransmitMessage blocks,
an error could be returned of the form:
put_Identification block (mask) does not have a parameter named

'pcxl_msg_id'.
A subsequent model update would not cause the same error to be

returned. Now the blocks have been update to not cause the error.
Communications

ISO-15765 over CAN.

Change log
• CAN messages stop transmitting due to failure in queueing

mechanism
A lack of robustness in the mechanism for queueing CAN messages

when no transmit buffers are available meant that in some circumstances
the messages associated with a particular CAN identifier could stop
transmitting. In practice this behaviour has only been observed when a
mixture of CAN messages are being transmitted both periodically and on
an angular basis. This problem has now been fixed.
• Platform does not intercept DM7 messages unless extended-

diagnostics is enabled
The platforms handles DM7 messages as a special case for use with
the extended-diagnostics blockset. Previously, with extended-diagnotics
disabled, this would cause all DM7 messages to be eaten up by the
platform making pj1939_pgReceive blocks unable to interpret them. The
behaviour has been fixed so that this only happens when extended-
diagnostics is enabled. Now, when extended-diagnotics are disabled, the
DM7 message gets passed to the application.
• Fixed queuing issue of outbound CAN messages
An issue was identified whereby a CAN message which should be

transmitted could become "stuck" due to a failure in the queueing process.
This problem was likely to be encountered only in conditions in which a
lot of queuing was taking place, e.g. due to bus interruptions, heavy load,
and attempted transmissions on (other) unconnected buses.
This fix prevents the process which unqueues messages from becoming
stuck.
• Optimisation of data unpacking by pcx_CANdb_ReceiveMessage

block
The previous implementation of pcx_CANdb_ReceiveMessage block (in

the underlying C-API function pcx_vdb_unpack_msg) used double-
precision floating point types to avoid rare but conceivable data value
overflows. After this change, single-precision types are used, which
execute much faster, but could conceivably overflow if extremely large
scale factors and integer data are encountered (e.g. MAX_U32 scaled by
1E+29).
• Fix CCP communications when dual ECUs are used
In the 2_1_0_oe-tw-c1.2 release for X657 only, multiple ECU on the

same bus caused CPP communications to drop out occasionally. This
fix modifies the memory checks so the checks are fast during boot, but
consume less resources during run time.
• Fix to J1939 message buffer handling

Change log
Previously the pj1939_PgReceive Sim-API block, or the

pj1939_pg_receive C-API function could return mismatched data as
compared to the data on the bus for a specific PGN, due to the handling of
the message buffers internal to the platform. This normally occured under
very heavy CPU loading and CAN bus loading. Now the functions are
more robust, and will return the correct data for the PGN.
• UDS reprogramming fixes for X657
Updates to include a pending response due to a

DiagnosticSessionControl request that results in a change in diagnostics
session via an ECUReset. For example a change in diagnostic session
from an application extended session to bootloader programming session.
The positive response is now provided after the reset has occured and the
requested diagnostic session has been formally entered.
A pending response has also been added prior to an erase memory

command while in the programming session. The positive response is
provided once the erase request has completed.
Note
• Add separate functions for J1939 message transmission using

PDU1 and PDU2 formats
Previously, the pj1939_pg_transmit() function used overloading

of PS field in PDU1 format. We now have two separate functions
pj1939_pdu1_transmit() and pj1939_pdu2_transmit() that
can be used for each of the transmission formats. The
pj1939_pg_transmit function has now been deprecated.
• Enabling of ISO diagnostics - pdg_enabled
Updated pdg_enabled to be a const parameter - to have it settable at build

time and not runtime.
• Invalid J1939 messages when DMs requested for which

configuration is not set up

Change log
Corrected the 'empty' message contents for DM30 and DM33 messages.
• Updated documentation related to J1939 DM28 transmission
Updated documentation related J1939 DM28 transmission to indicate that

active and permanent DTCs are transmitted on this message.

• Avoid driving inverted outputs on X657 during flash reprogramming
The X657 outputs A1 and A30 have inverted logic, such that when
the microcontroller pin is low, the output is turned on (drawing current
through a load). Previously, this occurred if CCP flash reprogramming
was initiated when in application mode, causing a transition (via a reset)
to reprogramming mode. Now the boot loader always ensures that the
outputs are not driven by default.
Note that the outputs B7 and B8 also have inverted logic, but are
specifically required by the X657 customer to turn warning lamps on when
the normal application software is not running correctly. These still drive
by default until turned off by application software.
Note
• Remember memory errors across resets
For MPC5xxx family units only, this update allows for the recovery of
the PSY Error Log (feature and error code) associated with the last
unrecoverable error, so that if the application restarts successfully the next
time, it can determine using psy_get_error() if internal problems such as
memory corruption errors caused the most recent reset.
Note
On recovery, the error code is clipped to 0xFF. All error codes used
in the platform for unrecoverable errors should be less than 0xFF.
Recoverable errors may use 16-bit codes.

Change log
This CR also fixes an issue whereby multiple resets due to unrecoverable

errors being hit did not necessarily cause the ECU to remain in
reprogramming mode.
Note
• Faster boot and application/calibration integrity information for

X657
To reduce boot-up time, a new application and calibration checksum

algorithm is now available which can be computed much faster when the
ECU starts up. The IPv4 header checksum is used, which is based on
a sum (hence the speed) but which folds back carried bits into the sum
(hence robust).
Additionally, for the X657 target specifically, some optimisations have

been made to enable cache use during checksumming, and to reduce the
size of the external RAM allocated for application use (which has not been
used in practice, yet which is still tested for data errors at startup time).
These changes have further improved boot-up time.
The application is only started if its checksum and that of the calibration
have passed validation. However, the boot loader can be started
in reprogramming mode for several reasons, with or without a valid
application or calibration. To satisfy diagnostic requirements for the boot
loader to report whether the application code or calibration data are intact,
the result of the start-up checksums are now made available in UDS PID
$F15B (read software fingerprint) as defined by the HIS reprogramming
specification.
Note
• Allow CCP/J1939/UDS reprogramming when FEPS is active
When the application code is running with FEPS active and a request
to reprogram over CCP or J1939 or UDS is received, the bootloader
code would drop the request when it detected that FEPS was active,
requiring a second attempt to reprogram. This situation can arise when
using an ATI hub that automatically applies FEPS during reprogramming.
The bootloader code has now been changed so that it ignores the FEPS
input in this context and continues to honour the original reprogramming
request instead.

Change log
Note
User documentation

and PDF formats.
• Correction to compiler version checks
Previously, when checking for a valid compiler, an error would be

produced by the Diab compiler about not understanding the target type
if the corresponding OPENECU_DIAB_... environment variable was not
defined. This has been fixed.
• Removed documentation for obsolete blocks
Documentation for the following blocks has been deleted as they no longer
exist.
• psp_SPIInput
• psp_SPIOutput
• Updated user documentation for direct injection configuration

functions
Updated documentation to clarify the meaning of the minimum injection

time parameter for the pan_config_injections_di() C-API function
and pan_InjectorConfig_DI Simulink block.
• Fixed CSS linking in HTML documentation
Previously, there was an error in the CSS linking from the HTML
documentation that caused the styles to not display under certain
browsers.
This error has been fixed such that it works on major web browsers
(Mozilla Firefox, Google Chrome, Microsoft Internet Explorer).
• Improved description of compiler defect relating to large C

functions
The Diab 5.5.1.0 compiler has a known defect relating to large C functions,
and during a Sim-API build, OpenECU checks for large functions and

Change log
issues a warning if any are found, referring to the User Guide. However,
finding the relevant section of the User Guide has proved difficult, so the
User Guide description now quotes the build-time warning making it easier
to find.
• Corrections to M461 technical specification
• Support newer versions of ATI Vision
Previously, support was indicated for ATI Vision v2.5 and above.
Additionally, examples in the user guide referenced an unsupported
version of ATI Vision.
Now, support for ATI Vision versions 3.6 and 3.7 are explicitly indicated in
the footnotes. Additionally, examples in the user guide no longer reference
unsupported versions of ATI Vision.
• Clarify behavior of digital outputs with selectable high- and low-side

drive
Added descriptive text to better describe how the digital outputs behave
depending on their selected polarity.
3.12. Release 2.1.0 (r2013-1)

Release labelled release-2.1.0-r2013-1 from 13 February 2013. This release is

compatible upgrade
10387 (F), 10334 (F), 10438 (F), 10398 (F), 10387 (F), 10310 (F),
10203 (F), 9809 (F), 9640 10397 (F), 10351 (F), 9040 (F), 10247 (F),
(F), 9615 (F), 10350 (F), 10349 (F), 9039 (F), 10231 (F)
9413 (F), 9040 (F), 9039 10348 (F), 10310 (F), 8714 (F),
(F), 9026 (F), 10247 (F), 10231 (F), 8499 (F),
9025 (F), 8614 (F), 8614 9751 (F), 9733 (F), 9719 7932 (F),
(F), 8614 (F), (F), 9661 (F), 5471 (F)
8499 (F), 8174 (F), 7932 9560 (F), 9560 (F), 9529
(F), 7827 (F), (F), 9525 (F),

Change log

compatible upgrade
7814 (F), 7388 (F), 7196 9055 (F), 9045 (F), 8973
(F), 7164 (F), (F), 8943 (F),
7163 (F), 6699 (F), 4749 8943 (F), 8942 (F), 8941
(F) (F), 8860 (F),
8816 (F), 8783 (F), 8715
(F), 8714 (F),
8680 (F), 8596 (F), 8581
(F), 8473 (F),
8450 (F), 8425 (F), 8141
(W), 7917 (F),
7827 (F), 7814 (F), 7814
(F), 7814 (F),
7814 (F), 7814 (F), 7636
(F), 7622 (F),
7358 (F), 7196 (F), 7084
(F), 5471 (F),
5471 (F), 5471 (F), 4749
(F), 4595 (F),
1916 (F)
10480 (F), 10387 (F), 10595 (F), 10579 (F), 10387 (F), 10310 (F),
10334 (F), 9793 (F), 9640 10562 (F), 10561 (F), 10346 (F), 10247 (F),
(F), 9615 (F), 10519 (F), 10511 (F), 9040 (F), 10231 (F)
9569 (F), 9413 (F), 9040 10438 (F), 10397 (F), 9039 (F),
(F), 9039 (F), 10351 (F), 10350 (F), 7932 (F),
9026 (F), 9025 (F), 8614 10349 (F), 10348 (F), 5471 (F)
(F), 8614 (F), 10346 (F), 10310 (F),
8614 (F), 8499 (F), 8174 10247 (F), 10231 (F), 9751
(F), 7932 (F), (F), 9733 (F),
7827 (F), 7814 (F), 7388 9722 (F), 9661 (F), 9653
(F), 7196 (F), (F), 9588 (F),
7164 (F), 7163 (F), 6848 9560 (F), 9560 (F), 9529
(F), 4749 (F) (F), 9525 (F),
9436 (F), 9055 (F), 9045
(F), 9033 (F),
8973 (F), 8943 (F), 8943
(F), 8942 (F),
8941 (F), 8860 (F), 8783
(F), 8715 (F),
8694 (F), 8680 (F), 8597
(F), 8596 (F),
8581 (F), 8530 (F), 8499
(F), 8499 (F),
8499 (F), 8499 (F), 8499
(F), 8473 (F),
8450 (F), 8425 (F), 8302
(F), 8141 (W),
7917 (F), 7827 (F), 7814
(F), 7814 (F),
7814 (F), 7814 (F), 7814
(F), 7622 (F),
7358 (F), 7353 (F), 7196
(F), 7084 (F),
6467 (F), 5811 (F), 5471
(F), 5471 (F),

Change log

compatible upgrade
5471 (F), 4749 (F), 4595
(F), 1916 (F)


developer software.
• Added support for MathWorks MATLAB versions R2010b, R2011a

and R2011b
• Added support for application-specified direct-injection duration
The Direct Injector interface now supports requests for both automatic
computation of duration from a volume request and an explicit duration.
The computation of duration from volume is similar to previous behavior

where the application must provide an injector characteristic map to the
platform and the platform uses that map to compute a duration based on
a measurement of fuel rail pressure at the start of injection.
If the application uses the new duration mode, the platform will simply
activate the injector for the amount of time specified by the application.
• Added support for overlapping direct-injection events
The mechanisms to specify injector characteristics have been changed

to support the ability for multiple Direct Injection events to occur
simultaneously. The calibrated injector characteristic map is now updated
only at application initialization (no real-time modifications) and the
methods available to convert demand to pulse width have been changed.
The changes made to this block will also be reflected

in the OpenECU Simulink block set as well. Since
there are no longer real-time modifications, the function
pan_adapt_injection_comp_table_di() has been removed along
with it's corresponding Simulink block.
This change is in conjunction with CR 9040 (F) which allows for direct
specification of the pulse durations.
• Add support for multiple injectors per cylinder

Change log
The interfaces to configure injectors have been extended so that individual

injectors can be configured for particular cylinders. While each injector
must be configured for one cylinder, any number of injectors can be
configured for a particular cylinder.
• Add support for two stroke engine operation
The engine configuration functions now support two stroke operation in

addition to four stroke operation. The pan_EngineConfig Sim-API block
now accepts a new parameter for Engine Cycle Type of either 2-stroke
or 4-stroke. The pan_config_engine() C-API function now has a
PIO_ENGINE_CYCLE_TYPE_T function parameter to select either mode
of operation.
• Modification of interface to non-volatile storage
Previously the C-API would require the application to pass in a reference

to the RAM copy of the non-volatile storage (adaptive) parameter. This
is no longer necessary. The RAM copy is maintained internally by the
platform and referenced using the flash default copy (calibration). There
are no changes to the 'adaptives' section of the interface description file for
the C-API. This change removes the requirement for the data dictionary
file to define adaptive parameters. Now adaptives can be defined without
a data dictionary file.
• Updated the angular A/D sampling functionality to provide each

sample individually or as an average
Previously, the pan_get_angular_ad() function or

pan_AngularAnalogInput block provided the average result of sampling A/
D inputs at multiple points synchronously to the overall engine position.
Now, for the C-API, the pan_get_angular_ad() function

has been marked deprecated and replaced with the
pan_get_angular_ad_avg() function to return the average of the
samples. The pan_get_angular_ad_samples() function has been
added to fill an array with each individual A/D sample.
For the Sim-API, the pan_AngularAnalogInput block has been updated

with a mask parameter which allows the block to be configured to
output a scalar representing the average A/D reading or output a vector
representing each individual A/D sample.
• Added support for Mathworks MATLAB releases R2012a and

R2012b
Calibration


Change log

software.
• Added support for PiSnoop
Pi Innovo's PiSnoop tool has many functions that are useful in typical
OpenECU developments. It offers a cost-effective alternative to traditional
calibration tools, but its emphasis is more on software development than
calibration. It also includes features for working with CAN messaging,
J1939 and UDS/KWP/J1979 diagnostics.
Visit our website [http://www.pisnoop.com] to download a free fully-

functional demo of PiSnoop.
The .elf file is also now output at the root level of the build alongside the
image and .a2l files to facilitate its use, giving access to data structures
and variables not available in the .a2l file. Also the base calibration image
file is similarly emitted to aid reflashing with modified calibrations using
PiSnoop.
Code generation

• Removed support for Diab 4.4b
• Basic support for Model Referencing added
This change adds basic support for Model Reference to OpenECU ERT
based models using MATLAB/Simulink versions R2008b to R2012b .
Model references can now be built along with the parent model. The model
reference blocks currently only support native Simulink blocks and the
put_Identification block.
The reference models do not require a put_Identification block in order to

build.
There are new configuration parameters for the OpenECU target

settings which are stored in the Configuration Set of the model. These
parameters can be modified using the put_Identification block in the
top level model and then propogated to each reference model by
either clicking the “Propogate settings to Model References” button
on the OpenECU target settings tab of the Real-Time Workshop
Configuration Parameters menu, or by running the MATLAB script
oe_propogate_target_settings.m on the top level model.
The model reference build supports Configuration Sets defined either in

each model separately, or using a Configuration Set reference in the base
workspace.
• Add support for Diab compiler versions v5.8.0.0 and v5.9.0.0 for
various ECU targets

Change log
For the M220, M250, M460, M461, U82, X221 and X657 targets, support
has been added for Diab v5.8.0.0 and v5.9.0.0 (existing support for Diab
v5.5.1.0 has been retained). For the C-API, see the updated installation
instructions for more. For the Sim-API, see the RTW setting section.
• Integration with MathWorks Real-Time Workshop based ASAP2

generation
This change is for integration of ASAP2 generation with MathWorks Real-

Time Workshop tools. This change adds support for the use of native
Simulink Lookup blocks and the generation of ASAP2 entries for these
blocks in the generated A2L file(s).
• Add support for service $19 subfunction $0A
• Add attribute to DTE/ DME structures to define if they are in-use or

not
Added support to define a DTE or DME as in-use in order to include or

remove it from consideration during computations that use DTE and DME
values and states.
• Added support for UDS service ControlDTCSetting $85
UDS service $85 ControlDTCSetting is now supported. The service can

be used to stop or resume the setting of diagnostic trouble codes (DTCs).
• Communications Control
Support for UDS service $28 communications control added to the

platform. Interfaces provided for C-API only.
Support for J2190 service $28 DisableNormalMessageTransmission and

J2190 service $29 EnableNormalMessageTransmission added to the
platform. Interfaces provided by the C-API only.
decoding.
• Addition of current monitors for M220

Change log
New current monitor inputs have been added to a select few M220 output
pins as shown in the table below. The current monitor inputs are only
available on M220 ECUs that have the circuitry populated. On M220 ECUs
without the circuitry, the inputs will return 0V.
Pin C-API macro name Sim-API channel name

A17 PIO_AIN_A17_MONITOR_C Monitor (c) (pin A17)
• GPIO outputs in IO file to support switched pull up/down resistors

for X657
Updated ecu_x657.io to include GPIO outputs on required PINS (A18-

A21,B12, A38,A35,A34).
• Addition of crank tooth edge polarity selection to the crank

configuration
The pan_config_crank_wheel_mtg() function and

pan_CrankWheelConfig block now have an additional parameter to
configure the tooth edge to use for synchronisation. Previously the
platform defaulted to falling edge for all targets. Now the edge is selectable
as either default, rising, or falling edge. The M220 target was previously
incorrectly configured to detect the falling edge, but is now configured to
detect rising edge by default.
• Added interface to modify parmeters relating to crank

synchronisation
For the M220 and M250, a C-API function called

pan_config_crank_wheel_mtg_ext and Sim-API block called
pan_CrankWheelConfigExt which allows the application to modify various
parameters relating to crank synchronisation.
Note
This interface is experiemental and has very little testing.
• Extended calibratable parameters relating to crank synchronisation
The extened crank configuration interface has been modified to:
• seperate the ratio settings for noise-rejection and stall-detection;
• extend the range for stall-detection ratio parameter from [0, 1) to [0, 4)
to accomodate engines with lower inertia.

Change log
Note
This interface is experiemental and has very little testing.
• Added documentation to the user guides for the extended crank

wheel configuration interface
• Added cam wheel tooth edge angle measurement
At the C-API level, the pan_config_cam_wheel_mt() function has

been added to allow an application to specify how to record angles relating
to cam wheel teeth. The pan_get_cam_wheel_teeth_angles()
function has been added to retrieve the recorded cam teeth angles.
At the Sim-API level, the existing pan_CamWheelConfig block has been

extended with an additional option for multiple cam wheel teeth to allow
an application to specify how to record angles relating to cam wheel teeth.
The pan_CamWheelToothEdgeAngles block has been added to retrieve
the recorded cam teeth angles.
In both cases the mechanism for achieving synchronisation to the cam

wheel is the same as before: an angle window in which a cam wheel tooth
edge can be detected that is unique across both halves of the engine
cycle.
• Added variable sample angles for crank synchronous A/D inputs
For the C-API, the pan_config_angular_ad(),

pan_get_angular_ad(), pan_get_angular_ad_avg() and
pan_get_angular_ad_samples() functions have been made
deprecated (and will be removed in a future release). These functions
have also been restricted to the G400, G800 and G850 targets, and
therefore can no longer be used on the M220 and M250 targets.
These functions have been replaced with

pan_config_angular_ad_fixed(),
pan_get_angular_ad_avg_fixed() and
pan_get_angular_ad_samples_fixed() for equivalent
functionality, i.e., declaring the sample angles during application
initialisation. These functions are similarly restricted to the G400, G800
and G850 targets but may be extended to the M220 and M250 targets in
the future.
In addition, functions pan_config_angular_ad_variable(),

pan_get_angular_ad_avg_variable() and
pan_get_angular_ad_samples_variable() to allow the
application to vary the sample angles, relative to TDC-firing, while the
application runs.
Similar functions, pan_config_angular_ad_abs(),

pan_get_angular_ad_avg_abs() and

Change log
pan_get_angular_ad_samples_abs() have been added to allow the

application to sample relative to zero crank degrees.
For the Sim-API, the existing pan_AngularAnalogInputConfig block has

been extended with a new mask parameter to specify whether an A/D
group should use fixed (model build-time) or variable (model run-time)
sample angles.
The pan_AngularAnalogInput block has been deprecated (and will be

removed in a future release) and similarily restricted to the G400, G800
and G850 targets.
Three blocks have been added, pan_AngularAnalogInputFixed,

pan_AngularAnalogInputVariable and
pan_AngularAnalogInputVariableAbs. When an A/D group has
been configured for fixed sample angles, use a
corresponding pan_AngularAnalogInputFixed block. When an
A/D group has been configured for variable sample
angles, use a corresponding pan_AngularAnalogInputVariable or
pan_AngularAnalogInputVariableAbs block.
Note
As part of the changes to the A/D sampling interface, the resolution
of the sample angle has been reduced from 0.1 degrees to 6
degrees.
• Add support for gasoline port injection functionality on the M220

target
The pan_set_injection_gpi() function and pan_Injection_GPI

block, and pan_update_injection_gpi function and
pan_UpdateInjection_GPI block, are now supported on the M220 target
in 720 degree mode only (i.e., once crank and cam synchronisation have
been achieved). The pan_set_initial_injection_gpi() function
and pan_InitialInjection_GPI block are not supported.
As of this release, the software provides support for the angular blockset
(Sim-API) across various ECU targets as follows:
Block support G400 G800 G850 M220 M250

pan_AngularAnalogInputConfig Y Y Y Y Y
pan_AngularAnalogInput Y Y Y Y Y
pan_CamWheelConfig Y Y Y Y Y
pan_CamWheelDeclareSync Y Y Y Y Y
pan_CamWheelMovement N N N Y Y
pan_CamWheelSpeed N N N Y Y
pan_CamWheelSync Y Y Y Y Y
pan_CrankWheelConfig Y Y Y Y Y
pan_CrankWheelMovement Y Y Y Y Y
pan_CrankWheelSpeed Y Y Y Y Y

Change log
Block support G400 G800 G850 M220 M250

pan_CrankWheelSync Y Y Y Y Y
pan_CurrentCrankAngle Y Y Y Y Y
pan_CurrentCrankTooth Y Y Y Y Y
pan_CurrentCylinder Y Y Y Y Y
pan_CurrentEngineAngle Y Y Y Y Y
pan_EngineConfig Y Y Y Y Y
pan_EngineSpeed N N N Y Y
a a
pan_EngineSpeedConfig N N N Y Y
pan_EngineSync Y Y Y Y Y
pan_InjectorConfig Y Y Y Y Y
pan_InjectorConfig_DI N N N Y Y
pan_InjectorCompConfig_DI N N N Y Y
pan_InjectorCompAdapt_DI_block N N N Y Y
pan_InjectionOverrideFrp_DI N N N Y Y
pan_Injection_DI N N N Y Y
pan_InitialInjection_GPI Y Y Y N N
b
pan_Injection_GPI Y Y Y Y N
b
pan_UpdateInjection_GPI Y Y Y Y N
c c c d e
pan_KnockConfig N N N N N
c c c d e
pan_KnockDetectionWindow N N N N N
c c c d e
pan_KnockFeedback N N N N N
c c c d e
pan_KnockFilter N N N N N
pan_SparkConfig Y Y Y Y Y
pan_Spark Y Y Y Y Y
a
Although there is a known defect, see the section Outstanding issues for details.
b
Adding GPI support to the M250 target in the future is largely a testing task, currently waiting on another feature
change to support multiple variants of hardware and software in the same install package (ref. W-CR 6584).
c
Currently not supported.
d
Cannot be supported.
e
Could be supported if a knock processing daughter board were developed.
Note
Some blocks are not supported based on the overall configuration
for the angular blockset. For instance, the pan_CamWheelSpeed
block is not supported if the pan_CamWheelConfig block selects
application declared cam wheel synchronisation. See the user guide
for details.
Some blocks have varying levels of functionality across all

supported ECU targets. For instance, the pan_Injection_GPI
supports 360 and 720 degree mode injections on the G400, G800
and G850 targets, but only 720 degree mode injections on the M220
and M250 targets. See the user guide for details.

Change log
• Add support for application determined cam synchronisation on

M220 and M250 targets
An extension of CR 6635 (W). See CR 7196 (F) for a list of angular blocks
and their support across targets.
• Add support for the angular functionality on the M220 target ECU
Installation

before OpenECU.
• OpenECU Developer Software now supports Microsoft Windows 7

(32-bit)
The OpenECU Developer Software blocksets, scripts and installers have

been upgraded to support the Microsoft Windows 7 (32-bit) operating
system. Integration with MATLAB (32-bit) is now also supported on
Windows 7.
Target ECU

• Sim-API added to X657 target
• Removed deprecated ECU targets
The following ECU targets are no longer supported: A450, G400, G800
and M001.
User documentation

and PDF formats.
• Added details about deprecated and end-of-life parts to the

OpenECU product
The release notes have been updated to include details about parts of
the OpenECU product which are marked deprecated (will no longer be
available in a future release of the product) and marked end-of-life (no
longer available for sale or support).

Change log
An up-to-date list can be found on the Pi Innovo

website (http://www.pi-innovo.com/support-center/compatibility [http://
www.pi-innovo.com/notifications]).


developer software.
• Various corrections to the pai_AnalogInput block
The pai_AnalogInput block incorrectly swapped the minimum and

maximum fault outports during simulation mode, for both raw and
engineering. This has been corrected.
The pai_AnalogInput block incorrectly truncated the raw A/D sample to

10 bits when both running in simulation and on target. This has been
corrected.
• Array indexing error when checking Simulink blocks for target

compatibility
The function that checks that a given Simulink block is supported by the
target specified in a model was using an incorrect array bound in its list
of supported targets. As a result, these checks could sometimes fail. This
has now been corrected.
• Fixed warning from put_Identification block when saved with

obsolete target
Previously, if a model from an earlier version of OpenECU is saved with

a target set in the put_Identification block that is obsolete in the current
version of OpenECU, then the following warning was raised when the
model was opened:
Warning: In instantiating linked block '[model name]/put_Identification'

Invalid setting in put_Identification block (mask)
'put_Identification' for parameter 'put_id_marque'.
The block would revert its target setting to the first option on the list and
no further changes in functionality should occur. This has been fixed.
• Minor fixes to the documentation of ptm_RealTime block

Change log
Previously, the help documentation for this block incorrectly described

the behaviour of the “Relative” time option, and implied that floating-point
instead of integer values were output. These issues are now fixed.
• Removed support for Mathworks MATLAB R2006b
• X657 can now support any CAN bus in the range [0,2] and will
generate an error outside this range
The CAN bus values are range-checked for CCP, ISO diagnostics and
J1939. If the CAN bus value is outside the range supported by the target
an error will be generated. Previously an error was generated for bus 2
on X657, but this is now fixed.
• Correction to the psc_KickWatchdog block
Previously, the psc_KickWatchdog block reset the main processor

watchdog regardless of the inport state. This would likely result in
the application resetting the watchdog too frequently, degrading the
effectiveness of the watchdog scheme.
Now, the psc_KickWatchdog block will reset the main processor watchdog
when the inport is non-zero.
• Correction to put_Identification block to avoid warnings when

loading a model
Previously, whenever a model was loaded, a long list of warnings would

be raised in MATLAB of the following form:
Warning: In instantiating linked block '<model-name>/put_Identification'

Invalid setting in put_Identification block (mask) 'put_Identification'
for parameter 'dummy_marque_00'.
The block has been fixed so that this warning is no longer raised.
• The Adaptive blocks do not generate properly on the Real-Time

Workshop Embedded Coder target when Global data is placed in a
seperate file
Previously the default values of adaptive parameters could be incorrect

when stored in a seperate file. Now the adaptive parameters are properly
handled when the variables are stored in a seperate file.
• Extension of MathWorks Real-Time Workshop based ASAP2

generation
Previously, the current operating point was not correctly supported

for the pnv_AdaptiveMap1d, pnv_AdaptiveMap2d, put_Calmap1d, and

Change log
put_Calmap2d blocks. Now the blocks correctly populate the current

operationg point variable in the generated ASAP2 file, when that variable
is available.

generation
Previously, support for ASAP2 entries for the RAM copy of the
adaptive variables use by the pnv_AdaptiveMap1d, pnv_AdaptiveMap2d,
pnv_AdaptiveScalar, and pnv_array blocks was removed.
Now this support has been added back in for Real-Time Workshop based
ASAP2 generation only. During the ASAP2 file generation process a new
ASAP2 entry will be added for each block following the naming format
<default-variable-name>_ram, the remaining fields for the ASAP2
entry will be the same as the default value.
• Added requirements, design and user documentation for PNTK

feature
The PEF (external flash) feature provides access to a serial external flash
memory used in X657 only. User documentation for this is now provided.
Additionally, internal documentation has been updated.
• Removed field sign information from the pj1939_PgTransmit block
The Field sign mask parameter from the Simulink pj1939_PgTransmit

block was unnecessary to the underlying implementation. As such, the
mask parameter has been removed. When a model using this block is
loaded, Simulink will emit warning messages like the following example,
which can be safely ignored:
Warning: In instantiating linked block [...] : pj1939_PgTransmit
block (mask) does not have a parameter named 'pj1939_field_sign'.
Calibration

software.
• CCP Security performance and documentation updates
Several sections of documentation related to CCP seed-key security have

been updated.
The interaction of CCP with nvram during startup could cause very long
startup times; this has been improved.
An issue where seed-key security may not be correctly applied

immediately after flashing a new application configured for seed-key but
with CCP disabled resolved.

Change log
Note
Code generation

• Fix for MathWorks Real-Time Workshop based ASAP2 generation of

adaptive parameters
Previously, the ASAP2 entries for adaptive parameters could be missing

from the generated A2L file depending on whether the model used multiple
native Simulink lookup table blocks configured for the same parameter in
the model. Now the adaptive parameters ASAP2 entries will be generated
correctly.
• Turned off RTW option Generate Report when creating an OpenECU

model using oe_create_model
• Correction to handling of ASAP2 name shortening and renaming
Previously, ASAP2 generation would shorten names to ensure

compatibility with the ASAP2 standard, which requires 31 or less
characters per name. Any shortened name with a duplicate would be
further renamed by replacing characters at the end of the name with a
unique number. The logic for this replacement was wrong, and rather than
deal with thousands of renames, the logic would stop at 150 renames,
resulting in an error similar to this:
(capi.py): (error 3008): found internal error while creating a

unique ASAP2 identifier for group name '[some-name][some-number]' --
too many unique conversions.
• Correction to handling of ASAP2 name shortening and renaming
Previously, ASAP2 generation would shorten names to ensure

compatibility with the ASAP2 standard, which requires 31 or less
characters per name. Any shortened name with a duplicate would be
further renamed by replacing characters at the end of the name with a
unique number. The logic for this replacement was wrong, and rather than
deal with thousands of renames, the logic would stop at 150 renames,
resulting in an error similar to this:
(capi.py): (error 3008): found internal error while creating a

unique ASAP2 identifier for group name '[some-name][some-number]' --
too many unique conversions.

Change log
• Correction to pcx_TransmitMessage block crash in Simulink
Previously, this block would cause an exception and a stack dump if

anything other than an integer was set as the “Field Type” parameter.
This has been fixed so that if anything other than an integer is set as the
parameter, an error block pops up.
• Correction to Simulink CANdb blocks
Previously, the CANdb file used by the pcx_CANdb_ReceiveMessage

and pcx_CANdb_TransmitMessage blocks needed to be in the current
working directory when the Simulink model was updated or built. This
restriction has now been removed, and the CANdb file can now be in any
directory as long as it is on the MATLAB path.
• Correction to Simulink blockset to support real_T datatypes, and

object based data dictionary
Previously, the code generation of the blockset would incorrectly assume

that real_T was single precision, when this was actually double
precision. The code generation now uses the intended data types for a
portion of the blockset.
The blocks modified in this release are:
• pai_AnalogInput
• pan_AngularAnalogInputConfig
• pan_EngineConfig
• pcx_CANdb_ReceiveMessage
• pcx_CANdb_TransmitMessage
• pcx_CANReceiveMessage
• pcx_CANTransmitMessage
• psc_BootBuildDate
• psc_BootVersion
• psc_PlatformBuildDate
• psc_PlatformVersion
• psc_PrgBuildDate
• psc_PrgVersion
• put_Reset
• Correction to Simulink blockset to support real_T datatypes, and

object based data dictionary
Change log
Previously, the pcx_CANdb_ReceiveMessage,

pcx_CANdb_TransmitMessage, pnv_AdaptiveMap1d,
pnv_AdaptiveMap2d, pnv_AdaptiveScalar, put_Calmap1d,
put_Calmap2d, and put_Reset blocks could use incorrect data types
during simulation, resulting in possibly corrupted simulation results in
seemingly unrelated blocks. The blocks now use the correct data types
during simulation, and prevent incorrect data types during the model
update process.
• Correction to model build error when using a block requiring

absolute time triggered from the pan_EngineConfig block
Previously if a block in a function-call subsystem triggered from the

pan_EngineConfig block, required a reference to time, then a model build
for the RSim coder would fail with an error message about getTick and
tid.
• Correction to handling of short DDE names
Previously, DDE names with a prefix and a single character for the name
(for instance, MAPd) would cause the C-API tool to fail when generating
ASAP2 files.

generation
This change extends the interface for ASAP2 generation to include

both RSIM and RTMODEL coders, and fixes minor issues with the A2L
generation.
• Extension of MathWorks Real-Time Workshop/Simulink Coder

based ASAP2 generation
Previously, support for ASAP2 generation was only supported up to

R2010a, now support has been extended up to R2012b.
Communications

ISO-15765 over CAN.
• Allow CAN blocks to be used in triggered sub-systems
Previously, the pcx_CANReceiveMessage and

pcx_CANTransmitMessage blocks would raise an error if used in triggered
sub-systems, i.e., when used with an inherited sample time.

Change log
• Should support $FFFFFF in $14 ClearDiagnosticInformation for UDS
Added support of UDS service $14 request.
• Problems in service $14 request
Added clearing of diagnostic information in response to service $14

request.
• Issues with DM36, DM37 and DM40
Corrected the various data limits and default values sent on DM40.
• Occurrence count of DTC in freeze frame instance is not being

updated when that DTC became active
Enhanced user guide to explain the occurrence count reported in DM

messages.
• Clearing of data on receipt of DM3 and DM11 messages
Enhanced user guide to add some hints for DM3/DM11 clearing of test
values.
• Update documentation for deprecated behavior in C-API function

pdtc_get_dtc_status()
Udpated documentation to reflect deprecated behavior of the function

when using the pdtcf_lamp_bitmap parameter to obtain lamp
information from pdtc_get_dtc_status().
• Incorrect argument type for override_state in ppid_get_pid()
Changed the type of the ppidf_override_state parameter from

BOOL* to U8* to match the implementation. Cosmetic change only.
• Parameter validation for pj1939_dmX_transmit() and

pj1939_set_control_area_status()
Improved the range checking on the message priority for transmitting

various DMs using the pj1939_dmX_transmit() functions. If a priority
numerically higher than 7 is requested, the function will clip the priority to 7.

Change log
pj1939_set_control_area_status() now validates its arguments

and returns a BOOL to indicate success. A requested area or status value
outside the supported ranges will make no changes to the status area and
will return FALSE. Calling the function with valid arguments changes the
status area and returns TRUE.
• DM10 test mapping fixed when no DTEs with TIDs in range [1,64]
Previously any model which had DTEs defined, but none in the range
[1,64], would fail at build time. This has been corrected.
• Send J1939 NACK for unsupported tests
Platform now sends NACK response when an unsupported test is

requested by the test tool.
• Updated documentation related to control of DTCs reported for

J1979/ISO diagnostics
Updated documentation related to the automatically generated calibration

pdgc_emissions_report_min_sev which controls which DTCs are
reported for J1979 and ISO services, as well as J1939 DM32.
• Clarify DTC type selection in the Sim-API
Previously, there were several blocks containing the parameter DTC Type
that, as one of the options had J1939 & ISO_DTC. This option has been
prone to misinterpretation because some DTC blocks with this option
selected refer to “either-or-both”, while others with this option selected
refer to “only both”.
The blocks that are affected and have been updated are: pdtc_ClearAll,
pdtc_ClearAllIfActive, pdtc_ClearAllIfInactive, pdtc_MatchExists, and
pdtc_ClearDtcs. These blocks have the parameter DTC Type
dropdown menu updated to say “J1939 or ISO_DTC”. The block
pdtc_DiagnosticTroubleCodeExt has it's DTC Type dropdown menu
updated to say “J1939 and ISO_DTC”.
Models that contain these blocks should be updated by opening the block
and selecting the DTC type. When a model using any of these blocks are
loaded, Simulink will emit warning messages, which can safely be ignored.
• Update KW2000-3/UDS handling for service $3E (Tester Present)
Service $3E now correctly handles Test Present requests with parameter
bytes 0x01 and 0x02 in addition to 0x00 and 0x80. 0x00 and 0x01
generate a positive response while 0x02 and 0x80 do not generate a
response.
Examples

Change log

• Fix for warnings displayed when loading an example model in

Simulink
Previously, the example models callback functions were

not setup correctly for OpenECU. The example models
for: candb_demo, fixed_angular, nvm_demo, two_pot_demo, and
two_pot_demo_w_sfunction would all emit a warning about the callback
of a block diagram. This was causing the workspace to not be loaded
properly when the model was opened. These models have been fixed
so that they no longer emit these warning messages and so that the
workspace loads properly.
• Correction to example models for angular functionality, allowing

them to build

• Changed M250 firmware to actively turn off pin A16 after power-on
or reset
Previously, the M250 firmware would leave pin A16 driven on, the default
configuration. This meant that pin A16 would be turned off only when the
application started to run (if written to do so), leaving pin A16 turned on
during reprogramming mode.
Now, the M250 firmware actively drives pin A16 off after power-on or reset.
Pin A16 will remain off in reprogramming mode, and the application will
need to actively turn pin A16 on if required. This means that pin A16 will
briefly glitch on after power-on or reset.
Note
• Validate calibration area before running application

Change log
Previously, only the application header was validated by checksum, and

the actual application code if configured with a checksum, before the boot
loader would attempt to run it. However, it was possible to interrupt the
programming process such that the calibration area was erased or part-
programmed but the application code was intact. Running the application
in such a state would generally lead to a reset.
Usually such a reset caused by invalid calibration data would trigger the
multiple reset detection logic, leaving the ECU in a state in which it could
be reprogrammed again. However, certain failure modes did not trigger
this logic, leaving an ECU that required FEPS to reprogram. Also, it was
conceivable that an application could run successfully with just a small
proportion of the calibration values invalid, leading to ill-defined behaviour.
After this change, if the application header is found to be intact by the boot
loader, it also checks the calibration header if one is referenced by the
application header. (For backwards compatibility with older builds, there
may be no such reference.) Furthermore if the calibration header defines
a full checksum over the calibration data, that is also validated. Only if all
validation passes is the application started; otherwise the ECU remains
in reprogramming mode.
Note that to allow calibration development work, the calibration area would
not normally have a full checksum. However, this can be generated using
the pop_header utility on production builds for the final calibration.
Note
decoding.
• Fix for recovery of synchonrisation with cam wheel
Previously, if synchronisation with the cam trigger wheel had been

attained, subsequently lost, and then the edge moved back into the
configured window, the cam function would be internally synced, but
the sync state returned from the pan_get_cam_wheel_sync() C-API
function and pan_CamWheelSync Sim-API block would be incorrect. Now
the sync state will be correctly returned for this scenario.
• Correction to generation of direct-injection pulses at transition

periods

Change log
Fixed an error in the direct-injection functionality that could incorrectly

delay all pulse requests by one engine cycle, producing a cycle with no
pulses, after periods of operation with no pulses.
Fixed an error where a pulse schedule starting at or just after the crank
missing tooth could generate an incorrect pulse at crank zero before
engine synchronisation, and an incorrect first sequence of pulses the first
cycle after synchronisation.
• Correction to direct-injection interface
Fixed an error in the direct-injection interfaces (the C-API

pan_set_injection_di function and Sim-API pan_Injection_DI block)
that could prevent any injections from being scheduled due to incorrect
checking of on-angles of pulses with a requested amount of zero. Pulses
with zero amount are now correctly ignored.
• Correction to generation of TDC-firing asynchronous sub-system

code generation
Previously, depending on the relative positioning of the put_Identification

and pan_EngineConfig block, it was possible for a model build to generate
an empty function for the TDC-firing asynchronous sub-system. This
resulted in none of the engine position synchronous logic running on
target. This has been corrected.
• Fix to gasoline port injection functionality starting an extra engine

cycle after engine sync
Previously, the injection function could take up to 5 crank cycles from first
edges of the crank input before starting the injections. The first crank cycle
would provide crank sync. The next cycle would provide full engine sync.
Then there would be two skipped cycles. On the next cycle the injections
would start. Now the skipped cycles are removed. The injections now
occur either immediately after engine sync, or one crank cycle after if an
offset is declared during application declared cam sync.
• Correction to gasoline port injection and spark angular outputs at

zero absolute degrees
Previously, if the on-angle of an injection pulse, or the on-angle of a spark

pulse was scheduled at an absolute crank angle (i.e. after tdc relative
offset is applied) in the range [0, 0.1] degrees and full engine sync has
not been attained. The output could turn on without full engine sync. This
issue has been avoided by rounding the requested angle in this range to
0.1 degrees.
• Correction to angular task skipping one engine cycle

Change log
Previously, the angular task would occassionally skip one engine cycle
due to an error in the feature which generates the angular task. This would
result in the appearance of one duplicated cylinder, and the spark outputs
would not be updated for that cycle, even the the injection could be.
• Correction to pkn_TaskDuration Simulink block to return the angular

task duration
Previously, the pkn_TaskDuration block did not support returning the

value of the angular task and there was no other way to return that value
to the application. Now the angular task duration is available when a -1
sample time (task) is provided to the block parameter.
• Correction to per-rev engine speed calculation when cam

synchronisation is found or declared
Previously, the data for per-rev engine speed calculations was zeroed
when transitioning from 360 to 720 degree mode, resulting in a zero per-
rev engine speed result for up to two crank revolutions.
• Correction to crank angle tracking
Previously, depending on how early the first tooth after the missing tooth
region arrived immediately after the ECU found crank synchronisation, the
ECU would incorrectly adjust the tracked angle resulting in an offset for
angle based functions such as injection and ignition.
• Enabled interfaces for crank synchronous A/D sampling on M250

target
Previously, if the crank synchronous A/D sampling with variable

run-time sample angle interfaces were used on the M250 target,
the application build would fail at the link stage, with an
error about C functions pan_config_angular_ad_var() and
pan_get_angular_ad_avg_var().
• Corrected handling of out-of-range frequency for H-bridge outputs
Previously, frequency requests in the range specified by the user guide

are correctly generated, but out of range requests were not. This has been
fixed.
• Correction to angle measurement when using a 32-2 patterned crank

wheel
• Correction to engine speed calculation where the engine TDC-firing

angles are not symmetrical

Change log
• Fixed simulation behaviour for the

pan_AngularAnalogInputVariable and
pan_AngularAnalogInputVariableAbs blocks
Previously, if the pan_AngularAnalogInputVariable or

pan_AngularAnalogInputVariableAbs block was simulated, the blocks
would either:
• cause the simulation to freeze due to the an incorrect outport width

determination; or
• report an incorrect port width for the samples inport if averaging was
turned off.
• Correction to crank synchronous A/D and crank tooth time sampling
Various issues have been discovered and resolved:
• Just after crank synchronisation was achieved, the sampling function

would suspend operation for one crank revolution, leading to crank
synchronous A/D samples and tooth times to be off by 360 degrees until
cam synchronisation was found or declared.
• When the application declared cam synchronisation, depending on

the crank configuration and crank signal, it was possible to miss one
sample, leading to crank synchronous A/D samples and tooth times to
be off by 6 degrees.
• When the application declared cam synchronisation, 360 degrees of

samples could be skipped depending on the sequence of events prior
up to cam synchronisation, leading to crank synchronous A/D samples
and tooth times to be off by 360 degrees.
• When the application declared cam synchronisation, one or two TDC-

firing triggers could be skipped depending on the sequence of events
prior up to cam synchronisation, leading to the TDC-firing triggered part
of the application becoming suspended without any indication.
• Correction to crank synchronous A/D sampling
Two issues have been discovered and resolved:
• Previously, after crank synchronisation was achieved, and before cam

synchronisation, the crank synchronous A/D would only sample one
engine cycle before stopping, resulting in the samples appearing to be
stuck. Now the crank synchronous A/D samples will continue to update
while crank synchronisation is achieved after the first engine cycle,
before and after cam synchronisation.
• Previously, when the application declared cam synchronisation with an

offset declared, the crank synchronous A/D samples would not switch
engine phase. Now the crank synchronous A/D samples will switch to
the correct phase if an offset is declared.

Change log
Two issues have been addressed:
• Previously, when cam synchronisation was declared without an offset,

the cranksync A/D inputs would not always align with the correct engine
phase. Now the crank synchronous A/D samples switch engine phase
correctly with or without the offset declared.
• Previously, when the application declared cam synchronisation, the

cranksync A/D inputs would clear their previous values, and it would
take a full engine cycle to update the values. Now when an offset is
declared, the previous A/D inputs will switch phase using the previous
values. There is still one outstanding issue related to this, regarding
the A/D values being incorrect for the next engine cycle, which will be
addressed in the next release.
Previously, when the application declared cam synchronisation, and the

cranksync A/D inputs switched phase using the previous values, there was
one engine cycle where the A/D values were incorrect, this is now fixed,
and the A/D values will read the correct last value, until they are updated
by the next engine cycle.
• Correction to M220 inputs for pins A4, A6, A8 and A9
Previously, the M220 pins A4, A6, A8 and A9 were marked as analogue
inputs rather than digital inputs. Reading these pins as analogue inputs
returned an undefined reading. These pins can no longer be read as
analogue inputs but can be read through various digital interfaces (such
as digital input, frequency input and so on).
The application will need to be adjusted to match the change in pin

function. C-API applications that referenced those pins will not compile
and will need to be adjusted. Sim-API applications that referenced those
pins will be changed by Simulink when the model is loaded, losing the pin
settings for any analogue input block, and will need to be adjusted.
• Fix to gasoline port injection functionality skipping an engine cycle
Previously, when the on-angle commanded using the pan_Injection_GPI

block crossed the zero degree absolute angle boundary (i.e. relative to
TDC) the injections would skip one engine cycle. This is now fixed, and
the on-angle can be on either side of the zero degree boundary without
skipping any cycles.
• Minor correction to pan_EngineConfig block
Previously, as described in CR 6467 (W), the pan_EngineConfig block

would cause Simulink to emit a warning about sample time when the

Change log
model was updated or built. The pan_EngineConfig block has been

updated and Simulink no longer emits a warning.
• Corrected engine speed calculation based on crank teeth relative to

TDC-firing
Previously, the engine speed calculation through the C-API

pan_get_engine_speed_tooth_range() function and Sim-API
pan_EngineSpeed block was derived by recording the time at which
specific crank teeth occurred every 360 degrees, rather than every 720
degrees. This meant that reported engine speed for a cylinder might have
been measured in the wrong half of the engine cycle.
Now, the tooth time capture occurs relative to TDC-firing for each cylinder.
As part of correcting this issue, the interface has changed from specifying
the teeth at application build time to specifying the teeth at application run-
time. As the interface was previously broken, rather than retain the old
interface marked deprecated, the existing interface has been replaced.
For the C-API, functions

pan_config_engine_speed_tooth_range() and
pan_get_engine_speed_tooth_range() have been removed,
and replaced with pan_get_engine_speed_tr_rel() and
pan_get_engine_speed_tr_abs().
For the Sim-API, block pan_EngineSpeedConfig has been removed, and

absolute and relative teeth engine speed calculations can be performed
with the pan_EngineSpeed block.
• Calculate tooth-to-tooth engine speed when crank synchonisation

has been gained
Previously, tooth-to-tooth engine speed was calculated when both crank

and cam synchronisation had been achieved. Now, tooth-to-tooth engine
speed is calculated when crank synchronisation has been achieved (cam
sychronisation has no effect, except when cam synchronisation is gained
or lost).
• Correction to tooth-to-tooth engine speed function
Previously, it was possible to read incorrect speed from the tooth-to-tooth

engine speed if there was high acceleration between crank teeth, as the
time of the tooth after the acceleration could be missed. Now the tooth-to-
tooth engine speed captures crank teeth times more robustly, and should
not return incorrect speeds. This change breaks backwards compatibility
with the direct injection functions, and as such these functions have been
temporarily disabled. These will be re-enabled under F-CR9395.
• Extended range of crank trigger wheel patterns

Change log
For the G400, G800 and G850 targets, the range of crank trigger wheel
patterns has been extended from [36, 60]-[1, 2] crank teeth to [12, 60]-[1,
3]. This extended range matches the M250 target.
Installation

before OpenECU.
• Allowing C-API documentation links to be installed if Sim32 blockset

is not installed
Previously, if only the C-API library was selected for installation, the
corresponding HTML and PDF user guides were not given Start menu
links, although the files were installed. This is now fixed.
• Installer was not properly integrating with Windows 7
When run on Windows 7, the OpenECU installer was deleting pathdef.m

and startup.m files for some MATLAB installations and the uninstaller
was not deleting the Start menu shortcuts. This upgrade fixes these
issues.
The installer and uninstaller now require administrative rights to run.
Target ECU

• PWM dead-time insertion to fix H-Bridge shoot-through problem
Originally, there was an issue with the H-bridge on the M250. Certain
mode transitions have caused a shoot-through problem causing damage
to the ECU. This was due to a lack of a proper amount of latency between
the time the PWM transitioning and the command signal transitioning. The
software has been adjusted so that the PWM signal is low for at least 100
microseconds while the command signal transitions.
This dead-time insertion is only inserted for one task cycle and only if the
PWM duty cycle is greater than 99%. Thus during a mode transition, it will
not be possible to command a 100% duty cycle for one task cycle.
User documentation

and PDF formats.
• Updated information about third party tool compatibility

Change log
The user guides and release notes have been updated to document third
party tool requirements and compatibility.
• Added details to M220 technical specification regarding non-

linearity of pin A16 current monitor response
The M220-000 Operational Details section of the Technical Specification

had no details on the response of the current monitor on pin A16 (Actuator
Supply). A table has been added demostrating the non-linear response
below 0.5A.
• Added user guide entry for OpenECU ASAP2 generation options
The RTW option to generate old style ASAP2 map names was missing
from OpenECU ASAP2 generation options. This change updates the user
guide with explanations about this option.
• Added note about slow and fast current decay for peak and hold
injector outputs for M460 target
3.13. Release 2.0.0 (r2012-1)

Release labelled release-2.0.0-2012-1 from 5 October 2012. This release is marked

compatible upgrade
C-API 9625 (F), 9573 (F), 9507 10120 (F), 9811 (F), 9807 No, see: Yes, see:
(F), 9075 (F), (F), 9799 (F), 9507 (F), 9610 (F),
8819 (F), 7292 (F), 5510 9727 (F), 9724 (F), 9656 4466 (F) 9507 (F),
(F), 5150 (F) (F), 9649 (F), 8933 (F),
9610 (F), 9574 (F), 9508 8819 (F),
(F), 9459 (F), 7900 (F),
7619 (F),

Change log

compatible upgrade
9458 (F), 9405 (F), 9149 7619 (F)
(F), 9073 (F),
8933 (F), 8885 (F), 8835
(F), 8803 (F),
8788 (F), 8779 (F), 8741
(F), 8673 (F),
8274 (F), 8211 (F), 8031
(F), 7978 (F),
7900 (F), 7650 (F), 7619
(F), 7619 (F),
7075 (F), 7044 (F), 7007
(F), 5073 (F),
4933 (F), 4711 (F), 4570
(F), 4466 (F),
4121 (F), 4088 (F), 3811
(F)
Sim-API 9636 (F), 9625 (F), 9573 10260 (F), 10120 (F), 9811 No, see: Yes, see:
(F), 9507 (F), (F), 9811 (F), 9507 (F), 9610 (F),
9075 (F), 8819 (F), 8778 9810 (F), 9807 (F), 9799 8921 (F), 9507 (F),
(F), 7292 (F), (F), 9750 (F), 4466 (F) 8933 (F),
5150 (F), 4222 (F), 1823 9727 (F), 9724 (F), 9656 8819 (F),
(F) (F), 9649 (F), 7900 (F),
9634 (F), 9610 (F), 9590 7619 (F),
(F), 9589 (F), 7619 (F)
9589 (F), 9574 (F), 9563
(F), 9541 (F),
9508 (F), 9464 (F), 9459
(F), 9458 (F),
9437 (F), 9410 (F), 9405
(F), 9149 (F),
9073 (F), 9028 (F), 9016
(F), 8985 (F),
8933 (F), 8921 (F), 8907
(F), 8885 (F),
8835 (F), 8803 (F), 8788
(F), 8779 (F),
8741 (F), 8704 (F), 8673
(F), 8643 (F),
8634 (F), 8237 (F), 8031
(F), 7978 (F),
7900 (F), 7650 (F), 7619
(F), 7619 (F),
7195 (F), 7116 (F), 7075
(F), 7044 (F),
7036 (F), 7007 (F), 6586
(F), 5073 (F),
4933 (F), 4711 (F), 4466
(F), 4121 (F),
4088 (F), 3811 (F)


Change log

developer software.
• Added warnings to deprecated blocks
We have recently started to document features of our products that have

become deprecated. For this change we have added some warnings
to the following Simulink blocks that are deprecated: put_Config_M460,
put_BitwiseOp and pcx_CAN_Status. Building or updating a model with
any of these blocks will output a warning similar to:
Warning: block 'test_j1939/pcx_CANStatus': The pcx_CAN_Status block is

deprecated. Please use the pcx_BusStatus block instead.
• Added C-API functions and Sim-API blocks to access the application

version and build date information
For the C-API, two new functions psc_get_application_version

and psc_get_application_build_date have been added. For the
Sim-API, two new blocks psc_AppVersion and psc_AppBuildDate have
been added.
• Added a MATLAB command to help switch between installed

versions of OpenECU
A new MATLAB command, oe_switch_version, has been introduced

to allow switching between OpenECU Platforms. When several OpenECU
platforms are installed on the same machine, this command allows the
user to switch from one version to another. The command takes care of
changing all MATLAB paths to point to the new platform.
You may use the command:
oe_switch_version
to determine which platforms are installed on your machine and which one
is currently active. You may use the command:
oe_switch_version [new-version]
to switch to a different version. The argument new-version can be the

complete path, or a small part of the path string that is unique for all
installed versions of OpenECU.
Desktop integration

• Change CCP seed/key security, including new Simulink interface

Change log
CCP seed/key security had previously been implemented, but not in a very
portable manner. Security was not available in reprogramming mode, and
there was no Simulink interface.
This has been significantly reworked. As such, it is deliberately not

backwardly compatible, because the old system of configuring CCP seed/
key security was not sufficiently complete.
Application security algorithm functions are now made available in

reprogramming mode, so that reprogramming mode has access to these
security algorithms in the same way as it has access to other CCP settings.
The security functions must not be larger than 2 KiB and must not access
static/global memory or call any functions, but otherwise are free to carry
out any operations required.
Note
For the C-API security algorithm functions require special treatment
during linkage. A new linker file excerpt is generated by the C-API
tool and this must be inserted into the main linker definition file at the
line containing the comment APP_FLASH_CODE_INSERT. A new
Python script called insert_at_tag has been added to facilitate this.
The C-API User Guide provides further information.
For the Sim-API, this is taken care of automatically as part of a model

build.
Note
Examples

• Addition of an extended diagnostics example Simulink model
• New customer examples for C-API and Simulink
There are now new examples for the customers to use and go over. These
new examples have been created for the M250 and the M220 platform.
New examples include: a utility demo, a non-volatile memory demo, an I/
O demo and a CAN demo.
• C-API H-Bridge Demo

Change log
Added a new example to the C-API examples. The example is set for the
M250 and the M220 platforms which demonstrate how to use the H-bridge.
• Extended Simulink example models
Added two Simulink examples; one that demostrates how to use the
CANdb blocks for Mxxx and G850 ECUs; a second detailing the required
blocks and their implementation for the adaptive blocks (NVM), for Mxxx
ECUs only.
Target ECU

• Reserved 128 kB of flash memory on the X657 exclusively for

customer use
• Like the G400 and G800 ECUs, the G850 target is now deprecated
Pi will no longer sell G850s to new customers due to stock levels. For
the time being, support for existing G850 customers continues but new
features are unlikely to be ported to the G850.
• Introduction of part numbers for bootloader, firmware, firmware

upgrade and platform software products
This update includes the introduction of part number variables for the
bootloader (PBT), firmware (PRG), firmware upgrade (PRG2PRG) and
platform (PSC) products. An application build will include new automatic
ASAP2 entries which will show a valid value if the firmware, bootloader or
the platform are up to date or a default value if they are too old. The default
value is usually set to 0, however it is not excluded that meaningless
values be displayed for very old products.
Note
User documentation

and PDF formats.

Change log
• Collapse bookmark outline in PDF documentation making the

outline easier to navigate


developer software.
• Added missing C-API header file for the M220 target
Previously, the M220 preg.h header file was not correctly included with
the package installer. This resulted in a compilation error when building
applications, similar to:
[...] error (dcc:1621): can't find file preg.h
• Correction to pdtc_DiagnosticTroubleCode block
A recent change to the underlying structure of the

pdtc_DiagnosticTroubleCode block introduced an error that caused
certain models containing this block to fail to update or build. This has now
been rectified.
• Updated model load scripts to avoid warnings about reaching the

MATLAB recursion limit
Previously, when loading some OpenECU models, especially larger

models, MATLAB would issue a warning message about reaching a
recursion limit:
Warning: [model-name], line [num]: Maximum recursion limit of 500

reached. Use set(0,'RecursionLimit',N) to change the limit. Be aware
that exceeding your available stack space can crash MATLAB and/or
your computer.
Now, when an OpenECU model is loaded, the recursion limit is raised to

at least 2000 to avoid the warning message.
• The oe_switch_version command will now refresh the library

browser dialog
Previously, when the oe_switch_version command switched versions

of OpenECU, the command would refresh internal cached data, such as

Change log
toolbox information, but the library browser dialog would not update. This
could result in the wrong blockset lists displayed on screen.
Now, with R2008b onwards, the command will refresh the library browser
dialog. For earlier supported versions of MATLAB, e.g., R2006b, the user
must manually close and reopen the browser dialog to refresh the display
of blocksets.
• Added missing C-API header file for the M220 target
Previously, the M220 preg.h header file was not correctly included with
the package installer. This resulted in a compilation error when building
applications, similar to:
[...] error (dcc:1621): can't find file preg.h
• Correction to simulation scale for pai_AnalogInput block
Previously, the simulation code for the pai_AnalogInput block would

incorrectly scale the value of the sim_adc inport by 4, reducing the
simulation range.
• Correction to date handling of data dictionary files
Previously, reading of data dictionary files used the MATLAB DATENUM()

function. Whilst this function deals with a variety of different date formats
returned by the operating system, it does not deal with them all. In
particular, the internationalisation of February in Turkey is #ubat and the
function did not correctly parse the date string.
• Correction in datatype handling for some Sim-API blocks
Previously, there was an issue with the pj1939_Dm4Transmit,

pj1939_Dm24Transmit, and pj1939_Dm25Transmit blocks. If the signal
attached to the transport error outport was not a uint8_t type an
erroneous value would result on that outport.
Also, the ppid_Pid block would output the incorrect value on the
override status outport when the PID's IOControlStatus was equal to
freezeCurrentState or shortTermAdjustment.
• Update to the pcx_CANdb_ReceiveMessage block for simulation

inports
Previously when the pcx_CANdb_ReceiveMessage block had the Provide

Simulation Input? disabled, the engineering value outputs would all emit
1's while the raw outputs would emit 0's. The code has been updated so
that all of the outports emit 0's when this input checkbox is disabled. This
makes it more consistent with the rest of the OpenECU blockset.
• Correction to the available blocks through the platform library

browser

Change log
Previously, the Angular Drivers -> Crank Wheel section of the platform
library failed to include the pan_CrankWheelDigitalInput block. This is now
included.
• Changed some of internal digital outputs names
In a continuing effort to provide less ambiguous and more consistent

naming for internal outputs, across the OpenECU product range, there
have been some changes to the naming or some of the internal digital
signals.
Previous Previous Previous 'Long' name New name

'Powertrain' 'Generic' name
name
M220
NA NA DOT switch-PSU1 DOT enable-EXT-PSU1
M250
DOT EXTPSU1 DOT EXTPSU1 DOT switch-PSU1 DOT disable-EXT-PSU1
DOT EXTPSU2 DOT EXTPSU2 DOT switch-PSU2 DOT disable-EXT-PSU2
M460
EXTPSU3 DOT EXTPSU3 DOT switch-PSU3 DOT disable-EXT-PSU3
M461
Calibration

software.
• Correction to ASAP2 generation for automatically generated DDEs
Previously, as part of CR 7047 (W), the automatically generated DDEs for

some blocks were broken. As a result, automatic DDEs were not added
to ASAP2 files on model build.
Now, automatic DDEs are properly handled and added to ASAP2 files on
model build.
• Correction to data dictionary file handling

Change log
Previously, if a directory for a data dictionary file contained a sub-directory

which was on the MATLAB path, then when the data dictionary files were
read by the OpenECU blockset, the blockset would incorrectly remove the
subfolder from MATLAB's path.
Code generation

• Updated pai_AnalogInput block so that min/max parameters can be

populated with calibrations
Previously, the pai_AnalogInput block split the array values specified in

the engineering and raw min/max mask parameters, and then individually
passed by value at build time. And so, it was not possible to set the
engineering or raw min and max parameters to a single calibrateable. Now
it is possible to specify both engineering and raw min max parameters as
vector calibrations with two elements.
• Modification to allow customer declared and platform automatic

string DDEs to be empty
Previously, an empty description or copyright field in the

put_Identification block would cause an error late in a model build:
(error 1084) [...]: 'mpls_app_copyright' is a string but has no value
(error 1084) [...]: 'mpls_app_description' is a string but has no value
Now, an empty description or copyright field in the

put_Identification block is allowed (no errors or warnings are
generated). And application declared string DDEs can have zero length.
• String based ASAP2 entries are incorrectly generated during an

application build
When building an application, any string based ASAP2 entries are now
correctly generated as “characteristics”, and are correctly displayed in
calibration tools. Platform string variables now stored in calibration area,
to allow migration of applications to an up-to-date platform but use an
existing calibration (file) from an older platform.
• Not all DDE items were added to ASAP2 files when building with the
Sim-API
Previously, if a 1d or 2d map lookup was implemented in the model, and

the x-lookup and/or y-lookup were not in the data dictionary, the build
procedure would fail to include the map in the ASAP2 file. This has not
been addressed.
DDE items were also being omitted from the ASAP2 file if a self referential
library link was found in the model. This was only a problem if the parent
library link was disabled.

Change log
Communications

ISO-15765 over CAN.
• Correction to CANdb file parsing
Previously the parser would not accomodate CANdb files that used the
BA_DEF_REL_ or BA_DEF_DEF_REL_ tokens, resulting in inoperative
pcx_CANdb_ReceiveMessage or pcx_CANdb_TransmitMessage blocks.
Desktop integration

• Add checks to all TLC files to ensure an OpenECU system target file
is selected
If a Simulink model did not have an OpenECU system target file selected
from the RTW options, the RTW build failed with unhelpful error reports
from the per-block TLC files. All TLC files now check that we have an
OpenECU system target file selected, and produce a meaningful error
message if this needs to be corrected.
• Name change to is_overriden parameter
Previously, in the ppid_Pid block in Simulink had an output

called is_overriden. This output name has been changed to
override_status since this name better describes what the output
actually is.
• Analogue inputs on G850 in the wrong angular sampling 'group'
A number of the analogue inputs listed in the two angular sampling input
groups for G850 were assigned incorrectly and it was possible to have
both primary and secondary angular sample channels on same the A/D
device, resulting in the same A/D readings for both primary and secondary
groups. These pins have now been reassigned: E22, E32 and T29, along
with the removal of an the internal analogue channel C35+C36 that is not
sampled by the A/D device.
• Correct state reporting for pdtc_DiagnosticTroubleCode

Change log
Simulink block pdtc_DiagnosticTroubleCode was outputting incorrect

values for DTC states (starting from zero for the clear state to two for
the inactive state). The state values now start from one to match the
existing documentation and to match the extended diagnostics library.
However, this change does mean the block is not backwards compatible
with existing applications.
• J1939 freeze frame data length off by one
The freeze frame data length field in both DM4 and DM25, was reporting
the length as 1 byte bigger than expected. With the size of the data length
field excluded from the calculation of freeze frame data length, the correct
value is now reported.
• UDS/KWP WriteDataByIdentifier requests no longer rejected if size

close to buffer length
Previously, a $2F service (WriteDataBy[Common]Identifier) or KWP

equivalent could fail if the response generated was close to filling the
transmit buffer size, because of double-counting a length. This is now
fixed.
• UDS/KWP ReadDataByIdentifier requests no longer rejected if size

close to buffer length
Previously, a $22 service (ReadDataBy[Common]Identifier) or KWP

equivalent could fail if the response generated was close to filling the
transmit buffer size, because of double-counting a length. This is now
fixed.
• Sample time mask parameter added to Sim-API pdtc_Status block
The Simulink pdtc_Status block had no way of explicitly setting the block
execution rate. A mask parameter has been added for sample time.
• Removed duplicate ppr_MonitorsIncomplete block
• Moved the extended diagnostics blocks from Pi OpenECU to Pi

OpenECU Extras — Diagnostics extensions in Simulink


Change log

• Boot loader upgrade made more robust
The boot loader upgrade program (prg2prg) now waits for a delay time
(currently 1 sec) before beginning erase and flash operations after power
up or FEPS application (on those ECUs that require it). This makes the
process more robust against glitches in the power or FEPS coming up to
voltage.
• Logical index now accepted for UDS erase memory routine
Previously, the erase memory routine ($FF00) supported for HIS-

compliant UDS flash reprogramming only worked with an actual start
address and non-zero byte length supplied from the test tool, interpreted
as the address range to erase. However, the HIS reprogramming
specification actually requires that the "address" is treated as a logical
index for the flash block to be erased, and no length is given at all.
For future flexibility, both options are now supported; with no length bytes
provided, the address number is treated as a flash block index, but if a
length is specified then it is still interpreted as an address. Please refer
to the MPC5534/5565 reference manual for flash block ranges (e.g. the
block indexed 0 is labelled "L0" (0x0000000 to 0x00003FFF), etc).
Note
• SessionControl ($10) in reprogramming mode return to application

mode
When in boot loader (reprogramming) mode, the ECU will now make a
transition to application (normal) mode if it receives a request to enter
the default session (e.g. $10 $01). This is required by the HIS flash
reprogramming specification.
Pi-internal documentation updates related to service $10 were also made

at this time.
Note

Change log
• Enabled pull-ups for unpopulated pads
External pull up resistors have been removed leaving some pads floating.
This change turns on the internal weak pull-ups to protect against EMI.
This change effects both the firmware and the platform library.
Note
• Corrected power-hold behaviour of the M220 firmware
This change corrects the behaviour of the power-hold whilst the firmware
is active. The power-hold is not longer active during firmware execution.
Note
• Corrected negative FEPS operation in M220 firmware
This change configures the M220 such that negative FEPS now works
correctly and enters reprogramming mode using the default CAN
configuration.
Note
• Updated documentation on FEPS programming
The FEPS signal may not be correctly detected if asserted at the same
time as the ECU is powered up. This behaviour was not sufficiently
documented.

Change log
decoding.
• Correction to dereferencing of channel names
The mechanism by which channel names are converted to channel

numbers when building a Simulink model could fail for certain Simulink
blocks, thereby giving the wrong number for a given channel. The affected
blocks are:
pdx_QuadratureDecode
pdx_QuadratureDecodeAndFrequencyInput
pdx_SteppedOutput
pdx_StepperMotorOutput
ppp_Configuration
This has now been corrected.
• Correction to indirect analogue input measurements
Previously, analogue input measurements taken by a separate input

device were being mishandled and would report the wrong value. This has
been corrected.
• Correction to pax_CcOutput block behaviour
Previously, a scaling mismatch in the pax_CcOutput block meant that the

output would not allow any current draw. This issue has been corrected.
• Correction to initial drive request for indirect/serial output drivers
Previously, the initial drive request for indirect/serial digital and constant
current outputs were ignored and the output driver was turned off.
This incorrect initial state would persist until the first application
request to change the drive request. The pax_cc_output() and
pdx_digital_output() C-API functions, and pax_CcOutput and
pdx_DigitalOutput Sim-API blocks were affected. This issue has been
corrected.
• Correction to parameter checking for the pdx_StepperOutput block
Previously, any model containing a pdx_StepperOutput block might fail to

update or build, issuing an error about invalid stepping range. The block
now correctly determines the stepping range and does not issue an invalid
error.
• Correction to reading frequency, period, quadrature and TLE4953

inputs on G400, G800 and G850 ECUs

Change log
Previously, period input measurements would incorrectly state the low-

time of the signal. This has been corrected.
Previously, frequency, period, quadrature and TLE4953 input

measurement would incorrectly determine when a signal had timed out.
This has been improved.
• The timeout flag of PWM inputs was sporadically toggling between

0 and 1 for signals that were supposed to cause a timeout
If a signal was supplied to a PWM input function or block that had a

frequency equal or slightly higher than the time-out frequency set for that
function/block. The timeout output of that function/block was sporadically
toggling between 0 and 1 and was never settling to 1. This change fixes
this issue and causes the timeout output to always be set to 1 for signals
of frequencies less than the time-out limit.
• Correction to the M461 technical specification for accelerometer

output voltage equation
• Correction to the G850 technical specification for H-bridge details
• Correction to I/O behaviour for some applications
Previously, some I/O operations could become intermittent or incorrect

due to overlapping memory assignment during initialisation. For example,
pin A45 when configured as a PWM output on the M250, might exhibit
intermittent behaviour for some applications, generating a PWM for up to
2 seconds then turning off for 2 seconds.
• Correction to crank synchronous A/D samples target and added

missing general purpose digital outputs, both for the G850
Previously, the crank synchronous A/D samples for cylinder 1 would be

clamped to zero volts incorrectly.
Previously, none of the general purpose digital outputs were able to be

driven.
• Updated technical specifications to describe output driver current

leaks
Some output drivers have feedback signals which the processor monitors.
These feedback signals are connected to ground through a load, causing
a small current draw through the actuator, enough to dimly light a LED.
• Corrected documentation relating to the M250 high-side switch

control

Change log
Previously, the documentation indicated the high-side switch is controlled

through the digital output block. It is in fact controlled by the
pss_OutputControl Sim-API block and pss_set_safety_switch() C-
API function.
• Corrected documentation of the pdxf_invert parameter in the

pdx_pwm_input() function
Previously, the documentation stated the PWM input signal measurement

starts on the falling edge when pdxf_invert is set to 0, and on the rising
edge when pdxf_invert is set to 1. In fact, the actual logic is reversed.
Installation

before OpenECU.
• Applied minor updates to the installer look and feel
• Robustness improvements to PFS (non-volatile flash filesystem)

feature
Firstly, the performance of PFS has been improved in applications in

which a large number of files are stored (currently only C-API applications
are able to create large numbers of files). Previously the periodic file
management process became unacceptably slow if the number of files
was large (e.g. 50 or more).
Secondly, some scenarios in which flash data might have been accessed
illegally while a flash program operation was in progress have been
avoided. In any case, no such illegal access was ever observed or
provoked in real applications.
Thirdly, the background file management process has been made more
robust against the filesystem becoming "locked" in certain scenarios, e.g.
repeated fast power cycling resulting in large numbers of part-written files
in flash. If necessary, old files are now deleted automatically until the
system is able to resume normal management operations. Also, greater
priority is now given to managing existing files, so that the process is not
unduly delayed by application-requested file writes, reducing the scope to
become "locked" in the first place (in applications making very frequent
write requests).
• Avoiding processor exceptions if NULL dereferenced in customer

application during flash erase

Change log
Previously, if a customer C-API application inadvertently read data via the

NULL pointer (address 0), or made some other access to addresses below
0x40000, no immediate effect would be seen. However, if the PFS feature
happened to be performing a background flash erase operation, this same
access would cause a processor exception resulting in a reset, leaving
the erase incomplete.
If the C-API application made such accesses continually, each time the
ECU then restarted, PFS would again attempt to erase the flash block
required and again a reset would occur when the application read through
NULL. This led to a cycle of resets until the multiple reset detection feature
of the boot loader prevented further application execution, leaving the
ECU in reprogramming mode. Once in reprogramming mode however,
the PFS feature would succeed in completing the erase correctly, so the
ECU would run normally if the power was cycled.
As the scenario above would become apparent only after PFS had cycled
through enough data to need to erase a block, there was a risk that an
otherwise well-validated application could fail only a long time after it has
been put into service, depending on NVM throughput in that application.
This would make for a serious yet difficult to detect or reproduce bug.
To avoid that situation, the processor exceptions generated if the

application accesses low memory during a flash operation are now
tolerated, if such an operation is in progress, and no longer result in a
reset. While the data returned from such an access is now unpredictable,
it would already have been true that reading through NULL would give
unexpected data at the application level, and so returning unexpected data
is considered less serious than the unexpected reset scenario above.
However, it is still possible for a bad access to cause an exception which

will continue to occur until the flash operation has completed. If it does,
a continuous loop is effectively entered until the flash operation is over.
If that operation is an erase, it may take long enough for a watchdog
exception to take place. Therefore CR 8211 (F) remains open for further
action in future to address this scenario. Note however that this type
of exception pattern occurs only very rarely even if NULL is repeatedly
read during flash operations, so it is now very much less probable that a
customer application will cause a reset in the manner described above.
Target ECU

• PDTC client task rate changed from 10 ms to 100ms on the X657 to

reduce CPU loading
• External sensor power supply output (pin A25) did not turn on for
M220-00E

Change log
Pin A25 was stuck for M220-00E due to circuit depopulations. The issue
has been fixed by changing the settings for the microcontroller output
which controls this pin.
User documentation

and PDF formats.
• Updated pai_AnalogInput documentation for the block output

vector, confirmed_faults, as the vector's element ordering was
incorrrect
• Fixed Simulink block HTML help file links
A number of the Simulink blocks were not correctly linked to there

respective help files. All links to HTML help files restored.
• Corrected documentation error for OBD DTC state values
Previously, a number of user guide diagrams incorrectly detailed the

numeric value of some DTC states. This has now been corrected.
• Updated user guides to explain that the GPI injector dead time
parameter is shared
Updated all references in the documentation for the injector dead_time

for the GPI feature, to explicitly say that it is a parameter that is shared
across all injectors.
• Update M220 tech. spec. to show that M220's have calibration RAM
• Documentation update for pcx_receive() function
Previously, the pcx_receive function could return an undocumented

return value. The documentation shows the correct value that is returned
from the function.
• Updated technical specifications with additional information for

non-volatile memory storage
• Corrected documentation in the Sim-API user guide for the step1

example

Change log
Both documentation and images in the Sim-API user guide had grown out
of date over time compared to the completed step1 example models.
• Corrected documentation in the digital inputs section of the M250

technical specification
• Updates to user guides to document A/D conversion rates
The Sim-API and C-API user guides have been updated to detail the worst
case conversion rate times for all A/D channels on each ECU.
• Various fixes applied to the Sim-API user guide
• User guide improvements required for high-side actuator output

control (M250 and M460)
• Updated M250 technical specification with recent power

consumption data
• Updated documentation to reflect supported versions of Microsoft

Windows
• Updated the M250 technical specification
The M250 technical specification was updated with a correction in the ECU
power input range and additional details on reverse battery voltage. A
section on RTD analogue input filtering has been added.
3.14. Release 1.9.2

Release labelled release-1.9.2 from 1 March 2012. This release is marked as
engineering meaning the release has had minimal testing and is intended to trial new features
for the purposes of feedback. The following table provides quick access to each of the
changes.
Table 3.11. Release summary for v1.9.2

compatible upgrade
C-API 8250 (W) 8967 (W), 8966 (W), 8908 No, see: Yes, see:
(W), 8902 (W), 8151 (W) 8908 (W)
8773 (W), 8746 (W), 8736
(W), 8153 (W),
8151 (W)
Sim-API 8250 (W) 8967 (W), 8908 (W), 8902 Yes Yes, see:
(W), 8794 (W), 8908 (W)

Change log

compatible upgrade
8762 (W), 8746 (W), 8745
(W), 8736 (W),
8243 (W), 8153 (W), 6526
(W)

Target ECU

• Run-time checks on RAM, flash and NVM data added
RAM is now tested continually in the background for bus faults or data
retention errors. If a fault is found, an unrecoverable error is taken as
program execution is otherwise likely to fail unpredictably. This also
applies to external RAM where used for application data (not calibration
shadowing) on certain targets. This is in addition to start-up RAM checks
performed by the boot loader.
Code and calibration areas are tested for corruption at run time if the
Calibration Verification Number (CVN) check is continually triggered by
the application. If corruption is detected, again an unrecoverable error is
raised. Downloading new calibration values via CCP is tolerated however.
This is in addition to start-up time checksumming of the code and
calibration, where used.
Corruption of NVM data on MPC5xxx targets which use the PFS (flash
filesystem) feature is also checked continually. If any file is found to have
become corrupt at run time, it is made unavailable for subsequent read,
so that the client software which would have used that data must instead
invoke its fallback strategy (e.g. using default values), just as if the data
had never been saved. This is in addition to start-up time checks which
determine what data is available.

Calibration

software.
• CANape warnings for string length exceeding 255 characters

Change log
For FUNCTION statements in the ASAP2 file the maximum string length
was being exceeded if the Simulink model hierarchy had a deep nesting
of sub-systems. These comment strings are now limited to 255 characters
(any characters after the limit are removed). The model hierarchy,
represented using ASAP2 FUNCTION statement, is not limited.
• Fix to CCP rates in CANape and INCA ASAP2 files
Previously, the 'RASTER' entries in the CANape and INCA-specific

ASAP2 (.a2l) files emitted did not correspond correctly to the periodic rates
implemented for CCP DAQ. The rates have now been corrected. A 1000
ms rate is also now made available for CANape.
• Correction to the automatic task time ASAP2 entry generation
Previously, the automatic task time ASAP2 entries (such as mpl_tt_xxx

and mpl_mtt_xxx) would be incorrectly generated such that one entry
might reflect the time of a different task.
Now, automatic ASAP2 entries for task times correctly match their
respective tasks.
Code generation

• Updated the pan_SparkConfig block
Previously, when a model contained a pan_SparkConfig block, but not a

pan_EngineConfig block, MATLAB would crash when updating or building
the model.
Communications

ISO-15765 over CAN.
• Allow CCP and ISO diagnostics to work on all buses via calibration
on selected targets
Previously, the CCP settings were always stored in the application

(strategy) area of memory and could not be calibrated. In general this is
preferred because calibrations are more frequently erased and so it is
easy to accidentally erase them by interruption of the flash reprogramming
process. However, selected targets now support the storage of CCP
settings as calibrations such that they can be changed.
Supporting CCP and ISO diagnostics on the second CAN bus of the X657
target also required a fix. Previously, CAN only operated on that bus if
traffic was also present on one of the other two buses. Now it works
correctly in isolation.

Change log
Note
to revision 1.9.2 or later. To upgrade the ECU's firmware please
contact OpenECU technical support as described in Appendix A,
Contact information.
• Blocks pcx_CANdb_TransmitMessage and

pcx_CANTransmitMessage do not report errors correctly
Simulink blocks pcx_CANdb_TransmitMessage and

pcx_CANTransmitMessage should output an error_flag value of 0 for no
error (sent OK) and 1 for error (could not send). However they actually
reported 0 for error and 1 for no error.
• Inclusion of support files for the pj1939_InhibitReprogramming

block
• Negative responses to incorrectly formatted J1979 messages
On certain J1979 ISO 15765-4 services, the ECU was generating

a negative response to incorrectly formatted request messages in
contradiction to the standard. No response is preferred in this situation.
This issue affected services $02 and $09 when the message length of the
request was incorrect. This behaviour has now been corrected.
• Added string length protection when setting infotype data
CR 8151 (W), affects C-API
The C-API function pdg_set_infotype() now takes an additional

argument to indicate the length of the data string being passed. Note that
this length must match the correct length for that InfoType as specified in
Appendix G of J1979 SEP2010.
decoding.
• Avoid perturbation of TPU channel 0 when synchronised PWM

running
Previously, running a synchronised PWM (injector) output on MPC5xxx

targets could disrupt an unrelated PWM input on TPU channel 0, causing

Change log
it to miss edges and so report an erroneously low frequency. This is now

fixed.
• Add fixed-frequency PWM support for X221 digital outputs
X221 support for fixed-frequency PWM on digital outputs was missed

previously. This has now been added.
• C-API function pfs_is_newer() returned TRUE if the revision

number for an NVM file is identical to the one being compared with
(e.g. the revision it was at before a write was attempted), instead of
FALSE
This issue did not have any effect on current Simulink applications. It
did not affect the writing of data to NVM or its retrieval in a Simulink
application. However, it could have affected user C-API applications using
this function. It is now resolved.
Target ECU

• Option added to disable background memory checks
A new C-API statement is now available which can be used to disable

the normal background memory checks which take place on MPC5xxx
targets. This should usually be omitted.
• Current monitor channel for X657 pin A30 fixed
Previously the wrong A/D channel was selected for this function,
corresponding to the pin B30 voltage monitor.
3.15. Release 1.9.1

Release labelled release-1.9.1 from 19 December 2011. This release is marked as
production meaning the release has had a subset of testing and is intended to support a
specific customer production release. The following table provides quick access to each of
the changes.

compatible upgrade
C-API 8555 (W), 8519 (W), 8518 8763 (W), 8693 (W), 8691 No, see: Yes, see:
(W), 8517 (W), (W), 8681 (W), 8532 (W), 8566 (W),

Change log

compatible upgrade
8403 (W), 8402 (W), 8351 8619 (W), 8616 (W), 8600 8484 (W), 8555 (W),
(W), 8308 (W), (W), 8590 (W), 8099 (W), 7530 (W),
8243 (W), 8099 (W), 7899 8579 (W), 8567 (W), 8566 7899 (W), 6048 (W)
(W), 7808 (W), (W), 8542 (W), 7808 (W)
7229 (W), 7229 (W), 7229 8532 (W), 8520 (W), 8503
(W), 7228 (W), (W), 8484 (W),
6679 (W) 8398 (W), 8372 (W), 8335
(W), 8333 (W),
8292 (W), 8262 (W), 8231
(W), 8208 (W),
8155 (W), 8020 (W), 7530
(W), 7263 (W),
6048 (W), 5676 (W)
Sim-API 8519 (W), 8518 (W), 8517 8763 (W), 8757 (W), 8734 No, see: Yes, see:
(W), 8408 (W), (W), 8697 (W), 8532 (W), 6048 (W)
8403 (W), 8402 (W), 8383 8693 (W), 8691 (W), 8681 8484 (W),
(W), 8308 (W), (W), 8640 (W), 8099 (W),
8243 (W), 8099 (W), 7899 8619 (W), 8617 (W), 8616 7808 (W),
(W), 7808 (W), (W), 8590 (W), 7047 (W)
7576 (W), 7231 (W), 7229 8579 (W), 8567 (W), 8542
(W), 7229 (W), (W), 8532 (W),
7229 (W), 7228 (W), 6679 8529 (W), 8520 (W), 8503
(W) (W), 8484 (W),
8398 (W), 8372 (W), 8335
(W), 8333 (W),
8292 (W), 8262 (W), 8231
(W), 8230 (W),
8208 (W), 8155 (W), 8115
(W), 8020 (W),
7263 (W), 7047 (W), 6048
(W), 5676 (W)


developer software.
• Support for external serial (SPI) flash memory chip (Numoynix

M25P16)
Two functions are provided to allow reading and writing data (in multiples
of 2 bytes) to/from the serial flash chip. A further two functions allow an
individual flash sector or the whole device to be erased. The raw device
status and overall busy status may also be read when required.
The device may or may not be fitted to an ECU so during initialisation the
presence of the device is determined by looking for specific device details.

Change log
These device details may be accessed by the client by the appropriate

function call.
The flash memory may be read using CCP to allow stored data to be
extracted. As the device is a serial device connected on the SPI bus, a
virtual address is used with CCP accesses, such that the device appears
to be a memory mapped device in the processor's address space.
FreeCCP timeouts for short upload and upload commands have been
increased to 1 second. This has been necessary to support reliable CCP
reading of flash data.
Communications

ISO-15765 over CAN.
• Addition of J1939 inhibit reprogramming functionality
Previously the application could not inhibit the J1939 reprogramming

feature from transferring control to the bootloader. Now
the application can inhibit the transfer to bootloader using
the pj1939_inhibit_reprogramming() C-API function or the
pj1939_InhibitReprogramming Simulink block.
• Support for ReadMemoryByAddress (UDS/KW2000-3 service $23)

added
Service $23 is now supported in both the main application and boot loader
builds. It can be used to upload areas of ECU internal memory, including
(where fitted) the PEF feature external flash.
C-API options are provided to allow or disallow support for this service
depending on the type of diagnostic session in progress and whether
seed and key SecurityAccess ($27) authentication has been passed.
The default behaviour is to disallow access, so existing projects will
not have memory contents made available to external diagnostic tools
unexpectedly.
Note
• Allow global override of priority for J1939 multi-frame diagnostic

messages

Change log
In Simulink an option has been added to the pj1939_Configuration block

to allow J1939 diagnostic messages (DMs) to use a single global priority
whenever the message response length exceeds 8 bytes (so that a multi-
frame response is required). A message response of 8 bytes or less
continues to take its priority from the inport of the relevant DM transmit
block. This option is turned off by default, in which case the message
response takes its priority from the DM transmit block inport regardless
of length.
Note that this global multi-frame priority option does not affect the
pj1939_PgTransmit block, for which the message length is fixed for a
given block instance, and which always uses the inport priority.
For C-API an optional multiframe-priority assignment statement is

supported within the j1939-messaging compound statement in the capi
file to allow a single global priority to be set for all diagnostic message
(DM) transmissions whose lengths exceed 8 bytes (that therefore require
a multi-frame response). When a multiframe-priority statement is
present, the priority values passed to the relevant C-API DM transmit
functions are ignored for all such messages in favour of the global priority
value so defined. The priority values passed to these functions are still
used for messages of 8 bytes or less that require only a single frame to
transmit.
When the multiframe-priority assignment is omitted from the

j1939-messaging compound statement, the priority used for all DM
messages is that passed to the relevant C-API DM transmit function
regardless of the message length.
Note that this global multi-frame priority option does not affect the
pj1939_pg_transmit() C-API function, for which the message
length is passed as a function argument, and which always uses the
corresponding priority passed in the function call.
• Allow application to erase all DTCs, even permanent and non-

erasable
In cases where OBD legislation do not apply, for example during

manufacturing, the customer may wish to erase all DTCs unconditionally
and clear the ECU back to its initial state. This has been added as an
option to the block/function which clears DTCs according to specified filter
criteria.
Note that the penalties for erasing CARB permanent or EURO non-
erasable DTCs during normal operation without complying with any
relevant legislation may be severe. The customer is responsible for adding
suitable checks to the application to ensure that unconditional erasing
of DTCs will only take place under suitable conditions as permitted by
legislation.
• Provide options to override the standard response to certain

ISO-15764 J1979 services
In certain circumstances only, the customer may wish to override the

standard response to the J1979 service requests $03, $07 and $0A. This

Change log
facility is provided as set of options in the piso_Configuration Simulink

block and C-API iso-diagnostics compound statement. The effect of
enabling and selecting these options is to transmit extra DTC information
that would otherwise not be present in a standard J1979 response. The
user may also manipulate the override options at runtime, via calibration
variables.
Note that the use of these overrides will cause the message contents to
deviate from the specified J1979 standards and may result in unexpected
bahaviour from a connected test tool.
• Add Simulink support for J1939 messages DM32 and DM34
Simulink support for J1939-73 messages DM32 and DM34 has been
added.
• Added support for DM24 data stream
Previously DM24 only reported Expanded Freeze Frame SPNs; and

for these it always reported that Data Streams were not supported.
Functionality has now been added to correctly report SPNs associated
with Data Streams.
• Added support for DM24 scaled test results
Previously DM24 only reported Expanded Freeze Frame SPNs; and for
these it always reported that Scaled Test Results were not supported.
Functionality has now been added to correctly report SPNs associated
with Scaled Test Results.
• Simulink blockset addition to support J1939 expanded freeze

frames
A DM25 freeze frame block has been added. The list of SPN(s) to be
recorded by a DM25 freeze frame is entered as a calibratable vector, as
such the list of SPN(s) is calibratable.
Note unlike other freeze frames only a single DM25 freeze frame can exist
within a given model.
• Support for CARB permanent DTC behaviour
The platform now supports CARB permanent DTC behaviour, specifically

the conditions for clearing permanent DTCs.
In Simulink, the pdtc_DiagnosticTroubleCodeExt block now has a

checkbox that allows one to specify whether a 'permanent' DTC should be
cleared on OBD request only when certain operating conditions are met,
as defined by CARB regulations. The pdtc_Control block has a new inport
to allow the application to signal whether or not these conditions are met.

Change log
In C-API, the dtc compound statement has a new assignment statement

use-conditions-to-clear-perm that allows one to specify whether
a 'permanent' DTC should be cleared on OBD request only when
certain operating conditions are met, as defined by CARB regulations.
A new C-API function pdtc_plat_obd_update_clr_perm_ok allows
the application to signal whether or not these conditions are met.
• Add Simulink support for J1939 messages DM35, DM36, DM37,

DM38, DM39 and DM40
Simulink blocks have been added to support J1939 messages DM35,

DM36, DM37, DM38, DM39 and DM40.
• Change to DM37 transmit function
The prototype to the C-API function pj1939_dm37_transmit() has

changed to allow the application to force transmission in addition to the
automatic transmissions that occur every 10 seconds or when the data
change. See C-API User Guide for more details.
• Updated interfaces to the calibration verification number (CVN) for

both Simulink and C-API
The Simulink block has 2 additional outports. One outport indicates the
availability of the CVN, while the other outport indicates if the CVN is
currently being calculated.
The C-API interface has been decomposed into 2 separate functions. One
function simply initiates the CVN calculation. While the other function is
used to poll the result of the CVN calculation.
• Add Simulink support for J1939 messages DM7, DM8, DM10 and
DM30
Simulink support for J1939-73 messages DM7, DM8, DM10 and DM30
has been added.
• Simulink blockset additions to support J1939 DM messages DM4,

DM24 and DM25
A DM4 transmit block has been added.
• Add support for J1939 DM4

Change log
Support for J1939 DM4 (freeze frames) has been added. This CR relates
just to packing and unpacking the messages. The underlying structures
to store and maintain freeze frames is be addressed under CR7228.
Partial support for J1939 DM24 has been added. This allows the
identification of the DM25 expanded freeze frame SPNs. See CRs 8402
and 8403 for support for Scaled Test Results and Data Stream. This CR
relates just to packing and unpacking the messages.
Support for J1939 DM25 (expanded freeze frames) has been added. This
CR relates just to packing and unpacking the messages. The underlying
structures to store and maintain freeze frames is be addressed under
CR7228.
• Addition of freeze frames to J1939 diagnostics
Freeze frames are now captured when a J1939 DTC becomes

active or pending after previously being clear or inactive. This is as
required by California Code of Regulations On-Board Diagnostic System
Requirements. In addition, the freeze frames are cleared when the
corresponding DTCs are cleared. See user guide for more details.
decoding.
• Peak-Hold injector driver support for reading the commanded output

state on U82
This new feature introduces two new digital inputs that read the
commanded state of the peak/hold outputs.
Target ECU

• Added support for X221-000 target ECU
Support for the X221-000 target ECU has been added for the C
and Simulink interfaces. As with all targets, select the ECU through
the put_Identification block, save, close and reopen the model before
selecting any I/O channels.

Change log


developer software.
• Correction to the configuration of the serialised digital inputs
An incorrect configuration of the serialised digital inputs resulted in several

signals not being read on the A450, M001, M250, M460 and M461 target
ECUs. The affected signals were predominantly current trip indicators.
• Only clear DTE test value/max/min on reset, and not when test has
not been run this step
Previously, DTE test value/max/min were cleared whenever the "test

complete" input was false. This has now been replaced with two separate
inputs for "test complete" and "reset". If neither input is set, the test value/
max/min hold their current state.
• Fixed PWM output behaviour at very low frequencies
Previously some PWM output channels could get stuck in the fully driven
state when changing from low to high duty cycles within the 0.5Hz to
1.05Hz frequency range.
Calibration

software.
• ASAP2 identifier prefixed with a number not dealt with correctly
Fix to script that generates the ASAP2 file so that Simulink subsystems
that begin with a number are modified with an underscore to conform to
the ASAP2 standard.
• Updated to allow old style map names in ASAP2 files
Release 1.9.0 introduced a minor change to map names in the ASAP2

files. This resulted in not being able to use old cal files from release 1.8.6

Change log
with 1.9.0. A new option has been added to allow ASAP2 file generation
to use the old or new map names. This can be accessed in the Simulink
model through the menu option, Tools|Real-Time workshop|Options|
OpenECU ASAP2 generation by ticking "Generate old style ASAP2 map
names".
Code generation

• Changed Sim-API model builds to use the C-API tool to generate

glue code and ASAP2 files
A continuation of the work to complete CR 7047 (W).
Communications

ISO-15765 over CAN.
• Correction to handling CANdb files containing negative integers and

numerical literals larger than 32-bits of integer
This issue affected the CANdb blocks pcx_CANdb_ReceiveMessage and

pcx_CANdb_TransmitMessage.
• Correction to the latency between J1939 BAM data frames
Previously the J1939 stack did not conform to the specified latency of 50
to 200 ms between successive data frames of a BAM message.
• Correction to queuing multiple J1939 transport messages to the

same destination address
Previously, the J1939 stack did not allow the application to queue multiple
transport messages with the same destination address (including the
global address). This has now been corrected and provided there are free
buffers available, multiple transport messages with the same destination
address will be queued.
• Enabled the pj1939_Dm16Transmit block to work with R2008b,

R2009a and R2010a
Previously, if a model containing the pj1939_Dm16Transmit block was

built using R2006 or R2007 then the build would complete successfully,
but not when built using other versions of Simulink.
• UDS-based flash reprogramming

Change log
UDS-based flash reprogramming is now supported. Please contact Pi

Innovo for further details.
Note
• Correction to user guide documentation for CCP security
Previously, various links in the C-API and Sim-API user guides did not
work. These have now been corrected.
• Correction to buffer overflow and ECU reset when the number of

SPNs for DM24 transmission exceeds 255
Requesting transmission of a DM24 message when the number of scaled

test results and data stream SPNs exceeded 255 caused the ECU to reset
with an access exception. This has been corrected such that the DM24
message can deal with more than 255 SPNs.
• Timestamps on DM1 and DM2 decode blocks
When DM1 (or DM2) decode blocks were configured to look for different
DTCs from the same source address, the timestamp information was only
updated for one of those blocks: the timestamps of the other blocks just
read zero. This has now been rectified.
• Default value for DM10 bit position now available for DTEs
In the Simulink block ppr_DiagnosticTestEntity, if the DTE is of J1939 type

and the test identifier (TID) is in the range 1-64, the block will automatically
fill in the value for the DM10 bitmap position (to match the TID) when that
field is left blank. The mechanism to do this had been provided, but was
not working. This has now been rectified.
• CVN calculation not iterating over all memory blocks
As part of the CVN calculation a CRC is calculated for each of the following
memory regions:

Change log
Calibration header
Calibration data
Application ISRs
Application exceptions
Application header
Application code
Where the memory region size exceeded 65535 bytes the CRC was only
partially done on the memory region. In such an instance the reported CVN
would not reflect alterations to certain parts of memory. This was due to
the memory region size being inadvertently interpreted as a 16 bit value.
To fix this issue the memory region size is now treated as a 32 bit value.
• Byte ordering for non-alphanumerics in DM transmits is wrong
Corrected the byte ordering for non-alphanumeric data transmitted over

DMs to transmit LSB first. The DMs affected are DM20, DM21, DM30,
DM32, DM33, DM36, DM37, DM39 and DM40.
• DTE test results being written to NVM too often
Changes to the DTE handling functionality caused it to schedule writes to

NVM of test results unconditionally. This has now been changed so that
writes are only scheduled when a test has run or the DTE test values are
being reset.
• Output count from Simulink pdtc_DiagnosticTroubleCodeExt block
The Simulink pdtc_DiagnosticTroubleCodeExt block always reported zero

on the count output, regardless of the number of times the DTC had been
set Active. This has been fixed, so that the count output now reports this
value correctly to the application. Note that this never affected the value
reported over J1939 on DM1 and other DTC reporting messages, which
was always correct.
• DM7, 8, 30 failure(s)
The correct PGN is now reported in the NACK for DM7. The test
values are no longer incorrectly limited to U8. Split requirement
[LLR.PLAT.J1939.73.DM7-RX.002] into two separate requirements and
reworded.
• DM4 data failures: fix to data byte ordering
Previously the SPN data was transmitted via DM4 and DM25 most-
significant byte first. A change has been made to match the J1939-71
standard, such that alphanumeric SPN data is still transmitted most-
significant byte first, but all other SPN data is transmitted least-significant
byte first.

Change log
To achieve this a new mechanism of specifying whether SPN data is

alphanumeric or not has been added. See the user guides for details.
• Incorrect decode of received J1939 DM1 and DM2 messages

containing multiple DTCs
This fixes a problem whereby decoding of incoming DM1/DM2 messages

would not result in an indication for each of the DTCs present in the
message.
• Incorrect J1939 DM32 message contents
This fixes a problem whereby the SPN and FMI information, in a J1939
DM32 message response, was being placed in the wrong bit positions.
• Software fingerprint PID with different read and write IDs supported
on X657
The HIS UDS flash reprogramming document specifies that the software
fingerprint PID is written via one ID and read via another (0xF15A and
0xF15B respectively). For X657 only, a write request to 0xF15A is now
internally remapped so that it writes to 0xF15B, and similarly with the
KW2000-3 LIDs 0x5A and 0x5B.
Note
• Updated to allow the user to define the name of the DM25 calibration
Previously the vector calibration that defined the contents of the J1939
DM25 freeze frame had to be called stpv_dm25_spn_set. This has now
been changed so that the user must now define it's name.
• DMs 20, 21, 29, 30, 31, 32, 33, 34 and 35 are now sent to a specified
destination address
Previously, DMs 20, 21, 29, 30, 31, 32, 33, 34 and 35 were being
broadcast globally. This has now been corrected.
In Simulink, an extra inport to specify the destination

address has been added to blocks pj1939_Dm20Transmit,
pj1939_Dm21Transmit, pj1939_Dm29Transmit, pj1939_Dm30Transmit,
pj1939_Dm31Transmit, pj1939_Dm32Transmit, pj1939_Dm34Transmit
and pj1939_Dm35Transmit. In addition, extra outports have been added

Change log
to the pj1939_Dm7Decode block for passing the destination and source

addresses of the received DM7 messages to the application.
In C-API, an extra argument to specify

the destination address has been added to
functions pj1939_dm20_transmit(), pj1939_dm21_transmit(),
pj1939_dm29_transmit(), pj1939_dm30_transmit(),
pj1939_dm31_transmit(), pj1939_dm32_transmit(),
pj1939_dm33_transmit(), pj1939_dm34_transmit() and
pj1939_dm35_transmit(). Also the structure passed to the function
pj1939_get_dm7_commanded_test has changed: the new structure
also contains source and destination address data from the received DM7
request. See the C-API user guide for more details.
• Change to remove old freeze frame files at start up
Extra functionality has been added to the PFF feature to undertake some
file checking at start up. This includes checks that no freeze frame files
exist outside the expected range for the current application. Any such
freeze frame files found are deleted. This means that NVM is not wasted
on old freeze frames from a previous application build, which will not be
accessed by the current application.
• Fixed freeze frame recovery functionality after undetected storage

corruption
A correction was made to the way the system handles DTCs and freeze
frames going out of sync as a result of undetected corruption / failure to
store data in NVM. At startup freeze frames are checked against DTCs to
check for discrepancies. This may result in unwanted freeze frames being
deleted. A change to this functionality was made to correct an issue that in
extremely rare cases might result in access to all freeze frames being lost.
• DTC state changing as a result of engine running timer may not

request NV storage
DTC states are changed correctly (ageing to Previously Active and Clear)
based on the engine running time. However under some situations, the
platform did not register that an NV write is required to update the non-
volatile copy of the states. This affected the output of the pdtc_Memory
block in Simulink and the pdtc_dtcs_modified() function in C. This
issue has now been fixed.
• Change to allow single parameter freeze frames
Defining freeze frames with a single data element to capture (PID/SPN)

previously generated a build error. A fix has been applied to the CAPI tool
to correct this. Single parameter freeze frames are now allowed.
• Response pending for CVN not handled correctly

Change log
A J1979 response pending mechanism has been added.
J1979 service $09 InfoType $06 CVN now gives the correct response
pending $78 NRC behaviour if a request is received before the CVN
calculation is complete
• Corrected response to J1979 $02 request for PID $00 for non-
existent freeze frame
Previously if a J1979 service $02 request for PID $00 was received for
a freeze frame that had not been stored, the ECU ignored the request.
The code has now been corrected to match the J1979 SEP2010 standard,
which indicates that the ECU should respond with data showing that just
PID $02 is supported.
• Updated to only capture J1979 $02 freeze frames for emissions

related DTCs
Previously, when any DTC was activated with an associated freeze frame,
a freeze frame would be captured. Data for this freeze frame would then be
available on J1979 $02. Service $02 should only report emissions related
DTCs. So a change has been made to only capture freeze frames for
emissions DTCs.
• Correctly allow reset of relevant diagnostic data on OBD clear

request
Previously, some stored diagnostic data was not cleared on an OBD

clear request, and no provision was made for this to be cleared by
the customer's application. OBD clear requests now clear all relevant
DTC data as required, and an additional interface is provided to allow
continuous and on-demand test results to be reset.
• Enhancements to C-API function and Simulink blocks which

determine the existence of DTCs that match supplied criteria
Enhancements have been made as follows:
• The user now has an option to use a greater-than-or-equal-to

comparison for the emissions severity of DTCs to match against.
• An output providing a count of the number of matching DTCs has been

added.


Change log
• Corrected incorrect baud rate setting in firmware
This change corrects an issue where the baud rate in the bootloader was
always set to 500kbaud, irrespective of the configured application or the
default baud rate.
Note
decoding.
• Correction to frequency range selection for U82 targets
Frequency range selection for U82 C-sample pins A16, A17, A45 and A46
would not work correctly. This has been corrected.
Target ECU

• X657 overlapping RAM warnings addressed
Previously, warnings about prg_data_ram and data_ram definitions

overlapping were emitted by the linker during application builds on the
X657 target. Those warnings have now been fixed.
• Additional outport for block ppr_DiagnosticMonitorEntity
When a Diagnostic Monitor Entity (DME) has run a sufficient number of

times such that it is ready for a diagnostic decision, the platform sets the
DME status accordingly. However, this was not previously available to
the user. This change adds an outport to the ppr_DiagnosticMonitorEntity
block to indicate the readiness status of the DME.
3.16. Release 1.9.0

Release labelled release-1.9.0 from 2 September 2011. This release is marked as
customer meaning the release has had a subset of testing and is intended to trial new features
and/or changes for the purposes of feedback. The following table provides quick access to
each of the changes.

Change log

compatible upgrade
(W), 8088 (W), (W), 8245 (W), 8118 (W), 8310 (W),
7902 (W), 7899 (W), 7810 8242 (W), 8239 (W), 8228 8088 (W), 8293 (W),
(W), 7808 (W), (W), 8224 (W), 7805 (W), 8212 (W),
7808 (W), 7804 (VI), 7721 8224 (W), 8212 (W), 8199 7594 (W), 8212 (W),
(W), 7648 (W), (W), 8195 (W), 7562 (W), 8199 (W),
7642 (W), 7594 (W), 7562 8180 (W), 8117 (W), 7961 6952 (W), 7721 (W),
(W), 7392 (W), (W), 7869 (W), 6874 (W), 7631 (W),
7281 (W), 7279 (W), 7267 7805 (W), 7800 (W), 7718 6658 (W), 7619 (W),
(W), 7212 (W), (W), 7652 (W), 6545 (W), 7495 (W),
7006 (W), 7001 (W), 6952 7633 (W), 7631 (W), 7619 5848 (W), 6952 (W),
(W), 6952 (W), (W), 7501 (W), 5847 (W), 6952 (W),
6930 (W), 6928 (W), 6874 7495 (W), 7411 (W), 7387 5846 (W) 6729 (W),
(W), 6729 (W), (W), 7384 (W), 6698 (W),
6698 (W), 6696 (W), 6635 7308 (W), 7289 (W), 7288 6547 (W),
(W), 6633 (W), (W), 7272 (W), 6377 (W),
6584 (W), 6547 (W), 6545 7228 (W), 7228 (W), 7228 5889 (W)
(W), 6545 (W), (W), 7228 (W),
6467 (W), 6377 (W), 6350 7173 (W), 7103 (W), 7078
(W), 6289 (W), (W), 7066 (W),
6134 (W), 5889 (W), 5879 7047 (W), 7047 (W), 7025
(W), 5850 (W), (W), 6982 (W),
5849 (W), 5848 (W), 5847 6927 (W), 6874 (W), 6874
(W), 5846 (W), (W), 6658 (W),
5845 (W), 5844 (W), 5381 6522 (W), 6122 (W), 5851
(W), 5148 (W), (W), 5851 (W),
4922 (W), 4228 (W) 5851 (W), 5851 (W), 5851
(W), 5851 (W),
5851 (W), 5851 (W), 5851
(W), 4266 (W),
2940 (W), 2692 (W)
(W), 8088 (W), (W), 8249 (W), 8118 (W), 8310 (W),
7808 (W), 7808 (W), 7804 8245 (W), 8242 (W), 8239 8088 (W), 8293 (W),
(VI), 7764 (W), (W), 8228 (W), 7805 (W), 8212 (W),
7721 (W), 7698 (W), 7642 8224 (W), 8224 (W), 8212 7594 (W), 8212 (W),
(W), 7594 (W), (W), 8199 (W), 7562 (W), 8199 (W),
7581 (W), 7562 (W), 7392 8195 (W), 8180 (W), 8117 7047 (W), 7721 (W),
(W), 7281 (W), (W), 7961 (W), 6965 (W), 7631 (W),
7267 (W), 7231 (W), 7204 7869 (W), 7805 (W), 7800 6952 (W), 7619 (W),
(W), 7197 (W), (W), 7652 (W), 6874 (W), 7495 (W),
7047 (W), 7006 (W), 7001 7633 (W), 7631 (W), 7619 6658 (W), 6965 (W),
(W), 6952 (W), (W), 7528 (W), 5848 (W), 6952 (W),
6952 (W), 6874 (W), 6729 7501 (W), 7495 (W), 7411 5847 (W), 6952 (W),
(W), 6635 (W), (W), 7387 (W), 5846 (W), 6729 (W),
6633 (W), 6584 (W), 6547 7384 (W), 7308 (W), 7289 4981 (W) 6547 (W),
(W), 6545 (W), (W), 7288 (W), 6377 (W),
6467 (W), 6377 (W), 6350 7272 (W), 7228 (W), 7228 5889 (W)
(W), 5889 (W), (W), 7228 (W),
5889 (W), 5850 (W), 5849 7228 (W), 7173 (W), 7155
(W), 5848 (W), (W), 7103 (W),
5847 (W), 5846 (W), 5845 7078 (W), 7066 (W), 7047
(W), 5844 (W), (W), 7047 (W),

Change log

compatible upgrade
5381 (W), 4981 (W), 4922 7047 (W), 6982 (W), 6965
(W) (W), 6965 (W),
6874 (W), 6874 (W), 6658
(W), 6542 (W),
6374 (W), 5851 (W), 5851
(W), 5851 (W),
5851 (W), 5851 (W), 5851
(W), 5851 (W),
5851 (W), 5851 (W), 4951
(W), 4266 (W),
2940 (W), 2826 (W), 2692
(W)


developer software.
• Extended memory map for greater calibration and RAM

consumption on X657
Previously, the memory layout on X657 was adequate for the current
software and enabled run-time calibration and execution on "production"
units with only 256 KB of external SRAM. However, new customer
software became too large to work with that layout.
Following this change, run-time calibration is possible only on "developer"

units with the larger 1 MB SRAM chip. "Production" unit calibrations
are accessed directly from flash memory and can only be altered by
reprogramming.
• Added the ability to assign an SPN identifier to a PID
Support for J1939 SPNs has been added to the diagnostic feature. This
allows an application to define a PID with a specific SPN, which then
allows it to be specified for capture in a freeze frame.
• Non-volatile PID/SPNs added
Data items identified by a KW2000-3 LocalIdentifier, UDS (16-bit) identifier

or J1939 SPN can now be given nonvolatile storage.
These so-called NV-PIDs are suitable for storing dates, serial numbers
and configuration parameters that must be set post-production using a
diagnostic tool.

Change log
New values may be set both in application running mode and in

reprogramming mode. However, new values that were set in the boot
loader will be discarded by the application if their identities are not
recognised or their sizes are outside defined limits. Setting during
reprogramming mode supports flash reprogramming procedures run via
diagnostic tools.
Note
• New types of PID supported, plus diagnostic callbacks introduced
Support for J1979 8-bit PIDs and Keyword 2000-3 8-bit LocalIdentifiers
have been added to the diagnostic feature. InputOutputControl is also
handled for applicable PIDs via either their KW2000 8-bit IDs or the
previous 16-bit CommonIDs which are also used by UDS.
InputOutputControl (override) of PIDs may now set a different number of

bytes to the normal output size of the PID, and there is a new C-API option
controlling whether the override data is automatically emitted when the
PID value is requested by an external tool if IOControl is in progress.
Callback routines can now be optionally invoked for diagnostics. This

gives the application the opportunity to override the response that the
platform would normally have made to some request. It also allows for
PID values to be computed or fetched dynamically at the time they are
requested (e.g. retrieved from non-volatile memory).
• Support for variants
The API now requires the application to define the hardware part number
(identifying which variant of the generic target is being used), the option
(where applicable, 000 by default), and the issue number. This allows one
to support in software different hardware variants and issues under the
same generic target name.
For C-API:
The path to the target required when building an application, and also the
flags to be passed to the compiler to identify the ECU for which the code is
being built, have changed. New options have been added to the C-API tool
to enable the correct path and flags to be automatically generated from the
C-API interface file within the batch file used to build the application. The
C-API examples have been updated to use this mechanism and should
be used as a template.
For Simulink:
When opening a model for the first time after this release, please observe
the following procedure to ensure that channel settings are not defaulted.

Change log
Firstly open the model in Matlab; then close it again without saving it, while
keeping Matlab open. Then open the model a second time. Check that
the channels in your model have not been defaulted (i.e. all set to the first
element of the list of available channels). Now select the correct hardware
part number for your target, if the correct one is not already shown, and fill
in the correct issue number. Only once you are satisfied that the channel
settings are all unaffected should you save the model.
The reason for this procedure is as follows. The available channels are
a function of the target type. If the target type cannot be resolved or has
changed, then the set of available channels will be changed and default
values will replace those that are no longer available. To prevent this from
happening, some bridging code converts the old target information into
the new format. However, to do this it has to locate the put_Identification
block within the model, and this operation alone (via a Matlab command)
causes the channel information to be reset. Hence the need not to save
the model on this first visit. The bridging code caches the location of the
put_Identification block within the model, so that when the model is loaded
for a second time, there is no need to locate the block. The bridging
code can now update the target information without the loss of channel
information.
• Removal of support for R12, R13 and R14 versions of MATLAB
The minimum supported version of MATLAB is now R2006b, following the

removal of support for the older R12, R13 and R14 versions.
• Added interface to read the ECU's registry or manufacturing data
Newer ECUs have registry data programmed when the ECU is

manufactured. The C-API preg_retrieve_key() function and Sim-
API preg_RetrieveKey block provide access to this data.
Calibration

software.
• Additional DTC parameters can be made calibratable
This continues an experimental change made in cr7281. Calibratable

DTCs are still not being made generally available. This change adds
additional DTC parameters, and adjusts the naming of the parameters as
added to the ASAP2 file.
• DTC IDs can be made calibratable
This is an experimental change and not being made generally available

at this time. This can be enabled by passing the "-d" option to the
capi tool (for C-API users), or by checking the "Generate DDEs for

Change log
DTC parameters." option under "Real-Time Workshop/OpenECU ASAP2

generation options" in Simulink "Configuration Parameters" (for Simulink
users).
Code generation

• Changed Sim-API model builds to use the C-API tool to generate

glue code and ASAP2 files
The Sim-API has been modified to use the C-API tool to create glue
code to the platform library, and to create ASAP2 files. This change
is significant and may cause unforseen backwards compatibility issues
or other problems in general, that we will try to address as quickly as
possible.
In particular, ASAP2 file generation has changed significantly, removing

defects from the old implementation which caused calibration tools to
raise errors and warnings, and adhering more closely to the ASAP2
specification, particularly with respect to naming. As such, importing
calibrations from earlier versions of OpenECU ASAP2 files may fail.
• Changes to the library file require changes to the linker command

in batch files or make files
Changes have been made to the OpenECU libraries which require an

additional file to be linked into the build. This will affect all batch files and
make files used to build for OpenECU targets.
The following file must be added to the list of object/library files to be linked.
• %OPENECU_LIB%platform_obd_diab_5_5_1_0.a
The linker command is %OPENECU_DIAB%dld. At this command, add the

file above to the command line immediately before the first object file (.o
suffix on file).
Note that the change above refers to the environment variables used
in the batch files for building the examples distributed with OpenECU.
Customer batch/make files may use different environment variable
names, or may use absolute paths. In this case, the environment
variables %OPENECU_LIB% and %OPENECU_DIAB% must be replaced as
appropriate to locate the OpenECU library files and the Diab compiler
respectively.
• Added new option, --name-length to specify the maximum length

of identifiers in ASAP2 files
See the C-API user guide for further details.
• Added support for using the C-API tool during the build process

Change log
To enable the production of SIL2 code, the Simulink code generation has
been rebased on the CAPI tool and the old mechanism has been removed.
• Support CCP seed/key security
CCP seed/key security is now supported, using the standard CCP

GET_SEED and UNLOCK services. Separate security algorithms may be
independently specified for calibration, data acquisition and programming.
See the user guide for details about how to configure this using the C-API.
This is backwards-compatible with all existing C-API configuration files. if

no security is specified then the C-API tool will auto-generate code which
requires no security for CCP operations.
Simulink configuration of CCP seed/key security has not yet been added.
Simulink builds will default to having no CCP security.
A2L files generated for CANape are automatically configured for CCP
seed/key security - see the user guide for more details. Configuration of
other calibration tools for CCP seed/key security is not currently supported
and is considered the responsibility of the customer.
Communications

ISO-15765 over CAN.
• Added interface to handle J1939 DM16 transmission
The pj1939_dm16_transmit() C-API function and

pj1939_Dm16Transmit Sim-API block have been added to support
variable length DM16 transmission by the application.
• Extra CAN functionality
Added time stamp functionality to the CAN receive functions and blocks.
The C-API function pcx_receive() now has an additional parameter that

can be used to determine the time at which the message was received.
The prototype of the function has changed and is therefore not backwards
compatible with previous versions of OpenECU.
The Simulink blocks pcx_CANReceiveMessage and

pcx_CANdb_ReceiveMessage now have a new mask parameter
Provide Timestamp? which, when selected, makes available an outport
representing the time at which the message was last received. The mask
parameter is unselected by default, providing backwards compatibility
when loading models created with previous versions of OpenECU.
Added functionality to count various CAN message transmission events.
The C-API function pcx_transmit_status() provides a count of the number

of times a message has been requested for transmission by the

Change log
application, a count of the number of times the message has been queued
rather than immediately sent, and a count of the number of times the
message has been successfully transmitted on the CAN bus.
The Simulink blocks pcx_CANTransmitMessage and

pcx_CANdb_TransmitMessage now have a new mask parameter Provide
Transmit Counters? which, when selected, makes available outports
representing the same counters as the C-API function. The mask
parameter is unselected by default, providing backwards compatibility
when loading models created with previous versions of OpenECU.
Added functionality to provide CAN bus status: error active, passive error,
and bus-off.
The C-API function pcx_get_bus_state() returns the current bus state.

This function largely replaces the pcx_is_bus_available() function which is
now deprecated but retained for backwards compatibility for the moment
(may be removed in a future version of OpenECU developer software).
The Simulink block pcx_BusStatus provides an outport that gives the

current bus state. This block largely replaces the pcx_CAN_Status block
which is now deprecated but retained for backwards compatibility for the
moment (may be removed in a future version of OpenECU developer
software)
Desktop integration

• Added password protection to installer
Previously the OpenECU software was distributed in password-protected

zip files. The password protection has now been moved into the installer
itself, to enable optional component installation and to reduce the number
of seperate installers.
• Add CAPI support for J1939 messages DM35, DM36, DM37, DM38,
DM39 and DM40
CAPI support for J1939 messages DM35, DM36, DM37, DM38, DM39
and DM40 has been added. Simulink block support will be covered as a
separate change.
Enhancements have been made to the pdtc and ppr features.
• A C-API function and Simulink block are provided to allow an application

to determine the existence of a DTC which matches specific criteria.
• A C-API function and Simulink block are provided to allow an application

to determine the number of incomplete diagnostic monitors.

Change log
The results can then be used by the application to generate data for certain
elements of J1939 messages DM35 to DM40, but may also be used for
other purposes.
• Interfaces to the calibration verification number (CVN) added to both

Simulink and C-API
A Simulink block and C-API to support interfacing the calibration

verification number (CVN), have been added. The CVN is calculated using
CRC-16-CCITT. The reported CVN is composed of the code area CRC
and calibration area CRC. Memory regions which are expected to change
during normal ECU operation have been omitted from both code and
calibration CRCs.
Also the InfoType block has been updated to support infotype $0B, In-use
Performance Tracking (IPT), of service $09 in J1979. In future releases,
infotype $0B's interface will be deprecated as it will be carried out in the
platform.
• Diagnostic pending response returned when the calibration

verification number (CVN) has not been computed
The calibration verification number (CVN), is computed in the background

task. Multiple invocations of the background task are used to calculate the
CRC so as to prevent a watchdog timeout. At each invocation the CRC
is calculated for a relatively small chunk of memory. Requesting the CVN
via diagnostic service 0x09 when the calculation has not yet completed
will result in a negative response indicating a pending response.
For Infotype 0x06 (CVN), the InfoType block should only be used in
conjunction with the psc_CvnCalc. block. As the trigger input to the
psc_CvnCalc block is needed to update InfoType 0x06. The connection
between the input trigger to psc_CvnCalc and allowing InfoType 0x06 to
update with a new value is implemented in the platform. In a future release
this connection shall be made available in the application.
• Add support for Euro regulations on DTC behaviour
CR 7804 (VI), affects Sim-API and C-API
CARB regulations require: the ability to transition from Active to Previously

Active based on drive cycles with no fault present; and the ability to
transition from Previously Active to Clear based on warm-up cycles with
no fault present.
Euro regulations (Directive 2005-78-EC) require: the ability to transition

from Active to Previously Active based on drive cycles with no fault present
or on engine running time with no fault present, whichever happens first;
the ability to transition from Previously Active to Clear based on warm-up
cycles with no fault present or on engine running time with no fault present,
whichever happens first; and the ability to transition from Previously Active
to Clear based only on engine running time with no fault present.
This CR adds the ability to calibrate DTCs to meet either set of regulations.
Transitions based on engine running time are disabled by setting the

Change log
engine running time calibration to 0xFFFFFFFF, setting the relevant CAPI

configuration to "never", or unchecking the relevant box in the Simulink
configuration. Similarly, transition from Previously Active to Clear based
on warm-up cycles is disabled by setting the warm-up cycle calibration to
0xFF, setting the relevant CAPI configuration to "never", or unchecking
the relevant box in the Simulink configuration.
Additionally, Euro regulations require the ability to set DTCs "non-

erasable". Active non-erasable DTCs may not be cleared by an OBD scan
tool request - they may only be cleared by warm-up cycles or engine
running time (as configured for this DTC). Following analysis of expected
behaviour during servicing, an OBD clear request will transition an Active
DTC to Previously Active so that the MIL and other lights are turned off.
• Extended in-use performance ratio Sim-API blockset
Changes made to add outports to the blockset to report the state of in-
use performance ratio data.
• Support for J1979 ISO-15765 service $09 InfoTypes
A new Simulink block pdg_InfoTypeInput has been added to support

interfacing service $09 of J1979. The block provides a drop down list to
designate the vehicle specific information type (InfoType) and an inport to
read in the data.
• Support for J1979 ISO-15765 Service $09 (C-API)

Support for ASCII InfoTypes (VIN, CALID, ECUNAME, ESN, EROTAN)
for J1979 ISO-15765 Service $09 has been added to the C-API. A new C-
API function pdg_set_infotype() has been added to allow this information
to be passed to the platform.
• Add application interface to indicate when DTCs have been cleared
A new C-API function pdtc_check_table_cleared() has been

added to report whether DTCs have been cleared by OBD request.
The function returns a bitfield indicating which OBD requests have been
received since the last function call.
A new Simulink block pdtc_TableCleared has been added to indicate

when a diagnostic command to clear all DTCs (or a subset of DTCs) has
been received for the specified table. The block outputs a bitfield indicating
which OBD requests have been received since the time the block was
executed.
• Platform support for PID 0x02 on J1979 service $01

PID 0x02 identifies the DTC that caused the freeze frame to be stored.
This PID is handled by the platform without any application involvement.
See user guide for more details.
• Service 06 and Diagnostic In-Use Performance Ratio (PPR) blocks

Change log
Simulink blocks to support ISO-15765 J1979 service 06 and In-Use

Performance Ratio monitoring (PPR) have been added.
• Removal of deprecated SPI blocks

The Simulink blocks psp_SPIInput and psp_SPIOutput having been
deprecated since version 1.8.0 have now been removed.
• Add CAPI support for J1939 DM32, DM33 and DM34
CAPI support for J1939 DM32, DM33 and DM34 has been added.
Simulink block support will be covered as a separate change.
• Add DTC transition from Previously Active to Pending, and age

DTCs only on drive/warm-up cycle completion
CARB does not specify what should happen if a fault recurs when a
DTC is in Previously Active state. Formerly the DTC went directly back to
Active. Now the calibration pdtc_transition_prev_act_to_pend allows one
to select whether it should go back to Active or back to Pending. To avoid
premature clearing of DTCs, if a DTC has transitioned from Previously
Active to Pending, and a drive cycle then occurs where the test passes
for the entire drive cycle, the DTC will return to Previously Active (with its
warm-up cycle counter cleared).
This CR also encompasses fixes to the DTC state transition algorithm

for aging/self-healing. DTC state transitions were previously only carried
out when a fault was reported set/cleared. DTCs now age correctly when
notification of a new drive cycle or warm-up cycle is received.
• Simulink blockset additions to support diagnostic freeze frames
A block to configure the amount of memory storage to allocate to freeze

frame operations has been added.
A freeze frame block has been added. The list of parameters to be

recorded by a freeze frame is entered as a calibratable vector, as such
the list of parameters is calibratable.
An additional field has be added to the pdtc_DiagnosticTroubleCodeExt

block to specify the freeze frame to capture upon the DTC transitioning
to active.
Only J1979 freeze frames are currently supported.
• Add CAPI support for J1939 DM7, DM8, DM30 and ISO-15765 service
$06
CAPI support for J1939 DM7, DM8, DM30 and ISO-15765 service $06 has
been added. Simulink block support will be covered as a separate change.

Change log
• Simulink block support for DTC-related J1939 DMs
Simulink block support for DM3, DM6, DM11, DM12, DM23, DM27 and
DM28 has been added.
• OBD-related J1939 diagnostic readiness messaging blocks
Simulink blocks to support J1939 DM messages DM5, DM20, DM21 and

DM26, related to diagnostic readiness reporting, have been added.
• Simulink blockset to interface PIDs
A block to interface J1979 8-bit PIDs, Keyword 2000-3 8-bit

LocalIdentifiers and 16-bit CommonID has been added. The block accepts
PID values from the application model via it's sole inport. This inport can
accept multiple values from a mux for example. The value of a string PID
maybe entered in a dialog box.
Non-volatile storage of PIDs is not presently supported.
A Scaling block has been added. Standard J1979 scalings are available
in a drop down list.
• Added J1939 acknowledgement message transmit as a convenience

function
Support for a J1939 DM message acknowledgement response has been

added.
• OBD-related J1939 diagnostic readiness messaging support
Support for J1939 DM messages DM5, DM20, DM21 and DM26, related
to diagnostic readiness reporting has been added.
• Addition of Simulink blockset support for platform-controlled DTCs
A new pdtc_DiagnosticTroubleCodeExt block has been added to provide

support for platform-controlled DTCs. In addition, there is also a
new piso_Configuration block in order to configure ISO diagnostic
communications.
• OBD-related J1939 messaging support
Support for a number of J1939 DM messages related to DTC reporting

has been added.
• Added support for storage and management of OBD in-use

performance ratio data

Change log
Reporting of this data will be added in a future release.

• Changed sampling mechanism for ADC inputs needed to enter

reprogramming mode for the U82 target
Previously, CR 6377 (W) added a new entry condition for reprogramming

mode which relied on sampling four analogue external pins a short period
of time after key on. The analogue inputs were chosen such that false
detection of reprogramming mode would not occur. In the field, it has
been found that at least one of the sensor signals glitches during key
on. Glitches in general may cause reprogramming mode to start when it
should not. To reduce this likelihood, the analogue inputs are sampled
multiple times periodically, and only if all samples meet the entry criteria,
will reprogramming mode be invoked.
Note
• Added primary boot-loader stage to firmware, to allow for inspection

of returned ECUs
The boot-loader has been split into two stages. The first stage is new and
is activated when the ECU is disconnected from other CAN nodes and
attached to Pi equipment. The primary boot-loader stage is present to
allow for detailed inspection of ECUs returned from the field. The second
stage is the same as the existing reprogramming mode of the ECU.
Note
• Added J1939 reprogramming support

Change log
Alpha support for J1939 reprogramming has been added to the firmware.
See the high-level design documentation for details relating to interface
and functionality (fs_j1939_reprogramming.doc, dated 13 May
2011).
Full functionality and documentation is split across two releases:
Functionality Release
Security exchange with dummy security algorithm This
Security exchange with Savanna specific security Subsequent
algorithm
Does not include processing for DM14, DM15 and DM16 This
messages unrelated to boot-load
Firmware handling of DM14, DM15 and DM16 This
messages for boot-load reprogramming. Includes: boot-
load, erase, write, read, operation complete and EDCP
generation message handling
Firmware transmission of ECU identification information Subsequent
Documentation for J1939 reprogramming Subsequent
Note
• Updated J1939 reprogramming support
Further work on J1939 reprogramming support has been completed:
• Security exchange with Savanna specific security algorithm.
• Includes processing for DM14, DM15 and DM16 messages unrelated

to boot-load at the application level.
• Firmware transmission of ECU identification information.
• Documentation for J1939 reprogramming supplied separately from the

main install package.
Note
• Alteration of ADC inputs needed to enter reprogramming mode for

the U82 target

Change log
Input A33 is to be used in place of A35. Thus to enter reprogramming

mode, apply the following combination of voltages to the specific pins prior
to ECU power up:
Pin Condition
A21 < 1V
A22 < 1V
A23 > 4V
A33 > 4V
Note
• ADC calibration in the bootloader has been added for the U82 target
Note
• Alternative method of entering reprogramming mode added for the

U82 target
To enter reprogramming mode, apply the following combination of

voltages to the specific pins prior to ECU power up:
Pin Condition
A21 < 1V
A22 < 1V
A23 > 4V
A35 > 4V
Note
Support for ADC calibration in the bootloader has not yet been
added. This may result in the sampled voltages being skewed.
The extent to how much an uncalibrated ADC can skew the
sampled voltage is unknown and thus this CR should be considered
experimental. The addition of an ADC calibration should resolve this,

Change log
CR 6547 (W) has been raised to an ADC calibration. This work will
be completed in a later release.
Note
decoding.
• Support for open load detection on H-bridge outputs on the U82

ECU
In order to provide open load detection on the H-Bridge outputs an

analogue feedback channel, Monitor (c) (pin A7+A8), has been added.
• Make current thresholds in the U82 configuration block calibratable
The peak current and hold current thresholds for outputs A13 and A14 in
the U82 configuration Simulink block will now accept calibration names
referenced to the data dictionary file. This allows these thresholds to be
changed by reflashing the module over CCP rather than having to rebuild
the model.
• Add support for application determined cam synchronisation on

G400, G800 and G850 targets
The pan_CamWheelConfig block has been extended with a new

cam trigger wheel selection called Determined by application. When
selected, the application can declare cam synchronisation using the
pan_CamWheelDeclareSync block.
• Extended support for the pan_CurrentEngineAngle and

pan_CurrentCrankAngle blocks for the G400, G800 and G850 targets
Previously, the pan_CurrentEngineAngle and pan_CurrentCrankAngle

blocks were supported on the M250 target only.
Now the blocks are supported on the G850 target but the resolution of the
angle outport is limited to the resolution of the crank trigger wheel. For
instance, with a 32-2 patterned crank trigger wheel, the resolution of the
angle outport is 11.25°.
• Extended support in the angular feature for G400, G800 and G850
targets

Change log
The angular functionality was previously left broken for G400, G800 and
G850 targets as part of the CR 2515 (W). As part of this change, angular
support in the Simulink blockset has been extended to support the G400,
G800 and G850 targets, and MATLAB R2010a. See CR 7196 (F) for a list
of angular blocks and their support across targets.
During a model build, MATLAB may emit the following warning:
Warning: Source 'pan_EngineConfig' specifies that its sample time (-1)

is back-inherited. You should explicitly specify the sample time of
sources. You can disable this diagnostic by setting the 'Source block
specifies -1 sample time' diagnostic to 'none' in the Sample Time group
on the Diagnostics pane of the Configuration Parameters dialog box.
This issue will be investigated and resolved in a later release.
• Use of BLDC output pins as H-bridge
The H-bridge interface for the U82 target has been extended to handle
driving two of the BLDC output pins as an H-bridge, with the third pin left
floating.
• Extended the range of PWM and Injector outputs for U82 target
The U82 target can achieve two frequency ranges, [0.1, 40] Hz and [0.5,
10000] Hz, selectable through the C-API function pcfg_setup_u82() or the
Sim-API block pcfg_Config_U82.
• Extended the H-bridge interface for the U82 target
A previous release enabled the H-bridge outputs, pins A7+A8, as

independent digital or PWM outputs. This release removes those digital
and PWM output channels, replacing them with support through the H-
bridge interface.
Note
The C-API function pdx_hbridge_out() has changed prototype
and is therefore not backwards compatible.
The Sim-API block pdx_HbridgeOutput has changed its mask

parameters and you may see warnings similar to these:
Invalid setting in HBRIDGE OUTPUT block (mask) [...]

[...] for parameter 'pdxl_hbot_channels'
[...] does not have a parameter named 'pdxl_hbot_channel_a_pwm'
[...] does not have a parameter named 'pdxl_hbot_channel_a_hs_ls'
[...] does not have a parameter named 'pdxl_hbot_channel_b_pwm'
[...] does not have a parameter named 'pdxl_hbot_channel_b_hs_ls'
[...] does not have a parameter named 'pdxl_hbot_init_mode_val'
In this situation, check the H-bridge block for the correct settings and
save the model. The block will continue to work as before.

Change log
• Added ability to stagger some digital output functions
The fixed and variable PWM interfaces, synchronised PWM interface

and injector peak-and-hold interfaces have been updated with an offset
parameter which staggers the starting edge of the output signal. The offset
can be used to introduce a phase offset between signals with the same
frequency.
Note
The offset parameter is not modifiable during application run-time.
Changing the frequency for related offset outputs during application
run-time must be avoided to maintain the correct offsets.
Note
The Sim-API documentation not complete and not included in this
release. A later release will complete the documentation.
• Added periodic injector functionality for peak-and-hold outputs
There is now a specific interface to drive peak-and-hold injector outputs

on a periodic basis. This interface has been enabled for the U82 target
but no others. A later release will enable support in other targets.
The new interface simplifies how peak-and-hold injector outputs are

driven by combining the separate PWM and synchronised PWM outputs
previously needed, and removing some of the information required from
the application. At the C-API level, the new interface is provided through
the pdx_phinj_output() function. At the Sim-API level, the new
interface is provided through the pdx_PeakHoldInjectorOutput block.
Note
On the U82 target, the peak-and-hold output interface replaces the
synchronised PWM output interface.
For the C-API, this change requires calls to

the pdx_spwm_output() function and corresponding
pdx_pwm_output() functions for the injector clock channels to be
replaced with calls to the pdx_phinj_output() function.
For the Sim-API, this change may lead to warning messages

when the model is loaded. To resolve this, remove the
pdx_PWMSynchronisedOutput blocks and their corresponding
pdx_PWMOutput blocks for the clock channels, replacing them with
a pdx_PeakHoldInjectorOutput block.

Change log
Warning
Use pins A13 and A14 in peak-and-hold mode only. Using pins A13
and A14 in PWM mode will result in undefined behaviour (see the
pcfg_Config_U82 block). A later release will correct this issue.
• Added standalone crank wheel decode functionality for the U82

target
The angular block set has been extended to decode a crank trigger wheel
for the U82 target. Extended crank wheel decode for the U82 target, to add
an option to disable angle clock generation and to function independently
of a cam sensor input.
At the C-API level, the function pan_config_crank_wheel_mtg()

now takes a new parameter panf_generate_angle_clk. Set the
new parameter false and do not call pan_engine_config() in your
application to enable only crank trigger wheel decoding.
At the Sim-API level, a mask parameter labelled Generate angle clock has
been added to the block pan_CrankWheelConfig. Untick the new mask
parameter and do not use the pan_EngineConfig block in your model to
enable only crank trigger wheel decoding.
In both cases, use the interface as directed to configure crank trigger

wheel decoding and then use one of the other crank interfaces to
determine the wheel's speed or other properties.
• BLDC output on the M250 option 00H target
Added draft support for driving a BLDC output on the M250 option 00H
target. Note: the angular functionality on the M250-00H target has been
removed for eTPU code space purposes.
• Flash memory filesystem feature (PFS) added for U82 target

Flash memory filesystem feature (PFS) was added for other targets under
W-CR #5148. Please refer to that change for further details.
• Added flash memory filesystem feature (PFS) to M001, A450, M250,

M460 and M461 targets
For the existing non-volatile storage of DTC and adaptive parameter data,
this improves robustness because previous data can be retrieved if the
most recent stored data is corrupt (e.g. because the ECU lost power during
the storage operation). Also, previous data is only used if the version

Change log
number of the application that wrote it matches the currently executing

version, as well as the data being the expected size. This gives the
application designer some control over whether previous non-volatile data
is used by an upgraded software version.
For C-API users, the functions pnv_commit_to_store() and

pdtc_commit_to_store() now return immediately and save the data
as a background operation while real-time execution continues. Call
pfs_flush_all() to ensure all data is written before power off.
Note
The corresponding Simulink blocks still suspend execution while the
data is saved, matching their previous functionality. Therefore there
is no need to modify existing Simulink models at this time.
For C-API use, the new PFS feature allows user code to read, write, and
delete “files” in flash memory. This provides a general-purpose method of
storing non-volatile data specific to the application. Saving can be done
during real-time execution of the application. See new user guide material
for details.
Target ECU

• Change U82 C-sample support into U82 XNOx-sample support
Support for U82 C-sample has been changed to support the reduced I/O
set of the XNOx-sample. An application, built for the U82 C-sample target,
can be run on C-sample or XNOx-sample ECUs. However, when run on
C-sample, the following C-sample I/O channels are affected and will not
perform as expected:
Pin Comment
A3 Affects digital output
A4+A5+A6 Affects BLDC output, current fault monitor
A9 Affects digital input
A10 Affects digital output, current trip and threshold monitors
A14 Affects digital output, peak/hold thresholds, clock, mode
and current trip monitor
A16 Affects digital output, current trip and dwell monitors
A17 Affects digital output, current trip and dwell monitors
A19 Affects digital input
A46 Affects digital output, current trip, threshold and voltage
monitors
B2 Affects digital input
B3 Affects digital ouptut

Change log
Pin Comment
B6 Affects digital input and voltage monitor
B12 Affects digital output and current threshold monitor
If identified as a requirement, it would be possible to reinstate C-sample

support in full and add a separate target selection for the XNOx variant.
• Added support for M220-00 target ECU
Support for the M220-00 target ECU has been added for the C
Note


developer software.
• Correction to algorithm for reading the ECU's registry or

manufacturing data
Previously, the checksum was not calculated properly for data

stored in the registry and searching for an unsupported
registry key could return incorrect results. This change affects
the preg_retrieve_value_from_key() C-API function and the
preg_RetrieveKey Simulink block.
Calibration

software.

Change log
• Automatic DTC calibrations are incorrectly generated during an

application build
Recent changes to the names of variables generated by the C-API

tool were not complete. The result was that the ASAP2 file could not
be correctly generated — calibrations for DTCs were not visible in the
generated file.
• Corrected ASAP2 file generation where displayables/measurables

were marked as read/write, rather than just read
Code generation

• ECU reset when DTCs cleared on engine running timer where DTCs
have freeze frames
Upon clearing a DTC based on the engine running timer, where the DTC
had a least one associated freeze frame, the ECU was found to reset.
The DTC engine running timer task was not previously allowed to access
the file system. Freeze frames are stored in NVM via the file system. When
the DTC engine running timer task attempted to delete a freeze freeze, it
failed to acquire the file system resource and thus invoked an ECU reset.
To resolve this issue the DTC engine running timer task has been allowed
access to the file system.
• Removed some features from U82 support to save RAM
The following features have been modified or removed to free RAM for
U82 applications:
• disabled driving the MC33937 BDLC device;
• disabled driving the H-bridge via the MC33937 BLDC device;
• disabled angular functionality, including crank trigger wheel input

decoding and voltage sense;
• reduced memory allocated to shared data between application mode

and reprogramming mode.
These changes free up around 6.1 KiB of RAM using a test application
that uses most of the U82 interfaces. Further RAM savings have been
made by optimising the data layout of the diagnostic trouble code feature
in W-CR 7805.
• Fix build dependencies so that if a new task rate is added the RTW
object files rebuild

Change log
Previously, if a new task rate was added and the model rebuilt then it
would fail at the link stage. The workaround was to remove the model build
directory and rebuild.
• Correction to C-API tool for ASAP2 generation when presented with

DDE names that do not match the 'prefix_name' style required by the
user guide
The C-API tool supports DDE renaming when generating the ASAP2 file
(for instance, changing prefix_name into name.prefix). However, DDE
names which do not follow those laid out by the user guide, for instance
TRUE, caused the renaming logic to fail.
The DDE renaming logic is now more tolerant of names which do not follow
the naming pattern laid out by the user guide.
• Correction to generation of the model hierarchy in ASAP2 files
The C-API tool supports placing each DDE in zero or more hierarchical
groups. But the C-API tool would not deal with groups without a name,
causing the tool to report an exception.
The C-API tool now supports unnamed elements in the hierarchy by

explicitly naming the unnamed elements unnamed. If more than one
unnamed element occurs then the C-API tool will rename them using the
same rules as any other duplicated ASAP2 identifier.
• Correction to generation of ATI Vision strategy files
• Correction to compiler check
While building a Simulink model, a check is made that

the compiler is available. When the OPENECU_DIAB_4_4B or
OPENECU_DIAB_5_5_1_0 environment variables were used but did not
end in a trailing \ character, the script making the check would fail.
• Correction to automatic signal property settings for DDEs when

library links are present in a model
Previously, if a library link was present in a model and active, then the
oe_update_model_for_ddes MATLAB script would fail and stop a
model build or a configuration set change from occurring.
Communications

ISO-15765 over CAN.
• Zero length Erase, Write or Read J1939 Memory Access commands

are not supported anymore

Change log
A zero-length Erase, Write or Read does not make sense and therefore
they are now rejected.
Note
• Longer than allowed J1939 DM16 messages are not supported

anymore
If a DM15 request is issued with a specific allowed length, a longer DM16

data message was allowed to be received which was corrupting ECU
memory. Now, only DM16 messages with the allowed length or less are
supported. Allowed length is sent on the DM15 message. Because the
DM16 message has an additional byte for Number of Occurrences, the
message can have a length of allowed length plus one additional byte.
Note
• Correction to possible buffer overflow for J1939 DM16 message
Previously, if a J1939 DM16 message was requested to be sent by the

application through the pj1939_dm16_transmit() C-API function or
the pj1939_Dm16Transmit Simulink block with a message size greater
than the size of the configured message buffer, the error was not detected
and could result in a buffer overflow. Now the error is properly detected
and passed to the application, avoiding the possible buffer overflow.
• Fix J1939 transmit priority for multi frame/packet messages
Previously the priority was stuck at 7 (lowest) regardless of what was

requested through the Simulink or C interfaces.
• Fixed J1939 transmit priority for single frame messages
Previously the priority was stuck at 7 (lowest) regardless of what was

requested through the Simulink or C interfaces.
• Correction to transmit priority for J1939 DM16 message

Change log
Previously, the transmit priority of all J1939 DM16 messages requested by

the application through the pj1939_dm16_transmit() C-API function
or the pj1939_Dm16Transmit Simulink block would be forced to 7.
• Fix to VDB pack routine (pcx_vdb_pack_msg and

pcx_CANdb_TransmitMessage)
Under certain circumstances, bits outside of a field could get corrupted

during packing. This has been corrected.
• FreeCCP/DevCCP installer and Kvaser operation
Fixed installer so that essential DLL for Vector drivers was released with
FreeCCP.
When using Vector interfaces, the "-device <value>" option may now
be used to set the interface channel being used. This is the same option
used to select the channel on Kvaser interfaces.
Kvaser interfaces were previously unreliable with FreeCCP. This was due
to the bit sampling time values used. These values have been fixed so
that FreeCCP may now be used reliably with Kvaser interfaces.
If hardware was not correctly communicating on CCP, CCP errors could

cause unhandled exceptions. This has been fixed so that CCP errors are
now reported correctly to the user without crashing FreeCCP.
• Mistake in determining error code in FreeCCP
Minor fix to allow retries after certain CAN receive failures, when checking
that data was transmitted OK.
• Added Kvaser support and memory upload options to unsupported

FreeCCP development tool
Kvaser CAN support is selected using the -kvaser command line option.
For more information about FreeCCP, see the user guide or use the
command line option -h when running FreeCCP.
• Servicing external watchdog in prg2prg and prg for X657 target
Previously, the external windowed watchdog in X657 was serviced during

boot loader execution, but not during flash erase operations. Also, prg2prg
(used to upgrade the firmware) was not supported for X657.

Change log
After this change, prg2prg is now supported for X657. The external
watchdog is also serviced during flash erase operations in boot loader or
prg2prg, so that large flash areas can be safely erased without the external
watchdog causing a reset. This will be important later in the life of the
microcontroller when the specified maximum erase times become much
longer (up to 7.5 sec).
Note
• FreeCCP allows 29-bit CAN IDs
Affects Sim-API and C-API
FreeCCP previously would not work with 29-bit CAN IDs on Vector
hardware. This has been fixed at FreeCCP version 4.1.0.
• Fixed incorrect behaviour for DTE numerator and denominator

updates
Previously, a requested numerator update via the

ppr_DiagnosticTestEntity block incorrectly resulted in a denominator
increment and vice-versa.
• Freeze frame buffer wraparound error
A buffer is used to store freeze frame data while it awaits storage in NVM.
This buffer is designed to wraparound in the case that multiple freeze
frames are awaiting storage and a new freeze frame is captured.
Low level testing has identified an error in the indexing of this data under
some conditions. This results in incorrect indexing into the buffer. The
result of this being that storage of new freeze frame data may be prevented
until the module has been reset.
• Freeze frame missing delete trigger
In two instances it was noted that the setting of a flag to trigger freeze
frame deletion was missing. This would only be noticeable in some
extreme cases: if the memory allocated to storing freeze frames was full
then new freeze frames might not be stored because other freeze frames
had not been successfully deleted.
• Reduce RAM and NV used by DTC structures

Change log
DTC structures have been changed so that only the minimum data
necessary is stored in NV. Further data is stored in RAM where necessary,
but this is still significantly reduced. Overall reductions should be 18 bytes
per DTC for NV usage and 12 bytes per DTC for RAM usage.
Some DTC table structures were found to have been stored in RAM
instead of in Flash. These have been correctly moved to Flash, saving 12
bytes of RAM per DTC.
DTC structures have also changed. Handling of DTCs has always required
the coder to pass a "const" and an "NV" section separately, which could
lead to inconsistent data being passed to the relevant functions. DTC
structures have now been changed so that the "const" structure only
is passed to the relevant functions. The "const" structure for each DTC
then references the relevant "NV" structure and a new "variable" structure
(stored in RAM). The coder does not (and should not) therefore need to
concern themselves with a DTC's internal data.
The change to DTC structures and DTC-related functions means that this
is not backwardly-compatible for customers using the C-API interface with
C code. This is encapsulated by the relevant Simulink blocks though, so
this change is backwardly-compatible for customers using the Simulink
interface.
• Changes to DTC state handling for warm-up
Changes have been made to DTC state handling for warm-up cycles to
better match our understanding of the legislative requirements. See user
documentation for a detailed description of the new behaviour.
• Non-continuous monitor status reporting in J1939 DM26 message

used incorrect DME flag
The J1939 DM26 message now reports non-continuous monitor status

using the DME readiness complete flag (as opposed to the DME
completed flag).
• Prevent clearing of permanent DTCs by ISO-15765 and J1939 clear

requests
DTCs marked as permanent may not be cleared by OBD clear requests.

They are only allowed to clear through the aging/self-healing process. This
has been added for ISO-15765 services $04 and $14, and for J1939 DMs
3 and 6.
• Remove risk of excessive NV writes for DTC storage
The function pdtc_update_plat_obd_dtc() was requesting DTC storage

to NV every time it was run, regardless of whether DTCs changed. If
the application was allowing NV writes at a fast rate (e.g. every 100ms),

Change log
this could have resulted in excessive NV writes. In practice it seems that

customer will not generally attempt NV writes this often, but NV write
for DTCs is now strictly requested only on DTC change, to prevent this
situation ever arising.
• Support desired lamp state priorities

Temporary fix to select suitable lamp state priorities ("fast-slow-on-off"
instead of "on-fast-slow-off") by default in Simulink builds. To be replaced
by an appropriate Simulink block configuration in future.
• Correct DM1 handling of ISO-15765/J1939 DTCs
If any DTCs were configured to be reported on both ISO-15765 and J1939,

these DTCs were not reported on J1939. This has now been fixed.
• Support ISO-15765 functional addressing in Simulink build
Interim fix added for Simulink builds to automatically support ISO-15765

functional Rx using standard ISO-15765 CAN IDs (0x7DF for 11-bit CAN
IDs, 0x18DB33F1 for 29-bit extended CAN IDs).
The Rx CAN ID specified in Piso_configuration block is used for

ISO-15765 physical Rx. At a later date, an additional option will be added
in the piso_configuration block to allow the functional RX CAN ID to be
specified by the customer.
• Fixed bugs in the DTC state machine (when DTC controlled by the
platform)
The state machine logic has changed such that:
1. When a DTC is in state Active, a test failing within a drive cycle would
not have been detected.
2. In state Pending, irrespective of drive cycle, a check should be made

to detect if a fault is present.
• Fix ECU flooding J1939 comms with DM1
If any DTC is active then a DM1 message was incorrectly sent every time
a call to dm1_transmit is made. And conversely, if no DTCs are active
then no DM1 message was sent at all.
This has been fixed to correctly follow J1939-73 revised Feb 2010. The
ECU now sends DM1 every 1s, regardless of whether any DTCs are
active or not. If a DTC changes to/from active state between 1s DM1
transmissions then a further DM1 is sent, but no further DM1s are sent for
changes of state of this DTC for this 1s period.
• Fixed bug whereby the updating of MIL-on timer and distance was
missing from platform controlled DTC updates

Change log
• “Off by one” error related to the drive and warm-up cycles
There was an “off by one” error related to the drive and warm-up cycle
parameters defined for use with the DTC state machine. This has now
been addressed.
• Addition of freeze frames to J1979 diagnostics
Freeze frames are now captured when a J1979 DTC becomes active from
being previously clear or inactive; or when a DTC goes pending. This
is as required by California Code of Regulations On-Board Diagnostic
System Requirements. In addition, the freeze frames are cleared when
the corresponding DTCs are cleared. See user guide for more details.
• Freeze frames for permanent DTCs being deleted on J1979 service

$04 request
Previously all freeze frames were deleted in response to a J1979 service

$04 request. However permanent DTCs are not deleted, and their freeze
frame data should not be either. This has now been rectified.
• Reporting PID 0x02 as supported on J1979 service $02
Previously PID 0x02 was not listed as a supported PID in response to a

J1979 service $02 request. Now, PID 0x02 is always listed as supported.
• Versioning issue causing freeze frame data to be lost
A problem with the way application version information was stored with
freeze frame data was causing freeze frame data to be rejected when read
out of non-volatile memory. This has now been fixed.
• Model build error if unused parameters left empty when defining a

DTC block
Leaving unused parameters empty when defining a DTC block caused a

model build error. This was easily done for the ISO ID parameter (when
the J1939 DTC type was selected) and the SPN, FMI and CM parameters
(when the ISO DTC type was selected). These parameters now default to
zero when empty and unused.
• DTC lamp status now set correctly
The DTC lamp status is 2-bit field with four values: 0 = Slow flashing; 1
= Fast flashing; 2 = On continuously; 3 = Off. Previously, at initialisation

Change log
and when DTCs were cleared, the lamp status was being set to 0 =
Slow flashing rather than to 3 = Off. This applied to clearing DTCs
by the C-API functions pdtc_clear_all(), pdtc_clear_all_if_active() and
pdtc_clear_all_if_inactive(), and by the Simulink blocks pdtc_ClearAll,
pdtc_ClearAllIfActive and pdtc_ClearAllIfInactive. The lamp statuses are
now set correctly.
• Fix to diagnostic clear routines
The functions "pdtc_clear_all", "pdtc_clear_all_tables" and

"pdtc_clear_all_by_severity" were incorrectly only allowing ISO-15765
DTCs to be cleared. Similarly, the functions "pdtc_clear_all_if_active" and
"pdtc_clear_all_if_inactive" were incorrectly only allowing J1939 DTCs to
be cleared. Within the platform and the expected application- platform
interface, this is how these functions were expected to be used; however
as a general-purpose interface, this undocumented restriction was not
desirable. The functions have therefore been changed so that they may
be used for any DTC type.
The functions already took a parameter to specify the DTC type, so the
functional interface is unchanged. The functions now use this parameter
correctly to select the desired DTC type to clear.
This fix also applies to Simulink functionality using the corresponding

"pdtc_clear" Simulink blocks.
• Fix bug wherein application crashed when there were zero DTCs
• The inclusion of a piso_Configuration block is no longer a

requirement when using pdtc_DiagnosticTroubleCodeExt blocks
Previously, any Simulink model that used the Simulink

block pdtc_DiagnosticTroubleCodeExt needed also to contain a
piso_Configuration block. This is no longer the case, and the blocks can
be used with or without each other.
• Number of drive cycles / warm-up cycles now limited to a maximum

of 254
In the Simulink block pdtc_DiagnosticTroubleCodeExt, the mask

parameters "Number of drive cycles that must be completed before this
DTC transitions from Pending to Active", "Number of drive cycles that must
be completed before this DTC transitions from Active to Previously Active"
and "Number of warm-up cycles that must be completed before this DTC
transitions from Previously Active to Clear" are now limited to a maximum
of 254, as values of 255 would prevent the corresponding transitions from
ever occuring.
• Fix lamp state prioritisation with multiple DTCs active

Change log
Lamp state prioritisation now works correctly when multiple DTCs are
active across multiple DTC tables. For each lamp, the highest-priority state
for that lamp will be selected from all active DTCs in the selected DTC
table.
The C interface to configure lamps has changed. However the CAPI

and Simulink interfaces have not changed, so configuration should be
backwardly-compatible for all current customers.
Examples

• Updated the quick-start example so that it will not compile without

following the changes specified in the quick start section of the user
guide
Previously, the quick-start step1 example would compile without

modifications required to fill out the functionality. The resulting non-
operational application could then be confused for a working application.
Now, when the step1 example is built without following the user guide, a
warning message is emitted and the build stops without completing.
• Change to default compiler in example batch files
Previously, the C-API examples delivered with OpenECU were provided

with batch files which did not point to any compiler. The user was required
to update the batch file before building.
Now, the batch files use the OPENECU_DIAB_5_5_1_0 environment

variable as the location of the compiler (see the installation section for
details on how to set this environment variable). In most cases, this change
removes the need for the user to update the batch file before building.
• Extended the Simulink examples to include S-function example
The Simulink examples have been extended to include a sample

application that illustrates how C code can be use in an OpenECU
Simulink model.

• Changed voltage levels of ADC inputs needed to enter

reprogramming mode for the U82 target

Change log
The voltage ranges for A21, A22, A23 and A33 have been narrowed to
avoid accidental entry to reprogramming mode on reset (related to CR
6377 (W) and CR 6729 (W)). Thus to enter reprogramming mode, apply
the following combination of voltages to the specific pins prior to ECU
power up:
Pin Condition
A21 < 0.05V
A22 < 0.05V
A23 > 4.95V
A33 > 4.95V
Note
• Updated firmware to allow CCP and J1939 to use the same CAN bus
while reprogramming
Previously, CR 6952 (W) extended the firmware to include reprogramming

using the SAE J1939 protocol. In doing so, it was assumed that CCP and
J1939 would exist on separate buses. But this lead to a defect where by
CCP would become disabled if enabled on the same CAN bus as J1939
during reprogramming.
Note
• Corrected negative FEPS operation in M220 firmware
This change configures the M220 such that negative FEPS now works
correctly and enters reprogramming mode using the default CAN
configuration.
Note

Change log

• Corrected power-hold behaviour of the M220 firmware
This change corrects the behaviour of the power-hold whilst the

bootloader is active. The power-hold is not longer active during bootloader
execution.
Note
decoding.
• Preprocessor inclusions for GPIO digital inputs
A recent change to the preprocessor inclusions for GPIO digital inputs

effectively removed support for these inputs for MPC5xxx targets. This
has now been rectified.
• Changes to I/O selections for U82 C-sample delivery
The software has been updated to add support for C-sample U82 ECUs
and to remove support for A-sample U82 ECUs. Changes from A-sample
to C-sample include:
Pin A-sample C-sample

A1+A30 Thermal trip monitor Current trip monitor,
temperature monitor
A7+A8 Digital monitor Current trip, short circuit
and undervoltage monitor
A10 - Current threshold monitor
A15 Spark output -
A17 Digital output Spark output
A19 Analogue input Digital input

Change log
Pin A-sample C-sample

B9 Digital input Analogue input
B10 FEPS -
B12 - Digital output, voltage
monitor, current trip
and threshold monitors
In addition, the pss_OvercurTripReset block has changed from controlling

the trip reset latches for pins A1, A15, A16 and A30, to controlling the trip
reset latches for pins A1, A7+A8, A10, A11, A12, A16, A17, A30, A45,
A46 and B12.
Warning
Do not run A-sample software on C-sample ECU, or vice-verca.
Doing so may damage the ECU.
Note
• Correction to the H-Bridge fault indicator input on U82
The H-Bridge output A7 and A8 was indicating a fault due to incorrect

microcontroller pin assignement to the fault indicator input. This was
corrected.
• Correction to task definitions for models with the TDC-firing trigger
In models without the TDC-firing trigger, the fastest model rate task
definition was incorrectly dropped from the schedule. This has been
corrected.
Installation

before OpenECU.
• Correction to installer for R2010a
Previously, when the user selected integration with MATLAB R2010a

through the installer, the installer would not update MATLAB's path for
R2010a. The result was that the user would need to manually update
MATLAB's path.

Change log
Now, the installer does not skip updating MATLAB's path for MATLAB
R2010a.
Target ECU

• Restore of IUPR NVM data on power-up
This fixes a problem whereby the in-use performance ratio data that was
stored to NVM upon power-down was not being restored upon power-up.
• Added some missing I/O channels for testing purposes (spare SPI
based channels)
• Removed quadrature decode functionality from U82 target for eTPU

code space purposes
• Updated range of I/O channels for U82 technical specification
• Draft U82 technical specification
• Correction to channel assignment for dwell feedback channels to

match U82 rev1mod2 PCB changes
• Correction to over-current trip handling through the

pss_OvercurTripReset block
• Changed names of various input channels for the U82 target
The following input channel names have changed: A4 voltage monitor

(phase-A), A5 voltage monitor (phase-B), A6 voltage monitor (phase-
C), A13 hold threshold monitor, A13 peak threshold monitor, A14 hold
threshold monitor, A14 peak threshold monitor, These channels will need
to be reset manually when a U82 model is loaded using this version of
OpenECU developer software.
• Added voltage monitor feedback signals for each arm of the H-

bridge on U82 target
• Draft U82 technical specification

Change log
Added draft U82 technical specification to remove some TODO items

(more left to do, technical specification is unreviewed, please treat with
care)
User documentation

and PDF formats.
• Improve Power hold description entry in user documentation
Updated User Guide/Tech Specs documentation for power hold

functionality on A450, M001, M220, M250, M460 and M461.
• Clarification made to documention for pcx_vdb_pack_msg() and

pcx_pack_msg() C-API functions
It wasn't clear that the array written to by these functions through the
pcxf_msg_data argument should be 8 bytes in length. This has been
clarified in the C-API user guide.
3.17. Release 1.8.6

Release labelled release-1.8.6 from 9 February 2011. This release is marked as general
meaning the release has been regression tested and is intended for general use. The
following table provides quick access to each of the changes.

compatible upgrade
C-API No CRs 6591 (W) Yes No
Sim-API No CRs 6591 (W) Yes No

decoding.
• Corrected an incorrect channel assignment for the M460 target
Previously, the M460's C7 pin had an incorrect channel defined which

prevented correct operation when used as a digital input.

Change log
3.18. Release 1.8.5

Release labelled release-1.8.5 from 20 December 2010. This release is marked as

compatible upgrade
C-API 5971 (W), 5813 (W), 5700 6138 (W), 6047 (W), 5737 No, see: No
(W), 4247 (W) (W), 2175 (W) 6138 (W)
Sim-API 5791 (W), 5700 (W), 4247 6507 (W), 6047 (W), 5737 No, see: No
(W) (W), 5708 (W), 4209 (W)
4563 (W), 4400 (W), 4209
(W), 2175 (W)


developer software.
• Added support for MATLAB/Simulink R2010a
The OpenECU blockset can now be used with Matlab R12.1, R13.1,
R14.1, R14.2, R2006b, R2007b, R2008b, R2009a and R2010a.
Note
A future release of OpenECU will remove support for R12, R13 and
R14.
Calibration

software.
• Added Vector CANape v8.0 support in the ASAP2 file generation
Further details are described in the “Supporting tools” section of the user
guides.

Change log
• Corrected issue with checksum during ISO reprogramming
• Added handling of DTC ageing by platform in accordance with

CARB-OBD rules
decoding.
• Added angular spark functionality for M250 targets
Angular spark functionality is now available via the pan_SparkConfig and

pan_Spark blocks on M250 targets.


developer software.
• Corrected dynamic inport sizing for adaptive 2D map lookup block
Previously, unlike the adaptive 1d map lookup block, the adaptive 2d map
lookup block would not allow vector signals as inports.
Now, the adaptive 2d map lookup block allows vector signals as inports, so
long as all vectors are of the same size. It is acceptable to have a mixture
of scalar and vector inputs to the block.
Code generation

• Eliminated use of individual linker files in C-API applications
Previously, each C-API application used its own linker file, which defines
the memory map and how to arrange objects within that map. However,
this made it difficult to alter or upgrade the memory map or linker settings,

Change log
as any changes would have to be applied to each such linker file. Now,
the linker file is constructed from master files in the platform library.
Existing C-API applications should be modified to use the new linker file
arrangement. To do this, use the installed example applications as a
template. The batch (.bat) file has a new line to construct the linker file
and then the invocation of the Diab linker command “dld” is modified to
use that linker file.
• Renamed command oe_build to oe_build_model
Communications

ISO-15765 over CAN.
• Correction to Vector CANdb file handling
The recent change for CR 4400 (W) allowed tolerance to Vector

CANdb files containing duplicated signals in one message. However, the
warnings emitted about these messages by the gen_candb_info tool
caused incorrect handling in the corresponding pcx_CANdb_Transmit and
pcx_CANdb_Receive blocks. The warnings are no longer emitted when
invoked from MATLAB so correct handling is restored, but are available
for command line use for diagnostic purposes.
• Corrected unpacking negative integers using the

pcx_CANdb_ReceiveMessage block for Simulink, or the
pcx_vdb_unpack_msg() C function
Previously, when extracting negative integers from a CAN

message using the pcx_CANdb_ReceiveMessage block or the
pcx_vdb_unpack_msg() C function, the most significant bit of the
integer (ignoring the sign bit) would be incorrectly set, resulting in an
incorrect value.
• Made CANdb file parsing tolerant of multiplex signals
Previously, Vector CANdb files containing messages with duplicate

signal entries were rejected by the gen_candb_info tool, so
such files had to be edited by hand before being used by
the pcx_CANdb_ReceiveMessage and pcx_CANdb_TransmitMessage
blocks, even if the message of interest contained no duplicate signals.
Now only the first instance of a signal is processed by default in any one
message, and processing continues, so that such a CANdb file can be
used without editing.

Change log
decoding.
• Corrected the angular diesel injection functionality
In certain circumstances, a very fast train of pulses was being generated

on the injector outputs, this has been fixed.
The time to restart injections having previously requested zero pules is

now much reduced.
• Correction to synchronised PWM output driver
Previously, the synchronised PWM (SPWM) driver could be disabled

incorrectly if the application had set the slave delay to zero while also
setting the master duty cycle to 100%, or if the frequency of master or
slave was changed abruptly.
Now, the SPWM driver has been corrected to handle 100% duty cycle,
and abrupt frequency changes without stopping the channel.
• Correction to PWM output for some G400, G800 and G850 pins to
give the correct duty cycle and frequency
3.19. Release 1.8.4

Release labelled release-1.8.4 from 18 October 2010. This release is marked as general

compatible upgrade
C-API 4211 (W) 5702 (W) Yes Yes, see:
5702 (W),
4211 (W)
Sim-API No CRs 5702 (W) Yes Yes, see:
5702 (W)

Communications

ISO-15765 over CAN.
• Added first basic support for ISO-15765 based flash reprogramming

Change log
Note


developer software.
• Corrected issue with application checksum calculation
Previously, the boot-loader made incorrect assumptions about the

application size. This potentially resulted in instances where the boot-
loader checksum calculation did not match the value in the application
header (calculated during compilation). As a result the boot-loader
erroneously regard the applications as corrupted.
Now, the checksum region size is always identical in both the boot-loader
and the compile time calculation.
Note
3.20. Release 1.8.3

Release labelled release-1.8.3 from 21 July 2010. This release is marked as general

compatible upgrade
(W), 4162 (W), (W), 4755 (W), 2515 (W) 4210 (W),
3376 (W), 3242 (W), 3242 4584 (W), 4521 (W), 4389 3376 (W),
(W), 3242 (W), (W), 4378 (W), 3242 (W)

Change log

compatible upgrade
3242 (W), 2515 (W), 2515 3713 (W), 3630 (W), 3382
(W) (W), 3256 (W),
3256 (W), 3242 (W), 2690
(W), 2473 (W),
2195 (W), 1925 (W), 1914
(W)
(W), 3242 (W), (W), 4560 (W), 2515 (W) 4210 (W),
2515 (W), 2515 (W) 4521 (W), 4391 (W), 4378 3242 (W)
(W), 3713 (W),
3630 (W), 2767 (W), 2690
(W), 2597 (W),
2515 (W), 2473 (W), 2195
(W), 1974 (W),
1925 (W), 1914 (W), 1902
(W)


developer software.
• Allow the idle background task to access model resources and to

indirectly access platform owned based resources for digital I/O and
CAN communications
Previously, if the idle background task attempted to access a resource

delared in a C-API interface specification, or if the idle background
task attempted to access some digital I/O or CAN communications, the
platform would record that the idle background task had attempted to use
a resource it should not have and then reset the ECU.
Now, the idle background task can use model resources, access digital
I/O through the PDX feature, and access CAN communications through
the PCX feature.
• Updated the C-API platform to use a SIL2 process
The development process of OpenECU has changed to be compliant to a

process suitable for SIL2 as defined by MISRA, “Development Guidelines
for Vehicle Based Software”, 1998. Currently only the M250 ECU and a
subset of the C-API functionality has been developed to this process.
Process changes have been made to requirements, design and test

specifications, with bidirectional traceability of requirements to design and

Change log
test specifications. Requirements, design, test and implementation have

all been peer reviewed and the MISRA, “Guidelines for the use of the C
Language in Vehicle Based Software”, 1998
Note
Please contact us if you need SIL2 compliance so we can confirm
whether or not your own application's use of the C-API is covered
by our development process.
• Added support for a subset of ISO-15765 based diagnostics
The C-API has been updated to add support for the following services
through the PDG, PDTC and PPID features:
ID Service Notes
0x03 ReadEmissionDTCs Reports only DTCs defined as
(J1979) emission-related
0x04 ClearEmissionDTCs Clears only DTCs defined as
(J1979) emission-related
0x14 ClearDiagInfo Clears all ISO DTCs (not J1939-
(KW2000-3/UDS) only DTCs)
0x18 ReadDTCByStatus All DTCs, regardless of emissions
(KW2000-3) severity
0x19 ReadDTCInfo 16-bit DTCs currently output,
(UDS) higher byte zero
0x22 ReadDataByCommonID Used to read PID values
(KW2000-3/UDS)
0x2F IOControlByCommonID Used to override PID values
(KW2000-3, UDS)
0x3E TesterPresent Ping to maintain communications
There is now more than one type of DTC, a J1939 DTC and an ISO DTC.
The platform treats both as the same, unifying both so that the same set
of DTCs can be accessed over J1939 and ISO communication protocols.
The C-API tool has been updated to support the same, introducing
the iso_diagnostics statement to declare ISO communication
parameters, introducing the pid_data statement to declare PID entities,
and introducing the dtc statement to declare unified diagnostic trouble
codes. See the C-API user guide for further details.


Change log

• Added repeated reset catch to prevent an ECU application from

continually resetting and becoming unresponsive
Previously, a reset in the application would cause the application to restart.

Repeatedly resetting in a short period of time would result in an ECU which
did not perform its function and was unresponsive to calibration tools.
Now, the ECU firmware has been updated to detect repeated resets. If a
repeated reset is detected, the firmware will enter reprogramming mode
and flash code 117. To restart the application, the ECU ignition or power
must be cycled.
Note
• Added application code and data checks prior to invoking the

application
The ECU firmware has been updated to include a full checksum of the
application (where previously the boot-loader would only checksum the
header of the application). This results in an increased boot duration but
mitigates the risk of running an application which has become corrupt.
To enable checksum tests:
1. Upgrade the ECU's firmware to revision 1.8.3 or later (see below).
2. Add the -c command line option when the pop_header.py script

is invoked as part of the build mechanism. As the pop_header.py
script is invoked separately for the application code and application
calibration data, the build can select which groups are checksummed
(if any).
Note
There is no support yet for allowing a calibration tool to update
the calibration checksum. If the application calibration data
is checksummed, then cal-on-the-fly functionality will still be
supported, but reprogramming a modified calibration will result in
a failed checksum test during boot mode, and the ECU will enter
reprogramming mode flashing code 118.
The C-API examples have been updated to checksum the application

code groups, but not the calibration data groups.

Change log
Note
• Added tests on RAM prior to starting the application
The platform has been extended to perform a series of RAM tests

before starting the application. If a RAM test fails, the ECU will enter
reprogramming mode and flash code .
Note
decoding.
• Added support for the pdx_QuadratureDecode,

pdx_QuadrateDecodeAndFrequencyInput blocks to the M2xx and
M4xx ECUs
• Added an enhanced analogue input processing function
The added functions, put_enh_process_analog_input_init()

and put_enh_process_analog_input(), use a leaky bucket per
transient fault signal, rather than the single, combined leaky bucket in the
put_process_analog_input() function, at the expense of additional
RAM consumption.
• Refactored angular C-API and Simulink blockset
Previously, the angular blockset provided little scope of extension. For

example, the pan_EngineConfig block was overloaded with configuration
parameters to define TDC firing angles, TDC calculation angle, crank and
cam wheel patterns, and crank synchronous A/D sampling. The block
itself was large enough that the corresponding dialog window displayed
by Simulink was too large for some screens.

Change log
Now, the angular blockset has been refactored into a more orthogonal
interface. There are individual configuration blocks for each aspect of the
angular functionality, which will allow smaller parts of the blockset to be
used without invoking functionality that is not required
Note
Due to the refactoring, support for angular functionality on the G400,
G800 and G850 targets in the Simulink blockset is broken. This will
be corrected in a future release.

• Allow the “idle” background task to lock resources
Previously, the background task could not acquire a resource without

causing the ECU to reset. This prevented the background task from
sharing data structures coherently with higher priority tasks.
Now, the C-API tool automatically adds the background task to each
resource declared in a C-API interface specification file, allowing the
background task to acquire resources used by higher priority tasks.
Target ECU

• Replaced support for M250 rev-1 ECUs with support for M250 rev-2
ECUs
The software has been updated to remove support for M250 rev-1 ECUs
and add support for M250 rev-2 ECUs. All M250 rev-1 ECUs will be
replaced with M250 rev-2 ECUs.
Note
If you have a M250 rev-1 ECU please contact OpenECU technical
support as described in Appendix A, Contact information.
• Added support for angular functionality in the M250
Angular support for diesel engines has been added. In particular the
platform provides the following functionality:
• Crank trigger wheel processing — can synchronise and track crank

wheels with grouped missing teeth;

Change log
• Cam trigger wheel processing — can synchronise and track a single

lobed cam wheel;
• Crank synchronous A/D input capture — can sample two A/D inputs on
an angle basis (up to 8 samples per cylinder);
• Diesel multi-point injection — can generate up to 6 injection pulses on an

angle-mass basis, adjusted for fuel-rail pressure just prior to generating
each injection pulse. An S070 ECU is required to convert the injection
pulses into peak-and-hold signals for the injectors.


developer software.
• Corrected macro for ptm_get_sys_time() and similar functions
Previously, the macro PSY_SYS_CLK_MHZ was not included in the

installation file set. As the C-API macro PTM_SYS_TIME_TO_US relied on
the PSY macro, some applications would not compile.
Now, the macro PTM_SYS_TIME_TO_US can be used in applications

without causing compilation issues.
• Added a 64-bit signed and unsigned integer types to the C-API as

a convenience
• Corrected duplicate error codes reported by the C-API interface tool
The C-API interface tool has been updated to extend some error and
warning messages with unique identifiers (where previously messages
were reused in situations were another message would have been more
helpful), and the user guide updated accordingly. See the C-API user
guide for a complete list of error messages.
• Changed behaviour of relative includes in C-API interface

specification files
Previously, include files with relative paths (like the statement include-
dde-tabbed-c ../interface_specification/foo.dde) where
taken relative to the invocation directory, not the directory of the interface
specification file, leading to confusion.
Now, include files with relative paths are taken relative to the directory of
the interface file that includes the file.

Change log
• Updated command line options for the C-API interface tool
The option -v has been added as a short version of --version. The

option --bool-type has been added as a long version of -b. Run the
C-API interface tool with option --help for a complete list of command
line options and meanings.
• Corrected handling of nested resource acquisitions
Previously, in some situations, if the application attempted to

acquire a second resource without first releasing the first using the
pkn_acquire_resource() function, the platform software would log
an incorrect unrecoverable error code and reset the ECU.
Now, the application can acquire more than one resource sequentially
without the platform software incorrectly causing a reset.
• Corrected in the maintenance of Simulink's task timers
Previously, the mechanism used to maintain Simulink's task timers was

incorrectly implemented. This meant that Simulink functionality that did not
rely on task timers worked as expected, but some functionality, such as
blocks in triggered subsystems, would fail. An example of this is the use
of the OpenECU pai_AnalogInput block in a triggered subsystem.
Now, with the expansion of the supported RTW auto-coders, the

RTW-RSIM auto-coder retains this broken behaviour for backwards
compatibility with existing models. The RTW-RTMODEL and RTW-EC
auto-coders correctly implement task timers.
• Issue with using the fastest model rate as the angular task
The platform was using the fastest rate for the angular
task. This caused various issues with Simulink blocks that
tracked time. To rectify this, the block set has been extended
to provide support for a non-periodic trigger for angular
functionality (see Sim-API blocks put_BufferedRateTransition_Read and
put_BufferedRateTransition_Write).
However, this new feature is still experimental and should not be used.
To continue to use the fastest model rate as the angular task, ensure the
Provide TDC calc trigger? parameter in the pan_EngineConfig block is
unticked and that the Angular rate functionality (deprecated) RTW option
is ticked.
Calibration

software.

Change log
• Corrected validation of C-style data dictionaries
Previously, a 2-D look-up y-axis array was rejected if it contained less than
3 elements, but the minimum allowed axis array size is 2 elements.
Code generation

• Corrected C-API tool code generation
Previously, if a C-API interface specification file contained a task

declaration without a period:
task
{
name = stp_task;
priority = 1;
function = stp_task_100ms;
}
then the C-API tool would incorrectly generate a warning about the task's
offset being more than twice the task's period, allowing an application build
to complete. The resulting application would cause the ECU to reset.
Now, the C-API tool raises an error asking for the task's period to be
defined, and stops an application build from continuing.
• Corrected size of generated application image files during a build
Previously, a build of an application would generate large application

image files which included a region of processor Flash that the
manufacturer of the processor has raised an errata for. The
reprogramming code would refuse to program this group of Flash,
resulting in an application that could not be programmed. This problem
did not affect the small application images.
Now, a build of an application will generate large application image files

leaving out the region of Flash not to be used.
• Workaround for incorrect code generation using Diab 5.5.1.0 with

large Simulink/RTW models
Without direction from a Simulink model, RTW will generate the majority
of the model code in one function. As the size of the model increases, the
size of the function increases. It has been discovered that Diab 5.5.1.0 will
silently generate incorrect code when the function size becomes too large.
The workaround for this issue is described in Section 2.5.9.2, “Known
defects”.
Communications

Change log

ISO-15765 over CAN.
• Corrected documentation in the J1939 receive and transmit blocks

for LS and MS packing
Previously, the J1939 receive and transmit blocks both incorrectly stated
the enumerations to use for LS and MS byte packing. The dialog stated
that MS byte packing corresponded to value 0 and LS byte packing
corresponding to value 1, unlike the user guide which stated the opposite.
Now, the J1939 receive and transmit blocks specify the same values as
the user guide.
• CAN receive processing robustness improvements
An earlier change to M2xx and M4xx ECUs included some minor

improvements to the handling of CAN receive events, CR 4378 (W). These
changes have been applied to Gxxx ECUs.
• Corrected instructions for reprogramming M2xx and M4xx ECUs
Previously, instructions in the user guides describing how to

reprogramming M2xx and M4xx ECUs did not describe the role of the
key position (ignition) switch input in controlling power. The key position
input must be powered in order for the ECU to power up and enter
reprogramming mode. Failure to power the key position input would leave
the ECU in a state where reprogramming could not commence.
Now, the instructions explain the use of the key position (ignition) switch
input.
decoding.
• Corrected issue with PWM generation
Previously, on the A450, M001, M250, M460 and M461 ECUs, some PWM
output channels could generate the wrong PWM signal for one cycle, when
changing from a non-zero duty cycle to zero duty cycle. When the issue
occurred, the PWM signal would generate 100% duty cycle for one cycle,
then revert to the requested duty cycle.
Now, changing from a non-zero duty cycle to a zero duty cycle is correctly
handled.
• Corrected configuration of PWM mode for M250 and M460 ECUs

Change log
Previously, setting the configuration to PWM mode with the

pcfg_setup_m250() and pcfg_setup_m460() C-API functions, or
pcfg_Config_M250 and pcfg_Config_M460 Simulink blocks, would not
switch in the recirculation diode.
Now, when the configuration is set to PWM then the platform software will
configure the hardware to allow current recirculation back to VPWR.
• Issue with locale settings and the use of the degree symbol in the
angular block set
Previously, the angular block set was using the ASCII degree symbol and
this in turn caused MATLAB to issue an error when using the block set.
The platform no longer uses the ASCII degree symbol, and models using
the angular block set would load without error in any locale.
• Corrected PWM input parameter clipping
Previously, the pdx_pwm_output() function would not clip the duty cycle
to the range [0, 100]% if the frequency was also clipped. This could result
in an incorrect PWM signal.
Now, the duty cycle parameter is clipped, regardless of whether the

frequency parameter is also clipped.
• Corrected the use of the pai_AnalogInput block in triggered

subsystems
Previously, some of the functionality of the pai_AnalogInput block

when used in a triggered subsystem, would fail, due to the incorrect
maintenance of Simulink's task timers, as described in CR 2767 (W).
Now, the pai_AnalogInput block is correctly supported when using the

RTW-RTMODEL or RTW-EC auto-coders.
• No channel checks for synchronised PWM output block
The Simulink interface does not prevent an application model using

channels in both a synchronised PWM output block and another PWM
output block. It is up to the developer to avoid this erroneous double
assignment.

• Corrected task timing

Change log
Previously, some versions of the software would incorrectly index the task
timing data in the ASAP2 file, for instance, the task timing for task B would
be displayed when viewing the task timing for task A.
Now, the task timing in the ASAP2 file is correctly aligned with the task
timing data recorded by the ECU.
Target ECU

• Corrected G850 technical specification regarding use of Hall-effect

crank sensors
Previously, the G850 technical specification described the use of the

E47+E46 pin pair for a Hall-effect crank sensor and erroneously showed
that pin E47 should be left unconnected, where instead, pin E46 should
be left unconnected.
• Corrected the documentation of the G850 UNI H-bridge driver
Previously, the relation between the duty cycle on the input and the actual
H-Bridge driver used inconsistent pictures to illustrate the behaviour. The
documentation has been updated to remove the inconsistency.
• Corrected A450 technical specification
The A450 technical specification stated that all A450 ECUs had power
hold functionality enabled. This wasn't the case; only a few A450
ECUs had power hold functionality enabled on the PCB. The technical
specification has been updated accordingly.
• Corrected various G850 technical specification issues
The G850 technical specification has been updated to correct and clarify
various issues:
1. Pin C46 (ISP-R) is inverted. Ignition switch on (VBAT) reads close to 0V,
ignition switch off reads close to 5V (in software, the range is scaled
down from VBAT to 5V). The trip point is around 1.5V +- 0.2V.
2. INJ_ENABLE must be asserted low to enable outputs, not assert high

as the documentation states.
3. Added in details about ECU protection modes for each of the output
drivers.
• Corrected G850 technical specification for pins E69+E70

Change log
Previously, the G850 technical specification showed that pins E69 and
E70 were independently driven with independent feedback signal, where
in fact those pins were driven from the same internal signal but had
independent feedback signals.
3.21. Release 1.8.2

Release labelled release-1.8.2 from 25 April 2010. This release is marked as general

compatible upgrade
C-API No CRs 4377 (W), 4372 (W), 3948 No, see: No
(W), 3653 (W), 3356 (W),
3356 (W), 2175 (W) 2175 (W)
Sim-API 3944 (W) 4590 (W), 4495 (W), 4395 No, see: No
(W), 4394 (W), 3356 (W)
4377 (W), 4372 (W), 4052
(W), 4050 (W),
3948 (W), 3653 (W), 3356
(W)


developer software.
• Added checks on the compiler prior to starting the compilation stage

of the build process
When a model build is initiated, OpenECU now attempts to check the

compiler for availability and accessibility. If the checks fail, then a suitable
message explaining the failure is printed and the build stops.
The intent of this change is to try to avoid unexpected errors during a build
if the compiler has not been setup correctly. In these circumstances, the
messages printed during a failed build were hard to understand. For more
information about the checks performed, issue:
help oe_check_compiler
at MATLAB's prompt, or issue:
oe_check_compiler

Change log
to run those checks manually.


developer software.
• Work-around to Simulink warning messages with models that

include large quantities of tunable parameters
Previously, with models that contain large quantities of tunable parameters

(calibrations), some versions of MATLAB would generate the following
warning messages when a model is loaded:
block_diagram does not have a parameter named 'portedGlobal'.

block_diagram does not have a parameter named 'rtedGlobal'.
block_diagram does not have a parameter named 'edGlobal'.
...
Now, the tunable parameters is cleared when possible to minimise the

possibility that these warning messages might occur.
• Corrected build mechanism to allow embedded S-functions in later

versions of OpenECU
Previously, with R2007b and other versions of Simulink, RTW would

force the inclusion of RTW specific files rt_matrx.c and rt_printf.c
regardless of whether any functions in those files were called or not.
As rt_matrx.c requires the use of dynamic memory (through calls to
calloc()), the Diab linker would require the linker scripts to support
dynamic memory. The OpenECU linker scripts do not support dynamic
memory by design and as a result, model builds would fail.
Now, the template makefile has been updated to exclude the use of
rt_matrx.c and rt_printf.c, which allows the build of a model with
at least one embedded S-function to complete.
• Changed some of C-API I/O names
In a continuing effort to provide access to all of the ECU I/O and to provide
consistent naming for I/O channels, there have been some recent changes
to the C-API macro names.
Previous name New name

A450
None PIO_AIN_A19_A29_A39_A40_MONITOR_V

Change log

None PIO_DIN_A19_A29_A39_A40_MONITOR_CT
G850
PIO_AIN_[...]_MONITOR PIO_AIN_[...]_MONITOR_V
PIO_AIN_C35_C36 PIO_AIN_C35_C36_VPWR
PIO_DIN_[...]_MONITOR PIO_DIN_[...]_MONITOR_D
PIO_PIN_[...]_MONITOR_MAX PIO_PIN_[...]_MONITOR_CT_MAX
PIO_PIN_[...]_MONITOR_NOM PIO_PIN_[...]_MONITOR_CT_NOM
M460
None PIO_AIN_A19_A29_A39_A40_MONITOR_V
PIO_AIN_INT_EXTERN_GROUND PIO_AIN_C9_C19_EXTERN_GND
None PIO_DIN_A19_A29_A39_A40_MONITOR_CT
M461
PIO_AIN_INT_PSUPOS_5VQ PIO_AIN_A9_A19_C9_C19_EXTERN_GND
None PIO_AIN_INT_COLD_JUNCTION_TEMP
Code generation

• Remove error after model build completes when the break-links

option is on
Previously, when the break-links option was on and a model finished

building, RTW would generate an error about an invalid handle.
Regardless of the error, the output files from the build were correctly
generated.
Now, the underlying issue causing the error message has been removed.
Communications

ISO-15765 over CAN.
• Fixed interrupt processing issue
Previously, with M2xx and M4xx ECUs, external interrupts (CAN and
SPI) could become incorrectly suspended while application code tasks
executed. This was seen to result in missed CAN receive messages in an
application with high CPU loading and high CAN traffic, and issues with
CCP data acquisition.
decoding.

Change log
• Corrected the inversion parameter in the digital input block
The digital input block would honour the inversion parameter during model
simulation but not when running on the target ECU. The issue has been
corrected.
• Updated non-volatile memory blocks and map lookup blocks to

remove unexpected MATLAB crashes
Previously, the adaptive scalar, map and array, and the utility map blocks
could cause MATLAB to crash if the block parameters were only partially
populated.
Now, the underlying issue causing the crashes have been removed.
• Updated pnv_Array block to remove unexpected MATLAB crashes
Previously, when more than one pnv_Array block was populated in a

model, there was a possibility that MATLAB would crash without referring
to the pnv_Array block in stack trace dumps.
Now, the underlying issue causing the crash has been removed.
Target ECU

• Updated G850 technical specification to show 2 CAN interfaces for

fleet units
• Updated connector image for M460, M461 and A450 to avoid

confusion
The protrusions indicated in these diagrams are on the back of the

connector shell, but can be confused with the ones on the mating
side, which are in a slightly different position. A note has been added
underneath the diagrams to explain this.
• Correction to analogue input ranges in G850 technical specification
The following external pin voltage ranges have been corrected: E23, E28,
E29, C7, C9, C15, C21, C26, C29, T16, T17, T24 and T25 and T28.

Change log
• Removed selection of current trip level for pins A1, A11, A21 and
A31 on the M461-00 ECU
Although early issues of the M461-00 ECU have the ability to select current
trip thresholds, later issues do not. The pcfg_Config_M461 Simulink block
and pcfg_setup_m461() C-API function have been removed.
3.22. Release 1.8.1

Release labelled release-1.8.1 from 9 November 2009. This release is marked as

compatible upgrade
C-API 3369 (W), 3356 (W), 3356 3470 (W), 3466 (W), 3349 Yes Yes, see:
(W), 3274 (W), (W), 3274 (W), 2950 (W),
2950 (W), 2950 (W), 2950 3022 (W), 2711 (W) 2950 (W)
(W), 2517 (W),
2074 (W)
Sim-API 3369 (W), 3356 (W), 3356 3470 (W), 3466 (W), 2711 Yes Yes, see:
(W), 2950 (W), (W), 1903 (W) 2950 (W),
2950 (W), 2950 (W), 2517 2950 (W)
(W), 2489 (W),
2074 (W)


developer software.
• Remove include order dependencies for C-API header files
Previously, the order of include files from the C-API mattered (psy.h had
to be included prior to other C-API headers, pdtc.h had to be included
prior to pj1939.h.
Now, the include order is unimportant. There is also a new header file,
openecu.h which includes all of the C-API header files.
• Added API to kick the main processor watchdog
Affects C-API
The C-API interface tool has been extended to specify whether

the platform software or application software will control the

Change log
watchdog timer through the os-native::watchdog statement. If the

application controls the watchdog timer, the application can invoke the
psc_kick_watchdog() function to resets the watchdog timer when
required.
Note
Currently, there is no mechanism to control the duration of the
watchdog timer.
• Added API to read the ECU's version information
Affects C-API
Each ECU contains 4 code images: boot code, reprogramming

code, platform code and application code. Each image
contains a version number and a date corresponding to
when the image was built. The psc_get_boot_version(),
psc_get_prg_version() and psc_get_platform_version()
provide access to the version information for those code images. The
psc_get_boot_build_date(), psc_get_prg_build_date() and
psc_get_platform_build_date() provide access to the build date
information for those code images.
• Added block to kick the main processor watchdog
Affects Sim-API
The psc_KickWatchdog block provides the model control over when the
watchdog timer is reset. If the block is not present in the model, then the
platform software continues to reset the watchdog timer automatically.
Note
Currently, there is no mechanism to control the duration of the
watchdog timer. See the block help for more details.
• Added block to determine the CPU loading
Affects Sim-API
The psc_CpuLoading block provides access to the average CPU loading

calculated every 50 milliseconds, and the maximum CPU loading seen
every 50 milliseconds since the ECU powered up.
• Added block to determine the stack usage
Affects Sim-API
The psc_StackUsed block provides access to the maximum number of

stack bytes used by the application since the ECU powered up.
• Added blocks to access the ECU's version information
Affects Sim-API
Each ECU contains 4 code images: boot code, reprogramming

code, platform code and application code. Each image contains a

Change log
version number and a date corresponding to when the image was

built. The psc_BootVersion, psc_PrgVersion and psc_PlatformVersion
provide access to the version information for those code images.
The psc_BootBuildDate, psc_PrgBuildDate and psc_PlatformBuildDate
blocks provide access to the build date information for those code images.
• Added blocks to provide model timing information
Affects Sim-API
Two blocks were added to provide access to time (both absolute and
relative). The ptm_SimulinkTime block provides access to Simulink's task
timers, in seconds, milliseconds or microseconds. The ptm_RealTime
block provides access to the ECU's processor timers, in seconds,
milliseconds and microseconds. Both blocks provide the time since the
start of simulation or since the start of the ECU power up, as an absolute
time. And both blocks provide the time since the last time the block was
executed (or the start of the model in the first instance).
• Added option to enable or disable simulation inports and outports

for most blocks
Affects Sim-API
• Added support for MATLAB R2009a
Affects Sim-API
As well as integrating with MATLAB R12.1, R13.1, R14.1, R14.2, R2006b,

R2007b and R2008b, OpenECU now integrates with MATLAB R2009a.
• Integrated OpenECU help files with MATLAB help browser
Affects Sim-API
In R14.1, R14.2 and R2008a, the OpenECU User Guide (Simulink) is now
available to read through the MATLAB help browser. Simply select the
Simulink menu item Help -> Product Help and select the OpenECU User
Guide.
Code generation

• Added support for Embedded Coder
Support for Embedded Coder has been added to the blockset. There
are a series of support blocks to quickly switch between the various
auto-coders supported by OpenECU (see prtw_ConfigUsingRtwEc,
prtw_ConfigUsingRtwRtmodel and prtw_ConfigUsingRtwRsim).
• Added blocks to configure a model for various auto-coders and to

initiate an RTW build
Affects Sim-API
The prtw_ConfigUsingRtwRsim, prtw_ConfigUsingRtwRtmodel and

prtw_ConfigUsingRtwEc blocks support configuring OpenECU models

Change log
using the three code formats supported by RTW (namely, RSIM, GRT
and ERT formats). The blocks change the model's target specification file
for the corresponding code format and update the model's configuration
parameters
The prtw_Build block initiates a model build using the model's current
configuration parameters.
• Added blocks to modify the command line options presented to the

compiler and linker
Affects Sim-API
The pcomp_CompileOptions and pcomp_LinkOptions blocks add simple

support for modifying the command line options presented to the compiler
and linker. The blocks allow the user to use the default OpenECU option
set, to add to the default OpenECU option set, or to replace the OpenECU
option set altogether.
Communications

ISO-15765 over CAN.
• Added support for 250 kBps default baud-rate (in addition to the
500 kBps setting) in reprogramming mode for G850, A450, M460, and
M461 targets
Now there are two different versions of boot and prg images that can be
flashed into the ECU.
Note
• Added support for FEPS-less reprogramming on A450, M460, and

M461 targets
These targets will be able to enter reprogramming mode when a reflash

is attempted with a calibration tool. The application still has the ability to
inhibit the reflash for safety reasons, in which case the Command Return
Code (CRC) from the CCP attempt will be ACCESS DENIED (0x33).
Note

Change log
• Added support for returning the MTA0 address in response to a

PROGRAM, or PROGRAM_6 command over the CCP protocol for the
A450, M460, and M461 targets
decoding.
• Ensure all A/D channels are sampled at least twice as quick as the
fastest software task
The A/D channels are now sampled twice as quick as the fastest software
task (1 millisecond) to ensure that if the software requires a new sample
every millisecond, it can have one.
• Added support for decoding TLE4953 input signals
Added the pdx_TLE4953_Input Simulink block and

pdx_tle4953_input() C-API function to decode the output from
TLE4953 devices (G400, G800 and G850 ECUs). The TLE4953 is a
differential Hall Effect sensor, designed to provide information about
rotational speed and direction of rotation.
• Added block to drive constant current outputs
Affects Sim-API
The pax_CcOutput block provides access to the constant current outputs

on some ECUs. This block replaces the mechanism to drive constant
current outputs through the deprecated psp_SpiOutput block.
• Added block to reset the over-current trip latches on some ECUs
Affects Sim-API
The pss_OvercurTripReset block provides a mechanism to reset the over-

current trip latches that disable outputs which draw too much current.

• Added API to read current and maximum task duration
Affects C-API
The pkn_get_task_duration() and

pkn_get_max_task_duration() functions return the last measured
task duration and maximum task duration (since power on or reset) in
microseconds.

Change log
• Added blocks to provide task timing information
Affects Sim-API
The pkn_TaskDuration block provides access to the last measured task

duration and the maximum measured task duration (since power on or
reset) in microseconds.
Target ECU

• Added selection of current trip level for pins A1, A11, A21 and A31
on the M461 ECU
The pcfg_Config_M461 Simulink block and pcfg_setup_m461() C-API

function allows the selection of the current trip level for pins A1, A11, A21
and A31 of the M461 ECU.
• Provide selection of current trip level for pin A31 on the M460 ECU
The pcfg_Config_M460 Simulink block and pcfg_setup_m460() C-API

function allows the selection of the current trip level for pin A31 on the
M460 ECU, when the pin is configured as a PWM output.
To support this, the C-API PCFG feature functions now return a code
indicating whether the function was successful or not, based on the
function arguments.
• Added support for M250-00 target ECU (rev-1)
Support for the M250-00 target ECU has been added for the C
M250-00 provides two H-Bridges. Use the Simulink block

pdx_HBridge_Output and pdx_hbridge_output() C-API function to
drive the H-Bridge.
M250-00 provides outputs than can be either high or low side via software
select. New internal digital output channels have been added to select the
output configuration.
A future release of the platform software will add engine/angular

functionality to the M250-00 target.
• Added blocks to support G400, G800, G850 and M250 target ECU
configuration
Affects Sim-API
The pcfg_Config_G400, pcfg_Config_G800, pcfg_Config_G850 and

pcfg_Config_M250 blocks add support to configure some of the ECU

Change log
hardware options for input filtering and trip point detection on some
pins. The G400, G800 and G850 blocks replace the previously hidden
calibration mechanism for doing the same.


developer software.
• Corrections to use single float math operations wherever possible
Previously, the platform library would use 64-bit wide floating point values
for constants. The use of double caused various calls to support libraries
to be called, slowing down simple arithmetic operations in some library
functions.
Now, the platform library uses 32-bit wide floating point values for
constants, avoiding expensive calls to support libraries. The overall result
is a reduction in run-time when calling certain platform functions. Although
the application as a whole will run more quickly, the application code itself
is unaffected by this change.
• The PTPU API has become deprecated in favour of the equivalent

PAN API
Affects C-API
The angular API PTPU has been replaced by the equivalent PAN API.
Please replace use of the PTPU API with the PAN API. In a future release,
the PTPU API will be removed.
Calibration

software.
• Raise an error in DDE files if there is more information than columns
Previously, if there was more information than there were columns in a

DDE file then the C-API interface tool would incorrectly raise an error about
a non-existent column.
Now, under the same circumstances, the C-API interface tool will raise an
error explaining the problem.
Communications

Change log

ISO-15765 over CAN.
• Correction to CCP driver
Previously, the CCP driver would reject requests for data from ROM
memory groups of the ECU when monitoring variables, only allowing data
to be read from RAM groups. However, ATI Vision ignores the rejection
and expects data for rejected groups. In turn, the ECU sends the variable
data as expected but would fill out rejected groups with uninitialised data.
In combination, these two mechanisms result in unexpected data being
displayed by Vision. The issue affected build and version automatic DDEs,
such as mpl_plat_build_day.
Now, the CCP driver accepts requests for variable data in ROM memory
groups and Vision correctly displays the data.
Examples

• Correct linker files for C-API examples
Previously, CR 2471 (W) corrected an issue related to non-correctable

Flash errors during power-on. The changes were applied to the Sim-API
but not the C-API, with the result that the C-API examples would not build.
Now, the C-API example linker files have been updated accordingly and
the C-API examples build without errors.
decoding.
• Remove the need to call the pan_ignore_cam_sync() C-API

function on a continual basis
Previously, the application needed to call the pan_ignore_cam_sync()

C-API function frequently, as the platform would reset the application's
request when crank sync was lost.
Now, the platform remembers the application's request when

pan_ignore_cam_sync() is called, and the application need not call
the function on a continual basis. By default, the platform will attempt to
synchronise to the cam signal.
• Document the allowable number of TDC firing events in the

pan_EngineConfig block

Change log
The pan_EngineConfig block has always only accepted an even

number of cylinders but the documentation has implied otherwise. The
documentation has been updated to show that 2, 4, 6 or 8 TDC events
must be provided.
Target ECU

• Included cold-junction temperature input for M461 ECU
The cold-junction temperature input for the M460 allows for accurate
calculation of the thermocouple inputs. Although the M461 doesn't
include thermocouple inputs, the cold-junction input is still available.
Previous versions didn't include the cold-junction input as there were no
thermocouple inputs. Now, the cold-junction temperature input for the
M461 is available as a means to determine the ECU temperature.
• The put_Config_M460 block has become deprecated
Affects Sim-API
The put_Config_M460 block is now deprecated, please replace use of

this block with the pcfg_Config_M460 block. In a future release, the
put_Config_M460 block will be removed.
3.23. Release 1.8.0

Release labelled release-1.8.0-internal-dev-1 from 4 July 2009. This release is

compatible upgrade
C-API 2940 (W), 2226 (W), 2175 3470 (W), 2549 (W) No, see: No
(W) 2175 (W)
Gateway 2226 (W), 2175 (W) 3470 (W), 1896 (W) No, see: No
2175 (W)
Sim-API 2226 (W), 2175 (W) 3470 (W), 3111 (W), 1155 No, see: No
(VI) 2175 (W)


developer software.

Change log
• Merged 1.5.x, 1.6.x and 1.7.x releases of software together
The versions of software for 1.5.x, 1.6.x and 1.7.x support various features
and hardware targets, but no one version of the software supported all
features and all hardware targets. By merging all versions together, there
is now one main version, which should lead to less confusion and easier
support.
This merge has introduced a number of differences:
• The psp_SpiInput and psp_SpiOutput blocks are now deprecated.

These blocks will be removed in a future version of the
software. For digital inputs and digital outputs, please use the
corresponding pdx_DigitalInput and pdx_DigitalOutput blocks. For
analogue inputs, please use the corresponding pai_AnalogInput or
pai_BasicAnalogInput blocks. A future release of the software will
include a block to deal with constant current outputs.
• The range of values used to drive constant current outputs has changed
from [0, 255] (G400) and [0, 511] (G800, G850), to [0, 4096] across all
targets.
• To facilitate the merge, the knock related angular blocks have been
disabled (affecting the G400 and G800 targets). A future release will re-
enable this functionality.
Communications

ISO-15765 over CAN.
• Update FreeCCP to work with A450, M460 and M461 ECUs
Previously, CR 1139 (VI) introduced a revised implementation of CCP.

The revised implementation contained differences from the previous
implementation that caused the display output from FreeCCP to differ from
its previous version.
Now, the display output from FreeCCP has been reformatted to improve
clarity, and the version number of the target CCP implementation is always
printed. In particular the verbose mode print-out is easier to read and
interpret.
Target ECU

• Extended the C-API to include the G850 target ECU
The C-API has been extended to include the G850 target ECU. Some of
the notable changes include:

Change log
• The C-API has been extended to include functionality for engine control,
including synchronisation to the crank and cam trigger wheels, injector
and coil driving. At a later date this API will be extended for knock signal
processing.
• The C-API has been extended to include functionality to configure some

of the signal processing performed by the G850 ASIC, including some
filter and hysteresis levels relating to HEGO and VRS inputs.
• The C-API interface tool has been extended to understand references

to arrays and structure members in data dictionary files. To take
advantage of this ability, the interface file must be updated to reference
a new type of data dictionary file. The new data dictionary file uses a
slightly different format from the existing data dictionary files, including
extended syntax for data dictionary entity names. For example, a data
dictionary entity can now refer to all the member variables adc_eng
from the following C declaration:
typedef struct
{
U16 adc_raw
F32 adc_eng;
U8 fault;
}
ADC_T;
ADC_T adcs[10];
as adcs[..].adc_eng.
While extending the C-API for the G850 target, there are some changes
which affect compatibility with previous versions of the OpenECU
software:
• The pax_set_input_update_rate(),
pax_set_output_update_rate(),
pdx_set_input_update_rate() and
pdx_set_output_update_rate() API functions have become
deprecated. Their use is no longer necessary. Calls to these API
functions should be removed from application code.
• The pcfg_softswitch_m460() API function has become

deprecated. Please use the pcfg_setup_m460() API function
instead.
• To accommodate new types of pins, some of the PIO_[...]

macros have changed name to make the format of the name more
consistent. Of note, the PIO_BUS_CAN_[...] macros have changed
to PIO_CAN_[...], and the PIO_SPOT_INT_SLAVE_[...] macros
have changed to PIO_SPOT_[...]_SLAVE. The complete list of
changes for all ECU targets are as follows:

PIO_TIME_PIN_TOUT_MIN_US PIO_RATE_FIN_MIN_HZ
PIO_TIME_PIN_TOUT_MAX_US PIO_RATE_FIN_MAX_HZ
PIO_TIME_PWMI_TOUT_MIN_US PIO_RATE_PWMI_MIN_HZ
PIO_TIME_PWMI_TOUT_MAX_US PIO_RATE_PWMI_MAX_HZ
PIO_BUS_CAN_[pin-names] PIO_CAN_[pin-name]

Change log

PIO_AIN_INT_CJ_TEMP PIO_AIN_[pin-
names]_COLD_JUNCTION_TEMP
PIO_AIN_INT_VBAT PIO_AIN_[pin-names]_VPWR
PIO_AIN_C24_C25 PIO_AIN_C24_C25_DIFF
PIO_AIN_INT_PSU_POS_3V3 PIO_AIN_INT_PSUPOS_3V3
PIO_AIN_INT_PSU_POS_5VD PIO_AIN_INT_PSUPOS_5VD
PIO_DIN_[pin-name]_MONITOR_C PIO_DIN_[pin-name]_MONITOR_CT
PIO_DOT_INT_PSU_HOLD PIO_DOT_A12_HOLD_PSU
PIO_DOT_C8_EXTPSU3 PIO_DOT_C8_SWITCH_PSU3
PIO_DOT_C18_EXTPSU4 PIO_DOT_C18_SWITCH_PSU4
PIO_POT_[pin-name]_INJ_CLOCK PIO_POT_[pin-
name]_DOT_INJECTOR_CLOCK
PIO_SPOT_INT_SLAVE_[pin-name] PIO_SPOT_[pin-name]_SLAVE
PIO_DOT_INT_OVERCURRENT_TRIP_1 PIO_DOT_[pin-names]_
OVER_CURRENT_TRIP_RESET_1
PIO_DOT_A31_SOFTSWITCH PIO_DOT_A31_FN_SWITCH
PIO_DOT_INT_OVERCURRENT_TRIP_2 PIO_DOT_A31_
OVER_CURRENT_TRIP_RESET_2
• OpenECU: corrected user guide to show angular blocks support the

G850 ECU (ref W-CR #2693);
Some additional work will be undertaken after this release to:
• Extend the C-API interface tool to support adaptive parameters defined

in C-style data dictionary files.
• Extend the C-API interface tool to support Tunes.
• Better document when parameters to API functions can be NULL.
Note
The C-API now supports the following ECUs: A450, G850, M460
and M461.
Although the C-API documentation makes explicit reference to the

G400 and G800 targets, no testing has been performed against
these targets and Pi will not provide technical support when using
the C-API against these targets.

Calibration


Change log

software.
• Data dictionary files may now use ** rather than -- to start a

comment line
Microsoft Excel, useful for editing the column data of a dictionary file,
does not reject the use of ** (but does reject the use of --, replacing the
comment with #NAME).
Code generation

• Updated the build directory name to include the version of OpenECU

and version of MATLAB
Affects Sim-API
Previously, the same build directory name ([model-

name]_openecu_rtw) was used across all versions of OpenECU and
MATLAB. This caused some problems when upgrading OpenECU or
changing to another version of MATLAB, if the model was rebuilt without
first deleting the build directory (which contained files created using a
different version).
Now, as well as adjusting the build process to try to avoid these problems,
a build directory which matches the OpenECU and MATLAB version,
avoiding the problem altogether.
Communications

ISO-15765 over CAN.
• Correction to J1939 receive and transmit blocks
• Removed OpenGateway functionality from product
CR 1896 (W), affects Gateway
Pi provide a number of alternative CAN to CAN gateway products. For

more information please contact <openecu@pi-innovo.com>.
• Correction to J1939 receive and transmit blocks
CR 1155 (VI), affects Sim-API
Previously, the J1939 receive and transmit blocks rejected use of the last
bit in a J1939 message.
Now, the last bit of a J1939 message can be accessed without an error
message.
Examples

Change log

• Corrected path information in C-API example build batch files
Previously, the C-API example build batch files would contain incorrect
path locations for the OpenECU installation path and Diab installation
path.
Now, the installer correctly adjusts the path locations (the user must still
update the batch files for the location of the Diab installation).
Target ECU

• Corrected the gain in the cold junction voltage equation in the A450
and M460 technical specifications
3.24. Release 1.7.5

Release labelled release-1.7.5 from 14 May 2009. This release is marked as general

compatible upgrade
C-API 2519 (W) 2520 (W), 2471 (W), 1956 Yes No
(W)
Gateway 2519 (W) 2520 (W), 2471 (W), 1956 Yes No
(W)
Sim-API 2688 (W), 2688 (W), 2519 2520 (W), 2471 (W), 1996 No, see: No
(W) (W), 1956 (W), 2688 (W)
1911 (W)


developer software.
• Added support for MATLAB R2006b, R2007b and R2008b

Change log
As well as integrating with R12.1, R13.1, R14.1 and R14.2, OpenECU

now integrates with R2006b, R2007b and R2008b. With this support, a
number of additional changes have occurred:
• As well as support for the RTW GRT (RSIM) auto-coder, there is

also experimental support for the RTW GRT (RTMODEL) auto-coder
which implements some of the benefits of the Embedded Coder RTW
package. By default, the GRT (RSIM) auto-coder is selected. A model
can select which auto-coder to use by changing the system target
file in the RTW options. Either openecu.tlc for GRT (RSIM) or
openecu_grt.tlc for GRT (RTMODEL).
Note
At this time, no technical support will be provided for the GRT
(RTMODEL) auto-coder. A future release will finalise support for
the GRT (RTMODEL) auto-coder and add support for Embedded
Coder.
• The supporting commands have changed name so that all begin with oe
to differentiate them from other commands of the same name in other
packages. The changes are outlined in the following table:
Previous Updated Use

Documentation
help openecu help openecu Print list of commands to the console
ver openecu ver openecu Print version of OpenECU blockset
to the console
Blockset
openecu_blockset oe_blockset Open the OpenECU blockset library
openecu_examples oe_examples Open the OpenECU examples
model
Model and build list actions
create_openecu_model oe_create_model Create a new OpenECU model in
the current directory
read_build_list oe_read_build_list Read the model data dictionaries
into the workspace
clear_build_list oe_clear_build_list Remove workspace DD entries and
build list paths
Supporting tools
freeccp oe_freeccp Download built model to an
OpenECU via CAN/CCP
Paths to OpenECU objects
path_openecu_examples oe_path_examples Print path to OpenECU top level
example files
path_openecu_help oe_path_help Print path to OpenECU help files
- oe_path_install Print path to OpenECU installation
directory

Change log
Previous Updated Use

path_openecu_python oe_path_python Print path to OpenECU python
installation
path_openecu_root oe_path_root Print root path to the OpenECU
blockset
path_openecu_tools oe_path_tools Print root path to OpenECU tools
• To better organise the Simulink support files that make up OpenECU,

various sub-directories to the [install-location]\openecu
directory have been made. This has little effect except when adjusting
the MATLAB path. Prior to this change, there was only one OpenECU
path to add to MATLAB search paths, but now there are multiple. See
the installation guide for details on how to set MATLAB's path manually.
• Integrated OpenECU help files with MATLAB help browser
In R14.1, R14.2, R2006b, R2007b and R2008b, the OpenECU User Guide
(Simulink) is now available to read through the MATLAB help browser.
Simply select the Simulink menu item Help -> Product Help and select the
OpenECU User Guide.
decoding.
• Added a PWM input block (Simulink) and function (C-API)
A pdx_PwmInput Simulink block and pdx_pwminput() C-API function

have been added. The function measures the input signal frequency,
duty cycle, pulse durations, counts of complete periods, and determines
whether the signal has timed out.

Code generation

• Rebuild models completely when changing version of OpenECU
Previously, if a model was build using one version of OpenECU, then the
version of OpenECU updated, then the model was rebuilt using the new
version, the resultant build would not always work correctly. This occurred
because some compiler options held in files in the build directory from
the older version of OpenECU were not overwritten with newer compiler
options.

Change log
Now, if the version of OpenECU changes, or if the version of Diab

changes, then the old model build directory will be rebuilt entirely,
removing the issue of building against old compiler options.
Communications

ISO-15765 over CAN.
• Correction to handling of CAN bus-off status
Previously, if a CAN bus-off event occurred, subsequent CAN message

transmissions would be delayed significantly (on average, by around 50
milliseconds), causing loss of communication with the calibration tool and
other issues with other communication traffic. In addition, the reporting of
the CAN bus-off event to the application was incorrect, such that when the
CAN bus-off condition no longer existed, the platform would still report a
CAN bus-off event in progress.
Now, decoding of the CAN bus-off event has been corrected, such that
CAN message transmissions are no longer delayed and the CAN bus-off
condition is correctly reported to the application.
• Correction to handling of signed signals in CANdb transmit block
Previously, the CANdb transmit block would incorrectly pack signed

negative numbers into the CAN message for transmission. The CANdb
transmit block would incorrectly and indirectly clip the negative value to
zero before packing the value into the CAN message for transmission.
Now, the CANdb transmit block no longer clips the signed number to zero
before packing into the CAN message for transmission.
• Correct parsing of CANdb files
Previously, the CANdb parser could not understand some forms of the
embedded CANdb SIG_KIND_ statement resulting in both the CANdb
receive and transmit block not showing the requested message signals
as inports and outports.
• Changes to handle non-correctable Flash errors during power-on

for A450, M460 and M461 ECUs
If power is removed during a reprogramming session, or while the

application had requested non-volatile data be written to Flash, then the
Flash memory may be left in an indeterminate state. The Flash memory

Change log
implements an error detection and correct scheme (ECC) where by single

bit errors are corrected but double bit errors cause the processor to raise
an exception. A Flash memory location left in an indeterminate state is
likely to cause the processor to raise an exception.
Previously, the platform software would catch this exception and reset the
ECU. If power were accidentally lost during a Flash operation, this could
result in the ECU appearing to be working in reprogramming mode, but
to be inactive in application mode. Reprogramming the ECU would not
rectify the failure if the adaptive or diagnostic trouble code non-volatile
Flash data groups were affected.
Now, the platform software recovers from non-correctable errors while

reading Flash after the ECU is powered on, avoiding the reset. Flash errors
in the application or calibration Flash groups are corrected when the ECU
is reprogrammed. Flash errors in other groups are corrected the next time
the application requests Flash to be updated.
3.25. Release 1.7.4

Release labelled release-1.7.4 from 14 January 2009. This release is marked as general

compatible upgrade
C-API No CRs No CRs Yes No
Gateway No CRs No CRs Yes No
Sim-API No CRs No CRs Yes No

Target ECU

• Added support for M461-00 ECU target
See the technical specification regarding the M461-00 for details about the
functional capabilities of the ECU. The M461 ECU is similar to the M460
ECU, with the following differences:
Accelerometer and gyroscope

The unit is fitted with a 3-axis accelerometer and a 3-
axis gyroscope.
Sensor power supply

There are 2 additional sensor power supplies, a total
of 4.

Change log
Synchronised variable frequency output

This feature is not available on the M461 target
because the injector outputs of the M460 are no
implemented on the M461. The M461 target provides
low side PWM outputs or digital outputs on the
equivalent pins (A1, A11, A21 and A31).
High side switch

This feature is not available on the M461 target.
Battery voltage monitoring and ECU protection

High side diagnostic weak pull up switch

I/O channel changes

The following channels are not available any more
because they are being reused for other purposes
(e.g. accelerometer and gyro):
• analogue input pins A8, A6, C7, C17, C39, C40 and
C27;
• thermocouple analogue input pins A13+A3 and

A14+A4;
• cold junction temperature analogue input (internal

— related to the thermocouple inputs);
• digital input pin A8;
• digital output pin A18.

3.26. Release 1.7.3


compatible upgrade
Sim-API No CRs 1227 (VI), 1225 (VI) Yes No


Change log

developer software.
• Reading the boot code major version number
The boot code major version number is different for each ECU target. This
number is available for reading, in case the application needs to verify
what target it is running on.
• Added support for Signal Checks library blocks
Affects Sim-API
The following Simulink library blocks are supported on A450

and M4xx targets: put_SignalGapDetection, put_SignalPrepare and
put_SignalValidate.
Target ECU

• Added support for M460-00 ECU target
See the technical specification regarding the M460-00 for details about the
functional capabilities of the ECU. The M460 ECU is similar to the A450
ECU, with the following differences:
Battery voltage monitoring and ECU protection

The platform software is now responsible for turning
off outputs when the battery voltage falls below 7.5V
and re-enabling the outputs when the battery voltage
raises above 7.75V (on the A450, the application
software was required to monitor the battery voltage
and turn the outputs off and on accordingly).
High side diagnostic weak pull up switch

The M460 makes available a switchable high side
weak pull up. The resistor works in conjunction with
the permanent weak pull down resistors in parallel
with all the low side outputs to cause all the outputs to
float around half battery voltage. The internal voltage
monitor channels can be read to determine if any
output is short circuited to battery or ground, or any
load is open circuit.
Over-current trip reset

The internal channels for manipulating the over-
current trip latches have been removed and replaced
by a Simulink block and C-API function to make the
interface cleaner.

Change log
Unlike the A450, it is not necessary to initialise

the over-current trip hardware in the application,
the platform software performs the necessary
initialisation.
A31 configuration switch

The internal channel for setting the configuration
of pin A31 has been removed and replaced by
a Simulink block and C-API function to make the
interface cleaner.
Additional digital input channels

Digital input pins C27, C29, C39 and C40 are
available in addition to the digital input pins provided
by the A450.
Additional monitor channel for the common ground pins

External ground monitor for the common ground pins
C9 and C19 is available for diagnostic purposes.
Additional monitor channel for the high side switch state

A monitor to determine the high side switch state is
available for diagnostic purposes.


developer software.
• Incorrect port type setting in mdlSetInputPortDataType for

put_calmap2d block
Previously, some applications showed Simulink raising an error related to

signal line going into the second port of put_calmap2d block.
Now, the error should not occur anymore.
• Change in API name for function pss_set_switch()
Affects C-API
To support the extended diagnostic capabilities of the M460, the

pss_set_switch() function is now deprecated. The function will be removed
from the C-API in a later release. The function has been replaced by
pss_set_safety_switch().
Calibration


Change log

software.
• Correct ASAP2 file generation for some DDE names
Previously, capitalised DDE names like TRICKLE_CHARGE_IT_NO

would not be correctly resolved to an address in the ASAP2 files generated
by a model build. In turn, the ASAP2 file would be read by ATI Vision but
Vision would silently ignore the error and the remainder of the ASAP2 file,
resulting in a confusing situation.
Now, capitalised DDE names are correctly resolved in ASAP2 files (which
are then subsequently read correctly by ATI Vision).
Examples

• Extended io_demo example application
Affects C-API
It includes a brief description on how to use the over-current trip reset.
It contains a basic description on how to run the hardware diagnostic on

loads connected to the actuator supply outputs provided by the ECU.
decoding.
• Actuator supply disabled when running reprogramming software
Previously, high side switch was not controlled by reprogramming

software, resulting in the actuator supply channels (A19, A29, A39, A40)
being set to battery voltage.
Now, reprogramming software forces the high side switch open, which
disables the actuator supply channels. Note, the reprogramming software
runs when the unit is powered up with FEPS line asserted.
Note
• Correction to A450 digital output pin selection

Change log
When utilising pins A5, A15, A25, A31, A35, C5, C10, C15 and C20
as digital outputs in either the Simulink blockset or C-API, the platform
software would drive the incorrect pin. When utilising the pins as PWM
outputs (or in the case of A31 as an injector output), the platform software
would drive the correct pin.
• Renamed synchronised PWM output channels
Affects Sim-API
The channels displayed on the Synchronised PWM output drop down

menu have been renamed. Application models developed with previous
releases need to have these channels re-selected on the block mask.
3.27. Release 1.7.2

engineering meaning the release has had minimal testing and is intended to trial new features
for the purposes of feedback. The following table provides quick access to each of the
changes.

compatible upgrade
3.28. Release 1.7.1

Release labelled release-1.7.1 from 24 September 2008. This release is marked as

compatible upgrade


developer software.

Change log
• Added C-API interface to OpenECU library
Affects C-API
The addition includes:
C-API User Guide

Included as HTML or as PDF, the guide details
the OpenECU C-API package. Of note is section 3,
named “Quick Start”, which introduces the interface
for new users, showing them how to create and build
a C application which reads an analogue input and
drives a PWM output based on the analogue input
level.
OpenECU Library
Included is a library (with associated C header
files) which when linked with an application provides
access to the target ECU functionality.
C-API Interface Tool

Included is a tool which helps generate the necessary
data definitions for linking an application with the
OpenECU library, and to generate ASAP2 files for
accessing the application while its running on the
target ECU.
C-API Example Sources

Included are examples which show how to use
the analogue and digital I/O features, CAN and
J1939 messaging features, non-volatile and adaptive
memory feature and some of the utility functions.


developer software.
• Updates to match C-API
Affects Sim-API
The Simulink/RTW blockset has been updated to match the C-API (for the
A450-00) and will continue to match the API in the future.
Target ECU

• Removed C29 from the A450 I/O set

Change log
Previously, pin C29 was listed as a digital and frequency input in the
technical specification. This was incorrect, pin C29 is unused.
Now, pin C29 is listed as unavailable.
3.29. Release 1.7.0

Release labelled release-1.7.0 from 11 June 2008. This release is marked as general

compatible upgrade

Calibration

software.
• Added support for the scale and offset columns in the data
dictionary files
Affects Sim-API
decoding.
• Added a synchronised PWM output block

(pdx_PWMSynchronisedOutput)
Affects Sim-API
This block allows the model to generated a pair of PWM signals, where
the second PWM signal is synchronised to the first. Currently, this block
is supported on the A450-00 target only.
• Added an output driver control block (pss_OutputControl)
Affects Sim-API
This block allows the model to control the operation of the output drivers.
Previous targets (G400, G800, G850) automatically turned on the output

Change log
drivers regardless of model state. The output control block allows the
model to control whether the output drivers are turned on or off. Currently,
this block is supported on the A450-00 target only.
Target ECU

• Added a new hardware target, the A450-00
Affects Sim-API
A new A450-00 target has been added to the list of supported OpenECU
targets. The A450-00 hardware is designed for emissions control, but
can be used for numerous applications. Some OpenECU functionality has
changed for the A450-00 target.
The target hardware runs in two modes: application mode and

reprogramming mode. The mode is selected on power by based on the
voltage applied to the FEPS pin. The range of FEPS voltage has been
extended on the A450-00 to allow the selection of the following modes:
application mode, reprogramming mode (using CCP settings taken from
the application), and reprogramming mode (using default CCP settings).
The target has a dedicated output pin for flash codes. The output can be
connected to a bulb or lamp and the ECU will cause the bulb to flash a
code. The code converts into a 3 digit number which gives an indication
of the ECU's state (for instance, the flash code may tell the user that the
ECU is running in reprogramming mode).
The target range of PWM and frequency inputs differs from other targets.
The target can measure frequency signals and drive PWM signals in the
range [0.5, 10000] Hz.
The A450-00 target does not support battery backed RAM. The non-
volatile memory blocks raise an error if storage to battery backed RAM
is selected.
The following blocks do not support the A450-00 target:
• Any of the angular driver blocks, e.g., pan_EngineConfig.
• Support for the ATI memory emulator, e.g.,

pem_AddRateForAtiEmulator.
• Some of the input measurement blocks, specifically: pdx_PeriodInput,

pdx_QuadratureDecode, pdx_QuadrateDecodeAndFrequencyInput,
and psp_SpiInput.
• Some of the output driver blocks, specifically:

pdx_StepperMotorOutput, pdx_SteppedOutput and psp_SpiOutput.
• Any of the Tunes Simulink blockset, e.g., ppp_Configuration.

Communications

Change log

ISO-15765 over CAN.
• Removed limits on the number of receive and transmit CAN

messages
Affects Sim-API
Previously, each target has a maximum number of receive or transmit

messages. The maximum number would limit the messaging capability of
a model.
Now, all targets are limited in the number of receive and transmit
messages only by the size of memory of the target.
decoding.
• Blocks which work with analogue inputs have changed output range
Affects Sim-API
OpenECU now supports targets with varying levels of conversion

resolution. The G400 and G800 support unsigned 10-bit conversions; the
G850 supports unsigned and signed 10-bit conversions; and the A450
supports unsigned 12-bit conversions. There may be other targets in the
future with varying conversion resolution.
To clarify the interface across all targets, all blocks which provide analogue
conversion, generate their results as if the conversion were 0 to 1023 full
scale for unsigned inputs, and -1024 to 1023 full scale for signed inputs.
This change affects the following blocks: pai_AnalogInput,

pai_BasicAnalogInput, pan_PrimaryAngularCounts,
pan_SecondaryAngularCounts.
3.30. Release 1.6.4

Release labelled release-1.6.4 from 13 March 2009. This release is marked as general

compatible upgrade
C-API No CRs 2169 (W), 2062 (W) Yes Yes, see:
2169 (W),
2062 (W)
Gateway No CRs 2169 (W), 2062 (W) Yes Yes, see:
2169 (W),
2062 (W)
Sim-API No CRs 2173 (W), 2169 (W), 2062 Yes Yes, see:
(W), 1995 (W), 2169 (W),

Change log

compatible upgrade
1958 (W), 1228 (VI), 1217 2062 (W)
(VI), 1211 (VI)

Code generation

• Add support for Diab compiler version 5.5.1.0
Affects Sim-API
Support has been added for Diab v5.5.1.0 (existing support for Diab v4.4b
has been retained). See the RTW settings for OpenECU and updated
installation instructions for more.

Calibration

software.
• Correct size of DAQ lists in INCA ASAP2 generation
During a model build for the G850 target, OpenECU would generate an
INCA ASAP2 file and specify the length of the DAQ lists as 16 long, but
the DAQ lists were 15 long. This resulted in INCA generating the following
log message:
ECU reports 15 ODTs in DAQ 3 but 16 are reported as available
in your QPBLOb. Please check the ASAP2 file.
Code generation

• Correct handling of Simulink MAX block when generating code
Previously, RTW would appear to leave out an RTW C header file when
generating the template makefile if a MAX block was used in the model.
The end result was a compilation error during a model build.
Now, the OpenECU build process will workaround this issue by including
the missing header file.

Change log
• MATLAB R14.2 build fails because of issue in TLC file of

pan_KnockFeedback block
Previously, MATLAB R14.2 build fails with the pan_KnockFeedback block.
Now, MATLAB R14.2 builds correctly with the pan_KnockFeedback block.
Communications

ISO-15765 over CAN.
embedded CANdb SIG_KIND_ statement resulting in both the CANdb
receive and transmit block not showing the requested message signals
as inports and outports.
• Extend range checking of CANdb files to include J1939 message

lengths
Previously, when the blockset was presented with a J1939 CANdb file the
supporting tool would raise an error regarding the length of some J1939
messages (which can be between 0 and 1785 bytes in length, compared
to between 0 and 8 bytes in length for CAN messages). The error was
correctly caught but not presented to the user.
Now, the blockset accepts J1939 based CANdb files.
• User guide improvement
Affects Sim-API
The J1939 section of the user guide has received one minor update for
clarification.
decoding.
• Correction to build when multiple frequency input blocks are

present
Previously, an undocumented feature of OpenECU which creates

calibrations for each frequency input block, would generate the same
calibration name for multiple frequency input blocks if the generic pin
naming was selected in the put_Identification block. This resulted in a
compile time error when building the model.

Change log
Now, the feature incorporates the pin number in the calibration name
making each automatic frequency input calibration unique.
Target ECU

• Correct handling of output drivers on some G850 ECUs
Previously, some G850 ECUs would incorrectly disable the outputs for
pins E4, E35, E36, E37, E38, E50, E52, E53, E54, E55, E67 C1, C13 and
C32 on a periodic basis, regardless of the requested enable state from
the application.
Now, the G850 enables the outputs as requested by the application. To

enable output pins E34 and E51, the application must set the internal
channel HBREN to zero. To enable output pins E4, E35, E36, E37, E38,
E50, E52, E53, E54, E55, E67 C1, C13 and C32, the application must set
the internal channel INJ_ENABLE to zero. Both HBREN and INJ_ENABLE
are configured by the platform to enable outputs after the ECU is powered
on (prior to the application running).
Note
• Correct unreliable detection of FEPS voltage on some G850 ECUs

during power up
Previously, some G850 ECUs would incorrectly determine the FEPS

voltage and start reprogramming mode rather than application mode.
Now, the G850 correctly determines the FEPS state during power on.
Note
3.31. Release 1.6.3


Change log

compatible upgrade
Sim-API No CRs 1206 (VI), 1194 (VI), 1187 No, see: No
(VI), 1187 (VI) 1194 (VI)

decoding.
• Improve frequency resolution on MIOS channels
Previously, the frequency fractional part on MIOS channel was discarded.
Now, the frequency fractional part is within a precision of 1/32 Hz.
Memory emulation
Some ECUs support memory emulators, a device to up load information from

the ECU, such as application variables or displayables, with significantly
higher bandwidth than CCP.
• Correct error when building for the ATI M6 emulator (G400 only)
Previously, when building a G400 model for use with an ATI M6 emulator,
the build would fail with the error message:
Error: could not import model image file 'model-name_small.s37' into

the ATI Vision strategy file 'model-name.vst'.
Now, the build completes without error.
Target ECU

• G850 channel "IMRC4 monitor" as "IMRC monitor"
Previously, the channel was called "IMRC4 monitor".
Now, the channel is called "IMRC monitor".

Change log
Note
After opening a model that uses the “IMRC4 monitor” channel, the
corresponding psp_SPIInput block channel must be changed to
“IMRC monitor”.
• Angular functionality blockset is supported on G850 target again
This affects the following blocks: pan_EngineConfig,

pan_InitialFuelPulse, pan_InjectorDrive, pan_UpdateInjectorDrive,
pan_CoilDrive, pan_EngineSpeed, pan_EngineAccel,
pan_PrimaryAngularCounts, pan_SecondaryAngularCounts.
However, knock detection functionality blockset is not supported yet.
3.32. Release 1.6.2


compatible upgrade
C-API 1139 (VI) 1171 (VI), 1168 (VI), 1118 Yes Yes, see:
(VI) 1168 (VI),
1118 (VI)
Gateway 1139 (VI) 1171 (VI), 1168 (VI), 1118 Yes Yes, see:
(VI) 1168 (VI),
1118 (VI)
Sim-API 1139 (VI), 1120 (VI), 1120 1197 (VI), 1190 (VI), 1190 No, see: Yes, see:
(VI) (VI), 1171 (VI), 1170 (VI), 1168 (VI),
1170 (VI), 1168 (VI), 1159 1144 (VI) 1118 (VI)
(VI), 1155 (VI),
1145 (VI), 1144 (VI), 1143
(VI), 1135 (VI),
1118 (VI), 1118 (VI), 1115
(VI)

Communications

ISO-15765 over CAN.
• Added a new CCP driver

Change log
The CCP driver has been re-written in an effort to improve the response
time of the ECU to calibration commands. Previously, at high CPU loading,
the model was given preference when both the model and CCP work
needed to be done, and this meant that CCP response messages could be
delayed and miss their deadlines, causing the calibration tool to complain.
Although this situation can still occur (there is only so much the ECU can
do in a period of time), this problem should be less apparent.
The driver matches the functionality of the existing driver with most CCP
commands, but some CCP commands have been dropped (see the User
Guide, section “CCP compliance” for details).
• Added a subset of SAE J1939 support to the Simulink blockset
Added a subset of SAE J1939 support to the blockset. The blockset

set supports a fixed J1939 node address and supports the transport
mechanism for large messages, as well as a few of the diagnostic
messages, through the following blocks:
pj1939_Configuration
Use this block to declare that J1939 will be used on a particular CAN
link, and to define other characteristics of the J1939 messaging.
pj1939_PgRequested
Use this block to determine if a J1939 node has requested a PG.
pj1939_PgReceive
Use this block to receive a fixed-length J1939 and extract the contents
of that message. Similar to the pcx_CANReceiveMessage block.
pj1939_PgTransmit
Use this block to pack data into a fixed-length J1939 message and to
transmit it. Similar to the pcx_CANTransmitMessage block.
pj1939_Dm1Decode
Use this block to determine if a DM1 message has been received from
a J1939 node, and to extract the state (active or not) of a DTC (based
on the SPN, FMI and CM values of the DTC).
pj1939_Dm1Transmit
Use this block to transmit a DM1 message containing the currently
active DTCs, from a table of DTCs declared in a pdtc_Table block.
pj1939_Dm2Decode
Use this block to determine if a DM2 message has been received from
a J1939 node, and to extract the state (previously active or not) of a
DTC (based on the SPN, FMI and CM values of the DTC).
pj1939_Dm2Transmit
Use this block to transmit a DM2 message containing the previously
active DTCs, from a table of DTCs declared in a pdtc_Table block.

Change log
• Added support for Diagnostic Trouble Codes (DTCs)
Added support for Diagnostic Trouble Codes (DTCs), which provide a

simple means of keeping track of a list of detected faults. Support is
provided to retain the list of faults across power cycles. The functionality
is provided through the blocks:
pdtc_Table
Use this block to declare a table of DTCs. The table contains a list of
DTCs which can be stored in non-volatile memory and acted on as a
whole (for instance, to clear all DTCs, or to send a SAE J1939 DM1
message).
pdtc_DiagnosticTroubleCode
Use this block to define a DTC. The DTC has a type (of which there is
currently on a J1939 type of DTC), that defines the content of the DTC.
J1939 DTCs have a SPN/FMI/CM identifier which uniquely identifies
the DTC, along with the state of four lamps. The DTC has a state
which, depending on the DTC type, determines whether the DTC is
active or not.
pdtc_ClearAll
Use this block to set all DTCs in a DTC table to the clear state.
pdtc_InactivateAll
Use this block to set all DTCs in a DTC table to the inactive state.
pdtc_Memory
Use this block to record the tables of DTCs in non-volatile memory.

Calibration

software.
• Corrections to allow INCA to work with the G850
Three things have changed to support INCA on the G850.
1. The firmware has been updated to accept and respond to the CCP
GET_S_STATUS and SET_S_STATUS commands. This change affects
the OpenECU firmware and OpenECU developer software.
2. The initialisation of calibration data on developer units has changed to

support INCA. This change affects the OpenECU developer software.
3. The installer has been updated to include PROF support files for each
of the OpenECU targets (G400, G800 and G850). This change affects
the OpenECU developer software.

Change log
Note
Communications

ISO-15765 over CAN.
• Remove CCP reset option
Previously, there was an option in the pcp_CCPConfiguration block to

allow the ECU to reset when the calibration tool completes download of
the calibration data.
Now, since the CCP reimplementation (CR 1139 (VI)), this option is no
longer supported and has been removed from the blockset. When a model
is opened in Simulink, there will an error, similar to:
Warning: pcp_CCPConfiguration block (mask) does not

have a parameter named 'pcpl_honour_reset'.
This can be safely ignored. When the model is saved, closed, and
reopened, the error message will no longer be present.
• Issue when entering block mask parameter in both

pj1939_PgReceive and pj1939_PgTransmit
Previously block mask raised an error when trying to use the last bit of
the message.
Now both blocks may use last bit of the message.
• Reintroduce the extended list of CAN baud rates
Previously the selectable set of CAN baud rates was 1000, 500 and 250
kBps.
Now the selectable set of CAN baud rates is as follows: 1000, 500, 250,
125, 100, 83.333, 62.5, 50 and 33.333 kBps.
Examples

• Extend list of example models to cover G850 target

Change log
Previously there were example models for G400 and G800 targets.
Now there is an equivalent list for G850 target.
decoding.
• HCS12 UNI and LSD drivers
Previously, output signal generated with latest valid duty-cycle, after input
signal had become stationary.
Now, output signal is set to either low or high voltage, after input signal
had become stationary. High if latest valid duty-cycle had the signal high
for most of the time, low otherwise.
Installation

before OpenECU.
• Correctly install INCA PROF configuration files
Previously, if an INCA installation had its PROF files removed, then the
OpenECU installer would not correctly install OpenECU PROF files if
asked to.
Now, the OpenECU installer will install the PROF configurations in all
circumstances.
• Remove relative path names from installer ZIP files
Previously the openecu_release_note.pdf was stored in the installer ZIP

files with a relative path name, i.e. ../doc_user/openecu_release_note/
openecu_release_note.pdf
Now installer ZIP files contain no relative path name.
• Correct simulation behaviour of the adaptive array block

Change log
Previously, the array block would incorrectly initialise the working copy of
the default data, if the default data was a vector of floating point values.
Now, the working copy is correctly initialised.
• Correct simulation behaviour of the adaptive blocks
Previously, when an adaptive block was simulated, the working copy of

the default data was initialised to zero, rather than being initialised to the
default data. A reset to the block was required before the working copy
was initialised to the default data.
Now, when an adaptive block is simulated, the working copy is initialised

to the default data at the start of the simulation.
• Improve documentation
Corrected and improved description for PNV feature. Added CCP default
baud rate value. Added example for controlling PWM output transition by
toggling duty cycle between 0 and 1.
Target ECU

• General improvements to the user documentation
Improved the labelling of various coil, injector and knock diagrams, added
a little more information to the FAQ, and added a table of software
components against version.
• Added details on drop down menu for pai_AnalogInput and

pan_EngineConfig blocks, in G580 target
Previously, when put_identification block had “pin naming” mask

parameter set to “Generic pin naming”, all AIN Reference Voltage
channels (HBVR1, HBVR2 and HBVR3) had the same description.
Now the specific HBVRx channel appears in the drop down menu
description.
• HCS12 software
The bootloader can be reflashed via CCP protocol.
In previous release, reflash over CCP protocol was only supported for
HCS12 application code.

Change log
Note
• HCS12 documentation
The documentation related to HCS12 software has been improved.
3.33. Release 1.6.1

Release labelled release-1.6.1-hcs12-1.0 from 27 March 2008. This release is

compatible upgrade
C-API No CRs 1118 (VI) Yes Yes, see:
1118 (VI)
Gateway No CRs 1118 (VI) Yes Yes, see:
1118 (VI)
Sim-API No CRs 1128 (VI), 1127 (VI), 1126 Yes Yes, see:
(VI), 1118 (VI) 1118 (VI)

Target ECU

• Added support for a new target, the G850-00
Additional changes to support the G850 hardware target. This release is

intended for internal testing only, and as such, no more detail is provided
here about the release.



Change log
developer software.
• Removed occasional reset during ECU initialisation
Previously, the controller would reset during initialisation, prior to running

the model. This has been corrected.
• Corrected boot duration from put_Reset block
• Corrected put_Reset block type of outport for logical signals
The logical outports for the put_Reset block were always typed as
double. This ignored the RTW optimisation setting for logical signals. The
put_Reset block now adheres to the RTW optimisation setting, and will
change the outport types to boolean if the optimisation is set.
Target ECU

• HCS12 software
G850 unit has two HCS12 CPUs, named LSI-HCS12 and eQuizzer-
HCS12. The software running an each HCS12 is composed by an
application and a bootloader, the latter is the same on both CPUs.
The bootloader runs when either FEPS line is asserted or the CRC test on
the application code fails. It is capable of reprogramming the application
code but not itself.
eQuizzer-HCS12 should be flashed with an application called eQuizzer.
LSI-HCS12 may be flashed with either UNI or LSD (Low Side Drive) driver
application.
Note
3.34. Release 1.5.9

Release labelled rel_install_1_5_9 from 7 March 2006. This release is marked as

Change log

compatible upgrade
Sim-API No CRs 498 (VI), 497 (VI), 496 Yes No
(VI), 495 (VI),
494 (VI), 493 (VI), 491
(VI), 480 (VI),
468 (VI), 383 (VI)


developer software.
• Improve CPU loading calculation
Previously the CPU loading calculation for ASAP2 entry

mpl_cpu_loaded was inaccurate at higher CPU loading. Although
reasonably accurate at lower CPU loading, the value of
mpl_cpu_loaded was overestimated as the CPU loading increased.
Now, a more linear CPU loading calculation has been implemented,

resulting in an accurate estimate of CPU loading regardless of the actual
CPU loading.
• Update contact details in the documentation, models and support

tools
• Improve CPU loading calculation
Calibration

software.
• Incorrect ASAP2 generation of group sub-system names
Previously, any valid sub-system name was passed to the ASAP2 file
with minimal change (spaces were changed to '_' characters). The ASAP2

Change log
specification only allows certains characters to be used for ASAP2 object

names (characters 'A' through 'Z', 'a' through 'z', underscore '_', numerals
'0' through '9', points '.' and brackets '[' and ']'). This subset is less than the
allowed characters for sub-systems. Copy names with characters not in
the allowed set resulted in some calibration tools rejecting the ASAP2 file.
Now, OpenECU changes the sub-system names as they appear in the

ASAP2 file so that any character not allowed is replaced with the character
'_'. This means the sub-system names that appear in the model and
ASAP2 file may differ.
• Improve CCP DAQ message timing under heavier CPU loading
Previously, the DAQ message list transmission could be interrupted by

higher priority tasks, including model tasks. If those higher priority tasks
occurred often enough and for long enough durations, the time between
consecutive DAQ messages could be larger than the CCP standard
allows.
Now, the DAQ message list transmissions occur in a task with higher
priority that the model tasks, resulting in messaging that mets the CCP
standard timeout value.
• Incorrect ASAP2 generation
Previously, if an ASAP2 description was generated by the data dictionary

but is not available in the compiler MAP file, then an error occurs in the
resulting ASAP2 file. This can occur on 1-d and 2-d maps that have an
interpolation point.
Now, only data dictionary entries that have a corresponding memory

location in the compiler MAP file are placed in the ASAP2 file.
Communications

ISO-15765 over CAN.
embedded CANdb BA_ statement resulting in both the CANdb receive
and transmit block not showing the requested message signals as inports
and outports.
Examples

• Correct fixed angular example models to remove build warnings

Change log
Previously the fixed angular example models would generate two

warnings about the fad_pri_counts and fad_sec_counts signals
because they had not been declared as ExportedGlobal in the model.
Memory emulation

• Include boot code image in an M6 build
Target ECU

• Updated technical specifications to show the crank input as VRS

and Hall effect
3.35. Release 1.5.8

Release labelled rel_install_1_5_8 from 28 August 2006. This release is marked as

compatible upgrade
Sim-API No CRs 489 (VI), 484 (VI), 308 (VI) Yes No


developer software.
• Incorrect web page links in documentation
Recently the OpenECU web page has been updated and reference links
have moved. Web page links in the documentation were not updated at
the same time as web page.

Change log
decoding.
• Improve the time to initially synchronise to the crank trigger wheel
Previously, the platform would synchronise to the crankshaft wheel by

detecting two missing tooth regions with the correct number of teeth
between them. This resulted more crank revolutions before injector and
coil pulses were generated.
Now the pan_EngineConfig block provides two mechanisms: the existing

method and a quicker method which only needs to detect a single missing
tooth region before declaring crankshaft wheel synchronisation.
Installation

before OpenECU.
• Uninstall of tunes does not work
Previously, uninstalling a version of the Developer Software that had

Tunes functionality would result in some files being left in the installation
directory relating to Tunes functionality.
3.36. Release 1.5.7

Release labelled rel_install_1_5_7 from 23 February 2006. This release is marked as

compatible upgrade
Sim-API No CRs 488 (VI) Yes No

Calibration


Change log

software.
• Tune blocks in atomic sub-systems fail to build
Previously, if a tune block in an atomic sub-system that was generated by

RTW into its own file, the OpenECU build would fail.
3.37. Release 1.5.6


compatible upgrade


developer software.
• The create_openecu_model command can sometimes fail
Previously, if the model name supplied to the script matched that of a build
in function, the function would fail to create the necessary OpenECU files.
For instance, the model name 'doc' would cause the script to fail.
decoding.
• The quadrature decode block outputs incorrect count of edges
Previously, the quadrature decode block output an incorrect count of

edges seen since the last iteration. This defect was introduced at version
1.4.0 of the developer software.

Change log
3.38. Release 1.5.5


compatible upgrade

• The pnv_AdaptiveScalar block does not simulate correctly
Previously, the block would incorrectly read the adaptive increment, adapt
and reset inports resulting in a block which would not adapt under
simulation.
Now, the block correctly reads the adaptive increment, adapt and reset
inports, correctly determining the value of each.
3.39. Release 1.5.4

Release labelled rel_install_1_5_4 from 12 December 2005. This release is marked

compatible upgrade
Sim-API 269 (VI) 474 (VI), 473 (VI), 472 (VI) Yes No

Memory emulation

Change log

• Add support for the ATI M6 Memory Emulator
ATI memory emulator support has been added to the software. To make
use of the M6, add up to four pem_AddRateForATIEmulator blocks to the
model, set the sample rate of each to match the sample rates already
present in the model and set the number of ASAP2 items accordingly
(maximum of 256 items per rate). The maximum number of sampled
items can be increased for a model rate by adding more than one
pem_AddRateForATIEmulator block to the same model rate.
The platform automatically detects the presence of a tab board or M6 and

adjusts its behaviour accordingly. If a tab board is present, the behaviour
is the same as previous versions. If a M6 is detected, the platform will
communicate with the M6 for data acquisition but will not honour requests
to write adaptive data to Flash.
Regardless of whether a tab board or M6 is connected, CCP will

still be active when the model runs, unless CCP is disabled in the
pcp_CCPConfiguration block.

Calibration

software.
• Incorrect generation of ASAP2 files under MATLAB R14.x
Previously, the ASAP2 generation script failed due to some of the more
recent R14.x blocks.
Installation

before OpenECU.
• The installer says only MATLAB R12.1, R13.0 and R13.1 are
supported
Previously, the installer would tell the user that only R12.1, R13.0 and
R13.1 were supported, if it could not find a version of MATLAB to integrate
with, even though R14.1 and R14.2 are supported.

Change log
Target ECU

• The technical data sheets show knock sensor inputs as

unsupported
The technical data sheets have been updated to show support for the
knock sensor pins.
3.40. Release 1.5.3

Release labelled rel_install_1_5_3 from 22 September 2005. This release is marked

compatible upgrade

Calibration

software.
• Incorrect typing of ASAP2 variables
Previously, if the type of a DD element did not match any of uint8_T,

int8_T, uint16_T, int16_T, uint32_T, int32_T, BOOL,
real_T then the type of the ASAP2 equivilent has a floating point type.
This is not always the case.
Communications

ISO-15765 over CAN.
• Incorrect unpacking of signed CANdb signals

Change log
Previously, signed CANdb signals were incorrecly unpacked from CAN

messages if the signal became negative.
3.41. Release 1.5.2

Release labelled rel_install_1_5_2 from 6 September 2005. This release is marked as

compatible upgrade

Communications

ISO-15765 over CAN.
Previously the parser would expect a plain integer at the end of an attribute
statement in the CANdb file but a quoted string would be valid as well.
This resulted in a cryptic message when a model (that refered to a CANdb
file of this form) was updated or built.
3.42. Release 1.5.13


compatible upgrade
Sim-API 620 (VI), 603 (VI), 597 632 (VI), 631 (VI), 630 No, see: Yes, see:
(VI), 586 (VI), (VI), 625 (VI), 618 (VI) 597 (VI)
581 (VI), 571 (VI)

Change log

compatible upgrade
623 (VI), 622 (VI), 621
(VI), 619 (VI),
618 (VI), 615 (VI), 594
(VI), 591 (VI),
590 (VI), 584 (VI), 570
(VI), 569 (VI),
568 (VI), 566 (VI), 559
(VI), 555 (VI),
553 (VI), 544 (VI), 537
(VI), 486 (VI)

Calibration

software.
• Derive ASAP2 array and map sizes based on workspace data
When a model is loaded, the DDE files are read into the workspace. The
values of these DDEs in the workspace form the calibration values during
a build of a model. Up to now, the size of these arrays and maps defined
in the built ASAP2 file was based on information from the DDE files and
not from the workspace.
The size of arrays and maps defined by the ASAP2 file can now be taken
from either the DDE files or from the workspace. This feature is turned by
unticking the RTW option Re-read build list before building and ticking the
RTW option Derive ASAP2 array and map sizes from the workspace.
Code generation

• Add option to allow build to continue if ATI Vision strategy creation

fails
Previously, if generation of an ATI Vision strategy failed (for instance,

because the wrong version of ATI Vision was used), the build would stop.
Now, there is a new RTW option, Continue building if creation of ATI Vision
strategy file fails, which controls whether to stop or continue the build when
the strategy file generation fails.
Communications

Change log

ISO-15765 over CAN.
• Increased the number of selectable CAN baud rates
The selectable set of CAN baud rates has been changed from 1000, 500
and 250 kBps to include 125, 100, 83.333, 62.5, 50 and 33.333 kBps.
Note
• Explain how to setup two OpenECUs on the same CAN bus
Added details of how to configure two OpenECUs and ATI Vision to work
together, when both ECUs are new. See Appendix B, Supporting tools of
the OpenECU User Guide for more.
decoding.
• Added a new output block for generating pulses
Added a new block called pdx_SteppedOutput. The stepped output block

pulses an output channel until requested to stop. The block is intended to
be used with smart stepper motor devices in conjunction with additional
output blocks to control direction and step resolution.
• Addition of a non-volatile array block
Added the pnv_array block. This block is similar to the

pnv_adaptive_map1d block. It can store an array of values in non-volatile
memory, change individual elements of the array and read individual
elements out of the array (but does not interpolate entries as the
pnv_adaptive_map1d block does).
To support the new block, there is a new DDE type for arrays which uses
the v character in the DDE naming scheme (similar to the use of the c
character when declaring scalar calibrations).

Change log


developer software.
• Allow very basic models to be built
Previously, very basic models required some signals that RTW could not
optimise away before the model could be built completely.
Now, very basic models can be built without the need to add dummy
functionality.
• create_openecu_model does not work with MATLAB R14.1
Previously, some users have noted that create_openecu_model does

not work with R14.1. When run, MATLAB would report:
??? No method 'set_param' with matching signature found [...]

Error in ==> create_openecu_model at 369
set_param(cs, 'EnforceIntegerDowncast', 'off', ...
Now, the script has been updated to work with R14.1.
• MATLAB installation path may contain spaces
Previously, an OpenECU build would crash if accessing MATLAB that had

been installed to a location contains spaces in the path. This was detected
when using MATLAB ver R14.2.
Now, spaces in the MATLAB installation path are correctly interpreted

during the build.
Calibration

software.
• Correct generation of ASAP2 files for enumerated values
Previously, the generation of ASAP2 files for enumerated values was

incorrect. The ASAP2 file would contain a /begin COMPU_VTAB section
ended with /end COMPU_METHOD instead of /end COMPU_VTAB. Some
calibration tools tolerated this, others did not.

Change log
• Long model names can cause ASAP2 generation to fail
Previously, if a model had a long name, ASAP2 generation would fail.

MATLAB was shortening the name of a called function which included the
model name. This in turn meant MATLAB could not find the called function
and MATLAB would report an error.
Now, the ASAP2 generator uses a short function name which allows an
ASAP2 file to be generated, regardless of the model name size.
• Allow data dictionary files to define some mplc calibrations
Previously, CR 242 (VI) introduced a mechanism to modify some specific

OpenECU functionality not provided via the Simulink blockset. Then CR
442 (VI) introduced tigher checking of the data dictionary which would
reject data dictionary names introduced by CR 242.
Now, data dictionary entries which match the naming scheme of CR 242,
are not flagged in error when the data dictionary is read.
• Scalar tune block does not simulate correctly
Previously, the scalar tune block would not simulate correctly. The value
of the block's parameter was incorrectly retrieved from Simulink and this
incorrect value was written to the block's outport. This has been corrected.
Communications

ISO-15765 over CAN.
• Correct mistake in the pcx_CANTransmitMessage block description
• Update signal outports for the CAN receive blocks whenever a CAN
message is received
Previously, if OpenECU received two or more CAN messages of the same

ID between model iterations, when the model processed the CAN receive
block for that CAN ID at the next model iteration, the block would ignore
both messages and use data received during older iterations.
Now, under the same circumstances, the CAN receive block for that CAN
ID processes the last received message at each iteration.
• Revert changes made to improve CCP DAQ performance
Previously, CR 480 (VI) introduced a change to help improve the CCP

implementation of DAQ lists. It was found that under heavy CPU loading,
the DAQ list would be transmitted outside the timing requirements of

Change log
the CCP standard, causing calibration tools to show a warning or error

message. However, it has been reported that since the changes for CR
480, CCP messages from the ECU will not work correctly under heavier
CPU loading and full DAQ lists.
Now, the changes made for CR 480 have been removed. The CCP DAQ
list messages may be transmitted outside of the timing requirements of
the ASAP CCP standard.
• Disallow constant sample time CAN transmit blocks
Previously, the pcx_CANTransmitMessage and

pcx_CANdb_TransmitMessage blocks could both take inputs with a
constant sample time and end up as a block configured with a constant
sample time. In turn, RTW would optimise away the block and the built
model would not transmit a CAN message.
Now, both blocks are configured to disallow being assigned a constant

sample time and are not optimised away by RTW.
decoding.
• Correct mistake in the pdx_PeriodInput block description
• Improve documentation for the stepper motor block
The User Guide for the stepper motor block gave insufficient detail relating
to how the stepper block maintained the desired position for the stepper.
The User Guide has been updated to make this clearer.
• Improve documentation for the quadrature decode blocks
The User Guide for the quadrature decode blocks lacked a description
of what a quadrature encoder is, and sometimes gave insufficient details
regarding the quadrature signal and block workings. The User Guide has
been updated to address these issues.
• Correct some error messages relating to the pai_AnalogInput block
Corrected error messages relating to the minimum and maximum raw and
engineering parameters in the pai_AnalogInput block. If the minimum was
greater than the maximum, an incorrect error message was displayed.
• Correct documentation relating to the minimum PWM frequency

Change log
Previously, the User Guide and blocks relating to PWM output claimed a
minimum frequency of 10Hz or 2.9Hz. However, the minimum frequency
of the blocks is higher than this. Furthermore, the blocks did not correctly
clip the requested frequency to the minimum frequency possible. As
a result, incorrect PWM signals could be generated if the requested
frequency was below the minimum frequency possible.
Now, the minimum PWM frequency is set to 15.3Hz for all PWM blocks.
The minimum is tested against when the model is updated and when the
model is running on the target.
• Correct error in synchronisation to crank trigger wheels
Previously, CR 308 (VI) introduced a defect where by the platform

could incorrectly synchronise to a 40-2 or 60-2 crank wheel when
configured for a 36-2 crank wheel. The platform would cycle between
the synchronised state and unsynchronised state while the crank wheel
turned. Synchronisation to crank trigger wheels with 1 missing tooth was
unaffected.
Now, the platform synchronises to a 36-2 crank wheel only when

presented with a 36-2 crank wheel pattern.
• Correct time out issue with the pdx_PeriodInput block
Previously, the period input block would incorrectly set the timed_out
port every 71 minutes.
Memory emulation

• Restrict M6 emulator functionality for the G400-01 target
The M6 memory emulator functionality has only been tested on the

G400-01 target. The User Guide has been updated to explain what targets
are supported and the pem_AddRateForATIEmulator block has been
updated to generate an error message if used in a model not targeting
the G400-01.
• Correct simulation behaviour for the pnv_Status block
Previously the pnv_Status block, under simulation, would always set

the check-sum outports to zero, regardless of the simulation check-sum
inports.

Change log
Now the pnv_Status block, under simulation, sets the outputs to the value
of the corresponding simulation inport.
• Clarify how adaption occurs in the non-volatile memory adaptive

blocks
The documentation was not clear about what data was adapted in the
PNV non-volatile memory adaption blocks. OpenECU adapts a copy of the
DDE declared in the Adaptive Scalar (default) or Adaptive Z Data (default)
mask parameter. If the same DDE appears in more than one block, then
OpenECU will adapt the same copied parameter more than once.
• Non-volatile memory adaptive map block mask parameters
Previously, when numerical values were directly inserted in the block

mask scalar, x-axis, y-axis and z-data parameters, a cryptic error was
issued at compile time, instead of having a clear error message when the
block parameters were entered. It was difficult for the user to understand
the root cause of the error.
Now, if numerical values are typed directly into the block mask an error
message is raised when the Apply or OK button is pressed in the block
mask. The user need to create a DDE item and use its identifier in the
mask parameter.
Target ECU

• Update environmental specifications and references in the user

guide and technical specification documents
The User Guide and Technical Specifications have been updated to

include new information relating to the environmental specifications for
each ECU. This includes new details on vibration, shock capability, IP
protection, EMC, and updates to some other existing details.
• G800 target has only 1 MiB of external Flash
Previously, the technical specification for the G800 claimed the target has
2 MiB of external Flash. This was incorrect, the G800 has only 1 MiB of
external Flash. The technical specifications have been corrected.
3.43. Release 1.5.12


Change log

compatible upgrade
Sim-API No CRs 550 (VI), 543 (VI), 540 Yes No
(VI), 478 (VI)


developer software.
• Free some Workspace memory for larger models
Previously, a mix of constant data from a model build was placed in

internal Flash (workspace) and external Flash (calibrations).
Now, to free some workspace memory, all constant data from a build is
placed in the calibration group.
Communications

ISO-15765 over CAN.
• Incorrect documentation for CANdb transmit block
Previously, the User Guide documentation for the CANdb transmit block
incorrectly refered to a sample time parameter of the block. There is no
sample time parameter; the block inherits its sample time.
Installation

before OpenECU.
• Incorrect behaviour of OpenECU installation process
Previously, the installer could prevent the user from completing the
installation if a compatible version of MATLAB could not be detected.

Change log
Target ECU

• Corrections to Simulink blockset and documentation for G800 pin

B42
Previously, the User Guide documentation listed B42 as a both supported

and unsupported, and the Simulink blockset allowed the user to select B42
as an output with a monitor feedback input. However, the G800 hardware
does not support pin B42.
Now the User Guide no longer lists B42 as supported and the Simulink
blockset does not allow the user to select pin B42 or its corresponding
monitor.
3.44. Release 1.5.11


compatible upgrade

• Adaptive data not retained in large models on a G800
Previously, if the model used large amounts of RAM on a G800, the data
would not be retained across power or reset cycles. This resulted in the
adaptive data being reset to its default values on power up.
3.45. Release 1.5.10

Release labelled rel_install_1_5_10 from 13 July 2006. This release is marked as

Change log

compatible upgrade
Sim-API 531 (VI), 530 (VI), 529 542 (VI), 541 (VI), 539 Yes No
(VI), 527 (VI), (VI), 533 (VI),
525 (VI), 524 (VI), 523 532 (VI), 528 (VI), 526
(VI), 522 (VI), (VI), 520 (VI),
521 (VI), 508 (VI), 503 (VI) 519 (VI), 518 (VI), 517
(VI), 516 (VI),
515 (VI), 514 (VI), 512
(VI), 507 (VI),
506 (VI), 502 (VI), 501
(VI), 500 (VI),
499 (VI), 479 (VI)

Calibration

software.
• Extend RTW options to control if build list is re-read prior to a build
Whether the build list and data dictionaries are re-read prior to a build or
not is controlled through an RTW option.
• Add enumerations to the data dictionary scheme
Enumerations can now be specified for data dictionary entries and are
extracted to the ASAP2 file. More information can be found in section 5
of the user manual.
• Added various automatic ASAP2 strings
OpenECU generates a number of automatic ASAP2 entries which extract

various information from the model. These entries are treated as text and
can be viewed via the calibration tool:
Name Description
mpls_model_build_time The date and time when the model was built.
mpls_model_copyright The copyright notice for the model taken from the
put_Identification block.

Change log
Name Description
mpls_model_description The model description taken from the put_Identification
block.
mpls_model_name The name of the built model.
mpls_model_version The model version number taken from the put_Identification
block.
mpls_plat_build_time The date and time when the platform was created.
mpls_plat_copyright The platform's copyright notice.
mpls_plat_target The hardware target the model was built to be run on.
mpls_plat_version The version of the platform the model was built against.
• Extend RTW options to control ASAP2 generation
What ASAP2 files are generated at the end of a build and what is
contained in the ASAP2 file can be controlled through a number of RTW
options. The RTW options can be accessed by opening an OpenECU
model and selecting the menu option Simulation -> Simulation
parameters... then browsing to the OpenECU options under Real-
Time Workshop. More details are given in the User Guide.
• Add heirarchy of ASAP2 entries to ATI Vision ASAP2 file
Added a heirarchy of DDEs to the ATI Vision ASAP2 file. The heirarchy
can be navigated by model sub-system, by type (maps, scalars, etc.) and
by DDE prefix.
Code generation

• Extend RTW options to control whether model links are broken prior
to a build
Whether all model links are broken or not is controlled through an RTW
option. Breaking model links has been shown to save RAM with some
versions of RTW. This functionality is only available for MATLAB/Simulink
R12.1.
• Extend RTW options to control generation of build images
What build images (S-record files, Intel HEX files, etc.) are produced at
the end of an OpenECU build can be controlled through a number of RTW
options. The RTW options can be accessed by opening an OpenECU
model and selecting the menu option Simulation -> Simulation
parameters... then browsing to the OpenECU options under Real-
Time Workshop. More details are given in the User Guide.
Examples

Change log

• Added example of 2-d map lookup data dictionary entry
Previously, the manual only showed how to create DDEs for 1-d map
lookups.
Target ECU

• Add details for G400 pins J1-27 and J1-48 to documentation
Previously, the User Guide and technical specification showed pin J1-27
and J1-48 on the G400 target as unsupported but they were a selectable
outputs.
Note
The output on pin J1-27 latches when driven on.
• Enable G400 pins J1-56, J1-73 and J1-99 as digital outputs
Previously, the technical specification showed pin J1-99 as a digital output

but it was not available as a channel in the digital output block. Pins 56
and 73 were not previously available as digital outputs.
• Added constant current output monitor/feedbacks for G800 target
Added monitor or feedback fault information for the VPS (pin A39) output
on the G800 target.


developer software.
• Adhere to the RTW "generate code only" option

Change log
Previously, an OpenECU model build which had the RTW "generate code
only" option selected, would not stop after the code was generated and
would attempt to compile the model.
• Incorrect calculation of stack usage
Previously, the reported maximum stack usage (ASAP2 entry

mpl_max_used_stack) was under reported by a factor of 4.
Calibration

software.
• Allow data dictionary names that are all upper case
OpenECU previously disregarded data dictionary names that were

all upper case (e.g., MPL_UPPER_CASE_NAME). OpenECU now
generates ASAP2 entries for these DDEs if the DDE was declared as
exported global.
• Added note about ASAP2 conformance
• Added note about automatic ASAP2 generated items for adaptive

and tune blocks
• Tidy up the automatic DDE ppp_tune_trigger_store
The automatic variable has been renamed to use the mpl prefix, like
all other automatic ASAP2 entries. The variable is only automatically
generated if a Tune block is present in the model.
• Improve DDE file handling
Previously, all columns or fields in a DDE file had to be present, even if

they could be optional and even if they were never used (for instance, the
Offset field.
Now, the DDE fields or columns can be declared in any order so long as
the Name field appears first and at a minimum, the following fields must
be present (others are now optional):
Name Value Units Description Type Min Max
• Allow blank lines and comment lines in DDE files

Change log
DDE files may now contain blank lines and comment lines in much the
same way that unit files can. A comment starts the line using the --
characters. More information is given in section 5 of the User Guide.
• Improve DDE file handling
• Raise a warning if the mpl prefix is used in user DD files
The prefix mpl is reserved by the platform. Data dictionary files should
contain named entries using the mpl prefix (with the exception of a few
items).
• Incorrect or failed ASAP2 generation on larger models
Previously, MATLAB R12.1 and R13 silently dropped characters from

strings larger than 64Kb resulting in incorrect ASAP2 generation. This
does not affect R14.
Now, an intermediate workaround has been put in place which reduces

the string lengths on larger models.
Code generation

• Allow some Simulink blocks to work with OpenECU calibrations
Previously, some of the Simulink blocks that used OpenECU calibrations

would not result autogenerated code that would compile.
decoding.
• Always turn coil outputs off when engine stops turning
Previously, if the coil output was on when the engine stopped turning, the
coil output would not be turned off.
• Improve the speed at which crank synchronisation occurs
• Improve the crank synchronisation detection

Change log
Previously, crank synchronisation was detected by comparing the ratio of

the tooth duration immediately prior to the missing tooth region and the
missing tooth region.
Now, the ratio of the tooth immediately before and after the missing tooth
region and the missing tooth region are compared.
• Loss of spark/coil outputs on slowly accelerating engines
Previously, the platform would not schedule coil pulses when the engine
accelerated slowly, leading to failed starts.
Installation

before OpenECU.
• Correct missing picture in the User Guide
• Correct wrong path in the release notes and installer
Previously, the release notes and installer gave the wrong command and
path information when an instance of MATLAB could not be found.
• Missing supporting script for FreeCCP
Previously, a missing script prevented the FreeCCP tool from running

correctly.
Target ECU

• Correct a subset of feedback/monitor signals on the G800 target
Previously, the following monitor or feedback signals were incorrect:
• MCS1 (pin A17)
• MCS2 (pin A18)
• GSS1 (pin A19)
• GSS2 (pin A20)
• ACR (pin B2)

Change log
• STRTEN (pin B4)
• LSF (pin B24)
• FP (pin B27)
• Correct constant current channel usage on the G800 target
Previously, the constant current output on the G800 (pin A39) did not work.
Requesting a constant current output between 0 and 1A resulted in the
constant current output turning half on or off.
Now, the constant current output can be variably changed between zero
and full scale.
Warning
The generic pin name of A39 and B3 have been corrected as part of
this change. Any SPI output block which used the generic pin name
for A39 or B3 will need to be updated the first time it is used with this
version (or any subsequent version) of the developer software.
• The SPI input block loses the G400 VBAT channel setting
Previously, if the SPI input block was setup to read the internal VBAT
processed analogue input, it would revert to the default channel when the
model was next loaded.
3.46. Release 1.5.1


compatible upgrade

Communications

ISO-15765 over CAN.

Change log
• Marginal CAN bit settings resulting in odd CAN behaviour
Previously, CAN communication was setup with marginal bit settings

which resulted in some odd behaviour when connected to some CAN
networks and correct operation on other CAN networks. The behaviour
did not affect the reprogramming mode of the device.
Now, the CAN bit settings have been corrected and operation verified on
two different vehicle networks.
• Incorrect handling of CANdb receive outports if RAW signals not

selected
Previously, if RAW output signals were not selected in a CANdb receive

block, a build of the model would fail with an error message about
accessing port indexes.
Now, regardless of whether RAW output signals are selected or not, a

build completes.
3.47. Release 1.5.0


compatible upgrade
Gateway No CRs 435 (VI) Yes No
Sim-API 463 (VI), 456 (VI), 455 462 (VI), 460 (VI), 458 No, see: No
(VI), 453 (VI), (VI), 457 (VI), 430 (VI),
452 (VI), 438 (VI), 432 446 (VI), 444 (VI), 442 428 (VI),
(VI), 431 (VI), (VI), 430 (VI), 427 (VI)
429 (VI), 426 (VI), 425 428 (VI), 427 (VI), 424
(VI), 424 (VI), (VI), 424 (VI),
424 (VI), 423 (VI), 420 424 (VI), 421 (VI), 420
(VI), 420 (VI), (VI), 420 (VI),
420 (VI), 420 (VI), 418 420 (VI), 419 (VI), 412
(VI), 418 (VI), (VI), 395 (VI),
411 (VI), 354 (VI), 309 (VI) 346 (VI), 316 (VI), 315
(VI), 241 (VI),
227 (VI), 214 (VI), 28 (VI),
6 (VI)


Change log

developer software.
• Added a bitwise operator block
Added a simple bitwise operator block that takes two signals and applies
one of AND, OR or XOR to the signals. Although later versions of MATLAB
supply a similar block, MATLAB R12.1 does not.
• Added preliminary MATLAB R14 support
Tested against R14.1 and R14.2 only. Model references, shared utilities
and elapsed timers are not yet supported. See the OpenECU User Guide
for more details.
• Added generic pin naming (in addition to the powertrain items

already there)
The existing pins are named after powertrain applications. The names are
not always clear in a generic context or in a powertrain context where the
pin is reused for a different function.
The generic scheme names pins like:
Name Description
AIN analogue input
DIN digital input
AOT analogue output
DOT digital output
Monitor feedback of output
The default selection is powertrain naming to maintain backwards

compatibility with existing models.
• Split out fault checking in blocks and provide as general blocks to

users
Added the following blocks related to fault processing:
• Added general "range check" block

Change log
• Added general "slew rate check" block
• Added general "fault check" (leaky bucket) block
• Added the put_SignalPreparation block for fixed point CAN messages
• Added the put_SignalValidate block for fixed point CAN messages
• Added the put_SignalGapDetection block for finding missing CAN

messages
• Added a platform version control block
Added a platform version control block where the user may select that a
model must work with:
• the Simulink blockset software at a specific version
• the Simulink blockset software before a specific version
• the Simulink blockset software after a specific version
• the Simulink blockset software from a version to another version
On loading the model, an error message is printed if the wrong version is

detected. On building the model, the build is stopped if the wrong version
is detected. If no platform version control block is present in a model, no
checks are made against the version of OpenECU Simulink blockset.
• Unload OpenECU workspace variables on request
Previously there was not mechanism to remove only the workspace

variables created when an OpenECU model is loaded.
Now there is a command (clear_build_list) that will remove

workspace variables created when loading an OpenECU model.
• Integrated OpenECU with MATLAB/Simulink more tightly
From the command prompt, OpenECU now responds to the following

commands:
Command Description
ver openecu Display version information about the installed
OpenECU Simulink blockset.
help openecu Display information about the available OpenECU
commands.
info openecu Display the changes to the OpenECU Simulink
blockset for each version.
From the launch pad, various items relating to OpenECU is available

under the name OpenECU Simulink Blockset (Pi Innovo), including links to

Change log
the OpenECU and PixCal User Guides, the change log for each version of
the OpenECU Simulink blockset, the example models, Simulink blockset
library models, and to various web pages including the OpenECU update
web site.
• Provided command to generate basic OpenECU models easily
A new OpenECU model with appropriate Simulink model settings and an

empty data dictionary can be created using the command:
create_openecu_model(...)
More details are given in the OpenECU User Guide.
• Added block to show the model rates and the model rate colours
Added a block which shows the model rates and the model rate colours.
The model must be updated twice for the block to show the model
information.
Calibration

software.
• Generate ASAP2 files for all supported calibration tools
Previously, only one ASAP2 file was generated at the end of a build for
the calibration tool specified in the pcp_CCPConfiguration block.
Now, an ASAP2 file is generated at the end of the build for each supported
calibration tool and the setting in the pcp_CCPConfiguration block has
been removed.
• Correctly handle the boolean setting in DD files
Previously, the Simulink boolean setting would not be honoured when

generating ASAP2 files. This lead to the situation where booleans in
the model would be treated as floating point values. This lead to these
elements being incorrectly displayed by the calibration tool.
• Provided grouping of data dictionary elements in ASAP2 file
As well as a flat list of all data dictionary elements, the generated ASAP2
file now contains a set of kinds. The kinds sort data dictionary elements
based on model hierarchy, on type and on prefix, making it easier to find
related elements.

Change log
• Extended ASAP2 generation to include map lookup details
Generated ASAP2 files now contain information about which inputs

contribute to a map lookup. Calibration tools can use this information to
display the current map operation point if those inputs are being viewed
over CCP.
This is a preliminary feature and may change in the future. In order for
this feature to work, the inputs to a map lookup must be named with a DD
entry. If a block divides the signal so that the signal to the map is unnamed,
the feature will not output the map lookup information to the ASAP2 file.
Communications

ISO-15765 over CAN.
• Added block to inhibit reprogramming based on an inport state
This replaces the functionality of the automatically generated ASAP2 entry

named mpl_inhibit_reprog. The model may now ignore requests to
reprogram the module for a given set of conditions.
• Added indication of CAN bus off state
Added a CAN bus status block pcx_CANStatus. The block provides

outports which set when the CAN bus goes offline.
• Added indication of lost CAN messages
The pcx_CANReceiveMessage block has been updated to include an

overrun flag. The overrun flag outport indicates if more than one CAN
message of the same identifier has been received since the last time the
block was iterated.
• Added support for Vector CANdb in the CAN blocks
The Simulink blockset now supports the use of Vector CANdb files in the
CAN receive and transmit blocks.
decoding.
• Added average engine speed and acceleration to existing blocks

Change log
Added the average engine speed and acceleration calculated over 720°
or more, to the existing engine speed and acceleration blocks.
• Added engine knock detection support
A set of blocks have been added to support knock detection (using the
HIP 9011 device).
• Added engine knock detection support
Installation

before OpenECU.
• Reimplement installer
The previous installer could not:
• modify more than one version of MATLAB
• modify more than one version of Vision
• display more than three versions of MATLAB to modify
• display more than three versions of Vision to modify
• correctly identify the third item if selected (MATLAB or ATI Vision) if

more than three items existed
• uninstall correctly
• correctly form dialogs
These issues and others have been addressed by re-writing the installer.


developer software.
• Consistently handle boolean items in block correctly

Change log
Previously the OpenECU Simulink blockset would type boolean inports

inconsistently (sometimes they were typed as boolean, sometimes as
double and sometimes they would change type based on Simulink's
boolean setting).
Now, the following blocks adhere to the boolean Simulink setting:
• pan_EngineConfig
• pdx_FrequencyInput
• pdx_PeriodInput
• pdx_QuadrateDecodeInputAndFrequencyInput
• pnv_adaptive_checksum
• pnv_adaptive_map1d
• pnv_adaptive_map2d
• pnv_adative_scalar
• pnv_status
The following blocks are consistent in using a checkbox to indicate a

boolean parameter setting (in this case, signal inversion):
• pdx_DigitalInput
• pdx_DigitalOutput
• pdx_PWMOutput
• pdx_PWMVariableFrequencyOutput
Warning
Any model loaded using this version of the platform will lose the
inversion information of each of those blocks.
Any model that uses these blocks and contains an inversion, will
need to reset the inversion setting after loading the model for the
first time.
• Changed various blocks to use a consistent naming convention
Changed the following blocks to use a similar naming convention to the

majority of platform blocks (done in platlib.mdl only, so library links
are maintained)
• pnv_AdaptiveChecksum
• pnv_AdaptiveMap1d
• pnv_AdaptiveMap2d
• pnv_AdaptiveScalar

Change log
• pnv_Status
• put_Calmap1d
• put_Calmap2d
• put_CalvalTune
Changed various inport and outport names to reflect actual usage (e.g.,
replace real_value with duty_cycle in pdx_pwmoutput block).
Changed 1-d and 2-d (calmap and calmap_tune) parameter names to

match the equivilent names in the adaptive blocks.
Changed pan_PrimaryAngularCounts to pan_PrimaryAngularInput.
Changed pan_SecondaryAngularCounts to pan_SecondaryAngularInput.
Corrected name of second inport in

pdx_QuadratureDecodeAndFrequencyInput.
• Updated the User Guides
Updated the user manual to correct a number of mistakes. Extended the

user manual to include many details that never made it into the original
manual. Extended the user manual to include changes to OpenECU since
the original manual was written.
Calibration

software.

Change log
• Correct hard coded number of Tunes
Previously, the number of tunes available was limited to a predefined limit

that varied on the version of the OpenECU software. The limit should have
been > 200 tunes, but the actual total was significantly less.
• Corrected ASAP2 generation with respect to INCA errors
Previously, the ASAP2 generator would output conversion rules for two
entries that might not be used by the reset of the ASAP2 file. In this case,
when the file was read into INCA, INCA would generate a warning for each
unused entry.
Now, the ASAP2 generator only outputs used conversion rules and INCA
no longer reports any warnings.
• Extended the error checking of the data dictionary handling
Data dictionary error handling has been extended to check around 40

properties of each element. A complete list of the checks performed is
given in the OpenECU User Guide.
Data dictionary error handling has been extended to read a units file (if
available) and raise an error if any DDE does not use one of the units from
that file. If no units file exists, no checks are made on the units of any DDE.
• Extended ASAP2 support for Tunes and Adaptives
The ASAP2 entries for tune and adaptive items were previously limited to
the first element of any map and were always of a specific type. These
ASAP2 entries are now fully formed.
• Do not produce a fatal error if a DD file is missing
Previously, reading a buildlist with a missing data dictionary file would lead
to a fatal error.
• Improve the loading time for data dictionaries
Previously, the load time for large data dictionaries could be lengthy.
Code generation

Change log

• A problem has been reported with OpenECU's handling of inf
Previously, if inf or -inf were used in a model, an OpenECU build would not
complete (an error was raised that noted various variables were missing).
Now, the RTW rt_nonfinite.c file is linked with the model objects and
rt_InitInfAndNaN() is called to initialise the missing variables prior
to model start.
Communications

ISO-15765 over CAN.
• Corrected packing of CAN data (LSB) in can translator
CR 435 (VI), affects Gateway
Previously, data arranged in least significant order (LSB ordering) was

incorrectly packed into a message to be transmitted.
• Correctly handle the maximum number of receive CAN mailboxes if

CCP is enabled
CAN block checking modified to automatically adjust how many receive

messages are available based on whether CCP is enabled or not.
• Rationalised user input of available CAN baud rates
Changed the pcx_CANConfiguration CAN block to have drop down for

supported CAN baud rates.
Warning
Any model using this block will loose any CAN baud settings. These
settings must be reset the first time they are used with this version
of the platform.
• Rationalised user input of available CAN buses
The following CAN blocks have changed to include a drop down for
selecting a CAN bus:
• pcx_CANConfiguration
• pcp_Configuration
• pcx_CANReceiveMessage

Change log
• pcx_CANTransmitMessage
Warning
Any model using these blocks will loose any CAN bus settings.
These settings must be reset the first time they are used with this
version of the platform.
Examples

• Extended the examples and provide loom details
The set of examples has been extended from the step1 model to include
the following:
Name Description
two_pot_demo Similar to step1 but shows how to combine more
than one input to achieve a similar effect.
multi-rate An example of how to exchange information
between parts of a model that run at different
rates.
fixed angular An example of how to configure a model to read
from a crank wheel and generated fixed injector
and spark outputs.
A selection of examples and details of their looms can be opened by

running the command:
openecu_examples
decoding.
• Angular platform ASAP2 entries generated if model has no angular

functionality
Previously, the platform would generate angular specific ASAP2 entries

if the model did not have angular functionality. When the ASAP2 file
was read into a calibration tool, the corresponding memory items for the
ASAP2 entries would not be present and the tool would complain.
Now, the platform angular ASAP2 entries are only created if the model
has angular functionality enabled.

Change log
• Remove simulation error for the stepper motor block
Previously, the stepper motor block would occasionally cause an

exception within the MATLAB environment when simulated.
• Remove simulation error for the variable frequency PWM block
Previously, the variable frequency PWM block would not simulate.
Now, it simulates correctly and the processed frequency is passed out as

a simulation outport (just as the processed duty cycle is).
• Reduced the RAM usage if angular functionality is not selected
Previously, if angular functionality was not selected then the amount of

RAM used by OpenECU would be the same as if angular functionality
were selected.
Now, if angular functionality is not selected then around 800 bytes of RAM
is freed up.
• Correct adaptive storage problem
Previously, if Flash storage was selected for adaptives and the pnv_Status
block was ordered after other adaptive blocks, then adaptives would not be
stored in Flash correctly and would not be retained across power cycles.
• Correct simulation of adaptive blocks
Previously, simulating a model that contained adaptive blocks would

cause the Simulink simulation engine to catch an exception. The problem
was traced to the pnv_Status block which was overwriting memory it did
not own. Depending on the layout of the model, the model would either
simulate without error or cause the exception seen.
Target ECU

• Corrected G400 I/O mapping
Previously, the I/O mapping made monitors for pins 2 and 6 available.
These were never intended to be used and provided no feedback. These
monitors have been removed.

Change log
3.48. Release 1.4.0

Release labelled rel_install_1_4_0 from 6 May 2005. This release is marked as general

compatible upgrade
(VI), 389 (VI), (VI), 399 (VI),
376 (VI), 372 (VI), 372 397 (VI), 388 (VI), 385
(VI), 372 (VI), (VI), 377 (VI),
371 (VI), 370 (VI), 357 374 (VI), 373 (VI), 348
(VI), 290 (VI) (VI), 233 (VI),
82 (VI), 81 (VI), 19 (VI)


developer software.
• Cache target and target I/O information to speed model load and
update
Previously, without any caching, the number of find_system calls caused

the model open and model update functions to take a long time. This
resulted in an inactive MATLAB application for up to a minute.
Now, tests on a model with lots of I/O show the caching has reduced the
load time from 45 seconds to 25 seconds. Further work to be done to
improve other aspects of using find_system.
• Display warning when RTW produces unsupported API calls
At the end of a build, a warning message is displayed if any of the RTW

generated code from the model makes a call that accesses absolute time.
After discussion with MathWorks, it appears that there is no work around

for blocks that rely on absolute time and that these blocks will eventually
fail when run on target. The build now generates a message at the end of
the build warning the user if this issue arises.

Change log
Calibration

software.
• Display summary of unresolved ASAP2 entries at end of build
Up to the first 5 ASAP2 entries which could not be found in the final image
are displayed at the end of a build.
• Add dropdown to the pcp_CCPConfiguration block to select

calibration tool
Support has been added to select a generic ASAP2 output or support for
the ETAS INCA or ATI Vision calibration tools.
• Added ETAS INCA support in the ASAP2 file generation
Support has been added for generating ASAP2 statements which support
the ETAS INCA tool (tested against version 5.1.2 (hot-fix 3)). These
statements define the CCP parameters (CAN message identifiers, logical
station address etc.) and the memory regions.
• Added INCA-ProF support
Preliminary support added for the INCA-ProF tool.
• Add ATI Vision support in the ASAP2 file generation
Support has been added for generating ASAP2 statements which support
the ATI Vision tool (tested against version 1.9.1). These statements define
the CCP parameters (CAN message identifiers, logical station address
etc.) and the memory regions.
When importing the ASAP2 file into ATI, do not select any strategy presets.
If importing into an existing strategy file, remove all previous presets

before importing. To do this, open the strategy, select the menu
option File->Properties, then the Device Settings tab and delete all the
parameters.
Code generation

• Print stack size allocated at the end of a build

Change log
decoding.
• Add uni-polar stepper motor output block
Support has been added for a stepper motor output block. A description of
its functionality can be viewed by selecting the block's help or by reading
the OpenECU User Guide.
• Add uni-polar stepper motor output block
• Added an injector update feature for improved transient control
Added the ability to update an already scheduled injector pulse more than
once per engine cycle. The updates include changes to dead time, flow
time and start angle.
If the update happens before the pulse has already started, the start
angle and duration can change. If the update occurs during the pulse, the
duration can be changed. If the update occurs after the pulse has been
delivered, and the duration has been extended, a new post pulse will be
started.
• Add Flash storage for adaptives
Adaptive constants, 1-d and 2-d maps can now be stored in battery backed
RAM (as before) or to Flash storage.


developer software.
• Adaptive blocks don't simulate correctly when more than one of the
same type exists in a model

Change log
Previously, if more than one type of adaptive block was present in a

model, the simulation of the model would be incorrect. Data created for
one adaptive block would be reused for the other blocks.
Now, each adaptive block separates its work data making each adaptive
block independent.
• 1-d and 2-d maps do not work under simulation
Previously, under simulation, the result of a table lookup would be the first
z-data element regardless of the x and y input values.
Calibration

software.
• Allow build list filename to be independent of model filename
Previously, a change forced the build list to have the same file name as
the model filename - a restriction on previous functionality.
Code generation

• Move <model_name>.a2l.err from build directory to model

directory
• Always generate an ASAP2 file
Previously, if a build was attempted after the success of a previous build,

the ASAP2 file generation failed.
Now, the ASAP2 file generation always occurs. A side effect of this is that
the user is asked to reload the build list each time a build starts.
• Clean up the build output
• Clean up the build output
Previously, various files are generated in the same directory as the built
model. These included various versions of the image files and some
temporary files from the ASAP2 generation.

Change log
Now, the following files are produced from a clean build:
File Description
model_name.a2l ASAP2 file
model_name_strategy_cal_image.s37 S-record of built model
model_name_strategy_cal_image.hex Intel HEX record of built
model
decoding.
• Correct spelling in pan_EngineConfig block mask
• Only allow even numbers of cylinders in pan_EngineConfig block
Previously, the block allowed odd numbers of cylinders, but this would
cause supporting scripts to fail. At the moment, only even numbers of
cylinders are supported. Odd numbers of cylinders can be configured by
selecting 1 more cylinder in the pan_EngineConfig block but not wiring it
into the system.
• Correct fault detection in analogue input block
Previously, RTW would generate code which relied on an absolute time for
the pai_AnalogInput block under certain circumstances. OpenECU does
not maintain absolute time (as it will eventually saturate a floating point
variable and fail, see CR #357), so the analogue input block would fail
when determining fault conditions.
Now, RTW does not generate code which relies on absolute time and fault
detection works.
• Replace crank synchronisation logic
Previously, the crank synchronisation logic would fail if the ECU

experienced infrequent but high processor utilisation around the crank
missing tooth region.
• Double initial fuel pulses
Previously, if the crank synchronisation failed during cranking (see CR

#384), the ECU would deliver more than one initial fuel pulse.
• Lag in angular injector and coil events

Change log
• Lag in angular injector and coil events
Previously, as the engine speed increased then the start and end angles
for injector and coil pulses would become less reliable. Part of the problem
is in the hardware filtering of the crank input signal (a linear increase of up
to 1° happens between 100 RPM and 8000 RPM) and part of the problem
was due to the way the processor time stamped crank teeth edges.
Now, although the hardware filtering still introduces a lag, the time
stamping of crank teeth edges has been improved significantly (see CR
#384).
• Initial fuel pulse after injector pulses
Previously, the ECU would occasionally produce an initial fuel pulse after
the main injection pulses had started.
3.49. Release 1.3.1

Release labelled rel_install_1_3_1 from 7 January 2005. This release is marked as

compatible upgrade

Calibration

software.
• No Tune group present in ATI Vision INI file after install
Previously, a clean install did not add a Tune region to the ATI Vision INI
file (if present).

Change log
Code generation

• Failure to build if no adaptive tables are present in a model
Previously, if a model did not contain an adaptive table block, the build
would fail.
Installation

before OpenECU.
• Missing file from installer
Previously, an executable file was missing from the installer. This resulted
in a failure to load an OpenECU model.
3.50. Release 1.3.0

Release labelled rel_install_1_3_0 from 22 November 2004. This release is marked

compatible upgrade
Sim-API 363 (VI) 363 (VI) Yes No


developer software.
• Added non-volatile adaptive Simulink blockset
The non-volatile adaptive Simulink blockset provides a mechanism to

store scalar, 1-d and 2-d map data in RAM, modify the data whilst the

Change log
model is running and reuse this information across power cycles (by
applying battery power to the module's keep alive pin).
The blocks are stored in the "Module Non-Volatile Memory" section of the
OpenECU Simulink blockset. See the installed help files for more.

decoding.
• Errors when using engine configuration block with blank fields
Previously, when the engine configuration block is copied from the library
to a model, a large number of errors are displayed in the MATLAB
command window. This was due to empty mask parameters in the block.
3.51. Release 1.2.0


compatible upgrade
Sim-API 356 (VI), 355 (VI), 352 (VI) 358 (VI), 353 (VI), 320 Yes No
(VI), 227 (VI)


developer software.
• Extend Tune support to MATLAB R13.x
Code generation

Change log

• Produce Intel HEX output files at the end of a build
Previously, the build process only created Motorola S-records of the model
image.
Now, the build process produces Motorola S-records and Intel Hex files of
the model image. The ATI Vision calibration tool can read both S-records
and Hex files, the ETAS INCA calibration tool can read Hex files.
Target ECU

• Allow the G800 CID2 channel to be used in a model configured to

run an engine
Previously, if a model had an engine configuration block, all use of the

CID channels was raised as an error.
Now, if a model has an engine configuration block, all use of the CID
(G400) and CID1 (G800) channels are raised as an error, but use of the
CID2 (G800) channel is allowed. Multiple use of the CID2 channel still
correctly results in an error.

Calibration

software.
• Additional help files added (ongoing)
Updated help file for block pcp_configuration to describe the sub-set

compliance with CCP version 2.1 and additional restrictions.
Code generation

• Move table lookup and interpolate source code into platform library

Change log
Examples

• Make all developer software blocks links in the example models
decoding.
• Remove default details from the analogue input block
3.52. Release 1.1.0

Release labelled rel_install_1_1_0 from 10 October 2004. This release is marked as

compatible upgrade
Sim-API 350 (VI), 345 (VI), 342 349 (VI), 344 (VI), 227 Yes Yes, see:
(VI), 327 (VI), (VI), 223 (VI), 350 (VI),
306 (VI) 182 (VI) 349 (VI)

Calibration

software.
• Extended DD tools to allow display precision to be specified
Previously, all floating point values were specified to have 4 digits after
the decimal place.
Now, the accuracy column is used to determine how many digits should
be displayed by the calibration tool. For instance, the accuracy values

Change log
100.01, 0.01 and .01 will cause the calibration tool to use 2 digits after the
decimal point. If the column is left empty, the default is 4 decimal digits
for a floating point value and is unchanged from previous functionality for
other data types.
• Added optional PixCal support
PixCal is a simplified calibration tool built around Excel and a standard

PC UART port, which allows the user to modify a small number of RAM
based calibrations called Tunes. Tunes are stored in Flash, recalled to
RAM when the ECU powers up, and can be written back to Flash when
the engine is not running under user control.
The Simulink blockset has been extended to include a PixCal protocol

configuration block, and a scalar, 1d and 2d table lookup block. If
purchased, these can be found in the Pi OpenECU Extras - Tunes library.
The PixCal manual is included with the OpenECU platform installer but is
intended for reference only. To purchase the tool and Simulink blockset,
or for further details contact Pi (see section 1.3).
Communications

ISO-15765 over CAN.
• Added CCP station identifier to CCP configuration block
Previously, OpenECU would allow sessions that use station address 0 or

1.
Now, OpenECU will allow sessions that match the station address given
in the CCP configuration block. If there is no CCP configuration block in
the model, reprogramming mode defaults to a station address of zero.
OpenECU devices that have never been programmed before default to a
station address of zero.
Note
• Allowed up to 15 receive messages per bus, or 28 overall
Previously, this extension was applied to OpenGateway only.
Examples


Change log
• Incorporated the two-pot demo into the examples


developer software.
Updated help files for blocks: pan_EngineConfig.
Added help files for blocks: pcp_Configuration, ppp_Configuration,

put_calval_tune, put_calmap1d, put_calmap1d_tune, put_calmap2d,
put_calmap2d_tune.
Calibration

software.
• Failure to transmit CCP data when user changes a calibration
Previously, when a calibration is changed while viewing data over CCP

(requested via DAQ lists) the OpenECU transmission of that data stops
until the calibration tool requests the current status.
Now, OpenECU continues to transmit data while the user is changing the
calibration. Further investigation will be required to determine if the CAN
data stream continues to transmit uninterrupted as required.
Communications

ISO-15765 over CAN.
• Removed loss of CCP communications with partial downloads of

application code
Previously, a partial download of the strategy code could stop CCP

communications.
Now, a partial download results either:

Change log
1. use of the new model settings (even through not all of the model code
or calibration was successfully downloaded);
2. use of default settings (CRO: 1785, DTO: 1784, Station ID: 0, CAN bus:
0, CAN bus baud rate: 500 kBps).
Note
• Removed warning messages about Rx and Tx CAN message blocks
Previously, if a CAN configuration block and CCP configuration block

existed in the model without any Rx and Tx blocks, the platform would
issue a warning. However, this is a valid state of the system (for instance,
for selecting a non-default baud rate for CCP).
decoding.
• Correction to ASAP platform variable name that signals gain or loss

of crank sync
Previously, the ASAP error file would contain a reference to the internal
platform signal phwl_synced_with_crank. This signal has been renamed,
hence the error.
Now, the ASAP tools correctly reference the signal name and the warning
has been removed.
3.53. Release 1.0.9


compatible upgrade
Gateway 306 (VI), 280 (VI) 308 (VI), 307 (VI), 304 Yes No
(VI), 303 (VI),
301 (VI)

Change log

compatible upgrade
Sim-API 295 (VI), 291 (VI), 280 (VI) 285 (VI), 284 (VI) Yes No

Communications

ISO-15765 over CAN.
• Allow up to 15 receive messages per bus, or 29 overall
• Updates
Added better VectorDB parsing; added support for bitwise operators (and,
or and exclusive-or); updated version of language support to 2 (the output
of the CANTranslator tool and the platform must match before the platform
will run the translator code).
• Updated platform to support new version of CANTranslator code
• Allow messages to be transmitted using a new keyword 'trigger'
Affects Gateway
This feature allows a message to be transmitted and as the keyword

can be used in a receive block or transmit block, the conditional logic
for transmitting logic can be extended beyond the 'when receive/unless'
mechanism.
Target ECU

• Added G600 target ECU hardware support
Added G600 as target in identification block; added limited I/O support.
• Added support for G400 pin J1-69 as an output


Change log

developer software.
• Correct wrong printed information of internal data (debug purposes

only)
• Remove block mask defaults
The user must now populate an OpenECU block before updating or

building the model. Previously, some of the defaults were confusing and
some referenced workspace variables which did not exist: now all blocks
are consistent in having no defaults.
Communications

ISO-15765 over CAN.
• Updates
Allow a translation to use one Vector DB file to declare both receive and
transmit messages; extend the language to distinguish which message is
meant when it is declared as both received and transmitted; allow more
than one Vector DB file to refer to the same CAN bus nodes.
• Fix error when more than the maximum receive messages were
declared
The platform would crash if it was asked to allocate more than maximum
receive messages per bus, or in total.
• Correct semantics for "not" operator
The translation would not invert a signal if the not operator was applied to
it, i.e., false was converted to false, true was converted to true.
• Accept Vector DB files with signal lengths > 32 bits, but reject their
use in the translation
• Updated platform to support new version of CANTranslator code

Change log
3.54. Release 1.0.8

Release labelled rel_install_1_0_8 from 14 April 2004. This release is marked as

compatible upgrade
Sim-API 270 (VI) 264 (VI) Yes No


developer software.
• Add beta MATLAB R13 support

Code generation

• Correct path to non-inlined S-function for compilation
3.55. Release 1.0.7


compatible upgrade

Change log

compatible upgrade
Sim-API 261 (VI), 253 (VI) 262 (VI), 260 (VI), 259 No, see: No
(VI), 258 (VI), 256 (VI)
257 (VI), 256 (VI)

decoding.
• Add a combined quadrature decode and frequency input block
The added block supports the following features:
• 16 bit quadratue decode count (as existing quadrature decode block);
• 31 bit timing on frequency for both quadrature channels;
• frequency measurement based on rising edge;
• frequency measurement of 1 period on primary channel;
• frequency measurement of configurable periods on secondary channel;
• associated simulation inports.
Target ECU

• Add SS2 to the G400 I/O channel mapping

Code generation

• Correct comment in auto-generated code for the frequency input

block
Communications

Change log

ISO-15765 over CAN.
• Correct CAN receive and transmit block behaviour when included

in atomic sub-systems
Previously, when a CAN receive or transmit block was included in

an atomic sub-system, the auto-generated code would refer to the
wrong CAN block. This caused the wrong messages to be received or
transmitted, and could cause unusual behaviour in the ATI calibration tool.
decoding.
• Make frequency input processing independent of the frequency

signal
Previously, the loading on the CPU would increase as the frequency of

the input signal increased.
Now, the CPU loading is independent of the signal frequency.
• Allow injector and coil monitors to be used when the engine

configuration block is present
Previously, when the injector or coil monitor was used and the model
contained an engine configuration block, the stronger channel testing
would reject the use of the monitor channel, due to its textual name.
Now, the injector and coil monitors can be used whether the model has
angular functionality or not.
• Correct default I/O channel mapping in the digital input blocks
Previously, some digital input channel settings would be reset when a

model was loaded because the default selection was out of date.
Target ECU

• Add back in the GSS2 monitor to the G800 I/O mapping
Previously, GSS2 monitor was accidentally removed from the I/O channel
selection.

Change log
3.56. Release 1.0.6


compatible upgrade
Sim-API 252 (VI) No CRs Yes No

decoding.
• Export of reason of reset as ASAP measurable
This brings out the processor reset register as a CCP measurable,

mpl_rsr. Its 16 bits long and contains a number of bits which signify
different events. The watchdog bit, 12 (i.e., 0x1000), is set if the last reset
was due to a watchdog trip. Typical values for this displayable are:
Value Reason for reset

57528 power on reset
61624 watchdog reset
The platform automatically generates an ASAP entry for this measurable.
3.57. Release 1.0.5


compatible upgrade

Change log

compatible upgrade
Sim-API 249 (VI), 246 (VI), 236 251 (VI), 250 (VI) Yes No
(VI), 231 (VI)

Communications

ISO-15765 over CAN.
• Allow inhibit of CCP reprogramming from application
This feature can be invoked by introducing a signal called

mpl_inhibit_reprog into the model. The signal must be an outport
from a block and must not a be ground source block. The application must
set the signal to inhibit reprogramming, or clear it to allow reprogramming.
The signal must have type uint8_T and must be exported global
(otherwise, the platform will raise an error when attempting to build). If the
signal is present in the model, the build process generates an ASAP entry,
otherwise no ASAP entry is generated.
When set, the following CCP operations will not be honoured (but other
implemented CCP operations are):
Operation CCP command

identifier
clear memory 0x10
select cal page 0x11
program 0x18
program 6 bytes 0x22
move 0x19
diagnostic service 0x20
action service 0x21
decoding.
• Add angular channels for block channel selection

Change log
All angular channels have been added to the I/O mapping. CPS and CID
can now be used in most digital input blocks, and INJx and CDx can now
be used as digital and PWM outputs.
To support this, the following model checks have been added. The model
does not start to build if any of these tests raises an error.
• error if CPS is selected and an engine configuration block exists;
• error if CID is selected and an engine configuration block exists and

cam shaft processing is selected;
• error if INJx is selected and an engine configuration block exists and x

<= number of engine cylinders;
• error if CDx is selected and an engine configuration block exists and x

<= number of engine cylinders;

decoding.
• Add stronger inter-block I/O channel checks
Previously, only I/O channels on the same block type were tested to be
unique.
• Add stronger quadrature decode channel checks
Previously, a quadrature decode block could select channels such that

the function would not operate.
Now, only channels which allow correct operation can be selected.
3.58. Release 1.0.4


compatible upgrade

Change log

compatible upgrade
Sim-API 243 (VI), 242 (VI), 240 No CRs Yes Yes, see:
(VI), 238 (VI), 240 (VI),
236 (VI), 236 (VI), 128 (VI) 128 (VI)

Calibration

software.
• Share application CCP settings with RPRG
Note
• Share application CCP settings with RPRG
The CCP settings defined in a model are now shared with the
reprogramming software. On a new ECU or an ECU without application
code (erased or corrupted state), the reprogramming software uses a
default of 500 kBps on CAN-0 (CRO and DTO of 1785 and 1784). On
an ECU with a valid application, the reprogramming software will use the
same CCP settings as the model application code.
Note
Communications

ISO-15765 over CAN.
• G400 1000 kBps CAN support in application

Change log
The previous bit timing settings for a G400 device at 1000 kBps CAN were
incorrect. This fix adjusts the timing and has been tested using an ATI hub.
decoding.
• A simplified analogue input block has been created
The simplified block provides a voltage reading without fault indication.
• Access to frequency input TPU parameters through data dictionary

entries
The underlying TPU frequency input function has been changed from
PPWA to PTA. This provides a wider timing range than before (32-bit
accumulation of pulses rather than 16 bit) and the flexibility to accumulate
multiple pulses to average over.
The block mask for the frequency input block has changed to remove the
minimum pulse period (used to mask noise) and to add a timeout duration
(above which if the input signal has not transitioned through a complete
pulse, the block shows the signal as stuck).
The functionality of the PTA function is further exposed through

calibrations.
Calibration name Type Range Description

mplc_fi_config_x uint16_T 7 or 11 Set to 7 to accumulate pulse duration starting
on a rising edge, set to 11 to accumulate
pulse duration starting on a falling edge.
mplc_fi_count_x uint8_T 1 to 255 Number of pulses to accumulate before
calculating the signal frequency.
In each calibration, x is replaced by the pin name. For instance, if pin 58

on the G400 is configured for a frequency input, then x is replaced by
OSS_VRS (as given in the drop down selection for the channel). Similarly,
if pin 34 was configured, x would be replaced by TSS.
The overall timing rate of the TPU (which includes more than the
PTA function) is exposed through the mplc_tcr1_scalar calibration. The
calibration is 16 bits long, and can take any even value between 2 and
128. A special case of 0 represents the default scaling . The following table
shows the timing rate for a variety of values.
mplc_tcr1_scalar Timing rate (Hz)

128 187,500
64 375,000
16 1,500,000

Change log
mplc_tcr1_scalar Timing rate (Hz)

2 12,000,000
Any other values for mplc_tcr1_scalar will give undefined results.
If any of these calibrations are defined in the data dictionary, then a

corresponding constant block must be added to the model. If any of
these calibrations are not added to the data dictionary, then they will be
automatically added by the build mechanism but a constant block must
not exist.
It should be noted that other functions rely on the TCR1 pre-scalar.

Specifically, the period input block can accumulate up to 24 bit durations,
and the PWM output block can emit 15 bit durations. Care should be taken
when changing the default pre-scalar.
Target ECU

• G400 CDA and CDB pins are now available as PWM outputs
On non-engine related applications (i.e., a model with any angular blocks,

such as engine configuration) may now use the CDA and CDB outputs
as PWM outputs.
• G800 CDA, CDB and HHTR12 now available as DOT
On non-engine related applications (i.e., a model with any angular blocks,

such as engine configuration) may now use the CDA, CDB and HHTR12
outputs as digital outputs.
3.59. Release 1.0.3


compatible upgrade


Change log

developer software.
decoding.
• Engine turning flag available from the pan_EngineConfig block
Whether the platform has been the crank input shaft turn or not, is now
available as an outport from the pan_EngineConfig block. The condition
for changing from stopped to turning is to have detected three teeth
transitions within 350ms.
• Additional changes to crank synchronisation microcode errors
3.60. Release 1.0.2


compatible upgrade
(VI), 223 (VI), (VI), 221 (VI),
215 (VI) 220 (VI), 207 (VI)

decoding.

Change log
• Period measurement block added, enabling closed loop ignition

dwell control
A period measurement block is now available as part of the block set. The
period measurement block provides a low time and a high time of an input
pulse train. See the online help for more.
• Crank sync flag now exported from the pan_EngineConfig block
Whether the platform is synchronised to the crank shaft input signal or not,
is now available as an outport from the pan_EngineConfig block.
Whether the platform is synchronised to the cam shaft input signal or not,
is now available as an outport from the pan_EngineConfig block.
• Make crank synced platform variable available as an imported

global
Whether the platform software is synced to the crank shaft input

signal is not, is now available as an imported global called
phw_synced_with_crank.
• AAICE configurable via calibration, enables Hall-effect cam sensor
Some default input signal characteristics can be changed by introducing

constant blocks into the model and calibration. The model constant
blocks don't need to be connected to anything. The names of
the calibrations and constant blocks must be: mplc_aaice_setup1,
mplc_aaice_setup2, mplc_aaice_vrsh, mplc_aaice_iksetup,
or mplc_aaice_sensel.
If you wish to modify the input characteristics of HEGO filtering; CID, OSS,
CPS, TSS, VSS for VRS or Hall effect; or the NOMI and MAXI trip points
please contact Pi OpenECU support.
Note: it may be possible to modify a sub-set of the above inputs.
Target ECU

• G400 CPS and CID channels now available as frequency inputs

Calibration

Change log

software.
• ATI crashes when importing an OpenECU ASAP2 file
With certain automatic platform ASAP entries, the generated ASAP file
would not contain necessary record descriptions to complete the definition
of those entries. This in turn would cause ATI to crash when it read the
ASAP file.
• ASAP variables causing an error during link
This error occurs with the OpenGateway tool. When the OpenGateway
configuration file refers to a valid ASAP entry from a pre-built model, it
reports that it cannot find its address during linking.
• ASAP files are generated with .a2l file extensions
Examples

• Updated quick start step1 Simulink example
decoding.
Help files for the following blocks are available online: engine configuration
block, frequency input block, period input block, quadrature decode input
block, identification block, automatic platform ASAP entries.
• Fix crank synchronisation microcode errors
There were a number of mis-calculations in the TPU microcode which

tracks the position of the crank shaft input wheel. These caused problem
during start and when idling at very low engine speeds. These have
been corrected. Tests show that the function can deal with the following
acceleration curve at low engine speeds:

Change log
Crank config 36-1 60-2

Engine speed Acceleration (RPM/s) Acceleration (RPM/s)
40 650 1100
130 7000 11600
220 20050 33450
310 39850 66400
400 66350 110600
3.61. Release 1.0.12


compatible upgrade

Communications

ISO-15765 over CAN.
• Corrected issue regarding extended CAN identifiers
Previously, the top most bit of any extended CAN identifiers was forced to
zero, causing problems receiving and transmitting CAN messages where
the top most bit was one.
decoding.
• Extend crankshaft configuration in the pan_EngineConfiguration

block
Previously, available crankshaft configurations with 36-1 and 60-2 crank

trigger wheels.

Change log
Now, user can select n-m, where n ranges from 36 to 60 and m ranges
from 1 to 2.
• Corrected n-2 crank trigger wheel synchronisation
Previously, engine configurations with n-2 crank trigger wheels failed to

synchronise correctly when also synchronised with the cam wheel.
Now, n-2 case acts in the same way as the n-1 case, when synchronised
with the cam wheel or not.
3.62. Release 1.0.11


compatible upgrade

Code generation

• Corrected platform path in template makefile
3.63. Release 1.0.10


compatible upgrade
Sim-API 298 (VI) No CRs Yes No

Change log

decoding.
• Added a variable frequency PWM output block
Previously, the PWM output block took the requested frequency as a block
parameter, making the frequency fixed at build time.
Now, there is an additional output block which takes the requested

frequency as an inport (only for TPU channels), making the frequency
modifiable at run time.
3.64. Release 1.0.1


compatible upgrade

decoding.
• Correct prescaler correction for MIOS PWM outputs
Each MIOS PWM output can scale the system clock. This feature is used
to generate as much resolution in each PWM output as possible. Under
certain circumstances, an incorrect clock scalar would be calculated,
resulting in a coarser resolution that possible. When this occurred,
the PWM signal would have a signal that approximated the requested
frequency and duty cycle.

Change log
• Rename MAP and MAF angular inputs
On engine related applications where analogue inputs are sampled on

an angular basis, it makes no sense to have these input names hard
coded when the user may select any analogue input channel. The angular
sample blocks have been renamed with generic names.
3.65. Release 1.0.0

Release labelled rel_man_1_03 from (not yet assigned). This release is marked as general

compatible upgrade

Appendix A. Contact information
If you have questions, or are experiencing issues with OpenECU please see the FAQ
website:
website
Support.OpenECU.com [http://Support.OpenECU.com]
If you still have questions after searching through the FAQ, or want to discuss sales or
proposals, you can contact main office:
Tel
+1 734 656 0140
Fax
+1 734 656 0141
during normal working hours (Mon to Fri, 0930 to 1700 EST).

Release Note Developer Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Release Note Developer Software

Uploaded by

Copyright:

Available Formats

®

OpenECU Developer Software

Copyright © 2019 Pi Innovo

Copyright 2019, Pi Innovo ii

1.2. Summary of releases

Copyright 2019, Pi Innovo 1

Fixes and Improvements

Table 1.1. Summary of releases

Copyright 2019, Pi Innovo 2

Release New features Fixes and improvements Backwards Firmware

Copyright 2019, Pi Innovo 3

Release New features Fixes and improvements Backwards Firmware

Copyright 2019, Pi Innovo 4

Release New features Fixes and improvements Backwards Firmware

Copyright 2019, Pi Innovo 5

Release New features Fixes and improvements Backwards Firmware

Copyright 2019, Pi Innovo 6

Release New features Fixes and improvements Backwards Firmware

Copyright 2019, Pi Innovo 7

Release New features Fixes and improvements Backwards Firmware

Copyright 2019, Pi Innovo 8

Release New features Fixes and improvements Backwards Firmware

Copyright 2019, Pi Innovo 9

Release New features Fixes and improvements Backwards Firmware

Copyright 2019, Pi Innovo 10

2.1.1. Third party tool requirements

2.1.2. Third party tool requirements — C-API

• Wind River Diab compiler

Copyright 2019, Pi Innovo 11

2.1.3. Third party tool requirements — Simulink-API

• MATLAB (base product)

• Simulink (to develop the models)

• Simulink Coder (to generate C code from the models)

• MATLAB Coder (Simulink Coder depends on this)

• Embedded Coder (to generate C code from the models)

• Wind River Diab compiler

• GCC compiler (free compiler but with known issues)

2.1.4. Third party tool requirements — installation

Copyright 2019, Pi Innovo 12

32-bit: R2013a, R2013b, R2014a, R2014b, R2015a, R2015b

• ETAS INCA calibration tool (version 7.2)

• Simulink Coder, formerly Real-Time Workshop, (optional) versions:

32-bit: R2013a, R2013b, R2014a, R2014b, R2015a, R2015b

• Embedded Coder, formerly Real-Time Workshop Embedded Coder, (optional) versions:

32-bit: R2013a, R2013b, R2014a, R2014b, R2015a, R2015b

32-bit: R2013a, R2013b, R2014a, R2014b, R2015a, R2015b

• Wind River (Diab) C compiler (version 5.9.0.0) for M670 target

• PiSnoop (any version)

• ATI Vision calibration tool (version 2.5 through 4.0)

• Vector CANape calibration tool (version 8.0 through 13.0)

2.1.5. Third party tool requirements — compatibility

Table 2.1. Third party tool compatibility

Copyright 2019, Pi Innovo 13

Third party tool Compatible versions

Third party tool Replacement

Copyright 2019, Pi Innovo 14

Third party tool Replacement

2.2. Installing OpenECU

The installation process starts with an introduction. Select Next to continue.

Copyright 2019, Pi Innovo 15

Copyright 2019, Pi Innovo 16

The following table breaks out each of the components:

Table 2.2. Install components