CA2459179A1 - Method for automatically recovering from a suspend state in a usb interface - Google Patents

Abstract

There is provided a method for attempting to reset a host or hub connected via a USB bus to a remote device. A routine in the firmware of the remote device monitors the USB bus to detect an unannounced and unanticipated SUSPEND state on the bus. When such a SUSPEND state is detected, a firmware routine forces a disconnect of the peripheral device from the USB bus by dropping the D+
signal. After a predetermined time, D+ is again presented to the bus and the host reconnects the remote device and reestablishes communication with the device. Such an unintended SUSPEND state may be caused by problems such as noise on the bus. Because typically no permanent hardware failure has taken place, the re-attachment process initiated by the remote device again presenting D+ usually resets the host or hub.

Description

For: METHOD FOR AUTOMATICALLY RECOVERING FROM A SUSPEND STATE
IN A USB INTERFACE
Application Of: Randolph Bullock and Larry R. Jensen Technical Field This invention pertains to error recovery in a device connected to a USB interface and, more particularly, to a method for recovering from a SUSPEND state on a USB bus induced by a transient impulse, noise, etc.
Background Art The lack of flexibility in reconfiguring peripheral devices attached to a computer, host or other controller has long been regarded as the Achilles' heel of the computer industry. The development of user-friendly graphical user interfaces and associated hardware and software have made computers less confrontational and easier to reconfigure.
From an end-user's perspective, however, the input/output (I/O) interfaces in common use have been limiting. The introductions of plug-and-play interfaces, while a step forward, were still limited and often unreliable in their configuration capabilities. In addition, conventional I/0 interfaces "crashed" easily if a peripheral device were added or removed "hot" (i.e., without turning the power off both on the device connected to the interface and on the interface host itself).
The arrival of the Universal Serial Bus (USB) overcame many of these problems. In particular, the USB allows hot connection/disconnection of peripheral devices. Also, the USB
automatically acknowledges the arrival of a newly attached device on the bus with no need to reboot the computer, host or controller to which the device has been added. These two characteristics of the USB have made it an ideal vehicle for the attachment of point-of-sale (POS) devices such as transaction printers to host controllers.
H0085620.1 A serial interface has long been considered desirable for attachment of remote devices such as POS printers to their central controller. Unlike many other interconnection methods, serial interfaces traditionally have required fewer conductors in interconnection cables. Also, greater cable lengths are typically available than are with other interface methods. For many years, the serial interfaces were defined by the RS-232 "standard". Unfortunately, according to at least one industry expert, "the only thing standard about RS
232 is the name." Indeed, very little could be assumed about a device advertising an RS-232 interface. Pinouts on connecters varied, voltage levels varied and signal-timing requirements were rarely standard. Because so many variants of transmission speed (i.e., baud rate), parity and handshaking protocol were used, setting up devices to communicate with one another was rarely simple. The USB
eliminates most of the problems inherent in RS-232, RS-422, and other "standard" prior art serial interconnection strategies while maintaining a small conductor count in the interconnection cables. Typically, up to 127 different USB-equipped devices can be plugged together using one or more USB
hubs with no manual configuration required.
While the introduction of the USB brought the simplicity of true plug-n-play system configuration/ re-configuration, the electrical signaling method and protocol chosen for its implementation is inherently less immune to electrical disturbances (i.e., electrical noise) than were its precursors. For example, the ubiquitous RS-232 interface was often implemented using voltage swings in the range of between ~10 and ~15 volts. The USB standard, on the other hand, recites signal voltage swings of only 0 - 3.3 volts. Although the USB uses differential techniques for purposes of speed, the noise immunity of a 0 - 3.3-volt signal is inherently worse than the ~10 to ~15 volt (i.e., 20 - 30 volt swings) that the RS-232 interfaces utilize.
H0085620.1 2 RS-232 drivers typically can withstand a 2KV or higher electrostatic discharge (ESD) "hit" directly input the port.
The energy is typically dissipated through the driver device's supply pins. The single-chip design of typical USB
transceivers, however, contains both line driver and logic circuitry for the serial interface engine, and FIFO buffers, etc. in close proximity. This means that there is little or no physical isolation between the line drivers, which must absorb and dissipate a noise spike such as an ESD hit, and the far more sensitive logic circuitry. Such circuitry, by virtue of its placement, is far more vulnerable to ESD and other similar spurious signals than older designs wherein the line driver circuitry was typically physically isolated from more sensitive logic circuitry.
Another difference, which makes the USB more noise sensitive, is that each attached device must process a periodic Start Of Frame (e.g., a 1 ms SOF) packet. This is necessary to maintain contact with downstream devices attached to the host via hubs, etc. To stay attached to the bus, each attached device must almost continuously process these SOF
packets. Older, more robust interfaces (e. g., RS-232) could remain quiescent until data transmission or reception was required. The USB remains almost continuously sensitive to noise, whereas the older interfaces are generally insensitive to noise during their quiescent periods.
To compensate for the lower range of signal voltages, the USB incorporates a very good error recovery mechanism buried in its hardware layer. Each data packet transmitted over the USB contains a cyclic redundancy check (CRC) number. This allows the receiver to test each data packet for errors and request a re-transmission when an error occurs. This is accomplished by "NACKing" (i.e., No-Acknowledge) data packets in which errors are detected. Because of this error recovery strategy, the effect of noise on the bus results in an overall slowdown of data transmission because of the many NACKed H0085620.1 packets, but device connection is generally maintained.
The USB standard, however, fails to adequately address the problems associated with ESD sensitivity or the overall network sensitivity caused by the need for almost continuous SOF processing, at least for high reliability applications such as POS printing. While the USB standard requires that each USB device meet CE mark (i.e., the requirements of the European Community European Directive 93/68/EEC), few marked USB products have been found to meet the minimum electromagnetic compatibility (EMC) immunity requirements satisfactorily. Included under the EMC umbrella are electro-static discharge (ESD), electrical fast transients (EFT), radiated RF interference (RFI), and conducted RF interference (CRFI). When an interfering noise condition or event persists over several SOF packets, the host is often prevented from receiving replies to its status requests. At other times and early End-Of-Packet (EOP) or a condition called "babble" EOP may cause the host to terminate its connection with the device. Generally, the host will make no attempt to re-connect a still connected node. Because RS-232 has no provision for built-in CRC or status poling, these types of problems do not occur unless detected by application firmware, software, or driver.
When noise induces a host disconnect, the host typically places the device in a USB suspend state. The only way for a suspended device to recover is either by having the host re-booted or by physically disconnecting from and reconnecting to the USB. The disconnect/re-connect act forces a re-enumeration of the entire USB network. Because of the plug-n-play nature of the USB, this may usually be done without interrupting the host application. However, in the POS
environment, of course, it is not considered good practice for clerks, checkers, or other retail personnel to unplug devices for recovery. In this environment, a re-boot is generally considered more desirable than a physical re-connection of the H0085620.1 device. Because the USB driver stack provides no automatic recovery of a suspended device, it is left to the operator to either re-boot or physically re-connect the device. However, to require that the entire POS system be re-booted to recover from a single device becoming non-communicative is impractical.
While the USB topography is generally good at self-healing, there are certain circumstances peculiar to the POS
environment, which are not well handled in typical systems using USB communication to peripherals. The USB facilitates a constant stream of two-way traffic (i.e., transactions) between the host and each peripheral device, even when no substantive data is being transmitted. Under certain circumstances, a strong noise spike or other perturbation on the interface may cause the host, or sometimes a hub downstream from the host, to stop communicating. When this happens, a remote POS terminal has heretofore had no way to attempt to restart the host and/or hub.
Due to the shortcoming enumerated hereinabove, the USB is better suited to the "home" computer environment than to the commercial and retail environments. First, noise spike in the home computer environment are typically less severe and system re-boot or device re-attachments have become a commonplace and acceptable part of home computer usage. Nonetheless, there is growing demand for the ease of use features of USB in the POS
and other commercial and industrial environments. Devices such as POS printers using a USB interface must be designed and built to meet more stringent immunity requirements.
Discussion of the Related Art:
Automatic recovery of interface errors and/or remotely restarting a computer or host after an error is not new.
United States Patent No. 4,072,852 for DIGITAL COMPUTER
MONITORING AND RESTART CIRCUIT, issued February 7, 1978 to James A. Hogan, et al., teaches a missing pulse detector for monitoring for the periodic occurrence of an output signal H0085620.1 5 from a digital computer. If, after a predetermined amount of time, an output pulse is not detected, a reset signal is generated to restart the computer.
In contradistinction, the method of the present invention relies on an algorithm embedded in the firmware of a remotely located peripheral device, not in a hardware circuit located at the computer or host.
United States Patent No. 4,513,417 for AUTOMATIC
PROCESSOR RESTART CIRCUIT, issued April 23, 1985 to James S.
Lamb, et al., teaches another hardware processor restart implementation. LAMB, et al. teaches the regular monitoring of a regularly serviced processor signal. After a predetermined time without detecting the processor signal, a reset signal to the processor is automatically issued by the circuit.
The method of the present invention, on the other hand, uses no hardware circuit directly connected to the processor.
The inventive algorithm operating on each of a large number of peripheral devices remotely located from the host or processor can initiate a reset of the communications interface. The processor itself does not reset. The inventive method uses an algorithm in the firmware of the peripheral devices to instigate the interface reset.
United States Patent No. 4,618,953 for WATCHDOG CIRCUIT, issued October 21, 1986 to Edward P. Daniels, et al., teaches a circuit arrangement for improving the possibility of recovery from failures caused by static discharge, RF
interference and similar conditions. A main processor periodically sends an inquiry to a secondary processor chip, which handles I/O. If status is not returned by the secondary processor chip within a predetermined amount of time, the DANIELS, et al. circuit initiates a reset of the main processor.
The inventive method does not rely on a hardware circuit but rather is an algorithm forming a part of the firmware H0085620.1 6 operating a POS printer remote from the processor (i.e., host). In the inventive system, the remote device, not the main processor, institutes a reset. The initiation of the inventive reset process does not rely on receiving status information.
United States Patent No. 4,860,289 for RESET CIRCUIT FOR
ELECTRICALLY ISOLATED CIRCUITS COMMUNICATING VIA UART, issued August 22, 1989 to Kenneth A. Coulson, teaches a watchdog circuit for monitoring remote systems via an interrupt or break signal communicated between a master and a slave circuit over a serial interface. The master circuit attempts to reset the slave circuit when a problem is detected.
In the method of the invention, however, software at the slave processor attempts to restart the master when the slave senses that the master has unintentionally gone into a SUSPEND
state. The inventive method relies on software, not a hardware implemented watchdog circuit.
United States Patent No. 5,155,846 for SYSTEM MONITORING
REPLIES TO CONTINUOUSLY TRANSMITTED SIGNAL AND DISCONTINUING
SIGNAL TO FORCE RESET OF REMOTE SYSTEM USING WATCHDOG TIMER, issued October 13, 1992 to Yoshihito Mino, et al., teaches yet another circuit-based watchdog system for restarting a remote device by monitoring a transmitted signal.
The inventive method, however, restarts the master (i.e., host), not the slave circuit, using an algorithm in the remote device firmware, not by a hardware circuit at the master.
While several of the patents discussed hereinabove utilize a watchdog type circuit to initiate a reset, either at the device or at a host, this is very different from a suspend state and a recovery therefrom. Under a reset. condition, whether originated by the host or the device, data present in the device, specifically in the POS printer, is lost. Because the host may have no way to know how much of the data sent to the POS printer was actually printed, an intelligent restart of the printing operation is not possible. The suspend state, H0085620.1 on the other hand, does not lose the data and, if a recovery is possible, allows the printing operation to pick up where it left off before the printer was placed in a suspend state.
The suspend recovery of the present invention is distinguished from the reset strategies of the aforementioned prior art.
SUMMARY OF THE INVENTION
In accordance with the present invention there is provided a method for attempting to reset a host or hub connected via a USB bus to a remote device. A routine in the firmware of the remote device monitors the USB bus to detect an unannounced and unanticipated SUSPEND state on the bus.
Such an unintended SUSPEND state may be caused by problems such as noise on the bus. When such a SUSPEND state is detected, a firmware routine forces a disconnect of the peripheral device from the USB bus by dropping the D+ signal.
After a predetermined time, D+ is again presented to the bus and the host reconnects the remote device and reestablishes communication with the device. Because typically no permanent hardware failure has occurred, the re-attachment process initiated by the remote device again presenting D+ usually resets the host or hub.
It is, therefore, an object of the invention to provide a method to recover from an unintended SUSPEND state on a USB
bus.
It is another object of the invention to provide a method to recover from an unintended SUSPEND state on a USB bus wherein a remote device initiates the resetting activity.
It is a further object of the invention to provide a method to recover from an unintended SUSPEND state on a USB
bus wherein a remote device initiates a disconnect then reconnect operation.
It is yet another object of the invention to provide a method to recover from an unintended SUSPEND state on a USB
bus wherein a remote device disconnects from the USB bus by automatically dropping its D+ or D- signal.
H0085620.1 It is a still further object of the invention to provide a method to recover from an unintended SUSPEND state on a USB
bus wherein a remote device reconnects to the USB bus by automatically raising its D+ or D- signal.
Brief Description of the Drawings A complete understanding of the present invention may be obtained by reference to the accompanying drawings, when considered in conjunction with the subsequent detailed description, in which:
FIGURE 1 is a simplified schematic block diagram of a typical USB interface; and FIGURE 2 is a simplified flow chart of the method of the invention.
Modes For Carrying Out The Invention The present invention provides a method for initiating a reset of the interface of a host or a hub upstream by a remote device connected to the host or hub by a USB connection.
Referring first to FIGURE 1, there is shown a simplified schematic block diagram of a typical USB interface, generally at reference number 100. A Serial Interface Engine (SIE) 102 forms the heart of USB interface 100. SIE 102 contains circuitry within which the entire USB protocol layer is hardwired. A hardwired implementation provides maximum speed and eliminates the need for firmware to accomplish the essential USB interface functions. These functions include synchronization pattern recognition, parallel/serial conversion, bit stuffing/de-stuffing, cyclic redundancy check (CRC) generation and verification, address recognition and handshake evaluation and generation.
SIE 102 is connected to bit clock recovery circuit 104, which is connected to phase locked loop (PLL) 106. In the embodiment chosen for purposes of disclosure, PLL 106 is implemented as a 6 MHz to 48 MHz multiplier which allows the H0085620.1 use of relatively inexpensive 6 MHz crystals. The use of such low frequency crystals also helps minimize problems with electromagnetic interference (EMI) generated by USB interface 100.
Random access memory (RAM) 108 is connected to SIE 102 by memory manager 110. RAM 108 is provided to store both commands and data as required by SIE 102. RAM 108 also serves as a buffer between the USB bus, typically operating in burst mode at approximately 12 MBits per second, and the slower DMA/parallel interface 112. This allows the microcontroller or the processor (not shown) to which the USB interface 100 is attached by interface 112, to read and write USB data packets at its own speed. DMA/parallel interface 112 provides a generic parallel interface bus for connection either to a data bus (not shown) or to a DMA controller (not shown) within the microcontroller to which USB interface 100 is connected.
Interface 112 typically makes USB controller 100 appear as a memory device having an 8-bit data bus and one address bit memory device. Receive data (RxD) and transmit data (TxD) lines 114 and 116, respectively, from SIE 102 are connected to analog transceiver 118. The D+ output 120 and the D- output 122 lines from analog transceiver 118 are connected to a standard USB connector 124, which in turn, is mated with a compatible USB connector 126. Analog transceiver 118 contains termination resistors (not shown) to properly match its input and output lines to the normal USB bus.
Connected to the D+ output 120 of analog transceiver 118 is a pull-up resistor 128, which is in turn connected to a positive DC voltage source 130. Typically, resistor 128 has a resistance of approximately 1500 ohms and DC voltage 130 is typically approximately 3.3 volts. While these values are considered industry standard values, it should be obvious that other voltage/resistor combinations could be used in alternate embodiments to accomplish a similar result.
H0085620.1 10 In the embodiment chosen for purposes of disclosure, SIE
102 is a Phillips USB Interface Device with Parallel Bus, Model No. PDIUSBD12 which contains several functions in addition to SIE 102 (e. g., transceiver 118) within a single package. Many other similar USB integrated interface devices are well known to those skilled in the art and other devices could readily be substituted for the Philips PDIUSBD12 device.
Referring now to FIGURE 2, there is shown a flow chart 200 illustrating the steps of a portion of the inventive reset process. In operation, a host (not shown) transmits start of frame (SOF) packets at predetermined intervals, typically about one every millisecond. Under normal circumstances, these SOF packets are ignored, in fact not even seen by the microcontroller (not shown). If no bus activity including the SOF packets is detected within a nominal time period, say perhaps 3 ms, the USB bus may be assumed to have been placed in SUSPEND state. The SUSPEND state of the USB bus may be directly checked by monitoring the SUSPEND output (typically pin 12) of the Philips PDIUSBD12 device.
There are circumstances where it may be undesirable to directly monitor the SUSPEND output of the USB device. In this case, the SUSPEND status of the USB bus may be verified indirectly by monitoring in firmware the Suspend Change interrupts, step 2,02, which indicate that the bus is either going in or going out of SUSPEND mode. Because it is impossible to tell from a single Suspend Change interrupt whether the bus is going in or out of SUSPEND mode, a timer is set, step 204, to define a window during which the bus will be monitored for the presence of any data, step 206. If data is observed before the timeout of the timer, step 207, control is returned to block 202. If additional data is received before timeout, step 208, it may be assumed that the bus is not in SUSPEND mode. If, however, additional data is not received before timeout, step 208, the configuration of the USB device may be changed, step 210, so that SOF packets are no longer H0085620.1 11 ignored. Another timer period is begun, step 212, and the USB
bus is again monitored for data including SOF packets, step 214. If no data is received during this secondary time period, the assumption is made that the bus is in SUSPEND
mode. The interface is then disconnected from the USB bus by forcing the D+ signal low, step 218. The firmware is typically running on the microcontroller to which USB
interface 100 is attached. Alternatively, if the SUSPEND
output of the USB device could be monitored directly, the system could proceed from step 202, above, to step 218, accomplishing the same result. Likewise, under certain situations, step 204 - 208 could be omitted.
Regardless of which method is used to determine that the USB bus is in SUSPEND mode, the interface 100 is logically removed from the bus by lowering the D+ signal, step 218.
This simulates unplugging the device, an action readily noted by a host or hub. In the present invention, circuitry (not shown) under software control of the firmware is used to virtually unplug the interface 100 from the USB bus. The host or hub must then reconfigure itself to a state absent the peripheral. After a predetermined amount of time, D+ may again be raised, step 220, thereby virtually plugging interface 100 back into the bus. The host/hub upstream must again reconfigure to add the peripheral device attached to interface 100. This action results in resetting at least the port on the host to which interface 100 is connected.
Generally speaking, this action is sufficient to recover from an interface stoppage cause by a noise spike or other such spurious signal on the USB bus.
Referring again to FIGURE 1, when the USB interface 100 is implemented using a Philips PDIUSBD12 device, the pull-up resistor 128 is implemented on the chip but is not permanently connected to a positive DC voltage 130. The connection is made upon execution of the command from the external microcontroller. This feature is known as SoftConnectz'''' in the H0085620.1 12 Philips device. Using this feature simplifies the implementation, but other ways to implement the inventive reset feature are well known to those skilled in the circuit design arts.
Since other modifications and changes varied to fit particular operating conditions and environments or designs will be apparent to those skilled in the art, the invention is not considered limited to the examples chosen for purposes of disclosure, and covers changes and modifications which do not constitute departures from the true scope of this invention.
Having thus described the invention, what is desired to be protected by letters patents is presented in the subsequently appended claims.
H0085820.1 13

Claims (11)

What Is Claimed Is:

1. A method for resetting a USB interface of a host after an interface stoppage, the steps comprising:
a) providing a peripheral device having a first USB interface, said peripheral device being adapted to selectively raise and lower a D+ signal;
b) connecting said peripheral device to a host having a second USB interface, using said first USB interface and said second USB interface and a USB bus therebetween;
c) raising said D+ signal and operating said peripheral device to transmit and receive data across said USB bus to and from said host;
d) monitoring said USB bus for the presence of at least a start-of-frame (SOF) packet transmitted by said host;
e) after a predetermined time, in the absence of said SOF packet, lowering said D+ signal; and f) after a second predetermined time, raising said D+
signal, thereby simulating the physical removal and reinstallation of said peripheral device on said USB bus and forcing a reset of a USB interface of the host.

2. The method for resetting a USB interface of a host after an interface stoppage as recited in claim 1, wherein a stoppage of said second USB interface of said host is indicated by a SUSPEND state on said USB bus.

3. The method for resetting a USB interface of a host after an interface stoppage as recited in claim 2, wherein said first USB interface is implemented using an integrated USB controller device.

4. The method for resetting a USB interface of a host after an interface stoppage as recited in claim 3, wherein said peripheral device comprises a microcontroller having at least a parallel data bus and means for executing at least one instruction, said parallel data bus being operatively connected to said integrated USB controller chip and adapted for data communication thereupon.

5. The method for resetting a USB interface of a host after an interface stoppage as recited in claim 4, wherein said integrated USB controller device comprises a signal representative of said SUSPEND state

6. The method for resetting a USB interface of a host after an interface stoppage as recited in claim 5, wherein said monitoring step (d) comprises monitoring said signal representative of said SUSPEND state by said microcontroller.

7. The method for resetting a USB interface of a host after an interface stoppage as recited in claim 4, wherein said monitoring step (d) comprises monitoring said USB bus for at least a Suspend Change interrupt.

8. The method for resetting a USB interface of a host after an interface stoppage as recited in claim 7, wherein said monitoring step (d) further comprising the sub-steps of:
i) starting a first timer having a first predetermined timeout period;
i) waiting throughout said first predetermined timeout period for any data on said bus;
iii) if no data is received during said first predetermined timeout period, changing the configuration of said integrated USB controller chip so as to force said chip to issue at least one interrupt to detect at least said SOF packet;
iv) starting a second timer having a second predetermined timeout period; and v) waiting through said second predetermined timeout period for said SOF packet.

9. The method for resetting a USB interface of a host after an interface stoppage as recited in claim 4, wherein said lowering said D+ signal step (e) is performed by said integrated USB controller chip upon receipt of a command from said microcontroller presented on said parallel data bus.

10. The method for resetting a USB interface of a host after an interface stoppage as recited in claim 4, wherein said raising said D+ signal step (f) is performed by said integrated USB controller chip upon receipt of a command from said microcontroller presented on said parallel data bus

11. The method for resetting a USB interface of a host after an interface stoppage as recited in claim 4, wherein at least one of said lowering said D+ signal step (e) and said raising said D+ signal step (f) is performed by control means external to said integrated USB controller chip upon receipt of a command from said microcontroller, presented~on said parallel data bus.