SECM112

Module

<br\>

Overview

The SECM112 is part of the engine management system for on-highway applications, which can include L6 4-stroke CNG intercity transit applications, L6, 4-stroke LNG intercity transit applications, and L4 4-stroke commercial vehicle applications. The module is capable of full authority digital engine control (FADEC) consisting of fuel, spark, and air delivery to the engine. Additional inputs and outputs are available to control other system functions, as defined by software. This unit provides 112 connector pins with inputs, outputs, and communications interfaces that support a wide variety of applications.

The SECM112 features two microprocessors in one rugged production intent housing. The module contains a main MPC5644 120Mhz processor along with a S12G fixed point processor, which can provide question-answer type challenge to the main processor. Both micros are connected on CAN1.

The SECM112 is part of the MotoHawk Control Solutions ControlCore® family of embedded control systems. The ControlCore operating system, MotoHawk® code generation product, and MotoHawk’s suite of development tools enable rapid development of complex control systems. Application code for both processors is developed in MotoHawk which allows the application developer to create applications directly in Simulink and build with a one step 'CNTL-B' build. The two controllers act like separate controllers in terms of programming. Then, the program can be flashed onto the micro using Woodward's MotoTune, Toolkit, or through industry standard 3rd party tools via xCP, or ISO15765.

Calibration can be done with Woodward's MotoTune or Toolkit or with industry standard 3rd Party tools through xCP.

Each controller is available in ‘F’ (Flash) or ‘C’ (Calibratible) versions. Flash modules are typically used for production purposes. Calibratible modules are typically for prototyping/development only; they can be calibrated in real time using MotoTune, ToolKit, or industry standard 3rd party tools via xCP.

<br\>

Power Requirements

All versions of the SECM112 Control require a voltage source of 8 to 32Vdc (12Vdc or 24Vdc nominal).

<br\>

MotoHawk Requirements

MotoHawk 2012bSP0 or higher is required for SECM112.

This means Matlab 2010b or higher is required, as MotoHawk supports Matlab 2 years backward.

<br\>

Compilers

Main Micro: Green Hills 4.2.4 or GCC PowerPC eabi SPE 4.6

Auxillary: Freescale CodeWarrior 4.6

<br\>

Targets

The SECM-112 has different Targets for the MAIN Prod and Dev modules as shown below. The S12G auxillary processor also has it's own target.

Main Processor

1751-6601: Target ECM-5644A-112-048-1204 DEV

1751-6605: Target ECM-56542A-112-049-1200 PROD

Auxillary Processor: Target ECM-S12G-112-059-1200 PROD Only

Control Features

Standard features common to both models are:

• 2 engine speed inputs: camshaft and crankshaft speed (software configurable for variable reluctance (VR) magnetic pickup sensor or Hall effect proximity sensor inputs)
• Up to 6 frequency inputs (some share analog resources)
• Up to 33 analog inputs
• 3 switch inputs
• 2 HEGO sensor inputs
• 2 LSU sensor inputs (also known as UEGO sensors)
• 2 knock sensor inputs
• 3 transducer power outputs providing +5V (350mA & 100mA) and +12V (100mA)
• 2 H-bridge driver outputs providing 10A and 5A drive capability and current sense feedback
• 6 Injector drivers providing software configurable peak and hold current levels (up to 7A/2A)
• 6 ignition coil drivers
• MPRD (Master Power Relay Driver) low side output
• TACH low side output
• 16 low side output drivers (1 with current sense feedback)
• 3 CAN (Controller Area Network) communications ports
• 4K-byte serial EEPROM for tunable parameter storage
• Auxiliary micro with 128k of flash, 8k of RAM, 4k of EEPROM

<br\>

Inputs

Analog Inputs (AN1 – AN34)

There are 34 analog inputs on the SECM112. The analog inputs have either a pull-up resistor as shown in Figure 2-12, or a pull-down resistor as shown in Figure 2-13. Five analog inputs have a software pull-up or pull-down selection via calibration. AN21 & AN30 share a common control line for the 1k or 11k selection, designed for EGT sensor diagnostics. All the analog inputs have a single-pole filter with a 1 ms time constant, except for Analog Input 5, which is reserved for a MAP (Manifold Absolute Pressure) sensor and has a 0.24 ms time constant.

The Analog Inputs are 12-Bit ADC

Fast Analog Channels

ANx_FAST channels are sampled faster than the equivalent ANx. This is needed on SECM112 because of how ADC bandwidth is consumed. SECM112 utilizes most of the available ADC bandwidth to service the reaction channel’s load current sampling. This means that the continuous scan queue sampling that is used by the other channels will take much longer than it normally takes on other modules. SECM112 FAST channel will be sampled every 90us where as normal channels will sample within 1ms (860us) worst case. The 1ms conversion time is problematic for threads of execution that execute at 1ms since the data is sometime old and sometimes new.

There is no need for such channels on the other ECUs because the ADC bandwidth is not being consumed like it is on the SECM112 and so all the channels are effectively sampled FAST.

Crank and CAM Inputs

The Cam and Crank (CNK) inputs are used to detect engine speed and angular position relative to TDC. The ECM-OH has CAM and Crank sensor inputs that can be connected to either a variable reluctance magnetic pick-up sensor (VR-MPU), or to a Hall-effect proximity switch. Each type of input has dedicated connector pins. See the ECM-OH datasheet for additional detail.

Digital Inputs

The SECM112 has 8 Discrete Inputs. Some may be used as switch inputs, others support frequency measurement.

Lambda Sensor Unit (UEGO) Inputs

The SECM112 control has two LSUs (Lambda Sensor Units), also known as UEGO (Universal Exhaust Gas Oxygen) inputs, which interface with Bosch LSU4.9 wide range oxygen sensors (Lambda sensors). The lambda-sensor(s) works in conjunction with the on-board Bosch CJ125 ASIC(s) to provide continuous regulation of  for a sensor in the range of  = 0.65... (air). The LSU inputs allow the ECM-OH to continuously regulate the engine air-to-fuel ratio, thus controlling the percentage of exhaust pollutants during the combustion process.

Knock Sensor Inputs

The SECM112 supports two Knock Sensor inputs.

Knock is implemented on the SECM112 in MotoHawk by the Knock by Decimation blockset. This is a specialized blockset and is included with Standard MotoHawk in 2014a and higher.

Outputs

Low-side Outputs (LSO)

The SECM112 control has 16 low-side outputs (LSOx & SPK8) that can be used as Boolean outputs for driving relays, or some as PWM outputs. LSO1 and LSO2 are also designed to drive the heater coil on a LSU sensor. Some low-side outputs are provided with freewheeling diodes (internal to the ECM-OH through DRVP or BATT) to suppress the back EMF caused by inductive loads. See the ECM-OH datasheet for low-side output capabilities and characteristics. The LSOs are clamped and can be used to drive relays.

Injector Outputs

The SECM112 control has 6 injector outputs, each capable of driving either low or high impedance injectors. Each injector output can be used as a Boolean output, a PWM output, or as a synchronous or periodic peak and hold injector output.

Reaction Module Blockset

The peak-hold current level is software configurable through the MotoHawk Reaction Channel Blockset.

Peak current cannot be run simultaneously on more than 3 injectors on the ECM-OH.

Spark Outputs

The SECM112 has 6 IGBT ignition coil drivers each capable of delivering up to 10A of peak dwell current.

A special blockset has been created for control and diagnostics of the MC33810 chip which is the driver for the IGBT coil drivers on the SECM112. See here for more detail on the blocks related to the MC33810.

H-bridge Outputs

The SECM112 control has two H-bridge outputs that can be used to drive electric motors, e.g., butterfly throttle valves. The H-Bridge outputs are provided with freewheeling diodes (internal to the ECM-OH through DRVP) to suppress the back EMF caused by inductive loads.

<br\>

Output Fault Detection

Output Fault Detection for the SECM112 is through the IO Fault Status block and the IO Fault Status Get block. This block will report a "0" if the driver is not reporting a fault, a "1" if the driver is detecting a fault, or in some cases a "2" for indeterminate. The faults that can be detected depend on the capability of the driver. Outputs driven by the MC33810 driver have additional fault reporting capability that can be exposed through the MC33810 Fault Detail Block. This block reports the last fault reported by the MC33810 driver and so the report from this block does not clear when the fault state is removed. The IO Fault Status block should be used to detect whether a fault condition is detected, and then the detail block can be used to detect which fault was reported. The fault detection capabilities of the SECM112 outputs are described below:

H-Bridges

For the h-bridges, shorted load faults can be reported. Shorted load reporting for each H-bridge is through overcurrent detection. See the SECM Hardware Manual for minimum overcurrent threshold values. Current Monitoring should be used in the application model for further diagnosis, such as for open load detection.

Injectors

SECM112’s injector drivers utilize the microprocessor’s Reaction Module for diagnosis. Reaction module diagnosis is based upon observing current and therefore INJ faults can only be detected when the INJ pins are asserted. Observed faults are cached until reported, where they are then cleared. Detection while not asserted is not possible. Therefore the fault status of an INJ output should only be queried once after an actuation event. Querying too often may result in no fault being reported even if the queried INJ output is currently in fault (e.g. open circuit). The PHWOT Reaction Channel MotoHawk help provides further detail.

Currently only the IO Fault Status block allows the fault status of an INJ output to be queried.

Spark

The Spark outputs are driven by the IGBT drivers of the MC33810 driver.

The spark output diagnostics assume the SPK outputs are driving an ignition coil as a load.

Comprehensive fault diagnosis when used with ignition coils is described in the MC33810 Datasheet. The diagnostic approach is based upon analysis of multiplexed feedback signals that go to the MC33810 which require that the actuators don’t de-assert (i.e. spark) at the same time. Overlap is possible with PWM and discrete, therefore, diagnosis is less capable or impossible when the SPK outputs are driven by PWM or Discrete output blocks.

Note that SPK8 is different from the other SPK outputs in that it is a MOSFET. SPK8 has short while asserted and open while not asserted detection and can be used with the MC33810 Fault Detail block. It is a GPGD type output and thus can use the MC33810 blocks related to GPGD configuration.

A special blockset has been created for control and diagnostics of the MC33810 chip which is the driver for the IGBT coil drivers on the SECM112. See here for more detail on the blocks related to the MC33810.

LSOs

There are three types of drivers for the LSOs on the SECM112. Each has slightly different fault reporting capability which is described below.

• LSO1-6: reports open circuit or short to ground while de-asserted and short when asserted. LSO6 has current sense as well.

• LSO 7,8,9,11, 12, 13, 14, TACH: These LSOs are driven by MC33810. Faults of Open while Asserted, Open while De-asserted, and Short to Battery can be reported. The IO Fault Status block reports the fault state, however there is also an MC33810 Fault Detail block that gives the last fault reported. The IO Fault Status block should be used to indentify that there is a fault and then the MC33810 Fault Detail block can identify which fault was reported. The open while asserted fault is detected through current monitoring. Currents less than 200mA can cause an open while asserted fault to be reported. Therefore, if the load current is expected to be under 200mA, the Open While Asserted diagnostic should be disabled via the Open Load While Asserted Configuration block. A special blockset has been created for control and diagnostics of the MC33810 chip which is the driver for the IGBT coil drivers on the SECM112. See here for more detail on the blocks related to the MC33810.

• LSO10: reports open or short to GND while de-asserted, and short while asserted. The IO Fault Status block will report a “2” if no fault is detected, or a “1” if a fault state is detected. It will not report a "0" (OK). There is a Fault Detail block that will also report which type of fault (Open or Short) has been detected. Note that the Fault Detail block can still report indeterminate (2) in some cases, but can more clearly identify whether a particular fault is active. For example, while LSO10 is de-asserted the fault detail for LSO10 will report the open fault as being either OK (0) or in fault (1), but will sometimes intermittently report indeterminate(2). The short to battery would continuously report indeterminate (2) while off.

• LSO15: reports open or short to GND while de-asserted, and short while asserted. There is not a block to detect which fault is being set, but the state of the output (On or Off) could be used in the application model. This will report “2” if no fault is detected, or a “1” if a fault state is detected. <br\> <br\>

Internal Temperature Monitor

The SECM112 has an internal temperature monitor. Although there is not a MotoHawk block to access the temperature, the internal temperature can be read in an application through the use of an inline code block. An example is shown below. Basically the inline code block copies the value from the “under the hood” variable (blue box) to a MotoHawk variable (Red Box) that can then be used throughout the model like any other variable. The under the hood variable only changes once per second. So, for example, you could implement a Simulink model that logged the maximum observed MicroTemp to NVM.

Shared Resources between the Main and Auxillary S12 cores

The following are shared between the main and s12G cores:

Analog inputs: AN01-05, AN16, AN17, AN18, AN24, AN31, VCAL, KEYSW

Digital inputs: VR1/DG1 (after mux), DG3, DG4, DG5, DG8, Wake-up (on XIRQ) from main core, reset from main core*, main core status

Comms: CAN1

Outputs: H1 enable, H2 enable, MC33810 enable, NCV enable, VR1/DG1 mux disable, VR2/DG2 mux disable, MPRD disable, main core reset, reset main core status, main core interrupt, CAM VR mode select, CAM VR threshold PWM, AN20 PU select, AN24 PU select, AN31 PU select, DG3 PU select

The CAM VR mode select, CAM VR threshold PWM, AN20 PU select, AN24 PU select, AN31 PU select, DG3 PU select can be configured by the main core via SPI.

• There is a shared line for reset of the S12 by the main core, however, this is not available to the application. There is no block to set it. It is currently only used during programming to turn the S12 off to prevent CAN bus errors or erroneous resets<br\>

Communications

CAN

The SECM112 has three 2.0B CAN ports for distributed I/O, distributed control, and Human Machine Interface (HMI) purposes.

Important: The SECM112 is programmed at the factory with a sample application that sets CAN-1 of both the Main and Auxillary Cores to 500k baud rate.   
Both Cores are internally connecxted within the ECU on CAN-1.
If the baud rate of one of the cores is changed on CAN-1, then the baud rate of the other core must be programmed also to match on CAN-1.
Each Core must also have a Unique City ID for MotoTune defined in the CAN Definition Block

For programming the SECM112, it may help to think of it as two modules connected on CAN-1 - the main and the aux S12G. Since the cores are internally connected on CAN-1, the baud rate must be the same for both on CAN-1, and they must have different City-ID’s. The module ships pre-programmed with an application that sets the Baud rate for both cores to 500k, with City ID of main – 0xB and the City ID of the aux 0x81.

The hardboot (settings used to program the module by boot key or boot harness) if it needs to be recovered are: Main: 250k b/s City ID 0xB Aux: 250k b/s City ID 0x81

To change the baud rate on CAN-1, first program the main core. Cycle power to put auxiliary in hardboot, the program the auxiliary as above.

<br\>

MotoHawk Target Cross Reference

The MotoHawk Target Cross Reference shows which IO on the ECM-OH hardware is supported by which behavior (blocks). There are charts showing behavior vs pin as well as pin vs behavior. This is the software help document for the module.

<br\>

The Reaction Module Blockset and the SECM112

The standard PSP blocks (Injector Sequence, Dual PSP, Multiple PSP..) are supported on the SECM112, but configuration of the Reaction Module is Required for Injection on the SECM112.

Peak-Hold timing is configured by the Reaction Module, and the peak-hold input port on the sequence blocks is ignored.

See the article on the Reaction Module Blockset for additional details.

<br\>

MC33810 Spark Blockset and the SECM112

Many of the Woodward MCS ECMs have EST outputs which provide 0-5V TTL level outputs for smart coils. The SECM112 spark outputs are IGBT coil drivers for driving a coil directly. These outputs use the MC33810 driver, which is configured through the MC33810 Configuration blocks, located in MotoHawk Module Configuration blocks.

See the article on the MC33810 Configuration blocks for more detail.

<br\>

Calibration Memory

The SECM112 has 64k of Calibration memory available.

If you are porting an application from another ECU (ex. the 128-pin) the SECM-112 may have less calibration memory available. There is a second 64k of Calibration Flash that can be used to shadow this data so that in the event of a power loss during calibration a copy of the calibration data is stored (from the last write). This redundant calibration is enabled with a special blockset. However, the SECM112 has 64k of Calibration Flash memory, regardless of whether redundant calibration is enabled or not. The second 64k cannot be used to store additional calibrations. This was a design descision based on the total memory of the DEV module. For the DEV module, calibration data is shadowed from flash into RAM at startup to allow on-line calibration. The SECM112 has limited RAM as compared to some of the other ECUs with external RAM. If additional calibration flash was allocated, the same amount of RAM would need to be reserved and would not be available to the application. For the Flash module, the calibration data is read directly from Flash and is not shadowed into RAM.

The SECM112 also has 32k of NV memory storage in serial EEPROM. The NV data (for both DEV or PROD) is shadowed in RAM at startup, and is stored in the serial EEPROM at shutdown through execution of the store NV block. Some calibration values may be able to be moved to NV storage (ex. Calibration NV).

Recommendations to reduce calibration memory in the application:

1. Review and Optimize Datatypes. The first thing to look at in reducing calibration memory is 64 bit vs 32 bit. Double is the Simulink default, but is often larger than required. Convert calibratons to 32-bit (single) or smaller datatypes.

2. Review and Optimize Tables. The next big item is table optimizations. It is likely that 32-bit floating point is not needed for every table and can be reduced. Reducing the dimenstions of tables would also reduce the memory usage.

The Main Power Relay Block and the S12G Auxillary processor

A common question is whether the MotoHawk MPRD block should be placed in the application for the S12G auxillary processor or not. And, if so does it need to be modified. The MPRD block is optional and does not need to be placed in the application.

Also, the MPRD block is intended as a starting point and is intended to be modified to suite specific application shutdown requirements (right click the block and select Look Under Mask).

An application may choose to have the MPRD block, or some shutdown logic, in the model for the S12G in order for the S12G to go to sleep to reduce current draw or to get the Key Off timer. The S12 will go to sleep when the shutdown power block is executed. When woken up by the main core, it will continue executed from where it left off. If using the standard MPRD block with the auxillary S12G, it is nessessary to remove the MPRD discrete output from the block. The below link has an example MPRD block modified for the ECM-OH Auxillary processor.

ECM-OH Example of Modified MPRD for the S12G

Recovering the SECM112

Occationally, errors in programming may require that the module be recovered with a boot key or boot sequence.

See Boot Key Recovery for more detail on how to recover the module.

The Hardboot Settings for SECM112 are CAN-1:

• Main: 250k, City ID 0x0B
• Aux: 250k, City ID 0x81

These are the MotoServer Port settings needed when recovering the module.

Important: Remove the ECU from all controll connections before attempting to recover the module.

The SECM112 is different in that it has two microprocessor cores, the Main Core and the Auxillary S12G. The processors are connected on CAN1, so it is important that the baud rate of both processors on CAN1 be the same. The processors must also communicate with MotoTune on different city-id's.

Recovering the Main Processor
The main processor can be recovered with a boot key on pin DG8. The boot key provides a 555Hz, 0-Vbatt, 50% duty cycle square wave on the STOP pin (pin E) of the 10-pin hub. This signal can then be wired to DG8.

Alternatively, the main processor can be recovered with the following sequence on the analog inputs:
AN3: Pull to +5V AN4: Pull to +5V AN16: Pull to GND AN17: Pull to GND AN18: Pull to +5V

Recovering the S12G Auxillary processor.
The S12G cannot be recovered with a boot key. A boot sequence on the analog inputs of the S12G is required to recover it.
AN3: Pull to +5V AN4: Pull to +5V AN16: Pull to +5V AN17: Pull to GND

Applying the boot signal or sequence

To apply the boot key signal or boot sequence to force the ECU into hardboot mode, the bootloader must 'see' the boot signal or sequence within 2-3 seconds of waking. Therefore, it help to 1) Apply the boot signal or sequence. 2) Turn Power ON, but key off. 3) Begin Programming the ECU on the MotoServer port (City ID 0x0B 250k baud for main, 0x081 250kbaud for auxillary). 4) When 'Searching for ECU' appears in MotoTune, turn the key on. It may take several tries.

Notes:

If you are recovering the S12G core of the ECM-OH, you must first program an application into the Main Core that sets CAN1 to be 250kbps. Battery must be toggled before powering up the S12G in Boot mode.

Use the following MotoServer Port Configurations when connecting with the ECU. These are the default hardboot settings. ECM-OH main: 250kbps on CAN-1, City ID 0xB (11) S12G: 250kbps on CAN-1, City ID 0x81 (129)

The Pre-PV and PV units will ship with a sample application that will connect at 500k on PCM-1 (City-ID 11) or PCM-2 (City-ID 12. Recovering either microprocessor will force it back to it's default hardboot baud rate of 250kbps. So, you must reprogram the other microprocessor with an application to change it to 250kbps.

FAQ

Why Do I get this Build Warning?WARNING: CamEncoder has interface Hardware that has not been defined.

There are new blocks in the MotoHawk Module Configuration library to set the Vr or Dg interface. The settings in the Encoder Definition block are ignored. You must use these blocks in the model.

What causes the build to fail with this error? "ERROR: A ReactPHWOTChan definition for INJ1 was not found in the application. "

If the application is using the Injector blocks, the module's Reaction Channel must be defined and configured using the Reaction Channel Blockset. This blockset is used to configure the peak/hold current levels (see above).

I see values with 100% in the build log. Is this expected?

There are several memory areas displayed in the build statistics that are internally reserved peices of data. These are displayed at 100% in the build statistics and cannot be changed by the application.
FLASH_RCHW: 4 bytes 100% of 4
FLASH_ENTRY: 4 bytes 100% of 4
FLASH_CRCDEFNPTR: 4 bytes 100% of 4
RAM_BOOTMAILBOX: 16 bytes 100% of 16

Is the 12 V power supply isolated?

12VOUT is supplied from DRVP and shares a common ground plane so no there is no galvanic isolation from the other supplies. The intent of the 12VOUT is to power a MAF sensor that requires this voltage.