Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

USB Mass Storage Class

Status
Not open for further replies.
tkbits said:
Are you using the correct PID?


I hope so.
After receiving a setup packet, the first packet I transmit is always DATA1,
then I toggle it every next ransmitting packet after I receive an ACK to complete the desciptor and so on.
Is that right?
 

It will work correctly. The SET_CONFIGURATION command is a send-from-host command, but no data packet is sent. So it does the turnaround and asks (sends IN) for the status packet, which must be DATA1 of zero length.

Are you using a USB 2 port? If so, try and get an older computer that has only USB 1.

My recollection is that slow responding devices can cause the status packet to be requested several times on USB 2 ports. The host may give up after three or four tries. My hazy memory thinks the host gave up even when the requests were properly NAK'ed. You would need to tap into the USB bus and directly monitor the USB traffic to determine if this is happening or not. Or add more debugging code in the device SW.
 

tkbits said:
It will work correctly. The SET_CONFIGURATION command is a send-from-host command, but no data packet is sent. .

The data packet is the request itself 8 bytes isn't it? What do you mean no data packet?


tkbits said:
So it does the turnaround and asks (sends IN) for the status packet, which must be DATA1 of zero length.

I am doing that.

tkbits said:
Are you using a USB 2 port? If so, try and get an older computer that has only USB 1.

I am using the 1.1 version, as my USBN9603 supports only 1.0, 1.1


tkbits said:
My recollection is that slow responding devices can cause the status packet to be requested several times on USB 2 ports. The host may give up after three or four tries. My hazy memory thinks the host gave up even when the requests were properly NAK'ed. You would need to tap into the USB bus and directly monitor the USB traffic to determine if this is happening or not. Or add more debugging code in the device SW.

Does it influence on the speed?
 

alexz said:
tkbits said:
Are you using a USB 2 port? If so, try and get an older computer that has only USB 1.

I am using the 1.1 version, as my USBN9603 supports only 1.0, 1.1
Are you talking about your device? I am asking about the PC you're plugged into. Is the PC port you're using, USB 2 capable?

You're correct, the SETUP packet is a data packet. I don't usually think of it as a data packet, as it's not part of the "data stage". See Chapter 8, section on Control Transfers.
 

tkbits said:
alexz said:
tkbits said:
Are you using a USB 2 port? If so, try and get an older computer that has only USB 1.

I am using the 1.1 version, as my USBN9603 supports only 1.0, 1.1
Are you talking about your device? I am asking about the PC you're plugged into. Is the PC port you're using, USB 2 capable?

I am not sure, but it is a quite new PC, so I guess it should be, shouldn't it?

tkbits said:
[
You're correct, the SETUP packet is a data packet. I don't usually think of it as a data packet, as it's not part of the "data stage". See Chapter 8, section on Control Transfers.

Yeah, I mean not a zero length packet
 

alexz said:
tkbits said:
You would need to tap into the USB bus and directly monitor the USB traffic to determine if this is happening or not. Or add more debugging code in the device SW.

Does it influence on the speed?
Adding code? Yes, that will slow down your device.

If possible, you may want to see if you're getting an IN token before sending the SET_CONFIGURATION status (zero length) packet. The SIE will send data immediately in response to an IN token. So the best possible scenario is that you create a zero length packet before the first IN token arrives.

For a stab-in-the-dark approach, you may want to speed up your response to SET_CONFIGURATION. Measure the time from when you get a SETUP packet, not from the time you determine it's a SET_CONFIGURATION command.
 

tkbits said:
alexz said:
tkbits said:
You would need to tap into the USB bus and directly monitor the USB traffic to determine if this is happening or not. Or add more debugging code in the device SW.

Does it influence on the speed?
Adding code? Yes, that will slow down your device.

If possible, you may want to see if you're getting an IN token before sending the SET_CONFIGURATION status (zero length) packet. The SIE will send data immediately in response to an IN token. So the best possible scenario is that you create a zero length packet before the first IN token arrives.

For a stab-in-the-dark approach, you may want to speed up your response to SET_CONFIGURATION. Measure the time from when you get a SETUP packet, not from the time you determine it's a SET_CONFIGURATION command.


But I will have to determine it before sending the zero len packet won't I?
 

Yes. There is also a bit in the command that tells you which way the data will go during the data stage. If the host says it will send zero bytes of data during the data stage, then it will skip the data stage and ask for the status packet.
 

tkbits said:
Yes. There is also a bit in the command that tells you which way the data will go during the data stage. If the host says it will send zero bytes of data during the data stage, then it will skip the data stage and ask for the status packet.


Sorry, could you explain that please?
 

I got it working!
I just added "FLUSH the receive buffer" once I get the SET_CONFIGURATION request, and it is working now.
I don't know how exactly it helped, but it is working
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top