ATMEGA32U4

Features • USB Protocol – Based on the USB DFU class – Autobaud (8/16 MHz crystal) • In-System Programming – Read/Write Flash and EEPROM on-chip memories – Read Device ID – Full chip Erase – Start application command • In-Application Programming – Software Entry-points for on-chip flash drivers 1. Description The 8bits mega AVR with USB interface devices are factory configured with a USB bootloader located in the on-chip flash boot section of the controller. This USB bootloader allows to perform In-System Programming from an USB host controller without removing the part from the system or without a pre-programmed application, and without any external programming interface. This document describes the USB bootloader functionalities as well as the serial protocol to efficiently perform operations on the on chip Flash memories (Flash and EEPROM). USB DFU Bootloader Datasheet AT90USB128x AT90USB64x AT90USB162 AT90USB82 ATmega32U4 ATmega16U4 7618C–AVR–07/08 2. Bootloader Environment The bootloader is located in the boot section of the on-chip Flash memory, it manages the USB communication protocol and performs read/write operations to the on-chip memories (Flash/EEPROM). The USB bootloader is loaded in the “Bootloader Flash Section” of the on-chip Flash memory. The size of the bootloader flash section must be larger than the bootloader size.USB products are factory configured with the default on-chip USB bootloader and the required bootsection configuration. Table 2-1. USB Bootloader Parameters Product AT90USB1287 4 KWord AT90USB1286 AT90USB647 0x03EB / 0x2FF9 AT90USB646 AT90USB162 2 KWord AT90USB82 ATmega32U4 ATmega16U4 0x03EB / 0x2FF7 0x03EB / 0x2FF4 0x03EB / 0x2FF3 0x0800 0x3800 0x0800 0x03EB / 0x2FFA 0x1800 0x7800 0x03EB / 0x2FFB 0xf000 Flash Bootsection Size Configuration VID / PID Bootloader Start Address (word address) Figure 2-1. Physical Environment DFU Class USB Interface USB Bootloader in Boot section Read/Write Flash Application section Read/Write EEPROM Data 3. Bootloader Activation As specified in the AT90USB datasheet, the bootloader can be activated by one of the following conditions: • Regular application execution: A jump or call from the user application program. This may be initiated by a trigger such as a command received via USB, USART or SPI and decoded by the application. 2 7618C–AVR–07/08 • Boot Reset Fuse The Boot Reset Fuse (BOOTRST) can be programmed so that the Reset Vector points to the Boot Flash section start address after reset. Once the user code is loaded, a bootloader command (“start application”) can start executing the application code. Note that the fuses cannot be changed by the MCU itself. This means that once the Boot Reset Fuse is programmed, the Reset Vector will always point to the Bootloader Reset and the fuse can only be changed through the serial or parallel programming interface. The BOOTRST fuse is not active in the default factory configuration. • External Hardware conditions The Hardware Boot Enable fuse (HWBE) can be programmed so that upon special hardware conditions under reset, the bootloader execution is forced after reset. These different conditions are summarized in Figure 3-1 on page 3. Figure 3-1. Boot Process Hardware Boot process Reset Yes Ext Hardware conditions No Yes BOOTRST = 0 PC = boot loader section PC = 0000h No Software Execution "Software activation (jump)" Application Running Start Bootloader 4. Protocol 4.1 Device Firmware Upgrade Introduction Device Firmware Upgrade (DFU) is the mechanism implemented to perform device firmware modifications. Any USB device can exploit this capability by supporting the requirements specified in this document. Because it is unpractical for a device to concurrently perform both DFU operations and its normal run-time activities, these normal activities must cease for the duration of the DFU operations. Doing so means that the device must change its operating mode; i.e., a printer is not a printer while it is undergoing a firmware upgrade; it is a PROM programmer. However, a 3 7618C–AVR–07/08 device that supports DFU is not capable of changing its mode of operation on its own. External (human or host operating system) intervention is required. 4.2 DFU Specific Requests In addition to the USB standard requests, 7 DFU class-specific requests are used to accomplish the upgrade operations: Table 4-1. DFU Class-specific Requests wValue wTimeout wBlock wBlock Zero Zero Zero Zero wIndex Interface (4) Interface (4) Interface (4) Interface (4) Interface (4) Interface (4) Interface (4) wLength Zero Length Length 6 Zero 1 Zero Data none Firmware Firmware Status none State none bmRequestType 0010 0001b 0010 0001b 1010 0001b 1010 0001b 0010 0001b 1010 0001b 0010 0001b bRequest DFU_DETACH (0) DFU_DNLOAD (1) DFU_UPLOAD (2) DFU_GETSTATUS (3) DFU_CLRSTATUS (4) DFU_GETSTATE (5) DFU_ABORT (6) 4.3 DFU Descriptors Set The device exports the DFU descriptor set, which contains: • A DFU device descriptor • A single configuration descriptor • A single interface descriptor (including descriptors for alternate settings, if present) 4.3.1 DFU Device Descriptor This descriptor is only present in the DFU mode descriptor set. The DFU class code is reported in the bDeviceClass field of this descriptor. Table 4-2. DFU Mode Device Descriptor Size 1 1 2 1 1 1 1 2 2 2 1 Value 12h 01h 0100h FEh 01h 00h 32 03EBh 2FFBh 0x0000 0 Size of this descriptor, in bytes DFU functional descriptor type USB specification release number in binary coded decimal Application Specific Class Code Device Firmware Upgrade Code The device does not use a class specific protocol on this interface Maximum packet size for endpoint zero (limited to 32 due to Host side driver) Vendor ID Product ID Device release number in binary coded decimal Index of string descriptor Description Offset 0 1 2 4 5 6 7 8 10 12 14 Field bLength bDescriptorType bcdUSB bDeviceClass bDeviceSubClass bDeviceProtocol bMaxPacketSize0 idVendor idProduct bcdDevice iManufacturer 4 7618C–AVR–07/08 Offset 15 16 17 Field iProduct iSerialNumber bNumConfigurations Size 1 1 1 Value 0 0 01h Index of string descriptor Index of string descriptor One configuration only for DFU Description 4.3.2 DFU Configuration Descriptor This descriptor is identical to the standard configuration descriptor described in the USB DFU specification version 1.0, with the exception that the bNumInterfaces field must contain the value 01h. DFU Interface Descriptor This is the descriptor for the only interface available when operating in DFU mode. Therefore, the value of the bInterfaceNumber field is always zero. Table 4-3. DFU Mode Interface Description Size 1 1 1 1 1 1 1 1 1 Value 09h 04h 00h 00h 00h FEh 01h 00h 00h Description Size of this descriptor, in bytes INTERFACE descriptor type Number of this interface Alternate setting(1) Only the control pipe is used Application Specific Class Code Device Firmware Upgrade Code The device does not use a class specific protocol on this interface Index of the String descriptor for this interface 4.3.2.1 Offset 0 1 2 3 4 5 6 7 8 Field bLength bDescriptorType bInterfaceNumber bAlternateSetting bNumEndpoints bInterfaceClass bInterfaceSubClass bInterfaceProtocol iInterface Note: 1. Alternate settings can be used by an application to access additional memory segments. In this case, it is suggested that each alternate setting employ a string descriptor to indicate the target memory segment; e.g., “EEPROM”. Details concerning other possible uses of alternate settings are beyond the scope of this document. However, their use is intentionally not restricted because the authors anticipate that implements will devise additional creative uses for alternate settings. 4.4 Commands Description The protocol implemented in the AT90USB bootloader allows to: • Initiate the communication • Program the Flash or EEPROM Data • Read the Flash or EEPROM Data • Program Configuration Information • Read Configuration and Manufacturer Information • Erase the Flash • Start the application Overview of the protocol is detailed in “Appendix-A” on page 18. 5 7618C–AVR–07/08 4.5 4.5.1 Device Status Get Status The Host employs the DFU_GETSTATUS request to facilitate synchronization with the device. This status gives information on the execution of the previous request: in progress/OK/Fail/... bmRequestType 1010 0001b 0010 0001b bRequest DFU_GETSTATUS (3) DFU_CLRSTATUS (4) wValue Zero Zero wIndex Interface (4) Interface (4) wLength 6 Zero Data Status none The device responds to the DFU_GETSTATUS request with a payload packet containing the following data: Table 4-4. Offset 0 DFU_GETSTATUS Response Field bStatus Size 1 Value Number Description An indication of the status resulting from the execution of the most recent request. 1 bwPollTimeOut 3 Minimum time in milliseconds that the host should wait before sending a subsequent DFU_GETSTATUS. The purpose of this field is to allow the device to dynamically adjust the amount of Number time that the device expects the host to wait between the status phase of the next DFU_DNLOAD and the subsequent solicitation of the device’s status via DFU_GETSTATUS. An indication of the state that the device is going to Number enter immediately following transmission of this response. Index Index of status description in string table. 4 bState 1 5 iString 1 Table 4-5. Status OK errTARGET errFILE errWRITE errERASE bStatus values Value 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A Description No error condition is present File is not targeted for use by this device File is for this device but fails some vendor-specific verification test Device id unable to write memory Memory erase function failed Memory erase check failed Program memory function failed Programmed memory failed verification Cannot program memory due to received address that is out of range Received DFU_DNLOAD with wLength = 0, but device does not think it has all the data yet. Device’s firmware is corrupted. It cannot return to run-time operations errCHECK_ERAS ED errPROG errVERIFY errADDRESS errNOTDONE errFIRMWARE 6 7618C–AVR–07/08 Status errVENDOR errUSBR errPOR errUNKNOWN errSTALLEDPK Value 0x0B 0x0C 0x0D 0x0E 0x0F Description iString indicates a vendor-specific error Device detected unexpected USB reset signaling Device detected unexpected power on reset Something went wrong, but the device does not know what it was Device stalled an unexpected request Table 4-6. State appIDLE appDETACH dfuIDLE bState Values Value 0 1 2 3 4 5 Description Device is running its normal application Device is running its normal application, has received the DFU_DETACH request, and is waiting for a USB reset Device is operating in the DFU mode and is waiting for requests Device has received a block and is waiting for the Host to solicit the status via DFU_GETSTATUS Device is programming a control-write block into its non volatile memories Device is processing a download operation. Expecting DFU_DNLOAD requests Device has received the final block of firmware from the Host and is waiting for receipt of DFU_GETSTATUS to begin the Manifestation phase dfuDNLOAD-SYNC dfuDNBUSY dfuDNLOAD-IDLE dfuMANIFEST-SYNC 6 or device has completed the Manifestation phase and is waiting for receipt of DFU_GETSTATUS. dfuMANIFEST dfuMANIFEST-WAITRESET dfuUPLOAD-IDLE dfuERROR 7 8 Device is in the Manifestation phase. Device has programmed its memories and is waiting for a USB reset or a power on reset. The device is processing an upload operation. Expecting DFU_UPLOAD requests. An error has occurred. Awaiting the DFU_CLRSTATUS request. 9 10 4.5.2 Clear Status Each time the device detects and reports an error indication status to the host in response to a DFU_GETSTATUS request, it enters the dfuERROR state. After reporting any error status, the device can not leave the dfuERROR state, until it has received a DFU_CLRSTATUS request. Upon receipt of DFU_CLRSTATUS, the device sets status to OK and move to the dfuIDLE state. Once the device is in the dfuIDLE state it is then able to move to other states. bmRequestType 0010 0001b bRequest DFU_CLRSTATUS (4) wValue Zero wIndex Interface (4) wLength 0 Data None 7 7618C–AVR–07/08 4.5.3 Device State The state reported is the current state of the device up to transmission of the response. The values specified in the bState field are identical to those reported in DFU_GETSTATUS. bmRequestType 1010 0001b bRequest DFU_GETSTATE (5) wValue Zero wIndex Interface (4) wLength 1 Data State 4.5.4 DFU_ABORT request The DFU_ABORT request forces the device to exit from any other state and return to the DFU_IDLE state. The device sets the OK status on receipt of this request. For more information, see the corresponding state transition summary. bmRequestType 1010 0001b bRequest DFU_ABORT (6) wValue Zero wIndex Interface (4) wLength 0 Data None 4.6 Programming the Flash or EEPROM Data The firmware image is downloaded via control-write transfers initiated by the DFU_DNLOAD class-specific request. The host sends between bMaxPacketSize0 and wTransferSize bytes to the device in a control-write transfer. Following each downloaded block, the host solicits the device status with the DFU_GETSTATUS request. As described in the USB DFU Specification, "Firmware images for specific devices are, by definition, vendor specific. It is therefore required that target addresses, record sizes, and all other information relative to supporting an upgrade are encapsulated within the firmware image file. It is the responsibility of the device manufacturer and the firmware developer to ensure that their devices can process these encapsulated data. With the exception of the DFU file suffix, the content of the firmware image file is irrelevant to the host." Firmware image: • 32 bytes: Command • X bytes: X is the number of byte (00h) added before the first significant byte of the firmware. The X number is calculated to align the beginning of the firmware with the flash page. X = start_address [32]. For example, if the start address is 00AFh (175d), X = 175 [32] = 15. • The firmware • The DFU Suffix on 16 Bytes. Table 4-7. Offset -0 -4 DFU File Suffix Field dwCRC bLength Size 4 1 Value Number 16 5 : 44h Description The CRC of the entire file, excluding dwCRC The length of this DFU suffix including dwCRC -5 ucDfuSignature 3 6 : 46h 7 : 55h The unique DFU signature field -8 bcdDFU 2 BCD 0100h DFU specification number 8 7618C–AVR–07/08 Offset -10 Field idVendor Size 2 Value ID Description The vendor ID associated with this file. Either FFFFh or must match device’s vendor ID The product ID associated with this file. Either FFFFh or must match the device’s product ID The release number of the device associated with this file. Either FFFFh or a BCD firmware release or version number -12 idProduct 2 ID -14 bcdDevice 2 BCD 4.6.1 Request From Host bmRequestType 0010 0001b bRequest DFU_DNLOAD (1) wValue wBlock wIndex Interface (4) wLength Length Data Firmware 4.6.1.1 Write Command data[0] 00h start_address 01h end_address Init EEPROM programming data[1] data[2] data[3] data[4] Description Init FLASH programming Command Identifier Id_prog_start 01h The write command is 6 bytes long. In order to meet with the USB specification of the Control type transfers, the write command is completed with 26 (= 32 - 6) non-significant bytes. The total length of the command is then 32 bytes, which is the length of the Default Control Endpoint. 4.6.1.2 Firmware The firmware can now be downloaded to the device. In order to be in accordance with the Flash page size (128 bytes), X non-significant bytes are added before the first byte to program. The X number is calculated to align the beginning of the firmware with the Flash page. X = start_address [32]. For example, if the start address is 00AFh (175d), X = 175 [32] = 15. 4.6.1.3 DFU Suffix The DFU suffix of 16 bytes is added just after the last byte to program. This suffix is reserved for future use. 9 7618C–AVR–07/08 Figure 4-1. Example of Firmware Download Zero Length DFU_DNLOAD Request SETUP OUT OUT OUT DFU_DNLOAD Prog_Start + (EP0 fifo length - 6) x 00h X offset bytes + Firmware Packet 1 Firmware Packet 2 OUT IN Firmware Packet n + DFU suffix ZLP The Host sends a DFU_DNLOAD request with Zero Length Packet (ZLP) to indicate that it has completed transferring the firmware image file. This is the final payload packet of a download operation. 4.6.1.4 Answers from Bootloader After each program request, the Host can request the device state and status by sending a DFU_GETSTATUS message. If the device status indicates an error, the host must send a DFU_CLRSTATUS request to the device. 4.7 Reading the Flash or EEPROM Data The flow described below allows the user to read data in the Flash memory or in the EEPROM data memory. A blank check command on the Flash memory is possible with this flow. This operation is performed in 2 steps: • DFU_DNLOAD request with the read command (6 bytes) • DFU_UPLOAD request which correspond to the previous command. 10 7618C–AVR–07/08 4.7.1 First Request from Host The Host sends a DFU Download request with a Display command in the data field. SETUP OUT IN DFU_DNLOAD Display_Data (6 bytes) ZLP Command Identifier data[0] 00h data[1] data[2] data[3] data[4] Description Display FLASH Data Id_display_data 03h 01h 02h start_address end_address Blank Check in FLASH Display EEPROM Data 4.7.2 Second Request from Host The Host sends a DFU Upload request. Answers from the Device The device sends to the Host the firmware from the specified start address to the specified end address. 4.7.3 SETUP IN IN DFU_UPLOAD Firmware Packet 1 Firmware Packet 2 IN OUT Firmware Packet n ZLP 11 7618C–AVR–07/08 4.7.4 Answers from the Device to a Blank Check Command The Host controller sends a GET_STATUS request to the device. Once internal blank check has been completed, the device sends its status. • If the device status is “OK”: the device memory is then blank and the device waits for the next Host request. • If the device status is “errCHECK_ERASED”: the device memory is not blank. The device waits for an DFU_UPLOAD request to send the first address where the byte is not 0xFF. 4.8 Reading Configuration Information or Manufacturer Information The flow described hereafter allows the user to read the configuration or manufacturer information. 4.8.1 Requests From Host To start the programming operation, the Host sends DFU_DNLOAD request with the Read command in the data field (2 bytes). SETUP OUT IN DFU_DNLOAD Read_command (2 bytes) ZLP Command Identifier data[0] data[1] 00h data[2] data[3] data[4] Description Read Bootloader Version Read Device boot ID1 Read Device boot ID2 Read Manufacturer Code Read Family Code Read Product Name Read Product Revision 00h 01h 02h Id_read_command 05h 01h 30h 31h 60h 61h 4.8.2 Answers from Bootloader The device has two possible answers to a DFU_GETSTATUS request: • If the chip is protected from program access, an “err_VENDOR” status is returned to the Host. • Otherwise, the device status is “OK“. The Host can send a DFU_UPLOAD request to the device in order to get the value of the requested field. 12 7618C–AVR–07/08 SETUP IN OUT DFU_UPLOAD Byte value (1 byte) ZLP 4.9 Erasing the Flash The flow described below allows the user to erase the Flash memory. The Full Chip erase command erases the whole Flash. 4.9.1 Request from Host To start the erasing operation, the Host sends a DFU_DNLOAD request with a Write Command in the data field (2 bytes). Command Identifier Id_write_command 04h data[0] 00h data[1] FFh data[2] data[3] data[4] Description Full chip Erase (bits at FFh) 4.9.2 Answers from Bootloader The device has two possible answers to a DFU_GETSTATUS request: • If the chip is protected from program access, an “err_WRITE” status is returned to the Host. • Otherwise, the device status is “OK“. 4.10 Starting the Application The flow described below allows to start the application directly from the bootloader upon a specific command reception. Two options are possible: • Start the application with an internal hardware reset using watchdog. When the device receives this command the watchdog is enabled and the bootloader enters a waiting loop until the watchdog resets the device. Start the application without reset. A jump at the address 0000h is used to start the application without reset. • To start the application, the Host sends a DFU_DNLOAD request with the specified application start type in the data field (3 or 5 bytes). This request is immediately followed by a second DFU_DNLOAD request with no data field to start the application with one of the 2 options. 13 7618C–AVR–07/08 Important note: The bootloader performs a watchdog reset to generate the “hardware reset” that allows to execute the application section. After a watchdog reset occurs, the AVR watchdog is still running, thus the application should take care to disable watchdog at program start-up (otherwise the application that does not manage the hardware watchdog will run in an infinite reset loop). 4.11 Request From Host SETUP IN OUT DFU_UPLOAD Jump Option (3 or 5 Bytes) ZLP SETUP DFU_UPLOAD Command Identifier Id_write_command 04h data[0] data[1] 00h data[2] data[3] data[4] Description Hardware reset 03h 01h address LJMP address 4.12 Answer from Bootloader No answer is returned by the device. 5. Security When the USB bootloader connection is initiated, the bootloader automatically enters a read/write software security mode (independent of the product lock bits settings). This allows to protect the on-chip flash content from read/write access over the USB interface. Thus the only DFU command allowed after a USB bootloader connection is a “Full Chip Erase” command. After this “Full Chip Erase” has been received and properly executed, all DFU commands are allowed, and thus the on-chip flash can be reprogrammed and verified. 14 7618C–AVR–07/08 6. Accessing the Low level Flash Drivers The AT90USB USB bootloader is located in the boot section of the on-chip flash memory, meanwhile the bootloader section is the unique memory location allowed to execute on-chip flash memory write operations (SPM instruction is decoded only in this section). Thus applications which require on-chip flash write access can perform calls to specific entry points located in the USB bootloader. The USB bootloader provides several Application Programming Interfaces (API) that allows the application to access low level flash drivers located in the boot section. These APIs allow the following operations: • Page Erase • Page Write • Load word in the temporary page buffer Figure 6-1. USB bootloader API calls USB Bootloader API entry points Boot section On-Chip flash Request: "Page Erase" "Page Write" "Load Word" Low level flash drivers Low Level Flash Operations Application Application section Target Page modified 15 7618C–AVR–07/08 The API are located at absolute addresses in the USB bootloader firmware and accept specific registers values as parameters. These parameters are compatible with a C compiler calling convention and thus can be called directly with function pointer declared as in the example below: C Code Example #if (FLASH_END==0x1FFFF) //128K bytes parts #define LAST_BOOT_ENTRY 0xFFFE #elif (FLASH_END==0xFFFF)//64K bytes parts #define LAST_BOOT_ENTRY 0x7FFE #else #error You must define FLASH_END in bytes. #endif // These functions pointers are used to call functions entry points in bootloader void (*boot_flash_page_erase_and_write)(unsigned long adr)=(void (*)(unsigned long))(LAST_BOOT_ENTRY-12); U8 (*boot_flash_read_sig) (unsigned long adr)=(U8 (*)(unsigned long))(LAST_BOOT_ENTRY-10); U8 (*boot_flash_read_fuse) (unsigned long adr)=(U8 (*)(unsigned long))(LAST_BOOT_ENTRY-8); void (*boot_flash_fill_temp_buffer) (unsigned int data,unsigned int adr)=(void (*)(unsigned int, unsigned int))(LAST_BOOT_ENTRY-6); void (*boot_flash_prg_page) (unsigned long adr)=(void (*)(unsigned long))(LAST_BOOT_ENTRY-4); void (*boot_flash_page_erase) (unsigned long adr)=(void (*)(unsigned long))(LAST_BOOT_ENTRY-2); void (*boot_lock_wr_bits) (unsigned char val)=(void (*)(unsigned char))(LAST_BOOT_ENTRY); // This function writes 0x55AA @ 0x1200 in the on-flash calling flash drivers located in USB bootloader void basic_flash_access(void) { unsigned long address; unsigned int temp16; temp16=0x55AA; address=0x12000; (*boot_flash_fill_temp_buffer)(temp16,address); (*boot_flash_page_erase)(address); (*boot_flash_prg_page)(address); } The full assembly code for the flash API drivers is given in “Appendix-B” on page 20. 16 7618C–AVR–07/08 7. Using the USB bootloader for In System Programming Flip software is the PC side application used to communicate with the USB bootloader (Flip is available for free on the Atmel website). For detailed instructions about using Flip and USB bootloader, please refer to AVR282: “USB Firmware Upgrade for AT90USB” (doc 7769). 17 7618C–AVR–07/08 8. Bootloader History The following table shows the different bootloader revision and associated changes. Table 8-1. Product AT90USB1287 AT90USB1286 AT90USB647 AT90USB646 1.0.0 AT90USB162 AT90USB82 1.0.1 1.0.5 ATmega32U4 ATmega16U4 1.0.0 Initial Revision Allow to use 16MHz cristal with 3.3V power supply and CKDIV8 fuse. Improved USB autobaud process Initial Revision 1.0.1 Initial Revision USB Bootloader History Bootloader Revision Changes 9. Appendix-A Table 9-1. Summary of Frames from Host data[0] 00h start_address 01h 00h Id_display_data 03h 01h 02h 00h Id_write_command 04h 03h 01h 00h 00h 01h 02h Id_read_command 05h 01h 30h 31h 60h 61h Id_change _base _address 06h address LJMP address Read Bootloader Version Read Device boot ID1 Read Device boot ID2 Read Manufacturer Code Read Family Code Read Product Name Read Product Revision Select “PP” 64kBytes flash page number FFh 00h start_address end_address end_address Init EEPROM programming Display FLASH Data Blank Check in FLASH Display EEPROM Data Full chip Erase (bits at FFh) Hardware reset data[1] data[2] data[3] data[4] Description Init FLASH programming Command Identifier Id_prog_start 01h 03h 00 “PP” 18 7618C–AVR–07/08 Table 9-2. 0010 0001b 0010 0001b 1010 0001b 1010 0001b 0010 0001b 1010 0001b 0010 0001b DFU Class-specific Requests bRequest DFU_DETACH (0) DFU_DNLOAD (1) DFU_UPLOAD (2) DFU_GETSTATUS (3) DFU_CLRSTATUS (4) DFU_GETSTATE (5) DFU_ABORT (6) wValue wTimeout wBlock wBlock Zero Zero Zero Zero wIndex Interface (4) Interface (4) Interface (4) Interface (4) Interface (4) Interface (4) Interface (4) wLength Zero Length Length 6 Zero 1 Zero Data none Firmware Firmware Status none State none bmRequestType 19 7618C–AVR–07/08 10. Appendix-B ;*A************************************************************************ ** ; $RCSfile: flash_boot_drv.s90,v $ ;--------------------------------------------------------------------------; Copyright (c) Atmel. ;--------------------------------------------------------------------------; RELEASE: ; REVISION: ; FILE_CVSID: $Name: $ $Revision: 1.7 $ $Id: flash_boot_drv.s90,v 1.7 2005/10/03 15:50:12 $ ;--------------------------------------------------------------------------; PURPOSE: ; This file contains the low level driver for the flash access ;************************************************************************** ** NAMEflash_drv(16) ;_____ I N C L U D E S ______________________________________________________ #define ASM_INCLUDE #include "config.h" ;************************************************************************** ** ; This is the absolute table entry points for low level flash drivers ; This table defines the entry points that can be called ; from the application section to perform on-chip flash operations: ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;************************************************************************** ** ASEG FLASH_END-0x0001B entry_flash_page_erase_and_write: entry_flash_page_erase: R18:17:R16: The byte address of the page entry_flash_prg_page: R18:17:R16: The byte address of the page entry_flash_fill_temp_buffer: data16 : address: R16/R17: word to load in the temporary buffer. R18/R19: address of the word in the temp. buffer. entry_flash_page_erase_and_write: R18:17:R16: The byte address of the page 20 7618C–AVR–07/08 JMP flash_page_erase_and_write entry_flash_read_sig: JMP JMP JMP JMP JMP JMP RSEGBOOT ;*F************************************************************************ ** ; NAME: flash_page_erase_and_write ;--------------------------------------------------------------------------; PARAMS: R18:17:R16: The byte address of the page ;--------------------------------------------------------------------------; PURPOSE: This function can be called for the user appplication ; This function performs an erase operation of the selected target page and ; the launch the prog sequence of the same target page. ; This function allows to save the 256 bytes software temporary buffer in ; the application section ;************************************************************************** ** flash_page_erase_and_write: PUSH POP RET ;*F************************************************************************ ** ; NAME: flash_prg_page ;--------------------------------------------------------------------------; PARAMS: R18:17:R16: The byte address of the page ;--------------------------------------------------------------------------; PURPOSE: Launch the prog sequence of the target page R18 R18 RCALL flash_page_erase RCALL flash_prg_page flash_read_sig flash_read_fuse flash_fill_temp_buffer flash_prg_page flash_page_erase_public lock_wr_bits entry_flash_read_fuse: entry_flash_fill_temp_buffer: entry_flash_prg_page: entry_flash_page_erase: entry_lock_wr_bits: 21 7618C–AVR–07/08 ;************************************************************************** ** flash_prg_page: RCALL MOV MOV OUT LDI SPM RCALL RCALL RET ;*F************************************************************************ ** ; NAME: flash_page_erase ;--------------------------------------------------------------------------; PARAMS: R18:17:R16: The byte address of the page ;--------------------------------------------------------------------------; PURPOSE: Launch the erase sequence of the target page ;--------------------------------------------------------------------------; NOTE: not This function does nt set the RWWSE bit after erase. Thus it does WAIT_SPMEN WAIT_SPMEN R31,R17 R30,R16 RAMPZ, R18 R20,$05 ;(1