SDK USBMSC

Forgot to mention, it only hangs if I have a USB memory stick plugged in.  If not, it times out (as I'd expect).

Ed,

  Please could you provide a bit more information? I presume you are using MCU SDK and SysBios rather than the examples shipped with StellarisWare? If that's true, I'll have to get hold of someone who knows about that product since I have no experience with MCU SDK as things stand. Which hardware are you running this software on - is it one of our evaluation or development kits or your own board?

  If you are running on one of our eval or development boards, please could you run the usb_host_msc example from the relevant release of StelarisWare and confirm that it works correctly with the USB stick you are using (this ensures that the problem isn't with your hardware). If this example also hangs, please try a different USB stick. We've found many, many sticks that don't comply with the USB standard and this causes problems in our host driver which makes the reasonable assumption that a USB stick won't draw enough current to pull Vbus down and will respond to queries the way it is supposed to!

I am using an LM3S9D92 with MCU SDK 1.0.0.68.  I am using sys bios.  I am running on cusomt hardware.

Ed,

  I'll have to figure out who to speak to in the MCU SDK organization or try to set up a development system here with that tool and see if I can reproduce your problem. In the meantime, if you can try building and running usb_host_msc from the ek-lm3s9d92 release of StellarisWare to confirm whether it shows the same problem, that would be enormously helpful. If it shows the same problem, that gives us a far easier debug platform since the example doesn't use any OS and since I have access to all the people who wrote that code and should be able to help you out very quickly. Our lm3s9d92 evaluation kit board is very simple so I imagine that porting the code to your platform will involve very little other than ensuring that the clock configuration (ROM_SysCtlClockSet or SysCtlClockSet) matches your crystal choice and, possibly, removing UART use if your board doesn't use UART0 on PA0 & PA1.

Pin

70 USBODM

71 USBODP

73 USBORBIAS

65 USBPFLT

66 USBOID

67 USB0VBUS

72 USB0EPE

My init code (before bios starts):

    /* Enable the USB peripheral and PLL */

    SysCtlPeripheralEnable(SYSCTL_PERIPH_USB0);

    SysCtlUSBPLLEnable();

    /* Setup pins for USB operation */

    GPIOPinTypeUSBAnalog(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1);

    /* Additional configurations for Host mode */

    if (usbMode == USBHOST) {                 // this is TRUE since I’m dedicated host

        /* Configure the pins needed */         

        GPIOPinConfigure(GPIO_PB2_USB0EPEN); 

        GPIOPinConfigure(GPIO_PB3_USB0PFLT);

        GPIOPinTypeUSBDigital(GPIO_PORTB_BASE, GPIO_PIN_2 | GPIO_PIN_3);

    }

My code to mount USB (after bios):

    /* Mount and register the USB Drive */

    USBMSCHFatFs_Params_init(&usbmschfatfsParams);

    usbmschfatfsHandle = USBMSCHFatFs_open(USBMSCHFatFs0, USB_DRIVE_NUM, &usbmschfatfsParams);

    if (usbmschfatfsHandle == NULL) {

        System_abort("Error starting the USB Drive\n");

    }

    else {

        System_printf("Drive %u is mounted\n", USB_DRIVE_NUM);

    }

    /* Need to block until a USB Drive has been enumerated */

    if (!USBMSCHFatFs_waitForConnect(usbmschfatfsHandle, 10000)) {

      return;

    }

Ed Hillen

it ... hangs if I have a USB memory stick plugged in

Can you step into the function to see where, exactly, it is "hanging" ?

It would be enormously helpful if you would try running the usb_host_msc application. I see you are using PB2/3 for USB0EPEN and USB0PFLT so you would have to modify the example source to move these from PH3/4 as used on our ek-lm3s9d96 board but, other than this, I think you should be able to run the code pretty much as it is. As I mentioned, this takes the OS out of the equation and would allow me to help you out a lot quicker since all the code in that application came from within 2 offices of where I sit.

The code you posted doesn't tell me the full initialization story. I don't see any SysCtlPeripheralEnable() call for GPIO port B (though you must be making this since, otherwise, the GPIOPinConfig() calls for the port would be faulting) and I can't tell how your system clock and SysTick are configured. These may be important.

As Andy Neil asked, it would also be helpful if you could tell us what debug steps you have taken already and what you have found. Is the hang caused by something blocking on a semaphore or mutex, something stuck in a polling loop, a fault (if so, which fault and where is it?), etc. ,etc.

As I mentioned before, we have seen quite a few problems with bad flash sticks so it would also be great if you could verify that you've tried running with multiple USB flash sticks including at least one from a premium brand (which is more likely to be spec-compliant). If the problem turns out to follow the flash stick, we may ask you for more details or a sample of the problem device so we can see what it is doing and try to work around whatever problem it is causing.

When I pause code, it seems to be in the USBHHubMain routine inside the following loop:

for(ucPort = 0; ucPort <= g_pRootHub->ucNumPortsInUse; ucPort++)

The ucNumPortsInUse variable is 0xFF ?

It appears (to me) that example DK uses PA6 and PA7 (not PH 3/4)... but anyhow, I think I changed (see below). 

GPIOPinTypeUSBAnalog(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1);GPIOPinConfigure(GPIO_PB2_USB0EPEN);
GPIOPinConfigure(GPIO_PB3_USB0PFLT);
GPIOPinTypeUSBDigital(GPIO_PORTB_BASE, GPIO_PIN_2 | GPIO_PIN_3);

 
You also mention, "I don't see any SysCtlPeripheralEnable() call for GPIO port B (though you must be making this since, otherwise, the GPIOPinConfig() calls for the port would be faulting) and I can't tell how your system clock and SysTick are configured. These may be important."

I have the following lines, is this what you are referring to? 

SysCtlPeripheralEnable(SYSCTL_PERIPH_USB0);

SysCtlUSBPLLEnable();

/* Setup pins for USB operation */

GPIOPinTypeUSBAnalog(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1);

Where can I find the usb_host_msc application in the SDK?

Ed,

  You are looking at a different version of usb_host_msc. The version from the dk-lm3s9b96 or dk-lm3s9d96 release of StellarisWare contains a bunch of graphics code and is for a board that is rather different from yours (I suspect). The one in the ek-lm3s9d92 kit will be a lot easier to port since that is a far simpler board and since it doesn't assume the presence of a QVGA touchscreen.

  As I mentioned, I have no experience of the MCU SDK so don't know if this example exists. I would love it if you could try the version from the base StellarisWare package (which you can download from here) and see if it shows the same problem. If the problem is still seen there, that rules out the OS or the port as culprits and we can debug using the simpler app. If the problem goes away, that tells us that something in the SysBios port or in the OS-dependent sections of the application are to blame.

  Once you download and install the StellarisWare package, look in C:\StellarisWare\boards\ek-lm3s9d96\usb_host_msc for the example. You will find read-made CCS project files for all the examples so these can be imported into a clean CCS workspace to allow you to build and debug the code easily.

Dave,

I know the project you're referring to; I had it running on the DK.  My problem is that I have customer hardware and my project (for my board) uses sysbios.  I can try and run that example outside sys bios but I'm not sure how to configure the fatfs and usb stuff in the midst of other parts of my project using sys bios.  Ideas?

Do I un-select fatfs and usb msc host from my config and then use snippets from the non-sysbios example?  What drivers/libs do I need to include?

We've reached a point where I can't offer any help since I know nothing about SysBios. Let me try to find someone round here who has used it to see if they can offer any assistance. I was hoping we could narrow down the problem area without having to use the full application with the OS. The basic question I am trying to answer (and which you definitely need to figure out) is whether your custom board's USB implementation is up and running correctly. To verify this, I strongly suggest using smaller, simpler testcases. Once you are 100% sure the base USB is rock-solid, then move on to the larger, more complex applications.

  While I'm looking for SysBios help, could you verify that you have thoroughly checked out your USB host hardware and can enumerate simple devices successfully using variations on some of the usb_host_xxx applications included in StellarisWare or your own testcases?

  More later...

Hi Ed,

Can you attach your board source files (e.g. DK_LM3S9D92.c, DK_LM3S9D92.h and DK_LM3S9D92.cmd). Are the rest of the project files similar to the mcusdk's fatsdusbcopy example?

Thanks,

Todd

Hi Ed,

also check your project's predefined symbols option. Make sure you update it for your part.

Please see my previous posts for my code.   Below you'll find my data declarations.  My project has numerous other (non-usb) related io drivers.  I've copied the code (posted) from the example and changed the USB IO for the two pins (pen and flt) that are different for my target.  FYI, my usb host (A cnctr) is powering device.

USBMSCHFatFs_Object USBMSCHFatFsObjects[USBMSCHFatFsCOUNT];

/* USBMSCHFatFs configuration structure, describing which pins are to be used */

const USBMSCHFatFs_HWAttrs USBMSCHFatFsHWAttrs[USBMSCHFatFsCOUNT] = {{INT_USB0}};

const USBMSCHFatFs_Config USBMSCHFatFs_config = {USBMSCHFatFsCOUNT, USBMSCHFatFsObjects, USBMSCHFatFsHWAttrs};

USBMSCHFatFs_Handle usbmschfatfsHandle;

USBMSCHFatFs_Params usbmschfatfsParams;