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.

CC2540 USB-MSD Linux Support

Other Parts Discussed in Thread: CC2540

Currently the Universal Boot Loader for SoC-8051 by USB-MSD Developer's Guide states the following known issues:

The USB is currently not working with Linux or Ubuntu. Although it enumerates as a sc’x’ device, Nautilus does not browse it and ‘ls /dev/sd*’ hangs when it reaches the device.

Is there any plans to support this?  If so, what is the status?

Thanks,

Robb S.

  • We do not yet have an update on this bug, though it is still under investigation.

  • I've been looking into this issue myself, as I've been trying to develop a device that uses this bootloader, and I seem to be having an issue regarding the operation of usb_msd.c.
    For me, this firmware only works on Windows 7 and Windows XP.

    On Linux, OS X, and Windows 8, the device is reset continually every 20 seconds or so, and the drive is never mounted.  I have scanned the USB Logs of this device (and compared them to logs of a Nextel USB Thumbdrive configured for a FAT Filesystem) on Linux, Windows 7, and Windows 8.

    In my scanning of the USB Logs, I have determined the following:
    One major issue seems to be related to the handling of Errors during Bulk Transfers.

     On all devices (CC2540 vwith UBL and my working Thumbdrive), calls to IRP_MJ_PNP (QUERY_CAPABILITIES), would periodically cause a status 0xc0000004 error during a Bulk Transfer (Windows 8).

    When the Nextel USB Thumbdrive Encounters these single errors, the device recovers, by responding properly to the Windows Driver's call to 'Reset the Pipe', and rearming the endpoint if the Host clears the 'Halt' Condition.

    While the CC2540 with the UBL Firmware, immediately stalls the pipe and waits for device reset. The Linux USB Enumeration logs show a similar condition. The issue is that the USB MSD Spec says, the device should not force a full reset unless the transfer fails twice in a row (the first time, just re-arm the endpoint).

    I am close to being able to implement this system in my firmware (without access to usb_msd_8051.lib source), to resolve at least part of this issue, but there is one issue that I cannot really resolve.

    In my example implementation of the USB MSD Source Code, A flag is set everytime the firmware Checks an MSD Request. If the CBW (Command Block Wrapper) is valid, then LastCBWValid = True, otherwise LastCBWValid = False.  

    Can I do something like this without the source for usb_msd_8051.c? This seems to me, the only way that I can act in accordance with the USB Mass Storage Specification (and truly tell whether the transmission failed twice in a row).

    Also, Is there a reference for the functions that are available in usb_msd_8051.lib?

  • Update:

    By cross-referencing some of the other TI USB Projects, I have found that I should be able to change the response to Bulk Transmission errors by creating alternate functions for,

    usbsrHookClearFeature()  and usbsrHookSetFeature() (or possibly just the ChangeFeature routine)

    , so I believe that I have answered my first question as to where to implement.

    In the other projects that I viewed, (one using USB-HID and the other USB-CDC) these functions merely Stall Endpoint 0.

    Is there a way to access the source for usb_msd_8051.lib, to ensure that I don't miss anything in my re-write of that routine?

    If not, is there any kind of reference for the functions that are available via usb_msd_8051.lib?