CDANewECUFlashSupportProcess_v1_4

(1)

Chrysler Diagnostic

Application

New ECU Flash Support

Process

A guide on the process to request CDA flash application support for new ECUs

(2)

Global Service Diagnostics

Release Version: 1.4 Release Date: 2 July 2008

I

NTRODUCTION

This document describes how to request EFD flash support for new ECUs. If an ECU is not available for selection in the drop-downs on the first screen in the EFD Builder application, then flash support for the ECU has not yet been implemented. It is typically the responsibility of the ECU Release Engineer to request flash support for the ECUs they are responsible for releasing. A request for EFD flash support is a request for flash implementation in EFD Builder, the Chrysler Diagnostic Application (CDA), and the Chrysler service tools. Flash support implementation also includes verification of flash support using all supported Chrysler diagnostic tools (StarMOBILE, StarSCAN, and Vector hardware).

R

EQUESTING

N

EW

ECU

F

LASH

S

UPPORT

ECU Release Engineers must request flash support for the ECUs they are responsible for releasing. To request flash support, ECU Release Engineers must follow these steps:

1. Gather the flash requirements described in Appendix A.

2. Submit an ‘ECU Flash Support Request’ through Jira. You will be required to enter in the information mentioned in #1 above. The basic steps to create a Jira issue are:

a. Log in to Jira using one of the following methods:

i. Log into the Diagnostic Workbench (http://workbench.ctc.chrysler.com:8090/wrkbch/) and click on Support (in the toolbar), then Submit issue.

ii. Log into Jira directly (http://ngstserver.ctc.chrysler.com:8080/secure/Dashboard.jspa) b. Click on the Engineering ECU Flash Support (EEFS) project.

c. Click Create New Issue near the top of the screen.

d. Ensure that the issue type is ECU Flash Support Request and click Next. e. Enter the information into ALL of the fields listed.

3. Provide hardware and wiring harness to the Global Service Diagnostics CDA flash development team for flash application development and verification. See Appendix B - ‘Hardware Requirements’ for more details. Please note that the ECUs will not be returned. They will be kept by Global Service

Diagnostics for regression testing.

4. The CDA flash development team will communicate with the ECU Release Engineer through Jira if any questions arise or more information is required.

R

ELEASING

N

EW

ECU

F

LASH

S

UPPORT

The CDA flash development team cannot begin flash support implementation until ALL of the requirements discussed in Appendices A and B are received and documented in the Jira issue. Once ALL of the necessary requirements are provided, the CDA flash development team will follow the process below.

As soon as is possible after receiving ALL necessary requirements (goal is within 1 week) the CDA team will: 1. Implement flash support for ECU in EFD Builder.

2. Verify that EFD Builder can build an EFD file based on the information and code/calibration files provided.

3. Verify that CDA can successfully flash the ECU parts provided using the EFD files generated in number 2 above.

(3)

4. Run basic diagnostic protocol tests on the ECU to ensure that the ECU is properly following diagnostic protocol as stated in the applicable diagnostic specification(s). Please note that if it is found that the ECU is not properly conforming to diagnostic protocol, EFD Builder support will not be released until the conformance issue(s) have been addressed, either by being fixed by the supplier or by the creation of a diagnostic waiver.

Once the flash implementation and testing have been completed AND there are no outstanding ECU protocol conformance issues, the CDA flash development team will do the following on the last working Thursday of the month:

1. Release successfully implemented and verified new ECU flash support to the production EFD Builder applications on the Diagnostic Workbench sites (both internal Chrysler site and external Supplier site).

(4)

A

PPENDIX

A

–

F

LASH

R

EQUIREMENTS

The tables below identify the requirements that are necessary in order to implement flash support for ECUs. Most of this information can be obtained from the supplier. ALL of the information shown in the tables below must be received by the CDA flash development team before work can begin.

These requirements should be provided via the Jira application, and they can be added over time as they are received from the supplier. In other words, not all requirements are necessary in order to initially create the Jira issue. To enter/modify information in an existing Jira issue, click the ‘Edit’ link on the left panel. To attach files to an existing Jira issue, click the ‘Attach Files’ link on the left panel.

1. Flash Information

Information Required Description

ECU Acronym (e.g. ABS, PCM, etc.)

ECU Long Name The full name of this ECU (e.g. WCM = Wireless Control Module).

ECU Type

ECU Type info is required if there are multiple types for a given ECU_Supplier combination. For example, for an NGC3 ECU, PCM is the ECU acronym, but there are multiple 'types' of NGC3 PCMs (Engine only, LEO, etc.). Each ECU type must have a separate flash request entered if the flash process differs based on the hardware type.

Initial / Lead Model Year The first model year that this ECU applies to.

Applicable Model(s) ALL vehicle lines that this ECU will be used on in the Initial/Lead Model Year.

Applicable Variant(s) All variants (e.g. 1, 2, and 3) that use the same flash process for a given ECU type (e.g. WCM).

CAN Diagnostic Request ID CAN Physical Request ID in hex format (e.g. 0x620). CAN Diagnostic Response ID CAN Physical Response ID in hex format (e.g. 0x720).

ECU Bus Type The physical bus designation that this ECU is flashed over (e.g. PCM is flashed over 'CAN-C (500Kb)').

ECU Supplier The ECU Supplier Note: The list in Jira is based off of the Supplier Table Encoding used in the DDTs.

Gateway(s) ECU could be flashed through

The Gateway(s) that this ECU could be flashed through. For example, if this ECU was used on two vehicle platforms (LX and HB) you would select the gateways that are used on those vehicle lines (FCM - Yazaki & FCM - Huntsville).

Release Engineer Contact Info (Chrysler)

The Release Engineer's name and contact info. (e.g. John Doe, [email protected], 248.944.2717)

Supplier Contact Information Any Supplier(s) Contact Information that is appropriate. (e.g. Jane Doe - Software Engineer, [email protected], 248.944.2717) Flash Process Enabling Criteria

/ Environmental Conditions

Any enabling criteria that is required to flash this ECU. For

example, VMM message 0x1c (wheel speed) must be set to 0x00. Another example would be system voltage has to be between 13 - 14 Volts.

(5)

ECU Logical Block Definition

The number of logical blocks supported by the ECU and the definition of those blocks (if KWP2000). For example, if an ECU supports flashing 3 logical blocks you would define them as follows: Code Logical Block: Physical address range 00002000 - 000FA000. Data Logical Block: Physical address range 0000FB00 - 00FF0000. Boot Logical Block: Physical address range

01F00000 - FF000000 For UDS ECUs: Specify the logical block number and physical address range for that particular block.

Checksum and Checksum Calculation Info

The Checksum method details if the ECU flash process requires that a checksum be calculated for any of the downloadable components (Erase SWIL, Program SWIL, and / or ECU Code Software). The supported checksum types are None, CRC32, FCSCRC, ADDITIVE16, or Constant. Constant type means the checksum is specified for a particular downloadable component (Erase SWIL, Program SWIL, and / or ECU Code Software). Note: Most previously supported KWP2000 CAN ECUs use a checksum type of 'None'.

Compression and Encryption (if used)

If this ECU supports encryption or compression for the ECU code file or SWIL(s), define which numerical value is being expected by the ECU. Note: If an ECU did not require encryption or

compression these values would be set to 0x00 indicating that they are not used.

Signature Information

The Signature Process details if the ECU flash process requires that a Signature be sent from the flash tool for any of the

downloadable components (Erase SWIL, Program SWIL, and / or ECU Code Software). Note: This is not 'typically' a common feature implemented by ECUs.

Flash Part Number Definition

The KWP2000 or UDS diagnostic command that is used to base flash part number supercedence on (for service). This data should be specified by the release engineer and is the part number information that is updated during/after a flash has occurred. Bootloader Details Details on the type and version of the ECU’s bootloader (e.g.

Vector SLP6, Vector SLP9, Supplier developed, etc.).

2. Flash Files

File Required Description

Erase SWIL File The source .s19, .s28, .s37, or .hex file that contains the Erase SWIL (Software Interlock) if supported by the ECU.

Program SWIL File The source .s19, .s28, .s37, or .hex file that contains the Program SWIL (Software Interlock) if supported by the ECU.

ECU Code Flash File Set #1 (and all applicable part numbers)

The source .s19, .s28, .s37, or .hex file that contains the ECU Software Code. The ECU Software Code file is the actual file that contains the physical block data that gets downloaded into the ECU. The file should contain only the data that is to be

downloaded to the ECU via the flash. Two ECU Flash Code Files are needed to ensure that the ECU part numbers are updating based on the requirements. Also ensure that the two ECU Code Flash Files that are attached actually have two different part numbers when requested via diagnostic commands (e.g. 0x1A 87,

(6)

1A 9C, 1A 9D, 1A 9E, etc.).

ECU Code Flash File Set #2 (and all applicable part numbers)

The source .s19, .s28, .s37, or .hex file that contains the ECU Software Code. The ECU Software Code file is the actual file that contains the physical block data that gets downloaded into the ECU. The file should contain only the data that is to be

downloaded to the ECU via the flash. Two ECU Flash Code Files are needed to ensure that the ECU part numbers are updating based on the requirements. Also ensure that the two ECU Code Flash Files that are attached actually have two different part numbers when requested via diagnostic commands (e.g. 0x1A 87, 1A 9C, 1A 9D, 1A 9E, etc.).

3. Flash Documents

Document Required Description

ECU Connector Pinout / Wiring Diagram

The most representative and clear pinout diagram for this ECU. If the ECU has multiple powers and grounds defined, note those that are actually used / required to power up the ECU.

ECU Paper Unlock Algorithm Submission Form

The ‘Security Algorithm Submission Form’ (available on the Core Vehicle Diagnostics database in Lotus Notes) must be submitted to the Core Vehicle Diagnostics group as stated on the form itself. Core Vehicle Diagnostics is then responsible for providing the unlock algorithm to the CDA Development Team based on the Security Unlock Authoring Process defined by both groups. Flash Trace Bus Log Flash trace bus log of the flash process using supplier or other

(7)

A

PPENDIX

B

–

H

ARDWARE

R

EQUIREMENTS

ECU hardware and a wiring harness must be provided to the Global Service Diagnostics CDA flash

development team for tool software verification. The ECUs will not be returned. They will be kept by Global Service Diagnostics for flash regression testing. The ECU harness must include a connector(s) for that ECU with the circuits used for powering and communicating (CAN) clearly labeled / defined. A minimum of 2 ECUs are required. If additional parts are required, the Release Engineer will be notified through Jira. The ECU must be labeled with the following information:

o ECU Acronym o Supplier

o Diagnostic Variant

o Jira issue number for ECU flash support request (e.g. EEFS-23) o ECU Release Engineer contact information

Choose one of the following methods for delivery:

o Hand-deliver the ECU hardware and harness to the drop box located at Nick Latorre’s desk in the Global Service Diagnostics department, CTC suite S2023, Pole #2 S8 W20.

o Ship the ECU hardware and harness to: Nick Latorre

c/o V2Soft, Inc.

2619 Product Dr. Suite 102 Rochester Hills, MI 48309