1. Overview OTG devices use the ID pin in the plug to differentiate A/b device,id ground is known as A-device, the USB host,a-device at the time of the connection always provides power to the bus, the ID floating is called the B-device, the connection time of the USB Devices, the device's USB HOST/USB device role can be switched via HNP.
The OTG device cannot cross the USB hub when connected and loses the HNP function if it crosses the USB hub.
Here to note that A-device/b-device and USB host/device is not the same thing without a bound relationship a-device must be host,a-device only when the Host can be connected through the HNP switch, Switch over A-device becomes USB device but still provides power to the bus.
2. Device Type embedded Host: Provides standard a socket, normal USB Host with TPL (list of supported devices)
OTG Device: Use a micro AB socket to switch host/device at run time.
Peripheral only B-device: can only be used as peripheral b-device (divided into plug-in and plug-in cable separation).
Note: OTG device will open Vbus when the plug is plugged in, turn off Vbus if no device is connected, and turn on ADP detection, while embedded host will not turn vbus off again.
3. Protocol SRP (Session Request Protocol):
B-device use. With a pulse on the data line, request A-device to open Vbus and start a session. The session is opened from Vbus to closed for some time. Support: A-device allows the srp,b-device to be responded to (including B-device only as peripherals), allowing the SRP to be initiated. A b-device that supports HNP should be able to initiate the SRP. When a plug is plugged in, the host that closes Vbus must support a response Srp,vbus always open the host without responding to the SRP.
ADP (Attach Detection Protocol):
Provides the device to detect if there is a peer-to-peer device plugged in. Support: Any OTG device, Embedded Host, b-device that supports SRP Probing,b-device and b-device that can only be used as peripherals must also support ADP senseing if they support ADP probing.
HNP (Host negotiation Protocol):
The OTG device switches the Host/device role through HNP. The current USB host uses the HNP Polling (similar to Polling Hub) to query the host request flag in the data returned by the poll GetStatus () command to see if the demand for the peer device changes to a host,polling interval of 1-2 seconds. When the current USB host decides to allow the B-device to change to host after the Setfeature () opens the b_hnp_enable, the host returns to A-device hand after the session ends.
4. Device Framework OTG descriptor when device enumeration, A-device requests the OTG descriptor through Getdeor to the B device. The OTG descriptor should also be returned as part of GetConfiguration (). Where the bmattributes indicates whether B-device supports ADP/HNP/SRP
Standard device features, set by Setfeature (). B_hnp_enable
Set this attribute to show that B-device is allowed to hnp,a the device must suspend the bus within T (HOST_REQ_SUSP) time. A_hnp_support
Earlier versions of OTG compatibility feature, set this feature to indicate the B-device-to-end a-device support HNP. A-device should set this attribute to B-device if A-device supports HNP. A_alt_hnp_support
Abandoned
GetStatus ()
The data section, OTG status, is the lowest bit of host Request flag, indicating that the current USB device role is expected to become the USB host role.
5. General connection process (Host, Device) OTG device/embedded Host detected a plug insertion with b-device (with a plug type) host side only as peripheral, stop ADP, open Vbus, Because the B-device a Plug and the device as a whole, at this time B-device must be connected with a plug, host detects the peripheral connection, start enumeration.
The OTG device/embedded host detects a plug insertion, stops ADP, turns on Vbus if the B-device is connected to the B-device (a plug for cable connection) only as a peripheral, and the entire connection process is the same as if the cable is plugged in , because the b-device may not have plugged in at this point, the device connection times out, Vbus is turned off again, waits for the next ADP change (the cable connection is complete), opens the Vbus again, and starts the normal bus enumeration.
OTG Device and OTG Devicehost end detect plug insertion, then turn on Vbus, if no peripheral detected, turn off Vbus, turn on ADP probing,device to detect Plug insertion, open SRP, if cable is not plugged in, SRP timeout, The device end begins the ADP probing, when the cable is connected, the device side detects an ADP change, sends the SRP request host Open Vbus,host responds to the SRP and opens the Vbus to complete the equipment connection.
6. OTG device (Host/device) with normal USB HOST/DEVICEOTG device (device) plugged into a normal USB host:spec indicates that OTG Device satisfies all USB peripheral conditions and the appliance principle is not identified. Normal USB device plugged into OTG device (HOST): OTG compatible, but the appliance principle is not identified, the opening of Vbus, and the processing of ADP and SRP are questionable. In usb.org, someone asked this question, the reply is only said to be recognized and compatible, but the implementation of the principle and monitoring details are unknown. Original Sticker Address: HTTPS://WWW.USB.ORG/PHPBB/VIEWTOPIC.PHP?T=14450&HIGHLIGHT=OTG
Some of the latest thoughts and speculations:
1.ADP is the key to OTG device as host, which can both turn off Vbus and monitor normal USB devices.
2.OTG device as host if ADP is not supported, but the SRP is supported, Vbus should always be turned on (or by inserting interrupts?). Roothub Polling), if you want to turn off Vbus only the OTG device that will initiate the SRP, the normal USB device, and the OTG device that does not support SRP, In the case where host has no ADP, the device cannot be detected (except for insert interrupts) in the case of Vbus shutdown and the Vbus is opened through the SRP.
Note: OTG device tries to open Vbus as host when plugged in a plug, and if the insertion device cable is connected when the a plug is plugged in, the normal enumeration occurs at this time of insertion. If the plug-in device cable is not connected when the a plug is plugged in, OTG device as host does not support ADP, but the SRP is supported, then the insertion device can initiate the SRP open Vbus after the cable is plugged in, if the plug-in device does not support SRP. The device is not working properly?
3.OTG device detects the plug when the plug is plugged in before monitoring the bus activity and device connection (normal USB does not detect the plug, because it does not care, OTG's ID PIN will interrupt the controller), which determines the OTG device role and waits for the device to connect via ADP. Then open Vbus for bus activity.
About SRP and ADP as a b-device or an ordinary USB Device, how to open Vbus for bus enumeration is their ultimate goal. The SRP is one of the means for B-device to request A-device to open a device, while ADP, for the purpose of detecting the insertion device, but some EH/OTG device will not wait for the SRP to arrive (or not support SRP) after ADP detects the condition, and open Vbus, If there is no device connection, then turn off Vbus and open ADP continue detection (OTG Device eh not), and even after the detection of a plug directly open Vbus (ADP came out late, many early OTG controller, there is no ADP and HNP polling words, It is estimated that there is no such thing in spec at that time. This makes the SRP somewhat redundant, but we should still be issuing the SRP before starting the bus operation as a b-device. Ensure that ADP is not supported for SRP only and does not open when plugged in Vbus only the controller that is opened Vbus by the SRP, the device can also be enumerated normally.
Mentor Graphics USB OTG Controller IP Core Debug notes
MUSBHDRC and MUSBMHDRC are mentor Graphics's compatible, OTG-enabled IP cores that are widely used in TI Adi's multimedia processors. The difference between the two IPs is that the MUSBMHDRC has a multipoint function and can be connected to the hub. The following is my FPGA debugging encountered problems and solutions, welcome to exchange shooting bricks.
MUSBHDRC RTL V1.8 version Bug and resolution 1. The interrupt does not PENDINGMUSBHDRC the interrupt bit when the EP interrupt is turned off, so that when the interrupt is switched on again, the interrupt is not pending, causing the interruption to be lost directly. And mentor's practice is also quite contempt, unexpectedly just in the datasheet in the original version of the datasheet in the interruption will pending the words quietly removed. Workaround: Only at the SOC level, the DaVinci Solution shadow the relevant registers, not allowing the associated interrupt registers in the original MUSBHDRC to be used instead of the relevant registers provided by the Soc.
The DMA mode of the 2.DMA BUGMUSB series is divided into 3 types. DMA mode 0,DMA Mode 1 REQ mode 0, DMA Mode 1 REQ mode 1. Where DMA Mode 1 REQ Mode 1 does not work properly on MUSBHDRC, once the FIFO has packet, and < MAXP will not be interrupted. DMA Mode 1 REQ mode 0 hangs the bus when a continuous DMA request is initiated, causing the system to lock up, and because DMA Mode 1 REQ mode 0 must know the limit of the total amount of data that cannot be used in many of the USB upper-level protocols. DMA mode 0 is inefficient in device mode and is not considered. Workaround: Only at the SOC level, you can see that both DaVinci and TUSB do not use the MUSBHDRC DMA controller, which is a DMA controller on the SOC to implement the relevant DMA operation.
MUSBMHDRC basically solves the related bug in MUSBHDRC and adds multipoint functionality. Unfortunately there is no endpoint reuse and scheduling related code in the Linux driver, so it is still not possible to support too many USB devices.
About ID pin interrupts the MUSB series does not provide an interrupt for the ID pin, and the A/b device logic we see from the controller is quite strange. In the A-device state, write devctl.session PHY pulls up Vbus,devctl.b-device and devctl. VBUS session is valid, that is, we must start the session software to know whether it is the current a-device or B-device, which is in the OTG state machine A- When device advances to the B-device state, there is a big problem: there will be a lot of state changes that are not present in the driver's side. In the OTG device-> Host when the plug changed and the software did not know, no one to drive VBUS, direct lead to the squib (a friend said I did not, but sometimes easy to use sometimes do not use, the reason behind the unveiling). While host-> device, when the host equipment is unplugged in the A_wait_bcon state, the B-device plug when the state machine has not been a_wait_bcon-> a_wait_vbus_fall-> a_idle- >b_idle change, directly lead to the state machine state change abnormal in the driver, and DaVinci took the timer to write the session method to workaround, but not the root of the problem, and we can not always through the session to detect, The most fundamental solution is to test the plug with an ID pin interrupt, while advancing the state machine.
Weird session request interrupt in datasheet, this is a only in the host mode of the interrupt, but in actual use, the interruption is very strange, b-device state sometimes in the insertion of B plug every 3-5 seconds, and sometimes do not come, Sometimes it comes back when it's not plugged in, it's erratic. While the driver received a session request interrupt immediately driver VBUS, which explains the previous device->host sometimes useful and sometimes invalid reasons. Resolution: Go through the normal ID pin detection to turn off this interrupt and immediately open session-drive VBUS when a plug insertion is detected, so you don't have to worry about the SRP of the other device.
Note about device mode setaddress follow the process in datasheet when you receive the setup package, you can set FADDR to change the current address, then clear the Rxpktrdy and place dataend reply 0 packets, And the controller enters the status Stage of the control transmission, completing a subsequent mc_int interrupt. In fact, if this operation causes the MUSB controller to lose its response, the Controller will see no reply in the token in the next get Deor setup transaction, or after replying to some nak, Loss of response.
The correct way to do this is: After receiving setaddress, do not immediately set up faddr, in the status stage after the end of the interruption in the setup package to set the address.
About DMA Mode 1 REQ mode 1Device Mode DMA Mode 1 REQ Mode 1 is the best way to compatibility and efficiency. However, only DMA mode 0 can be used in host mode. In the final analysis, the end condition of the DMA Mode 1 REQ Mode 1 < MAXP If the host turns on two in Transaction, each in Transaction size is a multiple of MAXP, it is not possible to differentiate two packets when the DMA is stopped, the previous in Transaction because the condition of the DMA Mode 1 REQ Mode 1 is satisfied at the end, the DMA controller directly causes the next in Transaction package to have received fifo/urb if all in Transaction If all can be MAXP divisible, the beginning of the URB will not become a group of paste.
Solution: Controller design problem is not fixed, using DMA MODE 0.
About drivers in Linux. The drive is located under Drivers/usb/musb. There is no endpoint reuse and dispatch part in the code, so the multipoint function is greatly limited. Interrupt and Isochronous modes of transmission appear to be problematic and have not yet been studied.
About the defects of vbus_error. When some devices that need a large amount of power are plugged in, Musb Vbus pull up when writing devctl.session, and Vbus_error interrupts are generated, and then the embarrassing problem occurs, and the controller actually cuts to B-device state, You can never pull up vbus by writing a session. Recovery method has not been found. Reprinted from: http://blog.21ic.com/user1/1113/archives/2010/67075.html
USB OTG Introduction (reprint)
