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.

TM4C123GH6ZRB: Extremely slow MSC speeds, only when using a composite device

Part Number: TM4C123GH6ZRB

Hello,

I am working with the TM4C123GH6ZRB and am trying to implement a composite device that consists of a BULK interface 0, and a MSC interface 1. Both interfaces work great on their own when they are not in a composite device, but once I try to put them together, I see an extreme drop in the MSC transfer speeds. For instance, when I am running just the MSC device, I can get ~64KBps. However, once it switches to the composite device, that same interface struggles to get ~8KBps.

I am using the TI TIVA MSC library and MSC example (usblib\device\usbdmsc.c & usb_de_msc), combined with a SPI Flash part using the spi_flash driver (utils\spi_flash.h) from TI as well. The spi_flash driver interfaces with a slightly modified version of the example driver MX66I51235f, as I am trying to use the MX25L51245G.

I am initializing my composite device as:

    //Force USB Device mode with no VBUS/ID monitoring.
    USBStackModeSet(0, eUSBModeForceDevice, 0);

    //Initialize our custom BULK interface
    g_sCompDevice.psDevices[0].pvInstance = USBDBulkCompositeInit(0, &g_sBulkDevice, &g_psCompEntries[0]);
    //Initialize a generic MSC interface
    g_sCompDevice.psDevices[1].pvInstance = USBDMSCCompositeInit(0, &g_sMSCDevice, &g_psCompEntries[1]);

    //Initialize USB device as a COMP device with BULK and MSC interfaces defined above
    USBDCompositeInit(0, &g_sCompDevice, COMPOSITE_DBULK_SIZE + COMPOSITE_DMSC_SIZE, (uint8_t *)pucDesciptorData);

Is there a reason that both of these interfaces work fine by themselves (Just calling USBDBulkInit or USBDMSCInit), but once I try to put them in the composite configuration I loose a lot of the throughput on the MSC interface? Is there some kind of configuration that I might be missing, or a method I should be using to better handle the MSC transfers?

  • Hi,

      I'm not an USB expert. I suppose you should get similar performance in either MSC only device or MSC in composite device. Can you answer the below questions so I can forward to our USB expert for comments.

      - Is the USB bulk interface in the composite device having the same performance compared to when it is a standalone BULK device?

      - Do you have an USB analyzer such that you can compare the transactions between MSC-only device vs. MSC in composite? Can you tell where the bottleneck is?

      - When you say MSC by itself is giving you higher throughput, are you interfacing to the same SPI flash? You mentioned you are using MX25L51245G. Are these two #define changed according to your new SPI flash?

    #define MX66L51235F_MEMORY_SIZE 0x04000000
    #define MX66L51235F_BLOCK_SIZE 0x1000

      - Can you compare your device and interface and endpoint descriptors for MSC-only vs MSC interface in the composite device? Can you tell any difference that might provide some hints?

      - In your composite device, is the BULK interface and MSC interface sharing the same endpoint? Have you tried to use different endpoint for each?

  • Hello,

    - The BULK interface on the composite device is not having the same issue and seems to be working just fine.

    - I am using Wireshark as a USB analyzer, and the only difference appears to be that the time between write commands takes longer to respond. ~50ms on the single MSC interface device, and ~300ms on the composite interface. There doesn't seem to be anything else other than the actual ACK of each packet.

    - I am using the same SPI flash part when testing both the composite and non composite device. The Memory size and block size have been updated accordingly.

    - The only difference in the descripts, is the introduction of the two interfaces, but both interfaces still match what the non composite device shows for each respective interface.

    - They are not sharing any endpoints. Both interfaces have their own set of endpoints (0x01 and 0x81 for BULK. 0x02 and 0x83 for MSC)

  • Hello Devon,

    There hasn't really been any throughput / performance analysis done for using the USB composite interface, so I don't have any reference points to say whether this is abnormal or typical.

    What I can say is that the composite interface implementation in the library is not the smoothest, and I could definitely see this issue being centered on inefficient handling extending throughput. The 250 ms difference would roughly equate to the throughput drop you are seeing.

    Have you tried changing the order of which device enumerates first? The thought process would be that maybe there are cycles wasted in sorting first vs second instance and the first instance gets better throughput. Given you have benchmarks for how long the write commands take, you should be able to see if this provides a tangible improvement which could give us a clue about what is going awry.

    One way to test for possible bottle necks would be to add debug signals between different parts of the code such as when the USB MSC interface is used for write commands. The idea being to try and locate the discrepancy of where the time extends. This can even be done in the USB library files itself by importing them into the CCS project as covered here: https://www.ti.com/lit/ug/spmu373/spmu373.pdf#page=19

    If we can trace down where the root cause is, I may be able to offer some guidance on how to improve the handling, but unfortunately I won't be able to manually debug it myself to track this down as I lack the harder to setup a USB MSC interface like you have done so.

    Best Regards,

    Ralph Jacobi