M110 Technical Specification
29T-068883TK-01

This technical specification relates to the following ECU variant:

This shows a high-level pictoral description of this ECU's capability.

Figure 1.1. Block diagram of M110 functionality

Various input and output functionality is supported where some pins may be capable of more than one function. Some functions require a combination of pins but not all pin combinations are possible.

Connector packs can be ordered from Pi. Individual connector components can be ordered from Pi or from various manufacturers.

Connector packs can be ordered from Pi. Individual connector components can be ordered from Pi or from various manufacturers.

The power supply pins (V_PWR A11+B20) and the ground pins (V_GND A1+B9+B10) are both rated to 20A.

The ECU V_GND (pins A1+B9+B10) and sensor ground (pins A14+B15) are directly connected together via a ground plane in the ECU PCB.

The ECU is designed for 12V or 24V vehicles, with various modes of operation based on the voltage (see Table 1.1, “Specification”). The ECU is protected against reverse supply connection. All inputs and outputs are protected against short-to-V_PWR or short-to-V_GND over normal operating range.

The ECU power arrangement is shown in Figure 4.1, “Switching arrangement for main power supply, wake-on-CAN enabled”.

Figure 4.1. Switching arrangement for main power supply, wake-on-CAN enabled

The default build option supports an ignition switch. The ECU powers up when the power supply pins (V_PWR A11+B20) and key position (ignition sense) input (pin A12) are asserted. The key position voltage threshold, above which the power supply turns on, is nominally 4.0V (worst case, a minimum of 3.4V and a maximum of 4.8V). The key position (pin A12) can be read as a digital input. The application must debounce the digital input over 200 milliseconds to achieve an accurate reading.

The default build option supports wake-on-CAN. The ECU powers up when the power supply pins are asserted and the ECU receives a message on a wake-on-CAN-enabled CAN bus (see Section 4.3, “ECU power — wake-on-CAN” for more). To fully disable wake-on-CAN, ECUs can be modified with a build option.

The ECU application software can hold power to the ECU after the conditions to power up the ECU no longer exist (e.g., the ignition sense is deasserted or CAN messages are no longer present). This allows, for example, the application to complete non-volatile memory processing. For the ECU to hold power the internal DOT enable-PSU-hold channel needs to be asserted. Setting this internal channel high will hold power when the key position input is opened, setting it low will allow the ECU to power off when the key position input is opened.

One CAN bus (pins A9 and A10) provides wake-on-CAN functionality. When the ECU power is controlled using CAN messages, the ECU powers up (or wakes) when the ECU senses two bus dominant states of at most 5 microseconds, with the first dominant state followed by a recessive state of at most 5 microseconds (provided the complete dominant-recessive-dominant pattern is completed within at most 2 milliseconds). Generally this pattern is fulfilled by sending a valid CAN message.

When ECU is powered via wake-on-CAN, it is the responsibility of the application to determine how long the ECU should remain on. In order to guarantee that the application is able to run after a wake-on-CAN event, it is recommended that the application initialize the DOT enable-PSU-hold channel to high to keep the ECU powered.

When the application has completed its desired tasks, the internal digital output DOT enable-PSU-hold should be set to low to allow the ECU to shut down. Once both the power-hold output and ignition input are deasserted, the platform will disable the CAN transceivers to cause the ECU to shut down.

The analog inputs (pins A5, A7, A8, A15, A17, A18, B1, B4, B11 and B12) sample voltage with varying resolution and range. See the pin information for more details. Some of the analog inputs have additional characteristics or may not be populated by default, as detailed in the following sections.

The ECU sensor supply arrangement is shown in Figure 4.2, “VREF arrangement”. The figure shows the relationship between the internal 5V reference supply and ground, the external sensor supply and ground, and the analog inputs.

Figure 4.2. V_REF arrangement

The internal precision 5V reference supplies the reference pin on the ADC. The exact sensor voltage being produced can be monitored on a (scaled) ADC channel. The scaling is detailed in Table 3.1, “Internal signals” and can be used to detect a short to battery or ground. The sensor ground is a nominal 0V.

The exact voltage on analog input pins can be read on a direct (unscaled) or an indirect (scaled) ADC channel. Standard 0-5V inputs are passed directly to the ADC with no scaling.

Some analog input pins are internally pulled up to the sensor power supply (pin A6+B5). If the sensor supply is not enabled, floating inputs will fluctuate when read by the ADC. The sensor supply must be enabled for resistance measurements made on any of these channels.

The analog inputs (B1, B4 and B12) have associated diode reference input channels that are used to monitor the voltage drop across the pull-up diodes at the pull-up resistor. These monitors can be used for more accurate measurements on their associated channels. Figure 4.3, “VREF diode monitor arrangement” shows the relationship between the 5V supply, the analog input and the diode reference.

Figure 4.3. V_REF diode monitor arrangement

The ECU has an internal thermistor temperature sensor. The conversion from input voltage, V_ADC, to temperature, T_SENSOR, is non-linear. Table 4.1, “Internal temperature conversion” provides nominal, median values; the minimum and maximum are within ±10% from -40°C and up, and ±5% above 95°C.

The analog outputs (pins B17 and B18) drive a constant voltage into an external load. See the Sim-API pax_AnalogOutput block and C-API pax_dac_output() function.

The valid range of the output is between 0.5V and 4.5V. The application can detect short-to-ground and short-to-battery faults by checking if the corresponding voltage monitor indicates it is out of the valid range.

The digital inputs (pins A5, A7, A8, A15, A17, A18, B1, B4, B11 and B12) sample a digital state, allowing the measurement of switches or pulsing inputs. See the pin information for more details. Some of the digital inputs have additional characteristics or may not be populated by default, as detailed in the following sections.

These digital inputs are not popuated by default. To support a variety of sensors, the ECU is pre-populated with a default selection of inputs with varying voltage thresholds and pull strengths. The inputs are not inverted.

See Chapter 2, Connector pinout for more information. In some cases the default selection will not meet the requirements of all customers. To help, Pi can modify the ECU PCB component population to adjust these characteristics as build options. Contact Pi for further information.

The ECU measures a signal frequency and duty cycle by capturing the time of the signal's filtered digital edges arriving at the processor. The time between similar edges gives the cycle period of the signal, and the inverse of the cycle period gives the frequency of the signal. The time between opposing edges gives the on and off periods, and the ratio of either the on or off period to the cycle period gives the corresponding on or off duty cycle.

Figure 4.4. Frequency measurement

The filtered digital edges for each input pin are captured relative to a digital timer. The digital timer has two properties that affect the measurable range of frequency.

Pins A5, A15 and B11 provide support for SENT sensors. To use the SENT channels, see the C-API or Sim-API User Guide for further details.

The digital outputs (pins A2, A3, A4, A13, B2, B3, B6, B7, B8, B13, B14 and B16) are a collection of low-side drivers, and are described in further detail in the following section.

With the low-side outputs (pins A2, A3, A4, A13, B2, B3, B6, B7, B8, B13, B14 and B16) the ECU switches the output pin to ground, the actuator is connected to the output pin and to V_PWR.

Figure 4.5. Switching arrangement for low-side digital outputs

The low-side output pins are protected against over-voltage up to 40V. These outputs can drive resistive loads at a maximum rate of 10 kHz.

The low-side digital outputs contain a mixture of monitoring circuitry that provides unconditioned diagnostic information that can be used for electrical diagnostics, such as state, voltage, and status monitors. These monitors are available to the application as individual analog or digital inputs.

These monitors can be used by the application to determine electrical faults. For instance, if a digital output is turned on but the corresponding state monitor reads off, then there is likely a short or open in the circuit.

Some of the internal and external inputs and outputs are classed as serial. The connector pinout tables and internal channel tables above specify whether a pin or channel is serial or not.

When a serial input is read, the measurement reflects the value of the input taken last time the application task ended. I.e., the value of the input is delayed by one cycle of the task period. When a serial output is set, the driven state is updated at the end of the current application task. I.e., there is a delay between requesting a change in the output state, and the output state honoring that request.

The CAN buses (pins A8+A7, A10+A9, A18+A17 and A20+A19) are implemented using high-speed CAN transceivers, compatible with J1939. The default CAN bus (pins A10+A9) has a terminating resistor fitted; the other CAN buses require external termination, by defualt.

One CAN bus (pins A9 and A10) has wake-on-CAN functionality (see Section 4.3, “ECU power — wake-on-CAN” for more details).

The M110 is designed to support LIN communications. However, this option is not yet supported. Contact Pi for further information.

The ECU supports different memory configurations for application, calibration and RAM sizes (see Section 4.20, “Memory — calibration capabilities”).

The ECU supports non-volatile memory storage in Flash. Battery backed RAM is not supported.

The processor's Flash memory is split into small and large memory blocks. The application and calibration are stored in large blocks, whilst DTC information, freeze frames and so on are stored in small blocks.

The largest Flash block can take up to approximately 7.5 seconds to erase. This occurs in an environment where the Flash has been erased and programmed many times at its temperature extreme. The typical erase time is smaller, especially at ambient temperatures. Reprogramming an ECU (where many large blocks would be erased), or storing DTC information across power cycles, can therefore take some time. Users and applications should take this into consideration.

The minimum number of erase cycles is approximately 1,000 for large Flash blocks and 100,000 for small Flash blocks. This occurs in an environment where the Flash has been erased and programmed many times at its temperature extreme. The typical number of erase cycles is larger, especially at ambient temperatures.

The minimum data retention is approximately 5 years for blocks which have been erased less than 100,000 times, and approximately 20 years for blocks which have been erased less than 1,000 times.

The information about the Flash has been taken from Freescale's MPC5534 Microcontroller Data Sheet document, revision 4 (dated Mar 2008).

The ECU supports both offline calibration (where all of the ECU's calibration memory is reprogrammed whilst the application is stopped) and online calibration (where individual calibrations can be modified whilst the application runs). These calibration capabilities are supported through the meomory configurations listed above:

The ECU can run in one of two system modes: reprogramming mode and application mode. In reprogramming mode, the ECU can be reprogrammed with application software from a calibration tool. In application mode, the ECU runs the programmed application software. The ECU selects which mode to enter when it is powered up by measuring the external FEPS A16 pin.

The ECU has a dedicated external pin (pin B19) for flashing a lamp. The LED should be connected between V_PWR (pin A11+B20) and pin B19.

The flash sequence represents a set of codes. Each code is a three digit number, where each digit is flashed a number of times equal to its value. An example would be the flash sequence for code 113. The flash sequence is broken down into a series of marks, or on and off pulses as follows:

Figure 4.6. Flash code sequence

Each of the marks lasts for a specific duration:

After the end code mark, the ECU will either flash the next code, or return to the start of the list and flash the first code. The ECU always has at least one code to flash.

Each code represents information about the ECU state. If there is no flash sequence, or a malformed flash sequence, then the ECU is malfunctioning. Otherwise, the flash sequence will represent one of the following codes:

The ECU closely adheres to the IEEE-754 for floating point numbers.

When using Simulink, floating point Simulink models are supported — all calculations are performed using single-precision (even if the model uses double-precision, the ECU performs calculations using single-precision).

When using the C-API, floating point applications are supported — all calculations are performed using single or double precision, as determined by the application code (although double precision will incur some software overhead — see the compiler reference manual for further details).

The rounding mode is set to round-to-nearest. In some conditions, the ECU will not adhere to the IEEE-754 standard:

The ECU does not generate ±Inf, NaN or a denormalised number as the result of a calculation.

To support a variety of sensors and actuators, the ECU is pre-populated with a default selection of components with varying voltage range, pull strengths, filtering and other characteristics. In some cases the default component selection will not meet the requirements of all customers. Within design constraints, Pi can modify the ECU components to adjust these characteristics as build options. Contact Pi for further information.