FORScan forum

"Bricked" module - module that was programmed unsuccessfully and doesn't run properly after reboot. Module remains programmable so can be recovered with proper programming in 99% of cases

EEPROM- Electronically Erasable Programmable Read-Only Memory

FEPS - Flash EEPROM Programming Signal (18V on pin 13 of the OBDII connector, reguired for old ECU programming)

FMFU - Ford Module Firmware Update process

MCU - Microcontroller Unit

MFU - Module Firmware Update process

PBL - Primary Boot Loader

ROM - Read-Only Memory

SBL - Secondary Boot Loader

First generation FMFU function appeared in Ford cars equipped with EEC-V ECU long time ago - at the end of 1990s. it was only available for PCM and TCM and required special FEPS signal support. Second generation appeared in the middle / second half of 2010s when Ford developed its Generic Global Diagnostic that is still in use. Starting from 2010-2011 model year, many of Ford modules have the FMFU. And in newest cars almost all modules can be reprogrammed. In 2020MY Ford introduced Over-The-Air (OTA) updates that can be counted as third generation.

Mazda prior to 7G (2019+MY Mazda 3/CX-30) implements the same FMFU functions as Ford, but in less amount: even last generation of Mazda only supports FMFU for PCM and TCM, and very few of other modules. At this moment there is no information about MFU implementation in 7G models.

By this moment FORScan only implements second generation of FMFU for Ford and Mazda cars. So this document also describes only 2nd generation. Implementation for the 1st generation is still in progress.

Every module is an electronic unit managed by a microcontroller (MCU), kind of small computer. Module has a flash memory that keeps executable code and program data. These code and data are represented by firmware files. Figure 1a explains how it may look like:


Division by ROM and EEPROM illustrated on this picture is conditional and relative to Ford Module Firmware Update process (FMFU). Both ROM and EEPROM segments are located in MCU Flash memory, but ROM segments are not available for reprogramming within FMFU. Also, the picture is simplified: there can be several ROM segments that may split EEPROM segments.

First block is always a Primary Boot Loader (PBL). PBL is usually hardcoded in ROM and cannot be reprogrammed. Its' goal is to launch (get control) when module is powered on and then load the application – executable that implements main module functionality. It also implements some basic functions to communicate with dealership equipment.

Application that implements the core module function (engine management for PCM, brake control for ABS etc) is represented by a firmware file called “Strategy”. Other firmware files contain data necessary for the work process of the application. Data can be represented by different type of firmware - “Calibration”, “Configuration” etc. For example, IPC images are stored in Calibration firmware, and BCM settings are stored in Configuration files.

Normal boot process works as the following:

1. Power is on, module MCU runs PBL
2. PBL tries to find and launch an application (executable)
3. If application is launched properly, module is online in normal mode of work.

In normal mode of work FMFU functions are not available. In order to start FMFU, module has to be switched to special programming mode and Secondary Boot Loader (SBL) has to be loaded into the RAM by diagnostic equipment. SBL unlocks flash EEPROM erase and reprogramming functions.

Normal firmware update process with FORScan works as the following:

A. Module is in normal mode of work, FORScan switches it to special programming mode, loads SBL into module memory and launches it.
B. FORScan is starting to program firmware file #1:
  B.1. Open and analyse the firmware file . Firmware file contains one or more blocks.
  B.2. Erase a part of module’s flash memory dedicated to this firmware file
  B.3. Upload firmware file by blocks. First block is uploaded as the following:
    B.3.1. Request start of the block upload from the module. Module confirms the upload and returns size of data packet size that has to be used for the upload.
    B.3.2. Send the block data in packets of required size. Module has to confirm receiving every packet.
    B.3.3. When the block is transferred, module returns a checksum of the received data, and FORScan compares it with the checksum available in the firmware file.
  B.4. If firmware has more than one block, all subsequent blocks are uploaded in exactly the same way (steps B.3.*)
C. If more firmware files are available, they are loaded in the same way and run all the same steps (B.1…B.3).
D. When all of the firmware files are uploaded, FORScan asks the module if a valid application is available and shows result to user, then exit the programming mode.

Note: the “upload/download” terms are a bit tricky because may be used differently. It depends on how the items are “stacked”: if scanner is on the top and module is on the bottom, the process of the programming is called “downloading”, because it “flows” down. If module is on the top and scanner is on the bottom, process is called “uploading”, because it “flows” up. We consider that scanner is down so we call it “uploading”.

Modules communicate with each other through networks. First programmable modules used Ford SCP (SAE J1850 PWM) bus. In more new models CAN buses are used. If modules are settled on different buses, special gateways are used to route the traffic. In older models one of modules played a role of gateway. In last generation of cars dedicated gateways are used.

The following things are important for FMFU:

1. Different bus have different speed. MS-CAN is 4 times slower than HS-CAN, thus programming will be up to 4 times longer.
2. Some modules are reachable and programmed not directly, but through a gateway.
3. In many cases it is required to stop internal communication between modules ("Stop activity on buses" checkbox).

Manufacturer does consider every module to be an assembly (“assy”) that includes hardware and firmware.

Assembly has a part number that usually matches to the module part number we use to order this module by the spare part catalogue. Part number has the following format:

JK2T-14G371-FCC, where JK2T is a prefix, -14G371- is a core, FCC is a suffix.

Core part identifies type of the item and usually quite stable between versions. For example, -12A650- always mean PCM assembly, no matter if it is 2001MY PCM or 2020MY PCM. Prefix is some internally generated number that specifies a family of the part. Suffix is also some internally generated number that specifies version of the part.

The part numbers are real numbers, but formed using not only digits (0..9) but also capital letters (A..Z), with some exceptions (for example, I,O,W letters aren’t used). This is quite important understanding, because it explains how numbers depend on each other. For example, if we have these 3 numbers:

JK2T-14G371-FDA
JK2T-14G371-FDB
JK2T-14G371-FDC

We know that these numbers are very close to each other: A+1=B, B+1=C. So *-FDB is next version after the FDA and FDC is next version after FDB. General rule is that newer versions have greater numbers. It should be however noted that comparing numbers doesn’t give us enough information about compatibility between versions. If difference is only in last letter, then it usually means part of the same branch and most likely the parts are compatible. But even difference in penultimate symbol may mean completely different module of another manufacturer with another hardware.

Hardware and every firmware file also have their own part numbers. Assembly build number usually (but not always) depends on internal components. If one of components (hardware or firmware) is changed, the assy number is also changed. However, not all components directly participate in the assy number. Hardware, Strategy and Calibration usually directly form the assy number, but several assies with the same number may contain different configuration files.

Assembly number concept mentioned above (when assy number is a derivative of all software and hardware numbers) is great but has two serious problems: it doesn't work for some modules for different reasons and technically it cannot be changed after firmware update (so programmed once on the factory). Both problems make recognition of actual module version quite difficult. To resolve this problem, Ford uses a “Calibration level” term. In short words, the “Calibration level” means a "virtual" assy number but dynamically calculated from counting all the firmware in module memory. On some new modules it can be read directly from ECU, but in majority of cases it has to be calculated on the fly.

Mazda uses the same principle, but there are some specifics. In addition to to reduced MFU functionality (it's only implemented for certain modules), there are other small differences.

First of all, Mazda uses different numbers (of course). For example, if Ford PCM has -12A650- core for PCM, Mazda has -18881- core for the same.

Second difference is that Mazda has no strong rules for suffixes. Numbers may have no suffix at all, for example:

L3DT-18881-

or be funny, like this:

GHR1-437AS-3-00

in this case suffix is "3-00", where (we guess) 3 is version and 00 is subversion. So different versions of the same module look like this:

GHR1-437AS-3-00
GHR1-437AS-3-10
GHR1-437AS-3-20
GHR1-437AS-3-30
GHR1-437AS-3-40
GHR1-437AS-3-50
GHR1-437AS-3-60
GHR1-437AS-3-70
GHR1-437AS-3-80
GHR1-437AS-3-90

Module firmware update function in FORScan is implemented separately for every module. There is no functionality for group firmware updates: if some modules have to be updated in pair (ex. PCM + TCM), user has to perform it one by one.

Module firmware update function is displayed in Configuration and Programming section, for every module it is supported for. Function is displayed if the following conditions are in place:

1. FORScan has identified the module (read assy number and found it in the database)
2. FORScan supports FMFU for this module.

So if there is no MFU function displayed for some module, it means that FORScan is either unable to identify it for some reason, or programming for this module is not yet supported.

After FMFU function has been started, FORScan adds the "Module firmware update" tab at the top of the application Windows, in addition to standard tabs such as Log. This tab and its screen displays the work area for FMFU. Progress, status and other information during the operation of FMFU function are displayed in the Log screen. FORScan switches between Log and MFU tabs when necessary, to better inform users about the status of this process.

MFU function screen in FORScan contains of 3 areas: Work area, Options pane and Buttons pane as illustrated on Figure 2a:


These areas are reviewed below in more details.

Work area is designed to display information about firmwares and also let user select proper firmware files. It is a table containing of four columns that represent the following information (from left to right):

1. Item name and information
2. Current firmware in module (that is currently programmed)
3. Selected firmware to be uploaded to the module
4. Item status, additional information and controls

Figure 2b shows an example of work area:


Data are provided in rows. First row is always Part Number (Assembly number) read from module, second row is Calibration Level (meaning for these numbers explained in section 1.4. Internals: Ford “assy” concept, part numbers and calibration level. Third row is always hardware Id, fourth row is always SBL. Fifth and further rows represent module firmware files. End number of rows depends on number of firmware available for this module.

First column represent the following information for firmware files:

• type of the firmware file: Strategy, Calibration, Configuration....
• interface type (CAN, USB...)
• firwmare file data identificator (DID) used by Ford.

Second column displays current state of the module: firmware files that have been programmed to the module at this moment.

Third column shows "To program" values, so firmware files that will be uploaded to the module. Top cell contains selector of programming modes. Three modes are presented by this moment:

• Available - FORScan offers compatible firmwares of the same branch that can be uploaded
• Factory - FORScan offers firmware that is factory installed for this module. In order to implement this feature, FORScan needs to load factory As Built Data (*.AB) file, so internet connection is required. If AB file doesn't contain information about this module firmware, this function will not work
• Custom - FORScan allows to select any programming files manually. In this mode files cannot be downloaded in automated mode, so user have to prepare it manually.

Second cell in third row allows to select calibration level of the firmware (only in Available mode) as illustrated on the Picture 2c:


Compatibility of firmwares calculated using quite complex algorithm, more information can be found in section 3.4. Programming Guide: Firmware database.

In Custom mode user has to press 3-dot button to open filename entering/file selection dialog as illustrated on the Picture 2d:


Note that by default files are filtered out by the core part, but user can select *.VBF in the filter below and select any file (dangerous!).

Last, fourth, column contains additional control and information elements:

• 3-dot button - used for manual files selection, unlocked only in Custom mode
• color square - represents current state of the firmware file (see below)
• depending on status of file: either status information, or size of firmware file in bytes.

Possible firmware file states:

• Green - file is available on disk and will be uploaded
• Red - file is not available on disk and needs to be downloaded
• Yellow - file will not be uploaded for some reason: either it is not supported by current programming method, or ignored (if "Force program unchanged firmware" checkbox is unchecked).

Options pane represents 3 options:

1. Force program unchanged firmware.

FMFU procedure was designed to be as much flexible as possible. It means, in particular, that firmware files can be uploaded separately. So user can upload, for example, only Configuration or Calibration and upload not Strategy file that remains the same. So, if this option is unchecked, FORScan compares current and new firmware files and program only files that have been changed. Picture 2e illustates how the screen may look if the option is unchecked:


In this specific example we see that although Calibration Level is quite different, in fact all firmware files are the same and there is no sense to reprogram it. The only file that is different here is Image (USB, 8033) that cannot be programmed by FORScan so ignored.

The problem is that in real world many modules require all files to be uploaded at once. If we program not all of files, such a module may be "bricked". So by default FORScan has this option enabled for all modules. We strongly recommend to keep this checkbox enabled unless you know a good reason to uncheck it.

2. Stop activity on buses

If this option is set, FORScan sends broadcast messages to all networks to inform every module that we are starting a programming procedure. This way FORScan switches networks to the special service (programming) mode. Then, while programming is being performed, FORScan continues to hold networks in this service (programming) state. Depending on the adapter used, FORScan may or may not be able to hold only one or all networks. This option is enabled by default and recommended to remain enabled, as some modules programming cannot be peformed well without it.

3. Recovery mode

This checkbox is used to activate special Recovery mode. It may be helpful in case of programmed module runs into "dead loop" or frozen state, so doesn't respond to any commands. More detailed description of the use case can be found in section 4.4. Troubleshooting: Recovery mode. If "Recovery mode" option is used, "Stop activity on buses" option is disabled as these options are mutually exclusive. User does NOT need to use this mode in case of simply "bricked" module. By default, this option is disabled.