USB OTG Learning

1. Overview
The OTG device uses the ID pin in the plug to differentiate A/b device,ID GroundKnown as A-device, for connection time.USB Host, A-device always provides power to the bus,ID DanglingKnown as B-device, for connection time.USB Device, the device's USB HOST/USB device role can be switched via HNP.OTG device cannot cross USB hub when connected, loses HNP function if spanning USB hub。
It's important to noteA-device/b-device and USB host/device are not the same thing, there is no bound relationship。 A-device must be host,a-device only when the host is connected, you can switch through HNP,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. Agreement
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
At 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 with B-device only as peripheral (with a plug-in type)
Host side detected a plug insertion, stop ADP, open Vbus, because B-device a Plug and device as a whole, at this time B-device must be connected with a plug, host detects the peripheral connection, start enumeration.

OTG device/embedded Host with B-device only as peripheral (a plug for cable connection)
The host segment detects a plug insertion, stops ADP, opens the Vbus, and if the B-device is connected in a plug-in then the entire connection process is the same as above, because at this point the b-device may not have plugged in, the device connection times out, the Vbus is closed again, Wait for the next ADP change (the cable connection is complete), open Vbus again, and start the normal bus enumeration.

OTG device and OTG device
The host side detects plug insertion, then turns on Vbus, if no peripheral detects, turns off Vbus, turns on ADP Probing,device detects plug insertion, opens SRP, if cable is not plugged, SRP expires, device end begins ADP Probing, when the cable connection is complete, 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 device connection.

6. OTG Device (Host/device) and normal USB Host/device
OTG device (device) inserted into the 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
Bugs and Solutions
1. Interrupts will not pending
MUSBHDRC does not reset the interrupt bit when the EP interrupt is turned off, so when the interrupt is switched on again, the interrupt is lost because there is no pending. 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.
Solve:
Can only be resolved 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.

Bug in 2.DMA section
The DMA mode of the MUSB 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.
Solve:
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
It basically solves the related bug in MUSBHDRC and adds the multipoint function. 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 interrupted.
In datasheet, this is a only in the host mode of interruption, but in actual use, this interruption is very strange, b-device state sometimes in the insertion of B plug every 3-5 seconds to come, sometimes do not come, and sometimes do not plug in the back, erratic. While the driver received a session request interrupt immediately driver VBUS, which explains the previous device->host sometimes useful and sometimes invalid reasons.
Solve:
Walk the regular ID pin detection to turn off this interrupt, immediately open session-drive VBUS when a plug insertion is detected, so you don't have to care about the SRP of the other device.

Attention to setaddress under Device mode
According to the process in datasheet, you can set FADDR to change the current address when you receive the setup package, then clear Rxpktrdy and reset Dataend reply to 0 packets, and enable controller to enter the status Stage of the control transmission. Complete later a 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 1
Device 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.

USB OTG Learning