MotoHawk Hardware

FAQs Page
MotoHawk Control Solutions

MotoHawk (formerly called MotoTron) Line of Controllers and Specifications

Please visit the following MotoHawk ECU Summary Page for MotoHawk controller family availability. This is a good starting point to help select a family for which numerous part numbers can be found by searching the data sheets in the download section (login required, can be requested by emailing sales@neweagle.net).

Controllers in development are also found in the download section of our site.

RoHS and MotoTron ECU Modules

Motorola had been pushing for RoHS compliance across the company since they are mainly consumer products, but when Conti took over there is no longer this push. There is no plan to go lead-free on solder for Visteon or Conti. The impact to the part design (higher reflow temps) and manufacturing is too great.

Controller Quality Certification

Both Visteon and Continental built MotoHawk modules (24, 48, 80, 128 pin modules) have QS-9000/TS16949 quality certification.

Do MotoHawk ECUs meet J1455 Heavy Duty Truck Standards?

In general, J1455 is a guideline, not really a standard. A potential OEM customer has to provide specific details on some tests called out in J1455. For vibration, some profiles are provided in the standard but the OEM has to determine the acceleration factors and duration based upon their expected system usage.

MotoHawk ECUs including the ECM24, GCM24, GCM48, ECM48 have been used in heavy duty truck applications for CAN gateways and Diesel emissions controls. In many cases, a customer will request and pay for additional testing than what was done in the validation of a MotoHawk module at either Continental or Visteon.

Which label contains the serial number?

Here is a label applied by Woodward that has the serial number highlighted in red.

Module Selection

To help select the proper module for a project, go to the ECU selection Document.

Use of MPRD

In all development harnesses New Eagle provides, and would design we include a main power relay, an example of which can be seen in the fusing requirements diagram below. The relay takes power from the battery and is controlled by the MPRD pin to provide power to the output pins through the DRVP pins. This might seem redundant and instead of having the relay you could just hard wire DRVP pins to the battery source; however for most applications this is not a good idea. One useful function of the main power relay (MPR) sourcing all the power that is sunk by the low-side drivers (including injector drivers) is the ECM can disable actuator power if it determines an actuator is shorted out on the control side to chassis ground. Of course this disables all low-side drivers, but it is the compromise to avoid having more expensive high-side drivers on the hardware; which could be able to disable source to the actuators individually. The assumption here is that shorts to battery power are much rarer than shorts to chassis.

The second reason for the MPR is reverse battery protection as this architecture allows the low-side drivers, other than MPRD, to not have reverse battery diode for protection since no DRVP, no current flow. For this protection us of the MPR is mandatory. Anything engine related would typically go through the MPR. In case where this is not convenient, like a on a bus with the engine in the rear, dash lamps and such would be sourced from VBAT. If you have a question on which LSD have a blocking diode look at the data sheet. If the datasheet does not contain the information contact New Eagle. However, as mentioned it is a better practice to use MPR and to only use the blocking diode when necessary. If you do hook up the low side drivers in a reverse battery situation all the loads will be actuated and it will likely damage the ECU if the condition persists.

Fusing Requirements

The load fusing requirements are dependent on the application, and module. An example diagram of how to fuse a module harness is below. However, across the range of modules a 2A fuse for the battery and 1A for KEYSW is recommended. The DRVP feed to the module is fused in common with the MPR coil feed and the size will depend on what outputs are being used. DRVP feeds the H-bridges and LSO recirculating current. It is also good practice to fuse injectors, ignition coils, and miscellaneous with separate fuses. It is good practice to fuse the injectors, ignition coils and miscellaneous with separate fuses. The diagram shows separate relays as well as fuses for the injector inputs, but this is not required as long as the relay current for MPRD is not exceeded. It is important to fuse the DRVP to the module separately from the injector feed as field issues have occurred where a common fuse blows and the injectors are back fed via the LSO recirculating diodes and still fire but at a reduced performance. This diagram shows separate relays as well, but this is not required as long as the relay current is not exceeded.

Specific Controller Information

ECM/GCM S12-24 Controllers

For information specific to the 24pin ECMs (the SECM family) please see Engine Control Modules.

Current Draw on the 24 pin family

Power draw should be the base below, plus power required for sensor inputs (from XDRP) and driven loads.

• SECM08xx (PROD): approx. 100 mA at 13.8 V (key on, module-only, no external loads or sensors).
• SECM08xx (DEV) : approx. 270 mA at 13.8 V (key on, module-only, no external loads or sensors).
• MCHI04xx (PROD): approx. 100 mA at 13.8 V (key on, module-only, no external loads or sensors).
• MCHI04xx (DEV) : Does not exist.

The above numbers are from a quick test here on-bench for the various modules, with a baseline "empty" application and with nothing but power, ground, and CAN connections. The SECM08xx (DEV) draws additional current, to drive the additional calibratible memory circuitry. This data comes from one SECM 24-pin DEV module.

For the MCHI04xx family, the key-off fully-shutdown power draw on BATT should be less than 0.5 mA.

Difference between ECM0502 and GCM0402

When the controllers shutdown, there is a difference in the way calibrations are stored. ECM does not have separate KeySw and Battery pins so there is no way the controller would know to save the calibrations before a shutdown. In this case, it would have to save these values periodically. Whereas in case of a GCM, there are two separate KeySw and Battery pins so the module can save Non Volatile data when a shutdown is commanded and then go to sleep.

Datasheets

• ECM-S12-024 Datasheets
• GCM-S12-024 Datasheets

Webstore

Webstore: 24-pin Electric Control Modules (ECM and GCM)

General Hardware / Wiring Questions

ECUP vs Key_SW and ESTOP

What/where is the ECUP line (in reference to key switch operation)? I cannot see it in the wiring diagram for the controller or for the development harness. I do, however, see "KEY_SW" and "STOP-DIG/AN_IN", which are connected to the SmartCraft connector as "WAKE" and "ESTOP" respectively. Or are you saying that the main power input line is affected by the operation of the key switch, and that in turn allows the controller to shut down properly?

ECUP and KEY_SW are used interchangeably. Different modules use the two terms but they always mean the same thing. ECUP or KEYSW are monitored by the internal power conditioning to wake up the processor. Once the processor is up and online, the application software monitors this line to indicate when to do a shutdown of the processor. On modules that have a BATT line, the module is capable of achieving a controlled shutdown by drawing power from the BATT line until a graceful shutdown is achieved. Basically, the sequence of events is that once the ECUP line drops, we begin an orderly shutdown of the application which includes storing non-volatile memory and shutting off the actuators including the Main Power Relay output. Once the MPR is dropped, the module will either go dormant or reboot depending upon the voltage at the ECUP/KEY_SW line.

I tried to operate the controller by unplugging the key switch and switching power directly, but the controller did not operate. Is this what you would expect? Is this related to the above question?

Yes. KEY_SW is the turn on/turn off signal.

Operating Without Keyswitch

If I wanted to operate the controller without the key switch (assuming I don't need to save any non-volatile memory prior to loss of power), would it be appropriate to connect/wire up the pins as if the switch were in the "on" position? If so, can you please provide the pin assignments and states for the switch? (When in on mode, does it connect power to wake?)

Wire BATT, KEY_SW, and DRVP pins to your voltage source. The module will boot up on the power coming up and crash when power goes down.

Is it possible and/or appropriate to replace the key switch with a relay or small manual switch between the pins identified in the above question?

Yes. You can switch ECUP or all of the power through a switch or relay.

SmartCraft Pinout

Boot Key Recovery

When working in the prototype phase with newly created .srz files from MotoHawk, it is possible to program a .srz with errors in the CAN software or in the model that prevent communications with the module once programmed. When this happens, the module appears to be locked up or frozen when accessing the module via MotoTune. In this case, use the Boot Key to force the module into reboot mode such that a known, valid .srz can be reprogrammed into the module.

Understanding the Boot Key functionality

The Boot Key has a 10 pin CAN connector that should be inserted into an open port on the CAN junction box. The device generates a 555 Hz, 5V signal out of pin E when power is applied to pin A and ground applied to pin B.

At power-on, the hardboot loader for the module first looks to see if the boot key input or boot cable sequence is present. If so, the code prepares to accept programming. If no programming instructions are received from Mototune within a few seconds (~3) then the existing program application is started & recovery is not successful. At power-on (Batt and Keysw), if the hardboot loader does not detect the bootkey signal (or boot harness sequence), then the hardboot loader skips the 3-second wait and starts the existing application. So, the ECU must see the boot key signal immediately when it powers up. It can help, especially on the 112 pin modules, to energize the boot key before the module (may need to disconnect the connector between ECU and the junction box, but leave power to junction box)

The recovery procedure is as follows:

1. Plug the Boot Key into the junction box and make sure that power and ground are connected to pins A and B on the junction box. Connect pin E of the junction box to the channel listed below on the following modules.

• ECM-555-48 – ESTOP

• To purchase a Boot Cable, please visit HARN-ECM-012-00

• ECM-555-80 – ESTOP
• PCM-565-128 – DG1
• HCM-563-48 – STOP*
• GCM-563-48 – STOP*

• If the Boot Key fails to work with above two GCM/HCM 563-48 modules, refer to Fire48 Hardboot Recovery. In order to purchase a boot cable, visit HARN-ECM-022

• ECM-5554-112 – STOP
• HCS-12 (24 pin modules) - Refer to HCS12 Boot Connections for GCM 24 pin module
• ECM-563-48 – Does not use a boot key.

• There are two approaches to recovering the module:

1. Use a Boot Cable (part number HARN-ECM-013), purchase at HARN-ECM-013, Download drawing from Harness Documentation
2. To boot strap the ECM-563-48 modules, connect the following channels and follow the steps below.

• AN1 – AN6 Pull to +5V
• AN8 Pull to GND
• AN11 & AN12 Pull to +5V

2. With the power to the module off and the boot key installed, select a known, valid .srz file to flash onto the module and program the module at 250kbps on the module's default city-ID. All modules default to city-ID PCM-1 (0x0B) with the following exceptions:

• ECM-S12 - SECM-1 (0x81) (Not applicable to ECM-S12-24-0804 which defaults to PCM-1)

• GCM-S12 - uCHI-1 (0x91)

3. When the “Looking for an ECU” prompt appears in the dialogue box, turn on power to the ECU. The module must “wake-up” with the boot key applied in order to force a reboot.

Voltage Specifications for Modules

While all the modules are designed to withstand momentary short-to-battery on the input sensor pins (except those that inherently cannot be protected), the hardware validation test is typically 1 minute short-to-battery.

In the case of analog and digital inputs (nominal 5-volt), the circuit may not be able to dissipate heat when connected to a higher voltage on a longer timeframe. For instance, the pull-up or pull-down resistor may not be sized to dissipate heat from that higher voltage (resistor wattage rating).

+++++

For the circuits marked "16V okay" in the table below, the resistor wattage rating is such that continuous operation at 16V should be okay.

"Double Battery" situation: If you have a question about a particular circuit, email New Eagle Support. At nominal 24V (as high as 32V jumpstart), the trace widths as well as the PU/PD resistor may be vulnerable. Some of the pull-downs would likely be okay, but this should be verified. For example, AN4: 220k-ohm pull-down ---> P = V2 / R = 32*32 / 220e3 = 0.005 W = 5 mW. The resistor for AN4 is rated 63 mW. Depending on ambient temperature for module (heat transfer from resistor, to module body, to ambient), this circuit may be okay for short "double battery" exposure.

H-bridge Wiring

The H-bridge is normally wired as: (H+)----(load)----(H–) and the H-bridge circuit is powered from DRVP internally. (BATT)----(MPR Common, MPR Normally Open)----(DRVP)----(to H-bridge and other internal devices, and flyback diodes).

The low side of the H-bridge circuitry connects to DRVGx and then back to battery ground.

In one H-bridge, the fault/current feedback line is shared between each half bridge. Therefore, you can only get reliable fault or current data when using it as a H-bridge or only using one half bridge. If both half-bridges are used independently, the fault/current feedback line will provide unreliable data for either of them.

CAN Addressing Conflicts

You may run into issues with MotoTune's CAN messaging conflicting with other CAN communications in your system. It is possible to change the CAN IDs on which MotoTune communicates to avoid this. This section will describe how to do so.

You will need to make changes to both your model and your MotoTune configuration to support the new MotoTune communication CAN IDs.

Model Configuration

1. Disable the MotoTune Protocol in the CAN Definition block
2. Add the MotoTune Custom CAN Protocol Handler block (Idle Triggered)

   RX ID = hex2dec('1A000B02')

   RX ID mask = hex2dec('1F00FFFF')

   TX ID = hex2dec('1A00020B')

• 

  MotoTune Protocol Disabled

• 

  New CAN IDs for the MotoTune Custom CAN Protocol block

MotoTune/MotoServer Configuration

1. Open MotoTune and configure the MotoServer Ports
2. Edit Port Names and create a Custom CAN Mapping

   TX ID: 436210434 (this is 0x1A000B02, but use decimal here)

   RX ID: 436208139 (this is 0x1A00020B, but use decimal here)

3. Create a new Port configuration
4. After flashing the module, the MotoTune protocol will no longer be available on PCM-1 and will only be available on the new custom mapping.

• 

  MotoTune context menu

• 

  Edit Names

• 

  Add a port name

• 

  Select 'CAN Custom'

• 

  Enter your name and the appropriate CAN IDs

• 

  Add a port configuration

• 
• 

  Now your custom port is in the ports list!

• 

  Don't forget to select it in the Program dialog box

MotoTune dongle is plugged in, but MotoViewer won't open.

In order to open up Motoviewer, a separate MotoService dongle is required.

MotoTune has stopped working after a Re-install/Update.

• If you are upgrading from 8.13 to 10.0, please uninstall 8.13 first then install 10.0 if you have encountered issues.
• When downgrading from 10.0 to 8.13, please uninstall 10.0 and the MotoLicense Handler before installing the 8.13 version of MotoTune

Implementing J1587 Protocol on a J1708 hardware layer (using a MotoTron RS485 Driver)

A RS485 software driver in MotoHawk can be written for J1587. The hardware signal conditioning and some general J1587 notes follow:

Communication between Serial port on ECU and USB device over RS485

Lets assume you want to use the USB with a laptop/PC and enable Mototune to communicate over RS485. So when the hardware is connected to the PC, it would be recognized by the computer, say as COM7 port.

1. Add a New Port by going to Motoserver->Ports->Add. In the window that appears, select ‘Serial’ under Type and ‘COM7’ under the Location.

2.‘Serial I/O Blocks’ in MotoHawk blockset will help define the communication over a specific protocol, RS485 in this case.

Hall Effect Inputs

Hall Effect Sensing

Variable Reluctance Inputs

VR Sensing

DC Motor Drive

Can one drive a DC Motor with a MotoHawk module? If current is one way, you can use a low side drive. You can parallel LSDs to get the power required. For example, a 12V, 150 watt motor would require 12.5 amps of drive.