JP2009048444A - Control method of usb device, controller and electronic equipment - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a controller capable of preventing such a problem that a USB device cannot be recognized. <P>SOLUTION: The USB controller 40 includes a register 130 which can input information for determining the time regarding control of the USB device 10 from outside, a processing part 120 which determines the time regarding control of the USB device 10 based on the information input in the register 130, and a USB interface 80 which is connected to the USB device 10 through USB and outputs a signal or data to the USB at the timing according to the time determined by the processing part 120. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a method for controlling a USB device by communicating with the USB device via a USB (Universal Serial Bus), a controller for controlling the USB device, and an electronic apparatus including such a controller.

  In recent years, USB (Universal Serial Bus) has been spotlighted as a high-speed serial interface. In USB, signals or data are transmitted and received between a USB host device and a USB device device.

  In the USB standard, in order for the USB host side device to recognize the USB device side device, etc., the time for which the USB host side device outputs a steady signal, periodic signal or data to the USB and / or continues output, Alternatively, various times from when a certain signal or data is output to the USB until the next signal or data is output to the USB are defined.

  However, in reality, there is a problem that even if the USB host side device outputs a signal or data to the USB according to the time specified in the USB standard, the USB device side device cannot be recognized.

  As a related technique, Japanese Patent Application Laid-Open No. 2004-228561 discloses a serial that prevents a transferred data file from being discarded unnecessarily when a cable is pulled out during data transfer or when a bus reset signal is generated. A bus communication system is listed.

JP 2003-242103 A

  The present invention has been made in view of the above technical problems, and the object of the present invention is to output a signal or data to the USB according to the time specified by the USB host device on the USB standard. Another object of the present invention is to provide a USB device control method capable of preventing problems such as inability to recognize a USB device side device. The present invention also provides such a controller. Moreover, this invention is providing the electronic device containing such a controller.

  The present invention is a method executed by a controller for communicating with a USB device via a USB (Universal Serial Bus) to control the USB device, in order to determine at least one time related to the control of the USB device. USB is received from the outside, determines at least one time based on the information, and controls a USB device by outputting a signal or data to the USB at a timing according to the determined at least one time. Related to device control method.

  According to the present invention, the timing for outputting a signal or data to USB can be set from the outside, and problems such as inability to recognize the USB device side device can be prevented.

  The present invention is also a controller for communicating with a USB device via a USB (Universal Serial Bus), and information for determining at least one time related to the control of the USB device is input from the outside of the controller. An information input unit that can be connected, a processing unit that determines at least one time based on information input to the information input unit, and at least one determined by the processing unit connected to the USB device via USB And a USB interface unit that outputs a signal or data to the USB at a timing corresponding to one time.

  According to the present invention, the timing for outputting a signal or data to a USB can be set from the outside. As a result, problems such as inability to recognize the USB device side device can be prevented.

  In the present invention, the processing unit includes a CPU core that executes a driver program for controlling the USB interface unit, and the CPU core determines at least one time based on information input to the information input unit. May be.

  In this way, it is possible to easily realize the process of determining at least one time based on information input from the outside by the program.

  In the present invention, the information input unit includes a register for externally writing information relating to controller setting and / or control, and at least one data for determining at least one time is externally written to the register. The processing unit may determine at least one time based on at least one data written in the register.

  In this way, it is possible to input at least one data for determining at least one time from the outside by using a register for originally writing information relating to controller setting and / or control from the outside. As a result, the timing for outputting a signal or data to the USB can be set from the outside without newly providing an external input terminal or the like.

  In the present invention, at least one value representing at least one time may be written to the register, and the processing unit may determine the time represented by the at least one value as at least one time.

  In this way, the processing for the processing unit to determine at least one time can be simplified. Further, at least one time can be set from a main CPU or the like that is connected to the controller and can access the register.

  The present invention further includes a storage unit that stores a plurality of tables each including at least one value representing at least one time, and data specifying any of the plurality of tables is written to the register, and the processing unit The time represented by at least one value included in the table specified by the data in the plurality of tables may be determined as at least one time.

  In this way, a plurality of times can be determined while reducing the amount of data written to the register from the outside.

  In the present invention, the information input unit includes a signal input circuit capable of inputting at least one signal for determining at least one time from the outside, and the processing unit is input to the signal input circuit. At least one time may be determined based on at least one signal.

  In this way, at least one time can be set from outside without changing or adding to the software or the like of the main CPU connected to the controller.

  The present invention further includes a storage unit that stores a plurality of tables each including at least one value representing at least one time, and at least one signal specifying any of the plurality of tables is input to the signal input circuit. The processing unit may determine a time represented by at least one value included in a table specified by at least one signal among the plurality of tables as at least one time.

  In this way, a plurality of times can be determined while reducing the number of externally input signals.

  In the present invention, at least one time may include a time related to control for initializing the USB device and / or a time related to control for resuming the USB device.

  In this way, the time related to the control for initializing the USB device and / or the time related to the control for resuming the USB device, which may cause an event that the actual USB device is not normally recognized and / or cannot operate normally. Can be set from the outside. As a result, it is possible to prevent an event that the actual USB device is not normally recognized and / or cannot be normally operated.

  In the present invention, at least one time is a time for outputting a steady signal, a periodic signal or data to the USB and / or a time for continuing the output, or a certain signal or data is output to the USB, and then the next time. The time until the signal or data is output to the USB may be included.

  The present invention also relates to an electronic device including the controller according to the present invention and a host CPU connected to the controller via a bus.

  Hereinafter, embodiments of the present invention will be described in detail. In addition, this embodiment demonstrated below does not unduly limit the content of this invention described in the claim. Further, not all of the configurations described in the present embodiment are essential as a solution means of the present invention. The same constituent elements are denoted by the same reference numerals and description thereof is omitted.

1. Times stipulated in the USB standard for controlling a USB device Several times stipulated in the USB standard for controlling a USB device will be described by way of examples.

1.1 When a USB Host and a USB Device are Connected First, a case where a USB host and a USB device are connected (attached) will be described.

1.1.1 When HS Host and HS Device are Connected FIG. 1 shows a waveform diagram of signals on the USB when an HS (High-speed) host and HS device are connected.

  When the host and the device are connected, a potential is supplied from the host to VBUS. After the VBUS potential rises to a given threshold potential at timing TM0, at timing TM1, the device is specified to pull up DP (D +) to 3.3V using a 1.5KΩ pull-up resistor. ing. This pull-up operation performed by the device is said to turn on FS termination. A bus power operation device that operates by receiving power supply from VBUS is specified to turn on FS termination within 100 ms from timing TM0.

It should be noted that DP (D +) is at H level and DM (D−) is at L level (more precisely, differential “1” (D +> V _OH (min) and D− <V _OL (max )))) Is called J state, chirp J or simply J. Further, DP is at L level and DM is at H level (more precisely, it is Differential “0” (D−> V _OH (min) and D + <V _OL (max))). , K state, chirp K, or simply K. Further, the fact that DP is at L level and DM is at L level (more precisely, D + and D− <V _OL (max)) is called SE0 (Single-ended 0).

  As will be described in detail later, the J state is defined as continuing for 100 ms or more from the timing TM1. Then, at timing TM2 after 100 ms has elapsed from timing TM1, the device enters a suspend (SUSPEND) state. This is because the USB standard stipulates that the device enters the suspended state when the J state continues for 100 ms or longer.

Thereafter, at timing TM3, DP becomes L level and becomes SE0. The time from the timing TM1 to the timing TM3 is defined as T _ATTDB in the USB standard, and the USB device is defined as setting this time within 100 ms.

  When SE0 continues for 2.5 μs or longer, the device transitions from the suspended state to the reset state at timing TM4. Further, the device starts chirp K output within 2.5 μs to 3 ms from the start of SE 0, that is, timing TM 3, and continues the chirp K output for 1 ms or longer. Thereafter, the device ends the output of the chirp K at the start time of SE0, that is, at timing TM5 less than 7 ms from timing TM3.

  At timing TM6 after SE0 continues for 100 μs from timing TM5, the host outputs a combination of chirp K and chirp J (alternately outputs chirp K and chirp J). When the device detects three (three times) combinations of chirp K and chirp J at timing TM7, the device turns off FS termination and shifts to the HS mode.

Thereafter, the host ends the output of the combination of chirp K and chirp J at timing TM8, and the device becomes HS idle. The time from the timing TM3 to timing TM8, the USB _standard, (in the root hub _{T DRSTR) T DRST} are defined _{as, T DRST} is defined as that at 20ms or less than 10 ms. Also, T _DRSTR is defined as being 50 ms or longer.

Further, the time from timing TM8 to timing TM9 is defined as _TRSTRCY in the USB standard, and the USB device is defined as setting this time within 10 ms.

1.1.2 When HS Host and FS Device are Connected FIG. 2 shows a waveform diagram of signals on the USB when the HS host and FS (Full-Speed) device are connected.

  When the host and the device are connected, a potential is supplied from the host to VBUS. After the potential of VBUS rises to a given threshold potential at timing TM10, the device turns on FS termination at timing TM11. A bus power operation device that operates by receiving power supply from VBUS is defined to turn on FS termination within 100 ms from timing TM10.

  The J state is defined as continuing for 100 ms or more from the timing TM11. The device enters a suspended state at timing TM12 after 100 ms has elapsed from timing TM11.

Thereafter, at timing TM13, DP becomes L level and becomes SE0. The time from the timing TM11 to the timing TM13 is defined as _TATTDB in the USB standard, and the USB device is defined as setting this time within 100 ms.

  When SE0 continues for 2.5 μs or longer, the device transitions from the suspended state to the reset state at timing TM14. Note that the FS device does not output chirp K, unlike the HS device described above.

  At timing TM18 after SE0 continues for 10 ms from timing TM13, the device becomes FS idle. Note that, unlike the case where the HS host and the HS device are connected (described above), the combination of chirp K and chirp J is not output between timing TM13 and timing TM18. Further, the time from the timing TM13 to the timing TM18 is defined as being 10 ms or more as in the case where the HS host and the HS device are connected. Also, the time from the timing TM18 to the timing TM19 is defined as being 10 ms or more as in the case where the HS host and the HS device are connected.

1.2 SetAddress Standard Device Request Recovery Interval Time USB communication is performed between the host and the device endpoint. The host communicates with the device endpoint by assigning the device a unique address within a system. When the host assigns an address to a device, a SetAddress standard device request is used. In the USB standard, the recovery interval (recovery) of the SetAddress standard device request, which is a wait time from when the host receives a response to the SetAddress standard device request from the USB device until the next request is transmitted to the USB device. interval) The time is specified as 2 ms or more. That is, the USB device needs to be ready to receive the next request within 2 ms after transmitting a response to the SetAddress standard device request to the USB host.

1.3 Resume Signal Output Time to Resume Suspended Device The USB standard stipulates that the host can resume a SUSPEND device. Then, the USB standard, the output time of the resume signal for the host to resume a device suspend state _is defined as a _{T DRSMDN,} this _{T DRSMDN} is defined as more than 20 ms.

1.4 Measured value of USB device device The present inventor measured the various times as described above in a general USB device device on the market. In addition, the present inventor measured various times as described above between a commercially available general personal computer (USB host device) and a commercially available general printer (USB device device). went.

  FIG. 3 shows the time defined in the USB standard (standard value) and the time actually measured in the USB device device (actual value). As shown in FIG. 3, the present inventor has found that the measured value of a commercially available USB device device is longer than the standard value of USB. When such a USB device device is connected to the USB host device, if the USB host device operates according to the USB standard value, the USB host device cannot recognize the USB device device normally, or the USB device device is normal. It can happen that it doesn't work.

  In the USB standard, the USB device device is defined as having a resume function. However, the present inventor has also found that there is a USB device device that does not have a resume function and can be said to be a violation of the standard. When a USB device device that can be said to be in violation of the standard is connected to the USB host device, the USB host device cannot resume the USB device device, and as a result, the USB host device and / or the USB device It can happen that the device freezes.

2. First Embodiment 2.1 Configuration FIG. 4 shows a configuration example of a USB host controller 40 (controller in a broad sense) and an electronic apparatus 20 including the USB host controller 40 of the present embodiment that can solve the above problems.

  The electronic device 20 includes a main CPU 30 and a USB host controller 40. The USB host controller 40 includes a USB I / F 80, a transfer controller 100, a processing unit 120, a register 130 (information input unit in a broad sense), and a DMA processing unit 140. The USB host controller 40 may be realized as a semiconductor integrated circuit.

  Note that the USB host controller 40 and the electronic device 20 are not limited to the configuration shown in FIG. 4, and some of the components are omitted, the connection form between components is changed, or components different from those shown in FIG. It is possible to carry out a modified implementation. For example, the USB host controller 40 can be modified to omit the configuration of the transfer controller 100, the processing unit 120, the DMA processing unit 140, and the like. Moreover, in the electronic device 20, you may add components (for example, an operation part, a display part, ROM, RAM, an imaging part, a power supply etc.) other than what is shown by FIG.

  As the electronic device 20 of the present embodiment, a video camera, a digital camera, a portable music player, a portable video player, an optical disk drive device, a hard disk drive device, an audio device, a mobile phone, a portable game machine, an electronic notebook, an electronic notebook Various things such as a dictionary or a portable information terminal can be considered.

  The main CPU 30 performs overall processing and control of the electronic device 20. For example, when the electronic device 20 is a video camera, the main CPU 30 functions as a camera processor, and performs control of the imaging device, image effect processing, image compression processing, and the like.

  The register 130 is mapped to the address space (memory space, I / O space, etc.) of the main CPU 30, and commands issued by the main CPU 30 via the CPU bus are written into the register 130. The USB I / F 80, the transfer controller 100, the processing unit 120, and the DMA processing unit 140 operate based on a command written in the register 130. In addition, the operation statuses of the USB I / F 80, the transfer controller 100, the processing unit 120, the DMA processing unit 140, and the like are written in the register 130, and the main CPU 30 can read out the operation status written in the register 130.

  The USB I / F 80 is an interface for performing data transfer (high-speed serial transfer) via the USB. Specifically, the USB I / F 80 includes a physical layer circuit that receives and transmits data via a USB (serial bus), and performs data transfer with the USB device 10.

  When the USB I / F 80 has a host function, a USB device may be connected to the USB, and data transfer may be performed between the USB device.

  The DMA processing unit 140 is connected to the CPU bus, receives data transmitted to the USB device 10 from the CPU bus, performs DMA transfer to the transfer controller 100, and / or transfers data received from the USB device 10 to the transfer controller 100. To DMA transfer to the CPU bus.

  The transfer controller 100 controls data transfer between the USB I / F 80 and the DMA processing unit 140. As a result, the data transferred from the CPU bus can be written to the USB device 10 and the data written to the USB device 10 can be transferred to the CPU bus.

  The transfer controller 100 includes a data buffer 102 (for example, a FIFO). The data buffer 102 is a buffer for temporarily storing data transferred by the transfer controller 100. The data buffer 102 can be realized by a memory such as a RAM.

  The processing unit 120 performs overall processing and control of the USB host controller 40 and controls each circuit block included in the USB host controller 40. A part or all of the functions of the processing unit 120 can be realized by, for example, a CPU and firmware operating on the CPU. The processing unit 120 can also be realized by a dedicated hardware circuit.

  In the present embodiment, the processing unit 120 includes a CPU 121, a RAM 122, and a ROM 123. The ROM 123 stores programs such as an OS (Operating System), a BIOS (Basic Input / Output System), an API (Application Programming Interface), an IC common function driver, a USB host class driver, and a USB host stack. The ROM 123 may be an EEPROM or the like.

  The processing unit 120 may not be built in the USB host controller 40, and a CPU I / F that performs interface processing with the main CPU 30 may be provided. In this case, the main CPU 30 controls the USB host controller 40 and each circuit block included in the USB host controller 40 via the CPU I / F.

  A program for operating the processing unit 120 is stored in a memory (EEPROM, etc.) on the main CPU 30 side, the main CPU 30 issues a download command after power-on, and is downloaded to the USB host controller 40 via the CPU bus. You may make it do.

  The CPU 121 executes a program stored in the ROM 123 while using the RAM 122 as a work area.

  FIG. 5 shows functional blocks realized by the CPU 121 executing a program stored in the ROM 123.

  The OS block is realized by the CPU 121 executing the OS program stored in the ROM 123, and is an operating system block for operating other programs in the ROM 123. Task generation and management, and other software blocks Provide service calls.

  The BIOS block is a block realized by the CPU 121 executing the BIOS program stored in the ROM 123, and the main CPU 30 analyzes the command set in the register 130 of the USB host controller 40, and an appropriate function of the API block. Is a software block that implements the functions of the USB host controller 40 by calling.

  The API block is a block realized by the CPU 121 executing an API program stored in the ROM 123, and software that provides the functions of the hardware and firmware of the USB host controller 40 to the BIOS block in a functional format. It is a block.

  The IC common function block is a block that is realized by the CPU 121 executing the IC common function program stored in the ROM 123. The initial setting of the USB host controller 40, the power management function, and the like of the USB host controller 40 itself. This is a software block for setting and control.

  The USB host class driver block is a block realized by the CPU 121 executing the USB host class driver program stored in the ROM 123, and is a software block that processes the upper protocol of the USB host stack. The USB standard HID (Human Interface Device) class, Mass Storage class, Audio (Audio) class, Video (Video) class, Printer (Printer) class, Communication device (Communication Device) class, Picture Transfer Protocol class Is a class driver block corresponding to.

  The USB host stack block is a block realized by the CPU 121 executing a USB host stack program stored in the ROM 123. The USB host stack block controls the USB I / F 80 to connect / disconnect the USB device 10, power management, and end. It is a software block that performs transfer processing for each point.

2.2 USB I / F
In USB, endpoints (EP0 to EP15) as shown in FIG. 6A are prepared on the USB device side. In USB, control transfer, isochronous transfer, interrupt transfer, bulk transfer, and the like are defined as transfer types, and each transfer includes a series of transactions. As shown in FIG. 6B, the transaction includes a token packet, an optional data packet, and an optional handshake packet.

  In the OUT transaction, as shown in FIG. 6C, first, the USB host issues an OUT token (talk packet) to the USB device. Next, the USB host transmits OUT data (data packet) to the USB device. If the USB device succeeds in receiving the OUT data, the USB device transmits an ACK (handshake packet) to the USB host. On the other hand, in the IN transaction, as shown in FIG. 6D, first, the USB host issues an IN token to the USB device. The USB device that has received the IN token transmits IN data to the USB host. When the USB host succeeds in receiving the IN data, the USB host transmits ACK to the USB device.

  “D ← H” means that information is transferred from the USB host to the USB device, and “D → H” means that information is transferred from the USB device to the USB host. .

  Next, a USB bulk-only transport protocol will be described. Mass storage devices such as hard disk drives and optical disk drives belong to a class called mass storage. In this mass storage class, a protocol called bulk-only transport is standardized.

  In bulk-only transport, packet transfer is performed using two endpoints, bulk IN and bulk OUT. That is, 31 bytes of data called CBW (Command Block Wrapper) is used for the command and transferred using the endpoint of the bulk OUT. For data transfer, endpoints of bulk IN and bulk OUT are used according to the transfer direction. As the status for the command, 13-byte data called CSW (Command Status Wrapper) is used and transferred using the bulk IN endpoint.

  Next, transmission / reception processing (protocol control) of bulk-only transport will be described with reference to FIGS. As shown in FIG. 7A, when the USB host transmits data to the USB device, first, command transport is performed in which the USB host transmits CBW to the USB device. Specifically, the USB host transmits a token packet designating the end point EP1 to the USB device, and then transmits CBW to the end point EP1 of the USB device. This CBW includes a write command. When the ACK handshake packet is returned from the USB device to the USB host, the command transport is completed.

  When the command transport is completed, the process moves to the data transport. In this data transport, the USB host first transmits a token packet designating the end point EP1 to the USB device, and then transmits OUT data to the end point EP1 of the USB device. When an ACK handshake packet is returned from the USB device to the USB host, one transaction is completed. When such a transaction is repeated and data is transmitted for the data length specified by the CBW, the data transport is completed.

  When the data transport ends, the status transport is entered. In this status transport, first, the USB host transmits a token packet designating the end point EP2 to the USB device. Then, the USB device transmits the CSW at the end point EP2 to the USB host. When the ACK handshake packet is returned from the USB host to the USB device, the status transport is completed.

  When the USB host receives data from the USB device, processing is performed as shown in FIG. FIG. 7B is different from FIG. 7A in that the CBW of the command transport includes a read command and that IN data is transferred in the data transport.

  FIG. 8 shows a configuration example of the USB I / F 80. The USB I / F 80 includes a transceiver 220, a transfer controller 250, and a data buffer 290.

  The transceiver 220 (dual transceiver) is a circuit for transmitting and receiving USB data using differential signals (DP, DM), and includes a host transceiver 230 and a device transceiver 240.

  The host transceiver 230 has an analog front-end circuit (physical layer circuit) and a high-speed logic circuit, and supports USB HS mode (480 Mbps), FS mode (12 Mbps), and LS mode (1.5 Mbps). The device transceiver 240 has an analog front-end circuit (physical layer circuit) and a high-speed logic circuit, and supports USB HS mode and FS mode. As the device transceiver 240, a circuit compliant with the UTMI (USB 2.0 Transceiver Macrocell Interface) specification can be used.

  The transfer controller 250 is a controller for controlling data transfer via the USB, and performs data transfer control such as a transaction layer and a link layer. The transfer controller 250 includes a host controller 260, a device controller 270, and a port selector 280. Note that some of these may be omitted.

  The host controller 260 (host serial interface engine) controls data transfer in the host mode. Specifically, the host controller 260 performs transaction scheduling (issue), transaction management, packet generation & analysis, and the like. It also generates bus events such as suspend, resume, and reset. Further, it detects the connection / disconnection state of the bus and controls the VBUS.

  A device controller 270 (device serial interface engine) controls data transfer in the device mode. Specifically, the device controller 270 performs transaction management, packet generation & analysis, and the like. It also controls bus events such as suspend, resume, and reset.

  The port selector 280 is a selector for selecting and enabling either the host mode or the device mode. For example, when the host mode is selected by setting a register or the like, the port selector 280 selects (enables) the host controller 260 and the host transceiver 230. On the other hand, when the device mode is selected by setting the register or the like, the port selector 280 selects (enables) the device controller 270 and the device transceiver 240.

  The data buffer 290 (FIFO, packet buffer) is a buffer for temporarily storing (buffering) data (transmission data, reception data) transferred via a USB (serial bus). The data buffer 290 can be realized by a memory such as a RAM.

  Note that some functions of the transfer controller 250 and the data buffer 290 may be realized by the transfer controller 100 and the data buffer 102 of FIG. FIG. 8 shows an example of the USB I / F 80 that performs both the host operation and the device operation. However, only the device operation may be performed.

2.3 Operation Next, the operation of this embodiment will be described. In the USB host controller 40 according to the present embodiment, the time related to the USB device control is not fixed to the time (standard value) defined in the USB standard as the time related to the USB device control, but according to the instruction from the main CPU 30. Try to change the time.

2.3.1 Operation at Initial Time First, the operation of the electronic device 20 at the initial time (power-on, reset time, etc.) will be described.

FIG. 9 is a flowchart showing the operation of the electronic device 20 at the initial time.
First, the main CPU 30 _sets information (which may be a name indicating time (T _ATTDB , T _DRST, etc.)) and / or a time value in the register 130 (step S11). .

  For example, the main CPU 30 may set a name and a time value representing time in the register 130 as shown in FIGS. FIG. 10A shows an example in which a long time value is set so that many USB devices can be recognized or operated. FIG. 10B shortens the waiting time and speeds up the operation. Therefore, this is an example in which a shorter time value is set, and FIG. 10C is an example in which a time value conforming to the USB standard is set. Alternatively, FIGS. 10A to 10C may be stored in advance in the ROM 123 as tables, and the main CPU 30 may set information indicating which table is used in the register 130.

  In FIGS. 10A to 10C, five time values are set. However, values (standard values) defined in the USB standard are used as time values other than these five time values. You can do it.

  In addition, when the time to be changed is determined in advance, information for specifying the time to be changed (such as a name indicating time) can be made unnecessary.

  The BIOS block of the USB host controller 40 analyzes the contents of the register 130 and calls the API with information specifying the time to be changed and the time value as arguments (step S21).

  The API block of the USB host controller 40 calls the USB host stack with information specifying the time to be changed and the time value as arguments (step S31).

  The USB host stack block of the USB host controller 40 sets and / or changes the time value on the RAM 122 based on the argument (step S41). A default time value may be written in advance on the RAM 122, and the USB host stack block may overwrite this default value.

  When returning from step S41 (USB host stack block) and step S31 (API block), the BIOS block sets a time value change completion status in the register 130 (step S22). The main CPU 30 can read the time value change completion status by referring to the register 130.

2.3.2 Operation when USB Host and USB Device are Connected Next, the operation of the USB host controller 40 when the USB device 10 is connected will be described.

FIG. 11 is a flowchart showing the operation of the USB host controller 40 when the USB device 10 is connected.
First, the USB host controller 40 (more specifically, the USB host stack block) performs a system initialization operation (step S51) and waits for the USB device 10 to be connected.

When the USB device 10 is connected (for example, a USB cable for connecting the USB host controller 40 and the USB device 10 is inserted), the USB host controller 40 performs a power supply stabilization wait time adjustment operation (steps). S52). More specifically, the USB host controller 40 determines the power supply stabilization wait time (timing TM1 to TM3 in FIG. 1) based on the set value of _TATTDB set from the main CPU 30 (see FIGS. 10A to 10C). And / or adjusting operation of timing TM11 to TM13 in FIG. That is, the USB host controller 40 outputs a signal or data to the USB at a timing according to the time based on the setting value of _TATTDB set from the main CPU 30. For example, the USB host controller 40 adjusts the length (time) of the timings TM1 to TM3 in FIG. 1 and / or the timings TM11 to TM13 in FIG.

Next, the USB host controller 40 performs a time adjustment operation from the reset of the USB device 10 to the packet issuance (step S53). More specifically, USB host controller 40, based on the set value of _{T DRST} and _{T RSTRCY} set from the main CPU 30 (see FIG. 10 (a) ~ (c) ), until the packet issued from the reset of the USB device 10 (See timings TM3 to TM8 in FIG. 1 and / or timings TM13 to TM18 in FIG. 2). That is, the USB host controller 40 outputs a signal or data to the USB at a timing according to the time based on the setting value of _TRSTRCY set from the main CPU 30. For example, the USB host controller 40 adjusts the length (time) of the timings TM3 to TM8 in FIG. 1 and / or the timings TM13 to TM18 in FIG.

  Next, the USB host controller 40 performs an enumeration operation (step S54). The enumeration operation includes an address change time adjustment operation.

FIG. 12 is a flowchart showing the address change time adjustment operation.
First, the USB host controller 40 (more specifically, the USB host stack block) issues a SetAddress standard device request to the USB device 10 (step S61), and the USB device 10 executes the SetAddress standard device request (step S61). In step S71, a response to the SetAddress standard device request is transmitted to the USB host controller 40 (step S72).

  When the USB host controller 40 receives a response to the SetAddress standard device request from the USB device 10, the set value of the recovery interval time of the SetAddress standard device request set from the main CPU 30 (FIGS. 10A to 10C). ))), A wait process is performed (step S62).

  The USB host controller 40 issues a GetDescriptor standard device request to the USB device 10 when the wait (wait) processing based on the set value of the recovery address time of the SetAddress standard device request set from the main CPU 30 is completed. (Step S63), the USB device 10 executes a GetDescriptor standard device request (Step S73), and transmits a response to the GetDescriptor standard device request to the USB host controller 40 (Step S74). In other words, the USB host controller 40 outputs a GetDescriptor standard device request to the USB at a timing corresponding to the time based on the set value of the recovery interval time of the SetAddress standard device request set from the main CPU 30. In other words, the USB host controller 40 adjusts the length of the wait (wait) time from when a response to the SetAddress standard device request is received from the USB device 10 until the GetDescriptor standard device request is issued.

  Thereafter, communication is performed between the USB host controller 40 and the USB device 10 as necessary.

  As described above, according to the present embodiment, the USB device 10 is controlled in accordance with an instruction from the main CPU 30 without being fixed to the time (standard value) defined by the USB standard for controlling the USB device. The time related to the control can be changed. Accordingly, it is possible to prevent the USB host controller 40 from recognizing the USB device 10 normally or from not operating normally.

2.3.3 Operation when Resume USB Device Next, the operation of the USB host controller 40 when the USB device 10 in the suspended state is resumed will be described.

FIG. 13 is a flowchart showing the operation of the USB host controller 40 when the USB device 10 in the suspended state is resumed.
First, the USB host controller 40 (more specifically, the USB host stack block) performs a resume operation (step S81). The resume operation includes a resume time adjustment operation (step S82).

In the resume time adjustment operation (step S82), the USB host controller 40 _resumes the USB device 10 based on the set value of _TDRSMDN set by the main CPU 30 (see FIGS. _{10A to 10C} ). Adjust the length (time) of the resume signal. That is, the USB host controller 40 continues the output of the resume signal for a time based on the set value of _TDRSMDN set by the main CPU 30 (see FIGS. _{10A to 10C} ).

  Then, when the resume of the USB device 10 fails (step S83), the USB host controller 40 performs a reset process of the USB device 10 (step S84). Specifically, the USB host controller 40 outputs a reset signal (SE0) for resetting the USB device 10 to the USB device 10.

  As described above, according to the present embodiment, the USB device 10 is controlled in accordance with an instruction from the main CPU 30 without being fixed to the time (standard value) defined by the USB standard for controlling the USB device. The time related to the control can be changed. This makes it possible to prevent the USB host controller 40 and / or the USB device 10 from freezing even if the USB device 10 does not have a resume function and is a USB device device that can be said to be a violation of the standard. .

3. Second Embodiment 3.1 Configuration FIG. 14 shows a configuration example of an ATA-USB bridge controller 70 (controller in a broad sense) of the present embodiment and an electronic device 50 including the same. In the present embodiment, paying attention to the presence of the ATA host I / F 62 of the main CPU 60, the ATA device I / F 160 corresponding to the host I / F 62 is provided in the ATA-USB bridge controller 70. In this way, data from the main CPU 60 can be written to the transfer controller 100 via the device-side I / F 160. In this embodiment, a USB I / F 80 for transferring data written in the transfer controller 100 to the USB device 10 is provided. In this way, a bus bridge function between the ATA bus and the USB can be realized.

  Note that the ATA-USB bridge controller 70 and the electronic device 50 are not limited to the configuration in FIG. 14, and some of the components are omitted, the connection form between the components is changed, or components different from those in FIG. 14. It is possible to carry out a modification in which For example, the ATA-USB bridge controller 70 may be modified to omit the configuration of the processing unit 150, USB I / F 80, device side I / F 160, and the like. In the electronic device 50, components other than those shown in FIG. 14 (for example, an operation unit, a display unit, a ROM, a RAM, an imaging unit, or a power source) may be added.

  The electronic device 50 includes a main CPU 60 and an ATA-USB bridge controller 70. The ATA-USB bridge controller 70 may be realized as a semiconductor integrated circuit.

  The main CPU 60 performs overall processing and control of the electronic device 50. The main CPU 60 includes an ATA host-side I / F (interface) 62. The host-side I / F 62 may be of the CF + interface standard that switches from the CF + interface to the ATA interface by mode setting.

  The ATA-USB bridge controller 70 includes an ATA (IDE) device-side I / F 160. Further, it can include a USB I / F 80, a transfer controller 100, a processing unit 150, and a GPI (input) circuit 170 (information input unit in a broad sense).

  Here, the device-side I / F 160 is an interface for performing data transfer (communication) with the main CPU 60 (ATA host) via the ATABUS1. The ATA in this embodiment can include ATAPI (AT Attachment with Packet Interface). In addition, it is possible to include standards developed from conventional ATA standards such as serial ATA and CE-ATA. The ATA-USB bridge controller 70 may be provided with an ATA host-side I / F.

  The device side I / F 160 includes a register 162. A command issued by the main CPU 60 via the ATABUS 1 is written in the register 162. Specifically, a task register included in the device side I / F of the ATA can be used as the register 162. In this embodiment, a command assigned as a vendor definition command (Vender specific command) among ATA commands is written to the register 162 (task register). The transfer controller 100 and the processing unit 150 can operate based on the vendor definition command. For example, the transfer controller 100 determines the data transfer direction between the device-side I / F 160 and the USB I / F 80 based on a vendor-defined transfer control command (command for specifying the transfer direction and transfer data amount) set in the register 162. To do. The transfer controller 100 also determines the amount of data to be transferred between the interfaces.

  The GPI circuit 170 includes GPI (input) terminals 171 and 172 capable of inputting signals from the outside. In FIG. 14, the GPI terminal 171 is connected to the power supply potential VDD via a pull-up resistor. That is, the H level is input to the GPI terminal 171. The GPI terminal 172 is connected to a power supply potential (ground potential) VSS via a pull-down resistor. That is, the L level is input to the GPI terminal 172.

  Although the GPI circuit 170 includes two GPI terminals 171 and 172 here, it may include one or three or more GPI terminals. Further, instead of the GPI (input) circuit 170, a GPIO (input / output) circuit may be used. In addition, although the GPI terminals 171 and 172 are pulled up or pulled down here, an output signal from an output circuit whose output level is variable may be input to the GPI terminals 171 and 172.

  When the USB I / F 80 has a host function, a USB device may be connected to the USB, and data transfer may be performed between the USB device.

  The transfer controller 100 controls data transfer between the device side I / F 160 and the USB I / F 80. As a result, the data transferred from the main CPU 60 can be written to the USB device 10, and the data written to the USB device 10 can be transferred to the main CPU 60.

  The processing unit 150 performs overall processing and control of the ATA-USB bridge controller 70 and controls each circuit block included in the ATA-USB bridge controller 70. A part or all of the functions of the processing unit 150 can be realized by, for example, a CPU and firmware operating on the CPU. The processing unit 150 can also be realized by a dedicated hardware circuit.

  In the present embodiment, the processing unit 150 includes a CPU 151, a RAM 152, and a ROM 153. The ROM 153 stores an OS (operating system), main task, ATA device side I / F driver, API, IC common function driver, USB host class driver, USB host stack, GPI circuit driver, and other programs and parameter tables. Yes. The ROM 153 may be an EEPROM or the like.

  The processing unit 150 may not be built in the ATA-USB bridge controller 70, and a CPU I / F that performs interface processing with the main CPU 60 may be provided. In this case, the main CPU 60 controls the circuit blocks included in the ATA-USB bridge controller 70 and the ATA-USB bridge controller 70 via the CPU I / F.

  A program for operating the processing unit 150 is stored in a memory (EEPROM or the like) on the main CPU 60 side. After the power is turned on, the main CPU 60 issues a download command, and the ATA-USB bridge controller 70 ( You may make it download to the memory which an ATA-USB bridge controller has.

  The CPU 151 executes a program stored in the ROM 153 while using the RAM 152 as a work area.

  FIG. 15 shows functional blocks realized by the CPU 151 executing a program stored in the ROM 153.

  The OS block is realized by the CPU 151 executing the OS program stored in the ROM 153, and is an operating system block for operating other programs in the ROM 153. The OS block is used for task generation and management, and for other software blocks. Provide service calls.

  The ATA device side I / F driver block is a block realized by the CPU 151 executing the ATA device side I / F driver program stored in the ROM 153, and controls the hardware of the ATA device side I / F 160. This is a driver block that processes commands written from the ATA host-side I / F 62 of the main CPU 60 to the register 162 (task register) of the ATA device-side I / F 160 in accordance with the ATA / ATAPI protocol.

  The main task block is realized by the CPU 151 executing the main task program stored in the ROM 153 and controls other software blocks. The main CPU 60 registers the device 162 I / F 160 in the register 162 (task register). Is a software block that analyzes the command set to, and calls an appropriate function of the API block to realize the function of the ATA-USB bridge controller.

  The API block is a block realized by the CPU 151 executing the API program stored in the ROM 153, and the functions of the hardware and firmware of the ATA-USB bridge controller 70 are expressed in a function format with respect to the main task block. Software block to be provided.

  The IC common function block is a block realized by the CPU 151 executing an IC common function program stored in the ROM 153. The ATA-USB bridge includes initial settings of the ATA-USB bridge controller 70, a power management function, and the like. It is a software block for setting and controlling the controller 70 itself.

  The USB host class driver block is a block realized by the CPU 151 executing a USB host class driver program stored in the ROM 153. The USB host class driver block is a software block that processes the upper protocol of the USB host stack. Class driver blocks corresponding to classes, mass storage classes, audio classes, video classes, printer classes, communication device classes, picture transfer protocol classes, and the like.

  The USB host stack block is a block realized by the CPU 151 executing the USB host stack program stored in the ROM 153. The USB host stack block controls the USB I / F 80, connects / disconnects the USB device 10, performs power management, and ends. It is a software block that performs transfer processing for each point.

  The GPI circuit driver block is a block that is realized by the CPU 151 executing a GPI circuit driver program stored in the ROM 153, controls the hardware of the GPI circuit 170, and is connected to the GPI terminals 171 and 172 of the GPI circuit 170. This is a driver block that provides a function of controlling the GPI circuit 170 such as reading a supplied value (H level or L level) and outputting it to the main task block.

  Further, the ROM 153 stores a plurality of parameter tables as shown in FIGS. 10A to 10C, for example. As will be described later, the ATA-USB bridge controller 70 selects and uses one of a plurality of parameter tables stored in the ROM 153 based on a signal input to the GPI circuit 170 from the outside. To do.

3.2 Device side I / F of ATA
FIG. 16 shows a configuration example of the ATA device-side I / F 160. As shown in FIG. 16, the device-side I / F 160 includes a task register 200, an MDMA / PIO control unit 202, an UltraDMA control unit 204, a data buffer 206, and a transfer control unit 208.

  The task register 200 is a register standardized by ATA (IDE), and includes a command block register and a control block register. Here, the command block register is a register used to issue a command or read a status. The control block register is a register used for controlling the device and reading the substitute status.

  FIG. 17 shows a register configuration of the task register 200. FIG. 17 shows a command block register that is selected when the chip select signals CS1 and CS0 (# indicates negative logic) are at the H and L levels, respectively. In FIG. 17, chip select signals CS1 and CS0 and address signals DA2, DA1, and DA0 are at H, L, H, H, and H levels, respectively. In the case of register write by the host, the command register indicated by A1 is set. In the case of a register read by the host, the status register indicated by A1 is accessed.

  The MDMA / PIO control unit 202 performs device-side control processing for ATA multiword DMA transfer and PIO transfer. The UltraDMA control unit 204 performs device-side control processing for ATA UltraDMA transfer. The data buffer 206 (FIFO) is a buffer for adjusting (buffering) the difference in transfer rate of data transfer. The transfer control unit 208 controls data transfer with the subsequent circuit (transfer controller 100, data buffer 102).

  Next, ATA data transfer will be described with reference to the signal waveforms in FIGS. 18 (A) to 19 (B). In FIGS. 18A to 19B, CS [1: 0] is a chip select signal used to access each register of the ATA. DA [2: 0] is an address signal for accessing data or a data port. DMARQ and DMACK are signals used for DMA transfer. When the device is ready for data transfer, the device side activates (asserts) DMARQ, and in response, the host side activates DMACK.

  DIOW (STOP) is a write signal used when writing to a register or a data port. Note that it functions as a STOP signal during UltraDMA transfer. DIOR (HDMARDY, HSTROBE) is a read signal used when reading a register or a data port. During UltraDMA transfer, it functions as an HDMARDY and HSTROBE signal. IORDY (DDARDY, DSTROBE) is used as a wait signal when the device side is not ready for data transfer. During UltraDMA transfer, it functions as a DDMRDY and DSTROBE signal.

  INTRQ is a signal used by the device side to request an interrupt from the host side. After the INTRQ becomes active, when the host reads the contents of the status register of the task register on the device side, the device side makes INTRQ inactive (negate) after a predetermined time. By using this INTRQ, the device side can notify the host side of the end of command processing.

  18A and 18B are signal waveform examples at the time of PIO (Parallel I / O) read and PIO write. Reading of the ATA status register is performed by PIO reading of FIG. 18A, and writing to the command register is performed by PIO writing of FIG. 18B. For example, the issue of a vendor-defined command by the main CPU 30 can be realized by PIO write.

  FIGS. 19A and 19B are signal waveform examples during DMA read and DMA write. When ready for data transfer, the device activates DMARQ. In response to this, the host side activates DMACK and starts DMA transfer. Thereafter, DMA transfer of the data DD [15: 0] is performed using DIOR (during reading) or DIOW (during writing).

3.3 Operation Next, the operation of the present embodiment will be described. In the ATA-USB bridge controller 70 according to the present embodiment, the time of the USB device 10 is controlled according to an instruction from the main CPU 30 without fixing the time (standard value) defined in the USB standard for controlling the USB device. The time related to control is to be changed.

3.3.1 Operation at Initial Time First, the operation of the ATA-USB bridge controller 70 at the initial time (power-on, reset, etc.) will be described.

FIG. 20 is a flowchart showing the operation of the ATA-USB bridge controller 70 at the initial time.
First, the main task block of the ATA-USB bridge controller 70 calls the GPI circuit driver block (step S101).

  The GPI circuit driver block detects signals input to the GPI terminals 171 and 172, and returns a value based on the detected signals to the main task block as a return value (step S111). For example, in FIG. 14, since the GPI circuit 170 includes two GPI terminals 171 and 172, it is possible to accept a 2-bit input from the outside. In FIG. 14, since the H level is input to the GPI terminal 171 and the L level is input to the GPI terminal 172, the GPI circuit driver may be “0b10” (or “0b01”). Return the bit return value to the main task block.

  Next, the main task block calls the API block with the return value from the GPI circuit driver block as an argument (step S102).

  The API block calls the time change function in the USB host stack block using the argument from the main task block as an argument (step S121).

  The time change function of the USB host stack block selects one parameter table corresponding to the argument from the API block among the plurality of parameter tables stored in the ROM 153 (step S131). At this time, the time change function of the USB host stack block transfers the selected parameter table from the ROM 153 to the RAM 152, and refers to the parameter table transferred to the RAM 152 when the USB device 10 is connected (described later). And may be used.

3.3.2 Operation when USB Host and USB Device are Connected The operation of the ATA-USB bridge controller 70 when the USB device 10 is connected is the operation of the USB host controller 40 described above (see FIG. 11 and FIG. 11). This is the same as the flowchart shown in FIG.

3.3.3 Operation when resuming USB device The operation of the ATA-USB bridge controller 70 when resuming the suspended USB device 10 is the same as the operation of the USB host controller 40 described above (the flowchart of FIG. 13). See).

  As described above, according to the present embodiment, the USB device is controlled according to a signal input from the outside without being fixed to the time (standard value) defined in the USB standard for controlling the USB device. The time for 10 controls can be changed. As a result, it is possible to prevent the ATA-USB bridge controller 70 from recognizing the USB device 10 normally or from malfunctioning. In addition, even if the USB device 10 does not have a resume function and is a USB device device that can be said to be in violation of the standard, it is possible to prevent the ATA-USB host controller 70 and / or the USB device 10 from freezing. Become.

In the present embodiment, the main CPU 60 uses the device side I / O to specify information (may be a name indicating time (T _ATTDB , T _DRST, etc.)) and / or a time value for specifying the time to be changed. It may be set in the register 162 (task register) of F160, and the ATA-USB bridge controller 70 may change the time related to the control of the USB device 10 using the time value set in the register 162 (task register). .

  In the first embodiment described above, the USB host controller 70 includes the GPI circuit 170, and the processing unit 120 of the USB controller 70 is connected to the USB device based on a signal input from the outside to the GPI circuit 170. You may make it change the time regarding 10 control.

  Although the present embodiment has been described in detail as described above, it will be easily understood by those skilled in the art that many modifications can be made without departing from the novel matters and effects of the present invention. Accordingly, all such modifications are intended to be included in the scope of the present invention. For example, in the specification or drawings, terms (controller, main CPU, ATA device side I / F, USB I / F, etc.) described at least once together with different terms having a broader meaning or the same meaning may be used anywhere in the specification or drawings. Can also be replaced by the different terms. Further, the configuration and operation of the controller and the electronic device are not limited to those described in this embodiment, and various modifications can be made. For example, the ATA bus may be a serial ATA or CE-ATA bus.

FIG. 6 is a waveform diagram of USB when a USB host and a USB device are connected. FIG. 6 is a waveform diagram of USB when a USB host and a USB device are connected. USB standard values and measured values of commercially available USB devices. 1 is a configuration example of a USB controller and an electronic device according to a first embodiment. Explanatory drawing of the functional block of a process part. 6A to 6D are explanatory diagrams of USB data transfer. 7A and 7B are explanatory diagrams of bulk-only transport. 2 shows a configuration example of a USB I / F. The flowchart of 1st Embodiment. Explanatory drawing of the example of a setting of the time value regarding control of a USB device. The flowchart of 1st Embodiment. The flowchart of 1st Embodiment. The flowchart of 1st Embodiment. 6 is a configuration example of a USB controller and an electronic device according to a second embodiment. Explanatory drawing of the functional block of a process part. 6 is a configuration example of an ATA device-side I / F. Explanatory drawing of the task register of ATA. FIGS. 18A and 18B show signal waveform examples of ATA PIO transfer. 19A and 19B are signal waveform examples of ATA DMA transfer. The flowchart of 2nd Embodiment.

Explanation of symbols

ATABUS1 ATA bus,
10 USB device, 20, 50 Electronic device, 30, 60 Main CPU,
40 USB host controller, 62 ATA host side I / F,
70 ATA-USB bridge controller, 80 USB I / F,
100 transfer controller, 102 data buffer, 120, 150 processing unit,
121, 151 CPU, 122, 152 RAM, 123, 153 ROM,
130 registers, 140 DMA processor, 160 ATA device side I / F,
162 ATA task register, 170 GPI circuit, 171, 172 GPI terminal

Claims (11)

A method executed by a controller for communicating with a USB device via a USB (Universal Serial Bus) to control the USB device,
Information input for determining at least one time relating to the control of the USB device is received from the outside, the at least one time is determined based on the information, and the USB at a timing according to the determined at least one time A USB device control method for controlling the USB device by outputting a signal or data to the USB device. A controller for communicating with a USB device via a USB (Universal Serial Bus),
An information input unit capable of inputting information for determining at least one time relating to control of the USB device from the outside of the controller;
A processing unit that determines the at least one time based on the information input to the information input unit;
A USB interface unit connected to the USB device via USB and outputting a signal or data to the USB at a timing according to the at least one time determined by the processing unit;
Including the controller. In claim 2,
The processing unit is
A controller including a CPU core that executes a driver program for controlling the USB interface unit, wherein the CPU core executes a program that determines the at least one time based on the information input to the information input unit. In claim 2 or 3,
The information input unit is
A register for externally writing information relating to setting and / or control of the controller;
At least one data for determining the at least one time is externally written to the register;
The processing unit is
A controller that determines the at least one time based on the at least one data written to the register. In claim 4,
At least one value representing the at least one time is written to the register;
The processing unit is
A controller that determines the time represented by the at least one value as the at least one time. In claim 4,
A storage unit that stores a plurality of tables each including at least one value representing the at least one time;
Data specifying any of the plurality of tables is written to the register,
The processing unit is
A controller that determines, as the at least one time, a time represented by the at least one value included in a table specified by the data of the plurality of tables. In claim 2 or 3,
The information input unit is
A signal input circuit capable of inputting at least one signal for determining the at least one time from the outside;
The processing unit is
A controller that determines the at least one time based on the at least one signal input to the signal input circuit. In claim 7,
A storage unit for storing a plurality of tables each including at least one value representing the at least one time;
The at least one signal specifying any of the plurality of tables is input to the signal input circuit;
The processing unit is
A controller for determining, as the at least one time, a time represented by the at least one value included in a table specified by the at least one signal of the plurality of tables; In any of claims 2 to 8,
The controller, wherein the at least one time includes a time related to control for initializing the USB device and / or a time related to control for resuming the USB device. In any one of Claims 2 thru | or 9.
The at least one time is a time for outputting a steady signal, a periodic signal or data to the USB and / or a time for continuing the output, or outputting a certain signal or data to the USB and then transferring the next signal or data to the USB. A controller that includes the time to output. A controller according to any one of claims 1 to 10;
A host CPU connected to the controller via a bus;
An electronic device comprising:

Images