OpenECU Developer Software Installation and Release Note

Release 2.9.0 (r2020-1)

13-Apr-2020


Table of Contents

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

Chapter 1. Release details

This document details generic release version 2.9.0 (r2020-1) of the OpenECU developer software and related tools, created on 13-Apr-2020. 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.

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

ReleaseNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
2.9.0 (r2020-1) Code generation,
Communications,
Diagnostics (communications and fault handling),
Target ECU,
Third party tool support
Application programming interface,
Calibration,
Code generation,
Communications,
User documentation,
Examples,
Input/output drivers,
Target ECU
NoYes
2.8.1 (m670-sat-inj-1) Input/output driversNoYesNo
2.8.0 (ptac-1) NoNoYesNo
2.8.0 (r2019-1) Application programming interfaceApplication programming interface,
Calibration,
Code generation,
Communications,
User documentation,
Input/output drivers,
Target ECU,
Third party tool support
NoYes
2.7.0 (r2017-1) User documentation,
Input/output drivers,
Third party tool support
Application programming interface,
Code generation,
Communications,
Diagnostics (communications and fault handling),
User documentation,
Examples,
Input/output drivers,
Target ECU,
Third party tool support
NoYes
2.6.0 (r2016-1) Application programming interface,
Calibration,
Communications,
User documentation,
Input/output drivers,
Target ECU,
Third party tool support
Application programming interface,
Calibration,
Code generation,
Communications,
Diagnostics (communications and fault handling),
User documentation,
Input/output drivers,
Target ECU
NoYes
2.5.0 (r2015-2) Application programming interface,
Code generation,
User documentation,
Examples,
Installation,
Input/output drivers,
Real-time operating system,
Target ECU,
Third party tool support
Application programming interface,
Calibration,
Code generation,
Diagnostics (communications and fault handling),
User documentation,
Examples,
Input/output drivers,
Target ECU,
Third party tool support
NoYes
2.4.1 (r2015-1-sp1) Input/output driversApplication programming interface,
Code generation,
Communications,
Firmware (boot and reprogramming),
Input/output drivers
YesYes
2.4.0 (r2015-1) Application programming interface,
Diagnostics (communications and fault handling),
User documentation,
Firmware (boot and reprogramming),
Installation,
Input/output drivers,
Target ECU,
Third party tool support
Application programming interface,
Calibration,
Code generation,
Communications,
Developer and supporting scripts/documentation,
Diagnostics (communications and fault handling),
User documentation,
Examples,
Firmware (boot and reprogramming),
Input/output drivers,
Non-volatile storage,
Real-time operating system,
Third party tool support
NoYes
2.3.0 (r2014-1) Application programming interface,
Calibration,
Code generation,
Developer and supporting scripts/documentation,
Diagnostics (communications and fault handling),
User documentation,
Firmware (boot and reprogramming),
Installation
Application programming interface,
Calibration,
Code generation,
Developer and supporting scripts/documentation,
Diagnostics (communications and fault handling),
User documentation,
Examples,
Installation,
Input/output drivers,
Non-volatile storage,
Real-time operating system,
Target ECU
NoYes
2.2.0 (r2013-2) Application programming interface,
Calibration,
Code generation,
Communications,
Desktop integration,
Diagnostics (communications and fault handling),
User documentation,
Examples,
Firmware (boot and reprogramming),
Target ECU
Application programming interface,
Calibration,
Code generation,
Communications,
Diagnostics (communications and fault handling),
User documentation,
Firmware (boot and reprogramming)
NoYes
2.1.0 (r2013-1) Application programming interface,
Calibration,
Code generation,
Diagnostics (communications and fault handling),
User documentation,
Installation,
Input/output drivers,
Target ECU
Application programming interface,
Calibration,
Code generation,
Communications,
Diagnostics (communications and fault handling),
User documentation,
Examples,
Firmware (boot and reprogramming),
Installation,
Input/output drivers,
Target ECU
NoYes
2.0.0 (r2012-1) Application programming interface,
Desktop integration,
User documentation,
Examples,
Target ECU
Application programming interface,
Calibration,
Code generation,
Communications,
Desktop integration,
Developer and supporting scripts/documentation,
Diagnostics (communications and fault handling),
User documentation,
Firmware (boot and reprogramming),
Installation,
Input/output drivers,
Non-volatile storage,
Target ECU
NoYes
1.9.2Target ECUCalibration,
Code generation,
Communications,
Diagnostics (communications and fault handling),
Input/output drivers,
Non-volatile storage,
Target ECU
NoYes
1.9.1Application programming interface,
Communications,
Diagnostics (communications and fault handling),
Input/output drivers,
Target ECU
Application programming interface,
Calibration,
Code generation,
Communications,
Diagnostics (communications and fault handling),
Firmware (boot and reprogramming),
Input/output drivers,
Target ECU
NoYes
1.9.0Application programming interface,
Calibration,
Code generation,
Communications,
Desktop integration,
Diagnostics (communications and fault handling),
Firmware (boot and reprogramming),
Input/output drivers,
Non-volatile storage,
Target ECU
Application programming interface,
Calibration,
Code generation,
Communications,
Developer and supporting scripts/documentation,
Diagnostics (communications and fault handling),
User documentation,
Examples,
Firmware (boot and reprogramming),
Installation,
Input/output drivers,
Target ECU
NoYes
1.8.6NoInput/output driversYesNo
1.8.5Application programming interface,
Calibration,
Diagnostics (communications and fault handling),
Input/output drivers
Application programming interface,
Code generation,
Communications,
Input/output drivers
NoNo
1.8.4CommunicationsApplication programming interfaceYesYes
1.8.3Application programming interface,
Diagnostics (communications and fault handling),
Firmware (boot and reprogramming),
Input/output drivers,
Real-time operating system,
Target ECU
Application programming interface,
Calibration,
Code generation,
Communications,
Input/output drivers,
Real-time operating system,
Target ECU
NoYes
1.8.2Application programming interfaceApplication programming interface,
Code generation,
Communications,
Input/output drivers,
Non-volatile storage,
Target ECU
NoNo
1.8.1Application programming interface,
Code generation,
Communications,
Input/output drivers,
Real-time operating system,
Target ECU
Application programming interface,
Calibration,
Communications,
Examples,
Input/output drivers,
Target ECU
NoYes
1.8.0Application programming interface,
Communications,
Target ECU
Calibration,
Code generation,
Communications,
Examples,
Target ECU
NoNo
1.7.5Application programming interface,
Input/output drivers
Code generation,
Communications,
Non-volatile storage
NoNo
1.7.4Target ECUNoYesNo
1.7.3Application programming interface,
Target ECU
Application programming interface,
Calibration,
Examples,
Input/output drivers
NoYes
1.7.2NoNoYesNo
1.7.1Application programming interfaceApplication programming interface,
Target ECU
NoNo
1.7.0Calibration,
Input/output drivers,
Target ECU
Communications,
Input/output drivers
YesNo
1.6.4Code generationCalibration,
Code generation,
Communications,
Input/output drivers,
Target ECU
YesYes
1.6.3NoInput/output drivers,
Memory emulation,
Target ECU
NoNo
1.6.2Communications,
Diagnostics (communications and fault handling)
Calibration,
Communications,
Examples,
Installation,
Input/output drivers,
Non-volatile storage,
Target ECU
NoYes
1.6.1Target ECUApplication programming interface,
Target ECU
YesYes
1.5.9NoApplication programming interface,
Calibration,
Communications,
Examples,
Memory emulation,
Target ECU
YesNo
1.5.8NoApplication programming interface,
Installation,
Input/output drivers
YesNo
1.5.7NoCalibrationYesNo
1.5.6NoApplication programming interface,
Input/output drivers
YesNo
1.5.5NoNon-volatile storageYesNo
1.5.4Memory emulationCalibration,
Installation,
Target ECU
YesNo
1.5.3NoCalibration,
Communications
YesNo
1.5.2NoCommunicationsYesNo
1.5.13Calibration,
Code generation,
Communications,
Input/output drivers,
Non-volatile storage
Application programming interface,
Calibration,
Communications,
Input/output drivers,
Memory emulation,
Non-volatile storage,
Target ECU
NoYes
1.5.12NoApplication programming interface,
Communications,
Installation,
Target ECU
YesNo
1.5.11NoNon-volatile storageYesNo
1.5.10Calibration,
Code generation,
Examples,
Target ECU
Application programming interface,
Calibration,
Code generation,
Installation,
Input/output drivers,
Target ECU
YesNo
1.5.1NoCommunicationsYesNo
1.5.0Application programming interface,
Calibration,
Communications,
Installation,
Input/output drivers
Application programming interface,
Calibration,
Code generation,
Communications,
Examples,
Input/output drivers,
Non-volatile storage,
Target ECU
NoNo
1.4.0Application programming interface,
Calibration,
Code generation,
Input/output drivers,
Non-volatile storage
Application programming interface,
Calibration,
Code generation,
Input/output drivers
YesNo
1.3.1NoCalibration,
Code generation,
Installation
YesNo
1.3.0Application programming interfaceInput/output driversYesNo
1.2.0Application programming interface,
Code generation,
Target ECU
Calibration,
Code generation,
Examples,
Input/output drivers
YesNo
1.1.0Calibration,
Communications,
Examples
Application programming interface,
Calibration,
Communications,
Input/output drivers
YesYes
1.0.9Communications,
Target ECU
Application programming interface,
Communications
YesNo
1.0.8Application programming interfaceCode generationYesNo
1.0.7Input/output drivers,
Target ECU
Code generation,
Communications,
Input/output drivers,
Target ECU
NoNo
1.0.6Input/output driversNoYesNo
1.0.5Communications,
Input/output drivers
Input/output driversYesNo
1.0.4Calibration,
Communications,
Input/output drivers,
Target ECU
NoYesYes
1.0.3NoApplication programming interface,
Input/output drivers
YesNo
1.0.2Input/output drivers,
Target ECU
Calibration,
Examples,
Input/output drivers
YesNo
1.0.12NoCommunications,
Input/output drivers
YesNo
1.0.11NoCode generationYesNo
1.0.10Input/output driversNoYesNo
1.0.1NoInput/output driversYesNo
1.0.0NoNoYesNo

Chapter 2. Installation

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

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): (see OpenECU Compatibility with Third Party Tools for a list of supported versions)

  • Embedded Coder, formerly Real-Time Workshop Embedded Coder, (optional): (see OpenECU Compatibility with Third Party Tools for a list of supported versions)

  • Stateflow: (see OpenECU Compatibility with Third Party Tools for a list of supported versions)

  • 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 toolCompatible versions
Operating systems
Microsoft Windows [a] 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

R2015a, R2015b (32-bit)
R2015a, R2015b, R2016a, R2016b, R2017a, R2017b, R2018a, R2018b, R2019a, R2019b, R2020a (64-bit)

MathWorks Simulink
MathWorks MATLAB Coder
MathWorks Simulink Coder [b]
MathWorks Embedded Coder
Compiler tools [c]
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
GCC Compiler [d] v4.7.3 for M110, M220, M250, M460, M461 and M670 targets
Reprogramming, data logging and calibration tools [e]
PiSnoopAny version
ATI Vision [f] [g] v2.5 through v5.1.2
ETAS INCAv7.2.7
Vector CANapev8.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 toolReplacement
MathWorks MATLAB R2015a MATLAB latest version (see Pi Innovo's website for a complete list of supported versions of MATLAB).
MathWorks MATLAB R2015b
MathWorks MATLAB R2016a
MathWorks MATLAB R2016b
MathWorks MATLAB R2017a
MathWorks MATLAB R2017b
WindRiver Diab 5.5.1.0WindRiver Diab 5.8.0 and 5.9.0

2.2. Installing OpenECU

The installer program, openecu_platform_2_9_0_r2020-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.

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.

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.

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

ComponentRequiredInstalled by defaultDescription
PlatformYesYesA selection of packages to install, including the C-API and Sim-API components.
OpenECU Sim-APIYesYesInstall the Simulink interface to OpenECU, documentation and support packages.
BlocksetYesYesInstall the OpenECU blockset.
Sim-API Manuals (HTML)(optional)YesInstall the OpenECU blockset, ECU Technical Specifications and other documentation in HTML format.
Sim-API Manuals (PDF)(optional)YesInstall the OpenECU blockset, ECU Technical Specifications and other documentation in PDF format.
Sim-API Examples(optional)YesInstall some examples of how to use the OpenECU blockset.
OpenECU C-APIYesYesInstall the OpenECU C-API files and libraries.
C-APIYesYesInstall the C interface to OpenECU, documentation and support packages.
C-API Manuals (HTML)(optional)YesInstall the OpenECU C-API User Guide, ECU Technical Specifications and other documentation in HTML format.
C-API Manuals (PDF)(optional)YesInstall the OpenECU C-API User Guide, ECU Technical Specifications and other documentation in PDF format.
C-API Examples(optional)YesInstall some examples of how to use the OpenECU C interface.
Extended Diagnostics Features(optional)NoInstall the On-Board Diagnostic (OBD) library. This library is available at extra cost.
PythonYesYesInstall the Python application. This application is used to provide build support when generating and compiling the model source code.
Tools(optional)NoInstalls additional OpenECU tools.
GCC(optional)YesInstalls the GNU Compiler Collection (v4.7.3) and related tools for OpenECU targets.
lmadmin installer(optional)NoInstalls the installers for the lmadmin license server from flexera.
FreeCCP(optional)NoInstalls the FreeCCP programming tool (note that this tool is provided without support or warranty).
Integration(optional)YesOptions to have the OpenECU installer integrate OpenECU with third party tools, like MATLAB and INCA.
MATLAB Integration(optional)YesDuring installation, the OpenECU blockset is integrated into MATLAB's PATH.
INCA-ProF Integration(optional)NoDuring installation, INCA-ProF is update to understand how to program an OpenECU.
Start Menu Shortcuts(optional)YesDuring installation, the Window's Start menu 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.

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.

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.

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.

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.

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

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.

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

2.5.2.1. Integration

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.

2.5.2.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.3. Microsoft Windows XP

2.5.3.1. Integration

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.3.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.4. MATLAB

2.5.4.1. Integration

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.

2.5.4.2. Known issues

  • Open: When loading an OpenECU model, 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

2.5.5.1. Integration

Unlike some other calibration tools, during installation there is nothing special to be done when integrating PiSnoop and OpenECU.

2.5.5.2. Known defects/issues

None.

2.5.6. ATI Vision

2.5.6.1. Integration

Unlike some other calibration tools, during installation there is nothing special to be done when integrating Vision and OpenECU.

2.5.6.2. Known defects/issues

  • 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

2.5.7.1. Integration

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.

2.5.7.2. Known defects/issues

None.

2.5.8. Vector CANape

2.5.8.1. Integration

Unlike some other calibration tools, during installation there is nothing special to be done when integrating CANape and OpenECU.

2.5.8.2. Known defects/issues

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:

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

2.5.9.3. Known issues

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

2.5.10. Wind River (Diab) C Compiler v5.8.0.0

2.5.10.1. Installation

The Wind River (Diab) compiler 5.8.0.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:

  • 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 Window's system path to include the absolute path to the compiler's bin directory.

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

    E.g., D:\Progra~1\diab\5_8_0_0\win32\bin\

2.5.10.2. Known defects

None identified.

2.5.10.3. Known issues

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

2.5.11. Wind River (Diab) C Compiler v5.9.0.0

2.5.11.1. Installation

The Wind River (Diab) compiler 5.9.0.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:

  • 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 Window's system path to include the absolute path to the compiler's bin directory.

  • 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 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_9_0_0\win32\bin\

2.5.11.2. Known defects

None identified.

2.5.11.3. Known issues

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

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

2.5.12.1. Installation

GCC is an optional component in the OpenECU installation and is installed by default.

2.5.12.2. Known defects

None identified.

2.5.12.3. Known issues

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

2.5.13.1. Installation

Python is a required component of the OpenECU installation.

2.5.13.2. Known defects

None identified.

2.5.13.3. Known issues

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

    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

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

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:

ECUReplacement
M460no replacement
M461no 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:

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

FunctionReplacement
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.
pss_set_switch()Replaced by pss_set_safety_switch() in version 1.7.3.

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

ToolReplacement
FreeCCP Replaced by PiSnoop (demo or trial available on request).

Third-party tools

The following third-party tool support will be removed in a future release.

Third party toolReplacement
MathWorks MATLAB R2015a MATLAB latest version (see Pi Innovo's website for a complete list of supported versions of MATLAB).
MathWorks MATLAB R2015b
MathWorks MATLAB R2016a
MathWorks MATLAB R2016b
MathWorks MATLAB R2017a
MathWorks MATLAB R2017b
WindRiver Diab 5.5.1.0WindRiver 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.

ECUReplacement
A450Replaced by M460 in version 2.1.0 (r2013-1).
G400Replaced by G850 in version 2.1.0 (r2013-1).
G800Replaced by G850 in version 2.1.0 (r2013-1).
G850Replaced by M670 in version 2.4.0 (r2015-1).
M001Replaced by X221 in version 2.1.0 (r2013-1).
M250 (revision 1) Replaced by M250 (revision 2) in version 2.1.0 (r2013-1). [a]
M250-00HNo replacement.
U82No replacement.
X221No replacement.
X657No 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 softwareReplacement
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:

BlockReplacement
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_PeriodInputReplaced by the pdx_PwmInput block.
pdx_StepperMotorOutputNo replacement.
pdx_SteppedOutputNo replacement.
pdx_TLE4953_InputNo replacement.
pem_AddRateForATIEmulatorNo replacement.
pj1939_Dm1Decode Replaced by the pj1939_Dm1Receive and pj1939_Dm1DecodeDtc blocks in version 2.6.0 (r2016-1).
pj1939_Dm2Decode Replaced by the pj1939_Dm2Receive and pj1939_Dm2DecodeDtc() blocks in version 2.6.0 (r2016-1).
pj1939_Dm6Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm12Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm16Transmit No replacement. Use the pj1939_PgTransmit block for this functionality.
pj1939_Dm23Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm27Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm28Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm29Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm31Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm41Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm42Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm43Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm44Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm45Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm46Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm47Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm48Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm49Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm50Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm51Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
pj1939_Dm52Transmit Replaced by the pj1939_TransmitDtcDm block in version 2.9.0.
ppp_ConfigurationNo replacement.
prtw_ConfigUsingRtwRsimNo replacement.
put_BitwiseOp Replaced by the bitwise operator blocks supplied by MathWorks as part of their Simulink block set.
put_Calmap1dTuneNo replacement.
put_Calmap2dTuneNo replacement.
put_CalValTuneNo 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:

FunctionReplacement
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.
pan_get_angular_ad_samples_fxd() Replaced by pan_config_angular_ad_var() 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).
pj1939_dm6_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm12_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm16_transmit() No replacement.
pj1939_dm23_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm27_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm28_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm29_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm31_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm41_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm42_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm43_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm44_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm45_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm46_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm47_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm48_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm49_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm50_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm51_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_dm52_transmit() Replaced by pj1939_ext_dtc_transmit() in version 2.9.0.
pj1939_pg_transmit() Replaced by pj1939_pdu1_transmit() and pj1939_pdu2_transmit() in version 2.2.0 (r2013-2).
pj1939_pdu1_transmit() Replaced by pj1939_pdu_transmit() in version 2.9.0.
pj1939_pdu2_transmit() Replaced by pj1939_pdu_transmit() in version 2.9.0.

The following C-API developer software tools are no longer supported and have been removed:

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

Third party toolReplacement
MATLAB R12.1By R2006b in version 1.9.0.
MATLAB R13 (SP1)
MATLAB R14 (SP2)
MATLAB R2006bBy R2007b in version 2.1.0 (r2013-1).
MATLAB R2007bBy R2008b in version 2.1.1.
MATLAB R2008a 
MATLAB R2008b 
MATLAB R2009aBy R2011a in version 2.5.0 (r2015-2).
MATLAB R2010a
MATLAB R2010b
MATLAB R2011aBy R2012a in version 2.7.0 (r2017-1).
MATLAB R2011b
MATLAB R2012aBy R2018a in version 2.8.0 (r2018-1).
MATLAB R2012b
MATLAB R2013aBy R2020a in version 2.9.0 (r2020-1).
MATLAB R2013b
MATLAB R2014a
MATLAB R2014b
MATLAB RSIM By RTMODEL in version 2.9.0 (r2020-1).
Wind River Diab compiler 4.4b By Diab compiler 5.5.1.0 in version 2.1.0 (r2013-1) (see Pi Innovo's website 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 for a complete list of supported versions the GCC compiler).

3.4.  Release 2.9.0 (r2020-1)

Release labelled release-2.9.0-r2020-1 from 13 April 2020. 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.


3.4.1. New features

New features introduced by this version, or significant changes to existing features.

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Added TargetLink integration block

    CR 4257 (F), affects Sim-API and C-API

    A new block ptl_TargetLinkIntegration was added to easily integrate TargetLink production code from a TargetLink model into an OpenECU model.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • XETK implementation

    CR 15487 (F), affects Sim-API and C-API

    This change affects hardware design and platform code to include an XETK interface. This interface significantly increases data flowrate in comparison to CAN based CCP.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Added J1939 multibus support

    CR 23456 (F), affects Sim-API and C-API

    OpenECU now supports J1939 communication on all CAN buses simultaneously. Each bus can be used as a single J1939 node.

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.

  • Added support for M220-0AU target

    CR 21547 (F), affects Sim-API and C-API

    Added support for the M220-0AU target, which supports M220-0AU and M220-XAU hardware options. This target differs from the M220-000 target in that it no longer supports any angular features, but adds support for quadrature decode inputs, 3 phase hall decode inputs, and a PWM output with synchronous analog input sampling. These new features can be used with the following blocks pdx_QuadratureDecode, pdx_QuadratureDecodeAndFrequencyInput, pdx_HallDecodeInput, and pdx_PWMOutputWithSyncSampling. See the user guide for details on each of the added interfaces.

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 MATLAB R2019a, R2019b, and R2020a

    CR 23687 (F), affects Sim-API

    OpenECU now integrates with MATLAB R2019a, R2019b, and R2020a. Starting with these releases, the build process has been updated based on the Toolchain approach instead of the Template Makefile approach. The format of the text printed to the Diagnostic Viewer during the build process has been modified due to this process, but the build process is functionally equivalent. No changes to application models are necessary.

  • Added a Simulink interface to configure application and calibration checksums

    CR 22868 (F), affects Sim-API and C-API

    Previously, application and calibration checksums could only be configured by modifying a makefile. Now, checksum configuration has been added to the Simulink model code generation configuration paramters for all OpenECU models

3.4.2. Fixes and improvements

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

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.

  • Prevent unnecessary model searches in the Simulink block callback functions.

    CR 24368 (F), affects Sim-API and C-API

    Several OpenECU Simulink blocks have callback functions which search the model to cross-check configuration settings or parameters. If several blocks require the same information, it is stored in persistent memory so that the model does not have to be searched multiple times. This change fixes a bug where the information was not always being stored in persistent memory, causing some searches to be performed many times.

  • Added Generic Key Field to PREG Retrieve Key block.

    CR 23508 (F), affects Sim-API and C-API

    Added a new field to the PREG Retrieve Key block for the SimAPI to allow users to be able to enter any generic key ID from the registry to retrieve it's corresponding value. Fixes an issue where the serial number in modern ECUs is not stored at the same key as the Legacy ECUs, and thus this field now allows users to enter the key manually in order to get the correct serial number depending on the ECU.

  • Fixed PCX queue emptier task which failed to run due to concurrency issues

    CR 23263 (F), affects Sim-API and C-API

    The pcx_qemptier_task was stopping even when there were still CAN messages queued for transmit and the task was not able to be rescheduled. The root cause was that the status variable controlling the pcx_qemptier_task was being incorrectly cleared even when there were CAN messages queued. This was because the read-modify-write operation of the variable was not protected. This variable was being altered from outside the interrupt context and was causing corruption and inconsistent memory states. The issue was fixed by suspending the scheduler around the read-modify-write of this status variable.

  • Resolved bug in ppid_pid where it was not accepting symbols for mask parameters

    CR 20001 (F), affects Sim-API and C-API

    Previously, the mask parameters for the ppid_pid block did not accept symbols and it would throw errors. A fix for this was identifid and applied.

  • Fixed Injection Duration limits to be from 0ms to 2097ms

    CR 18639 (F), affects Sim-API and C-API

    The pan_InjectorConfig block only allowed the injection durations within 0.1ms and 1ms. This limation was only software and the ptpu code accepted durations of [0, 4000]. This mismatch in the duration ranges was fixed.

  • Fixed issue where a function call generator triggering a referenced model subsystem caused build errors.

    CR 17877 (F), affects Sim-API

    When using a triggered subsystem in a referenced model, Simulink generates an asynchronous sample time in the referenced model and when building that referenced model and generating the corresponding capi file, it generates an angular task wherever it finds an asynchronous sample time. For targets, such has the M110, that do not support angular functionality this results in a build error. To fix this, the angular task is only generated if the model is not a referenced model, and if it is Simulink simply ignores it.

  • Fixed 'ModelReferenceCompliant' option to be set properly in the STF callback

    CR 15600 (F), affects Sim-API

    Model that were based on openecu_ert.tlc were reporting that they were not model reference compliant, this implies that the 'ModelReferenceCompliant' option was not being set correctly in the STF callback. The cause for this issue was that when setting the ModelReferenceCompliant option the oe_is_ert() function was being used however that function sometimes returned the incorrect model if the focus of the Simulink GUI changed during the callback. This implementation has been fixed to correctly set the ModelReferenceCompliant option when required.

  • Reformatted ADD_INCLUDES build path to use "/" style slashes instead of "\" slashes

    CR 15559 (F), affects Sim-API

    When compiling a Simulink model using GCC, that includes a custom C header file, the mk_model_common Makefile formats the path to these custom header files using Windows style "\" slashes instead of "/" which caused the model to not build successfully. This issue was fixed by reformatting "/" slashes with "\" slashes in all instances of the ADD_INCLUDES variable.

  • Fix broken mask worker for the ppid_Scaling block

    CR 15374 (F), affects Sim-API

    Previously, when using the ppid_Scaling block MATLAB would throw an error about a syntax error in the ppid_scaling_worker function, making the block unusable. This has been resolved and the block now works as expected.

  • Changed put_Identification block so that it now requires version numbers to be in the range [0, 255]

    CR 15259 (F), affects Sim-API and C-API

    In pfs.h, the app major/minor/sub-minor versions are all stored as U8's, but the put_Identification block allows for U16's to be set. In pfsl_fill_metadata() in pfs.c, the major/minor/sub-minor versions are all clipped to 255 just before writing the file to flash, but in pfs_fstat() in pfs.c, the version of the file read from flash are compared against the unclipped U16 value of the versions (i.e. "this_ver_wrote" field would be set to 0 for an app version > 255).

  • Fixed issue in Quadrature decode blocks to show correct IO for M670 and M110 ECUs.

    CR 14992 (F), affects Sim-API

    The pdx_QuadratureDecode and pdx_QuadratureDecodeAndFrequencyInput blocks incorrectly relied on an old obsolete IO mapping file, put_io_mapping.m, to populate the primary and secondary channels instead of using the new mapping file, oe_mapping_io.m. This issue has been fixed and those blocks now use the newer file.

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.

  • Added support for extended CCP IDs

    CR 25148 (F), affects Sim-API and C-API

    Added support for extended CCp IDs in A2L files for ATI Vision, INCA, and Canape. When building an application with the CCP setting "Use SRC extended ID" or "Use DTO extended ID" All A2L files that contain CCP information now properly set bit 31.

  • A2L variables not generated

    CR 15568 (F), affects Sim-API and C-API

    Fixed issue where some variables would not be generated or grouped correctly during A2L generation.

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Removed support for MATLAB 2013, MATLAB 2014, and RSIM

    CR 25028 (F), affects Sim-API

    Support for MATLAB 2013 and 2014 has been removed. Support for RSIM Simulink Code Generation has been removed.

  • Fixed CAPI A2L file generation regex bug

    CR 24598 (F), affects Sim-API and C-API

    In the capi_parse_dwarf python script that parses gcc's objdumb output, there was a bug in the regular expression that captures the tag of a debugging information entry (DIE). Previously the regex assumed that were would only ever be one digit for each DIE entry tag, this was found to be incorrect as the number could be more than 1 digit. The regex in question has now been updated to address this.

  • Revised RSIM deprecation message and recommendation

    CR 23281 (F), affects Sim-API

    It is recommended to use the blocks under "OpenECU/RealTime Workshop Utilities" to switch the build configuration from RSIM to ERT or RTMODEL.

  • Fix referenced model build errors with GCC

    CR 22637 (F), affects Sim-API and C-API

    This change fixes a build error where referenced models would not build with the GCC compiler due to backslashes '\' in some of the file paths.

  • Fix model reference builds including lower level model archives

    CR 22353 (F), affects Sim-API and C-API

    Previously, if a block in a model reference hierarchy included other model reference blocks multiple times in a hierarchy of model reference blocks, a build error could be raised due to duplicate instances of the archive files of the blocks. Now, the model reference archives are not included within other model reference archives, and all archives are linked together only when the top level model is built.

  • Resolved issue with put_Calmap2d block code generation when using the GCC compiler

    CR 18364 (F), affects Sim-API

    When using the put_Calmap2d block and building a model with the GCC compiler, the auto generated code attaches a OE_CAL identifier to one of the local variables used to call the C-API function for this block. In GCC this OE_CAL identifier is a section attribute and thus they can not be specified for local variables and the build fails. A fix was made to change how the code was generated by the build process such that the OE_CAL attribute is not used.

  • ASAP2 generation with Simulink data dictionaries

    CR 18344 (F), affects Sim-API

    Fixed a problem that excluded data dictionary files if the model was using a simulink data dictionary.

  • Added support for mpl data entries in Simulink ASAP2 files

    CR 18181 (F), affects Sim-API

    Previously .a2l files directly generated by Simulink would omit the standard platform mpl_ variables. These are now included in .a2l files directly generated by Simulink.

  • Warn and omit prefix-style a2l variable names less than four characters long

    CR 17975 (F), affects Sim-API and C-API

    Prefix-style data dictionary entries require that all variable names be at least four characters long. Any variables that do not meet this criteria (when using prefix-style data dictionary entries) are now omitted from the a2l file and appropriate warnings are produced.

  • Fixed inconsistencies in prefix-style DDE generation with 1x1 vector values

    CR 15407 (F), affects Sim-API and C-API

    Previously, prefix-style DDE files from simulink data dictionaries could be generated with both vector-prefixed names and scalar values. Now prefix-style ddes will generate with the variable type specified in the prefixed name.

  • Reduced missing x or y dde errors to warnings

    CR 15407 (F), affects Sim-API and C-API

    Previously an error would be produced if an x or y lookup dde were not found in the .elf file. This error has been replaced with a warning.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Fixed issues with CANdb message packing.

    CR 23130 (F), affects Sim-API and C-API

    Fixed packing of CANdb signals of "float" value type. Previously, scaling and offset were not applied to signals of this type.

    Fixed potential corruption of adjacent signals while packing fields that are not byte-aligned.

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.

  • Fix Two pot demo with S-Function

    CR 25255 (F), affects Sim-API

    The two pot demo with S-Function was previously implemented as a non-inlined S-Function, which is not supported by the OpenECU developer platform. This has been fixed, and the documentation updated. Further changes were made to detect and raise an error if a non-inlined S-Function is used within an application model, which could have undefined behavior.

  • Cleanup of SENT example for M110 and M670

    CR 21598 (F), affects Sim-API and C-API

    Previously the signal names in the model referenced pin XG4 which was not the correct pin used in the example for either target. The signal names have now been left generic to avoid confusion.

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.

  • pdx_Monitor functionality removed from the M110 platform

    CR 25413 (F), affects Sim-API and C-API

    pdx_Monitor conflicts with the other functions that are available on the A4, A13, B2, B3, B6, B13, B14, and B16 connector pins. Similar diagnostic capabilities can be achieved using the other input blocks.

  • Angular analog inputs sync issue resolved.

    CR 23581 (F), affects Sim-API and C-API

    This change resolves incorrect behavior of angular analog inputs when the sync offset is non-zero and the initialization routine runs after the first cycle. Also, a data-type issue is resolved in which the block pan_AngularAnalogInputVariable was referencing the input port for cylinder number for the angle datatype.

  • DI Pulse Spacing

    CR 22460 (F), affects Sim-API and C-API

    In previous releases, DI injector pulses with less than 0.2msec spacing could be cancelled due to interaction with the current control circuity programming. This has now been resolved for pulse spacing down to the level allowed at build (0.1ms).

  • Improvements in range of useable injection angles.

    CR 22006 (F), affects Sim-API and C-API

    • When the commanded injection angle plus the cylinder offset crossed a threshold (by advancing) which caused the timing to wrap from -360 to +360 (+ = retard), the injection would skip. Now resolved.

    • Attempts to operate at low speed (less than ~150rpm) would lead to erratic injection behavior. Now resolved.

    • Injection scheduling and drop dead angles were previously limited to 0 to 719.9 (although larger ranges of injector on angles were accepted, because only positive drop dead angles were accepted, use of negative injection angles was limited). Now injector start angles and drop dead angles of -720 to 720 are accepted in the pan_Injection_DI block.

  • Angular outputs no longer latch when duration is greater than 1 cycle

    CR 15473 (F), affects Sim-API and C-API

    The angular output was observed to latch to the active state when:

    • the requested duration was greater than one engine cycle.

    • allow cycle repeat was set to zero (false).

    • no further pulse requests were made.

    This modification prevents this situation.

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.

  • Fixed potential pfs_flush_all lockup.

    CR 24617 (F), affects Sim-API and C-API

    Fixed potential ECU lockup when using pfs_flush_all.

  • Added warnings for incorrect tlc configurations

    CR 23842 (F), affects Sim-API and C-API

    Added warnings for when the selected tlc file does not match the configuration model default.

  • Fixed UDS transport protocol.

    CR 23760 (F), affects Sim-API and C-API

    Fixed UDS messages longer then 8 bytes timing out.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.9.0-r2020-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Embedded software optimizations

    CR 23335 (F), affects Sim-API and C-API

    Optimizations were made to improve CPU throughput in the following areas: DTC match iterator, CAN buffer copies, CAN callbacks, and TLE8110 SPI driver.

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.

  • Corrected and added information in the M670 Tech Spec

    CR 24819 (F), affects Sim-API and C-API

    Corrected information on pins Y18 and Y53 and added missing information in sections 4.10. Analogue inputs and 4.32. Digital outputs.

  • Fixes issue in MATLAB R2018B where the images in the Simulink user guide are not displaying

    CR 22121 (F), affects Sim-API and C-API

    Previously, when the OpenECU Simulink User Guide was opened from within MATLAB 2018 or higher, all images and CSS files could not be found by MATLAB and resulted in formatting issues. A possible cause for this could be that in newer versions of MATLAB some sort of check was put into place that prevented it from accessing resources (such as images) that are not in the same directory as the HTML files. A fix was made to remedy this by setting the help location in MATLAB to a base folder that has these images, CSS and HTML files as subdirectories, and also moving the table of contents that links to each HTML file to this folder as-well.

  • Corrected information in the M670 Tech Spec

    CR 22059 (F), affects Sim-API and C-API

    Digital inputs XF3, Y34, and Z12 previously displayed a voltage range of 0V to 5V. Those pins have been corrected to say 0V to VPwr, but it has been noted that 0V to 5V is preferred.

  • Updated the M220 Technical Specification with a note about Hall effect sensors

    CR 17928 (F), affects Sim-API and C-API

    The note reads: Reading a Hall effect sensor may require an external pull up resistor or a pull up resistor added as a custom option.

3.4.3. Outstanding issues

  • Simultaneous receive of J1939 PGNs on multiple buses

    CR 25039 (F), affects Sim-API and C-API

    When the same PGN is received on multiple buses within the same model iteration, including DM7 test requests or PG requests, unexpected behavior may occur.

  • Limitations on M110 CAN channels C and D

    CR 21783 (F), affects Sim-API and C-API

    The M110 uses a SPI-to-CAN ASIC for CAN channels C and D. There are known limitations on these CAN buses which can limit the message bandwidth capability, and occasionally CAN message data may get corrupted.

  • Errors integrating with ETAS INCA calibration tool during OpenECU installation

    CR 10955 (F), affects Sim-API and C-API

    When integrating OpenECU with the ETAS INCA calibration tool during OpenECU installation, there is a problem with part of the installation 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

    CR 10386 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.9.0-r2020-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • 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

    CR 8766 (W), affects Sim-API and C-API

  • J1939 PG transmit and PG receive interfaces do not correctly determine the CAN bus off condition

    CR 8754 (W), affects Sim-API and C-API

    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

    CR 8752 (W), affects Sim-API and C-API

    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

    CR 8743 (W), affects Sim-API and C-API

    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

    CR 8499 (W), affects Sim-API

    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

    CR 8259 (W), affects Sim-API and C-API

    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

    CR 8259 (W), affects Sim-API and C-API

    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

    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

    CR 7370 (W), affects Sim-API

    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

    CR 7082 (W), affects Sim-API and C-API

    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

    CR 7072 (W), affects Sim-API and C-API

    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

    CR 7070 (W), affects Sim-API and C-API

    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

    CR 6502 (W), affects Sim-API

    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

    CR 5787 (W), affects Sim-API and C-API

    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

    CR 5786 (W), affects Sim-API and C-API

    There is a known issue with the J1939 protocol stack implemented in the OpenECU platform:

    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.

  • Support for ETAS INCA v5.1.2 has not been fully verified

    CR 1875 (W), affects Sim-API and C-API

    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.8.1 (m670-sat-inj-1)

Release labelled release-2.8.1-m670-sat-inj-1 from 16 December 2019. 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.2.  Release summary for v2.8.1-m670-sat-inj-1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API14910 (F)No CRsYesNo
Sim-API14910 (F)No CRsYesNo

3.5.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Updated M670 injectors to support saturating injectors on M670B hardware

    CR 14910 (F), affects Sim-API and C-API

    The M670 platform has been updated to support driving saturating injectors identical to the M670S behavior on an M670B module, without hardware modification. For details please contact OpenECU support.

3.6.  Release 2.8.0 (ptac-1)

Release labelled release-2.8.0-ptac-1 from 8 April 2019. This release is marked as internal meaning the release is for Pi internal use only. The following table provides quick access to each of the changes.

Table 3.3.  Release summary for v2.8.0-ptac-1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
Sim-APINo CRsNo CRsYesNo

3.6.1. New features

New features introduced by this version, or significant changes to existing features.

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


3.7.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 R2018b.

    CR 21786 (F), affects Sim-API

    OpenECU now integrates with MATLAB R2018b.

  • Added support for MATLAB R2018a.

    CR 21209 (F), affects Sim-API

    OpenECU now integrates with MATLAB R2018a. Support or RSIM has been deprecated. (RSIM is still included but will not work with Matlab 2018a and on)

  • 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.7.2. Fixes and improvements

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

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.

  • Put_identification block no longer modifies data dictionary unintentionally

    CR 15523 (F), affects Sim-API

    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

    CR 15331 (F), affects Sim-API

    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

    CR 19317 (F), affects Sim-API

    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

    CR 15679 (F), affects Sim-API

    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

    CR 18616 (F), affects Sim-API

    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

    CR 15406 (F), affects Sim-API and C-API

    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

    CR 20435 (F), affects Sim-API and C-API

    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

    CR 20431 (F), affects Sim-API and C-API

    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.

    CR 20339 (F), affects Sim-API and C-API

    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

    CR 19126 (F), affects Sim-API and C-API

    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)

    CR 18354 (F), affects Sim-API and C-API

    Corrected an error in the platform that prevented the ASAP2 2D and ND lookup tables

  • Build Warnings

    CR 18208 (F), affects Sim-API and C-API

    Added the ability for customers to turn off the build warnings for openecu variables exceeding variable character limit

  • CPU Loading Optimization

    CR 18177 (F), affects Sim-API and C-API

    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.

  • Prevent loss of cam edge information when cam edge crosses cycle boundary.

    CR 21871 (F), affects Sim-API and C-API

    The eTPU code which records the position and direction of camshaft tooth edges ptpu_cam.c previously reset every cycle. Camshaft phasing or jitter which moved one of the camshaft edges across the cycle boundary at the second tooth after the missing tooth region would cause an extra edge to occur in one cycle, and a missing edging in the adjacent cycle. This caused the loss of one camshaft edge until that cycle had passed. By resetting the camshaft edge log index only after the calibrated number of edges had occurred in ptpu_cam.c all edges are now recorded, but the order of the log no longer matches the previous methods. The index is therefore offset in ptpu_pan_cam_in.c prior to output as an array from pan_CamWheelToothEdgeAngles. The edge log arrangement is therefore preserved from previous software levels, with the exception that when an edge would have been lost for a cycle, this no longer happens and all edges shift immediately.

  • Correction to UEGO device initialisation

    CR 20429 (F), affects Sim-API and C-API

    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

    CR 20429 (F), affects Sim-API and C-API

    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

    CR 20392 (F), affects Sim-API and C-API

    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

    CR 20151 (F), affects Sim-API and C-API

    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

    CR 20151 (F), affects Sim-API and C-API

    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

    CR 20151 (F), affects Sim-API and C-API

    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

    CR 19918 (F), affects Sim-API and C-API

    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

    CR 19851 (F), affects Sim-API

    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

    CR 19537 (F), affects Sim-API and C-API

    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

    CR 18444 (F), affects Sim-API and C-API

    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

    CR 18237 (F), affects Sim-API and C-API

    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.

    CR 18630 (F), affects Sim-API and C-API

    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.

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.

  • CANape reprogramming of rebuilt application

    CR 21807 (F), affects Sim-API and C-API

    The CANape A2L is now built to define memory regions based on the total region size, not used memory in the region. This allows the same device database configuration to be used even if the application size changes when rebuilt.

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.

  • Corrected tech spec for FEPS pin

    CR 21314 (F), affects Sim-API and C-API

    Previously the M110 tech spec incorrectly stated that pin A16 could be used for FEPS, analog input, or digital input. This pin can only be used for FEPS so the tech spec has been updated accordingly.

  • Updates to 3rd party tool compatibility

    CR 21192 (F), affects Sim-API and C-API

    Updated versions of 3rd party tools supported by OpenECU and recommended Simulink model configuration settings.

  • Corrected cutoff frequency for m110 tech spec pin B4

    CR 21138 (F), affects Sim-API and C-API

    The M110 tech spec stated the cutoff frequency for pin B4 analog input was 1.06kHZ. This is now corrected to 574Hz.

  • Removed IMU references from tech spec for M250

    CR 20334 (F), affects Sim-API and C-API

    Removed the references to IMU for the M250.

  • Fixed M110 tech spec error with pin B11

    CR 18711 (F), affects Sim-API and C-API

    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

    CR 18566 (F), affects Sim-API and C-API

    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

    CR 15737 (F), affects Sim-API and C-API

    Fixed some incorrect voltage ranges in the m110 tech spec.

  • Added a clarification for the M110 tech spec

    CR 15414 (F), affects Sim-API and C-API

    Added a clarification to the M110 tech spec for Pin A5 to clarify that the pin has 2 default functions.

3.8.  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. The following table provides quick access to each of the changes.


3.8.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Added injector and spark schedule feedback interfaces

    CR 14965 (F), affects Sim-API and C-API

    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

    CR 14964 (F), affects Sim-API and C-API

    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

    CR 14955 (F), affects Sim-API and C-API

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

    CR 14851 (F), affects Sim-API

    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

User documentation covers technical specifications for each ECU, user guides or reference manuals, installation guides and release notes, in HTML and PDF formats.

  • Added information about when DTCs are cleared after reprogramming

    CR 17945 (F), affects Sim-API and C-API

    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.

3.8.2. Fixes and improvements

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

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.

  • Correction to creating an OpenECU model

    CR 18113 (F), affects Sim-API

    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

    CR 17980 (F), affects Sim-API

    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

    CR 15788 (F), affects Sim-API

    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'

    CR 15340 (F), affects Sim-API

    Previously, a warning message about dummy_marque_06 would be raised when a model was loaded. This has been resolved.

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

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

    CR 18359 (F), affects Sim-API

  • Correction to oe_create_model command for the M550 and M670 targets

    CR 18110 (F), affects Sim-API

    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

    CR 15635 (F), affects Sim-API

    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

    CR 15408 (F), affects Sim-API and C-API

    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

    CR 15394 (F), affects Sim-API and C-API

    Previously, the ASAP2 module name could contain an a character prohibited by ASAP2. Now, the ASAP2 module name is fully compliant.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Support for J1939 PGNs with non-zero Data Page

    CR 18193 (F), affects Sim-API and C-API

    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

    CR 15416 (F), affects Sim-API and C-API

    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

    CR 15522 (F), affects Sim-API and C-API

    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

    CR 15663 (F), affects Sim-API

    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

    CR 15340 (F), affects Sim-API

    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.

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.

  • Failure to allocate stack correctly on Time Processing Unit

    CR 17968 (F), affects Sim-API and C-API

    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 in possible corruption of some eTPU parameters. This has now been rectified.

  • Correction to analogue input sampling for long application initialisations

    CR 15748 (F), affects Sim-API and C-API

    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

    CR 15361 (F), affects Sim-API

    With reference to CR (?), changes have been made to the channel names of M670 knock processing pins.

    FromTo
    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

    CR 15251 (F), affects Sim-API and C-API

    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

    CR 15224 (F), affects Sim-API and C-API

    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

    CR 14941 (F), affects Sim-API and C-API

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

    CR 12324 (F), affects Sim-API and C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • M110 repeated resets with certain applications

    CR 18373 (F), affects Sim-API and C-API

    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.

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.

  • Build process failing to clean up archives after quick appends

    CR 17967 (F), affects Sim-API

    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

    CR 15389 (F), affects Sim-API and C-API

    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.

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.

  • Updated the M670 Technical Specification regarding the use of the UEGO at 24V

    CR 17974 (F), affects Sim-API and C-API

  • Added information about crimp tools to the M220 and M250 Technical Specifications

    CR 17956 (F), affects Sim-API and C-API

  • Updated the M110 Technical Specification to note that ignition-less reprogramming is not supported

    CR 17923 (F), affects Sim-API and C-API

    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

    CR 17864 (F), affects Sim-API and C-API

    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

    CR 15296 (F), affects Sim-API and C-API

    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

    CR 15295 (F), affects Sim-API and C-API

    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.

3.9.  Release 2.6.0 (r2016-1)

Release labelled release-2.6.0-r2016-1 from 11 August 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.


3.9.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 CPU loading calculation performed each second

    CR 14410 (F), affects Sim-API and C-API

    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

    CR 11972 (F), affects Sim-API and C-API

    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

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.

  • Support for ETAS XETK-V2.0A emulator test probe

    CR 13476 (F), affects Sim-API and C-API

    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

    CR 10766 (F), affects Sim-API and C-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Added support for M110 CAN C and D

    CR 14793 (F), affects Sim-API and C-API

    The M110 now supports 4 CAN buses, CAN C and D use a mcp2515 CAN controller with SPI interface.

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.

  • Enabled SENT functionality for some M670 inputs

    CR 14477 (F), affects Sim-API and C-API

    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

    CR 14165 (F), affects Sim-API and C-API

    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

    CR 14163 (F), affects Sim-API and C-API

    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

    CR 13685 (F), affects Sim-API and C-API

    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

    CR 13580 (F), affects Sim-API and C-API

    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.

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.

  • Added support for the M110 target ECU

    CR 14800 (F), affects Sim-API and C-API

    Support has been added for the M110 target ECU.

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 to build M670 applications using GCC

    CR 11886 (F), affects Sim-API and C-API

    The OpenECU developer software has been extended to support application builds for the M670 target using the GCC compiler.

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.

  • Added M110 Technical Specifications

    CR 14915 (F), affects Sim-API and C-API

    File is released as 29T-068883TK-xx-M110-Technical-Specification.

3.9.2. Fixes and improvements

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

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.

  • Fixed issue in pj1939_PgReceive block, where outport signals can get disconnected

    CR 14995 (F), affects Sim-API and C-API

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

    CR 14953 (F), affects Sim-API and C-API

    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'

    CR 14384 (F), affects Sim-API

    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

    CR 14090 (F), affects Sim-API

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.

  • Fixed DDE generation to correctly handle spaces and tabs in the description field

    CR 15238 (F), affects Sim-API and C-API

    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

    CR 15161 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.6.0-r2016-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Fixes to data dictionary processing for fixed-point value support

    CR 10992 (F), affects Sim-API and C-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Removed large function warning during build process when the compiler is not Diab 5.5.1.0

    CR 14880 (F), affects Sim-API and C-API

    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

    CR 14869 (F), affects Sim-API and C-API

    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

    CR 14819 (F), affects Sim-API and C-API

    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

    CR 14778 (F), affects Sim-API

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

    CR 14754 (F), affects Sim-API

    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

    CR 14748 (F), affects Sim-API

    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

    CR 14732 (F), affects Sim-API

    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

    CR 14691 (F), affects Sim-API and C-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Fixed accidental limitation of CCP ODTs

    CR 15173 (F), affects Sim-API and C-API

    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

    CR 11328 (F), affects Sim-API

    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.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Improved robustness of freeze frame feature against uncontrolled shutdown

    CR 14661 (F), affects Sim-API and C-API

    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

    CR 14517 (F), affects Sim-API and C-API

    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

    CR 9630 (F), affects Sim-API and C-API

    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.

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.

  • Fixed an issue with the reported edge angles with multiple cam inputs on M670

    CR 15175 (F), affects Sim-API and C-API

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

    CR 15171 (F), affects Sim-API and C-API

    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

    CR 15166 (F), affects Sim-API and C-API

    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

    CR 15005 (F), affects Sim-API and C-API

    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

    CR 14866 (F), affects Sim-API and C-API

    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

    CR 14848 (F), affects Sim-API and C-API

    File is released as 29T-068883TK-xx-M110-Technical-Specification.

  • Increase number of cam wheel teeth supported in pan_CamWheelConfig

    CR 14719 (F), affects Sim-API and C-API

    Previous limit was 8 cam teeth. This change increases the limit to 13.

  • Clarified instructions on installing vendor daemon for lmadmin

    CR 14356 (F), affects Sim-API and C-API

    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

    CR 12656 (F), affects Sim-API and C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Adjusted linker allocations such that .sbss variables are less likely to be in external RAM

    CR 14750 (F), affects Sim-API and C-API

    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

    CR 11696 (F), affects Sim-API and C-API

    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

User documentation covers technical specifications for each ECU, user guides or reference manuals, installation guides and release notes, in HTML and PDF formats.

  • Fixed broken link in host ID pop-up

    CR 14993 (F), affects Sim-API and C-API

    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

    CR 14988 (F), affects Sim-API and C-API

    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

    CR 14757 (F), affects Sim-API and C-API

    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

    CR 14746 (F), affects Sim-API and C-API

    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

    CR 14720 (F), affects Sim-API and C-API

    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

    CR 14700 (F), affects Sim-API and C-API

    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

    CR 14671 (F), affects Sim-API and C-API

    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.

  • Knock detection interface documentation improvement

    CR 14639 (F), affects Sim-API and C-API

    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

    CR 14486 (F), affects Sim-API and C-API

    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

    CR 14136 (F), affects Sim-API and C-API

    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

    CR 12730 (F), affects Sim-API and C-API

    The timing resolution of injection durations was added to the C-API and Sim-API user guides.

  • Diagnostic lamp interface documentation corrected

    CR 11273 (F), affects Sim-API and C-API

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


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

  • Extended CCP to support 29-bit CAN identifiers

    CR 10780 (F), affects Sim-API and C-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Added instructions on integrating a TargetLink model into OpenECU

    CR 4257 (F), affects Sim-API and C-API

    The new document openecu_targetlink_model_integration describes the process of taking code generated from a TargetLink model and building it into OpenECU.

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.

  • Added an example that uses model referencing

    CR 13951 (F), affects Sim-API

    A simple example has been added to demonstrate model referencing with OpenECU.

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.

  • Addition of resistance based analog output for the M221 target

    CR 12209 (F), affects Sim-API and C-API

    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

    CR 13769 (F), affects Sim-API and C-API

    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

    CR 4239 (F), affects Sim-API and C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Removed support for deprecated ECU targets

    CR 13710 (F), affects Sim-API and C-API

    The following ECU targets are obsolete and longer supported:

    • G850
    • U82
    • X221
    • X657

  • Removed support for obsolete interfaces

    CR 13710 (F), affects Sim-API and C-API

    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_Calmap2dTune
    • 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()
    • 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

    CR 12174 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.5.0-r2015-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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 R2015b (32-bit and 64-bit)

    CR 14281 (F), affects Sim-API

    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

User documentation covers technical specifications for each ECU, user guides or reference manuals, installation guides and release notes, in HTML and PDF formats.

  • Add links from error codes to user documentation

    CR 13742 (F), affects Sim-API and C-API

    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.

3.10.2. Fixes and improvements

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

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.

  • Fixed pnv_AdaptiveMap1d Simulink simulation behavior

    CR 14285 (F), affects Sim-API

    Previously, the pnv_AdaptiveMap1d block would not correctly simulate in Simulink. This has been resolved.

  • Fixed unnecessary parameterisation of links to libraries

    CR 13944 (F), affects Sim-API

    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

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.

  • Fixed platform constants erroneously defined as calibrations

    CR 12341 (F), affects Sim-API and C-API

    The platform software had some constants incorrectly defined as calibrations. This has now been corrected.

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Fix to name length limit for Units, Enums/Constants, and Lookup variables in dde files

    CR 14593 (F), affects Sim-API and C-API

    Previously, an error would be raised if the number of characters used for units, enums, constants, or lookup variables exceeded 31 characters, 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

    CR 14044 (F), affects Sim-API

    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

    CR 8586 (F), affects Sim-API

    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 (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Diagnostics updates to DTC fault status bits and positive response suppression bit

    CR 14019 (F), affects Sim-API and C-API

    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

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.

  • Renamed extended_diagnostic_example

    CR 8586 (F), affects Sim-API

    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.

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.

  • Optimized injector high side drive on the M670B module to reduce faults

    CR 14592 (F), affects Sim-API and C-API

    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

    CR 14460 (F), affects Sim-API and C-API

    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

    CR 14341 (F), affects Sim-API and C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Fixed reprogramming driver sequence and timeout errors

    CR 14428 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.5.0-r2015-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Corrected M670 target platform library version

    CR 14338 (F), affects Sim-API and C-API

    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.

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.

  • Removed spaces from the name field in the INCA-ProF files for OpenECU targets

    CR 14388 (F), affects Sim-API and C-API

    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

User documentation covers technical specifications for each ECU, user guides or reference manuals, installation guides and release notes, in HTML and PDF formats.

  • M220 H-bridge ready signal clarification.

    CR 14548 (F), affects Sim-API and C-API

    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

    CR 14545 (F), affects Sim-API and C-API

    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

    CR 14544 (F), affects Sim-API and C-API

    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

    CR 14382 (F), affects Sim-API and C-API

    User documentation has been improved to specify the limitations of OpenECU CANdb interfaces regarding multiplexed messages.

  • Addressed M220 current monitor ambiguity

    CR 14241 (F), affects Sim-API and C-API

    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

    CR 14075 (F), affects Sim-API and C-API

    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

    CR 14028 (F), affects Sim-API and C-API

    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

    CR 14027 (F), affects Sim-API and C-API

    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.

    CR 13601 (F), affects Sim-API and C-API

    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.

    CR 13572 (F), affects Sim-API and C-API

    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

    CR 12626 (F), affects Sim-API and C-API

    Example application loom diagrams have been updated to specify CAN termination details.

  • M220 output warning for power supply under/over voltage.

    CR 9400 (F), affects Sim-API and C-API

    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.

    CR 8784 (F), affects Sim-API and C-API

    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.11.  Release 2.4.1 (r2015-1-sp1)

Release labelled release-2.4.1-r2015-1-sp1 from 2 November 2015. 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.8.  Release summary for v2.4.1-r2015-1-sp1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API14066 (F), 14065 (F)14168 (F), 13937 (F), 13926 (F), 7095 (F)YesYes, see:
14168 (F),
14065 (F)
Sim-API14066 (F), 14065 (F)14210 (F), 14168 (F), 14097 (F), 13937 (F),
13926 (F), 7095 (F)
YesYes, see:
14168 (F),
14065 (F)

3.11.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Added injector high side voltage monitors for M670

    CR 14066 (F), affects Sim-API and C-API

    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.

  • Updates to M670 I/O for recent hardware changes

    CR 14065 (F), affects Sim-API and C-API

    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 enable this functionality, the ECU's firmware must be upgraded 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.

3.11.2. Fixes and improvements

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

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.

  • Fixed an issue which caused warnings when a model was reopened without clearing the workspace

    CR 14097 (F), affects Sim-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

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

    CR 14210 (F), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Added documentation about how reprogramming inhibiting works when the application does not use the inhibit functionality

    CR 7095 (F), affects Sim-API and C-API

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

    CR 14168 (F), affects Sim-API and C-API

    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 enable this functionality, the ECU's firmware must be upgraded 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.

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 M670N Z18 and Z29 waveforms set with the wrong channel

    CR 13937 (F), affects Sim-API and C-API

    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

    CR 13926 (F), affects Sim-API and C-API

    Previously, the M670 5A H-bridge would trigger a false current trip if invalid parameters were supplied. This issue has been fixed.

3.12.  Release 2.4.0 (r2015-1)

Release labelled release-2.4.0-r2015-1 from 13 July 2015. 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.9.  Release summary for v2.4.0-r2015-1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API13662 (F), 13654 (F), 13499 (F), 13019 (F),
12978 (F), 12906 (F), 12905 (F), 12723 (F),
12679 (F), 12672 (F), 12671 (F), 12463 (F),
12349 (F), 12345 (F), 12281 (F), 12279 (F),
12087 (F), 11969 (F), 11683 (F), 11680 (F),
11679 (F), 11678 (F), 11677 (F), 11674 (F),
11594 (F), 10382 (F), 9683 (F), 9657 (F),
8678 (F)
13894 (F), 13854 (F), 13781 (F), 13720 (F),
13690 (F), 13647 (F), 13573 (F), 13519 (F),
13468 (F), 13256 (F), 13099 (F), 12841 (F),
12458 (F), 12200 (F), 11891 (F), 11706 (F),
11559 (F), 11298 (F), 11058 (F), 10778 (F),
10395 (F)
No, see:
13099 (F),
12672 (F),
11683 (F),
11679 (F),
11559 (F),
8678 (F)
Yes, see:
13099 (F),
13019 (F),
12905 (F),
12841 (F),
12463 (F),
12200 (F)
Sim-API13662 (F), 13654 (F), 13499 (F), 13309 (F),
13019 (F), 12978 (F), 12906 (F), 12905 (F),
12723 (F), 12686 (F), 12685 (F), 12684 (F),
12679 (F), 12672 (F), 12671 (F), 12463 (F),
12349 (F), 12345 (F), 12281 (F), 12279 (F),
12087 (F), 11969 (F), 11683 (F), 11680 (F),
11679 (F), 11678 (F), 11677 (F), 11674 (F),
11594 (F), 11552 (F), 10942 (F), 10382 (F),
9683 (F), 9657 (F), 8678 (F)
13894 (F), 13854 (F), 13829 (F), 13781 (F),
13720 (F), 13690 (F), 13656 (F), 13647 (F),
13573 (F), 13519 (F), 13468 (F), 13325 (F),
13256 (F), 13170 (F), 13099 (F), 12841 (F),
12773 (F), 12458 (F), 12200 (F), 12010 (F),
11891 (F), 11706 (F), 11299 (F), 11298 (F),
11058 (F), 11037 (F), 10778 (F), 10395 (F),
9682 (F), 9586 (F), 4440 (F)
No, see:
13099 (F),
12672 (F),
11683 (F),
11679 (F),
8678 (F)
Yes, see:
13099 (F),
13019 (F),
12905 (F),
12841 (F),
12463 (F),
12200 (F)

3.12.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 platform interfaces for the application to retrieve stable and unstable reset counts

    CR 12906 (F), affects Sim-API and C-API

    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.

    CR 12686 (F), affects Sim-API

    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

    CR 12349 (F), affects Sim-API and C-API

  • Added continuously running memory tests for the primary processor's eTPU peripheral

    CR 11969 (F), affects Sim-API and C-API

    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 functionSimulink blockC-API function
    Direct injectionpan_InjectionSetpoint_DIpan_get_injection_di_setpoint()
    Port injectionpan_InjectionSetpoint_GPIpan_get_injection_gpi_setpoint()
  • Added continuously running memory tests for the primary processor

    CR 11683 (F), affects Sim-API and C-API

    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

    CR 10942 (F), affects Sim-API

    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.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • J1939-73 (2013) specification update — new DM7 option added to get all OBD test results for all required monitors

    CR 12672 (F), affects Sim-API and C-API

    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

    CR 12671 (F), affects Sim-API and C-API

    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

    CR 12463 (F), affects Sim-API and C-API

    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.

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.4.0-r2015-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added definition of functional receive ID in piso_Configuration block

    CR 11552 (F), affects Sim-API

    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

    CR 8678 (F), affects Sim-API and C-API

    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.

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.

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

    CR 13019 (F), affects Sim-API and C-API

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.4.0-r2015-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Improved checksum tests for boot and reprogramming modes

    CR 12905 (F), affects Sim-API and C-API

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.4.0-r2015-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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.

  • Extended support for up to 12 cylinders on the M670

    CR 13662 (F), affects Sim-API and C-API

  • Extended support for up to 16 injector outputs on the M670

    CR 13654 (F), affects Sim-API and C-API

    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

    CR 12978 (F), affects Sim-API and C-API

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

  • Added PDD digital data feature

    CR 12723 (F), affects Sim-API and C-API

    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

    CR 12679 (F), affects Sim-API and C-API

    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

    CR 12345 (F), affects Sim-API and C-API

    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

    CR 12281 (F), affects Sim-API and C-API

    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

    CR 12279 (F), affects Sim-API and C-API

    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

    CR 11680 (F), affects Sim-API and C-API

    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.

    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

    CR 11679 (F), affects Sim-API and C-API

    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

    CR 11678 (F), affects Sim-API and C-API

    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

    CR 11677 (F), affects Sim-API and C-API

    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)

    CR 9683 (F), affects Sim-API and C-API

    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

    CR 9657 (F), affects Sim-API and C-API

    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

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.

  • Added generation of license information to installer

    CR 13499 (F), affects Sim-API and C-API

    Upon installation, a new file will appear containing the license HOSTID information as well as instructions on retrieving a license.

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.

  • Added support for the M670 target ECU

    CR 11594 (F), affects Sim-API and C-API

    Support has been added for the M670 target ECU, which comes in three varieties:

    ECUBuild option
    M670B
    01T-068787-000 Issue 2
    Non-overlapping boosted peak and hold solenoid injectors
    M670N
    01T-068803-000 Issue 1
    Overlapping non-boosted peak and hold solenoid injectors
    M670S
    01T-068850-000 Issue 1
    Overlapping saturating solenoid injectors

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

    CR 10382 (F), affects Sim-API and C-API

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 R2015a (32-bit and 64-bit)

    CR 13309 (F), affects Sim-API

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

    CR 12685 (F), affects Sim-API

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

    CR 12684 (F), affects Sim-API

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.

  • Updated terms of the license agreement

    CR 12087 (F), affects Sim-API and C-API

    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

    CR 11674 (F), affects Sim-API and C-API

    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.

3.12.2. Fixes and improvements

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

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.

  • Default stack size increased to 8192 bytes

    CR 13781 (F), affects Sim-API

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

    CR 13781 (F), affects C-API

    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

    CR 13720 (F), affects Sim-API and C-API

    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

    CR 11559 (F), affects C-API

    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

    CR 4440 (F), affects Sim-API

    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:

    oe_adjust_model_path('begin'); open('model'); oe_adjust_model_path('end')

    To build an OpenECU model:

    oe_adjust_model_path('begin'); rtwbuild('model'); oe_adjust_model_path('end')

    This temporary work around will be replaced in a subsequent version of OpenECU.

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.

  • Fixed use of propagated signal names for map lookup points during ASAP2 generation

    CR 11299 (F), affects Sim-API

  • Increased number of 4-byte CCP parameters from 60 to 120 for M670 target only

    CR 11298 (F), affects Sim-API and C-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Fixed issue when using the large image from a model build using the GNU GCC compiler

    CR 13170 (F), affects Sim-API

    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

    CR 12010 (F), affects Sim-API

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

    CR 9586 (F), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Corrected some general parsing issues of CANdb files

    CR 13656 (F), affects Sim-API

    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

    CR 13468 (F), affects Sim-API and C-API

    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

    CR 11706 (F), affects Sim-API and C-API

    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

    CR 13325 (F), affects Sim-API

    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):
                              trying to assign 'ptr to volatile' to 'ptr'

    The message should be ignored.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Extended diagnostics example model and related library fixes

    CR 12458 (F), affects Sim-API and C-API

    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

    CR 12200 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.4.0-r2015-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Updated how the calculation of CVN is handled

    CR 11058 (F), affects Sim-API and C-API

    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

    CR 11037 (F), affects Sim-API

    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

    CR 9682 (F), affects Sim-API

    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

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.

  • Correction to the M220 NVM example

    CR 13829 (F), affects Sim-API

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

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.

  • Corrected handling of CCP security in development mode

    CR 13099 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.4.0-r2015-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Corrected firmware issue that could leave ECU non-communicative

    CR 12841 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.4.0-r2015-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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 DI and GPI functions for schedule update close to on angle

    CR 13894 (F), affects Sim-API and C-API

    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.

  • Correction to crank input processing of noisy trigger wheel inputs

    CR 13854 (F), affects Sim-API and C-API

    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

    CR 13519 (F), affects Sim-API and C-API

    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

    CR 13256 (F), affects Sim-API and C-API

    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

    CR 13647 (F), affects Sim-API and C-API

    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

    CR 12773 (F), affects Sim-API

    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-volatile memory storage option now being flash, rather than battery-backed RAM.

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.

  • Corrected application reset if pan_EngineConfig block is present with no angular task logic for G850 target

    CR 11891 (F), affects Sim-API and C-API

    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.

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.

  • Fixed warnings about shadowed files from MATLAB R2013b when a model build-list contains relative path entries

    CR 13690 (F), affects Sim-API and C-API

    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

User documentation covers technical specifications for each ECU, user guides or reference manuals, installation guides and release notes, in HTML and PDF formats.

  • Corrected M220 technical specification for digital input A11

    CR 13573 (F), affects Sim-API and C-API

    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)

    CR 10778 (F), affects Sim-API and C-API

  • Documented that the M461 default CCP settings differ from normal (250 kBps rather than 500 kBps)

    CR 10395 (F), affects Sim-API and C-API

3.13.  Release 2.3.0 (r2014-1)

Release labelled release-2.3.0-r2014-1 from 28 October 2014. 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.


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

  • Add new CCP interface to count receive messages

    CR 11320 (F), affects Sim-API and C-API

    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

    CR 7309 (W), affects Sim-API

    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

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.

  • Added a CCP security algorithm development mode of operation and CCP security functionality for applications built with GCC

    CR 11427 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.3.0-r2014-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • GCC builds now support DTCs and extended diagnostics

    CR 11497 (F), affects Sim-API and C-API

    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

    CR 11475 (F), affects Sim-API and C-API

    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

    CR 11355 (F), affects Sim-API and C-API

    Applications which use adaptive parameters can now be built with GCC.

  • New option to control ATI Vision flash voltage setting

    CR 10987 (F), affects Sim-API and C-API

    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

    CR 10739 (F), affects Sim-API

    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

    CR 10724 (F), affects Sim-API

    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.

Developer and supporting scripts/documentation

Changes related to OpenECU's development environment.

  • Updated GCC support from version 4.7.2 to 4.7.3

    CR 12138 (F), affects Sim-API and C-API

    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.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Added UDS $19 ExtendedDataRecord support

    CR 11234 (F), affects Sim-API and C-API

    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

    CR 11222 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.3.0-r2014-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added controlEnableMask handling for UDS $2F InputOutputControlByIdentifier

    CR 11221 (F), affects Sim-API and C-API

    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

    CR 11220 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.3.0-r2014-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added support for UDS service $24 ReadScalingByIdentifier

    CR 11219 (F), affects Sim-API and C-API

    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.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.3.0-r2014-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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.

  • Add flash code to indicate last reset was due to the watchdog

    CR 11086 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.3.0-r2014-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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.

  • Add installation guide note about a known issue with Python

    CR 12301 (F), affects Sim-API and C-API

    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

User documentation covers technical specifications for each ECU, user guides or reference manuals, installation guides and release notes, in HTML and PDF formats.

  • Added document that provides an overview of the OpenECU Sim-API

    CR 9721 (F), affects Sim-API

    The document contains a short summary of the available blockset. The document is available with other OpenECU documentation, via the Windows start menu.

3.13.2. Fixes and improvements

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

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.

  • Corrected block checking of target ECU

    CR 12559 (F), affects Sim-API

    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

    CR 11458 (F), affects Sim-API

    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

    CR 11036 (F), affects Sim-API

    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.

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

    CR 2786 (F), affects C-API

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.

  • FreeCCP invocation from MATLAB fixed, but now deprecated

    CR 12654 (F), affects Sim-API and C-API

    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

    CR 11572 (F), affects Sim-API and C-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Correction to remove duplicate compilation of model sources

    CR 12101 (F), affects Sim-API and C-API

    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

    CR 12004 (F), affects Sim-API and C-API

    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.

Developer and supporting scripts/documentation

Changes related to OpenECU's development environment.

  • Unify GCC and Diab linker script generation

    CR 12097 (F), affects Sim-API and C-API

    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.

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 pdg_ExtendedDataRecord block mask

    CR 12189 (F), affects Sim-API and C-API

    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

    CR 12144 (F), affects Sim-API and C-API

    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

    CR 12089 (F), affects Sim-API and C-API

    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

    CR 12014 (F), affects Sim-API

    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.

    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

    CR 11918 (F), affects Sim-API and C-API

    To match previous releases, the following diagnostic C-API functions and Sim-API blocks are available through a standard license.

    C-APISim-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_is_store_intact()
    pdtc_Memory
    -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_pdu1_transmit()
    pj1939_pdu2_transmit()
    pj1939_PgTransmit
    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

    CR 11627 (F), affects Sim-API

    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

    CR 11479 (F), affects Sim-API and C-API

    Previously, applications built with very large numbers of DTCs and with generous freeze frame allocations showed a slow response to diagnostic 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

    CR 11205 (F), affects Sim-API and C-API

    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

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.

  • Modified example models to use first CAN bus for CCP

    CR 12663 (F), affects Sim-API

    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

    CR 10488 (F), affects Sim-API

    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.

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.

  • Fixed polarity of PWM on H-bridge driver for M220 and U82 target ECUs

    CR 12365 (F), affects Sim-API and C-API

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

    CR 11554 (F), affects Sim-API and C-API

    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

    CR 11072 (F), affects Sim-API and C-API

    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

    CR 11047 (F), affects Sim-API and C-API

    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

    CR 11035 (F), affects Sim-API and C-API

    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.

  • Cam synch behavior is now correct with cam window in [0,360)

    CR 10680 (F), affects Sim-API and C-API

    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

    CR 4197 (F), affects Sim-API and C-API

    The documentation for the pan_CurrentCylinder Simulink block and pan_get_engine_cyl() C-API function have been improved.

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.

  • Addition of Microsoft shared run-time library for Python

    CR 11928 (F), affects Sim-API and C-API

    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 storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Non-volatile memory storage CPU issue fixed on X657

    CR 12244 (F), affects Sim-API and C-API

    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

    CR 12000 (F), affects Sim-API and C-API

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

    CR 11623 (F), affects Sim-API and C-API

    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.

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.

  • Increase in application watchdog task rate

    CR 11602 (F), affects Sim-API and C-API

    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

    CR 6811 (F), affects Sim-API and C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Reliably clear pin A45 overcurrent trip reset on M220 power-up

    CR 12271 (F), affects Sim-API and C-API

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

User documentation covers technical specifications for each ECU, user guides or reference manuals, installation guides and release notes, in HTML and PDF formats.

  • Fixed error where some files would not be included in the chunked Simulink user guide.

    CR 12638 (F), affects Sim-API and C-API

    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

    CR 12259 (F), affects Sim-API and C-API

  • Missing help for pan_EngineSync block

    CR 11894 (F), affects Sim-API

    The pan_EngineSync block help was missing. This has now been added.

  • Documentation for crank tooth edge polarity selection in the pan_CrankWheelConfig block

    CR 9640 (F), affects Sim-API

    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

    CR 8758 (F), affects Sim-API and C-API

    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.14.  Release 2.2.0 (r2013-2)

Release labelled release-2.2.0-r2013-2 from 19 December 2013. 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.11.  Release summary for v2.2.0-r2013-2

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

3.14.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 Mathworks MATLAB release R2013b (32-bit)

    CR 11201 (F), affects Sim-API

  • Remove deprecated blocks

    CR 11153 (F), affects Sim-API and C-API

    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)

    CR 10936 (F), affects Sim-API

  • Added support for Mathworks MATLAB release R2013a

    CR 10935 (F), affects Sim-API

  • Added support for the M250-00Z IMU

    CR 10875 (F), affects Sim-API and C-API

    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

    CR 10849 (F), affects Sim-API and C-API

    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.

  • Added functionality to pai_AnalogInput block

    CR 10687 (F), affects Sim-API

    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

    CR 10617 (F), affects Sim-API and C-API

    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

    CR 10279 (F), affects C-API

    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

    CR 3672 (W), affects Sim-API

    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:

    help oe_create_model

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.

  • OE_CAL replaces volatile const for calibrations

    CR 10836 (F), affects C-API

    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

    CR 7758 (F), affects Sim-API and C-API

    Previously the OpenECU application couldn't create a strategy file if the COM interface for Vision was unregistered. Now,when the COM interface 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

    CR 4248 (W), affects Sim-API and C-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Generation of unsupported characters in accordance to ASAP2 standards in ASAP2 file

    CR 11229 (F), affects Sim-API and C-API

    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

    CR 11020 (F), affects Sim-API

    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.

  • Added GCC compiler support

    CR 10836 (F), affects Sim-API and C-API

    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.

    CR 10412 (F), affects Sim-API and C-API

  • Build error when code size exceeds space available

    CR 9582 (F), affects Sim-API and C-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Added support for application specified string for CCP message EXCHANGE-ID

    CR 10773 (F), affects Sim-API and C-API

    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

    CR 9650 (F), affects Sim-API and C-API

    OpenECU now supports the Windows 7 64-bit operating system.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Added support for multiple UDS security levels with Simulink configuration

    CR 11218 (F), affects Sim-API and C-API

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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • UDS service $19 SnapshotData support

    CR 11216 (F), affects Sim-API and C-API

    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

    CR 11196 (F), affects Sim-API and C-API

    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

    CR 10423 (F), affects Sim-API and C-API

    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

    CR 10420 (F), affects Sim-API and C-API

    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.

  • Performance improvements

    CR 10318 (F), affects Sim-API and C-API

    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

    CR 9713 (F), affects Sim-API

    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

    CR 8337 (F), affects C-API

    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

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.

  • Updated oe_create_model to create a sample units files

    CR 9553 (F), affects Sim-API

    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.

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.

  • Add support for ignition-less wake-on-CAN reprogramming

    CR 11320 (F), affects Sim-API and C-API

    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.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added new firmware for M221 family of modules

    CR 11319 (F), affects Sim-API and C-API

    This is the initial release of firmware for the M221 target.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Updates to the Extended EXCHANGE_ID CCP message handling to extract manufacture information

    CR 11016 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added version numbers for each software component to firmware release notes

    CR 10744 (F), affects Sim-API and C-API

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.

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

    CR 11319 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Removed deprecated ECU target

    CR 10735 (F), affects Sim-API and C-API

    The target M250-00H is no longer supported.

    The bldc features are no longer supported.

  • New flash code for licensing

    CR 10278 (F), affects Sim-API and C-API

    The flash code "222" has been added to the firmware to indicate when the loaded application is not validly licensed

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added facility to output the entire adapted array

    CR 9429 (F), affects Sim-API and C-API

    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

    CR 9412 (F), affects Sim-API and C-API

    The facility to select different memory configurations has been added for targets M220, M250, M460 and M461.

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.

  • Updated third party tools documentation to include MATLAB coder

    CR 11204 (F), affects Sim-API and C-API

    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.

3.14.2. Fixes and improvements

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

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 error message when adaptives or DTCs are used with GCC

    CR 11499 (F), affects Sim-API and C-API

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

    CR 10798 (F), affects Sim-API and C-API

  • Correction to how some blocks display in MATLAB R2010b or later

    CR 10722 (F), affects Sim-API

    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

    CR 10696 (F), affects Sim-API and C-API

    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

    CR 9544 (F), affects Sim-API

    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

    CR 7759 (F), affects Sim-API

    Previously, a subset of the blocks would make assumptions that data dictionary elements used for mask parameters must be of Simulink 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

    CR 4997 (F), affects Sim-API and C-API

    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

    CR 4401 (F), affects Sim-API

    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

    CR 2254 (F), affects Sim-API and C-API

    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

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.

  • Corrected errors in the ProF configuration files for the M220 target affecting integration with ETAS INCA

    CR 10978 (F), affects Sim-API and C-API

    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.

    CR 10838 (F), affects Sim-API and C-API

    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

    CR 10606 (F), affects Sim-API and C-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Fix to oe_update_model_for_ddes for Embedded Coder

    CR 11443 (F), affects Sim-API

    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

    CR 11438 (F), affects Sim-API

  • Fix to oe_update_model_for_ddes.m to account for inherited signal names within a library link in a main model

    CR 11245 (F), affects Sim-API

    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

    CR 11233 (F), affects Sim-API and C-API

    There was a bug that caused capi_visitor_dde_gen_asap2.py to raise an error in some cases. This has been fixed.

  • Correction to SimulinkCoder build directory naming

    CR 11156 (F), affects Sim-API

    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

    CR 10917 (F), affects Sim-API

    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

    CR 10723 (F), affects Sim-API and C-API

    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

    CR 10621 (F), affects Sim-API

    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.

    CR 10608 (F), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • CAN messages stop transmitting due to failure in queueing mechanism

    CR 11472 (F), affects Sim-API and C-API

    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

    CR 11293 (F), affects Sim-API and C-API

    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

    CR 11055 (F), affects Sim-API and C-API

    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

    CR 10997 (F), affects Sim-API and C-API

    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

    CR 10899 (F), affects Sim-API and C-API

    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

    CR 9101 (F), affects Sim-API and C-API

    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.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • UDS reprogramming fixes for X657

    CR 10760 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Add separate functions for J1939 message transmission using PDU1 and PDU2 formats

    CR 8915 (F), affects C-API

    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

    CR 8687 (F), affects C-API

    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

    CR 8608 (F), affects Sim-API and C-API

    Corrected the 'empty' message contents for DM30 and DM33 messages.

  • Updated documentation related to J1939 DM28 transmission

    CR 8458 (F), affects Sim-API and C-API

    Updated documentation related J1939 DM28 transmission to indicate that active and permanent DTCs are transmitted on this message.

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.

  • Avoid driving inverted outputs on X657 during flash reprogramming

    CR 10870 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Remember memory errors across resets

    CR 10857 (F), affects C-API

    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.

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Faster boot and application/calibration integrity information for X657

    CR 10761 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Allow CCP/J1939/UDS reprogramming when FEPS is active

    CR 10746 (F), affects Sim-API and C-API

    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.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.2.0-r2013-2 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.

  • Correction to compiler version checks

    CR 11242 (F), affects Sim-API and C-API

    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

    CR 11066 (F), affects Sim-API

    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

    CR 10926 (F), affects Sim-API and C-API

    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

    CR 10736 (F), affects Sim-API and C-API

    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

    CR 10632 (F), affects Sim-API

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

    CR 10351 (F), affects Sim-API and C-API

  • Corrections to M460 technical specification

    CR 10350 (F), affects Sim-API and C-API

  • Corrections to M250 technical specification

    CR 10349 (F), affects Sim-API and C-API

  • Corrections to M220 technical specification

    CR 10348 (F), affects Sim-API and C-API

  • Support newer versions of ATI Vision

    CR 9552 (F), affects Sim-API and C-API

    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

    CR 4580 (F), affects Sim-API and C-API

    Added descriptive text to better describe how the digital outputs behave depending on their selected polarity.

3.15.  Release 2.1.0 (r2013-1)

Release labelled release-2.1.0-r2013-1 from 13 February 2013. 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.12.  Release summary for v2.1.0-r2013-1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API10531 (F), 10480 (F), 10387 (F), 10334 (F),
10203 (F), 9809 (F), 9640 (F), 9615 (F),
9413 (F), 9040 (F), 9039 (F), 9026 (F),
9025 (F), 8614 (F), 8614 (F), 8614 (F),
8499 (F), 8174 (F), 7932 (F), 7827 (F),
7814 (F), 7388 (F), 7196 (F), 7164 (F),
7163 (F), 6699 (F), 4749 (F)
10579 (F), 10519 (F), 10438 (F), 10398 (F),
10397 (F), 10351 (F), 10350 (F), 10349 (F),
10348 (F), 10310 (F), 10247 (F), 10231 (F),
9751 (F), 9733 (F), 9719 (F), 9661 (F),
9560 (F), 9560 (F), 9529 (F), 9525 (F),
9055 (F), 9045 (F), 8973 (F), 8943 (F),
8943 (F), 8942 (F), 8941 (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)
No, see:
10387 (F),
9040 (F),
9039 (F),
8714 (F),
8499 (F),
7932 (F),
5471 (F)
Yes, see:
10310 (F),
10247 (F),
10231 (F)
Sim-API10559 (F), 10531 (F), 10480 (F), 10387 (F),
10334 (F), 9793 (F), 9640 (F), 9615 (F),
9569 (F), 9413 (F), 9040 (F), 9039 (F),
9026 (F), 9025 (F), 8614 (F), 8614 (F),
8614 (F), 8499 (F), 8174 (F), 7932 (F),
7827 (F), 7814 (F), 7388 (F), 7196 (F),
7164 (F), 7163 (F), 6848 (F), 4749 (F)
10683 (F), 10625 (F), 10595 (F), 10579 (F),
10562 (F), 10561 (F), 10519 (F), 10511 (F),
10438 (F), 10397 (F), 10351 (F), 10350 (F),
10349 (F), 10348 (F), 10346 (F), 10310 (F),
10247 (F), 10231 (F), 9751 (F), 9733 (F),
9722 (F), 9661 (F), 9653 (F), 9588 (F),
9560 (F), 9560 (F), 9529 (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),
5471 (F), 4749 (F), 4595 (F), 1916 (F)
No, see:
10387 (F),
10346 (F),
9040 (F),
9039 (F),
7932 (F),
5471 (F)
Yes, see:
10310 (F),
10247 (F),
10231 (F)

3.15.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 MathWorks MATLAB versions R2010b, R2011a and R2011b

    CR 9569 (F), affects Sim-API

  • Added support for application-specified direct-injection duration

    CR 9040 (F), affects Sim-API and C-API

    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

    CR 9039 (F), affects Sim-API and C-API

    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

    CR 9026 (F), affects Sim-API and C-API

    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

    CR 9025 (F), affects Sim-API and C-API

    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

    CR 8499 (F), affects C-API

    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

    CR 7388 (F), affects Sim-API and C-API

    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

    CR 6848 (F), affects Sim-API

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.

  • Added support for PiSnoop

    CR 10334 (F), affects Sim-API and C-API

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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Removed support for Diab 4.4b

    CR 10387 (F), affects Sim-API and C-API

  • Basic support for Model Referencing added

    CR 9793 (F), affects Sim-API

    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

    CR 9413 (F), affects Sim-API and C-API

    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

    CR 8499 (F), affects Sim-API

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

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Add support for service $19 subfunction $0A

    CR 10480 (F), affects Sim-API and C-API

  • Add attribute to DTE/ DME structures to define if they are in-use or not

    CR 10203 (F), affects C-API

    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

    CR 8174 (F), affects Sim-API and C-API

    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

    CR 6699 (F), affects C-API

    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.

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.

  • Addition of current monitors for M220

    CR 10531 (F), affects Sim-API and C-API

    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
    A17PIO_AIN_A17_MONITOR_CMonitor (c) (pin A17)
    A29PIO_AIN_A29_MONITOR_CMonitor (c) (pin A29)
    A32PIO_AIN_A32_MONITOR_CMonitor (c) (pin A32)
    A33PIO_AIN_A33_MONITOR_CMonitor (c) (pin A33)
  • GPIO outputs in IO file to support switched pull up/down resistors for X657

    CR 9809 (F), affects C-API

    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

    CR 9640 (F), affects Sim-API and C-API

    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

    CR 8614 (F), affects Sim-API and C-API

    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

    CR 8614 (F), affects Sim-API and C-API

    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.

    Note

    This interface is experiemental and has very little testing.

  • Added documentation to the user guides for the extended crank wheel configuration interface

    CR 8614 (F), affects Sim-API and C-API

  • Added cam wheel tooth edge angle measurement

    CR 7827 (F), affects Sim-API and C-API

    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

    CR 7814 (F), affects Sim-API and C-API

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

    CR 7196 (F), affects Sim-API and C-API

    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 supportG400G800G850M220M250
    pan_AngularAnalogInputConfigYYYYY
    pan_AngularAnalogInputYYYYY
    pan_CamWheelConfigYYYYY
    pan_CamWheelDeclareSyncYYYYY
    pan_CamWheelMovementNNNYY
    pan_CamWheelSpeedNNNYY
    pan_CamWheelSyncYYYYY
    pan_CrankWheelConfigYYYYY
    pan_CrankWheelMovementYYYYY
    pan_CrankWheelSpeedYYYYY
    pan_CrankWheelSyncYYYYY
    pan_CurrentCrankAngleYYYYY
    pan_CurrentCrankToothYYYYY
    pan_CurrentCylinderYYYYY
    pan_CurrentEngineAngleYYYYY
    pan_EngineConfigYYYYY
    pan_EngineSpeedNNNYY
    pan_EngineSpeedConfigNNN Y [a] Y [a]
    pan_EngineSyncYYYYY
    pan_InjectorConfigYYYYY
    pan_InjectorConfig_DINNNYY
    pan_InjectorCompConfig_DINNNYY
    pan_InjectorCompAdapt_DI_blockNNNYY
    pan_InjectionOverrideFrp_DINNNYY
    pan_Injection_DINNNYY
    pan_InitialInjection_GPIYYYNN
    pan_Injection_GPIYYYY N [b]
    pan_UpdateInjection_GPIYYYYN [b]
    pan_KnockConfig N [c] N [c]N [c] N [d] N [e]
    pan_KnockDetectionWindowN [c]N [c]N [c]N [d]N [e]
    pan_KnockFeedbackN [c]N [c]N [c]N [d]N [e]
    pan_KnockFilterN [c]N [c]N [c]N [d]N [e]
    pan_SparkConfigYYYYY
    pan_SparkYYYYY

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

  • Add support for application determined cam synchronisation on M220 and M250 targets

    CR 7164 (F), affects Sim-API and C-API

    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

    CR 7163 (F), affects Sim-API and C-API

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.

  • OpenECU Developer Software now supports Microsoft Windows 7 (32-bit)

    CR 4749 (F), affects Sim-API and C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Sim-API added to X657 target

    CR 10559 (F), affects Sim-API

  • Removed deprecated ECU targets

    CR 7932 (F), affects Sim-API and C-API

    The following ECU targets are no longer supported: A450, G400, G800 and M001.

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.

  • Added details about deprecated and end-of-life parts to the OpenECU product

    CR 9615 (F), affects Sim-API and C-API

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

    An up-to-date list can be found on the Pi Innovo website (http://www.pi-innovo.com/support-center/compatibility).

3.15.2. Fixes and improvements

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

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.

  • Various corrections to the pai_AnalogInput block

    CR 10683 (F), affects Sim-API

    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

    CR 10625 (F), affects Sim-API

    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

    CR 10595 (F), affects Sim-API

    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

    CR 10562 (F), affects Sim-API

    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

    CR 10346 (F), affects Sim-API

  • X657 can now support any CAN bus in the range [0,2] and will generate an error outside this range

    CR 9719 (F), affects C-API

    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

    CR 9653 (F), affects Sim-API

    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

    CR 9033 (F), affects Sim-API

    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

    CR 8499 (F), affects Sim-API

    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

    CR 8499 (F), affects Sim-API

    Previously, the current operating point was not correctly supported for the pnv_AdaptiveMap1d, pnv_AdaptiveMap2d, put_Calmap1d, and put_Calmap2d blocks. Now the blocks correctly populate the current operationg point variable in the generated ASAP2 file, when that variable is available.

  • Extension of MathWorks Real-Time Workshop based ASAP2 generation

    CR 8499 (F), affects Sim-API

    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

    CR 7636 (F), affects C-API

    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

    CR 7353 (F), affects Sim-API

    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

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.

  • CCP Security performance and documentation updates

    CR 10247 (F), affects Sim-API and C-API

    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.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.1.0-r2013-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

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

    CR 10511 (F), affects Sim-API

    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

    CR 9588 (F), affects Sim-API

  • Correction to handling of ASAP2 name shortening and renaming

    CR 9560 (F), affects Sim-API and C-API

    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

    CR 9560 (F), affects Sim-API and C-API

    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 pcx_TransmitMessage block crash in Simulink

    CR 9436 (F), affects Sim-API

    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

    CR 8973 (F), affects Sim-API and C-API

    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

    CR 8943 (F), affects Sim-API and C-API

    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

    CR 8943 (F), affects Sim-API and C-API

    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

    CR 8597 (F), affects Sim-API

    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

    CR 8596 (F), affects Sim-API and C-API

    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.

  • Extension of MathWorks Real-Time Workshop based ASAP2 generation

    CR 8499 (F), affects Sim-API

    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

    CR 8499 (F), affects Sim-API

    Previously, support for ASAP2 generation was only supported up to R2010a, now support has been extended up to R2012b.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Allow CAN blocks to be used in triggered sub-systems

    CR 8530 (F), affects Sim-API

    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.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Should support $FFFFFF in $14 ClearDiagnosticInformation for UDS

    CR 9751 (F), affects Sim-API and C-API

    Added support of UDS service $14 request.

  • Problems in service $14 request

    CR 9733 (F), affects Sim-API and C-API

    Added clearing of diagnostic information in response to service $14 request.

  • Issues with DM36, DM37 and DM40

    CR 9661 (F), affects Sim-API and C-API

    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

    CR 9529 (F), affects Sim-API and C-API

    Enhanced user guide to explain the occurrence count reported in DM messages.

  • Clearing of data on receipt of DM3 and DM11 messages

    CR 9525 (F), affects Sim-API and C-API

    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()

    CR 8860 (F), affects Sim-API and C-API

    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()

    CR 8816 (F), affects C-API

    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()

    CR 8714 (F), affects C-API

    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.

    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]

    CR 8694 (F), affects Sim-API

    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

    CR 8581 (F), affects Sim-API and C-API

    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

    CR 8450 (F), affects Sim-API and C-API

    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

    CR 8302 (F), affects 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)

    CR 7084 (F), affects Sim-API and C-API

    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

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.

  • Fix for warnings displayed when loading an example model in Simulink

    CR 10561 (F), affects Sim-API

    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

    CR 5811 (F), affects Sim-API

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.

  • Changed M250 firmware to actively turn off pin A16 after power-on or reset

    CR 10310 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.1.0-r2013-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Validate calibration area before running application

    CR 10231 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.1.0-r2013-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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.

  • Fix for recovery of synchonrisation with cam wheel

    CR 10519 (F), affects Sim-API and C-API

    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

    CR 10438 (F), affects Sim-API and C-API

    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

    CR 10397 (F), affects Sim-API and C-API

    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

    CR 9722 (F), affects Sim-API

    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

    CR 9055 (F), affects Sim-API and C-API

    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

    CR 9045 (F), affects Sim-API and C-API

    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

    CR 8942 (F), affects Sim-API and C-API

    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

    CR 8941 (F), affects Sim-API and C-API

    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

    CR 8715 (F), affects Sim-API and C-API

    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

    CR 8473 (F), affects Sim-API and C-API

    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

    CR 8425 (F), affects Sim-API and C-API

    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

    CR 8141 (W), affects Sim-API and C-API

    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

    CR 7917 (F), affects Sim-API and C-API

  • Correction to engine speed calculation where the engine TDC-firing angles are not symmetrical

    CR 7827 (F), affects Sim-API and C-API

  • Fixed simulation behaviour for the pan_AngularAnalogInputVariable and pan_AngularAnalogInputVariableAbs blocks

    CR 7814 (F), affects Sim-API and C-API

    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

    CR 7814 (F), affects Sim-API and C-API

    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

    CR 7814 (F), affects Sim-API and C-API

    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.

  • Correction to crank synchronous A/D sampling

    CR 7814 (F), affects Sim-API and C-API

    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.

  • Correction to crank synchronous A/D sampling

    CR 7814 (F), affects Sim-API and C-API

    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

    CR 7358 (F), affects Sim-API and C-API

    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

    CR 7196 (F), affects Sim-API and C-API

    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

    CR 6467 (F), affects Sim-API

    Previously, as described in CR 6467 (W), the pan_EngineConfig block would cause Simulink to emit a warning about sample time when the 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

    CR 5471 (F), affects Sim-API and C-API

    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

    CR 5471 (F), affects Sim-API and C-API

    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

    CR 5471 (F), affects Sim-API and C-API

    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

    CR 1916 (F), affects Sim-API and C-API

    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

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.

  • Allowing C-API documentation links to be installed if Sim32 blockset is not installed

    CR 10398 (F), affects C-API

    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

    CR 4749 (F), affects Sim-API and C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • PWM dead-time insertion to fix H-Bridge shoot-through problem

    CR 7622 (F), affects Sim-API and C-API

    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

User documentation covers technical specifications for each ECU, user guides or reference manuals, installation guides and release notes, in HTML and PDF formats.

  • Updated information about third party tool compatibility

    CR 10579 (F), affects Sim-API and C-API

    The user guides and release notes have been updated to document third party tool requirements and compatibility.

  • Corrections to M461 technical specification

    CR 10351 (F), affects Sim-API and C-API

  • Corrections to M460 technical specification

    CR 10350 (F), affects Sim-API and C-API

  • Corrections to M250 technical specification

    CR 10349 (F), affects Sim-API and C-API

  • Corrections to M220 technical specification

    CR 10348 (F), affects Sim-API and C-API

  • Added details to M220 technical specification regarding non-linearity of pin A16 current monitor response

    CR 8783 (F), affects Sim-API and C-API

    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

    CR 8680 (F), affects Sim-API and C-API

    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

    CR 4595 (F), affects Sim-API and C-API

3.16.  Release 2.0.0 (r2012-1)

Release labelled release-2.0.0-2012-1 from 5 October 2012. 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.13.  Release summary for v2.0.0-r2012-1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API9625 (F), 9573 (F), 9507 (F), 9075 (F),
8819 (F), 7292 (F), 5510 (F), 5150 (F)
10120 (F), 9811 (F), 9807 (F), 9799 (F),
9727 (F), 9724 (F), 9656 (F), 9649 (F),
9610 (F), 9574 (F), 9508 (F), 9459 (F),
9458 (F), 9405 (F), 9149 (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)
No, see:
9507 (F),
4466 (F)
Yes, see:
9610 (F),
9507 (F),
8933 (F),
8819 (F),
7900 (F),
7619 (F),
7619 (F)
Sim-API9636 (F), 9625 (F), 9573 (F), 9507 (F),
9075 (F), 8819 (F), 8778 (F), 7292 (F),
5150 (F), 4222 (F), 1823 (F)
10260 (F), 10120 (F), 9811 (F), 9811 (F),
9810 (F), 9807 (F), 9799 (F), 9750 (F),
9727 (F), 9724 (F), 9656 (F), 9649 (F),
9634 (F), 9610 (F), 9590 (F), 9589 (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)
No, see:
9507 (F),
8921 (F),
4466 (F)
Yes, see:
9610 (F),
9507 (F),
8933 (F),
8819 (F),
7900 (F),
7619 (F),
7619 (F)

3.16.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 warnings to deprecated blocks

    CR 9636 (F), affects Sim-API

    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

    CR 5150 (F), affects Sim-API and C-API

    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

    CR 4222 (F), affects Sim-API

    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

OpenECU software, examples and documentation are accessible through the desktop, from the Windows Start button.

  • Change CCP seed/key security, including new Simulink interface

    CR 9507 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.0.0-r2012-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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.

  • Addition of an extended diagnostics example Simulink model

    CR 8778 (F), affects Sim-API

  • New customer examples for C-API and Simulink

    CR 7292 (F), affects Sim-API and C-API

    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

    CR 5510 (F), affects C-API

    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

    CR 1823 (F), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Reserved 128 kB of flash memory on the X657 exclusively for customer use

    CR 9625 (F), affects Sim-API and C-API

  • Like the G400 and G800 ECUs, the G850 target is now deprecated

    CR 9075 (F), affects Sim-API and C-API

    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

    CR 8819 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.0.0-r2012-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.

  • Collapse bookmark outline in PDF documentation making the outline easier to navigate

    CR 9573 (F), affects Sim-API and C-API

3.16.2. Fixes and improvements

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

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 missing C-API header file for the M220 target

    CR 9649 (F), affects Sim-API and C-API

    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

    CR 9634 (F), affects Sim-API

    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

    CR 9563 (F), affects Sim-API

    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

    CR 9541 (F), affects Sim-API

    Previously, when the oe_switch_version command switched versions of OpenECU, the command would refresh internal cached data, such as 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

    CR 9508 (F), affects Sim-API and C-API

    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

    CR 8985 (F), affects Sim-API

    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

    CR 8907 (F), affects Sim-API

    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

    CR 8704 (F), affects Sim-API

    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

    CR 7116 (F), affects Sim-API

    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

    CR 6586 (F), affects Sim-API

    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

    CR 4466 (F), affects Sim-API and C-API

    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 'Powertrain' namePrevious 'Generic' namePrevious 'Long' nameNew name
    M220
    NANADOT switch-PSU1DOT enable-EXT-PSU1
    M250
    DOT EXTPSU1DOT EXTPSU1DOT switch-PSU1DOT disable-EXT-PSU1
    DOT EXTPSU2DOT EXTPSU2DOT switch-PSU2DOT disable-EXT-PSU2
    M460
    EXTPSU3DOT EXTPSU3DOT switch-PSU3DOT disable-EXT-PSU3
    EXTPSU4DOT EXTPSU4DOT switch-PSU4DOT disable-EXT-PSU4
    M461
    EXTPSU1DOT EXTPSU1DOT switch-PSU1DOT disable-EXT-PSU1
    EXTPSU2DOT EXTPSU2DOT switch-PSU2DOT disable-EXT-PSU2
    EXTPSU3DOT EXTPSU3DOT switch-PSU3DOT disable-EXT-PSU3
    EXTPSU4DOT EXTPSU4DOT switch-PSU4DOT disable-EXT-PSU4

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.

  • Correction to ASAP2 generation for automatically generated DDEs

    CR 9750 (F), affects Sim-API

    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

    CR 9016 (F), affects Sim-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Updated pai_AnalogInput block so that min/max parameters can be populated with calibrations

    CR 9589 (F), affects Sim-API

    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

    CR 9459 (F), affects Sim-API and C-API

    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

    CR 8741 (F), affects Sim-API and C-API

    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

    CR 8634 (F), affects 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.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correction to CANdb file parsing

    CR 9028 (F), affects Sim-API

    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

OpenECU software, examples and documentation are accessible through the desktop, from the Windows Start button.

  • Add checks to all TLC files to ensure an OpenECU system target file is selected

    CR 9590 (F), affects Sim-API

    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.

Developer and supporting scripts/documentation

Changes related to OpenECU's development environment.

  • Name change to is_overriden parameter

    CR 9464 (F), affects Sim-API

    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'

    CR 9458 (F), affects Sim-API and C-API

    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.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Correct state reporting for pdtc_DiagnosticTroubleCode

    CR 8921 (F), affects Sim-API

    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

    CR 8885 (F), affects Sim-API and C-API

    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

    CR 8788 (F), affects Sim-API and C-API

    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

    CR 8779 (F), affects Sim-API and C-API

    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

    CR 8643 (F), affects Sim-API

    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

    CR 8237 (F), affects Sim-API

  • Moved the extended diagnostics blocks from Pi OpenECU to Pi OpenECU Extras — Diagnostics extensions in Simulink

    CR 7195 (F), affects Sim-API

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.

  • Boot loader upgrade made more robust

    CR 9656 (F), affects Sim-API and C-API

    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

    CR 9610 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.0.0-r2012-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • SessionControl ($10) in reprogramming mode return to application mode

    CR 8933 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.0.0-r2012-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Enabled pull-ups for unpopulated pads

    CR 7900 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.0.0-r2012-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Corrected power-hold behaviour of the M220 firmware

    CR 7619 (F), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.0.0-r2012-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Corrected negative FEPS operation in M220 firmware

    CR 7619 (F), affects Sim-API and C-API

    This change configures the M220 such that negative FEPS now works correctly and enters reprogramming mode using the default CAN configuration.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 2.0.0-r2012-1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Updated documentation on FEPS programming

    CR 4121 (F), affects Sim-API and C-API

    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.

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 dereferencing of channel names

    CR 10260 (F), affects Sim-API

    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

    CR 10120 (F), affects Sim-API and C-API

    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

    CR 9811 (F), affects Sim-API

    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

    CR 9811 (F), affects Sim-API and C-API

    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

    CR 9810 (F), affects Sim-API

    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

    CR 9807 (F), affects Sim-API and C-API

    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

    CR 9799 (F), affects Sim-API and C-API

    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

    CR 9727 (F), affects Sim-API and C-API

  • Correction to the G850 technical specification for H-bridge details

    CR 9724 (F), affects Sim-API and C-API

  • Correction to I/O behaviour for some applications

    CR 9073 (F), affects Sim-API and C-API

    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

    CR 8803 (F), affects Sim-API and C-API

    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

    CR 5073 (F), affects Sim-API and C-API

    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

    CR 4933 (F), affects Sim-API and C-API

    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

    CR 4570 (F), affects C-API

    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

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.

  • Applied minor updates to the installer look and feel

    CR 7044 (F), affects Sim-API and C-API

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Robustness improvements to PFS (non-volatile flash filesystem) feature

    CR 9405 (F), affects Sim-API and C-API

    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

    CR 8211 (F), affects C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • PDTC client task rate changed from 10 ms to 100ms on the X657 to reduce CPU loading

    CR 9574 (F), affects Sim-API and C-API

  • External sensor power supply output (pin A25) did not turn on for M220-00E

    CR 8673 (F), affects Sim-API and C-API

    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

User documentation covers technical specifications for each ECU, user guides or reference manuals, installation guides and release notes, in HTML and PDF formats.

  • Updated pai_AnalogInput documentation for the block output vector, confirmed_faults, as the vector's element ordering was incorrrect

    CR 9589 (F), affects Sim-API

  • Fixed Simulink block HTML help file links

    CR 9437 (F), affects Sim-API

    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

    CR 9410 (F), affects Sim-API

    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

    CR 9149 (F), affects Sim-API and C-API

    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

    CR 8835 (F), affects Sim-API and C-API

  • Documentation update for pcx_receive() function

    CR 8274 (F), affects C-API

    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

    CR 8031 (F), affects Sim-API and C-API

  • Corrected documentation in the Sim-API user guide for the step1 example

    CR 7978 (F), affects Sim-API and C-API

    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

    CR 7650 (F), affects Sim-API and C-API

  • Updates to user guides to document A/D conversion rates

    CR 7075 (F), affects Sim-API and C-API

    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

    CR 7036 (F), affects Sim-API

  • User guide improvements required for high-side actuator output control (M250 and M460)

    CR 7007 (F), affects Sim-API and C-API

  • Updated M250 technical specification with recent power consumption data

    CR 4711 (F), affects Sim-API and C-API

  • Updated documentation to reflect supported versions of Microsoft Windows

    CR 4088 (F), affects Sim-API and C-API

  • Updated the M250 technical specification

    CR 3811 (F), affects Sim-API and C-API

    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.17.  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.14.  Release summary for v1.9.2

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API8250 (W)8967 (W), 8966 (W), 8908 (W), 8902 (W),
8773 (W), 8746 (W), 8736 (W), 8153 (W),
8151 (W)
No, see:
8151 (W)
Yes, see:
8908 (W)
Sim-API8250 (W)8967 (W), 8908 (W), 8902 (W), 8794 (W),
8762 (W), 8746 (W), 8745 (W), 8736 (W),
8243 (W), 8153 (W), 6526 (W)
YesYes, see:
8908 (W)

3.17.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Run-time checks on RAM, flash and NVM data added

    CR 8250 (W), affects Sim-API and C-API

    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.

3.17.2. Fixes and improvements

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

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.

  • CANape warnings for string length exceeding 255 characters

    CR 8762 (W), affects Sim-API

    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

    CR 8746 (W), affects Sim-API and C-API

    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

    CR 8736 (W), affects Sim-API and C-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Updated the pan_SparkConfig block

    CR 6526 (W), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Allow CCP and ISO diagnostics to work on all buses via calibration on selected targets

    CR 8908 (W), affects Sim-API and C-API

    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.

    Note

    To enable this functionality, the ECU's firmware must be upgraded 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

    CR 8794 (W), affects Sim-API

    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

    CR 8243 (W), affects Sim-API

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Negative responses to incorrectly formatted J1979 messages

    CR 8153 (W), affects Sim-API and C-API

    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.

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.

  • Avoid perturbation of TPU channel 0 when synchronised PWM running

    CR 8967 (W), affects Sim-API and C-API

    Previously, running a synchronised PWM (injector) output on MPC5xxx targets could disrupt an unrelated PWM input on TPU channel 0, causing it to miss edges and so report an erroneously low frequency. This is now fixed.

  • Add fixed-frequency PWM support for X221 digital outputs

    CR 8745 (W), affects Sim-API

    X221 support for fixed-frequency PWM on digital outputs was missed previously. This has now been added.

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • 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

    CR 8773 (W), affects C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Option added to disable background memory checks

    CR 8966 (W), affects C-API

    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

    CR 8902 (W), affects Sim-API and C-API

    Previously the wrong A/D channel was selected for this function, corresponding to the pin B30 voltage monitor.

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


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

  • Support for external serial (SPI) flash memory chip (Numoynix M25P16)

    CR 8351 (W), affects C-API

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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Addition of J1939 inhibit reprogramming functionality

    CR 8243 (W), affects Sim-API and C-API

    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.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Support for ReadMemoryByAddress (UDS/KW2000-3 service $23) added

    CR 8555 (W), affects C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Allow global override of priority for J1939 multi-frame diagnostic messages

    CR 8519 (W), affects Sim-API and C-API

    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

    CR 8518 (W), affects Sim-API and C-API

    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

    CR 8517 (W), affects Sim-API and C-API

    In certain circumstances only, the customer may wish to override the standard response to the J1979 service requests $03, $07 and $0A. This 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

    CR 8408 (W), affects Sim-API

    Simulink support for J1939-73 messages DM32 and DM34 has been added.

  • Added support for DM24 data stream

    CR 8403 (W), affects Sim-API and C-API

    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

    CR 8402 (W), affects Sim-API and C-API

    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

    CR 8383 (W), affects Sim-API

    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

    CR 8099 (W), affects Sim-API and C-API

    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.

    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

    CR 7899 (W), affects Sim-API

    Simulink blocks have been added to support J1939 messages DM35, DM36, DM37, DM38, DM39 and DM40.

  • Change to DM37 transmit function

    CR 7899 (W), affects C-API

    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

    CR 7808 (W), affects Sim-API 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

    CR 7576 (W), affects Sim-API

    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

    CR 7231 (W), affects Sim-API

    A DM4 transmit block has been added.

    A DM24 transmit block has been added.

    A DM25 transmit block has been added.

  • Add support for J1939 DM4

    CR 7229 (W), affects Sim-API and C-API

    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.

  • Add support for J1939 DM24

    CR 7229 (W), affects Sim-API and C-API

    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.

  • Add support for J1939 DM25

    CR 7229 (W), affects Sim-API and C-API

    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

    CR 7228 (W), affects Sim-API and C-API

    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.

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.

  • Peak-Hold injector driver support for reading the commanded output state on U82

    CR 8308 (W), affects Sim-API and C-API

    This new feature introduces two new digital inputs that read the commanded state of the peak/hold outputs.

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.

  • Added support for X221-000 target ECU

    CR 6679 (W), affects Sim-API and C-API

    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.

3.18.2. Fixes and improvements

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

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.

  • Correction to the configuration of the serialised digital inputs

    CR 8567 (W), affects Sim-API and C-API

    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

    CR 8484 (W), affects Sim-API and C-API

    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

    CR 5676 (W), affects Sim-API and C-API

    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

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.

  • ASAP2 identifier prefixed with a number not dealt with correctly

    CR 8697 (W), affects Sim-API

    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

    CR 8617 (W), affects Sim-API

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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Changed Sim-API model builds to use the C-API tool to generate glue code and ASAP2 files

    CR 7047 (W), affects Sim-API

    A continuation of the work to complete CR 7047 (W).

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correction to handling CANdb files containing negative integers and numerical literals larger than 32-bits of integer

    CR 8529 (W), affects Sim-API

    This issue affected the CANdb blocks pcx_CANdb_ReceiveMessage and pcx_CANdb_TransmitMessage.

  • Correction to the latency between J1939 BAM data frames

    CR 8520 (W), affects Sim-API and C-API

    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

    CR 8503 (W), affects Sim-API and C-API

    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

    CR 8115 (W), affects Sim-API

    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

    CR 7530 (W), affects C-API

    UDS-based flash reprogramming is now supported. Please contact Pi Innovo for further details.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Correction to user guide documentation for CCP security

    CR 7263 (W), affects Sim-API and C-API

    Previously, various links in the C-API and Sim-API user guides did not work. These have now been corrected.

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 buffer overflow and ECU reset when the number of SPNs for DM24 transmission exceeds 255

    CR 8763 (W), affects Sim-API and C-API

    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

    CR 8757 (W), affects Sim-API

    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

    CR 8734 (W), affects Sim-API

    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

    CR 8693 (W), affects Sim-API and C-API

    As part of the CVN calculation a CRC is calculated for each of the following memory regions:

    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

    CR 8691 (W), affects Sim-API and C-API

    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

    CR 8681 (W), affects Sim-API and C-API

    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

    CR 8640 (W), affects Sim-API

    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)

    CR 8619 (W), affects Sim-API and C-API

    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

    CR 8616 (W), affects Sim-API and C-API

    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.

    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

    CR 8590 (W), affects Sim-API and C-API

    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

    CR 8579 (W), affects Sim-API and C-API

    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

    CR 8566 (W), affects C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Updated to allow the user to define the name of the DM25 calibration

    CR 8542 (W), affects Sim-API and C-API

    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

    CR 8532 (W), affects Sim-API and C-API

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

    CR 8372 (W), affects Sim-API and C-API

    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

    CR 8335 (W), affects Sim-API and C-API

    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

    CR 8333 (W), affects Sim-API and C-API

    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

    CR 8292 (W), affects Sim-API and C-API

    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

    CR 8262 (W), affects Sim-API and C-API

    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

    CR 8231 (W), affects Sim-API and C-API

    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

    CR 8208 (W), affects Sim-API and C-API

    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

    CR 8155 (W), affects Sim-API and C-API

    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

    CR 8020 (W), affects Sim-API and C-API

    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.

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.

  • Corrected incorrect baud rate setting in firmware

    CR 6048 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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 frequency range selection for U82 targets

    CR 8398 (W), affects Sim-API and C-API

    Frequency range selection for U82 C-sample pins A16, A17, A45 and A46 would not work correctly. This has been corrected.

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.

  • X657 overlapping RAM warnings addressed

    CR 8600 (W), affects C-API

    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

    CR 8230 (W), affects Sim-API

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

Table 3.16.  Release summary for v1.9.0

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API8212 (W), 8118 (W), 8115 (W), 8088 (W),
7902 (W), 7899 (W), 7810 (W), 7808 (W),
7808 (W), 7804 (VI), 7721 (W), 7648 (W),
7642 (W), 7594 (W), 7562 (W), 7392 (W),
7281 (W), 7279 (W), 7267 (W), 7212 (W),
7006 (W), 7001 (W), 6952 (W), 6952 (W),
6930 (W), 6928 (W), 6874 (W), 6729 (W),
6698 (W), 6696 (W), 6635 (W), 6633 (W),
6584 (W), 6547 (W), 6545 (W), 6545 (W),
6467 (W), 6377 (W), 6350 (W), 6289 (W),
6134 (W), 5889 (W), 5879 (W), 5850 (W),
5849 (W), 5848 (W), 5847 (W), 5846 (W),
5845 (W), 5844 (W), 5381 (W), 5148 (W),
4922 (W), 4228 (W)
8310 (W), 8293 (W), 8256 (W), 8245 (W),
8242 (W), 8239 (W), 8228 (W), 8224 (W),
8224 (W), 8212 (W), 8199 (W), 8195 (W),
8180 (W), 8117 (W), 7961 (W), 7869 (W),
7805 (W), 7800 (W), 7718 (W), 7652 (W),
7633 (W), 7631 (W), 7619 (W), 7501 (W),
7495 (W), 7411 (W), 7387 (W), 7384 (W),
7308 (W), 7289 (W), 7288 (W), 7272 (W),
7228 (W), 7228 (W), 7228 (W), 7228 (W),
7173 (W), 7103 (W), 7078 (W), 7066 (W),
7047 (W), 7047 (W), 7025 (W), 6982 (W),
6927 (W), 6874 (W), 6874 (W), 6658 (W),
6522 (W), 6122 (W), 5851 (W), 5851 (W),
5851 (W), 5851 (W), 5851 (W), 5851 (W),
5851 (W), 5851 (W), 5851 (W), 4266 (W),
2940 (W), 2692 (W)
No, see:
8118 (W),
8088 (W),
7805 (W),
7594 (W),
7562 (W),
6952 (W),
6874 (W),
6658 (W),
6545 (W),
5848 (W),
5847 (W),
5846 (W)
Yes, see:
8310 (W),
8293 (W),
8212 (W),
8212 (W),
8199 (W),
7721 (W),
7631 (W),
7619 (W),
7495 (W),
6952 (W),
6952 (W),
6729 (W),
6698 (W),
6547 (W),
6377 (W),
5889 (W)
Sim-API8212 (W), 8118 (W), 8115 (W), 8088 (W),
7808 (W), 7808 (W), 7804 (VI), 7764 (W),
7721 (W), 7698 (W), 7642 (W), 7594 (W),
7581 (W), 7562 (W), 7392 (W), 7281 (W),
7267 (W), 7231 (W), 7204 (W), 7197 (W),
7047 (W), 7006 (W), 7001 (W), 6952 (W),
6952 (W), 6874 (W), 6729 (W), 6635 (W),
6633 (W), 6584 (W), 6547 (W), 6545 (W),
6467 (W), 6377 (W), 6350 (W), 5889 (W),
5889 (W), 5850 (W), 5849 (W), 5848 (W),
5847 (W), 5846 (W), 5845 (W), 5844 (W),
5381 (W), 4981 (W), 4922 (W)
8310 (W), 8293 (W), 8256 (W), 8249 (W),
8245 (W), 8242 (W), 8239 (W), 8228 (W),
8224 (W), 8224 (W), 8212 (W), 8199 (W),
8195 (W), 8180 (W), 8117 (W), 7961 (W),
7869 (W), 7805 (W), 7800 (W), 7652 (W),
7633 (W), 7631 (W), 7619 (W), 7528 (W),
7501 (W), 7495 (W), 7411 (W), 7387 (W),
7384 (W), 7308 (W), 7289 (W), 7288 (W),
7272 (W), 7228 (W), 7228 (W), 7228 (W),
7228 (W), 7173 (W), 7155 (W), 7103 (W),
7078 (W), 7066 (W), 7047 (W), 7047 (W),
7047 (W), 6982 (W), 6965 (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)
No, see:
8118 (W),
8088 (W),
7805 (W),
7594 (W),
7562 (W),
7047 (W),
6965 (W),
6952 (W),
6874 (W),
6658 (W),
5848 (W),
5847 (W),
5846 (W),
4981 (W)
Yes, see:
8310 (W),
8293 (W),
8212 (W),
8212 (W),
8199 (W),
7721 (W),
7631 (W),
7619 (W),
7495 (W),
6965 (W),
6952 (W),
6952 (W),
6729 (W),
6547 (W),
6377 (W),
5889 (W)

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

  • Extended memory map for greater calibration and RAM consumption on X657

    CR 7902 (W), affects C-API

    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

    CR 7810 (W), affects C-API

    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

    CR 6698 (W), affects C-API

    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.

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • New types of PID supported, plus diagnostic callbacks introduced

    CR 6696 (W), affects C-API

    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

    CR 6584 (W), affects Sim-API and C-API

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

    CR 4981 (W), affects Sim-API

    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

    CR 4922 (W), affects Sim-API and C-API

    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

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.

  • Additional DTC parameters can be made calibratable

    CR 8088 (W), affects Sim-API and C-API

    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

    CR 7281 (W), affects Sim-API and C-API

    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 DTC parameters." option under "Real-Time Workshop/OpenECU ASAP2 generation options" in Simulink "Configuration Parameters" (for Simulink users).

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Changed Sim-API model builds to use the C-API tool to generate glue code and ASAP2 files

    CR 7047 (W), affects Sim-API

    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

    CR 6545 (W), affects C-API

    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

    CR 6289 (W), affects C-API

    See the C-API user guide for further details.

  • Added support for using the C-API tool during the build process

    CR 5889 (W), affects Sim-API

    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

    CR 4228 (W), affects C-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Added interface to handle J1939 DM16 transmission

    CR 8115 (W), affects Sim-API and C-API

    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

    CR 5847 (W), affects Sim-API and C-API

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

OpenECU software, examples and documentation are accessible through the desktop, from the Windows Start button.

  • Added password protection to installer

    CR 6545 (W), affects Sim-API and C-API

    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.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Add CAPI support for J1939 messages DM35, DM36, DM37, DM38, DM39 and DM40

    CR 7899 (W), affects C-API

    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.

    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

    CR 7808 (W), affects Sim-API 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

    CR 7808 (W), affects Sim-API and C-API

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

    CR 7764 (W), affects Sim-API

    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

    CR 7698 (W), affects Sim-API

    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)

    CR 7648 (W), affects 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

    CR 7642 (W), affects Sim-API and C-API

    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

    CR 7594 (W), affects Sim-API and C-API

    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

    CR 7581 (W), affects Sim-API

    Simulink blocks to support ISO-15765 J1979 service 06 and In-Use Performance Ratio monitoring (PPR) have been added.

  • Removal of deprecated SPI blocks

    CR 7562 (W), affects Sim-API and C-API

    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

    CR 7279 (W), affects C-API

    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

    CR 7267 (W), affects Sim-API and C-API

    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

    CR 7231 (W), affects Sim-API

    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

    CR 7212 (W), affects C-API

    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.

  • Simulink block support for DTC-related J1939 DMs

    CR 7204 (W), affects Sim-API

    Simulink block support for DM3, DM6, DM11, DM12, DM23, DM27 and DM28 has been added.

  • OBD-related J1939 diagnostic readiness messaging blocks

    CR 7197 (W), affects Sim-API

    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

    CR 7006 (W), affects Sim-API and C-API

    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

    CR 6930 (W), affects C-API

    Support for a J1939 DM message acknowledgement response has been added.

  • OBD-related J1939 diagnostic readiness messaging support

    CR 6928 (W), affects C-API

    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

    CR 6874 (W), affects Sim-API and C-API

    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

    CR 6134 (W), affects C-API

    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

    CR 5879 (W), affects C-API

    Reporting of this data will be added in a future release.

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.

  • Changed sampling mechanism for ADC inputs needed to enter reprogramming mode for the U82 target

    CR 8212 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added primary boot-loader stage to firmware, to allow for inspection of returned ECUs

    CR 7721 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added J1939 reprogramming support

    CR 6952 (W), affects Sim-API and C-API

    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:

    FunctionalityRelease
    Security exchange with dummy security algorithm This
    Security exchange with Savanna specific security algorithm Subsequent
    Does not include processing for DM14, DM15 and DM16 messages unrelated to boot-load This
    Firmware handling of DM14, DM15 and DM16 messages for boot-load reprogramming. Includes: boot-load, erase, write, read, operation complete and EDCP generation message handling This
    Firmware transmission of ECU identification information Subsequent
    Documentation for J1939 reprogramming Subsequent

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Updated J1939 reprogramming support

    CR 6952 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Alteration of ADC inputs needed to enter reprogramming mode for the U82 target

    CR 6729 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • ADC calibration in the bootloader has been added for the U82 target

    CR 6547 (W), affects Sim-API and C-API

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Alternative method of entering reprogramming mode added for the U82 target

    CR 6377 (W), affects Sim-API and C-API

    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, CR 6547 (W) has been raised to an ADC calibration. This work will be completed in a later release.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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.

  • Support for open load detection on H-bridge outputs on the U82 ECU

    CR 7392 (W), affects Sim-API and C-API

    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

    CR 7001 (W), affects Sim-API and C-API

    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

    CR 6635 (W), affects Sim-API and C-API

    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

    CR 6633 (W), affects Sim-API and C-API

    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

    CR 6467 (W), affects Sim-API and C-API

    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

    CR 5850 (W), affects Sim-API and C-API

    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

    CR 5849 (W), affects Sim-API and C-API

    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

    CR 5848 (W), affects Sim-API and C-API

    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.

  • Added ability to stagger some digital output functions

    CR 5846 (W), affects Sim-API and C-API

    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

    CR 5845 (W), affects Sim-API and C-API

    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.

    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

    CR 5844 (W), affects Sim-API and C-API

    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

    CR 5381 (W), affects Sim-API and C-API

    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.

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Flash memory filesystem feature (PFS) added for U82 target

    CR 6350 (W), affects Sim-API and C-API

    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

    CR 5148 (W), affects C-API

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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Change U82 C-sample support into U82 XNOx-sample support

    CR 8118 (W), affects Sim-API and C-API

    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:

    PinComment
    A3Affects digital output
    A4+A5+A6Affects BLDC output, current fault monitor
    A9Affects digital input
    A10Affects digital output, current trip and threshold monitors
    A14Affects digital output, peak/hold thresholds, clock, mode and current trip monitor
    A16Affects digital output, current trip and dwell monitors
    A17Affects digital output, current trip and dwell monitors
    A19Affects digital input
    A46Affects digital output, current trip, threshold and voltage monitors
    B2Affects digital input
    B3Affects digital ouptut
    B5Affects digital input
    B6Affects digital input and voltage monitor
    B7Affects digital input
    B8Affects digital input
    B12Affects 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

    CR 5889 (W), affects Sim-API and C-API

    Support for the M220-00 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.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

3.19.2. Fixes and improvements

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

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.

  • Correction to algorithm for reading the ECU's registry or manufacturing data

    CR 8228 (W), affects Sim-API and C-API

    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

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.

  • Automatic DTC calibrations are incorrectly generated during an application build

    CR 7961 (W), affects Sim-API and C-API

    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

    CR 7173 (W), affects Sim-API and C-API

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • ECU reset when DTCs cleared on engine running timer where DTCs have freeze frames

    CR 8195 (W), affects Sim-API and C-API

    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

    CR 8117 (W), affects Sim-API and C-API

    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

    CR 7528 (W), affects Sim-API

    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

    CR 7047 (W), affects Sim-API and C-API

    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

    CR 7047 (W), affects Sim-API and C-API

    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

    CR 7047 (W), affects Sim-API

  • Correction to compiler check

    CR 6542 (W), affects Sim-API

    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

    CR 4951 (W), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Zero length Erase, Write or Read J1939 Memory Access commands are not supported anymore

    CR 8310 (W), affects Sim-API and C-API

    A zero-length Erase, Write or Read does not make sense and therefore they are now rejected.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Longer than allowed J1939 DM16 messages are not supported anymore

    CR 8293 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Correction to possible buffer overflow for J1939 DM16 message

    CR 8256 (W), affects Sim-API and C-API

    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

    CR 8245 (W), affects Sim-API and C-API

    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

    CR 8242 (W), affects Sim-API and C-API

    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

    CR 8239 (W), affects Sim-API and C-API

    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)

    CR 7066 (W), affects Sim-API and C-API

    Under certain circumstances, bits outside of a field could get corrupted during packing. This has been corrected.

  • FreeCCP/DevCCP installer and Kvaser operation

    CR 6982 (W), affects Sim-API and C-API

    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

    CR 4266 (W), affects Sim-API and C-API

    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

    CR 2692 (W), affects Sim-API and C-API

    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.

Developer and supporting scripts/documentation

Changes related to OpenECU's development environment.

  • Servicing external watchdog in prg2prg and prg for X657 target

    CR 7495 (W), affects Sim-API and C-API

    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.

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Fixed incorrect behaviour for DTE numerator and denominator updates

    CR 8249 (W), affects Sim-API

    Previously, a requested numerator update via the ppr_DiagnosticTestEntity block incorrectly resulted in a denominator increment and vice-versa.

  • Freeze frame buffer wraparound error

    CR 8224 (W), affects Sim-API and C-API

    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

    CR 8224 (W), affects Sim-API and C-API

    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

    CR 7805 (W), affects Sim-API and C-API

    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

    CR 7800 (W), affects Sim-API and C-API

    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

    CR 7718 (W), affects C-API

    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

    CR 7652 (W), affects Sim-API and C-API

    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

    CR 7633 (W), affects Sim-API and C-API

    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), 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

    CR 7501 (W), affects Sim-API and C-API

    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

    CR 7411 (W), affects Sim-API and C-API

    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

    CR 7384 (W), affects Sim-API and C-API

    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)

    CR 7308 (W), affects Sim-API and C-API

    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

    CR 7289 (W), affects Sim-API and C-API

    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

    CR 7288 (W), affects Sim-API and C-API

  • Off by one” error related to the drive and warm-up cycles

    CR 7272 (W), affects Sim-API and C-API

    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

    CR 7228 (W), affects Sim-API and C-API

    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

    CR 7228 (W), affects Sim-API and C-API

    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

    CR 7228 (W), affects Sim-API and C-API

    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

    CR 7228 (W), affects Sim-API and C-API

    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

    CR 7155 (W), affects Sim-API

    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

    CR 7103 (W), affects Sim-API and C-API

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

    CR 7078 (W), affects Sim-API and C-API

    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

    CR 6927 (W), affects C-API

  • The inclusion of a piso_Configuration block is no longer a requirement when using pdtc_DiagnosticTroubleCodeExt blocks

    CR 6874 (W), affects Sim-API and C-API

    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

    CR 6874 (W), affects Sim-API and C-API

    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

    CR 6658 (W), affects Sim-API and C-API

    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

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.

  • 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

    CR 6522 (W), affects C-API

    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

    CR 6122 (W), affects C-API

    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

    CR 2826 (W), affects Sim-API

    The Simulink examples have been extended to include a sample application that illustrates how C code can be use in an OpenECU Simulink model.

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.

  • Changed voltage levels of ADC inputs needed to enter reprogramming mode for the U82 target

    CR 8212 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Updated firmware to allow CCP and J1939 to use the same CAN bus while reprogramming

    CR 8199 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Corrected negative FEPS operation in M220 firmware

    CR 7631 (W), affects Sim-API and C-API

    This change configures the M220 such that negative FEPS now works correctly and enters reprogramming mode using the default CAN configuration.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Corrected power-hold behaviour of the M220 firmware

    CR 7619 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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.

  • Preprocessor inclusions for GPIO digital inputs

    CR 7387 (W), affects Sim-API and C-API

    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

    CR 6965 (W), affects Sim-API

    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:

    PinA-sampleC-sample
    A1+A30Thermal trip monitorCurrent trip monitor, temperature monitor
    A7+A8Digital monitorCurrent trip, short circuit and undervoltage monitor
    A10-Current threshold monitor
    A11-Current threshold monitor
    A12-Current threshold monitor
    A15Spark output-
    A17Digital outputSpark output
    A19Analogue inputDigital input
    A45-Current threshold monitor
    A46-Current threshold monitor
    B9Digital inputAnalogue input
    B10FEPS-
    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.9.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Correction to the H-Bridge fault indicator input on U82

    CR 6965 (W), affects Sim-API

    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

    CR 2940 (W), affects Sim-API and C-API

    In models without the TDC-firing trigger, the fastest model rate task definition was incorrectly dropped from the schedule. This has been corrected.

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.

  • Correction to installer for R2010a

    CR 6374 (W), affects Sim-API

    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.

    Now, the installer does not skip updating MATLAB's path for MATLAB R2010a.

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.

  • Restore of IUPR NVM data on power-up

    CR 8180 (W), affects Sim-API and C-API

    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)

    CR 5851 (W), affects Sim-API and C-API

  • Removed quadrature decode functionality from U82 target for eTPU code space purposes

    CR 5851 (W), affects Sim-API and C-API

  • Updated range of I/O channels for U82 technical specification

    CR 5851 (W), affects Sim-API and C-API

  • Draft U82 technical specification

    CR 5851 (W), affects Sim-API and C-API

  • Correction to channel assignment for dwell feedback channels to match U82 rev1mod2 PCB changes

    CR 5851 (W), affects Sim-API and C-API

  • Correction to over-current trip handling through the pss_OvercurTripReset block

    CR 5851 (W), affects Sim-API and C-API

  • Changed names of various input channels for the U82 target

    CR 5851 (W), affects Sim-API and C-API

    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

    CR 5851 (W), affects Sim-API and C-API

  • Draft U82 technical specification

    CR 5851 (W), affects Sim-API and C-API

    Added draft U82 technical specification to remove some TODO items (more left to do, technical specification is unreviewed, please treat with care)

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.

  • Improve Power hold description entry in user documentation

    CR 7869 (W), affects Sim-API and C-API

    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

    CR 7025 (W), affects C-API

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

Table 3.17.  Release summary for v1.8.6

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRs6591 (W)YesNo
Sim-APINo CRs6591 (W)YesNo

3.20.1. Fixes and improvements

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

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.

  • Corrected an incorrect channel assignment for the M460 target

    CR 6591 (W), affects Sim-API and C-API

    Previously, the M460's C7 pin had an incorrect channel defined which prevented correct operation when used as a digital input.

3.21.  Release 1.8.5

Release labelled release-1.8.5 from 20 December 2010. 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.18.  Release summary for v1.8.5

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API5971 (W), 5813 (W), 5700 (W), 4247 (W)6138 (W), 6047 (W), 5737 (W), 2175 (W)No, see:
6138 (W)
No
Sim-API5791 (W), 5700 (W), 4247 (W)6507 (W), 6047 (W), 5737 (W), 5708 (W),
4563 (W), 4400 (W), 4209 (W), 2175 (W)
No, see:
4209 (W)
No

3.21.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/Simulink R2010a

    CR 5791 (W), affects Sim-API

    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

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.

  • Added Vector CANape v8.0 support in the ASAP2 file generation

    CR 4247 (W), affects Sim-API and C-API

    Further details are described in the Supporting tools section of the user guides.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Corrected issue with checksum during ISO reprogramming

    CR 5971 (W), affects C-API

  • Added handling of DTC ageing by platform in accordance with CARB-OBD rules

    CR 5813 (W), affects C-API

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.

  • Added angular spark functionality for M250 targets

    CR 5700 (W), affects Sim-API and C-API

    Angular spark functionality is now available via the pan_SparkConfig and pan_Spark blocks on M250 targets.

3.21.2. Fixes and improvements

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

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.

  • Corrected dynamic inport sizing for adaptive 2D map lookup block

    CR 5708 (W), affects Sim-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Eliminated use of individual linker files in C-API applications

    CR 6138 (W), affects C-API

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

    CR 4209 (W), affects Sim-API

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correction to Vector CANdb file handling

    CR 6507 (W), affects Sim-API

    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

    CR 6047 (W), affects Sim-API and C-API

    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

    CR 4400 (W), affects Sim-API

    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.

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.

  • Corrected the angular diesel injection functionality

    CR 5737 (W), affects Sim-API and C-API

    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

    CR 4563 (W), affects Sim-API

    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

    CR 2175 (W), affects Sim-API and C-API

3.22.  Release 1.8.4

Release labelled release-1.8.4 from 18 October 2010. 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.19.  Release summary for v1.8.4

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API4211 (W)5702 (W)YesYes, see:
5702 (W),
4211 (W)
Sim-APINo CRs5702 (W)YesYes, see:
5702 (W)

3.22.1. New features

New features introduced by this version, or significant changes to existing features.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Added first basic support for ISO-15765 based flash reprogramming

    CR 4211 (W), affects C-API

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.8.4 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

3.22.2. Fixes and improvements

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

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.

  • Corrected issue with application checksum calculation

    CR 5702 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.8.4 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

3.23.  Release 1.8.3

Release labelled release-1.8.3 from 21 July 2010. 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.


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

  • Allow the idle background task to access model resources and to indirectly access platform owned based resources for digital I/O and CAN communications

    CR 3242 (W), affects C-API

    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

    CR 3242 (W), affects C-API

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

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Added support for a subset of ISO-15765 based diagnostics

    CR 4162 (W), affects C-API

    The C-API has been updated to add support for the following services through the PDG, PDTC and PPID features:

    IDServiceNotes
    0x03ReadEmissionDTCs
    (J1979)
    Reports only DTCs defined as emission-related
    0x04ClearEmissionDTCs
    (J1979)
    Clears only DTCs defined as emission-related
    0x14ClearDiagInfo
    (KW2000-3/UDS)
    Clears all ISO DTCs (not J1939-only DTCs)
    0x18ReadDTCByStatus
    (KW2000-3)
    All DTCs, regardless of emissions severity
    0x19ReadDTCInfo
    (UDS)
    16-bit DTCs currently output, higher byte zero
    0x22ReadDataByCommonID
    (KW2000-3/UDS)
    Used to read PID values
    0x2FIOControlByCommonID
    (KW2000-3, UDS)
    Used to override PID values
    0x3ETesterPresentPing 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.

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.

  • Added repeated reset catch to prevent an ECU application from continually resetting and becoming unresponsive

    CR 4210 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.8.3 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added application code and data checks prior to invoking the application

    CR 3376 (W), affects C-API

    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.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.8.3 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added tests on RAM prior to starting the application

    CR 3242 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.8.3 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

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.

  • Added support for the pdx_QuadratureDecode, pdx_QuadrateDecodeAndFrequencyInput blocks to the M2xx and M4xx ECUs

    CR 3573 (W), affects Sim-API

  • Added an enhanced analogue input processing function

    CR 3242 (W), affects C-API

    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

    CR 2515 (W), affects Sim-API and C-API

    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.

    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.

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.

  • Allow the “idle” background task to lock resources

    CR 5174 (W), affects C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Replaced support for M250 rev-1 ECUs with support for M250 rev-2 ECUs

    CR 4222 (W), affects Sim-API and C-API

    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

    CR 2515 (W), affects Sim-API and C-API

    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;

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

3.23.2. Fixes and improvements

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

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.

  • Corrected macro for ptm_get_sys_time() and similar functions

    CR 4584 (W), affects C-API

    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

    CR 4389 (W), affects C-API

  • Corrected duplicate error codes reported by the C-API interface tool

    CR 3382 (W), affects C-API

    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

    CR 3256 (W), affects C-API

    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.

  • Updated command line options for the C-API interface tool

    CR 3256 (W), affects C-API

    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

    CR 3242 (W), affects C-API

    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

    CR 2767 (W), affects Sim-API

    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

    CR 2515 (W), affects Sim-API

    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

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.

  • Corrected validation of C-style data dictionaries

    CR 4849 (W), affects C-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Corrected C-API tool code generation

    CR 5323 (W), affects C-API

    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

    CR 2473 (W), affects Sim-API and C-API

    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

    CR 1974 (W), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Corrected documentation in the J1939 receive and transmit blocks for LS and MS packing

    CR 4391 (W), affects Sim-API

    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

    CR 4378 (W), affects Sim-API and C-API

    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

    CR 2195 (W), affects Sim-API and C-API

    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.

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.

  • Corrected issue with PWM generation

    CR 5346 (W), affects Sim-API and C-API

    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

    CR 4755 (W), affects Sim-API and C-API

    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

    CR 4560 (W), affects Sim-API

    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

    CR 3630 (W), affects Sim-API and C-API

    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

    CR 2597 (W), affects Sim-API

    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

    CR 1902 (W), affects Sim-API

    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.

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.

  • Corrected task timing

    CR 4904 (W), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Corrected G850 technical specification regarding use of Hall-effect crank sensors

    CR 4521 (W), affects Sim-API and C-API

    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

    CR 3713 (W), affects Sim-API and C-API

    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

    CR 2690 (W), affects Sim-API and C-API

    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

    CR 1925 (W), affects Sim-API and C-API

    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

    CR 1914 (W), affects Sim-API and C-API

    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.24.  Release 1.8.2

Release labelled release-1.8.2 from 25 April 2010. 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.21.  Release summary for v1.8.2

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRs4377 (W), 4372 (W), 3948 (W), 3653 (W),
3356 (W), 2175 (W)
No, see:
3356 (W),
2175 (W)
No
Sim-API3944 (W)4590 (W), 4495 (W), 4395 (W), 4394 (W),
4377 (W), 4372 (W), 4052 (W), 4050 (W),
3948 (W), 3653 (W), 3356 (W)
No, see:
3356 (W)
No

3.24.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 checks on the compiler prior to starting the compilation stage of the build process

    CR 3944 (W), affects Sim-API

    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

    to run those checks manually.

3.24.2. Fixes and improvements

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

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.

  • Work-around to Simulink warning messages with models that include large quantities of tunable parameters

    CR 4590 (W), affects Sim-API

    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

    CR 4495 (W), affects Sim-API

    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

    CR 2175 (W), affects C-API

    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 nameNew name
    A450
    NonePIO_AIN_A19_A29_A39_A40_MONITOR_V
    NonePIO_DIN_A19_A29_A39_A40_MONITOR_CT
    G850
    PIO_AIN_[...]_MONITORPIO_AIN_[...]_MONITOR_V
    PIO_AIN_C35_C36PIO_AIN_C35_C36_VPWR
    PIO_DIN_[...]_MONITORPIO_DIN_[...]_MONITOR_D
    PIO_PIN_[...]_MONITOR_MAXPIO_PIN_[...]_MONITOR_CT_MAX
    PIO_PIN_[...]_MONITOR_NOMPIO_PIN_[...]_MONITOR_CT_NOM
    M460
    NonePIO_AIN_A19_A29_A39_A40_MONITOR_V
    PIO_AIN_INT_EXTERN_GROUNDPIO_AIN_C9_C19_EXTERN_GND
    NonePIO_DIN_A19_A29_A39_A40_MONITOR_CT
    M461
    PIO_AIN_INT_PSUPOS_5VQPIO_AIN_A9_A19_C9_C19_EXTERN_GND
    NonePIO_AIN_INT_COLD_JUNCTION_TEMP

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Remove error after model build completes when the break-links option is on

    CR 4052 (W), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Fixed interrupt processing issue

    CR 4377 (W), affects Sim-API and C-API

    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.

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.

  • Corrected the inversion parameter in the digital input block

    CR 4050 (W), affects Sim-API

    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.

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Updated non-volatile memory blocks and map lookup blocks to remove unexpected MATLAB crashes

    CR 4395 (W), affects Sim-API

    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

    CR 4394 (W), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Updated G850 technical specification to show 2 CAN interfaces for fleet units

    CR 4372 (W), affects Sim-API and C-API

  • Updated connector image for M460, M461 and A450 to avoid confusion

    CR 3948 (W), affects Sim-API and C-API

    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

    CR 3653 (W), affects Sim-API and C-API

    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.

  • Removed selection of current trip level for pins A1, A11, A21 and A31 on the M461-00 ECU

    CR 3356 (W), affects Sim-API and C-API

    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.25.  Release 1.8.1

Release labelled release-1.8.1 from 9 November 2009. 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.22.  Release summary for v1.8.1


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

  • Remove include order dependencies for C-API header files

    CR 3274 (W), affects C-API

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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Added support for Embedded Coder

    CR 2489 (W), affects Sim-API

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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and 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

    CR 2950 (W), affects Sim-API and C-API

    Now there are two different versions of boot and prg images that can be flashed into the ECU.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.8.1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Added support for FEPS-less reprogramming on A450, M460, and M461 targets

    CR 2950 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.8.1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • 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

    CR 2950 (W), affects Sim-API and C-API

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.

  • Ensure all A/D channels are sampled at least twice as quick as the fastest software task

    CR 3369 (W), affects Sim-API and C-API

    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

    CR 2074 (W), affects Sim-API and C-API

    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.

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

  • 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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Added selection of current trip level for pins A1, A11, A21 and A31 on the M461 ECU

    CR 3356 (W), affects Sim-API and C-API

    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

    CR 3356 (W), affects Sim-API and C-API

    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)

    CR 2517 (W), affects Sim-API and C-API

    Support for the M250-00 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.

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

3.25.2. Fixes and improvements

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

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.

  • Corrections to use single float math operations wherever possible

    CR 3466 (W), affects Sim-API and C-API

    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

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.

  • Raise an error in DDE files if there is more information than columns

    CR 3274 (W), affects C-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correction to CCP driver

    CR 2711 (W), affects Sim-API and C-API

    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

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.

  • Correct linker files for C-API examples

    CR 3022 (W), affects C-API

    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.

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.

  • Remove the need to call the pan_ignore_cam_sync() C-API function on a continual basis

    CR 3349 (W), affects C-API

    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

    CR 1903 (W), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Included cold-junction temperature input for M461 ECU

    CR 3470 (W), affects Sim-API and C-API

    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.26.  Release 1.8.0

Release labelled release-1.8.0-internal-dev-1 from 4 July 2009. 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.23.  Release summary for v1.8.0

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API2940 (W), 2226 (W), 2175 (W)3470 (W), 2549 (W)No, see:
2175 (W)
No
Gateway2226 (W), 2175 (W)3470 (W), 1896 (W)No, see:
2175 (W)
No
Sim-API2226 (W), 2175 (W)3470 (W), 3111 (W), 1155 (VI)No, see:
2175 (W)
No

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

  • Merged 1.5.x, 1.6.x and 1.7.x releases of software together

    CR 2175 (W), affects Sim-API and C-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Update FreeCCP to work with A450, M460 and M461 ECUs

    CR 2226 (W), affects Sim-API and C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Extended the C-API to include the G850 target ECU

    CR 2940 (W), affects C-API

    The C-API has been extended to include the G850 target ECU. Some of the notable changes include:

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

      Previous nameNew name
      PIO_TIME_PIN_TOUT_MIN_USPIO_RATE_FIN_MIN_HZ
      PIO_TIME_PIN_TOUT_MAX_USPIO_RATE_FIN_MAX_HZ
      PIO_TIME_PWMI_TOUT_MIN_USPIO_RATE_PWMI_MIN_HZ
      PIO_TIME_PWMI_TOUT_MAX_USPIO_RATE_PWMI_MAX_HZ
      PIO_BUS_CAN_[pin-names]PIO_CAN_[pin-name]
      PIO_AIN_INT_CJ_TEMPPIO_AIN_[pin-names]_COLD_JUNCTION_TEMP
      PIO_AIN_INT_VBATPIO_AIN_[pin-names]_VPWR
      PIO_AIN_C24_C25PIO_AIN_C24_C25_DIFF
      PIO_AIN_INT_PSU_POS_3V3PIO_AIN_INT_PSUPOS_3V3
      PIO_AIN_INT_PSU_POS_5VDPIO_AIN_INT_PSUPOS_5VD
      PIO_DIN_[pin-name]_MONITOR_CPIO_DIN_[pin-name]_MONITOR_CT
      PIO_DOT_INT_PSU_HOLDPIO_DOT_A12_HOLD_PSU
      PIO_DOT_C8_EXTPSU3PIO_DOT_C8_SWITCH_PSU3
      PIO_DOT_C18_EXTPSU4PIO_DOT_C18_SWITCH_PSU4
      PIO_POT_[pin-name]_INJ_CLOCKPIO_POT_[pin-name]_DOT_INJECTOR_CLOCK
      PIO_SPOT_INT_SLAVE_[pin-name]PIO_SPOT_[pin-name]_SLAVE
      PIO_DOT_INT_OVERCURRENT_TRIP_1PIO_DOT_[pin-names]_
      OVER_CURRENT_TRIP_RESET_1
      PIO_DOT_A31_SOFTSWITCHPIO_DOT_A31_FN_SWITCH
      PIO_DOT_INT_OVERCURRENT_TRIP_2PIO_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.

3.26.2. Fixes and improvements

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

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.

  • Data dictionary files may now use ** rather than -- to start a comment line

    Affects Sim-API and C-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • 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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correction to J1939 receive and transmit blocks

    CR 3111 (W), affects Sim-API

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

  • 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

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.

  • Corrected path information in C-API example build batch files

    CR 2549 (W), affects C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Corrected the gain in the cold junction voltage equation in the A450 and M460 technical specifications

    CR 3470 (W), affects Sim-API and C-API

3.27.  Release 1.7.5

Release labelled release-1.7.5 from 14 May 2009. 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.24.  Release summary for v1.7.5

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-API2519 (W)2520 (W), 2471 (W), 1956 (W)YesNo
Gateway2519 (W)2520 (W), 2471 (W), 1956 (W)YesNo
Sim-API2688 (W), 2688 (W), 2519 (W)2520 (W), 2471 (W), 1996 (W), 1956 (W),
1911 (W)
No, see:
2688 (W)
No

3.27.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 R2006b, R2007b and R2008b

    CR 2688 (W), affects Sim-API

    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:

      PreviousUpdatedUse
      Documentation
      help openecuhelp openecuPrint list of commands to the console
      ver openecuver openecuPrint version of OpenECU blockset to the console
      Blockset
      openecu_blocksetoe_blocksetOpen the OpenECU blockset library
      openecu_examplesoe_examplesOpen the OpenECU examples model
      Model and build list actions
      create_openecu_modeloe_create_modelCreate a new OpenECU model in the current directory
      read_build_listoe_read_build_listRead the model data dictionaries into the workspace
      clear_build_listoe_clear_build_listRemove workspace DD entries and build list paths
      Supporting tools
      freeccpoe_freeccpDownload built model to an OpenECU via CAN/CCP
      Paths to OpenECU objects
      path_openecu_examplesoe_path_examplesPrint path to OpenECU top level example files
      path_openecu_helpoe_path_helpPrint path to OpenECU help files
      -oe_path_installPrint path to OpenECU installation directory
      path_openecu_pythonoe_path_pythonPrint path to OpenECU python installation
      path_openecu_rootoe_path_rootPrint root path to the OpenECU blockset
      path_openecu_toolsoe_path_toolsPrint 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

    CR 2688 (W), affects Sim-API

    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.

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.

  • Added a PWM input block (Simulink) and function (C-API)

    CR 2519 (W), affects Sim-API and 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.

3.27.2. Fixes and improvements

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

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Rebuild models completely when changing version of OpenECU

    CR 1996 (W), affects Sim-API

    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.

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correction to handling of CAN bus-off status

    CR 2520 (W), affects Sim-API and C-API

    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

    CR 1956 (W), affects Sim-API and C-API

    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

    CR 1911 (W), affects Sim-API

    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.

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Changes to handle non-correctable Flash errors during power-on for A450, M460 and M461 ECUs

    CR 2471 (W), affects Sim-API and C-API

    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 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.28.  Release 1.7.4

Release labelled release-1.7.4 from 14 January 2009. 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.25.  Release summary for v1.7.4

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRsNo CRsYesNo

3.28.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Added support for M461-00 ECU target

    Affects Sim-API and C-API

    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.

    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

    This feature is not available on the M461 target.

    High side diagnostic weak pull up switch

    This feature is not available on the M461 target.

    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.28.2. Fixes and improvements

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

3.29.  Release 1.7.3

Release labelled release-1.7.3 from 28 November 2008. 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.26.  Release summary for v1.7.3

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs1227 (VI), 1225 (VI)YesNo

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

  • Reading the boot code major version number

    Affects Sim-API and C-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Added support for M460-00 ECU target

    Affects Sim-API and C-API

    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.

    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.

3.29.2. Fixes and improvements

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

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.

  • Incorrect port type setting in mdlSetInputPortDataType for put_calmap2d block

    CR 1225 (VI), affects Sim-API

    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

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.

  • Correct ASAP2 file generation for some DDE names

    CR 1227 (VI), affects Sim-API

    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

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.

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

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.

  • Actuator supply disabled when running reprogramming software

    Affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.7.3 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Correction to A450 digital output pin selection

    Affects Sim-API and C-API

    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.30.  Release 1.7.2

Release labelled release-1.7.2 from 18 November 2008. 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.27.  Release summary for v1.7.2

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRsNo CRsYesNo

3.31.  Release 1.7.1

Release labelled release-1.7.1 from 24 September 2008. 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.28.  Release summary for v1.7.1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRsNo CRsYesNo

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

3.31.2. Fixes and improvements

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

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.

  • 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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Removed C29 from the A450 I/O set

    Affects Sim-API and C-API

    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.32.  Release 1.7.0

Release labelled release-1.7.0 from 11 June 2008. 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.29.  Release summary for v1.7.0

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRsNo CRsYesNo

3.32.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Added support for the scale and offset columns in the data dictionary files

    Affects Sim-API

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.

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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

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

3.32.2. Fixes and improvements

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

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and 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.

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.

  • 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.33.  Release 1.6.4

Release labelled release-1.6.4 from 13 March 2009. 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.30.  Release summary for v1.6.4

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRs2169 (W), 2062 (W)YesYes, see:
2169 (W),
2062 (W)
GatewayNo CRs2169 (W), 2062 (W)YesYes, see:
2169 (W),
2062 (W)
Sim-APINo CRs2173 (W), 2169 (W), 2062 (W), 1995 (W),
1958 (W), 1228 (VI), 1217 (VI), 1211 (VI)
YesYes, see:
2169 (W),
2062 (W)

3.33.1. New features

New features introduced by this version, or significant changes to existing features.

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

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

3.33.2. Fixes and improvements

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

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.

  • Correct size of DAQ lists in INCA ASAP2 generation

    CR 1958 (W), affects Sim-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Correct handling of Simulink MAX block when generating code

    CR 2173 (W), affects Sim-API

    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.

  • MATLAB R14.2 build fails because of issue in TLC file of pan_KnockFeedback block

    CR 1995 (W), affects Sim-API

    Previously, MATLAB R14.2 build fails with the pan_KnockFeedback block.

    Now, MATLAB R14.2 builds correctly with the pan_KnockFeedback block.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correct parsing of CANdb files

    CR 1228 (VI), affects Sim-API

    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.

  • Extend range checking of CANdb files to include J1939 message lengths

    CR 1211 (VI), affects Sim-API

    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.

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 build when multiple frequency input blocks are present

    CR 1217 (VI), affects Sim-API

    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.

    Now, the feature incorporates the pin number in the calibration name making each automatic frequency input calibration unique.

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.

  • Correct handling of output drivers on some G850 ECUs

    CR 2169 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.6.4 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Correct unreliable detection of FEPS voltage on some G850 ECUs during power up

    CR 2062 (W), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.6.4 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

3.34.  Release 1.6.3

Release labelled release-1.6.3 from 5 November 2008. 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.31.  Release summary for v1.6.3

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs1206 (VI), 1194 (VI), 1187 (VI), 1187 (VI)No, see:
1194 (VI)
No

3.34.1. Fixes and improvements

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

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.

  • Improve frequency resolution on MIOS channels

    CR 1187 (VI), affects Sim-API

    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)

    CR 1206 (VI), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • G850 channel "IMRC4 monitor" as "IMRC monitor"

    CR 1194 (VI), affects Sim-API

    Previously, the channel was called "IMRC4 monitor".

    Now, the channel is called "IMRC monitor".

    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

    CR 1187 (VI), affects Sim-API

    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.35.  Release 1.6.2

Release labelled release-1.6.2 from 6 June 2008. 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.32.  Release summary for v1.6.2


3.35.1. New features

New features introduced by this version, or significant changes to existing features.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Added a new CCP driver

    CR 1139 (VI), affects Sim-API and C-API

    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

    CR 1120 (VI), affects Sim-API

    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.

Diagnostics (communications and fault handling)

Diagnostic trouble codes and read/write parameter IDs are supported over the ISO-15765 and SAE-J1939 protocols.

  • Added support for Diagnostic Trouble Codes (DTCs)

    CR 1120 (VI), affects Sim-API

    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.

3.35.2. Fixes and improvements

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

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.

  • Corrections to allow INCA to work with the G850

    CR 1168 (VI), affects Sim-API and C-API

    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.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.6.2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Remove CCP reset option

    CR 1170 (VI), affects Sim-API

    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

    CR 1155 (VI), affects Sim-API

    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

    CR 1115 (VI), affects Sim-API

    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

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.

  • Extend list of example models to cover G850 target

    CR 1135 (VI), affects Sim-API

    Previously there were example models for G400 and G800 targets.

    Now there is an equivalent list for G850 target.

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.

  • HCS12 UNI and LSD drivers

    CR 1171 (VI), affects Sim-API and C-API

    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

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.

  • Correctly install INCA PROF configuration files

    CR 1197 (VI), affects Sim-API

    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

    CR 1145 (VI), affects Sim-API

    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.

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Correct simulation behaviour of the adaptive array block

    CR 1190 (VI), affects Sim-API

    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

    CR 1190 (VI), affects Sim-API

    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

    CR 1143 (VI), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • General improvements to the user documentation

    CR 1159 (VI), affects Sim-API

    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

    CR 1144 (VI), affects Sim-API

    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

    CR 1118 (VI), affects Sim-API and C-API

    The bootloader can be reflashed via CCP protocol.

    In previous release, reflash over CCP protocol was only supported for HCS12 application code.

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.6.2 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • HCS12 documentation

    CR 1118 (VI), affects Sim-API

    The documentation related to HCS12 software has been improved.

3.36.  Release 1.6.1

Release labelled release-1.6.1-hcs12-1.0 from 27 March 2008. 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.33.  Release summary for v1.6.1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRs1118 (VI)YesYes, see:
1118 (VI)
GatewayNo CRs1118 (VI)YesYes, see:
1118 (VI)
Sim-APINo CRs1128 (VI), 1127 (VI), 1126 (VI), 1118 (VI)YesYes, see:
1118 (VI)

3.36.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Added support for a new target, the G850-00

    Affects Sim-API and C-API

    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.

3.36.2. Fixes and improvements

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

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.

  • Removed occasional reset during ECU initialisation

    CR 1128 (VI), affects Sim-API

    Previously, the controller would reset during initialisation, prior to running the model. This has been corrected.

  • Corrected boot duration from put_Reset block

    CR 1127 (VI), affects Sim-API

  • Corrected put_Reset block type of outport for logical signals

    CR 1126 (VI), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • HCS12 software

    CR 1118 (VI), affects Sim-API and C-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.6.1 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

3.37.  Release 1.5.9

Release labelled rel_install_1_5_9 from 7 March 2006. 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.34.  Release summary for v1.5.9

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs498 (VI), 497 (VI), 496 (VI), 495 (VI),
494 (VI), 493 (VI), 491 (VI), 480 (VI),
468 (VI), 383 (VI)
YesNo

3.37.1. Fixes and improvements

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

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.

  • Improve CPU loading calculation

    CR 496 (VI), affects Sim-API

    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

    CR 493 (VI), affects Sim-API

  • Improve CPU loading calculation

    CR 383 (VI), affects Sim-API

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.

  • Incorrect ASAP2 generation of group sub-system names

    CR 498 (VI), affects Sim-API

    Previously, any valid sub-system name was passed to the ASAP2 file with minimal change (spaces were changed to '_' characters). The ASAP2 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

    CR 480 (VI), affects Sim-API

    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

    CR 468 (VI), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correct parsing of CANdb files

    CR 495 (VI), affects Sim-API

    Previously, the CANdb parser could not understand some forms of the embedded CANdb BA_ statement resulting in both the CANdb receive and transmit block not showing the requested message signals as inports and outports.

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.

  • Correct fixed angular example models to remove build warnings

    CR 494 (VI), affects Sim-API

    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

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.

  • Include boot code image in an M6 build

    CR 491 (VI), affects Sim-API

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.

  • Updated technical specifications to show the crank input as VRS and Hall effect

    CR 497 (VI), affects Sim-API

3.38.  Release 1.5.8

Release labelled rel_install_1_5_8 from 28 August 2006. 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.35.  Release summary for v1.5.8

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs489 (VI), 484 (VI), 308 (VI)YesNo

3.38.1. Fixes and improvements

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

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.

  • Incorrect web page links in documentation

    CR 484 (VI), affects Sim-API

    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.

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.

  • Improve the time to initially synchronise to the crank trigger wheel

    CR 308 (VI), affects Sim-API

    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

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.

  • Uninstall of tunes does not work

    CR 489 (VI), affects Sim-API

    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.39.  Release 1.5.7

Release labelled rel_install_1_5_7 from 23 February 2006. 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.36.  Release summary for v1.5.7

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs488 (VI)YesNo

3.39.1. Fixes and improvements

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

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.

  • Tune blocks in atomic sub-systems fail to build

    CR 488 (VI), affects Sim-API

    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.40.  Release 1.5.6

Release labelled rel_install_1_5_6 from 20 February 2006. 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.37.  Release summary for v1.5.6

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs485 (VI), 477 (VI)YesNo

3.40.1. Fixes and improvements

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

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.

  • The create_openecu_model command can sometimes fail

    CR 485 (VI), affects Sim-API

    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.

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.

  • The quadrature decode block outputs incorrect count of edges

    CR 477 (VI), affects Sim-API

    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.

3.41.  Release 1.5.5

Release labelled rel_install_1_5_5 from 1 February 2006. 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.38.  Release summary for v1.5.5

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs481 (VI)YesNo

3.41.1. Fixes and improvements

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

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • The pnv_AdaptiveScalar block does not simulate correctly

    CR 481 (VI), affects Sim-API

    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.42.  Release 1.5.4

Release labelled rel_install_1_5_4 from 12 December 2005. 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.39.  Release summary for v1.5.4

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API269 (VI)474 (VI), 473 (VI), 472 (VI)YesNo

3.42.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Add support for the ATI M6 Memory Emulator

    CR 269 (VI), affects Sim-API

    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.

3.42.2. Fixes and improvements

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

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.

  • Incorrect generation of ASAP2 files under MATLAB R14.x

    CR 474 (VI), affects Sim-API

    Previously, the ASAP2 generation script failed due to some of the more recent R14.x blocks.

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.

  • The installer says only MATLAB R12.1, R13.0 and R13.1 are supported

    CR 473 (VI), affects Sim-API

    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.

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.

  • The technical data sheets show knock sensor inputs as unsupported

    CR 472 (VI), affects Sim-API

    The technical data sheets have been updated to show support for the knock sensor pins.

3.43.  Release 1.5.3

Release labelled rel_install_1_5_3 from 22 September 2005. 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.40.  Release summary for v1.5.3

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs470 (VI), 469 (VI)YesNo

3.43.1. Fixes and improvements

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

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.

  • Incorrect typing of ASAP2 variables

    CR 470 (VI), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Incorrect unpacking of signed CANdb signals

    CR 469 (VI), affects Sim-API

    Previously, signed CANdb signals were incorrecly unpacked from CAN messages if the signal became negative.

3.44.  Release 1.5.2

Release labelled rel_install_1_5_2 from 6 September 2005. 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.41.  Release summary for v1.5.2

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs467 (VI)YesNo

3.44.1. Fixes and improvements

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

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correct parsing of CANdb files

    CR 467 (VI), affects Sim-API

    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.45.  Release 1.5.13

Release labelled release-1.5.13 from 25 June 2007. 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.42.  Release summary for v1.5.13

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API620 (VI), 603 (VI), 597 (VI), 586 (VI),
581 (VI), 571 (VI)
632 (VI), 631 (VI), 630 (VI), 625 (VI),
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)
No, see:
618 (VI)
Yes, see:
597 (VI)

3.45.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Derive ASAP2 array and map sizes based on workspace data

    CR 586 (VI), affects Sim-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Add option to allow build to continue if ATI Vision strategy creation fails

    CR 620 (VI), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Increased the number of selectable CAN baud rates

    CR 597 (VI), affects Sim-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.5.13 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Explain how to setup two OpenECUs on the same CAN bus

    CR 571 (VI), affects Sim-API

    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.

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.

  • Added a new output block for generating pulses

    CR 603 (VI), affects Sim-API

    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.

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Addition of a non-volatile array block

    CR 581 (VI), affects Sim-API

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

3.45.2. Fixes and improvements

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

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.

  • Allow very basic models to be built

    CR 559 (VI), affects Sim-API

    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

    CR 555 (VI), affects Sim-API

    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

    CR 553 (VI), affects Sim-API

    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

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.

  • Correct generation of ASAP2 files for enumerated values

    CR 615 (VI), affects Sim-API

    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.

  • Long model names can cause ASAP2 generation to fail

    CR 590 (VI), affects Sim-API

    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

    CR 584 (VI), affects Sim-API

    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

    CR 569 (VI), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correct mistake in the pcx_CANTransmitMessage block description

    CR 631 (VI), affects Sim-API

  • Update signal outports for the CAN receive blocks whenever a CAN message is received

    CR 619 (VI), affects Sim-API

    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

    CR 594 (VI), affects Sim-API

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

    CR 537 (VI), affects Sim-API

    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.

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.

  • Correct mistake in the pdx_PeriodInput block description

    CR 630 (VI), affects Sim-API

  • Improve documentation for the stepper motor block

    CR 625 (VI), affects Sim-API

    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

    CR 623 (VI), affects Sim-API

    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

    CR 622 (VI), affects Sim-API

    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

    CR 618 (VI), affects Sim-API

    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

    CR 570 (VI), affects Sim-API

    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

    CR 566 (VI), affects Sim-API

    Previously, the period input block would incorrectly set the timed_out port every 71 minutes.

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.

  • Restrict M6 emulator functionality for the G400-01 target

    CR 621 (VI), affects Sim-API

    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.

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Correct simulation behaviour for the pnv_Status block

    CR 632 (VI), affects Sim-API

    Previously the pnv_Status block, under simulation, would always set the check-sum outports to zero, regardless of the simulation check-sum inports.

    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

    CR 544 (VI), affects Sim-API

    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

    CR 486 (VI), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Update environmental specifications and references in the user guide and technical specification documents

    CR 591 (VI), affects Sim-API

    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

    CR 568 (VI), affects Sim-API

    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.46.  Release 1.5.12

Release labelled rel_install_1_5_12 from 10 August 2006. 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.43.  Release summary for v1.5.12

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs550 (VI), 543 (VI), 540 (VI), 478 (VI)YesNo

3.46.1. Fixes and improvements

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

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.

  • Free some Workspace memory for larger models

    CR 550 (VI), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Incorrect documentation for CANdb transmit block

    CR 540 (VI), affects Sim-API

    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

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.

  • Incorrect behaviour of OpenECU installation process

    CR 478 (VI), affects Sim-API

    Previously, the installer could prevent the user from completing the installation if a compatible version of MATLAB could not be detected.

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.

  • Corrections to Simulink blockset and documentation for G800 pin B42

    CR 543 (VI), affects Sim-API

    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.47.  Release 1.5.11

Release labelled rel_install_1_5_11 from 3 August 2006. 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.44.  Release summary for v1.5.11

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs547 (VI)YesNo

3.47.1. Fixes and improvements

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

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Adaptive data not retained in large models on a G800

    CR 547 (VI), affects Sim-API

    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.48.  Release 1.5.10

Release labelled rel_install_1_5_10 from 13 July 2006. 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.45.  Release summary for v1.5.10

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API531 (VI), 530 (VI), 529 (VI), 527 (VI),
525 (VI), 524 (VI), 523 (VI), 522 (VI),
521 (VI), 508 (VI), 503 (VI)
542 (VI), 541 (VI), 539 (VI), 533 (VI),
532 (VI), 528 (VI), 526 (VI), 520 (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)
YesNo

3.48.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Extend RTW options to control if build list is re-read prior to a build

    CR 531 (VI), affects Sim-API

    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

    CR 529 (VI), affects Sim-API

    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

    CR 527 (VI), affects Sim-API

    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:

    NameDescription
    mpls_model_build_timeThe date and time when the model was built.
    mpls_model_copyrightThe copyright notice for the model taken from the put_Identification block.
    mpls_model_descriptionThe model description taken from the put_Identification block.
    mpls_model_nameThe name of the built model.
    mpls_model_versionThe model version number taken from the put_Identification block.
    mpls_plat_build_timeThe date and time when the platform was created.
    mpls_plat_copyrightThe platform's copyright notice.
    mpls_plat_targetThe hardware target the model was built to be run on.
    mpls_plat_versionThe version of the platform the model was built against.
  • Extend RTW options to control ASAP2 generation

    CR 523 (VI), affects Sim-API

    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

    CR 503 (VI), affects Sim-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Extend RTW options to control whether model links are broken prior to a build

    CR 530 (VI), affects Sim-API

    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

    CR 522 (VI), affects Sim-API

    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

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.

  • Added example of 2-d map lookup data dictionary entry

    CR 521 (VI), affects Sim-API

    Previously, the manual only showed how to create DDEs for 1-d map lookups.

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.

  • Add details for G400 pins J1-27 and J1-48 to documentation

    CR 525 (VI), affects Sim-API

    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

    CR 524 (VI), affects Sim-API

    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

    CR 508 (VI), affects Sim-API

    Added monitor or feedback fault information for the VPS (pin A39) output on the G800 target.

3.48.2. Fixes and improvements

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

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.

  • Adhere to the RTW "generate code only" option

    CR 520 (VI), affects Sim-API

    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

    CR 499 (VI), affects Sim-API

    Previously, the reported maximum stack usage (ASAP2 entry mpl_max_used_stack) was under reported by a factor of 4.

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.

  • Allow data dictionary names that are all upper case

    CR 539 (VI), affects Sim-API

    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

    CR 528 (VI), affects Sim-API

  • Added note about automatic ASAP2 generated items for adaptive and tune blocks

    CR 526 (VI), affects Sim-API

  • Tidy up the automatic DDE ppp_tune_trigger_store

    CR 518 (VI), affects Sim-API

    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

    CR 516 (VI), affects Sim-API

    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

    CR 515 (VI), affects Sim-API

    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

    CR 514 (VI), affects Sim-API

  • Raise a warning if the mpl prefix is used in user DD files

    CR 512 (VI), affects Sim-API

    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

    CR 500 (VI), affects Sim-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Allow some Simulink blocks to work with OpenECU calibrations

    CR 542 (VI), affects Sim-API

    Previously, some of the Simulink blocks that used OpenECU calibrations would not result autogenerated code that would compile.

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.

  • Always turn coil outputs off when engine stops turning

    CR 541 (VI), affects Sim-API

    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

    CR 533 (VI), affects Sim-API

  • Improve the crank synchronisation detection

    CR 532 (VI), affects Sim-API

    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

    CR 479 (VI), affects Sim-API

    Previously, the platform would not schedule coil pulses when the engine accelerated slowly, leading to failed starts.

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.

  • Correct missing picture in the User Guide

    CR 519 (VI), affects Sim-API

  • Correct wrong path in the release notes and installer

    CR 517 (VI), affects Sim-API

    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

    CR 502 (VI), affects Sim-API

    Previously, a missing script prevented the FreeCCP tool from running correctly.

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.

  • Correct a subset of feedback/monitor signals on the G800 target

    CR 507 (VI), affects Sim-API

    Previously, the following monitor or feedback signals were incorrect:

    • MCS1 (pin A17)
    • MCS2 (pin A18)
    • GSS1 (pin A19)
    • GSS2 (pin A20)
    • ACR (pin B2)
    • STRTEN (pin B4)
    • LSF (pin B24)
    • FP (pin B27)

  • Correct constant current channel usage on the G800 target

    CR 506 (VI), affects Sim-API

    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

    CR 501 (VI), affects Sim-API

    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.49.  Release 1.5.1

Release labelled rel_install_1_5_1 from 16 August 2005. 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.46.  Release summary for v1.5.1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs466 (VI), 465 (VI)YesNo

3.49.1. Fixes and improvements

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

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Marginal CAN bit settings resulting in odd CAN behaviour

    CR 466 (VI), affects Sim-API

    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

    CR 465 (VI), affects Sim-API

    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.50.  Release 1.5.0

Release labelled rel_install_1_5_0 from 20 July 2005. 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.


3.50.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 a bitwise operator block

    CR 463 (VI), affects Sim-API

    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 a bitwise operator block

    CR 453 (VI), affects Sim-API

  • Added a bitwise operator block

    CR 438 (VI), affects Sim-API

  • Added preliminary MATLAB R14 support

    CR 432 (VI), affects Sim-API

    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)

    CR 429 (VI), affects Sim-API

    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:

    NameDescription
    AINanalogue input
    DINdigital input
    AOTanalogue output
    DOTdigital output
    Monitorfeedback 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

    CR 426 (VI), affects Sim-API

    Added the following blocks related to fault processing:

    • Added general "range check" block

    • 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

    CR 425 (VI), affects Sim-API

    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

    CR 420 (VI), affects Sim-API

    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

    CR 418 (VI), affects Sim-API

    From the command prompt, OpenECU now responds to the following commands:

    CommandDescription
    ver openecuDisplay version information about the installed OpenECU Simulink blockset.
    help openecuDisplay information about the available OpenECU commands.
    info openecuDisplay 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 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

    CR 418 (VI), affects Sim-API

    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

    CR 309 (VI), affects Sim-API

    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

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.

  • Generate ASAP2 files for all supported calibration tools

    CR 456 (VI), affects Sim-API

    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

    CR 420 (VI), affects Sim-API

    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

    CR 420 (VI), affects Sim-API

    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.

  • Extended ASAP2 generation to include map lookup details

    CR 420 (VI), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Added block to inhibit reprogramming based on an inport state

    CR 431 (VI), affects Sim-API

    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

    CR 424 (VI), affects Sim-API

    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

    CR 424 (VI), affects Sim-API

    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

    CR 354 (VI), affects Sim-API

    The Simulink blockset now supports the use of Vector CANdb files in the CAN receive and transmit 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.

  • Added average engine speed and acceleration to existing blocks

    CR 455 (VI), affects Sim-API

    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

    CR 452 (VI), affects Sim-API

    A set of blocks have been added to support knock detection (using the HIP 9011 device).

  • Added engine knock detection support

    CR 411 (VI), affects Sim-API

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.

  • Reimplement installer

    CR 423 (VI), affects Sim-API

    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.

3.50.2. Fixes and improvements

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

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.

  • Consistently handle boolean items in block correctly

    CR 428 (VI), affects Sim-API

    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

    CR 427 (VI), affects Sim-API

    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

    • pnv_Status

    • put_Calmap1d

    • put_Calmap2d

    • put_CalvalTune

    • put_Calmap1dTune

    • put_Calmap2dTune

    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

    CR 346 (VI), affects Sim-API

    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.

  • Updated the User Guides

    CR 316 (VI), affects Sim-API

  • Updated the User Guides

    CR 315 (VI), affects Sim-API

  • Updated the User Guides

    CR 227 (VI), affects Sim-API

  • Updated the User Guides

    CR 214 (VI), affects Sim-API

  • Updated the User Guides

    CR 6 (VI), affects Sim-API

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.

  • Correct hard coded number of Tunes

    CR 460 (VI), affects Sim-API

    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

    CR 444 (VI), affects Sim-API

    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

    CR 442 (VI), affects Sim-API

    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

    CR 421 (VI), affects Sim-API

    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

    CR 420 (VI), affects Sim-API

    Previously, reading a buildlist with a missing data dictionary file would lead to a fatal error.

  • Extended the error checking of the data dictionary handling

    CR 420 (VI), affects Sim-API

  • Improve the loading time for data dictionaries

    CR 420 (VI), affects Sim-API

    Previously, the load time for large data dictionaries could be lengthy.

  • Extended the error checking of the data dictionary handling

    CR 395 (VI), affects Sim-API

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • A problem has been reported with OpenECU's handling of inf

    CR 241 (VI), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and 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

    CR 424 (VI), affects Sim-API

    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

    CR 424 (VI), affects Sim-API

    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

    CR 424 (VI), affects Sim-API

    The following CAN blocks have changed to include a drop down for selecting a CAN bus:

    • pcx_CANConfiguration

    • pcp_Configuration

    • pcx_CANReceiveMessage

    • 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

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.

  • Extended the examples and provide loom details

    CR 419 (VI), affects Sim-API

    The set of examples has been extended from the step1 model to include the following:

    NameDescription
    two_pot_demoSimilar to step1 but shows how to combine more than one input to achieve a similar effect.
    multi-rateAn example of how to exchange information between parts of a model that run at different rates.
    fixed angularAn 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

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.

  • Angular platform ASAP2 entries generated if model has no angular functionality

    CR 462 (VI), affects Sim-API

    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.

  • Remove simulation error for the stepper motor block

    CR 458 (VI), affects Sim-API

    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

    CR 457 (VI), affects Sim-API

    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

    CR 28 (VI), affects Sim-API

    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.

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Correct adaptive storage problem

    CR 446 (VI), affects Sim-API

    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

    CR 412 (VI), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Corrected G400 I/O mapping

    CR 430 (VI), affects Sim-API

    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.

3.51.  Release 1.4.0

Release labelled rel_install_1_4_0 from 6 May 2005. 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.48.  Release summary for v1.4.0

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API402 (VI), 394 (VI), 393 (VI), 389 (VI),
376 (VI), 372 (VI), 372 (VI), 372 (VI),
371 (VI), 370 (VI), 357 (VI), 290 (VI)
417 (VI), 403 (VI), 401 (VI), 399 (VI),
397 (VI), 388 (VI), 385 (VI), 377 (VI),
374 (VI), 373 (VI), 348 (VI), 233 (VI),
82 (VI), 81 (VI), 19 (VI)
YesNo

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

  • Cache target and target I/O information to speed model load and update

    CR 402 (VI), affects Sim-API

    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

    CR 357 (VI), affects Sim-API

    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.

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.

  • Display summary of unresolved ASAP2 entries at end of build

    CR 389 (VI), affects Sim-API

    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

    CR 372 (VI), affects Sim-API

    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

    CR 372 (VI), affects Sim-API

    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

    CR 372 (VI), affects Sim-API

    Preliminary support added for the INCA-ProF tool.

  • Add ATI Vision support in the ASAP2 file generation

    CR 371 (VI), affects Sim-API

    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

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Print stack size allocated at the end of a build

    CR 376 (VI), affects Sim-API

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.

  • Add uni-polar stepper motor output block

    CR 393 (VI), affects Sim-API

    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

    CR 370 (VI), affects Sim-API

  • Added an injector update feature for improved transient control

    CR 290 (VI), affects Sim-API

    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.

Non-volatile storage

Storage of data across power cycles, including 1-d and 2-d adaptive map updates using reverse interpolation.

  • Add Flash storage for adaptives

    CR 394 (VI), affects Sim-API

    Adaptive constants, 1-d and 2-d maps can now be stored in battery backed RAM (as before) or to Flash storage.

3.51.2. Fixes and improvements

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

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.

  • Adaptive blocks don't simulate correctly when more than one of the same type exists in a model

    CR 417 (VI), affects Sim-API

    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

    CR 403 (VI), affects Sim-API

    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

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.

  • Allow build list filename to be independent of model filename

    CR 399 (VI), affects Sim-API

    Previously, a change forced the build list to have the same file name as the model filename - a restriction on previous functionality.

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Move <model_name>.a2l.err from build directory to model directory

    CR 388 (VI), affects Sim-API

  • Always generate an ASAP2 file

    CR 377 (VI), affects Sim-API

    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

    CR 374 (VI), affects Sim-API

  • Clean up the build output

    CR 373 (VI), affects Sim-API

    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.

    Now, the following files are produced from a clean build:

    FileDescription
    model_name.a2lASAP2 file
    model_name_strategy_cal_image.s37S-record of built model
    model_name_strategy_cal_image.hexIntel HEX record of built model

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.

  • Correct spelling in pan_EngineConfig block mask

    CR 401 (VI), affects Sim-API

  • Only allow even numbers of cylinders in pan_EngineConfig block

    CR 397 (VI), affects Sim-API

    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

    CR 385 (VI), affects Sim-API

    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

    CR 348 (VI), affects Sim-API

    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

    CR 233 (VI), affects Sim-API

    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

    CR 82 (VI), affects Sim-API

  • Lag in angular injector and coil events

    CR 81 (VI), affects Sim-API

    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

    CR 19 (VI), affects Sim-API

    Previously, the ECU would occasionally produce an initial fuel pulse after the main injection pulses had started.

3.52.  Release 1.3.1

Release labelled rel_install_1_3_1 from 7 January 2005. 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.49.  Release summary for v1.3.1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs367 (VI), 366 (VI), 365 (VI)YesNo

3.52.1. Fixes and improvements

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

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.

  • No Tune group present in ATI Vision INI file after install

    CR 365 (VI), affects Sim-API

    Previously, a clean install did not add a Tune region to the ATI Vision INI file (if present).

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Failure to build if no adaptive tables are present in a model

    CR 366 (VI), affects Sim-API

    Previously, if a model did not contain an adaptive table block, the build would fail.

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.

  • Missing file from installer

    CR 367 (VI), affects Sim-API

    Previously, an executable file was missing from the installer. This resulted in a failure to load an OpenECU model.

3.53.  Release 1.3.0

Release labelled rel_install_1_3_0 from 22 November 2004. 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.50.  Release summary for v1.3.0

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API363 (VI)363 (VI)YesNo

3.53.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 non-volatile adaptive Simulink blockset

    CR 363 (VI), affects Sim-API

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

3.53.2. Fixes and improvements

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

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.

  • Errors when using engine configuration block with blank fields

    CR 363 (VI), affects Sim-API

    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.54.  Release 1.2.0

Release labelled rel_install_1_2_0 from 18 November 2004. 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.51.  Release summary for v1.2.0

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API356 (VI), 355 (VI), 352 (VI)358 (VI), 353 (VI), 320 (VI), 227 (VI)YesNo

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

  • Extend Tune support to MATLAB R13.x

    CR 356 (VI), affects Sim-API

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Produce Intel HEX output files at the end of a build

    CR 355 (VI), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Allow the G800 CID2 channel to be used in a model configured to run an engine

    CR 352 (VI), affects Sim-API

    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.

3.54.2. Fixes and improvements

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

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.

  • Additional help files added (ongoing)

    CR 227 (VI), affects Sim-API

    Updated help file for block pcp_configuration to describe the sub-set compliance with CCP version 2.1 and additional restrictions.

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Move table lookup and interpolate source code into platform library

    CR 353 (VI), affects Sim-API

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.

  • Make all developer software blocks links in the example models

    CR 358 (VI), affects Sim-API

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.

  • Remove default details from the analogue input block

    CR 320 (VI), affects Sim-API

3.55.  Release 1.1.0

Release labelled rel_install_1_1_0 from 10 October 2004. 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.52.  Release summary for v1.1.0

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API350 (VI), 345 (VI), 342 (VI), 327 (VI),
306 (VI)
349 (VI), 344 (VI), 227 (VI), 223 (VI),
182 (VI)
YesYes, see:
350 (VI),
349 (VI)

3.55.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Extended DD tools to allow display precision to be specified

    CR 342 (VI), affects Sim-API

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

    CR 327 (VI), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Added CCP station identifier to CCP configuration block

    CR 350 (VI), affects Sim-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.1.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Allowed up to 15 receive messages per bus, or 28 overall

    CR 306 (VI), affects Sim-API

    Previously, this extension was applied to OpenGateway only.

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.

  • Incorporated the two-pot demo into the examples

    CR 345 (VI), affects Sim-API

3.55.2. Fixes and improvements

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

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.

  • Additional help files added (ongoing)

    CR 227 (VI), affects Sim-API

    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

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.

  • Failure to transmit CCP data when user changes a calibration

    CR 182 (VI), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Removed loss of CCP communications with partial downloads of application code

    CR 349 (VI), affects Sim-API

    Previously, a partial download of the strategy code could stop CCP communications.

    Now, a partial download results either:

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.1.0 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Removed warning messages about Rx and Tx CAN message blocks

    CR 344 (VI), affects Sim-API

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

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 ASAP platform variable name that signals gain or loss of crank sync

    CR 223 (VI), affects Sim-API

    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.56.  Release 1.0.9

Release labelled rel_install_1_0_9 from 29 July 2004. 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.53.  Release summary for v1.0.9

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
Gateway306 (VI), 280 (VI)308 (VI), 307 (VI), 304 (VI), 303 (VI),
301 (VI)
YesNo
Sim-API295 (VI), 291 (VI), 280 (VI)285 (VI), 284 (VI)YesNo

3.56.1. New features

New features introduced by this version, or significant changes to existing features.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Allow up to 15 receive messages per bus, or 29 overall

    CR 306 (VI), affects Gateway

  • Updates

    CR 280 (VI), affects Gateway

    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

    CR 280 (VI), affects Sim-API

  • 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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Added G600 target ECU hardware support

    CR 295 (VI), affects Sim-API

    Added G600 as target in identification block; added limited I/O support.

  • Added support for G400 pin J1-69 as an output

    CR 291 (VI), affects Sim-API

3.56.2. Fixes and improvements

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

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.

  • Correct wrong printed information of internal data (debug purposes only)

    CR 303 (VI), affects Gateway

  • Remove block mask defaults

    CR 284 (VI), affects Sim-API

    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

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Updates

    CR 308 (VI), affects Gateway

    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

    CR 307 (VI), affects Gateway

    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

    CR 304 (VI), affects Gateway

    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

    CR 301 (VI), affects Gateway

  • Updated platform to support new version of CANTranslator code

    CR 285 (VI), affects Sim-API

3.57.  Release 1.0.8

Release labelled rel_install_1_0_8 from 14 April 2004. 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.54.  Release summary for v1.0.8

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API270 (VI)264 (VI)YesNo

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

  • Add beta MATLAB R13 support

    CR 270 (VI), affects Sim-API

3.57.2. Fixes and improvements

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

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Correct path to non-inlined S-function for compilation

    CR 264 (VI), affects Sim-API

3.58.  Release 1.0.7

Release labelled rel_install_1_0_7 from 12 February 2004. 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.55.  Release summary for v1.0.7

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API261 (VI), 253 (VI)262 (VI), 260 (VI), 259 (VI), 258 (VI),
257 (VI), 256 (VI)
No, see:
256 (VI)
No

3.58.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Add a combined quadrature decode and frequency input block

    CR 261 (VI), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • Add SS2 to the G400 I/O channel mapping

    CR 253 (VI), affects Sim-API

3.58.2. Fixes and improvements

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

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Correct comment in auto-generated code for the frequency input block

    CR 259 (VI), affects Sim-API

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Correct CAN receive and transmit block behaviour when included in atomic sub-systems

    CR 260 (VI), affects Sim-API

    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.

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.

  • Make frequency input processing independent of the frequency signal

    CR 262 (VI), affects Sim-API

    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

    CR 258 (VI), affects Sim-API

    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

    CR 256 (VI), affects Sim-API

    Previously, some digital input channel settings would be reset when a model was loaded because the default selection was out of date.

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.

  • Add back in the GSS2 monitor to the G800 I/O mapping

    CR 257 (VI), affects Sim-API

    Previously, GSS2 monitor was accidentally removed from the I/O channel selection.

3.59.  Release 1.0.6

Release labelled rel_install_1_0_6 from 27 January 2004. 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.56.  Release summary for v1.0.6

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API252 (VI)No CRsYesNo

3.59.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Export of reason of reset as ASAP measurable

    CR 252 (VI), affects Sim-API

    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:

    ValueReason for reset
    57528power on reset
    61624watchdog reset

    The platform automatically generates an ASAP entry for this measurable.

3.60.  Release 1.0.5

Release labelled rel_install_1_0_5 from 26 January 2004. 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.57.  Release summary for v1.0.5

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API249 (VI), 246 (VI), 236 (VI), 231 (VI)251 (VI), 250 (VI)YesNo

3.60.1. New features

New features introduced by this version, or significant changes to existing features.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Allow inhibit of CCP reprogramming from application

    CR 246 (VI), affects Sim-API

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

    OperationCCP command identifier
    clear memory0x10
    select cal page0x11
    program0x18
    program 6 bytes0x22
    move0x19
    diagnostic service0x20
    action service0x21

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.

  • Add angular channels for block channel selection

    CR 249 (VI), affects Sim-API

  • Add angular channels for block channel selection

    CR 236 (VI), affects Sim-API

  • Add angular channels for block channel selection

    CR 231 (VI), affects Sim-API

    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;

3.60.2. Fixes and improvements

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

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.

  • Add stronger inter-block I/O channel checks

    CR 251 (VI), affects Sim-API

    Previously, only I/O channels on the same block type were tested to be unique.

  • Add stronger quadrature decode channel checks

    CR 250 (VI), affects Sim-API

    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.61.  Release 1.0.4

Release labelled rel_install_1_0_4 from 15 January 2004. 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.58.  Release summary for v1.0.4

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API243 (VI), 242 (VI), 240 (VI), 238 (VI),
236 (VI), 236 (VI), 128 (VI)
No CRsYesYes, see:
240 (VI),
128 (VI)

3.61.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Share application CCP settings with RPRG

    CR 240 (VI), affects Sim-API

    Note

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.0.4 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

  • Share application CCP settings with RPRG

    CR 128 (VI), affects Sim-API

    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

    To enable this functionality, the ECU's firmware must be upgraded to revision 1.0.4 or later. To upgrade the ECU's firmware please contact OpenECU technical support as described in Appendix A, Contact information.

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • G400 1000 kBps CAN support in application

    CR 238 (VI), affects Sim-API

    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.

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.

  • A simplified analogue input block has been created

    CR 243 (VI), affects Sim-API

    The simplified block provides a voltage reading without fault indication.

  • Access to frequency input TPU parameters through data dictionary entries

    CR 242 (VI), affects Sim-API

    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 nameTypeRangeDescription
    mplc_fi_config_xuint16_T7 or 11Set 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_xuint8_T1 to 255Number 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_scalarTiming rate (Hz)
    128187,500
    64375,000
    161,500,000
    212,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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • G400 CDA and CDB pins are now available as PWM outputs

    CR 236 (VI), affects Sim-API

    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

    CR 236 (VI), affects Sim-API

    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.62.  Release 1.0.3

Release labelled rel_install_1_0_3 from 20 November 2003. 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.59.  Release summary for v1.0.3

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs230 (VI), 227 (VI), 222 (VI)YesNo

3.62.1. Fixes and improvements

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

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.

  • Additional help files added (ongoing)

    CR 227 (VI), affects Sim-API

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.

  • Engine turning flag available from the pan_EngineConfig block

    CR 230 (VI), affects Sim-API

    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

    CR 222 (VI), affects Sim-API

3.63.  Release 1.0.2

Release labelled rel_install_1_0_2 from 14 November 2003. 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.60.  Release summary for v1.0.2

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API231 (VI), 226 (VI), 224 (VI), 223 (VI),
215 (VI)
232 (VI), 227 (VI), 222 (VI), 221 (VI),
220 (VI), 207 (VI)
YesNo

3.63.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Period measurement block added, enabling closed loop ignition dwell control

    CR 226 (VI), affects Sim-API

    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

    CR 224 (VI), affects Sim-API

    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

    CR 223 (VI), affects Sim-API

    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

    CR 215 (VI), affects Sim-API

    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

OpenECU software supports a number of ECUs. Each target ECU has differing capabilities across connectors, input/output conditioning circuitry, memory, processors and architectures.

  • G400 CPS and CID channels now available as frequency inputs

    CR 231 (VI), affects Sim-API

3.63.2. Fixes and improvements

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

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.

  • ATI crashes when importing an OpenECU ASAP2 file

    CR 232 (VI), affects Sim-API

    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

    CR 221 (VI), affects Sim-API

    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

    CR 207 (VI), affects Sim-API

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.

  • Updated quick start step1 Simulink example

    CR 220 (VI), affects Sim-API

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.

  • Additional help files added (ongoing)

    CR 227 (VI), affects Sim-API

    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

    CR 222 (VI), affects Sim-API

    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:

    Crank config36-160-2
    Engine speedAcceleration (RPM/s)Acceleration (RPM/s)
    406501100
    130700011600
    2202005033450
    3103985066400
    40066350110600

3.64.  Release 1.0.12

Release labelled rel_install_1_0_12 from 16 July 2004. 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.61.  Release summary for v1.0.12

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs328 (VI), 325 (VI), 310 (VI)YesNo

3.64.1. Fixes and improvements

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

Communications

External communication mechanisms and protocol support for both reprogramming and application mode, including CCP, SAE-J1939 and ISO-15765 over CAN.

  • Corrected issue regarding extended CAN identifiers

    CR 328 (VI), affects Sim-API

    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.

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.

  • Extend crankshaft configuration in the pan_EngineConfiguration block

    CR 325 (VI), affects Sim-API

    Previously, available crankshaft configurations with 36-1 and 60-2 crank trigger wheels.

    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

    CR 310 (VI), affects Sim-API

    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.65.  Release 1.0.11

Release labelled rel_install_1_0_11 from 16 July 2004. 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.62.  Release summary for v1.0.11

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs319 (VI)YesNo

3.65.1. Fixes and improvements

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

Code generation

Integration with code-generation tools, such as MathWorks Real-Time Workshop for Simulink, and the C-API tool for OpenECU.

  • Corrected platform path in template makefile

    CR 319 (VI), affects Sim-API

3.66.  Release 1.0.10

Release labelled rel_install_1_0_10 from 12 July 2004. 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.63.  Release summary for v1.0.10

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-API298 (VI)No CRsYesNo

3.66.1. New features

New features introduced by this version, or significant changes to existing features.

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.

  • Added a variable frequency PWM output block

    CR 298 (VI), affects Sim-API

    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.67.  Release 1.0.1

Release labelled rel_install_1_0_1 from 18 August 2003. 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.64.  Release summary for v1.0.1

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRs206 (VI), 202 (VI)YesNo

3.67.1. Fixes and improvements

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

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.

  • Correct prescaler correction for MIOS PWM outputs

    CR 206 (VI), affects Sim-API

    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.

  • Rename MAP and MAF angular inputs

    CR 202 (VI), affects Sim-API

    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.68.  Release 1.0.0

Release labelled rel_man_1_03 from (not yet assigned). 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.65.  Release summary for v1.0.0

PackageNew featuresFixes and improvementsBackwards
compatible
Firmware
upgrade
C-APINo CRsNo CRsYesNo
GatewayNo CRsNo CRsYesNo
Sim-APINo CRsNo CRsYesNo

Appendix A. Contact information

If you have questions, or are experiencing issues with OpenECU please see the FAQ website:

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