Author Topic: USB mass storage class - answering to SCSI inquiry  (Read 15494 times)

mikyak

  • Member
  • ***
  • Posts: 9
USB mass storage class - answering to SCSI inquiry
« on: September 01, 2011, 02:57:38 am »
Hello!

I am trying to implement a mass storage device driver on an mcf5272 processor.

I use the endpoint 2 for bulk input and output, while endpoint 1 is used
for the HID interface by an example from freescale - motorola.
Is it possible that endpoint 2 bulk is starved because of endpoint
1 traffic ?

Currently , the device passes enumeration, and receives the Command Block
Wrapper CBW on endpoint 2 OUT. I read the CBW: it contains the SCSI Inquiry
request and an expected length of 36 bytes. The direction bit in the CBW
message is set to IN.

After the CBW is read, I check the direction in the endpoint 2 status register
EP2ISR. It says that the endpoint is currently configured in OUT direction.

After this I try 2 approaches:
1. To wait until there is an interrupt which sets the endpoint 2 to IN
   direction. This seems to be somehow connected with IN EndOfTransfer
   or IN EndOfFrame event.
   However, the IN interrupt for endpoint 2 does not happen,
   altough endpoint 0 changes to IN state many times.

2. To change the direction bit in EP2ISR manually and write the data in the
   endpoint 2 data register EP2DR. The direction does not change however, after
   writing to EP2ISR [DIR]
   I clear the EP2CTL [IN_DONE] after the data is written to the ep2
   data register so the data can be sent to the host.
   [Also I tried to set the EP0CTL [CMD_OVER] bit, to try to ACK
   the CBW command, but this still does not change the direction
   of endpoint 2 to IN. ]

On the output of the USB analyzer it can be seen that the
OUT transfer of CBW request is completed and ACKed but the IN transfer
does not happen, altough the data has been written to the FIFO and
the EP2CFG [IN_DONE] bit has been cleared. On the analyzer it can be seen
that the host sends IN tokens, but there is no response from the device.

So my question is:
1. Should I wait for the interrupt that sets endpoint 2 to IN mode
   before trying to write to the data register.

2. Should I manually ACK the host OUT transmission, before the
   IN bytes can be sent.

3. It says in one example that the response to SCSI Inquiry should be
   wrapped inside the Command Status Wrapper of the Mass Storage Class.
   However, the CSW only has 13 Bytes. So I suppose that the SCSI
   response should be sent before sending the CSW and that the CSW message
   should only contain the SCSI request status. Is that correct ?

Thanks for any help.

mikyak

  • Member
  • ***
  • Posts: 9
Re: USB mass storage class - answering to SCSI inquiry
« Reply #1 on: September 01, 2011, 10:58:01 am »
Using dedicated endpoints one for IN and one for OUT solves this.

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB mass storage class - answering to SCSI inquiry
« Reply #2 on: September 01, 2011, 11:16:49 am »
I'm glad to hear you got it working!

Jan

Bret

  • Frequent Contributor
  • ****
  • Posts: 68
Re: USB mass storage class - answering to SCSI inquiry
« Reply #3 on: September 01, 2011, 03:41:05 pm »
I figured I would make a point of clarifications, since I was confused by this in my early days with USB as well.

For all types of end points except control, the direction is part of the end point "number".  You can have an EP2-In and and EP2-Out on the same device, but they are NOT the same end point.  At least theoretically, they wouldn't even need to be the same type of EP (one could be bulk and the other interrupt, e.g.).  Control EP's are bidirectional (though I've never personally seen a device with a control EP other than EP0).

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB mass storage class - answering to SCSI inquiry
« Reply #4 on: September 01, 2011, 03:59:37 pm »
That's correct. The USB spec calls endpoint number + direction the "endpoint address."

There is no advantage to multiple control endpoints, so no point to supporting other endpoint numbers for control endpoints.

A lot of the USB terminology is more confusing than it needs to be, in my opinion.

Jan