Forums

Please provide more detail on your desired application. You might need to write your own example instead of usb_dev_bulk as this uses standard MSC descriptor and so windows PC will show it in system tray.

Ajay

Dear Ajay:

Thanks for your reply!

My application will use basic USB bulk transfers as in usb_dev_bulk, using the WinUSB driver on the PC side.  I do need to set bInterfaceClass = 0xFF (vendor-specific) in my interface descriptor.

usb_dev_bulk

• need to install WinUSB driver on PC side (not MSC)
  - does not mount as a drive
• usbdbulk.c / g_pBulkInterface: USB_CLASS_VEND_SPECIFIC
  - i.e., bInterfaceClass = 0xFF (usblib.h)
• however, "Stellaris Bulk Device" still appears in the "Safely Remove Hardware" list
  - is there any way to avoid this by changing firmware or the INF file?
  - writing a custom PC driver is infeasible for us..

Contrast with usb_dev_msc (I am not using this):

• no driver installation (generic windows mass storage)
• usbdmsc.c / g_pMSCInterface: USB_CLASS_MASS_STORAGE
  - i.e., bInterfaceClass = 0x08 (usblib.h)

Sorry about any miscommunication.

Thanks!
Jonathan

Jonathan,

Did you try changing the device descriptor data in starterware code. Search where dev_msc descriptor are being defined and do the changed as per you need. important one is bInterfaceClass code in "device descriptor" and "interface descriptor".

Ajay

Dear Ajay:

Unfortunately, my application requires and already uses

• bInterfaceClass = 0xFF
• WinUSB driver on PC side
• "Generic Bulk Device" is shown on the "Safely Remove Hardware" list

Also my code is based on usb_dev_bulk, not usb_dev_msc.  Sorry if I was unclear earlier.

I suspect the source of the problem is the way the WinUSB driver interacts with Windows' USB stack, and winusb.sys is not enabling surprise removal... What do you think?  I am fairly new to all of this, and I am not very sure about anything..

Thank you!
Jonathan

Jonathan,

It all fine that your application uses 0xff code. You need to change the same in descriptor data in starterware firmware also. I mean when starter ware is connected to PC it should tell to windows that its bInterfaceClass code is 0xFF which would require change in starterware code as default bInterfaceClass will be set to as of MSC class.

Ajay

Dear Ajay:

Ajay

default bInterfaceClass will be set to as of MSC class.

By "application", I was referring to both my PC-side and firmware-side custom code; sorry about any confusion.

I did not want to post large chunks of default StarterWare code we should both already have, but I feel this information is not being communicated properly.  Please see the following yellow highlighted library code, copy/pasted unmodified from default StarterWare code for the usb_dev_bulk example:

// AM1808_StarterWare_1_00_03_03/usblib/device/usbdbulk.c

//...
#include "usblib.h"
//...

//*****************************************************************************
//
// Device Descriptor.  This is stored in RAM to allow several fields to be
// changed at runtime based on the client's requirements.
//
//*****************************************************************************
unsigned char g_pBulkDeviceDescriptor[] =
{
    18,                         // Size of this structure.
    USB_DTYPE_DEVICE,           // Type of this structure.
    USBShort(0x110),            // USB version 1.1 (if we say 2.0, hosts assume
                                // high-speed - see USB 2.0 spec 9.2.6.6)
    USB_CLASS_VEND_SPECIFIC,    // USB Device Class
    0,                          // USB Device Sub-class
    0,                          // USB Device protocol
    64,                         // Maximum packet size for default pipe.
    USBShort(0),                // Vendor ID (VID).
    USBShort(0),                // Product ID (PID).
    USBShort(0x100),            // Device Version BCD.
    1,                          // Manufacturer string identifier.
    2,                          // Product string identifier.
    3,                          // Product serial number.
    1                           // Number of configurations.
};

// ...

//*****************************************************************************
//
// The remainder of the configuration descriptor is stored in flash since we
// don't need to modify anything in it at runtime.
//
//*****************************************************************************
const unsigned char g_pBulkInterface[] =
{
    //
    // Vendor-specific Interface Descriptor.
    //
    9,                          // Size of the interface descriptor.
    USB_DTYPE_INTERFACE,        // Type of this descriptor.
    0,                          // The index for this interface.
    0,                          // The alternate setting for this interface.
    2,                          // The number of endpoints used by this
                                // interface.
    USB_CLASS_VEND_SPECIFIC,    // The interface class
    0,                          // The interface sub-class.
    0,                          // The interface protocol for the sub-class
                                // specified above.
    4,                          // The string index for this interface.

    //
    // Endpoint Descriptor
    //
    7,                               // The size of the endpoint descriptor.
    USB_DTYPE_ENDPOINT,              // Descriptor type is an endpoint.
    USB_EP_DESC_IN | USB_EP_TO_INDEX(DATA_IN_ENDPOINT),
    USB_EP_ATTR_BULK,                // Endpoint is a bulk endpoint.
    USBShort(DATA_IN_EP_MAX_SIZE),   // The maximum packet size.
    0,                               // The polling interval for this endpoint.

    //
    // Endpoint Descriptor
    //
    7,                               // The size of the endpoint descriptor.
    USB_DTYPE_ENDPOINT,              // Descriptor type is an endpoint.
    USB_EP_DESC_OUT | USB_EP_TO_INDEX(DATA_OUT_ENDPOINT),
    USB_EP_ATTR_BULK,                // Endpoint is a bulk endpoint.
    USBShort(DATA_OUT_EP_MAX_SIZE),  // The maximum packet size.
    0,                               // The polling interval for this endpoint.
};

// AM1808_StarterWare_1_00_03_03/usblib/include/usblib.h for reference

// ...

//*****************************************************************************
//
// USB Device Class codes used in the tDeviceDescriptor.bDeviceClass field.
// Definitions for the bDeviceSubClass and bDeviceProtocol fields are device
// specific and can be found in the appropriate device class header files.
//
//*****************************************************************************
#define USB_CLASS_DEVICE        0x00
#define USB_CLASS_AUDIO         0x01
#define USB_CLASS_CDC           0x02
#define USB_CLASS_HID           0x03
#define USB_CLASS_PHYSICAL      0x05
#define USB_CLASS_IMAGE         0x06
#define USB_CLASS_PRINTER       0x07
#define USB_CLASS_MASS_STORAGE  0x08
#define USB_CLASS_HUB           0x09
#define USB_CLASS_CDC_DATA      0x0a
#define USB_CLASS_SMART_CARD    0x0b
#define USB_CLASS_SECURITY      0x0d
#define USB_CLASS_VIDEO         0x0e
#define USB_CLASS_HEALTHCARE    0x0f
#define USB_CLASS_DIAG_DEVICE   0xdc
#define USB_CLASS_WIRELESS      0xe0
#define USB_CLASS_MISC          0xef
#define USB_CLASS_APP_SPECIFIC  0xfe
#define USB_CLASS_VEND_SPECIFIC 0xff
#define USB_CLASS_EVENTS        0xffffffff

• This is all default StarterWare firmware code,
  
• Using this default StarterWare firmware code, the EVM board is listed under the "Safely Remove Hardware" list. This is the issue I reported in my original post.
  
• This is not the Mass Storage Class example (usb_dev_msc). The usb_dev_bulk firmware example that I use is described here in the StarterWare wiki.
  - usb_dev_bulk does not use MSC code.
  - usb_dev_bulk does not mount as a Removable Drive.
• The usb_dev_bulk example uses usbdbulk.c
  - it does not use usbdmsc.c

Please let me know if I am not understanding something correctly.

Sincerely,
Jonathan

Jonathan,

I am sorry to create confusion, I am not directly working and have code for starterware. Now I understand the issue on why PC is showing the device in "Safely Remove Hardware list" when the device is vendor specific.

I am not sure on how is this affecting you work ?  I believe you can still go ahead and communicate to starterware devcie using your custom application on PC. I can see in my wondows 7 PC even non MSC devices getting listed in "Safely Remove list"/

Ajay

Dear Ajay:

You are correct, the PC and StarterWare device can still communicate correctly.

Our application/firmware does not require Safe Removal (i.e., allows surprise removal), so it is not necessary to list our device under "Safely Remove Hardware".

If we could remove our device from the "Safely Remove Hardware" list, the overall experience would be that much less confusing experience for the end user.

This is a minor issue.  However, CDC devices (USB/serial converters) are not shown in the "Safely Remove Hardware" list, so wanted to know whether it would be possible by changing one of the following:

• device firmware
• application software
• Windows INF file
• Windows driver (winusb.sys)

Or is "Safely Remove Hardware" specified unconditionally by the USB standard for Vendor Specific devices?  We are able to modify everything except for winusb.sys.

Thank you!
Jonathan

I don't have answer to this. May be you can post this in Microsoft's support forum.

Thanks,

Ajay

good to see that we now know where the issue it.

Ajay