STMicroelectronics DFU Manager manual
Contents
1. 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 implemented in the LS project only It is not described in the DFU specification a 8 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES Figure 2 DFU Mode Entry Mechanism Couns E Sector 0 Sectors 1 and 2 Main DFU Mode Entry hardware switch Code Checksum CRC Sectors 1 amp 2 are OK Yes DFU_Detach Main Application DFU Process 3 3 FLASH SECTOR MANAGEMENT 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 O 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 t2. Descriptor included in the DFU Mode Configuration descriptor These descriptors are placed in Sector 0 in the following files In the LS project DFUDescript c DFUDescript h In the FS project DFU_desc c 3 5 3 DFU STRING DESCRIPTORS DFU string descriptors are in theoretically optional But three descriptors are created for the DFU in the LS and FS projects These allow the host to get some useful information when Sectors 1 amp 2 are incorrect DFU Language ID 0409h US English code DFU Manufacturer Name STMicroelectronics DFU Product Name DFU Demo These descriptors are located in Sector 0 in the same files as listed above 15 30 Y DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 3 6 PROTOCOL 3 6 1 DOWNLOAD STRATEGY The strategy adopted in the LS and FS projects is exactly the same 1 Sector 1 and or Sector 2 are erased 2 Blocks of data are transferred and programmed 8 bytes for LS project and 128 bytes for the FS project 3 A code or a checksum is written at the end of Sector 1 This code certifies that the download operation has been performed correctly The Host selects the data to be downloaded into the device In order to decrease the down loading time blocks of data containing only FFh are not transferred To achieve this strategy the wBlockNum field of the DFU_DNLOAD request is used 3 6 2 wBLockNum VALUES As already mentioned this field is used to pass certain information durin
3. exports this descriptor set DFU Mode Device descriptor 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 USB Device Firmware Upgrade Specifica tion 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 EPO The host issues a USB reset to the device This USB Reset is not possible on some Windows versions To bypass this issue the USB reset is performed by the device USB regulator 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 ky DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES When a USB reset signal is received th
4. 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 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 1 INTRODUCTION sont Ad 1 2 DEWCLASS in AS AS 4 2 1 INTRODUCTION 55 0 E one ey 4 22 PHASES e A daa 4 23 REQUESTS SA RS A a o a ie 5 2 4 ENUMERATION PHASE cocaina ee 5 2 4 1 Run Time Descriptor Set 0 0 cee ee ee 6 2 4 2 DFU Mode descriptor Set 0 ee eee 6 2 5 RECONFIGURATION PHASE 0 cece eee e ee eee eee e eee 6 2 6 TRANSFER PHASE 000 avian be wee ee we eee 7 2 6 1 Downloading sxe ice he et ee eee Binds dM ww da ed 7 2 6 2 Uploading Wan A hae baad Coie ig ee RN 7 2 7 MANIFESTATION PHASE i 0 2 c200 00s0 10s 00s 04370000008 7 3 DFU IMPLEMENTATION co certees pie east be dea 8 3 1 FIRMWARE ORGANIZATION 00 cece eee eee eee eee 8 3 2 DFU MECHANISM usaras ada 8 3 3 FLASH SECTOR MANAGEMENT 000 e cece eee eee e eens 9 3 3 1 SECTOR 1 AND 2 INTEGRITY CHECK 0 0000 o 9 3 3 2 LIBRARY FUNCTIONS CALLED BY THE APPLICATION 10 3 3 3 APPLICATION FUNCTIONS CALLED BY THE LIBRARY 11 3 3 4 JUMP TABLE 000500 eta eee EA 12 3 4 RAM MANAGEMENT 0 cece cece ee eee eee eee eee eee 12 3 4 1 SHARED VARIABLES coca eatin beh daw ioe Le 12 3 4 2 LOCAL VARIA
5. 19 30 Y DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES Table 4 LS Project DFU Files EA TEA E DFUCore c DFUCore h Contain the DFU Kernel routines Not protocol nor applica tion dependant DFUDescript c DFUDescript h Ga DFU descriptors They are dependant on the ap DFUJumpTable_XXX asm Contain the Jump Tables used by the Library to access the application routines Dependant on the application Contain the address of the Library routines called by the Ap DFULibFuncAdd h plication Must be modified each time the Library function ad dresses are changed DFUProtocol c DFUProtocol h Contain the DFU protocol routines They are dependant on the application 4 3 DFU CALL BACK FUNCTIONS These functions are called by the DFU Kernel routines They are dependant on the protocol and or the application All these functions are located in the DFUProtocol c file The content of these functions is only a DFU implementation example Depending on the protocol adopted these functions can be modified by the user Table 5 LS Project DFU Call back Functions Called by the DFU_Abort function when a DFU_ABORT re DEU Aboi USE quest is received Used to set Vpp to 5V Called by the DFU_ClearStatus function when a PPO A tame DFU_CLRSTATUS request is received Called by the DFU_Download function when a DFU_Download_User DFU_DNLOAD request is received Used to received and decode the data from the Host Called by the
6. AD 00100001b 1 E wBlockum Interface Length Firmware DFU_UPLOAD 10100001b 2 Zero Interface Length Firmware DF ETSTATE DFU_ABORT For additional information about these requests please refer to the DFU Class specification DFU_GETSTATUS 10100001b 3 Zero Interface Status 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 acomposite device HID Mass storage or any functional class and with DFU capability During the enumeration phase the device exposes two distinct and independent descriptor 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 operations Y 5 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 2 4 1 Run Time Descriptor Set During normal run time operation the device exposes its normal set of descriptors plus two additional descriptors Run Time DFU Interface descriptor Run Time DFU Functional descriptor Note The number of interfaces in each configuration descriptor 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 host and the device agree to perform DFU operations the host re enumerates the device At this time the device
7. BLES turca tica Bal 12 3 4 37 OVERLAP AREA 6 ans a on Oe ees 13 3 44 STACK tt d br ida Shi deel ee 14 3 5 DESCRIPTORS 16 avira koe ei oui eee eae Bale amp 14 3 5 1 STANDARD DESCRIPTORS padar cece tee 14 3 5 2 DEU DESCRIPTORS iunior aada e aaa AAA A 15 3 5 3 DFUSTRING DESCRIPTORS 0 000 cece ee 15 3 60 PROTOCOL ici OD ae RAR 16 3 6 1 DOWNLOAD STRATEGY 0 00 eee eee 16 3 6 2 wBLockNum VALUES 0 0c eects 16 2 30 a DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 3 7 HARDWARE CONSIDERATIONS 0ccccccccoc 16 LM NPE di iS dd dad baie dd te 16 3 7 2 FORCED DFU MODE ENTRY o 17 3 8 HDFLASH DRIVERS ocio a aa a a ee we 17 3 8 1 FUNCTIONS USED ieties erdei ori e o eE eee 17 3 8 2 STACK AND RAM o ccccccocco rnrn eee 17 4 DFU LOW SPEED PROJECT 600 a A Se 19 441 DIRECTORIES co ese rar a a E G 19 4 2 DFU FILES da a A O A A AAA 19 4 3 DFU CALL BACK FUNCTIONS 0 cc eee eee eee 20 4 4 OTHER DFU FUNCTIONS cece eee cere teen erences 21 4 5 DFU VARIABLES 235 true nates AE eee 21 4 6 RESTRICTIONS wisi ccivedeieneideas teeta rara 22 5 DFU FULL SPEED PROJECT cavar a 23 5 1 DIRECTORIES v0 0 0d ptas tas BEE le ade eE diia 23 5 2 DEUPILES web ti Pa da aa 23 5 3 DFU CALL BACK FUNCTIONS 00 cece eee eee eee 24 5 4 OTHER DFU FUNCTIONS 0 0 cece eee eee 24 5 5 DEUNARIABLES ariera ofa deans ead eee d aoe e eia 25 5 6 RESTRICTIONS sais Pi A eae ce
8. Ba ae ane Se 26 6 RELATED DOCUMENTS ostia aia aan 27 7 RELATED SOFTWARE 00 ana serene ease ed ered a eee AER 28 8 TERMS AND ABBREVIATIONS 2 0 cc eee eee eee eee eee 29 3 30 a DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 2 DFU CLASS 2 1 INTRODUCTION The DFU class uses the USB as a communication channel between the ST7 and the program ming tool generally a PC host The DFU class specification states that all the commands 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 format of the data transferred s19 hex pure binary etc 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 associated functional descriptor embedded within the device s normal run time descriptors serve this purpose and provide a target for class specific requests over the control pipe 2 Reconfiguration The host and the device agree to initiate a firmware upgrade The host is sues a USB reset to the device and the device then exports a second set of descriptors in preparation for the Transfer phase This deactivates the run time device drivers associated with the d
9. DFU_Init function when entering DFU mode PPan gsar Used to initialize variables Vpp etc a 20 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES Table 5 LS Project DFU Call back Functions Called by the DFU_GetStatus function at the end of the DFU_ManifestWaitReset_User downloading phase This function is used to write the End Of Programming code in the last byte of Sector 1 Used to check the integrity of Sectors 1 and 2 This is the first alo function called by DFU_Main after Reset Called by the DFU_Upload function when a DFU_UPLOAD DFU_UpLoad_User request is received Used to prepare and send the data to the Host Called by the DFU_Main function This function manages the HDFlashProcess f call to all HDFlash routines Used to check the presence of the Vbus when device is in VbusCheck self powered mode This function is compiled if the SELF_POWERED compilation variable is defined 4 4 OTHER DFU FUNCTIONS These functions are not called by the Library They are utility routines used during DFU processing Table 6 LS Project Other DFU Functions SetVpp12V Used to set the Vpp voltage to 12V needed during erasing or programming operations SetVpp5V Used to set the Vpp Voltage to 5V when not erasing or pro gramming 4 5 DFU VARIABLES These variables are shared by the DFU kernel and the DFU protocol functions Y 21 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DE
10. ECT INDIRECT OR CONSEQUENTIAL DAMAGES WITH RESPECT TO ANY CLAIMS ARISING FROM THE CONTENT OF SUCH A NOTE AND OR THE USE MADE BY CUSTOMERS OF THE INFORMATION CONTAINED HEREIN IN CONNECTION WITH THEIR PRODUCTS Information furnished is believed to be accurate and reliable However STMicroelectronics assumes no responsibility for the consequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use No license is granted by implication or otherwise under any patent or patent rights of STMicroelectronics Specifications mentioned in this publication are subject to change without notice This publication supersedes and replaces all information previously supplied STMicroelectronics products are not authorized for use as critical components in life support devices or systems without the express written approval of STMicroelectronics The ST logo is a registered trademark of STMicroelectronics 2003 STMicroelectronics All Rights Reserved Purchase of IC Components by STMicroelectronics conveys a license under the Philips IC Patent Rights to use these components in an 12C system is granted provided that the system conforms to the 12C Standard Specification as defined by Philips STMicroelectronics Group of Companies Australia Brazil Canada China Finland France Germany Hong Kong India Israel Italy Japan Malaysia Malta Morocco Singapore Spain Sweden Swi
11. VICES Table 7 LS Project DFU Variable DFUDataReceived Buffer for storing data coming from the host after a Down Load request DFUDataToSend Buffer containing data to send to the host for UpLoad Get State or GetStatus requests Contains the current DFU state of the device as defined in the DFUDeviceState DFU specification Sent after a GetState or GetStatus re quest Contains the current DFU status of the device as defined in the DFU specification Sent after a GetStatus request DFUPollTimeOutH Contains the high byte of the Polling TimeOut Sent after a GetStatus request DFUDeviceStatus Contains the low byte of the Polling TimeOut Sent after a BEER Orme Ont GetStatus request 4 6 RESTRICTIONS This project is compatible with MetroWerks compiler only and with ST72F62 16K and ST72F63B 16K devices due to RAM size restriction a 22 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 5 DFU FULL SPEED PROJECT The FS DFU project has been created from the ST7265 5 in 1 project and the ST7 USB FS Li brary Two other parts have been added the DFU specific files and the HDFlash drivers in bold in the next section 5 1 DIRECTORIES ST7USBFS DFU Object output from compilation Sources MassSto Mel Usb ST7 USB Full Speed Library kernel files Usb_App USB application specific files Usb_DFU USB DFU specific files kernel application HD Flash driver
12. able 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 software protection The only way to recover is by using a Hard 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 STA 9 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES In the LS project the solution adopted for this check is the following the last byte of sector 1 is reserved after the erasing operation this byte contains FFh atthe end of downloading this byte is written with 6Dh after each MCU Reset this byte is checked If it contains 6Dh we jump to the Application main routine otherwise we jump to the DFU process routine So if the download operation is aborted or if something wrong happens the MCU will always enumerate in DFU mode In the FS project a Checksum calculation is used during downloading the Checksum is calculated on all the data received at the end of download the Checksum is written at the end of Sector 1 after MCU Reset th
13. are running a 18 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 4 DFU LOW SPEED PROJECT The LS DFU project has been created starting from the ST7 USB LS Evaluation Kit project and the ST7 USB LS Library Two other parts have been added the DFU specific files and the HDFlash drivers in bold in the next section 4 1 DIRECTORIES ST7USBLS DFU EvalKit ST7 USB LS Evaluation Kit project Config project configuration files mak prm etc Appli application files DFU DFU layer files Objects output from compilation HDFlashDriver Flash routines to erase and program Library ST7 USB LS Library project Config project configuration files mak prm etc Macro macros definitions Micro devices mapping files Usb ST7 USB Low Speed Library kernel files Objects output from compilation As you can see the Library can be compiled alone without the EvalKit project This is because the RAM area of the Library is completely separated from the RAM area of the EvalKit project So a different prm file is needed The S19 file generated from the Library can then be loaded into Sector 0 even if the EvalKit project is not ready 4 2 DFU FILES All these files are placed inside the DFU directory Files in bold are files that depend on the protocol and or the application and may be modified by the user
14. because the same area could be used by a new application firmware See RAM management for more details For these routines the parameters are passed through a structure of global variables LS project example define Set_EP_Ready EndPointPrm DirectionPrm LengthPrm GParams SEPRParams EndPoint EndPointPrm GParams SEPRParams Direction DirectionPrm GParams SEPRParams Length LengthPrm Set_EP_Ready_NP define Set_EP_Ready_NP void void OxF70E In the Application firmware we still use the same call to the Library routine Set_EP_Ready 0 EP_IN 8 But here the 3 parameters are saved in RAM Then the Set_EP_Ready_NP routine is called The purpose of this routine is to retrieve the parameters previously saved in RAM and then to call the Library routine located in Sector 0 void Set_EP_Ready_NP void Set_EP_Ready GParams SEPRParams EndPoint GParams SEPRParams Direction GPar ams SEPRParams Length Note In the FS project none of the Library functions use parameters So the issue does not occur in this project 3 3 3 APPLICATION FUNCTIONS CALLED BY THE LIBRARY Also called Call back functions The Application routines called by the Library can have their address location changed after a download The address of these routines must be saved somewhere in order to allow the Li brary to call them This area is called a Jump Tab
15. d a variable used by the application at address 50h and a var able used by a Library function at address 51h The Library and Application firmware are written in Sectors 0 1 2 using an EPB programming board Figure 3 Initial State of Overlap area prior to DFU FLASH memory RAM memory Overlap area Application 1 sectors 1 8 2 Library sector0 The problem appears when a new application firmware is written in the Flash and the overlap area is modified Suppose now that the application function uses a second variable The linker will locate this second variable at address 51h and the Library function variable at address 52h But in DFU programming the Library in Sector 0 is not changed and still uses the ad dress 51h Y 13 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES Figure 4 Problem of Overlap area conflict after DFU FLASH memory RAM memory Overlap area Application 2 sectors 1 8 2 Library sector0 So it is necessary also in this case to separate the Library and the Application Overlap areas Note The same thing must also be done for the ZeroPage area Refer to the project PRM file for details about the location of these areas 3 4 4 STACK The stack area is shared by the Library and the Application No special precautions are needed in normal mode but a minimum amount of free stack must be available before calling any of the Embedded Commands used for HDFlash programming Th
16. d address and it in turn calls the appli cation function App_USB_Setup 3 4 RAM MANAGEMENT 3 4 1 SHARED VARIABLES Some variables are accessed by both Library and Application functions These variables are located at a fixed addresses in 16 bit RAM Some variables used In the LS project UsbLibStatus USBbRequest USBwValue USBwIndex etc In the FS project EPs_DataAddress EPs_Length etc The EndPoint buffers are also shared variables The location of these variables is done using pragmas or using the symbol after the vari able declaration 3 4 2 LOCAL VARIABLES This refers to all variables which are not shared between the Library and the Application func tions Library variables and Application variables are located in different areas in order to avoid overlapping when an application firmware is upgraded See the PRM files for details on the location of these variables 12 30 a DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 3 4 3 OVERLAP AREA The Overlap area is not used by the Library of the FS project So no precautions are neces sary for this project But the Library of the LS project is strongly impacted A lot of Library functions have parame ters When more than 2 bytes are used the parameter passing is done through the Overlap area An overlapping problem can occur when a firmware is upgraded See the example below Initial state the linker has place
17. e Checksum is re calculated and compared to the value written in the last bytes of Sector 1 Note This second solution takes more execution time than the first one 3 3 2 LIBRARY FUNCTIONS CALLED BY THE APPLICATION The Application calls several functions from the USB Library For the LS project the Library functions called are Init_USB_HW Disable_USB_HW Handle_USB_Events Enable_STATUS_Stage Test _EP_Ready Set_EP_Ready Write_EP_Buffer Read_EP_Buffer These Library routines are placed in Sector 0 and their content and address locations are not changed in DFU mode The problem we face is that the Application firmware is also linked with these Library routines The location of these Library routines can be different from the location chosen by the linker when the Library is compiled on its own A simple way to solve this issue is to access the Library functions using their direct address LS project example define Init_USB_ HW void void O0xF635 The call to the function remains the same Init_USB_HW Special case Functions with Parameters Some Library routines need parameters with a number of bytes greater than 2 These are In the LS project Set_EP_Ready Write _EP Buffer Read_EP_Buffer 10 30 ky DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES If the MetroWerks compiler is used the third and any subsequent bytes are saved in the Overlap area However this is not compatible with DFU operation
18. e 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 phase begins after the device has processed the USB reset and exported 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 ofthe 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 wTransferSize field of the DFU Functional Descriptor 2 6 2 Uploading The purpose of an Upload is to retrieve and a
19. e using the Embedded Commands in the System Memory of the ST7 device Some routines drivers have been created to access these Embedded Commands easily These routines can be used in any project that needs to erase or program the HDFlash For more information on these drivers see the AN1576 3 8 1 FUNCTIONS USED Only few driver functions are used in the DFU project They are RASS_ Disable to unlock the FCSR register HDFlashEraseSector to erase a sector HDFlashWriteByte to write a single byte HDFlashWriteBlock to write a block Note The FS project uses the WriteBlock function to program the bytes into the Flash while the LS project uses the WriteByte function 3 8 2 STACK AND RAM Caution Before launching any Embedded Command the Stack Pointer must be greater than or equal to 017Ch This is due to the fact that 124 bytes are used in the Stack by the Em bedded commands In the LS project the Stack area of the ST72F62 and ST72F63B devices contains only 128 bytes So we must have a maximum of 2 function calls starting from the main routine before STA 17 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES launching a HDFlash function This limitation does not exist in the FS project because the Stack area is bigger in the ST72F65 device Embedded commands also use the RAM from FOh to FFh for parameter passing and local variables This area must not be used by the application while the Embedded commands
20. en AN1577 ST APPLICATION NOTE DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES by Microcontroller Division Applications 1 INTRODUCTION This application note presents the implementation of a Device Firmware Upgrade DFU ca pability in ST7 USB microcontrollers It follows the DFU class specification defined by the USB Implementers Forum for reprogramming an application through USB The DFU principle 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 most of the ST7 microcon 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 Flash operations erasing and program 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 amp 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
21. evice 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 descriptor are used to ensure correct block sizes and timing for programming the nonvolatile memories Status requests are employed to maintain synchronization between the host and the device 4 Manifestation Once the device reports to the host that it has completed the reprogram 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 id Product field of the device when it enumerates the DFU descriptor set This ensures that the 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 FFO3h and 0003h for the standard Evaluation Kit without the DFU 4 30 a DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 2 3 REQUESTS A number of DFU class specific requests are needed to accomplish the upgrade operations The following table summarizes the DFU class specific requests Table 1 Summary of DFU Class Specific Requests DFU_DETACH 00100001b 0 K wTimeout Interface DFU_DNLO
22. g download The same field is also used in the DFU_UPLOAD request to read the flash memory The table below summarizes the values used Table 3 wBlockNum values sp OO 1DFFh to 1000h Flash address divided by 8 OFFFh to 0000h Not Used Note The fact that the Flash address is given divided by 8 is only a protocol example 3 7 HARDWARE CONSIDERATIONS 3 7 1 VPP The HDFlash memory needs 12V on the Vpp pin during erasing and programming operations This 12V is provided using a ST662A device This device is already present on the Evaluation 16 30 IST DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES Kit and the 5 in 1 boards A specific I O port is used to control the presence of the 12V on the Vpp pin LS project I O Port PB1 FS project I O Port PE4 Please refer to the ST7 Family Flash Programming Reference Manual for implementation details concerning the ST662A device 3 7 2 FORCED DFU MODE ENTRY In the LS project only there is a possibility to enter DFU mode directly without checking the in tegrity of Sectors 1 amp 2 To do this the SW1 Switch must be pressed while the Reset button is released This mechanism is very useful when a problem occurs in the Application and the DFU_DETACH command cannot be interpreted If this happens in the FS project the only way to recover is to erase Sector 1 using an EPB programming board 3 8 HDFLASH DRIVERS Erasing and programming the HDFlash memory is don
23. is is explained in detail further on 3 5 DESCRIPTORS 3 5 1 STANDARD DESCRIPTORS The normal run time descriptors have to be modified to support DFU capability Device descriptor The Product ID must be changed because when DFU is implemented the device becomes composite In the LS project Evaluation Kit DFU has the number FFO3h instead of 0003h for Evalua tion Kit alone In the FS project 5 in 1 DFU has the number 0320h instead of 1307h for 5 in 1 alone Note When the device is in DFU mode only its Product ID is the number DF11h This number is common for any project with DFU support Configuration descriptor The bNuminterfaces of each configuration that supports DFU must be incremented by one For LS project bNuminterfaces 2 HID DFU For FS project bNuminterfaces 2 MASS STORAGE DFU 14 30 a DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES Furthermore 2 additional descriptors must be added at the end of the Configuration de scriptor the Run Time DFU Interface descriptor and the Run Time DFU Functional descriptor These descriptors are described in detail below 3 5 2 DFU DESCRIPTORS The table below summarizes the 5 DFU descriptors to be created and in which mode they ap pear Table 2 DFU Descriptors DFU Interface Descriptor DFU Run time Interface Descriptor X DFU Functional Descriptor X Descriptor included in the Run Time Configuration descriptor
24. le see below for details The Application functions called by the Library are In the LS and FS projects the main application routine all the interrupt routines In the LS project the MCU_Init routine called when an USB EndSuspend interrupt occurs the USB specific routines Appli_Status_In and Appli_Status_Out for each Status IN OUT stage ky 11 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES In the FS project all USER_USB_xxx functions 3 3 4 JUMP TABLE As already mentioned this table is used to store the address of the Application routines called by the Library In the LS project In order to use fewer bytes when routines are called this table is defined in assembly It simply contains a JP to the routine address This table is placed at a fixed address at the end of Sector 1 EFCOh It is important to note that two assembly files are used for this Jump Table One is used during the compilation of the Library in Sector 0 and contains dummy addresses The second one is used during the compilation of the Application in Sectors 1 and 2 At this time the addresses of the routines are known In the FS project the call is performed in C language directly using a double function call Dummy functions placed at a fixed address are used for this purpose FS project example The Library calls the USER_USB_Setup function This function calls the dummy function Vec_USB_Setup It is located at a fixe
25. lication Programming Drivers for XFlash and HDFlash ST7 MCUs AN1475 Developing a ST7265X Mass Storage Application AN1603 Using the ST7 USB Device Firmware Upgrade Development Kit DFU DK ST7 USB Device Firmware Upgrade Demonstrator User Manual 27 30 Y DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 7 RELATED SOFTWARE Table 14 Microcontroller Software A A On o This is the example referred to in this application note AN1577 of a user application firmware with DFU capabil ity for the ST72F65x devices The project is supplied as a zip file containing all the necessary source and project files ready for compilation by the Metroworks C Complier It can be used to test the DFU process and can be easily adapt ed by the user to another application This is the example referred to in this application note AN1577 of a user application firmware with DFU capabil ity for the ST72F62 or ST72F63B devices The project is supplied as a zip file containing all the necessary source and project files ready for compilation by the Metroworks C Complier It can be used to test the DFU process and can be easily adapted by the user to another application ST7 USB Full Speed DFU Project DFU for ST72F65x devices ST7 USB Low Speed DFU Project DFU for ST7262 63B devices Table 15 PC Software MOE gt Ned This an example of a Graphical User Interface for starting a DFU session lt can be used wi
26. me of the DFU IN requests during the Status PEE test stage For example UpLoad and GetStatus DFU_CopyDatalN Not used in this project Used to copy data returned by a DownLoad request into the pre eopyDalgord EndPoint 0 Out buffer DFU_Setup Used to decode and process all DFU requests 5 4 OTHER DFU FUNCTIONS These functions are not call back functions They are utility routines used during DFU processing Table 10 FS Project Other DFU Functions CheckSum_ROM Used to calculate a checksum on Sectors 1 and 2 CRC_ROM Used to calculate a CRC on Sectors 1 and 2 Not used in this project only given as example DFU_Init Used to initialize all DFU variables DFU Manifest Called after Downloading is finished Calculates and writes z the Checksum in the Flash 24 30 a DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES Table 10 FS Project Other DFU Functions Flashing_End Sets Vpp to 5V Called when Flash operations are finished Flashing_Start Sets Vpp to 12V and unlock FCSR register Called before Flash operations start dp Label Jumps to the address previously saved by the Set_Label function Powers down and Power up the USB voltage regulator to Replug_Device simulate a replug to the Host Used after a Detach and after programming is finished Saves current PC in a variable This variable is used to jump Set_Label to the right place after a Detach request for example Initializes the timer u
27. rchive a device s firmware It is by definition the reverse of a Download After Upload the Host should have 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 Y DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 3 DFU IMPLEMENTATION 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 Library and the Application Figure 1 Firmware Overview Application DFU Protocol Example Customer DFU Core Flash Driver STMicroelectronics USB Library 3 2 DFU MECHANISM The solution proposed by STMicroelectronics provides a mechanism 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 This check can be done in several ways
28. s For details of MassSto and Mc directories please refer to AN1475 Developing an ST7265X Mass Storage Application 5 2 DFU FILES All these files are located in the Usb_DFU directory Files in bold are files that depend on the protocol and or the application and can be modified by the user Table 8 FS Project DFU Files AS EA AR A DFU c DFU h Contain all DFU kernel and Protocol routines DFU_Desc c Contains the DFU descriptors DFU_Var asm Contains the definition of DFU variables Flashing h Contains the HDFlash routines Contain all call back functions called by the Library These Pec Deb ese USED functions call the DFU functions described in the DFU c file 23 30 Y DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 5 3 DFU CALL BACK FUNCTIONS These functions are not directly called by the Library Instead they are called by intermediate layer functions like USER_USB_Reset etc They are protocol and application dependant and you can modify them to fit with yours application protocol Table 9 FS Project DFU Call back Functions Used to check if the Application code in Sectors 1 and 2 is valid A Checksum is calculated and compared with the PPAP Mallo Checksum previously saved in the last bytes of Sector 1 Re turns 0 if Checksum is false Processes some of the DFU OUT requests during the Status DFU_Status_In stage For example DownLoad and Detach Processes so
29. sed to count the timeout value after a Setup_Timer Detach request is received 5 5 DFU VARIABLES Table 11 FS Project DFU Variables DFU_Action Used to keep trace of the current DFU action DFU_BlockNum Contains the wBlockNum value present in DownLoad and UpLoad DFU requests DFU_BlockSiz Contains the number of bytes to program or read DFU Buffer Used to store the data received from the Host DownLoad re quest or to send to the Host UpLoad request DFU_Capability Contains information on DownLoad and UpLoad capabilities DFU_Request Contains the current DFU request received DFU_State Contains the current DFU State Sent by GetState and Get Status requests DFU_Status Contains the current DFU Status Sent by GetStatus request DFU_Timeout Contains the TimeOut value sent by Detach request 25 30 Y DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 5 6 RESTRICTIONS This project is compatible with MetroWerks compiler and with the ST72F65 device only 26 30 a DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 6 RELATED DOCUMENTS Table 12 External Documents Universal Serial Bus Specification 1 1 Sept 23 1998 Universal Serial Bus Device Class Specification for Device 1 0 Firmware Upgrade May 13 1999 Table 13 STM Documents ST7 Family Flash Programming Reference Manual AN1575 On Board Programming Methods for XFlash and HDFlash ST7 MCUs AN1576 In App
30. th the ST7 USB Full Speed and Low Speed Projects listed in Table 14 or with any user developed project that uses the same protocol lt has been developed in Visual C and is supplied as an ST7 DFU Demo Package installation file ready to be installed on a Windows PC This a set of library routines and device drivers that can be used to develop a Windows GUI application such as the ST7 DFU Demo Package listed above Refer to AN1603 for more information DFU DK Development Kit Package 28 30 a DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES 8 TERMS AND ABBREVIATIONS Table 16 Terms and Abbreviations Device Firmware Upgrade Executable software stored in a write able nonvolatile mem ory on a USB device 1 To overwrite the firmware of a device 2 the act of over Upgrade writing the firmware of a device 3 new aa intended to replace a device s existing firmware To transmit information from host to device Upload To transmit information from device to host Low Speed Evaluation Kit project for ST72F62 and 72F63B ES Project devices a FSproject Full Speed 5 in 1 board project for ST72F65 device Y 29 30 DEVICE FIRMWARE UPGRADE DFU IMPLEMENTATION IN ST7 USB DEVICES THE PRESENT NOTE WHICH IS FOR GUIDANCE ONLY AIMS AT PROVIDING CUSTOMERS WITH INFORMATION REGARDING THEIR PRODUCTS IN ORDER FOR THEM TO SAVE TIME AS A RE SULT STMICROELECTRONICS SHALL NOT BE HELD LIABLE FOR ANY DIR
31. tzerland United Kingdom U S A http www st com 30 30 a
Download Pdf Manuals
Related Search