USB OHCI specification.

[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?

[BenLunt]

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

[mindentropy]

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

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?

[BenLunt]

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.

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.

[mindentropy]

Sorry I was not clear in my last post.

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.

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 3522 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?

[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

[BenLunt]

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

[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						

[BenLunt]

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.

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

[mindentropy]

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?

[BenLunt]

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.