FORScan forum

Software scanner for Ford, Mazda, Lincoln, Mercury vehicles Search…  

 Quick links  FAQ  Notifications  Private messages aloneraja 

 Board index ‹ English & International forums ‹ Beta testing

How to update module firmware with FORScan

Locked    Search this topic…   21 posts 1 2 3 

How to update module firmware 

FORScan
Site Admin
with FORScan
Posts: 2922
 by FORScan » Tue Jun 22, 2021 2:29 pm Joined: Fri Jun 13, 2014 5:21 am

Table of contents

Glossary
1. Internals
1.1. Introduction
1.2. Flash memory and firmware update process
1.3. Network of modules
1.4. “Assy” concept, part numbers and calibration level
1.5. Mazda specifics for part numbers
2. Module firmware update function (MFU) in FORScan
2.1. General function organization
2.2. Work area
2.3. Options pane
2.4. Buttons pane
3. Programming guide
3.1. Preparation
3.2. Programming time
3.3. Application and adapter settings
3.4. Firmware database
3.5. Current firmware backup
3.6. Firmware update process
4. Troubleshooting
4.1. Firmware has not been uploaded
4.2. Firmware uploaded successfully, but module doesn't work
4.3. Problems with firmware database
4.4. Recovery mode


Glossary 
FORScan
Site Admin
 by FORScan » Tue Jun 22, 2021 2:29 pm
Posts: 2922
Joined: Fri Jun 13, 2014 5:21 am
"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

Back to contents


1.1. Internals: Introduction  FORScan

Site Admin
 by FORScan » Mon Jul 05, 2021 3:36 am
Posts: 2922
First generation FMFU function appeared in Ford cars equipped with EEC-V ECU Joined: Fri Jun 13, 2014 5:21 am
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.

Back to contents


1.2. Internals: Flash memory and  FORScan

Site Admin
firmware update process
 by FORScan » Sun Jul 11, 2021 2:07 pm Posts: 2922
Joined: Fri Jun 13, 2014 5:21 am
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:
 Picture 1a. FMFU memory organization

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

Back to contents


1.3. Internals: Network of modules 

FORScan
Site Admin
 by FORScan » Mon Jul 26, 2021 6:05 am
Posts: 2922
Modules communicate with each other through networks. First programmable Joined: Fri Jun 13, 2014 5:21 am
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).
Back to contents


1.4. Internals: Ford “assy” concept, 

FORScan
Site Admin
part numbers and calibration level
Posts: 2922
 by FORScan » Sun Aug 22, 2021 8:29 am
Joined: Fri Jun 13, 2014 5:21 am
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.

Back to contents


1.5. Internals: Mazda specifics for part 

FORScan
Site Admin
numbers
Posts: 2922
 by FORScan » Sun Aug 22, 2021 9:39 am
Joined: Fri Jun 13, 2014 5:21 am
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

Back to contents


2.1. MFU in FORScan: General function  FORScan

Site Admin
organization
Posts: 2922
 by FORScan » Tue Aug 24, 2021 3:20 am
Joined: Fri Jun 13, 2014 5:21 am
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:

Picture 2a. FMFU function screen in FORScan

These areas are reviewed below in more details.

Back to contents


2.2. MFU in FORScan: Work area 

FORScan
Site Admin
 by FORScan » Wed Aug 25, 2021 5:40 am
Posts: 2922
Work area is designed to display information about firmwares and also let user Joined: Fri Jun 13, 2014 5:21 am
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:

 Picture 2b. FMFU 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:
 Picture 2c. FMFU Available firmware selector

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:
 Picture 2d. FMFU Custom mode

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).
Back to contents


2.3. MFU in FORScan: Options pane 

FORScan
Site Admin
 by FORScan » Fri Aug 27, 2021 4:29 am
Posts: 2922
Options pane represents 3 options: Joined: Fri Jun 13, 2014 5:21 am

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:
 Picture 2e. FMFU Force program unchanged firmware 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.

Back to contents


Locked      21 posts 1 2 3 
 Return to “Beta testing” Jump to 

WHO IS ONLINE
Users browsing this forum: aloneraja and 0 guests

 Board index  The team  Members  Delete cookies All times are UTC+03:00

Powered by phpBB® Forum Software © phpBB Limited

Privacy | Terms