FAQ

Welcome to the OpenECU general information FAQ. If you would like to visit the OpenECU technical support FAQ, please visit: support.openecu.com

Hardware
      • What are the ‘options’ for the digital inputs on M2xx and M4xx?
      • How are the RTD inputs intended to be used on the M2xx and M4xx series OpenECU?
      •  How do I integrate OpenECU intop my vehicle wiring loom?
      • None of the ECUs you sell fit my I/O requirements?
      • Can OpenECU drive a stepper motor?
      •  Can Hall effect sensors be used with OpenECU as well as VRS?
      • Is OpenECU protected against reverse voltages, etc.?
Software
      • What third party products do I need for OpenECU 16bit development?
      • What is the OpenECU 32bit Developer Platform third party tool compatibility?
      • But OpenECU is an auto-coding platform – is this not detrimental to system performance?
      • Are pull-up/-down resistors on inputs and outputs software-configurable?
      • How much memory is available for my control application?
      • Does the OpenECU blockset allow me to handle communication over the CAN bus?
      • What is the operating system (OS)? Is it OSEK compliant?
      • Why does the technical specification show 512KB code space? My MPC5534 technical specification states 1MB flash?
Application
      • Is it possible to integrate any of my existing ‘C’ code algorithms with OpenECU auto-generated code?
      •  I renamed my Simulink model and now the Data Dictionary won’t load?
      • For engine control applications, what is the maximum engine speed limit?
      •  Options for Targetlink integration with OpenECU
      • How do I calibrate an OpenECU strategy?
Does the M250 have spark dwell control?

The M250 ECU design does not provide specific functionality to measure the rise time of a spark signal, as its spark output is intended for applications such as igniting a burner in an aftertreatment application, where precise dwell time control is not required.

What are the ‘options’ for the digital inputs on M2xx and M4xx?

The inputs are build-configurable to support 3 modes of operation:

VOLTAGE THRESHOLD MODE (also referred to as “normal mode” or “high/low speed digital input”)
This is a normal digital input which registers high when the voltage is above some (build configurable) threshold and low when the voltage is below the threshold. There is a build option to include either a pull up or a pull down resistor.We have used the terms high speed digital and low speed digital in our ECUs to distinguish inputs which are capable of using a TPU for pulse width and frequency capture (high speed) and inputs which are only capable of simple on/off operation (low speed).

VRS MODE
This interfaces to a VRS sensor, the input will register high when the voltage goes above 50% of the peak signal amplitude and low when the voltage passes through the zero crossing point.

HALL MODE
This interfaces to a bidirectional hall effect sensor such as the Infineon TLE4953 which communicates by varying the current which it draws. NB: Regular uni-directional hall effect sensors normally make use of the standard voltage threshold mode with a pullup resistor, this mode is only for the special bidirectional sensors.

N.B. 
When in VOLTAGE THRESHOLD MODE the inputs are protected against the application of any voltage between 0V and battery.When configured for VRS MODE, the inputs are additionally proof against the application of a 200V peak AC waveform.The inputs can be build-configured for a single pole filter with a cut-off in the range 5Hz to 50KHz, the standard product has a filter of 10KHz.

Why does the technical specification show 512KB code space? My MPC5534 technical specification states 1MB flash?

The platform software splits the 1MB MPC5534 flash space into parts, of which 512MB is assigned to the application code, 256KB is assigned to calibration data, and the remaining 256KB to other uses (such as firmware, non-volatile data spaces (like diagnostic trouble codes, adaptives, etc.).

How are the RTD inputs intended to be used on the M2xx and M4xx series OpenECU?

The RTD inputs have a high pull up resistance and gain to avoid self heating of the sensors. They are intended to be used with, but not limited to, PT200 sensors, which is a platinum resistance thermometer with a resistance at 0°C of 200 ohms. Other RTD type sensors may work depending on their resistance.

If you have specific requirements regarding other temperature sensing devices, e.g. thermistors, please click Contact Us tab at top of page.

What is the OpenECU 32bit Developer Platform third party tool compatibility?

Please see the Third Party Tool Compatibility page.

What is the operating system (OS)? Is it OSEK compliant?

OpenECU uses a proprietary pre-emptive multi-tasking real-time OS to minimise processor and memory demands, whilst maximising efficiency and execution speed.

The OpenECU OS has been designed to be OSEK BCC1 like, however, it is not OSEK compliant.

How do I calibrate an OpenECU strategy?

OpenECU supports calibration over CAN using the industry-standard CCP protocol (CAN Calibration Protocol), also known as ASAP1a.

The build process outputs calibration and variable parameter information in ASAP2 format.
The calibration tool therefore needs to support both CCP and ASAP2 standards to calibrate OpenECU.

The list of supported calibration tools is detailed here.

Is it possible to integrate any of my existing ‘C’ code algorithms with OpenECU auto-generated code?

Yes. You can integrate legacy C code as Simulink S-functions. An example of this can be provided on request.

None of the ECUs you sell fit my I/O requirements?

OpenECU makes it possible to provide all the I/O requirements necessary for prototyping. This can be achieved by utilising more than one OpenECU, communicating where necessary over CAN.

As a prototyping solution, OpenECU allows the customer to then produce a production solution that satisfies all your I/O requirements in one box.

Does the OpenECU blockset allow me to handle communication over the CAN bus?

Yes. The OpenECU platform provides fucntionality for CAN communication: configuration, transmit and receive,  error status (e.g. bus off), etc.

As well as access to CAN in both APIs, Vector CANdbc files can be used at the Simulink level.
How much memory is available for my control application?

The amount of memory available for your application is dependent on the OpenECU hardware being used. Please see the hardware comparison section of our website, here.

Can OpenECU drive a stepper motor?

We don’t currently support stepper output on OpenECU M-series units, but it is possible to add stepper motor control if required. Contact us for details.
Are pull-up/-down resistors on inputs and outputs software-configurable?

On the OpenECU M-series modules, it is possible to specify a build option that allows a variety of input/output configuration. This a is a chargeable service. Please contact us for further details.

But OpenECU is an auto-coding platform – is this not detrimental to system performance?

Of course there is some overhead associated with automatically generated code compared with hand-cut code.

In Pi Innovo’s experience, a very approximate rule of thumb is that RTW autocoded control algorithms run about 10% slower and code size could be (but not necessarily will be) up to 40% larger.

However, since any control loop designed on a rapid prototype system must be scalable to a production ECU, the quantity of strategy executable on OpenECU is actually a very sensible constraint to place on control system designers.

Can Hall effect sensors be used with OpenECU as well as VRS?

On OpenECU M250, both Hall/VRs sensors can be used the Hall/VRs inputs are build configurable

For engine control applications, what is the maximum engine speed limit?

This is dependent on application size and how much code will be run every firing TDC (720º (crank degrees) on a 4-stroke engine), but 10,000 rpm is achievable on M250 modules for gasoline and diesel strategies respectively.

Is OpenECU protected against reverse voltages, etc.?

All OpenECU modules are protected against reverse supply connection and all inputs and outputs are protected against short-to-VPWR or short-to-VGND over normal operating range.

Note however for modules with a voltage reference pin, it should not be shorted-to-VPWR or shorted-to-VGND since this will do permanent damage to the module.

For full details please see the technical specifications for each ECU.

How do I integrate OpenECU intop my vehicle wiring loom?

Pi Innovo provide a range of “vehicle-side” loom connection solutions. Available loom accessories are detailed in our OpenECU Product Cross Reference. However, you can also source the part yourself.

I renamed my Simulink model and now the Data Dictionary won’t load.

The name of the build list file needs to have the same name as the Simulink model e.g. M250_step1_example.mdl will have a corresponding build list file of M250_step1_example_bl.m

What third party products do I need for OpenECU 16bit development?

As the OpenECU 16bit development platform is C-API only, you only need the following third party products;

·       FreeScale CodeWarrior 5.0

You need a tool to download your application and calibrate your application while it runs on the ECU. Applications can be downloaded and calibrated via CCP. You can use:

·       ATI Vision (v2.5)

Options for Targetlink integration with OpenECU

The Pi Innovo OpenECU platform software currently provides Simulink/RTW and C interfaces.

Simulink blockset

The Simulink interface allows applications to be configured and built to a downloadable target hex file without leaving MATLAB. The custom Simulink blockset provides both configuration blocks (e.g. CAN baud rate set-up) and I/O blocks (e.g. to read an analogue input, drive a PWM output or transmit a CAN message).

Pressing Ctrl-B invokes the RTW build which generates C code from the model and invokes the Diab compiler and linker, together with some custom scripts, to produce a downloadable target image file and ASAP2 description file. The ECU can then be flashed with the new program using the calibration tool.

The OpenECU build does not require the Embedded Coder product. However, support for Embedded Coder has recently been added.

C-API

For non-MATLAB users, a C language interface to OpenECU is also provided.

Configuration options are specified in a project description file (.capi file) which is used by a custom tool (CAPI tool) to generate various code files required by the platform, e.g. to define operating system tasks and J1939 options, as well as an ASAP2 description file.

A batch file is used to invoke the CAPI tool and Diab compiler and linker.

Access to communications and I/O functions, together with supporting utilities, is generally provided by function-call interfaces.

TargetLink

Like RTW, TargetLink allows application designers to build models in Simulink and then auto-generate C code to build and execute on a target ECU. TargetLink is marketed as being intended more for production use, with more control offered over the generated code. However, it also requires that the model is converted from native Simulink format, which requires some extra work and tool licences for all engineers involved on the project.

OpenECU currently has no explicit support for dSPACE TargetLink. However, the application designer may wish to use TargetLink to generate code which employs the C-API. This has been done on several projects at Pi Innovo using the related 16-bit OpenECU platform. The following approaches have both been used on that platform;

      • using “custom code” blocks in TargetLink to invoke API C function calls directly in the auto-generated C code.
      • writing some interface code by hand to access platform I/O functions, which then exports global variables; the TargetLink model can then read or write those global variables to achieve the required hardware-related operations;

Using TargetLink may provide more control over target code generation than RTW. However, the model-build-execute cycle would involve more effort and time.