Page 5 of 5
Re: USB OHCI specification.
Posted: Sat May 06, 2017 8:08 am
by mindentropy
I get some strange results now consistently now when before it was intermittent.
My port status is as follows:
Code: Select all
Port status :
Port1: 0x00000303
Port2: 0x00010101
Strange this is that I do not have any thing connected on Port2 but still the CSC bit is set. It was happening inconsistently before. It tested it on two boards and the results are the same. It also happens after I reset my OHCI controller.
Should I reset my ports before I reset my OHCI controller should it be the reverse?
Re: USB OHCI specification.
Posted: Sat May 06, 2017 8:17 am
by BenLunt
mindentropy wrote:I get some strange results now consistently now when before it was intermittent.
My port status is as follows:
Code: Select all
Port status :
Port1: 0x00000303
Port2: 0x00010101
Strange this is that I do not have any thing connected on Port2 but still the CSC bit is set. It was happening inconsistently before. It tested it on two boards and the results are the same. It also happens after I reset my OHCI controller.
Should I reset my ports before I reset my OHCI controller should it be the reverse?
This happens before you reset the controller, correct?
Your driver should not do anything when the CSC bit becomes set until after you reset the controller, then reset the port.
Once you have done this, if the CSC bit becomes set and there was no physical change in the port status, you may have a hardware or OHCI firmware problem.
Just my guess.
Ben
Re: USB OHCI specification.
Posted: Sat May 06, 2017 10:16 am
by mindentropy
BenLunt wrote:
This happens before you reset the controller, correct?
Ben
It happens after I reset the controller but before I reset the port.
Before I reset my port or the controller my port status is as follows:
Code: Select all
Port status :
Port1: 0x00000100
Port2: 0x00000100
BenLunt wrote:
Your driver should not do anything when the CSC bit becomes set until after you reset the controller, then reset the port.
Once you have done this, if the CSC bit becomes set and there was no physical change in the port status, you may have a hardware or OHCI firmware problem.
After the CSC bit is set after resetting the controller I reset my USB ports etc. I tried another thing. The Host controller controls 2 ports. I also have a USB device controller on the SoC which is connected to a USB Type B connector. I connect the cable to the connector and then I see the Port2 CSC status change to 0. Is the Host controller and the device controller related?
Re: USB OHCI specification.
Posted: Sat May 06, 2017 4:38 pm
by BenLunt
mindentropy wrote:BenLunt wrote:
This happens before you reset the controller, correct?
Ben
It happens after I reset the controller but before I reset the port.
Before I reset my port or the controller my port status is as follows:
Code: Select all
Port status :
Port1: 0x00000100
Port2: 0x00000100
You should not care or worry about the CSC bit until after you have reset the controller and reset the port.
mindentropy wrote:
After the CSC bit is set after resetting the controller I reset my USB ports etc. I tried another thing. The Host controller controls 2 ports. I also have a USB device controller on the SoC which is connected to a USB Type B connector. I connect the cable to the connector and then I see the Port2 CSC status change to 0. Is the Host controller and the device controller related?
You have lost me here. Do you have a cable that includes a device within the cable? These are known to happen, but not on the OHCI. Just Type C cables.
Re: USB OHCI specification.
Posted: Sat May 06, 2017 10:47 pm
by mindentropy
Sorry I was not clear in my last post.
BenLunt wrote:
You should not care or worry about the CSC bit until after you have reset the controller and reset the port.
Yes and the CSC is set for both the ports after I reset the controller and the port. It should be disabled for Port2.
BenLunt wrote:
You have lost me here. Do you have a cable that includes a device within the cable? These are known to happen, but not on the OHCI. Just Type C cables.
This is how the connection looks from my SoC:
- usb_from_soc
- from_soc.png (10.61 KiB) Viewed 3519 times
This how the connections terminate to the USB connectors:
- to_connectors
I realized that if I connect a cable to the USB Port B to my computer the CSC bit gets disabled in Port2. This gave me a clue that I should disable the USB Port B. The way I fixed it is since the USB_EN is connected to a GPIO I set it to output and set the output to 0. This fixed the CSC issue and now I see the CSC bit disabled for Port2. Is this enough?
Re: USB OHCI specification.
Posted: Mon May 08, 2017 12:27 pm
by mindentropy
Ben,
Today seems to be a good day for USB development. I think I got the GET_DESCRIPTOR request working. If possible could you please verify if my ED's and TD's are correct?
ED and TD log:
Code: Select all
ED:
Endpt ctrl: 0x00082000
TailP: 0x00000000
HeadP: 0x30007B10
NextED: 0x00000000
TD0:
TD addr:0x30007B10
TDCTRL : 0xE2E00000 (DP_SETUP)
CBP : 0x300078FC
NXT_TD : 0x30007B20
buffer_end: 0x30007903
CBP Buffer dump: 0x80 0x06 0x00 0x01 0x00 0x00 0x08 0x00
TD1:
TD addr:0x30007B20
TDCTRL : 0xE3100000 (DP_IN)
CBP : 0x30007904
NXT_TD : 0x30007B30
buffer_end: 0x3000790B
CBP Buffer dump: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
TD2:
TD addr:0x30007B30
TDCTRL : 0xE3080000 (DP_OUT)
CBP : 0x00000000
NXT_TD : 0x00000000
buffer_end: 0x00000000
Final data buffer (8 bytes): 0x12 0x01 0x10 0x01 0x00 0x00 0x00 0x08 <--- I think I got my Maximum packet size
Re: USB OHCI specification.
Posted: Tue May 09, 2017 9:11 am
by BenLunt
mindentropy wrote:Ben,
Today seems to be a good day for USB development. I think I got the GET_DESCRIPTOR request working. If possible could you please verify if my ED's and TD's are correct?
ED and TD log:
I am glad that you have some good advancement in your work. It is always a good feeling to accomplish something when you have been working on it for so long.
Without tearing down each TD (sorry, don't have the time right now), I don't see anything standing out at me.
Good job with the work. Hope it continues to go well,
Ben
Re: USB OHCI specification.
Posted: Sun May 14, 2017 12:14 pm
by mindentropy
Ben,
If the Maximum Packet Size equals 8 then should I have multiple TD's having 8 byte buffers to read the complete GetDescriptor data?
Also I managed to get hold of an oscilloscope to decode the USB packets and dump. I have attached the spreadsheet. In the spreadsheet there is are IN and NAK. Is this because the USB function is not ready with the data and hence is responding with the NAK for at least 3 times?
Code: Select all
Time Serial Bus PID Addr Endp Data Fr CRC Errors
550.4ns Serial1 SETUP 0 0 2
26.71us Serial1 DATA0 80 06 00 01 00 00 08 00 94EB
95.37us Serial1 ACK
120.7us Serial1 IN 0 0 2
146.6us Serial1 NAK
168.5us Serial1 IN 0 0 2
194.4us Serial1 NAK
216.4us Serial1 IN 0 0 2
242.1us Serial1 NAK
263.5us Serial1 IN 0 0 2
289.3us Serial1 DATA1 12 01 10 01 00 00 00 08 7711
361.0us Serial1 ACK
385.3us Serial1 OUT 0 0 2
411.5us Serial1 DATA1
437.4us Serial1 ACK
Re: USB OHCI specification.
Posted: Mon May 15, 2017 9:49 am
by BenLunt
mindentropy wrote:Ben,
If the Maximum Packet Size equals 8 then should I have multiple TD's having 8 byte buffers to read the complete GetDescriptor data?
Yep.
mindentropy wrote:
Also I managed to get hold of an oscilloscope to decode the USB packets and dump. I have attached the spreadsheet. In the spreadsheet there is are IN and NAK. Is this because the USB function is not ready with the data and hence is responding with the NAK for at least 3 times?
Without looking at exactly what you have, I would guess so. However, it looks like you are receiving, or at least the device is sending back the Device Descriptor packet.
For what it is worth, and for others that may be interested, I have a Beagle Protocol Analyzer from
Total Phase that works really well. The GUI they include with it captures and displays all data as well as accurately detecting the type of device attached and catering the output accordingly. The captures can also be saved for later analysis. Well worth the purchase if you plan on doing any real USB analysis.
Ben
Re: USB OHCI specification.
Posted: Tue Sep 05, 2017 5:12 am
by mindentropy
BenLunt wrote:SpyderTL wrote:BenLunt wrote:You send the Set Address TD, wait for the response, then send the Status TD.
Can you elaborate a bit, for clarity?
What "response" are you waiting for? Do you mean just wait for the TD ConditionCode to be something other than 0x0e (pending)?
And what "Status TD" are you sending? Do you mean send a GET_STATUS message, and read the result? Is this strictly necessary?
Thanks.
A device can stall after the start of a setup packet. The only way to clear the stall is to start a new setup packet.
If you send a setup packet, the first TD is a SETUP TD. This is when the device may stall. If your ED contains a list of TD's, two in this case, and the second TD is the Status TD, you haven't cleared a stall and the Status TD won't ever get processed. Your code could be waiting for the Status TD to complete for a long time.
Therefore, send the first TD, the SETUP TD. If and when it comes back successful, then send the Status TD. If it comes back stalled. You need to clear the stall by sending another Setup TD.
The reason for the Status TD is to indicate to the device that you have successfully sent/received a transfer. If you instantly send the Status TD before waiting for the device to process the request, it defeats the purpose of the Status TD.
However, please note that if you have a Status TD right after a Setup TD in the same ED, the device won't process the Status TD until after it has processed the Setup TD. But if the device stalls, it will never get to the Status TD.
Therefore, send the Request TD, wait for a good transfer, then send the Status TD.
I gave an example to the OP of this thread of an ED with two TD's, assuming it would not stall. To create a good USB driver, you should not do this, but send a Setup TD, wait for the response, then send the Status TD, using two separate ED's, or the same ED, twice.
Does this help?
Ben
Ben,
In my case when I do a Control Read I should be sending the SETUP TD's together with the DATA TD's and then check for the error and then send the STATUS TD's right?
Re: USB OHCI specification.
Posted: Tue Sep 05, 2017 7:21 am
by BenLunt
mindentropy wrote:Ben,
In my case when I do a Control Read I should be sending the SETUP TD's together with the DATA TD's and then check for the error and then send the STATUS TD's right?
Correct. Build a transaction that has the SETUP TD and enough DATA TDs to receive the requested data and then watch for the interrupt or poll the TDs for completion or error. Once you receive a completion, if successful, send the STATUS TD. If non-successful, depending on the error and type of transaction, you may need a clear stall, reset, or other transaction.