ST AN1577 Application note

AN1577

APPLICATION NOTE

DEVICE FIRMWARE UPGRADE (DFU) IMPLEMENTATION IN

ST7 USB DEVICES

by Microcontroller Division Applications

1 INTRODUCTION

This application note p resents th e imple mentation of a Device Firmw are Upg rad e (DF U) ca­pability in ST7 USB microcontrollers. It follows the DFU class specification defined by the USB
Impleme nters Forum , for reprog ramm ing an app licat ion throu gh USB . The DFU prin ciple is
particularly well suited to USB applications that require need to be reprogrammed in the field:
The same USB connector can be used both for the standard operating mode, and for the re­programming process.

This operation is made possible by the IAP capability featured by mos t of the ST7 mi crocon­trollers, which allows a FLASH MCU to be reprogrammed by any communication channel
(Please refer to AN1575 for more details).

The DFU process, like any other IAP process, is based on the execution of firmware located in
Sector 0 of the ST7 Flash memory which manage the Flas h operations (erasing and pr ogram­ming) of Sectors 1 and 2.

This application note covers then two main aspects:
The firmware located in Sector 0,
The Interface between the firmware in Sector 0 and the firmware in Sectors 1 & 2.
The proposed implementation is demonstrated with 2 different projects: the USB Low -Speed

devices Evaluation Kit and the ST7265 Full-Speed 5-in-1 demoboard. In this document these

projects are referred to as “LS project” and “FS project”.
A basic DFU protocol is also used in these projects. The modular approach used in the imple-

mentation based on a DFU library allows you to adapt it easily to other higher level protocols
or new types of hardware.

AN1577/0103 1/30

1

DEVICE FIRMW ARE UPGRADE (DFU) IMPLEMENTAT ION IN ST7 USB D EVICES

1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 DFU CLASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 INTRODU CTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 PHASES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 REQUESTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 ENUMERA TION PHASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4.1 Run-Time Descriptor Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.2 DFU Mode descriptor Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5 RECONFIGURATION PHASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.6 TRANSFER PHASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6.1 Downloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6.2 Up loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.7 MANIFEST AT ION PHASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 DFU IMPLEMEN TATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 FIRMWARE ORGANIZATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 DFU MEC HANISM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 FLASH SECTOR MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.1 SECTOR 1 AND 2 INTEGRITY CHECK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.2 LIBRARY FUNCTIONS CALLED BY THE APPLICATI ON . . . . . . . . . . . . . . 10

3.3.3 APPLICATION FUNCTIONS CALLED BY THE LIBRARY . . . . . . . . . . . . . . 11

3.3.4 JUMP TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4 RAM MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4.1 SHARED VARIABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4.2 LOCAL VARIABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4.3 OVERLAP AREA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4.4 STACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5 DESCRIPTOR S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5.1 STANDARD DESCRIPTORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5.2 DFU DESCRIPTORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.5.3 DFU STRING DESCRIPTORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.6 PROTOC OL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.6.1 DOWNLOAD STRATEGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.6.2 wBLockNum VALUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2/30

2

DEVICE FIRMW ARE UPGRADE (DFU) IMPLEMENTAT ION IN ST7 USB D EVICES

3.7 HARDWARE CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.7.1 VPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.7.2 FORCED DFU MODE ENTRY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.8 HDFLASH DRIVERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.8.1 FUNCTIONS USED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.8.2 STACK AND RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 DFU LOW-SPEED PROJECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 DIRECTOR IES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 DFU FILES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 DFU CALL-BACK FUNCT IONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4 OTHER DF U F UNCTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.5 DFU VARIABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6 RESTRICTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 DFU FULL-SP EED PROJECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 DIRECTOR IES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2 DFU FILES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3 DFU CALL-BACK FUNCT IONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.4 OTHER DF U F UNCTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.5 DFU VARIABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.6 RESTRICTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 RELATED DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 RELATED SOF TWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8 TERMS AND ABBREVIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3/30

1

DEVICE FIRMW ARE UPGRADE (DFU) IMPLEMENTAT ION IN ST7 USB D EVICES

2 DFU CLA SS

2.1 INTRODUCTION

The DFU class uses the USB as a communication channel between the ST7 and the program­ming too l, gen era l ly a P C hos t . T he D FU cl ass spe cif ica tion st ate s t ha t, a ll the c om man ds ,
status and data exchanges have to be performed through Control Endpoint 0. The command
set, as well as the basic protocol are also defined, but the higher level protocol (Data format,
error message, ..) remain vendor specific. This means that the DFU class does not define the

(.s19

, .

hex

format of the data transferred

2.2 PHASES

There are four distinct phases required to accomplish a firmware upgrade:

1. Enumeration: The device informs the host of its capabilities. A DFU class-interface de-

scriptor and as sociated fun ctional descriptor embedde d within the de vice’s no rmal run-ti me
descriptors serve this purpose and provide a target for class-specific requests over the control
pipe.

, pure binary, etc...).

2. Reconfiguration: The host and the device agree to initiate a firmware upgrade. The host is ­sues a USB r eset to the device , and the device the n expo rts a seco nd set of de script ors in
preparatio n for the Tra nsfer ph ase. This dea ctivat es the run- time dev ice driver s associ ated
with the device and allows the DFU driver to reprogram the device’s firmware unhindered by
any other communications traffic targeting the device.

3. Transfer: The host transfers the firmware image to the device. The parameters specified in
the functional desc riptor are used to ensure corr ect block sizes and ti ming for programm ing
the nonvolatile memories. Status requests are employed to maintain synchronization between
the host and the device.

4. Manifestation: Once the d evice repo rts to t he ho st t hat it has com plet ed the rep r ogram -
ming operations, the host issues a USB reset to the device. The device re-enumerates and ex­ecutes the upgraded firmware.

To ensure that only the DFU driver is loaded, it is considered necessary to change the

Product

DFU driver will be loaded in cases where the operating system simply matches the vendor ID
and product ID to a specific driver.

LS project Example: the Product ID of the Evaluation Kit with the DFU class is the FF03h and
0003h for the standard Evaluation Kit without the DFU.

field of the device when it enumerates the DFU descriptor set. This ensures that the

id-

4/30

DEVICE FIRMWARE UPGRADE (DFU) IMPLEMENTATION IN ST7 USB DEVICES

2.3 REQUESTS

A number of DFU class-specific requests are needed to accomplish the up grade operations.
The following table summarizes the DFU class-specific requests.

Table 1. Summary of DFU Class-Specific Requests

bmRequestType bRequest wValue wIndex wLength Data

00100001b

00100001b

10100001b

10100001b

00100001b

10100001b

00100001b

DFU_DETACH
(0)

DFU_DNLOAD
(1)

DFU_UPLOAD
(2)

DFU_GETSTATUS
(3)

DFU_CLRSTATUS
(4)

DFU_GETSTATE
(5)

DFU_ABORT
(6)

wTimeout Interface Zero None

wBlockum Interface Length Firmware

Zero Interface Length Firmware

Zero Interface 6 Status

Zero Interface Zero None

Zero Interface 1 State

Zero Interface Zero None

For additional information about these requests, please refer to the DFU Class specification.

2.4 ENUMERATION PHASE

A device with DFU capability must be able to be enumerated in two ways by the host:

- As a single device with only DFU capability.

- As a composite device: HID, Mass storage, or any functional class, and with DFU capability.
During the enume ration ph ase, the d evice exposes two di stinct and indep endent de scriptor

sets, one each at the appropriate time:

- Run-time descriptor set: shown when the device performs normal operations.

- DFU mode descriptor set: shown when host and device agree to perform DFU oper ations.

5/30

DEVICE FIRMW ARE UPGRADE (DFU) IMPLEMENTAT ION IN ST7 USB D EVICES

2.4.1 Run-Time Descriptor Set

During normal run-tim e operation, the dev ice exposes its normal set of desc riptors plus two
additional descriptors:

- Run-Time DFU Interface descriptor

- Run-Time DFU Functional descriptor
Note: The number of inte rfaces in each configuration des criptor that supports the DFU must

be incremented by one to accomodate the addition of the DFU interface descriptor.

2.4.2 DFU Mode descriptor Set

After the ho st and th e d evic e a gree to p erform D FU ope ra tions, th e h ost re-enu mer ates the
device. At this time the device exports this descriptor set:

- DFU M ode Device descrip tor

- DFU Mode Configuration descriptor

- DFU Mode Interface descriptor

- DFU Mode Functional descriptor: identical to the Run-Time DFU Functional descriptor
For detail information on these descriptors see the

tion

.

USB Device Firmware Upgrade Specifica-

2.5 RECONFIGURATION PHASE

Once the operator has identified the device and supplied the filename, the host and the device
must negotiate to perform the upgrade.

An example of negotiation could be as follows:

- The host issues a Vendor Specific request containing a key (optional).

- The device checks the key received and sends back a status on the acknowledgement of the
flash read or write request.

- If the host receives a negative acknowledgement then the host aborts the firmware upgrade.
otherwise the following operations are performed:

- The host issues a DFU_DETACH request to Control Endpoint EP0.

- The host issues a U SB reset to the device. This USB R eset is not possible on some Windows
versions. To by pass this issue, the USB reset is per formed by the devi ce (USB regu lator is
powered-off then powered-on).

- The device enumerates with the DFU Mode descriptor set, as described above.
To support entering the transfer phase, a variable mapped in RAM keeps the DFU_DETACH

request status: DETACH received or not

6/30

DEVICE FIRMWARE UPGRADE (DFU) IMPLEMENTATION IN ST7 USB DEVICES

When a USB reset signal is received, the USB reset interrupt routine checks this variable. If a
DETACH has previously been received, the device exports the DFU Mode descriptor set, oth­erwise it exports its normal run-time descriptor set.

2.6 TRANSFER PHASE

The Transfer phas e begins after the device has processed the USB reset and exporte d the
DFU Mode descriptor set. Both downloads and uploads of firmware can take place during this
phase. This transfer phase consists of a succession of DFU requests according to the state di­agram defined in the DFU Class specification (Fig A1 page 26).

2.6.1 Downloading

The host slices the firmware image file into N pieces and sends them to the device by means
of control-write operations in the default endpoint (Endpoint 0).

The maximum number of bytes that the device can accept per control-write transaction is
specified in the

wTransferSize

field of the DFU Functional Descriptor.

There are several possible download mechanisms . The third mechanism described in
chapter 6.1 of the

USB Device Firmware Upgrade Specification

is implemented in this project:

1. A large portion of memory is erased. In our case all of Sector 1 and/or all of Sector 2.

2. Small firmware blocks are written. 8 bytes in the LS project, 128 bytes in the FS project.
Note: The number of bytes sent to the device in a control-write transfer is indicated by the

wTran s fe rSize

field of the DFU Functional Descriptor.

2.6.2 Uploading

The purpose of an Upload is to retrieve and archive a device’s firmware. It is by definition the
reverse of a Download. A fter Upload the Host should h ave a DFU suffix in the file where the
data are saved. This suffix contains useful information like the VendorID, ProductID, Firmware
Version, etc...

2.7 MANIFESTATION PHASE

After the transfer phase is terminated, the device is ready to execute the new firmware. To do
this the host must send a USB reset to re-enumerate the device in normal run-time operation.

7/30

DEVICE FIRMW ARE UPGRADE (DFU) IMPLEMENTAT ION IN ST7 USB D EVICES

3 DFU IMPLEMEN TATION

3.1 FIRMWARE ORGANIZATION

Both LS and FS projects are organized in the same way in terms of their DFU implementation.
Figure 1 shows the different software layers that have been added between the Lib rary and
the Application:

Figure 1. Firmware Overview

Application

Customer

DFU Protocol

DFU Core

Flash Driver

Example

STMicroelectronics

USB Library

3.2 DFU MECHANISM

The solution proposed by STMi croelectron ics provides a mech anism for selecting entry into
DFU Mode (See Figure 2). To accomplish this task it is very important to understand that only
the Sectors 1 and 2 can be erased and programmed during DFU operation. Sector 0 contains
the USB Standard Library and the DFU class routines.

After MCU Reset, the Reset Vector points to the DFU main routine. Just afterward, a verifica­tion of the integrity of Sectors 1 and 2 is performed. T h is chec k c an be done in several ways:
Checksum, CRC, Code etc... If this test is OK (meaning that Sectors 1 and 2 are correct), then
the application main routine is executed. Otherwise the DFU process takes place.

There are two other ways to enter DFU mode:

1. By receiving a DFU_DETACH request while the application is running.

2. By Hardware after an MCU Reset. This solution allows the user to force entry into DFU

mode. This solution is only given as example and is i mplemented in the LS project onl y. It is
not described in the DFU specification.

8/30

DEVICE FIRMWARE UPGRADE (DFU) IMPLEMENTATION IN ST7 USB DEVICES

Figure 2. DFU Mode Entry Mechanism

MCU Reset

Main DFU

Code, Checksum,
CRC, ...

Sectors 1 & 2
are OK ?

Yes

Main Application

3.3 FLASH SECTOR MANAGEMENT

Sector 0

Sectors
1 and 2

Forced DFU Mode Entry
(Controlled by har dware switch)

No

DFU_Detach

DFU Process

In order for the DFU mode entry mechanism described above to function correctly, it is neces­sary to place the firmware routines in the right sectors.

Basically, Sector 0 contains all routines that must be preserved during DFU erasing and pro­gramming. It principally contains the USB standard Library and the DFU layer routines.

Note: Application routines or constants can also be present in this sector, but in this case they
cannot be updated in DFU mode.

The Sectors 1 and 2 contain all routines and data that can be erased or changed in DFU

mode. They contain the Application routines and the “jump table” (see below).
The DFU_DETACH request decoding must also be present in these sectors. We can imagine

a “one shot DFU”, where the DFU_DETACH request decoding is not implemented in the new
firmware just downloaded (softw are protection) . The only way to recover is by using a H ard­ware switch (see Figure 2).

3.3.1 SECTOR 1 AND 2 INTEGRITY CHECK

As we have seen previously, we need to check if Sectors 1 and 2 are correct before calling the
main application routine. This will insure that these sectors are not corrupted due bad erasing
or bad programming. This check is not described in the DFU specification. and it can be easily
removed from the DFU protocol.

9/30