System and method for simulating USB smart cards connected to USB host

This invention relates to the field of smart cards, and more particularly, this invention relates to a system and method for simulating USB smart cards.

Smart cards are plastic cards having an embedded Integrated Circuit (IC). That IC may be a logic circuit with its associated memories or a microcontroller with its associated memories and software, or a microcontroller with its associated memories and software coupled to a custom circuit block or interface.

To use the computing power of the IC, a smart card makes use of a full set of packaging technologies. For example, the die size varies from 1mm² to 30 mm², but is limited because of the mechanical limitations imposed by the plastic construction of the smart card. The IC is attached to a lead frame and wire-bonding techniques are used to connect the IC pads to the lead frame contacts. Potting or other strengthening methods can be used to protect the IC against chemical and mechanical stresses during manufacturing and are a part of everyday usage of a smart card. Eight contacts are located on one side of the card. The smart card performs transactions with a smart card reader using a serial protocol. The mechanical and electrical specifications for a smart card are published by the International Standard Organization (ISO) as ISO7816-X standards, which have allowed the simple and massproduced magnetic stripe cards to evolve toward the smart card. This natural evaluation has allowed smart cards, depending of the IC complexity, of course, to perform pre-paid accounting, cryptographic scheme, personal authentication using a PIN code, biometrics, and java scripts, for example.

ISO documents ISO 7816-1 Physical Characteristics, ISO 7816-2 Dimensions and Locations of the contacts, ISO 7816-3 Electronic signals and transmission protocols, ISO 7816-4 Interindustry Commands for Interchange, and ISO 7816-10 Electronic signals and answer to reset for synchronous cards are incorporated herein by reference.

In operation, smart card readers are recognized by the reader infrastructure or a host computer prior to performing any transaction involving a smart card. The infrastructure runs an application involving the smart card. The half duplex protocol between the smart card and the smart card reader, in which either the smart card sends information to the smart card reader or vice versa, cannot start until a smart card is in place and detected by the smart card reader. The infrastructure manages authentication or transactions for pre-paid cards in public telephony, for Bankcards in Point-of-Sale (POS) terminals and Automatic Teller Machines (ATM), for Pay TV providers in set top boxes, and for wireless telecom operators in Subscriber Identification Modules (SIM) used in Global System for Mobile (GSM) terminals. Except for SIM cards, all other smart card reader applications use a physical sensor to detect the smart card. This sensor tells the smart card reader when a smart card is in place, i.e., when the smart card lead frame contacts mate with the smart card reader contacts.

When the smart card reader has established that a smart card is in place, a power-up sequence begins. After this power-up sequence has finished, the smart card reader typically provides a clock to the smart card and releases a reset signal. The smart card then executes its stored Operating System (OS). The SIM card, on the other hand, is in place only once with the power-off and used constantly subsequent to its positioning.

The first application for smart card technology was the public telephone system. The smart card die size was typically less than 1mm², and only memories and logic circuits were integrated in the IC. The smart card reader used all eight contacts to interface properly with the different smart card generations. When the smart card was inserted in the payphone, the telephone infrastructure authenticated the smart card and the telephone removed "units" from the smart card.

The banking industry subsequently adopted smart cards. The die size was about 10mm², and a microcontroller and its associated memories and software were integrated in the IC. The smart card reader used up to six contacts to interface properly with the different smart card generations. When a smart card was inserted in the ATM or the POS (point-of-sale), the smart card user was authenticated with a PIN code. The smart card could store different items, such as the balance of cash received from an ATM on a per week basis or details of purchases since a last closing date. Based on this information, authorization could be issued on the spot once the PIN had authenticated the debtor. This was accomplished without telephone calls to the bank.

Another application for smart cards has been developed by GSM manufacturers. The die size in a SIM is about 30mm², and a microcontroller and its associated memories and software are integrated in the IC. The SIM reader uses five contacts to interface properly with the smart card. The more sophisticated smart card applications are performed in GSM using Java applets.

A new market for the smart card has emerged with the growth of the internet accessed from a personal computer. Secure message, Public Key Infrastructure, Authentication and Electronic Payment are new smart card areas of interest. The smart card acts as an e-commerce facilitator. One advantage of a smart card compared to other solutions is the smart card PIN located in its memory that is never communicated in any transaction.

Presently, a smart card is inserted into a smart card reader connected to a host computer. Two protocols are involved in supporting transactions between the smart card and host computer. The first protocol complies with the ISO-7816-3, which provides detailed requirements for the serial interface between smart card and smart card reader. The reader is connected to the computer via a serial port, a parallel port, or the Universal Serial Bus (USB), using a second protocol. The smart card reader contains electronic circuits and embedded software that enable communication between the smart card using the first protocol and the host computer using the second protocol. The host computer is loaded with any appropriate drivers to support the smart card reader.

Many countries have begun to use the smart card in the PC environment. The die size used in these applications ranges from 5mm² to 30mm², and the microcontroller and its associated memories and software are integrated in the IC typically with a cryptocontroller. Sometimes, a bio-sensor is integrated. The smart card reader uses at least five contacts to interface properly with the smart card in these applications.

Since the late 1990's, the universal serial bus (USB) has become firmly established and has gained wide acceptance in the PC marketplace. The USB was developed in response to a need for a standard interface that extends the concept of "plug and play" to devices external to a PC. It has enabled users to install and remove external peripheral devices without opening the PC case or removing power from the PC. The USB provides a low-cost, high performance, half-duplex serial interface that is easy to use and readily expandable.

USB uses four wires. The power supply is carried with two wires (VBus and ground), and data is carried with the other two wires (D+, D-). The latest version of the USB is currently defined by the Universal Serial Bus Specification Revision 2.0, written and controlled by USB Implementers Forum, Inc., a non-profit corporation founded by the group of companies that developed the USB Specification.

In particular, Chapter 5 USB Data Flow Model, Chapter 7 Electrical, Chapter 8 Protocol Layer and Chapter 9 USB Device Framework of Universal Serial Bus Specification are incorporated herein by reference. The increasingly widespread use of the USB has led smart card reader manufacturers to develop USB interfaces for connection of their products to host computers to complement the existing serial and parallel interfaces.

Because the USB protocol is becoming increasingly important, it is necessary to develop products involving complex smart card devices for use with USB systems. To produce a functional equivalent of a smart card before the final product is available and any chips are manufactured, a simulator is developed on a software development computer and acts to "simulate" the behavior of the smart card. After the smart card program is assembled or compiled, the output is sent to the smart card simulator, which interprets the instructions it finds and runs the program to a break point (e.g., a stop or normal execution interrupt), or allows a user to single step the program and watch a change of state of the simulated smart card device. The communication interfaces of the smart card, including the various default pipe, pipe bundles, and USB wire are accomplished with the simulated software and associated devices.

Prior art solutions for developing USB smart card simulation programs and devices, USB smart card contacts, and software have included systems that simulate a "virtual USB host" and software that communicates with a smart card USB peripheral. Another prior art solution runs the program on a chip emulator as a step between running the smart card program in the simulator and running it on a smart card itself. The chip emulator contains the actual chip or design of the chip in a manner that will allow the tester to examine the internal state of the chip and single step the program. In the USB smart card context, the emulator is connected to a real USB host.

These prior art devices or systems often do not allow faithful and complete functionality adhering to all aspects of USB specifications. They often require a large number or enhanced processing power of hardware peripherals and require, in some cases, a "virtual USB host" to send the USB traffic to the simulator. If a "virtual USB host" is created, a possible wrong interpretation of the USB specification could be implemented. In some cases, several different operating behaviors of the virtual USB host must be developed because each computer operating system would implement a USB host having a different operating behavior. Even when a chip emulator is used, use of the emulator would still require a final debugging step.

It has also been known that depending upon capabilities built into software, virtual devices, such as a "virtual USB host," can exhibit different synchronization behaviors with actual physical devices. As a result of these and other problems, there is an inability to debug and validate embedded software with a simulator while in the context of the current environment or a final application for a USB smart card device. There is also the inability to use the simulator in the environment adhering to all aspects of the USB specifications. There is also the problem of connecting the simulator to a real USB host device and the resultant inability to debug and validate the USB PC driver of the final application using the simulator. Any USB system works as a slave/master system, and thus, it is impossible for two devices acting as master devices to communicate in the USB protocol.

It is therefore an object of the present invention to provide communications between a USB smart card simulator running on a software development computer and USB host controller that overcomes the disadvantages of prior art solutions noted above.

The present invention is advantageous and simulates a universal serial bus (USB) smart card device connected to a USB host device for development and debugging. A computer simulator has software that simulates a USB smart card device. The USB host device includes a USB host controller operatively connected along a communications link with the computer simulator for transmitting or receiving data packets to or from the computer simulator. A microcontroller is located in the communications link between the computer simulator and the USB host device and translates the data packets into a USB protocol to be used by the USB host device and defined by the computer simulator.

In one aspect of the present invention, the microcontroller can be a serial/USB translator interconnected between the computer simulator and the USB host device. The computer simulator can include a serial port connected to a serial communications line that is, in turn, connected to the microcontroller. The USB communications link can extend between the serial/USB translator and the USB host device.

In yet another aspect of the present invention, the microcontroller is operative for supporting control, bulk, interrupt, and/or isochronous USB transfer modes. A serial and USB peripheral can be controlled by the microcontroller.

In yet another aspect of the present invention, the microcontroller comprises a USB/USB translator. Two USB peripherals can be controlled by the microcontroller. A USB host controller can be operative with the computer simulator and connected to the communications link.

In yet another aspect of the present invention, the microcontroller has input and output software stacks for recording and aiding data packet transfers. The software stacks can store data regarding packet type, data payload, endpoint address, endpoint number and/or transfer state within each software stack.

A method for simulating a USB smart card device connected to a USB host device for development and debugging is also set forth.

Other objects, features and advantages of the present invention will become apparent from the detailed description of the invention which follows, when considered in light of the accompanying drawings in which: <ul id="ul0001" list-style="none"><li>FIG. 1 is a block diagram of a USB host/device showing various data transport mechanisms, pipes, and the USB-relevant format of transported data between the host and interconnected physical device as used in the Universal Serial Bus Specification Revision 2.0.</li><li>FIG. 2 is a high level block diagram of the present invention showing a software development computer and simulator as a smart card USB device connected to a host computer and USB host controller.</li><li>FIG. 3 is a block diagram of a first embodiment of the present invention using a software development computer, USB-SERIAL microcontroller, and host computer, and showing input and output stacks.</li><li>FIG. 4 is a protocol example for a control write transfer that can be used with the present invention.</li><li>FIG. 5 is a block diagram of a second embodiment of the present invention similar to FIG. 3, and using a software development computer, but using USB-USB microcontroller connected to the host computer, and showing input and output stacks.</li></ul>

The present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

The present invention advantageously provides communication between a USB smart card simulator running on a software development computer and a USB host controller. In accordance with the present invention, one of the peripherals in the software development computer sends data to a USB host controller via a hardware connection. Because the software development computer does not have a USB device interface, a protocol translation is required between the software development computer and the host computer with the USB host controller.

The present invention allows faithful and complete functionality, adhering to all aspects of the USB specification, including Universal Serial Bus Specification Revision 2.0. It allows a smart card software developer to develop and debug any code before the actual silicon chip is a final, physically tangible product. It does not require a large number of hardware peripherals or operating capability because most of the application is performed by software. It is not required to develop a "virtual USB host" to send USB traffic to the simulator, and as a result, there is no risk of a wrong interpretation of the USB specification when developing a virtual USB host. There is also no requirement to develop several operating behaviors of a virtual USB host as required in prior art solutions where each computer operating system would implement a USB host with a different operating behavior.

The present invention also allows debugging and validation in the current environment of a final application and allows debugging and validation of a USB PC driver using the simulator. It is lower in cost than many prior art solutions because not only is there no final debugging step, but also a chip emulator is no longer required to run the smart card software program. The "time to market" from development to the complete product, including the chip, driver, smart card application and other associated developments, is improved as a result of the present invention.

For purposes of background and reference, the basic USB data flow between a USB host and a USB device and the various implementations and layers in accordance with Universal Serial Bus Specification Revision 2.0 are set forth in FIG. 1.

As shown in FIG. 1, the connection of a host <b>10</b> to a physical device <b>12</b> requires the interaction between different layers, i.e., the USB bus interface layer <b>14</b>, USB device layer <b>16</b>, and function layer <b>18</b>. An interconnect <b>20</b> between the host and device is illustrated.

The USB bus interface layer <b>14</b> includes a USB bus interface circuit <b>22</b> and serial interface engine (SIE) <b>24</b> at the device <b>12</b> that communicates with a serial interface engine (SIE) <b>26</b> and its host controller <b>28</b> at the host <b>10</b> via a physical wire <b>29</b>. The USB device layer <b>16</b> includes at the physical device <b>12</b> a collection of endpoints as a USB logical device <b>30</b>. An endpoint zero <b>32</b> is operable in communication via the default pipe <b>34</b> to USB system software <b>36</b> that is operable for device management at the host <b>10</b>. The function layer <b>18</b> includes at the physical device <b>12</b>, a logical function <b>38</b> as an interface collection, and the interface <b>40</b> that communicates via a plurality of pipe bundles <b>44</b> to client software <b>42</b> that is operable for interface management.

The USB bus interface layer <b>14</b> provides the physical wire <b>29</b> for the traffic signaling and packet conductivity between the host <b>10</b> and physical device <b>12</b>. The USB device layer <b>16</b> views the USB system software <b>36</b> to perform generic USB operations with the physical device <b>12</b> via the default pipe <b>34</b> to endpoint zero <b>32</b>. The functional layer <b>18</b> adds capabilities to the host using matched client software. The USB Device Layer <b>16</b> and Function Layer <b>18</b> each view logical communications within their layers and use the USB Bus Interface Layer <b>14</b> for any data transfer. The USB host <b>10</b> coordinates the overall USB system, controls access, and monitors the USB topology.

Logical communications exist between the client software and the Function Layer <b>18</b> and the USB system software <b>36</b> and USB logical device <b>30</b>. Actual packets flow between the USB host controller <b>28</b> and the USB bus interface circuit <b>22</b>.

As is known, USB physical devices add functionality to the host and have the same interface. Each physical device carries and reports configuration-related data, which it forwards to the host to allow the host to identify and configure the USB device. Typically, devices on the USB are connected to a host using a tiered star topology, including the hub. The host, on the other hand, communicates with each logical device as if it were directly connected to a root port. The client software manipulates a USB function interface of a device only as an interface of interest.

It should be understood that the actual communication flows across several interface boundaries. The two software interfaces for the host are a host controller driver (HCD) and a USB driver (USBD). A software interface between a USB host controller <b>78</b> and USB system software <b>76</b> implements the host controller driver and allows the host controller to implement functions without requiring the host software to be dependent on any particular implementation. One USB driver can support different host controllers. Specific knowledge of a host controller implementation is not required.

The USB logical device <b>30</b> can be considered a collection of endpoints and are grouped into endpoint sets to implement the interface. The USB system software <b>36</b> manages or controls the device using the default pipe <b>34</b> to the endpoint zero <b>32.</b> Client software <b>42</b> manages the interface using pipe bundles <b>44</b> associated with an endpoint set. Data is moved between a buffer on the host <b>10</b> and an endpoint on the USB device <b>12</b> when client software requests the data. The host controller <b>28</b> or USB device <b>12</b>, depending on the direction of data transfer, packetizes the data and forwards the packets over the bus. It also coordinates bus access. The host communicates with the physical device using a desired communication that is designed to match any communication requirements of the physical device and transfer characteristics provided by a USE.

The endpoint is an identifiable portion of the device that terminates the communication between the host. It can be a collection of independent endpoints. Default control uses input and output endpoints and the endpoint number "zero" as part of the default pipe <b>34</b>.

The data transport mechanism includes transfers of data between the host controller <b>28</b> and the USB system software <b>36</b> at the host <b>10.</b> Buffers can be used as a data transport mechanism between the USB system software <b>36</b> and the client software <b>42</b> at the host <b>10</b>. The other data transport mechanism includes transactions between the host controller <b>28</b> and the serial interface engine <b>26</b> within the USB bus interface of the host.

The data transport mechanism also exists as a data per endpoint between the USB bus interface circuit <b>22</b> and the USB logical device <b>30</b> at the physical device <b>12</b>. The data transport mechanism between the function <b>38</b> (and with the interface <b>40</b>) and the endpoint zero <b>32</b> is interface-specific.

USB-relevant format of transported data occurs as USB frame data between the serial interface engine <b>26</b> and the host controller <b>28</b> and between the host controller <b>28</b> and the USB system software <b>36</b> at the host <b>10</b>. No USB format of transporting data exists between the client software <b>42</b> that manages an interface and the USB system software <b>36</b>.

At the device <b>12</b>, USB-relevant format of transported data exists as USB frame data between the USB bus interface circuit <b>22</b> and the USB logical device <b>30.</b> No USB format of data occurs between the interface <b>40</b> and the endpoint zero <b>32</b> at the device <b>12</b>.

Further details of the functioning of the USB host and device and data flow can be found in the Universal Serial Bus Specification Revision 2.0, Chapter 5 entitled "USB Dataflow Model," the disclosure which is hereby incorporated by reference in its entirety.

The present invention incorporates functionality for simulating a smart card or Universal Serial Bus smart card device (USD) <b>100</b> and provides communications between a USB smart card simulator <b>101</b> as software running on a software development computer <b>102</b> and a host computer <b>104</b> having a USB host controller <b>106</b> as shown in FIG. 2.

As shown in FIG. 3, a first embodiment is illustrated where one of the serial ports <b>110</b> of the software development computer <b>102</b> sends or receives data to or from a simulator <b>101</b> via a USB peripheral <b>112</b>. The data is transmitted on a serial cable <b>114</b> to a chip microcontroller as a USE-SERIAL microcontroller <b>116</b>, which acts as a protocol translator. It includes firmware <b>118</b> for translating the serial protocol into a USB protocol. The chip or USB-SERIAL controller <b>116</b> communicates to the USB host computer <b>104</b> using the USB protocol defined into the simulator and through a USB cable <b>120.</b> As illustrated, the software development computer <b>102</b> includes the smart card simulator <b>101</b> and the USB peripheral <b>112</b>. The items communicate with the firmware <b>118</b> as part of the USB, SERIAL microcontroller <b>116</b>. The USB-SERIAL microcontroller <b>116</b> performs the translation and includes a serial and a USB peripheral <b>124.</b> The USB peripheral must have the same features as the product to simulate. For example, the microcontroller should support the four USB transfer modes of control, bulk, interrupt and isynchronous transfer modes.

A special protocol is defined to transfer USB information over the serial communication link. For example, not only must information regarding the type of transfer be forwarded, but also the cyclic redundancy check (CRC) must be forwarded. There are some speed limitations because the serial interface RS232 works at a maximum speed of 115 Kbit/s while the full speed of USB is 12 Mbit/s (and 40 Mbits/s for USB Specification Revision 2.0). The simulator speed depends on the computer peripheral speed and of the implementation of the simulator.

As noted before, the USE-SERIAL microcontroller <b>116</b> must have the same hardware configuration, i.e., the same endpoints number, endpoints type, and other factors, as the USB smart card simulator <b>101</b>. The firmware of the USE-SERIAL microcontroller <b>116</b> implements two software stacks as an input stack <b>130</b> and an output stack <b>132</b> (FIG. 3). Each stack item will give the following information: <ul id="ul0002" list-style="none" compact="compact"><li>a) packet type (control, bulk, interrupt, isynchronous);</li><li>b) data payload;</li><li>c) endpoint address;</li><li>d) endpoint number; and</li><li>e) the transfer state (i.e., which transaction and which packet is in the transaction).</li></ul>

The input stack <b>130</b> records all transfers from the host computer <b>104</b> to the USE-SERIAL microcontroller <b>116.</b> The host computer <b>104</b> will send USB packets to the USE-SERIAL microcontroller <b>116</b>. The microcontroller firmware <b>118</b> decodes the USB packet and fills the input stack <b>130</b>. The USE-SERIAL microcontroller reads the input stack <b>130</b> and converts it into a serial packet and forwards it to the smart card simulator <b>101</b>.

The output stack <b>132</b> records the transfers from the smart card simulator <b>101</b> to the USE-SERIAL microcontroller <b>116.</b> The smart card simulator <b>101</b> forwards serial data to the USB-SERIAL microcontroller, where its firmware <b>118</b> decodes the serial packet and fills the output stack <b>132</b>. The USE-SERIAL microcontroller <b>116</b> reads the stack and converts it into USB format and forwards data to the host computer <b>104.</b>

In order to simulate a single ended zero (SE) in a suspend mode, a special flag can be sent to the host computer. The single ended zero bus state is operative with the start of packet (SOP) and end-of-packet (EOP). The end-of-packet could be signaled by driving D+ and D- to a SCO state for two bit times. The lines to the J state can be driven for one bit time. This transition from the single ended zero to the J state defines an end-of-packet as received. The J state can be asserted for one bit time, while any D+ and D- output drivers are in a high impedance state. As to a suspend mode, a bus termination resistor could hold a bus in an idle state. Devices can be in a suspend mode (or state) from any powered state. For example, the entire bus could be placed in a suspend state by ceasing transmissions, including a start-of-frame token. There could be a global suspend and a selective suspend followed by resume.

FIG. 4 shows a protocol example for a control write transfer between the smart card USB device and the host of FIG. 3. It is shown that the USB data packet is translated to the serial data packet. A serial ACK packet is translated to the USB ACK packet. Throughout the time frame, which is advancing downward in this protocol example, the translation occurs from the USB packet to the serial packet, such as for the OUT, data, ACK, IN, data and ACK packets.

It should be understood that the bottle neck for data transfer using the embodiment shown in FIG. 3 is located at the simulator. It is required to implement special buffer features in the simulator <b>101</b> to keep a record of all data coming from the USB host <b>104</b>.

The second embodiment shown in FIG. 5 addresses this issue by using a USB host controller <b>200</b> of a software development computer <b>202</b> forming the smart card USB device <b>203</b> to send or receive the data to or from the smart card simulator <b>204</b>. The communication speed is 12 Mbits/s (or 40 Mbits/s) instead of 115 Kbits/s used with the simulator and embodiment of FIG. 3.

The data is transmitted on a USB cable <b>210</b> to a USB device that is a chip microcontroller operable as a USB-USB microcontroller <b>212</b>, which manages two USB peripherals <b>214,216.</b> The USB-USB microcontroller <b>212</b> communicates to a USB host controller 220 of the host computer <b>222</b> using the USB protocol defined in the simulator. The USB-USB microcontroller <b>212</b> coordinates the data transfer between both USB peripherals <b>214,216.</b> One of the USB peripherals must have the same features as the simulated product, and thus, the USB-USB microcontroller typically supports all USB transfer modes (control, bulk, interrupt and isynchronous).

The firmware <b>230</b> of the USB-USB microcontroller <b>212</b> could implement two software stacks as shown in FIG. 5, an input stack <b>232</b> and output stack <b>234.</b> Each stack item could hold an entire USB packet.

As shown in the embodiment of FIG. 5, the USB-USB microcontroller <b>212</b> coordinates the data transfer between USB peripherals. A protocol can define the transfer of USB information over the USB channel between the smart card simulator <b>204</b> and the USB-USB microcontroller <b>212.</b> The recommended configuration of the USB peripheral is a control transfer endpoint to configure the USB-USB microcontroller <b>212</b>. An interrupt transfer endpoint in the IN direction knows when the USB host controller <b>220</b> tries to send a command to the smart card simulator. This guarantees that the smart card simulator <b>204</b> will request data with minimal delay. Bulk transfer endpoints (IN and OUT) transfer large amounts of data.

The firmware <b>230</b> of the USB-USB microcontroller <b>212</b> implements the two software stacks as the input stack <b>232</b> and the output stack <b>234.</b> Each stack item holds an entire USB packet data. An interrupt IN transfer is accomplished between the smart card simulator <b>204</b> and the USB-USB microcontroller <b>212.</b> It does not have a noticeable delay between the host computer <b>222</b> sending a packet and the smart card simulator <b>204</b> answering to the packet. For example, when a host computer <b>222</b> forwards a packet to the USB-USB microcontroller <b>212</b>, the packet and USB transfer type are stored in the input stack <b>232.</b> When the interrupt transaction occurs, the first stored packet is forwarded to the smart card simulator <b>204</b>.

The smart card simulator <b>204</b> also answers to the host computer <b>222</b>. It sends the answer packet in the USB type specified by the USB transfer type to the USB-USB microcontroller <b>212</b> and stores the packet in the output stack <b>234.</b> The packet is sent to the host computer in its current format. The USB communication between the USB-USB microcontroller <b>212</b> and the host computer <b>222</b> is the real USB communication for the final chip. To simulate a single ended zero in the suspend mode, a special flag is sent to the host computer.

Many modifications and other embodiments of the invention will come to the mind of one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed, and that the modifications and embodiments are intended to be included within the scope of the dependent claims.