Professional Documents
Culture Documents
A guide on the process to request CDA flash application support for new ECUs
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).
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.
2 of 7
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).
3 of 7
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
4 of 7
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.).
Signature Information
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)
5 of 7
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).
6 of 7
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
7 of 7