AnsweredAssumed Answered


Question asked by John McCabe on Mar 21, 2018


(See Additional comments below after editing)

I'm currently trying to port the usbd_rom_msc_ram example from the LCP18S37 samples to the Embedded Artists LPC1788 Development Kit, as an interim step to porting it to some custom hardware based on the LPC1788. I've managed to get it mostly working, including porting the external SDRAM config in to allow me to provide 32MBytes of storage but, (in windows) when I right click on the drive and select "Eject", I get a message that an error occurred.


After a bit of research around the place, and using Wireshark to capture the USB packets, it looks like this might be related to the SCSI PREVENT ALLOW MEDIUM REMOVAL command's response being "command failed" (irrespective of whether the command asks for PREVENT or ALLOW. An example of the output in Wireshark is attached.


When the sense information is requested after this, the response (which is included in the file but, to make it obvious,...) includes:

SCSI Payload (Request Sense Response Data)
[LUN: 0x0000]
[Command Set:Direct Access Device (0x00) ]
[SBC Opcode: Request Sense (0x03)]
[Request in: 1991]
[Response in: 1993]
.111 0000 = SNS Error Type: Current Error (0x70)
Valid: 112
0... .... = Filemark: False
.0.. .... = EOM: False
..0. .... = ILI: False
.... 0010 = Sense Key: Not Ready (0x2)
Sense Info: 0x00000000
Additional Sense Length: 10
Command-Specific Information: 00000000
Additional Sense Code+Qualifier: Cannot Read Medium - Unknown Format (0x3001)
Field Replaceable Unit Code: 0x00
0... .... = SKSV: False
.000 0000 0000 0000 0000 0000 = Sense Key Specific: 0x000000

Does anyone know whether there is an obvious reason for this (i.e. is there a configuration option I'm missing somewhere)?

I'm assuming that this is happening in the default handler for this message type in the USBD library's MSC stuff; as an alternative to a quick fix, does anyone know how I can override the handling of the message myself? Is this part of the EP0 handling? 


Any help gratefully appreciated.





After a bit of further consideration, I don't think it's the handling of the PREVENT ALLOW MEDIUM REMOVAL command that's the issue here. As I understand it (please correct me if I'm wrong), if the command succeeds, Windows (in this case) thinks it's safe to cache data for the drive and only write it when the drive's being ejected. If the command fails, the caching is avoided and writes just happen when they're needed.


My latest thought is that it's around the SCSI START STOP UNIT command (telling it to stop) that's the problem. This is sent when I select "Eject" on the context menu. The device is responding with command failed. It looks like this is retried then the SCSI TEST UNIT READY command is sent out, which gets a "command passed" response with "Good". 


This is only an educated guess, but I suspect that Windows is hoping to see START STOP return command passing then, when it sends TEST UNIT READY, get back a CHECK CONDITION response, with MEDIUM NOT PRESENT or something in the sense information. Obviously that's not happening, so it goes back to the question on whether there's any way to capture the SCSI commands and process them in a way that may be more appropriate.


Also, one other weird thing is that the version of usbdlib I'm using, admittedly from a relatively old LPCOpen release (I think), has the SCCS field in the INQUIRY response set to 1 to show SCC is supported (see below). Does that sound reasonable?


Frame 1414: 63 bytes on wire (504 bits), 63 bytes captured (504 bits) on interface 0
Interface id: 0 (\\.\pipe\wireshark_extcap_\\.\USBPcap2_20180321142047)
Interface name: \\.\pipe\wireshark_extcap_\\.\USBPcap2_20180321142047
Encapsulation type: USB packets with USBPcap header (152)
Arrival Time: Mar 21, 2018 14:20:50.933845000 GMT Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1521642050.933845000 seconds
[Time delta from previous captured frame: 0.001000000 seconds]
[Time delta from previous displayed frame: 0.001000000 seconds]
[Time since reference or first frame: 3.082000000 seconds]
Frame Number: 1414
Frame Length: 63 bytes (504 bits)
Capture Length: 63 bytes (504 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb:usbms]
[Source: 2.7.1]
[Destination: host]
USBPcap pseudoheader length: 27
IRP ID: 0xfffffa801660c010
IRP information: 0x01, Direction: PDO -> FDO
0000 000. = Reserved: 0x00
.... ...1 = Direction: PDO -> FDO (0x1)
URB bus id: 2
Device address: 7
Endpoint: 0x81, Direction: IN
1... .... = Direction: IN (1)
.... 0001 = Endpoint number: 1
URB transfer type: URB_BULK (0x03)
Packet Data Length: 36
[Request in: 1413]
[Time from request: 0.001000000 seconds]
[bInterfaceClass: Mass Storage (0x08)]
USB Mass Storage
SCSI Payload (Inquiry Response Data)
[LUN: 0x0000]
[Command Set:Direct Access Device (0x00) ]
[SBC Opcode: Inquiry (0x12)]
[Request in: 1413]
[Response in: 1415]
Peripheral: 0x00, Qualifier: Device type is connected to logical unit, Device Type: Direct Access Device
000. .... = Qualifier: Device type is connected to logical unit (0x0)
...0 0000 = Device Type: Direct Access Device (0x00)
Inquiry RMB Flags: 0x80, Removable
1... .... = Removable: This is a REMOVABLE device
Version: No Compliance to any Standard (0x00)
Inquiry ACA Flags: 0x01, Response Data Format: Unknown
..0. .... = NormACA: Normaca is NOT supported
...0 .... = HiSup: Hierarchical addressing mode is NOT supported
.... 0001 = Response Data Format: Unknown (1)
Additional Length: 32
Inquiry SCCS Flags: 0x80, SCCS, TPGS: Asymmetric LU Access not supported
1... .... = SCCS: SCC is SUPPORTED
.0.. .... = ACC: Access control coordinator NOT supported
..00 .... = TPGS: Asymmetric LU Access not supported (0)
.... 0... = 3PC: Third party copy is NOT supported
.... ...0 = Protect: Protection information NOT supported
Inquiry BQue Flags: 0x00
0... .... = BQue: Bque is NOT supported
.0.. .... = EncServ: Enclosed services is NOT supported
...0 .... = MultiP: This is NOT a multiport device
Inquiry RelAdr Flags: 0x00
.... ..0. = CmdQue: Command queuing is NOT supported
Vendor Id: NXP
Product Id: LPC Mem Disk
Product Revision Level: 1.0
SCSI transfer limited due to allocation_length too small: SCSI truncated]