Troubleshooting MotoTune Communication Problems

From MotoHawk
Jump to navigationJump to search

It is possible that you may run into difficulty connecting to the module with MotoTune. The below article is intended to address the most common causes of communication issues and to guide you through successful troubleshooting.

Hardware:

Connections

The communication channel wiring may be incorrect. Recheck the wiring with the ECU datasheet. At a minimum, Power, Ground, Key, CAN1+ and CAN1- are needed. The key needs to be on (12V or 24V)

There may not be proper CAN termination. It is recommended to have 120-Ohms at each end of the bus, but for bench work at slow baud rate (250k or 500k baud), 120-ohms is normally ok.

The communication connections could be loose or pins may not be making good contact (contamination). Make sure wires are secure and pins are clean.

Input Current and Input Voltage to the module are out of range. If the input voltage drops below a pre-defined threshold (based on module and application) or if the power supply cannot source enough current (current limiting), there may be issues reprogramming the module. Verify adequate input supply for the ECM hardware. See module datasheet for further information.

The CAN adaptor

CAN adaptor may not be working correctly. For Kvaser, power light should be steady. If it is blinking, there may be an issue with the adaptor hardware or with the drivers on the PC.

Windows may not be recognizing the CAN Hardware. To see if the CAN Hardware is recognized - Right Click on the Motoserver Icon (satellite dish) at the right of your window. Select Ports, double click Select CAN port, and click on More Info.

MotoServer1.PNG

If Windows is not recognizing the CAN hardware – the Device will shows as Kvaser Virtual CAN. The driver below is a simulated CAN bus. The computer is not connecting to the CAN.

MotoServer2.PNG

If windows is not recognizing the CAN hardware, verify
  • CAN bus is plugged in and connections are good
  • Wiring is correct – Communication cable is plugged in, to correct CAN/Serial channel
  • Power is on and being supplied, key is on.
  • CAN bus is clean – dirty CAN bus can frequently cause communication to fail
  • CAN termination present and correct
If the above is correct and Windows is not recognizing the CAN hardware, first try to unplug the USB connection from the computer, close Mototune, reconnect the USB, and relaunch MotoTune.

Note: If Windows still does not recognize the CAN hardware, try running the device manager, and search for new hardware. You may need to install new Kvaser drivers, available for download from Kvaser


If this does not work, after Closing MotoTune, use Windows Task Manager (Cntl-Alt-Delete) to check whether there are any mnfeature processes running. If so, end them with task manager before relaunching MotoTune.

Bus Errors

There may be other modules on the bus interfering with Communication. Remove other devices from the bus.

If you are using CAN trace software, it may not be allowing MotoTune to connect, or may be holding a different baud rate. If you are using Vector Hardware, you must set to "acknowledge on" for Mototune.

The 48, 80, and 128 pin ECU's can only program on CAN-1. If the application has set MotoTune protocol to CAN-2 only, the module will not be able to be reprogrammed. You may see an error 'Unable to change protocol'. The ECU can be recovered with a boot key.

MotoServer Port Configuration

MotoServer gives the connection between MotoTune and the ECU. The communication port that MotoServer uses to connect to the ECU must match what is programmed from the CAN Definition block. The ECU's are shipped able to connect on a default MotoServer Port, however, the application can change this port through the CAN Definition block. Then, a new port needs to be configured to match what is defined by the appplication.

Module Default CityIDs and Settings

MotoServer Port Configuration:

MotoServer Ports1.PNG

Configuring MotoServer Ports


Changing the City ID

License Issues

MotoTune verifies the information in the MotoTune dongle when connecting to the module for programming, calibration, or opening a diplay. If the license information cannot be read correctly, you will not be able to communicate with module using MotoTune.

Check that the top of your MotoTune Window displays your license dongle name, and does not say Unlicensed. If MotoTune displays Unlicensed, or dongle is otherwise unrecognized: Try closing MotoTune, plugging the dongle into another USB port, then relaunching MotoTune. Creating a License Update Transaction and then canceling it can sometimes refresh the license information on an unrecognized dongle. If creating and canceling a license update does not work, you can email a License Transaction file to MCSLicense@woodward.com and we can send you a new activation file.

Link to Using License Update to create Update Transaction:

Software

Errors in configuration, logic and/or other programming made during program development for can cause a persistent loss of CAN communications with the module under development. If this happens, apply the boot key to force the module into reboot mode, reloading the module with functional program code (a known, valid .srz file) in order to allow resumption of module communication. Follow the steps listed in the following link to recover the module with boot key or boot harness:

Boot Key Recovery of the ECU


The following are common errors that once programmed, developer will need boot-key (or boot harness) to recover the module:

1. Programming a “Prod (F)” module with an srz built for a “DEV(C)” module When programming verify that the part number of the module – whether it has a “C” at the end and or an “F”. Programming a PROD module with a DEV srz will cause the module to lose communication, and a boot key will be required. You will see an error at the end of programming, Programming Failed. Failure to write 0xF....

2. Having Resource set to “None” in the CAN definition block in the model. Note: If the target in the target definition block is changed, the CAN resource may show up as before until a CNTRL-D update, but will default to “None”


3. Disabling MotoTune protocol. If MotoTune protocol is disabled, you will not be able to communicate with the module via MotoTune. Note: Some module (48, 80, 128 pin), can only be programmed on CAN-1. If MotoTune protocol is disabled on that channel, you will not be able to reprogram the module (without a bootkey).

4. Application Issues/ Runtime Errors (stack overflow, divide by zero – lookup tables w/ default of zero value, infinite loop). The application monitor in the MotoHawk System Debug block library can be used to diagnose stack/heap/ idle CPU, and OS errors. The application developer sets margins for stack/heap/CPU idle, etc. When the margin is exceeded, the application monitor halts the application and maintains a connection to MotoTune. The reason for the application halt is then displayed in System | Debug | Application Monitor. For additional help on the Application Monitor, see the help test in the block mask (place the block in your model, double click, and select help).


5. Messages ID’s in the application conflict with ID’s used by MotoTune.

Some Common MotoTune Errors

1. Transport Packet Failed: usually occur because of a timeout between the module and the tool. Warning is triggered when no response is received from the module based on the default timeout. Check :

  • There are no other modules on the bus (impacting bus load).
  • Wiring/Termination Resistance
  • Baud Rate
  • CAN Length and Shielding (if in noisy environment).

2. No ECU Online/ No ECU found: MotoTune is attempting connection to module, but module itself is not responding. Check:

  • Wiring – Power, Ground, Communication Channel Connections, CAN Termination
  • Port is correctly configured and correct port is selected
  • Power/Key is on
  • Kvaser is operating correctly and is recognized by MotoServer

Module may need to be recovered with a Boot-Key or Boot-Harness

3. Programming Failed. Cause: Customer security failedThis error can be caused by the programming in a faulty srz or interruption during programming, and a boot key may be needed to recover the module. It can also indicate an issue with the license dongle.

4. Cannot Find 555xhboot_r01.dll This means the module is in hardboot mode. If you are seeing this error when attempting to open a display or calibration, the boot-key should be unplugged, or the harness is in “boot” mode.


The boot-key should only be used to recover a module due to an error in programming. The boot-key should be removed once programming is successful, before opening a display or calibration.

5. Cannot program this application because the application reports that the ECU hardware is not compatible. This means the .srz was built for a different ECU than the one being programmed. Verify that the Target selected in the Target Definition Block matches your actual hardware.

6. Unable to Change Protocol MotoTune is attempting to negotiate programming, but request is not successful. Some modules can only program on CAN-1. Attempting programming on CAN-2 will result in this error. Program the module over CAN-1 - you may need to modify your application to enable MotoTune protocol on CAN-1 in your CAN Definition block and recover the module with a boot key. CAN conflicts from other devices on the bus can also result in this error.

7. Access Level to Low This means the port access level in MotoServer is too low, or the dongle does not have sufficient permissions to allow programming. Try setting the port access level to 4.