• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 312 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123GE6PM: Help USB MSC vs Bulk transfer device

Robert Valentine
Prodigy 205 points
Part Number: TM4C123GE6PM

Hello,

I am trying to figure out how to approach a USB project with a Tiva MCU.  I need to transfer with the MCU as a device using bulk transfers.  This way I can utilize the most bus bandwidth available.  I'm using USB 2.0 and would like to write a python application to connect and test the firmware.  I am seeing both bulk transfer examples such as the example in Tivaware usblib which is very helpful.  But I'm also seeing a lot of people use the MSC device class.  I want windows 10 to recognize the interface automatically with no required user driver installation to communicate to the MCU (using the bulk transfers).  

So as a first step I'm trying to figure out the following:

1. Can you run an MCU in USB 2.0 device mode like this as a MSC mass storage device?  If so does this makes sense?

2. Does the tivaware usblib bulk transfer example require a custom driver on the host side?  I notice my device manager shows a generic bulk device, but I have a yellow warning sign on it.

3. Does the mass storage device class require there be a filesystem on the device?  I have only seen this used with USB drives which look like a drive with a filesystem.

The top level view of this project is to use bulk transfers to communicate between a host Python application and the MCU.  The customer/end user can't install any drivers or supporting software/libraries/dependencies.  So I need the device setup in a way that leverages standard windows 10 supporting libraries/drivers for communication.

Any help is greatly appreciated!

Thanks!

  • +1
    TI__Guru*** 128125 points

    Hello Robert,

    I will try and answer what I can regarding these questions.

    For Question 1, yes you can run the device in such a mode. As for how much it makes sense... I'm not quite sure. If the sole intent is to use bulk endpoints I feel like either CDC or Bulk interfaces may be better served?

    For Question 2, this is less about TM4C and more about Windows and my knowledge is rather limited. On the TM4C end, the device expects a standard enumeration process where it provides some fundamental data about what sort of device it is, what endpoints are used etc. - but there isn't some sort of driver requirement from the TM4C to tell Windows a unique protocol. It's all standard USB interface which is communicated during the enumeration.

    Where my knowledge falls off here is what does Windows require and how that can be worked into a 'driverless' installation. The whole driver bit with Windows tends to be focused around Windows needing to know whether a USB device that's attached to the system is a valid one. The drivers contain PID and VID information that is registered and allows Windows to authenticate the USB device as a legitimate one. This has been a growing focus for Windows since Windows 7 and I have seen them crack down more on allowing unregistered USB devices to properly enumerate. If there is a way to use some sort of existing / generic descriptor to avoid the driver installation is something that would need to be investigated on the Windows side as it isn't a TM4C requirement but an OS one. I would guess these exist for something like MSC because you don't have to install drivers to use USB sticks etc. But I am not sure what rules govern their usage.

    For Question 3, no there isn't a requirement for one, but MSC stands for mass storage class and is typically used for purposes like USB sticks and such so the standard application cases for it would all use a file system which is why you have that observation. Again this goes back to the point where I am not sure if MSC really is the best choice over CDC or Bulk.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 205 points

    Hi Ralph,

    Thank you for the detailed reply!  I really appreciate your time!  This is very helpful and it seems as I suspected the MSC isn't necessary.  From your experience is it common to just use bulk endpoint communication for moving data?  This is really all I need.  I just ventured into the MSC domain because I thought it might solve my "driver less" plug and play approach for this device project.

    I do see the icon of a generic bulk device.  Do you know if that means it is possible to get a hold of the bulk endpoints?  It has the warning icon so I'm not sure and will fiddle with this some more.  This sounds like it all boils down to using bulk endpoints is common and normal so that looks like a good approach for me to pursue for now.

  • 0 in reply to Robert Valentine
    TI__Guru*** 128125 points

    Hi Robert,

    Yes it's common to use the bulk endpoint. The driver less plug and play approach probably has solutions for other means too, and I don't know how Windows handles the MSC piece of that. I could see the automated driver that doesn't need installing being based on doing file system level accesses - like part of the process is determining the file system of the USB drive. And if there isn't one that fits Windows expectations, then it would treat it as a non-standard MSC and require a driver again. Just speculation on my end. But I imagine there should be basic drivers for simple applications because like bare bones USB mice and keyboards don't need any drivers, they just work (those are HID) so there should be hopefully a generic/basic driver you can use for Bulk or CDC for your use case.

    As for the Generic Bulk Device w/ the icon I think that's indicating it only partially enumerated and it expects a driver to help finish the enumeration - the windows_drivers we have in TivaWare should fix that bit. That'd be all because our default enumeration is based on the PID/VID we have approved for our devices like LaunchPads and we provide drivers to complete that enumeration based on that.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 205 points

    Hi Ralph,

    I ran a traffic logger to capture the enumeration process and it seems some things are missing.  One that jumps out is the interface descriptors aren't shown.  Below is a screenshot of the enumeration and it looks like you may be correct that it only partially enumerates. 

    I'm trying to use the bulk endpoints, but without having to provide a driver.  I've also purchased PID/VID numbers for my product so I have my own.  I actually was hoping to do exactly what you pointed out with HID - basically just plug in and use a default driver provided by windows.  Just as one can do with HID I want to do that with bulk endpoints.  I "think" there is a python host library called libusb1.0 available, but I'm unsure how to get the device to enumerate.

    So it sounds like there is an option to modify this example project in tivaware usblib to make more progress in the enumeration process without the TI provided driver as you mentioned?  My reason for trying to avoid using your driver is because I don't want to provide it to customers with my host application.  

  • 0 in reply to Robert Valentine
    TI__Guru*** 128125 points

    Hello Robert,

    You wouldn't need to modify anything in the usblib of the code. The descriptors for enumeration used by the library are defined in the application within files like usb_bulk_structs.c.

    In that file you can change what is being sent to not be the TI-based drivers, but your own.

    We do have defined VID and PID data that is part of the usblib but you can just replace that with your own:

    tUSBDBulkDevice g_sBulkDevice =
{
    USB_VID_TI_1CBE,
    USB_PID_BULK,
    500,
    USB_CONF_ATTR_SELF_PWR,
    USBBufferEventCallback,
    (void *)&g_sRxBuffer,
    USBBufferEventCallback,
    (void *)&g_sTxBuffer,
    g_ppui8StringDescriptors,
    NUM_STRING_DESCRIPTORS
};

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 205 points

    Hi Ralph,

    I was looking at this earlier and the reason I didn't bring it up was because I didn't think it had enough information there to tell windows to do something like that.  I do see the VID/PID, but I don't see any other fields that could convey information to Windows.  Do you know if changing out the VID/PID is enough?  Maybe the TI VID/PID is what is doing the connecting between the device and the TI host drivers?

    The rest of the information just seems to be callbacks and buffers and string descriptors so I guess I still have a gap in my understanding of what field actually tells the host to try a driver.  

  • 0 in reply to Robert Valentine
    TI__Guru*** 128125 points

    Hello Robert,

    Honestly this is where my knowledge of the USB descriptors breaks down a bit. I'm more familiar with how end points work and the more technical side of the enumeration in terms of configuring the actual data streams. When it comes to the 'drivers' aspects like PID, VID, descriptor names etc. I am not really knowledgeable about what all is required and how you'd go about adapting the descriptor to be driverless.

    What I can say is the USB library uses the structures passed into it to send all the descriptor data over. It will add in details like how many endpoints are needed, what each endpoint is numbered, the type of endpoint etc. but what is used by Windows from a USB driver standpoint is contained within the application layer so you don't need to modify the USB library to change how the device enumerates from a driver standpoint.

    Best Regards,

    Ralph Jacobi