Chrysler Diagnostic Application

New ECU Flash Support Process

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

CDA NEW ECU FLASH SUPPORT PROCESS

INTRODUCTION
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).

REQUESTING NEW ECU FLASH SUPPORT

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.

RELEASING NEW ECU FLASH SUPPORT

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.

Global Service Diagnostics Copyright 2008 Chrysler LLC

2 of 7

Release Version: 1.4 Release Date: 2 July 2008

CDA NEW ECU FLASH SUPPORT PROCESS

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).

Global Service Diagnostics Copyright 2008 Chrysler LLC

3 of 7

Release Version: 1.4 Release Date: 2 July 2008

CDA NEW ECU FLASH SUPPORT PROCESS

APPENDIX A FLASH REQUIREMENTS

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 ECU Acronym ECU Long Name Description (e.g. ABS, PCM, etc.) The full name of this ECU (e.g. WCM = Wireless Control Module). 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. The first model year that this ECU applies to. ALL vehicle lines that this ECU will be used on in the Initial/Lead Model Year. All variants (e.g. 1, 2, and 3) that use the same flash process for a given ECU type (e.g. WCM). CAN Physical Request ID in hex format (e.g. 0x620). CAN Physical Response ID in hex format (e.g. 0x720). The physical bus designation that this ECU is flashed over (e.g. PCM is flashed over 'CAN-C (500Kb)'). The ECU Supplier Note: The list in Jira is based off of the Supplier Table Encoding used in the DDTs. 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). The Release Engineer's name and contact info. (e.g. John Doe, jd1@dcx.com, 248.944.2717) Any Supplier(s) Contact Information that is appropriate. (e.g. Jane Doe - Software Engineer, jd@supplier.com, 248.944.2717) 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. The flash protocol this ECU has implemented.

ECU Type

Initial / Lead Model Year Applicable Model(s) Applicable Variant(s) CAN Diagnostic Request ID CAN Diagnostic Response ID ECU Bus Type ECU Supplier

Gateway(s) ECU could be flashed through Release Engineer Contact Info (Chrysler) Supplier Contact Information

Flash Process Enabling Criteria / Environmental Conditions ECU Flash Protocol

Global Service Diagnostics Copyright 2008 Chrysler LLC

4 of 7

Release Version: 1.4 Release Date: 2 July 2008

CDA NEW ECU FLASH SUPPORT PROCESS

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. 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'. 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. 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. 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. Details on the type and version of the ECUs bootloader (e.g. Vector SLP6, Vector SLP9, Supplier developed, etc.).

Checksum and Checksum Calculation Info

Compression and Encryption (if used)

Signature Information

Flash Part Number Definition

Bootloader Details

2. Flash Files File Required Erase SWIL File Program SWIL File Description The source .s19, .s28, .s37, or .hex file that contains the Erase SWIL (Software Interlock) if supported by the ECU. The source .s19, .s28, .s37, or .hex file that contains the Program SWIL (Software Interlock) if supported by the ECU. 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,

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

Global Service Diagnostics Copyright 2008 Chrysler LLC

5 of 7

Release Version: 1.4 Release Date: 2 July 2008

CDA NEW ECU FLASH SUPPORT PROCESS

1A 9C, 1A 9D, 1A 9E, etc.). 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.).

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

3. Flash Documents Document Required ECU Connector Pinout / Wiring Diagram Description 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. 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 of the flash process using supplier or other flash applications if available (e.g. Vector CANflash).

ECU Paper Unlock Algorithm Submission Form

Flash Trace Bus Log

Global Service Diagnostics Copyright 2008 Chrysler LLC

6 of 7

Release Version: 1.4 Release Date: 2 July 2008

CDA NEW ECU FLASH SUPPORT PROCESS

APPENDIX B HARDWARE REQUIREMENTS

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 o o o o ECU Acronym Supplier Diagnostic Variant Jira issue number for ECU flash support request (e.g. EEFS-23) ECU Release Engineer contact information

Choose one of the following methods for delivery: o o Hand-deliver the ECU hardware and harness to the drop box located at Nick Latorres desk in the Global Service Diagnostics department, CTC suite S2023, Pole #2 S8 W20. Ship the ECU hardware and harness to: Nick Latorre c/o V2Soft, Inc. 2619 Product Dr. Suite 102 Rochester Hills, MI 48309

Global Service Diagnostics Copyright 2008 Chrysler LLC

7 of 7

Release Version: 1.4 Release Date: 2 July 2008