|Numéro de publication||US7562360 B2|
|Type de publication||Octroi|
|Numéro de demande||US 10/726,075|
|Date de publication||14 juil. 2009|
|Date de dépôt||1 déc. 2003|
|Date de priorité||1 déc. 2003|
|État de paiement des frais||Payé|
|Autre référence de publication||US20050120343|
|Numéro de publication||10726075, 726075, US 7562360 B2, US 7562360B2, US-B2-7562360, US7562360 B2, US7562360B2|
|Inventeurs||Horng-Ming Tai, Dinghui Richard Nie, Samir Camdzic|
|Cessionnaire d'origine||Texas Instruments Incorporated|
|Exporter la citation||BiBTeX, EndNote, RefMan|
|Citations de brevets (15), Référencé par (9), Classifications (6), Événements juridiques (2)|
|Liens externes: USPTO, Cession USPTO, Espacenet|
The present invention generally relates to data downloading and more particularly to firmware downloading while connected to a host.
Application code (e.g., firmware) for peripheral devices (e.g., Universal Serial Bus (USB) compatible devices) is commonly stored in an on-board non-volatile memory device, such as an Electrically Erasable Programmable Read Only Memory (EEPROM) external to a microcontroller unit (MCU) of the peripheral device. Although employing an external EEPROM provides good field programmability and upgrade capability, downloading the firmware during the Micro Controller Unit's (MCU) power-on boot time is time consuming for some applications. As defined by the Universal Serial Bus (USB) standard, version 2.0 (USB 2), a bus powered device is allowed to spend one hundred milliseconds (100 ms) for external descriptor and firmware downloading after power up and prior to signal connect. For many applications this is not enough time.
For example, the ubiquitous, low cost and widely available I2C EEPROM can be used to store firmware for USB compatible devices. However, the typical I2C EEPROM has either a 100K bit/sec or 400K bit/sec data transfer rate. Thus, a typical 32K-byte firmware download takes 720 milliseconds to complete even when using the 400K bit/sec data transfer rate, which far exceeds the maximum 100 millisecond time requirement allowed by the USB specification.
A current solution for USB devices requires a dummy boot loader and host utility/driver software to first enumerate the dummy boot loader which then starts the firmware downloading process. Enumeration is the process of determining what device has just been connected to the bus and what parameters it requires such as power consumption, number and type of endpoint(s), class of product, etc. The host will then assign the device an address and enable a configuration allowing the device to transfer data on the bus.
After the dummy boot loader finishes the downloading, it performs a pseudo disconnect and re-connect to the USB host controller to re-enumerate the USB peripheral device to a device that matches the functionality defined by the firmware downloaded. A disadvantage of this solution is that the special dummy boot loader requires additional boot code development. Another disadvantage to this solution is that it is necessary to develop a custom host/utility driver software for each operating system. Yet another disadvantage of this solution is potential side effects from the dynamic disconnect and reconnect to the USB host controller because different operating systems can react differently with respect to software timing issues.
The present invention is directed to a method and system for downloading data while connected to a host. For example, the present invention can be executed by a microcontroller of a Universal Serial Bus (USB) compatible device that is downloading application firmware from a non-volatile memory.
One aspect of the present invention is a method for a device to download data from a data source while connected to a host. The method comprises connecting to a host and waiting for a request signal from the host, responding to the request signal with a negative acknowledgement (NAK) to intentionally postpone a response to the request signal, and downloading data from the data source for a predetermined time period based on the request signal.
Another aspect of the present invention relates to a method for a Universal Serial Bus (USB) device to download application firmware while connected to a USB host. The method includes connecting to a USB host and waiting for a request signal from the USB host. Data blocks associated with firmware are downloaded from a data source based on a predetermined time period associated with the request signal type. The waiting for a request signal and the downloading data blocks from the data source is repeated, until the downloading of the firmware is complete.
Another aspect of the present invention relates to a universal serial bus (USB) compatible device. The USB compatible device includes a non-volatile memory (e.g., an EEPROM) having firmware stored therein, and a microcontroller unit (MCU). The MCU configures the device such that the device responds with a negative acknowledgement (NAK) in response to a request signal from a host controller, until downloading of firmware to the MCU has completed.
The foregoing and other aspects of the present invention will become apparent to those skilled in the art to which the present invention relates upon reading the following description with reference to the accompanying drawings.
The present invention is directed to a method and system for enabling a device to download data (e.g., application firmware) from a data source (e.g., an EEPROM), while the device (e.g., a USB compatible peripheral device) is connected to a host (e.g., a USB controller). When the device desires to download data from the data source (e.g., at power up, at device reset), the device waits for a request signal from the host. The request signal is a request for identification, status or data information from the device. The device responds with a negative acknowledgement (NAK) to intentionally postpone transmission of the response to the request signal. The device downloads data from the data source for a predetermined period of time based on the type of request signal received from the host.
The device will repeat the process of transmitting a NAK and downloading data from the data source for a predetermined period of time based on the type of request signal received from the host, until the data download is complete. Once the device has completed the download, it responds normally to the host. The device may use a pointer to track the progress of the download. The pointer may contain the address of the last block of data downloaded, or alternatively the address of the next block of data to be downloaded.
The request signal may be a control transfer. The Universal Serial Bus specification, version 2.0 (USB 2) uses control transfers to exchange device configuration and other information between the device and the host. The control transfer is initiated by the host. As defined by the USB 2 specification, any USB peripheral device is required to return data to the USB host controller within 500 milliseconds when the control transfer has a data stage (data request). If the control transfer is a status request, the peripheral device is required to return status information to the USB host controller within 50 milliseconds.
An aspect of the present invention is to determine whether a control transfer is a data request or a status request and to use the time allotted for responding to the request for downloading firmware. For example, if it is determined that a control transfer is a data request, the device sends a NAK handshake to the USB host and utilizes the allotted 500 milliseconds of time to respond to the request to download firmware from the data source. If the USB host is asking for status information, the mechanism issues a NAK handshake to the USB host, while utilizing the allotted 50 milliseconds of time for firmware downloading.
There are at least two USB control transfers requiring a data stage, which are the Get Device Descriptor and Get Configuration Descriptor. By using the time allotted to respond to these two requests for downloading firmware, the present invention enables the boot code to secure at least 1000 milliseconds for firmware downloading, providing ample time for a typical 32 K byte firmware download that is compatible with USB compatible peripherals using a non-volatile memory, such as an I2C EEPROM, other EEPROM devices, or flash memory.
The present invention does not require a special dummy boot loader, which simplifies boot code development. The present invention does not require a special host utility/driver, thus providing an operating system independent method and system. Another aspect of the present invention is that the device does not have to disconnect and re-connect to the USB host controller.
Upon power up or reset, MCU 108 executes a portion of a boot program, which may be stored in a non-volatile memory (e.g., an EEPROM) 116. Optionally, the boot program may be stored on an internal non-volatile memory (not shown). The portion of the boot program provides the MCU 108 with sufficient program code to communicate with host 102. USB 2 allows MCU 108 to spend one hundred milliseconds (100 ms) for external descriptor and firmware downloading after power up and prior to signal connect. MCU 108 may use this time to begin downloading firmware from EEPROM 116. Pointer 115 would be set to the address the last block read or the next block to be read from EEPROM 116. MCU 108 then connects via interface 110 to USB host controller 106. MCU 108 then waits for USB host controller 106 to initiate a control transfer.
Once a control transfer is initiated, the MCU 108 responds to the USB host controller 106 with a NAK, determines the type of control transfer, uses the time allotted for responding to the control transfer to download firmware from EEPROM 116, and updates pointer 115 accordingly. For example, if the control transfer is a data request type, the download time is based on a first time period (e.g., 500 ms). If the control transfer is a status request type, the download time is based on a second time period (e.g., 50 ms). The firmware can be downloaded based on a respective predetermined time period by employing the timer 118 to monitor the download time. Alternatively, a predetermined number of data blocks or packets can be downloaded within the respective predetermined time period based on one or more downloading parameters (e.g., download data rate, download time period, download block or packet size).
If the download is not completed, MCU 108 waits for another control transfer and again responds to the control transfer with a NAK, determines the type of control transfer, using the time allotted for responding to the control transfer to download firmware from EEPROM 116, and updates pointer 115 accordingly. This process repeats until the firmware download is complete. Once the firmware download is complete MCU 108 executes the downloaded application code and responds to subsequent signal request by the host in a normal manner.
A boot program 208 is provided that contains the bootstrap program for MCU 202. Boot program 208 can be stored in non-volatile random access memory (NV-RAM), such as a boot ROM. Alternatively, a portion of boot program 208 can be stored in boot ROM and the remainder of the boot program 208 can be stored elsewhere such as an EEPROM located locally or remotely, providing that the boot program stored in the boot ROM is sufficient to enable the MCU 202 to communicate with the EEPROM A request type routine 212 determines the request type of the request signal by the host (not shown) and sets a time period for firmware downloading based on the request type. The request type routine 212 can also determine the number of data blocks to be downloaded in the set time period.
Host interface 218 handles communication between the MCU 202 and the host (not shown). Firmware download module and pointer 216 handles the actual downloading of data, such as application firmware, from a data source. The pointer (not shown) is used to track the progress of the download and may store either the address of the last block of data downloaded or the address of the next block of data to be downloaded.
While, for purposes of simplicity of explanation, methodologies are shown and described as executing serially, it is to be understood and appreciated that the present invention is not limited by the order shown, as some aspects may, in accordance with the present invention, occur in different orders and/or concurrently from that shown and described herein. Moreover, not all features shown or described may be needed to implement a methodology in accordance with the present invention. Additionally, such methodologies can be implemented in hardware, software or a combination of hardware and software.
At 310, the device begins downloading firmware. USB 2 allows a device 100 milliseconds for descriptor and firmware downloading after power up and prior to signal connect. Therefore, the device would have about 100 milliseconds, the time that was spent to read and process the descriptor blocks at 308, to download firmware. At 312, a pointer is set to the address of the last block of firmware downloaded. Alternatively, the pointer may be set to the address of the next block of firmware to be downloaded. The methodology then advances to 314.
At 314, the MCU connects to the host, for example, by transmitting identification information to the host during initialization. At 316, the MCU waits for a request signal from the host. For example, a request signal can be a data request signal type or a status request signal type. Once the MCU receives a request signal from the host, the MCU responds with a NAK at 318. The NAK intentionally postpone transmission of the response to the request signal. At 320, firmware is downloaded from the EEPROM for a predetermined time period. The predetermined time period depends on the type of request signal (e.g., 500 milliseconds for a data request and 50 milliseconds for a status request). A predetermined number of data blocks or packets can be downloaded based on the predetermined time period and one or more additional downloading parameters (e.g., download data rate, download block or packet size).
A pointer that is tracking the progress of the firmware download is then updated at 322. At 324, the MCU sends a response to the request to the host. At 326, it is determined whether the firmware download is complete. If at 326, it is determined that the firmware download from the EEPROM is not complete (NO), the MCU returns to 316 to wait for another request signal. If at 326, the firmware download is determined to be complete (YES), the methodology proceeds to 328. At 328, control is released to the application firmware.
At 504, the download pointer is retrieved associated with the last block or packet of data downloaded. At 506, the request type (e.g., status request type, data request type) is determined. At 508, a download time period is determined based on the request type. For example, the download time period can be a first time period (e.g., 500 ms) for a data request, and a second time period (e.g., 50 ms) for a status request.
At 510, the number data blocks or data packets that can be downloaded from firmware are determined based on the download time period and other download parameters (e.g., download data rate, download block or packet size). The methodology then proceeds to 510. At 512, the data blocks or data packets are downloaded from firmware based on the download time period and other download parameters (e.g., download data rate, download block or packet size). For example, a loop counter can be set to different values based on download parameters and a request type. The value of the loop counter can correspond to the number of data blocks or data packets to be downloaded in a given download period. At 514, the download pointer is updated based on the last data block or data packet downloaded. The methodology then proceeds to 516 to determine if the download has been completed. If the firmware download has not completed (NO), the methodology returns to 502 to wait for another request signal and repeat the process 500. If the firmware download has completed (YES), the methodology exits and the USB device returns to normal operation.
What has been described above includes exemplary implementations of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the present invention, but one of ordinary skill in the art will recognize that many further combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.
|Brevet cité||Date de dépôt||Date de publication||Déposant||Titre|
|US6145045 *||7 janv. 1998||7 nov. 2000||National Semiconductor Corporation||System for sending and receiving data on a Universal Serial Bus (USB) using a memory shared among a number of end points|
|US6311294 *||20 oct. 1998||30 oct. 2001||Cypress Semiconductor Corp.||Device and method for efficient bulk data retrieval using a universal serial bus|
|US6357021 *||14 avr. 1999||12 mars 2002||Mitsumi Electric Co., Ltd.||Method and apparatus for updating firmware|
|US6415342 *||27 juil. 1999||2 juil. 2002||Hewlett-Packard Company||Universal serial bus controlled connect and disconnect|
|US6467087 *||16 déc. 1999||15 oct. 2002||Destiny Technology Corporation||Method for updating a printer firmware|
|US6516359 *||28 avr. 1999||4 févr. 2003||Clarion Co., Ltd.||Information processing method and apparatus, automotive information system and method of controlling the same, and storage medium on which an information processing program is stored|
|US6574309 *||1 mars 2000||3 juin 2003||Turnstone Systems, Inc.||Remotely actuated splittler bypass system and method|
|US6622246 *||12 nov. 1999||16 sept. 2003||Xerox Corporation||Method and apparatus for booting and upgrading firmware|
|US6708231 *||12 août 1999||16 mars 2004||Mitsumi Electric Co., Ltd.||Method and system for performing a peripheral firmware update|
|US6898751 *||31 juil. 2002||24 mai 2005||Transdimension, Inc.||Method and system for optimizing polling in systems using negative acknowledgement protocols|
|US6907602 *||9 sept. 2003||14 juin 2005||Mustek Systems Inc.||Method for updating firmware of computer device|
|US6944854 *||30 nov. 2000||13 sept. 2005||International Business Machines Corporation||Method and apparatus for updating new versions of firmware in the background|
|US6996708 *||30 sept. 2002||7 févr. 2006||Ncr Corporation||Methods and apparatus for automatically selecting and loading initialization software for a hardware configuration|
|US7000057 *||11 févr. 2002||14 févr. 2006||Cypress Semiconductor Corp.||Method and apparatus for adding OTG dual role device capability to a USB peripheral|
|US20030217254 *||9 mai 2002||20 nov. 2003||Page James W.||Method and apparatus for programming non-volatile, programmable, electrically erasable memory using a USB interface|
|Brevet citant||Date de dépôt||Date de publication||Déposant||Titre|
|US7844766 *||3 oct. 2008||30 nov. 2010||XETA Technologies, Inc.||System and method for location specific computer enabled services/monitoring|
|US8032881 *||4 oct. 2011||Axis Ab||Method and system for upgrading a plurality of devices|
|US8473666 *||27 juin 2011||25 juin 2013||Schneider Electric It Corporation||Systems and methods for driverless operation of USB device|
|US8813061 *||16 oct. 2013||19 août 2014||Movimento Group||Module updating device|
|US9003097 *||7 oct. 2010||7 avr. 2015||Biglobe Inc.||Information transfer apparatus, information transfer system and information transfer method|
|US9128798||31 juil. 2014||8 sept. 2015||Movimento Group||Module updating device|
|US20070250830 *||28 févr. 2007||25 oct. 2007||Jonas Holmberg||Method and system for upgrading a plurality of devices|
|US20110196992 *||11 août 2011||Wistron Corporation||Method for dismounting a storage device, and computer program product and electronic apparatus for implementing the method|
|US20120246378 *||7 oct. 2010||27 sept. 2012||Nobuyuki Enomoto||Information transfer apparatus, information transfer system and information transfer method|
|Classification aux États-Unis||717/178, 717/173|
|Classification internationale||G06F9/445, G06F9/44|
|1 déc. 2003||AS||Assignment|
Owner name: TEXAS INSTRUMENTS INCORPORATED, TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TAI, HORNG-MING;NIE, DINGHUI RICHARD;CAMDZIC, SAMIR;REEL/FRAME:014777/0162;SIGNING DATES FROM 20031124 TO 20031125
|2 janv. 2013||FPAY||Fee payment|
Year of fee payment: 4