Maintaining at least partial functionality of a device as...

Electrical computers and digital data processing systems: input/ – Input/output data processing – Peripheral configuration

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C710S104000, C713S001000, C713S100000, C711S103000

Reexamination Certificate

active

06795872

ABSTRACT:

BACKGROUND
The present invention is related to programming non-volatile memory, and more particularly to methods and apparatus for programming electrically erasable non-volatile memory using a Universal Serial Bus (USB) interface.
USB is fast becoming the defacto bus interface standard for low to medium speed personal computer (PC) to peripheral device interconnections. The USB interface achieves transport speeds that are fast enough for supporting high-speed printers, CD-quality audio playback, and high-resolution scanners. USB expansion hubs make the bus available for supporting dozens of USB capable devices simultaneously. Detailed information regarding USB functionality and capabilities may found in the Universal Serial Bus Specification, Revision 2.0 (Apr. 27, 2000).
USB has gained popularity for several reasons. First, a USB device can be plugged into the bus at anytime, even when the PC is turned on; a feature commonly referred to in industry as “plug-n-play”. When the PC detects that a USB device has been plugged in, the PC automatically interrogates the device to learn its capabilities and requirements. Using this information, the PC then automatically loads the device's driver into the operating system. Later, when the device is unplugged from the bus, the operating system automatically “logs off” the device from the bus, and unloads its driver from the system.
Another reason for the growing popularity of the USB interface is that the built-in plug-n-play capability eliminates the need to manually set DIP switches, insert jumpers, or load configuration programs, in order to properly configure devices attached to the bus. Also, USB connected devices do not result in the hardware conflicts (e.g., IRQ, DMA, MEMORY, or I/O conflicts) that commonly occur when connecting devices to today's conventional serial and parallel I/O buses.
USB devices are sold with internally stored software (or firmware) that controls the operation of the device. This firmware is typically stored in non-volatile, electrically erasable, programmable memory, such as the popular flash memory developed by Intel Corporation. Users that have purchased USB capable devices may occasionally require the ability to upgrade this firmware with improved versions, or with firmware patches, as such upgrades become available from the device manufacturers.
These firmware upgrades may be effected in several ways. For example, if the firmware is stored on a separate memory module in the device, the module may be removed from the device and replaced with a new memory module that includes the firmware updates. This manual upgrade method has the disadvantages of being both difficult and time consuming to perform, as well as typically requiring that the device be powered off to effect the upgrade. Also, this manual method requires the firmware to be stored on a dedicated memory module within the device, which may lead to inefficient use of memory in the device.
An easier and more efficient method of upgrading the firmware installed in a peripheral device has been to use an existing device I/O bus to upgrade the firmware code. With this method, either the entire firmware program may be first erased, and then overwritten with the new firmware code, or only a portion of the originally installed firmware may be overwritten with a corresponding firmware “patch”.
Alternatively, the hardware may be so configured so as to allow firmware patches to be installed in specially reserved portions of the system memory, and then automatically executed under certain program conditions to effect a firmware upgrade. Such an arrangement is described in copending U.S. patent application Ser. No. 09/896,780, entitled “Method and Apparatus for Dynamically Modifying a Stored Program”, assigned to the same assignee as this application.
To use an existing I/O bus to upgrade the firmware code stored in device, it is first necessary to develop a transfer protocol that controls and oversees the firmware upgrade process. Generally, a different transfer protocol must be developed for each corresponding I/O bus type used to upgrade the firmware.
In the case of USB, a transfer protocol for effecting firmware upgrades in USB capable devices has been proposed by the USB Implementors Forum (USB-IF). This group has published a document for its proposed transfer protocol entitled “Universal Serial Bus Device Class Specification for Device Firmware Upgrade”, Version 1.0, May 13, 1999. This document describes proposed requirements and specifications for implementing USB devices that are capable of supporting the group's proposed Device Firmware Upgrade (DFU) function.
A drawback of the proposed DFU solution is that concurrent execution of both DFU operations and normal run-time activities is not possible within the USB device. The proposed specification requires that all normal run-time activities must cease for the duration of any DFU (upgrade) operations. This implementation thus requires that a device re-enumerate, or change its operating mode, to effect a firmware upgrade. For example, according to the proposed specification, a printer would not function as a printer while undergoing a firmware upgrade. Instead, the printer would be operating as a firmware programmer during DFU operations. This is due, at least in part, to the fact that under the DFU proposal, only a single endpoint (or channel) is active between the programming host and the USB device. Typically, re-enumeration requires that the device be physically disconnected from the USB bus. In contrast, the techniques described below employ several endpoints between the host and USB device to maintain normal device operations, even while the device firmware is being programmed or updated.
The type of memory programming described in the DFU proposal is referred to as “in-circuit” programming. While the memory need not be removed from its circuitry, the device nevertheless no longer operates in its normal mode during the programming phase. In-circuit programming is to be contrasted with in-system programming (a feature of the techniques described herein), in which a device continues to operate (at least partially) in its normal mode of operation during the programming process. Another important advantage to programming device firmware in-system is that host device drivers, used to communicate with the device during its operation, need not be uninstalled while the firmware is being programmed, and then reinstalled when the programming process has ended. Not having to uninstall then reinstall device drivers saves time and host system resources.
Others have approached the problem of effecting firmware upgrades in USB devices in an entirely different manner. For example, Cypress Semiconductor offers a solution called “EZ-USB”, that includes an internal microprocessor and internal random access memory (RAM) for program and data storage in the USB device itself. The use of volatile RAM to store the device firmware, rather the non-volatile memory used in other USB devices, makes the EZ-USB product a so-called “soft solution” product. During normal operation, a USB host (e.g., the PC) may initiate a download of program instructions into the device internal microprocessor, and device “personality” firmware into the device internal RAM over the USB bus. After the download completes, the EZ-USB device is reconnected to the PC as a newly customized device defined by the downloaded personality firmware.
Although this solution does provide for the ability to download new firmware over a USB interface at any time during device operation, the solution nevertheless has some drawbacks. First, because the firmware is stored in RAM instead of some other form of non-volatile memory, the firmware will be lost should power to the device ever be inadvertently disconnected during operation. Firmware loss may also occur if the device is mistakenly disconnected from the USB interface in bus-powered devices. Second, whenever a firmware download is initiated by the PC host, the EZ-USB device must first be discon

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Maintaining at least partial functionality of a device as... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Maintaining at least partial functionality of a device as..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Maintaining at least partial functionality of a device as... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-3245009

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.