JP2007140813A - Usb device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prevent malfunctions from occurring when a transfer error is generated in a status stage during control transfer from a USB host. <P>SOLUTION: When the USB device automatically responds to the request of the control transfer received from the USB host, setting required by the request is performed at a timing (steps S3, S5 and S8) specified by the contents of the request. For the request of Set_Address, an address is set to the USB device in the step S5 or S8. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a USB device that automatically responds to a control transfer request received from a USB host, and more particularly to a USB device that prevents malfunction due to a transfer error that occurred during the control transfer.

  First, USB will be briefly described. Data transferred by USB is composed of a token packet, a data packet, and a handshake packet, and one data transfer composed of these three packets is called a transaction.

  The token packet stores the PID (identifier) indicating the type of transaction, the address of the USB device that is the counterpart of the data transfer, and the end point, and between the USB device and the USB host that conform to the information of the token packet. Data transfer becomes possible. Transfer data is stored in the data packet. The handshake packet stores information indicating whether or not the data transfer has been normally completed.

  There are three types of transactions: IN transactions, OUT transactions, and SETUP transactions. In the IN transaction, data is transferred from the USB device to the USB host. Conversely, in the OUT transaction, data is transferred from the USB host to the USB device. The SETUP transaction is used when a command specified by the standard is transferred from the USB host to the USB device. These three transactions constitute a transfer called bulk transfer, control transfer, isochronous transfer, or interrupt transfer.

  Bulk transfer is used for transferring a large amount of data aperiodically, and is performed by repeating an IN transaction or an OUT transaction. The control transfer is a transfer used for exchanging information necessary for USB device control, etc., and starts with a setup transaction (setup stage), followed by a data transaction (data stage) consisting of an IN transaction or OUT transaction, and a status transaction (status End with stage. However, there may be no data transaction. Isochronous transfer is used for continuous and periodic communication, and is a sequence of IN or OUT transactions without handshake packets. An interrupt transfer is a single IN transaction used for periodic and low bandwidth data transfers.

  These various transfers are arranged in a certain period called a frame (1 ms in the full speed mode, 125 μs in the high speed mode) and transferred in units of one frame. The start of the frame is notified by a special packet called an SOF (Start of Frame) packet.

  FIG. 3 shows the configuration of the USB system. A plurality of USB devices are connected to one USB host 1 (personal computer). For example, when three USB devices 2A, 2B, and 2C are connected, addresses “1”, “2”, and “3” are assigned by the USB host 1 to the individual USB devices 2A, 2B, and 2C. Then, each USB device 2A, 2B, 2C confirms the address included in the token packet transferred from the USB host 1, and is sent to its own USB device or to another USB device. Determine if it is a packet.

  FIG. 4 is a diagram showing an outline of this process, and shows a case where token packets are transferred from the USB host 1 in the order of the USB devices 2A → 2B → 2C. For example, the USB device 2A returns data DATA_A to the token packet with the address “1”. In response to this, the USB host 1 returns a handshake packet ACK. However, the USB device 2A does not return data to token packets of other addresses “2” and “3”, and ignores the transmitted token packet. The USB device 2A also ignores the ACK returned by the USB host 1 for the data DATA_B and DATA_C from the other USB devices 2B and 2C.

  FIG. 5 is an explanatory diagram of address setting to the USB device. The initial value of the address of each USB device is “0”, and one of the addresses “1” to “127” other than “0” is set by a control transfer Set_Address request after connection. That is, in the setup stage, when receiving the SETUP token packet and the 8-byte data packet transmitted from the USB host, the USB device holds the address (for example, “1”) included in the setup data. Then, an ACK handshake packet is returned to the USB host. When receiving the ACK handshake packet, the USB host next transmits an IN token packet to the USB device in the status stage. The USB device that has received this transmits a 0-byte data packet informing the normal reception of the address “1”. When this is received by the USB host, an ACK handshake packet is returned from the USB host to the USB device, and when this is received, the USB device sets the address “1”. In this way, the USB device performs address setting at the timing of receiving the ACK handshake packet indicating completion of the status stage of control transfer.

  FIG. 6 is a block diagram showing the configuration of the USB device 2. The USB device 2 includes a USB device controller 21, an MPU 22 that controls USB operation, a memory (RAM) 23 for storing data, a memory controller 24 that controls the memory 23, and an internal bus 25.

  FIG. 7 is a block diagram showing an internal configuration of the USB device controller 21 shown in FIG. The USB device controller 21 includes a USBPHY 211 that controls input / output of packets, a packet control circuit 212 that controls packets to be input / output, an endpoint buffer 213 for holding data, a DMA controller 214, and a control register 215.

  By the way, in the USB standard, when a transfer error occurs, a protocol at the time of the error occurrence is defined so that subsequent communication will not stop. In the IN transfer in which the USB host receives data from the USB device in the Set_Address request for the control transfer, the processes of FIGS. 8 to 10 are performed.

  Case 1 is shown in FIG. This is a case where the USB device cannot normally receive the IN token packet returned from the USB host. At this time, since there is no reply of a 0-byte data packet from the USB device, the USB host transmits (retrys) the IN token packet to the USB device again, and the 0-byte data from the USB device is returned. Request a reply. The USB device that has received this second IN token packet returns a 0-byte data packet, and the USB host that has received this data packet sends an ACK handshake packet. Address setting in the USB device is performed at the reception timing.

  FIG. 9 shows Case 2. This is a case where the USB host cannot normally receive the 0-byte data packet returned from the USB device. Since the data packet cannot be received, the ACK handshake packet is not returned from the USB host. Then, the USB host transmits (retrys) the IN token packet to the USB device again. In response to this, the USB device transmits the same 0-byte data packet. After this, as in Case 1, the USB device that received the second IN token packet returns a 0-byte data packet, and the USB host that received this data packet sends an ACK handshake packet. When received by the USB device, address setting in the USB device is performed at the reception timing.

  If a transfer error such as in cases 1 and 2 above occurs in the status stage of control transfer using an IN token packet, the address set of the USB device is determined by retransmitting (retrying) the IN token packet from the USB host. It is done correctly and subsequent communication never stops.

  However, when a transfer error in case 3 shown in FIG. 10 occurs, the address is not set correctly in the USB device, causing malfunction. That is, Case 3 in FIG. 10 is a case where the USB device cannot normally receive the ACK handshake packet returned from the USB host in the status stage. At this time, since the USB host has already received the 0-byte data packet from the USB device, the USB host determines that the address setting on the USB device has been performed normally, returns an ACK handshake packet, and returns the control transfer status. End the stage. In the next setup stage, a SETUP token packet designating a set address (“1” in FIG. 10) is transmitted.

  However, since the USB device side has not yet received the ACK handshake packet from the USB host, the address is not set, and the address remains at the initial value “0”. For this reason, it becomes impossible to respond due to the address mismatch of the SETUP token packet, and malfunction occurs.

  From the above, in order to re-establish the connection, it is necessary to prepare in advance a process for performing a re-request with the firmware of the USB host, or when this is not available, the USB cable must be manually connected and disconnected.

  An object of the present invention is to provide a USB device in which a malfunction does not occur even when a transfer error occurs in a status stage during control transfer from a USB host, or at least the malfunction is suppressed.

In order to solve the above-described problem, the invention according to claim 1 is a USB device that automatically responds to a control transfer request received from a USB host, and the request is specified at a timing specified by the content of the request. The setting requested by was added.
According to a second aspect of the present invention, when the content of the request receives a retry of an IN transfer request from the USB host after performing the setting, the request can automatically respond to the retry. In this case, the setting is made without waiting for the reception of the ACK signal transmitted by the USB host that has received the response transmitted by the USB device in response to the request.
The invention according to claim 3 is the invention according to claim 2, wherein the content of the request is set without waiting for reception of an ACK signal transmitted by the USB host that has received a response transmitted by the USB device. When an IN transfer request retry is received from the USB host and it is impossible to automatically respond to the retry, the setting is performed after the reception of the ACK signal.
According to a fourth aspect of the present invention, in the invention according to any one of the first to third aspects, the USB host that has received a response transmitted by the USB device in response to the request follows the ACK signal to the USB device. When the next packet to be transmitted can be identified, the setting is performed after waiting for the reception of the identified next packet.
The invention according to claim 5 is the invention according to claim 4, further comprising a setup buffer for storing data received from the USB host in the setup stage of the control transfer, and the USB host after transmitting a response to the request. A packet identification circuit for comparing reception of the next packet identified is compared with data stored in the setup data buffer.
The invention according to claim 6 is the invention according to claim 1, 2, 3, 4 or 5, further comprising a request decoder circuit for decoding the request and judging the content of the request.

  According to the USB device of the present invention, since the setting requested by the request is performed at the timing specified by the content of the control transfer request received from the USB host, even if a transfer error occurs, malfunction is prevented. Can do.

  There are several other types of requests that require standard support for all USB devices and that use the same type of control transfer as the Set_Address request. For example, Set_Feature, Clear_Feature, Set_Configuration, Set_Interface, etc. In the present invention, the contents requested by the request are set at a specific timing in accordance with the contents of the various control transfer requests, and no malfunction occurs even if a transfer error occurs.

  FIG. 1 is a block diagram showing a configuration of a device controller 21 of a USB device according to one embodiment of the present invention. Among the components shown in the figure, a setting circuit 216 including a setup data buffer 2161, a request decode circuit 2162, a packet identification circuit 2163, and a setting condition generation circuit 2164 is newly added in the device controller 21 of the present embodiment. The other elements are elements included in the conventional USB device controller 21 described with reference to FIG.

  In the USB device having the USB device controller 21 shown in FIG. 1, setting data such as address data included in the request received by the packet control circuit 212 is stored in the setup data buffer 2161. The received request is sent to the request decode circuit 2162, and the request content (type) is determined. Further, the packet identification circuit 2163 identifies the received packet. Based on the decoding result by the request decoding circuit 2162 and the packet identification result by the packet identification circuit 2163, the setting condition generation circuit 2164 sets the setting timing. At appropriate timing based on the setting result, setting data included in the packet received by the packet control circuit 212 is stored in the control register 215 and setting is performed.

  FIG. 2 shows a flow of status step processing in the USB device of this embodiment. In the present embodiment, steps S3, S5, and S8 of settings (1) to (3) selected according to the request contents are provided at three locations in the status stage transfer flow. The settings (1) to (3) are selected by the request decode circuit 2162 and the packet identification circuit 2163 of the USB device controller 21. However, it may be switched by judging the request outside the USB device controller 21 each time and writing it in the register 215.

  In FIG. 2, step S1 determines whether or not an IN token packet first transferred from the USB host is received in the status stage. In step S2, when the IN token packet is received, the corresponding data is transmitted to the USB host. In step S4, it is determined whether or not an ACK handshake packet is received from the USB host that has received the corresponding data. In step S6, it is determined whether or not an IN token packet re-transferred from the USB host by the retry is received. In step S7, after transmitting the data in step S2, it is determined whether or not the USB host that has received this data has received the next packet transmitted following the ACK handshake packet. For example, if the setup stage preceding the status stage is a Set_Address request, the address data received in the setup stage is stored in the setup data buffer 2161. In step S7, it is determined whether or not the USB host 1 has transmitted the next packet to the address.

  In FIG. 2, the setting (1) in step S3 does not affect the retry operation even if a transfer error occurs after the setting is made (that is, automatic operation is not required for the retry without requiring firmware or manual response). Set according to the content of the request (which can respond). For example, when the Configuration Value is set by the Set_Configuration request, even if a retry of IN token packet transfer in the status stage occurs after the setting, the retry operation is not affected, so this setting (1) is used. On the other hand, for example, when setting TEST_MODE with a Set_Feature request, the USB device moves to another mode if it is set in setting (1). I cannot respond. Also, when setting a device address with a Set_Address request, if an address is set in setting (1), it cannot respond to a retry of IN token packet transfer due to an address mismatch. In the case of such a request, the setting in the setting (1) is not performed.

  In this setting (1), when the request decoded by the request decoding circuit 2162 has contents to be made in the setting (1) of the step S3, the IN token packet received in step S1 is identified by the packet identification circuit 2163. Immediately after that, the timing of the setting (1) is generated by the setting condition generation circuit 2164 and the setting is made to the control register 215. This setting (1) may be performed simultaneously with or before the data transmission in step S2.

  The setting (2) in step S5 is a request that affects the retry operation when a retry of the IN stage packet transfer in the status stage due to a transfer error occurs if the setting is made in the setting (1). Do.

  In this setting (2), when the request decoded by the request decoding circuit 2162 has contents that should not be made in the setting (1) of step S3, the packet identification circuit 2163 receives the ACK handshake packet received in step S4. Immediately after the identification, the setting condition generation circuit 2164 generates the timing of setting (2), and the setting is performed on the control register 215. Since the setting (2) is performed when an ACK handshake packet is received in step S4, the setting described with reference to FIGS. 5, 8, and 9 can be performed for the Set_Address request. However, it cannot cope with the transfer error described in FIG.

  The setting (3) in step S8 is a request that affects the retry operation when an IN token packet transfer retry occurs due to a transfer error if the setting is made in the setting (1), and the subsequent packet It is executed when the request can be confirmed (assumed). That is, the condition is that the next request to be executed is determined in the USB connection procedure. For example, when the USB device address is set by the Set_Address request, it is determined that the Get_Descriptior request is executed next.

  This setting (3) is made on condition that the request decoded by the request decoding circuit 2162 is the contents to be made in the setting (3) of step S7. If the ACK handshake packet cannot be received (step S4) and the retry IN token packet cannot be received (step S6), the packet identification circuit 2163 identifies that the received packet is a specific next packet. Immediately after (step S7), the timing of setting (3) is generated by the setting condition generation circuit 2164, and the setting is performed on the control register 215.

  For example, in the case of a Set_Address request, the setting (3) is specifically performed as follows. First, setup stage address data included in the request is stored in a setup data buffer 2161. The received Set_Address request is sent to the request decoding circuit 2162, and the contents thereof are determined. Thereafter, in step S7, the received packet is identified by the packet identification circuit 2163, and the address included in the received packet is compared with the address stored in the setup data buffer 2161. Then, when both addresses match, it is identified that the received packet is a specific next packet. Then, based on the determination result by the request decode circuit 2162 being a Set_Address request and the identification result by the packet identification circuit 2163 being the next packet of step S7, the setting condition generation circuit 2164 sets the timing of setting (3). Is generated. At this timing, the address data stored in the setup data buffer 2161 is stored in the control register 215, and address setting is performed. With this setting (3), even if the transfer error described in FIG. 10 occurs, the address can be set by receiving the SETUP token packet in the next setup stage. Therefore, the occurrence of malfunction can be prevented.

  In this embodiment, three setting timings (1), (2), and (3) are provided, and the setting is performed at any one of these timings according to the content of the request. Thus, although it is not possible to prevent the occurrence of malfunctions in all cases, the frequency of malfunctions can be greatly reduced compared to the case where only one set timing is provided. However, it is not always necessary to provide all of these three setting timings. Even if any two setting timings are provided and the setting is performed at any timing according to the content of the request, the frequency of occurrence of malfunction can be reduced as compared with the case where only one setting timing is provided. it can.

  For example, it is possible to cope with the transfer error shown in FIG. 10 by providing only the setting timings of the settings (2) and (3) without providing the timing of the setting (1). In other words, the timing of the setting (1) is not necessary for setting for the Set_Address request. In this case, in the above embodiment, the Configuration Value setting in the Set_Configuration request set in the setting (1) is also performed in the setting (2).

It is a block diagram of a structure of the USB device controller of the USB device of the Example of this invention. It is a flowchart of the process of the status stage of the USB device of the Example of this invention. It is a block diagram of the structure of the conventional USB system. 4 is a timing chart of data transfer to the USB device of FIG. 3. It is a timing chart of the address setting to a USB device. It is a block diagram for demonstrating schematic structure of the conventional USB host and USB device. It is a block diagram of the structure of the conventional USB device controller. 10 is a timing chart of case 1 when there is an error in transferring an address setting to a USB device. 12 is a timing chart of case 2 when there is an error in transferring an address setting to a USB device. 12 is a timing chart of case 3 in the case where there is an address setting transfer error to the USB device.

Explanation of symbols

1: USB host 2, 2A, 2B, 2C: USB device 21: USB device controller, 211: USBPHY, 212: packet control circuit, 213: endpoint buffer, 214: DMA controller, 215: control register, 216: setting circuit 2161: Setup data buffer, 2162: Request decode circuit, 2163: Packet identification circuit, 2164: Setting condition generation circuit

Claims (6)

  A USB device that automatically responds to a control transfer request received from a USB host, wherein the setting requested by the request is performed at a timing specified by the content of the request.   When the content of the request is a request that can automatically respond to the retry when receiving the retry of the IN transfer request from the USB host after performing the setting, The USB device according to claim 1, wherein the setting is performed without waiting for reception of an ACK signal transmitted by the USB host that has received a response transmitted by the USB device.   If the content of the request is set without waiting for the reception of the ACK signal transmitted by the USB host that has received the response transmitted by the USB device, the request is received when an IN transfer request retry is received from the USB host. The USB device according to claim 2, wherein when the automatic response to the retry is impossible, the setting is performed after the reception of the ACK signal.   When the content of the request can identify the next packet that the USB host that has received the response transmitted by the USB device in response to the request transmits to the USB device following the ACK signal, the specification can be performed. The USB device according to claim 1, wherein the setting is performed after waiting for reception of the next packet.   A setup buffer for storing data received from the USB host in the setup stage of the control transfer, and comparing data received from the USB host after transmitting a response to the request with data stored in the setup data buffer; 5. The USB device according to claim 4, further comprising a packet identification circuit for identifying reception of the specified next packet.   6. The USB device according to claim 1, further comprising a request decoder circuit that decodes the request and determines contents of the request.

Images