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