AN1633
APPLICATION NOTE
DEVICE FIRMWARE UPGRADE (DFU) IMPLEMENTATION IN
NON-USB APPLICATIONS
by Microcontroller Division Applications
1 INTRODUCTION
This application note describes how to implement the Device Firmware Upgrade (DFU) capa-
bility using a ST7 USB microcontroller like the ST72F62 or ST72F63B in a general purpose or
‘non-USB’ application. The term ’non-USB’ is used here to contrast with ‘USB application’
which has a different DFU implementation (refer to AN1577). In the implementation described
here, the USB interface is not used in the application. The application board is self powered
and the on-chip USB interface is only used occasionally, as a maintenance utility port to up-
grade the MCU firmware.
The USB cell is only activated when the USB cable is plugged-in. At this time the application
is stopped and the microcontroller is seen as a USB device and enters the DFU process to
erase and program the new firmware in Sector 1 and/or Sector 2. When the user removes the
USB cable, the USB cell is switched-off and the main application is executed !
To illustrate this application note, a firmware example has been developed using a ST72F62
or a ST72F63B USB Low-Speed device. This firmware is based on the ST7 USB Low-Speed
DFU Demo firmware.
It is not necessary to know the USB cell to understand this application note. For more informa-
tion about the USB DFU class, please refer to the Application Note AN1577.
AN1633/0303
1/9
1
2 DFU MECHANISM
2.1 OVERVIEW
As mentioned in the introduction, the microcontroller’s USB cell is only used during the DFU
upgrade process. This upgrade process takes place only when the USB cable is plugged-in.
When the USB cable is removed the non-USB application is executed and the USB cell is
switched off. The following figure explains this mechanism in detail.
Figure 1. DFU Flowchart in a non-USB application
SECTOR 0
SECTORS 1 & 2
MCU Reset
(jump table)
Main (DFU)
Main (Application)
USB cable ?
No
USB cable ?
No
Yes
Yes
DFU Process
Flash
erasing &
programming
WDG Reset
Yes
USB cable ?
No
WDG Reset
As you can see, two separate firmware applications reside in different flash sectors and are
selected by plugging a cable in the USB connector.
2/9
2
The first firmware application contains the USB Library, the DFU layer and the HDFlash driver.
This firmware application must be placed in Sector 0. It is executed only when the USB cable
is plugged-in. This firmware cannot be modified during the DFU process. When the Flash up-
grade is finished, the firmware in Sector 0 continues execution until the USB cable is removed.
The second firmware application is the main application. It must be placed in Sectors 1 or 2
because it is modified during the DFU process. This firmware is executed only when the USB
cable is not plugged into the board.
The DFU layer also allows you to upgrade only one sector. You can use this feature, for ex-
ample, to store common data or code for any firmware loaded in Sector 2.
2.2 USB CABLE DETECTION
The detection of the USB cable is made through an I/O port configured in Input mode. This
I/O is connected to the Vbus line on the USB connector. Detection can be done with interrupts
or by polling. In our example, the polling method is used. This detection must be performed by
both applications (main application and DFU).
Figure 2. Connecting an I/O Port to the Vbus line
+5V
Vdd
I/O
USB connector
USB Vcc
Vss
Vbus
3/9
2.3 TRANSITION BETWEEN USB AND APPLICATION
The transition between the application firmware and the DFU firmware is made only through
an MCU reset. A software reset is performed using the Watchdog control register when the
USB cable is detected.
The transition between the DFU firmware and the application firmware is made through a
“Jump Table”. In fact, the DFU firmware only needs to know the address of the application
main routine. This address is saved in the last bytes of Sector 1.
2.4 RAM
As the execution of the firmware in Sector 0 and Sectors 1 & 2 always starts after a MCU
Reset, we have no RAM overlapping problem. Furthermore, as it is a non-USB application,
there none of the USB Library functions are called by the main application. So, there is also no
problem of parameter passing. This simplifies the RAM management a lot.
4/9
3 FIRMWARE
A specific firmware example has been developed to illustrate this application note: ST7 USB
LS DFU Demo for non-USB applications.
This firmware has been created starting from the ST7 USB LS DFU Demo firmware, itself
based on the ST7 USB LS Library and ST7 USB LS EvalKit.
The main changes concern the size optimization of the USB Library and the DFU layer in
order to use a little space as possible in Sector 0. Currently the space required by the USB Li-
brary and the DFU layer is around 2 Kbytes. This optimization leaves 2 Kbytes of code for run-
ning the application during the DFU process or using it for code that does not need to be up-
graded.
This firmware is compatible with Cosmic and Metrowerks compilers.
3.1 MAIN APPLICATION FUNCTION EXAMPLE
void main(void) {
Init_Appli();
while (1) {
// MANDATORY: USED TO GO INTO DFU MODE WHEN THE USB CABLE IS PLUGGED
if (ValBit(PBDR, 5)) { // Check if Vbus is present ?
Stop_Appli();
WDGCR = 0x80; // MCU Reset
}
else {
Application();
}
} // End of while
} // End of main
3.2 DEVICE INFORMATION EXAMPLE
As the application is non-USB, we don’t have the USB descriptors. The descriptors normally
contain strings like: Manufacturer name, Product name, firmware version, ...
Because it is very useful to know which product is connected to the USB, a kind of string de-
scriptor has been created in this project.
The principle is very simple: a fixed table contains the address and the size of these string de-
scriptors (for example the Product name and its version). The host retreives this information
using a DFU_UPLOAD request. It is then possible to display these strings on a Graphical User
Interface.
5/9
京公网安备 11010802033920号
Copyright © 2005-2026 EEWORLD.com.cn, Inc. All rights reserved
电子工程世界
