FDRS Module Programming Job Aid (24-7011)

FDRS MODULE PROGRAMMING JOB AID

TECHNICAL SERVICE BULLETIN

MARKETS

North American markets only

SUMMARY

This article provides support for module programming related concerns that may be encountered while using the FDRS  scan tool. The information contained within this article assumes that all steps of the service repair process have been completed, including documenting the vehicle owner's current concern, reviewing TSB, SSM, FSA  and the WSM  . This document does not supersede or replace existing publication or warranty direction.

SERVICE INFORMATION

SERVICE FUNCTIONS

Service functions refer to any application within FDRS  that might complete a learning routine, calibration, or initialization. These routines include things like LIN  new module initialization, ABS HCU  pressure bleed, and camera alignments. These routines, from a high-level point of view, are not VIN  -specific. These routines operate in a manner where FDRS  instructs the responsible module on the vehicle to execute the routine. FDRS  simply sends a go command to the module. The module will then perform the routine as it is coded to do. The most common causes for a service function errors are damaged circuits or components involved in the system. For example, if a BCM LIN  initialization routine fails, it is possible that a fault on the LIN  network or a fault with the LIN  device is the cause. A fault with the FDRS  scan tool application could be ruled out by running it on another similarly equipped VIN  since these applications are not VIN  -specific.

MODULE SWAPPING AND ORDERING USING A DIFFERENT VIN

Swapping a used module from a vehicle for diagnostic purposes or to complete repairs is likely to cause vehicle symptoms or programming errors and is not recommended. Ordering a replacement module using a VIN  from a different vehicle is also not recommended. Most modules on these affected vehicles are VIN  /vehicle specific, and hardware variations between modules do exist. Swapping a module from a vehicle or ordering a module using a different vehicle/VIN  can cause ineffective repairs and additional vehicle downtime. Make sure all appropriate WSM  procedures are followed when diagnosing the condition before any module replacements and only order modules using the correct VIN  .

ADDING/REMOVING FEATURES USING PROGRAMMABLE PARAMETERS DUE TO VEHICLE MODIFICATIONS

Ford and Lincoln vehicle owners may request modifications to their vehicle such as enabling DRL  , adding navigation, changing tire/axle sizes, and/or adding trailer brake control modules. A list of programmable parameters that are available for alteration is shown in WSM  , Section 418-01A > Module Configuration. Parameters available for alteration will vary by model and model year. If the desired parameter is not listed in the right column of the Module Configuration And Parameter Chart, alteration of that parameter is not supported by Ford Motor Company. A list of supported parts that can be added to the vehicle is available at accessories.ford.com. Adding/removing accessories and/or programming vehicle features is not warrantable.

MODULE SERVICE REPLACEMENT PARTS

The FDRS  service scan tool functionality is largely based on the part number of the individual modules installed in each vehicle. If an incorrect module has been fitted to a vehicle, application and programming errors are likely. If a fault is occurring only on a replacement module, it is recommended that the installed part be verified as compatible by VIN  using the Historical Vehicle Bill of Material (HVBoM), the Ford ECAT parts catalog or Ford Component Sales (FCS) online 1878 form (for infotainment modules). The first digit of the prefix in a part number indicates the model year that the part was intended for, identical to the 10th digit of the VIN  .

• Example: MU5T-15604-A. The M indicates that this part is intended for a 2021 model year vehicle.
• Example: LU5T-15604-B. The L indicates that this part is intended for a 2020 model year vehicle.

Most often, replacement modules should share the same part number as the one which the vehicle was built with according to HVBoM, or a later level part found in ECAT or FCS 1878 order forms. For example, a 2021 model year vehicle built with an M prefix part should usually not receive an L prefix part from 2020 model year. This is a general rule for module part numbers and there are few exceptions. Other vehicle parts may not have the same model year correlation to their part numbers.

Module parts are often superseded and intended to be made backward compatible, though. For example, a 2021 model year vehicle built with an M prefix part may receive a superseded part with a prefix that begins with N for the 2022 model year.

MODULE COMMUNICATION

The vast majority of FDRS  functions require communication between the FDRS  scan tool and one or more modules on the vehicle via the CAN  . CAN  and module communication related concerns should be addressed before programming is attempted. Programming while a CAN  issue is present may result in damaged modules, unnecessary vehicle downtime and unnecessary warranty expenditure. This article will not discuss in depth how network diagnostics should be performed but will focus on a few key concepts as they relate to module programming. Diagnostics for network concerns should be performed per the direction in the WSM  .

• On SYNC 4 equipped vehicles, certain modules are programmed between both the CAN  and USB  drive. These modules often include the infotainment modules such as the APIM, TCU, GWM  and/or high level IPC  . USB  port, USB  cable, ethernet network or CAN  faults may contribute to programming errors.
• For all other modules on SYNC 4 or previous generations of vehicles, programming is performed over the CAN  . Module or network communication faults will contribute to vehicle symptoms and programming errors.
• A module needs three things to communicate properly on the CAN  and with the FDRS  scan tool: power to the module, ground to the module, and the CAN  wiring.
• The FDRS  Network Monitor application will ping each module or network enabled in the test and make sure that FDRS  receives a response from the module, proving that communication is likely ok.
• Running the on-demand DTC  self-tests will stress test the module communication by forcing the module to activate outputs during the test. Modules failing or aborting the on-demand DTC  self-test (grey in color) suggests that the power, ground, or CAN  wiring may be damaged.
• Modules that respond negatively (purple in color) suggest that the module is communicating but may have failed a previous programming attempt, possibly due to a module or network related communication concern.

When the customer's symptoms, DTC  s, and any programming errors present themselves like a possible network concern, it is recommended to not only rely on self-test and network monitor results. These tests are great go/no-go type tests. However, due to network fault tolerance, these tests may pass and suggest that the network is OK. However, module programming often transmits significantly more data over the network than these tests, increasing the odds of an error only during programming. It may be necessary to perform loaded voltage drop testing on all of the module's power and ground circuits. The VCMM  oscilloscope is a powerful tool for verifying the integrity of the CAN  itself. Known good network waveforms are available in WSM  , Section 418-00x and additional information regarding VCMM  usage and setup can be found in STARS  training.

The below example demonstrates a VCMM  capture (Figure 1) of an HS-CAN  network which is being shorted to ground (0.0v) but that the HS-CAN  modules are communicating (green in color) with FDRS  via the ALL CMDTC  test. This example demonstrates the potential need to take network diagnostics further than running a network test or self-test.

IDENTIFYING A PROGRAMMING RELATED CONCERN

Vehicle repairs have taken on additional complexity over the last decade. Many repairs include the need to complete module replacement programming, learning, or calibration routines. With repairs being so reliant on scan tools, it is critical to understand how the scan tool functions and when a vehicle symptom may result from a programming error. Determining when a vehicle symptom is programming-related is not always an easy task. It often requires a thorough understanding of the entire service repair process for the vehicle in question. A few of the key things to look for in the service process include:

• Original concern vs. current concern
  • If a vehicle came in for service for the same concern that is present after module replacement or programming, this is unlikely to be a programming-related issue.
  • The concern may be programming-related if a new DTC  or symptom is present only after performing module programming or replacement. Verify that all installation steps per the WSM  have been completed properly. If the issue remains, it is likely that the module was flashed or configured incorrectly and requires support from the module programming team.
• DTCs 
  • Replacement modules have default or manufacturer substate DTC  s stored that indicate they require programming, initialization, and/or calibration routines completed. If the same DTC  the vehicle entered service with returns on the replacement, the concern is unlikely to require module replacement or programming. Most replacement modules will only store DTCs related to the steps required in the installation process, not circuit or performance related DTC  s.
  • DTCs  stored for components which the vehicle is not equipped with per the build sheet and/or window sticker may suggest a programming-related concern. In some cases, a module may still have wiring for the component it is not equipped with and may still monitor for circuit faults. If the wiring is present, it should still be inspected, particularly for shorts to voltage or ground. These types of circuits are usually expected to be open.
• Service messages
  • Review all available service messages that may relate to both the customer's original concern, current concern, and the programming error being encountered.
• Intermittent vs hard faults
  • Modules are either programmed correctly or incorrectly. If the module is programmed incorrectly, the symptom or DTC  will always be present. Intermittent DTC  s suggest that a vehicle-side concern in wiring, connectors or components may be present.

12-VOLT BATTERY TESTING, CHARGING, MAINTENANCE AND STATE OF CHARGE FOR MODULE PROGRAMMING

FDRS VEHICLE IDENTIFICATION PROCESS

Starting a vehicle session requires the user to select the Read VIN From Vehicle button in FDRS  . Once the Read VIN From Vehicle button is selected, FDRS  will read the VIN  via the CAN  from the PCM  using OBD  -II protocol from PCM  Mode 09 data. The PCM  will report the VIN  to FDRS  , which displays it in the VIN  entry box. The user will then select Go, at which time FDRS  will retrieve a vehicle model from the servers for that VIN  , including which modules are equipped, the powertrain type, and the vehicle program information. This process occurs while FDRS  displays a progress bar stating, Downloading Vehicle Information. Once obtained, FDRS  will perform a network test on the vehicle and read the part numbers and DTC  in all equipped modules.

MODULE PROGRAMMING PRE-CHECKS

• Verify that the 12-volt battery is maintained between 12.6 volts and 13.6 volts using approved Rotunda tools, including the GRX-3590 or DCA-8000 units. Refer to the 12-Volt Battery Testing, Charging, Maintenance And Sate Of Charge For Module Programming section in this article for additional recommendations and testing.
• Verify that the BCM  Battery State of Charge % (BATT_SOC%) PID  is reading 75% or greater. Refer to the 12-Volt Battery Testing, Charging, Maintenance And Sate Of Charge For Module Programming section in this article for additional recommendations and testing.
• Inspect the vehicle for possible aftermarket electronic accessories that may be connected to the vehicle's network wiring. These devices may include remote start kits, GPS  devices, radios, alarms, insurance dataloggers, gauge packs/pods, and hotspot devices. They may be located on or near the kick panels, dash A-pillars, glove box, center console, or near the DLC  .
• Verify that accessory loads are off, including headlamps, heated/cooled seats, and the climate control system blower motor.
• Verify that the scan tool and vehicle communication interface are at the latest available software levels. The latest levels of each can be downloaded from PTS > Rotunda tab > Diagnostic Tool Support > Download Software.
• Verify that if a module has been replaced, that the correct replacement part has been installed. Refer to the Service Replacement Parts section in this article.
• Verify that the module is properly communicating. Refer to the Module Communication section in this article.
• Verify that service messages (PTS Alerts, TSB, SSM  , etc) have been reviewed, not only for the customers original vehicle concern but also for messages which might be related to the programming being attempted.

MODULE PROGRAMMING ERRORS AND TROUBLESHOOTING