OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 11:27 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
 Post subject: Re: USB OHCI specification.
PostPosted: Sat May 06, 2017 8:08 am 
Offline
Member
Member

Joined: Thu Jan 13, 2011 3:33 pm
Posts: 42
I get some strange results now consistently now when before it was intermittent.

My port status is as follows:

Code:
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?


Top
 Profile  
 
 Post subject: Re: USB OHCI specification.
PostPosted: Sat May 06, 2017 8:17 am 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
mindentropy wrote:
I get some strange results now consistently now when before it was intermittent.

My port status is as follows:

Code:
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


Top
 Profile  
 
 Post subject: Re: USB OHCI specification.
PostPosted: Sat May 06, 2017 10:16 am 
Offline
Member
Member

Joined: Thu Jan 13, 2011 3:33 pm
Posts: 42
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:
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?


Top
 Profile  
 
 Post subject: Re: USB OHCI specification.
PostPosted: Sat May 06, 2017 4:38 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
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:
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.


Top
 Profile  
 
 Post subject: Re: USB OHCI specification.
PostPosted: Sat May 06, 2017 10:47 pm 
Offline
Member
Member

Joined: Thu Jan 13, 2011 3:33 pm
Posts: 42
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:
Attachment:
File comment: usb_from_soc
from_soc.png
from_soc.png [ 10.61 KiB | Viewed 2695 times ]


This how the connections terminate to the USB connectors:
Attachment:
File comment: to_connectors
to_connectors.png
to_connectors.png [ 71.46 KiB | Viewed 2695 times ]


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?


Top
 Profile  
 
 Post subject: Re: USB OHCI specification.
PostPosted: Mon May 08, 2017 12:27 pm 
Offline
Member
Member

Joined: Thu Jan 13, 2011 3:33 pm
Posts: 42
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:
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


Top
 Profile  
 
 Post subject: Re: USB OHCI specification.
PostPosted: Tue May 09, 2017 9:11 am 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
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


Top
 Profile  
 
 Post subject: Re: USB OHCI specification.
PostPosted: Sun May 14, 2017 12:14 pm 
Offline
Member
Member

Joined: Thu Jan 13, 2011 3:33 pm
Posts: 42
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:
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                  



Top
 Profile  
 
 Post subject: Re: USB OHCI specification.
PostPosted: Mon May 15, 2017 9:49 am 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
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


Top
 Profile  
 
 Post subject: Re: USB OHCI specification.
PostPosted: Tue Sep 05, 2017 5:12 am 
Offline
Member
Member

Joined: Thu Jan 13, 2011 3:33 pm
Posts: 42
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?


Top
 Profile  
 
 Post subject: Re: USB OHCI specification.
PostPosted: Tue Sep 05, 2017 7:21 am 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 74 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group