Hard fault when connecting to host on LM3S5C51

You can just use any GPIO (other than PB1), configure it as an input and monitor the USB VBUS signal on that pin during enumeration. You are really not mapping USB0VBUS pin to another pin, but just using another pin to monitor USB VBUS (which would otherwise be monitored by USB0VBUS). 

Joe,

Using a different GPIO pin configured as an input to monitor the VBUS signal is the workaround that this errata describes, as Harman suggested.  However, if using StellarisWare, any mention of PB1 as VBUS must be changed.  To do this is pretty difficult.  I would suggest running as OTG and not forcing device mode (by using the DEVMODOTG or DEVMOD bits).  Instead, tie PB0 (USBID) high to permanently configure USB device.  This way, you will not run into this errata and PB1 can still be used to monitor VBUS.

-Rebecca

Thanks for the reply Rebecca and Harman. I am using the StellarisWare software, specifically the CDC device class driver. Is there a way of using the CDC device driver in the OTG mode? Do I simply add a call to USBOTGModeInit after calling USBDCDCInit? Note: I have added a test jumper from PB0(USBID) to the USB 5V, similar to the LM3S9B92 dev board.

Joe,

Placing the USB device in OTG mode occurs before dealing with the class drivers, so you won't have to do anything special for the device to operate in OTG mode using the CDC device driver.  When using the StellarisWare API USBStackModeSet(), ensure that the second parameter is USB_MODE_DEVICE (like this: USBStackModeSet(0, USB_MODE_DEVICE, 0);).  To see how this is used and where to place it within your code, please refer to on of the USB device examples for the LM3S9B92.  This parameter will make it so that the device will be OTG and will recognize that the ID pin is high which indicates that it is a device and will not set the DEVMODOTG or the DEVMOD bits, thereby never running into the errata.

-Rebecca 

@ Rebecca - find your recent posts - this thread - simply great!  Wonderfully argued and clear in their presentation.

That memorialized - does such guidance extend to Stellaris MCU's beyond device in question?  If so - would you be so good as to provide - or link to such list?

Much thanks...

cb1,

Yes, this should apply to all devices with the "Special considerations for PB1" erratum mentioned in the first post.

-Rebecca

Hi Rebecca,

Had a different perspective - was instead wondering if a "listing" of those Stellaris MCUs which suffer this PB1 erratum - and benefit from the approach you've ably supplied - exist?  Hope this verbage clearer...

cb1,

There is no readily available listing of the parts that have this erratum.   

The workaround I've suggested is a good alternative for parts that are USB OTG capable and that are affected by this erratum.  Though, the suggested workaround in the erratum is also a viable solution.  After discussing this with our USB software expert, the user can use another GPIO to monitor VBUS to indicate whether the device is connected by adding some extra software calls.  If the GPIO voltage is 0V, make a call to USBDevDisconnect() to remove the USB device from the bus.  If the GPIO voltage is 5V, make a call to USBDevConnect() to reconnect the bus.

-Rebecca

@Rebecca -

Once again, detailed, caring, well explained - thank you - appreciated.  Being able to "mass characterize" affected MCUs should save, "wear/tear" on you/other TI responders.

Rebecca,

I've been working on this problem for some time now. I was originally working with Stellarisware 7611and CCS4, this is where I kept getting the Hard Fault error when connecting the LM3S5C51 prototype board to the pc. With this software combination, I did see the usb_dev_serial example work on the EK-LM3S9B92 board. Note: the 7611 software does not handle the function USBStackModeSet(0, USB_MODE_DEVICE, 0) correctly since it does not check for the presence of a callback function and just assumes that a valid function pointer is provided and jumps on it.

Next, since I was not having any success, I updated the Stellarisware to the latest and greatest, version 9107. Then I tried to make this work with the CCS4 and had all kinds of problems. So I installed CCS5 and was able to rebuild the usb_dev_serial example for the EK-LM3S9B92 board. While trying to download / debug the project, I kept receiving error messages that the part on the EK-LM3S9B92 board had an invalid part number. I think something must have happened to the board during a debug session, because I tried using an IAR setup on the board and it also could not communicate with it over the JTAG connection.

I took the new Stellarisware 9107 version of the usb_dev_serial example and changed the user LED pin mapping since my prototype board also has UART0 free on it, changed the target defines from LM3S9B92 to LM3S5C51 and compiled the project using CCS5. I downloaded it into my board and ran it. When I plug the usb cable into the laptop, I no longer receive the hard fault, but that is all it does, and after a few seconds, a windows message pops up stating that the usb device was not recognized. I tried having windows update the driver, pointing to the Stellarisware/windows_drivers folder, but windows displays a message that it could not find a better driver for the device.

I decided to try another board with the LM3S9B92 part on it, the EVALBOT board. As before, I started with the usb_dev_serial project and changed the LED mapping to one of the LEDs on the board, and also set a port pin to drive the USB HOST / DEVICE mux. I downloaded this project into the board and connected it to the laptop. Nothing happened, windows did not even detect the device. So then I tried using the USBStackModeSet(0, USB_MODE_DEVICE, 0) function with the USB_MODE_FORCE_DEVICE setting since I found the note below describing its purpose.

    //
    //! The application is forcing device mode so that the VBUS and ID pins are
    //! not used or seen by the USB controller.
    //
    USB_MODE_FORCE_DEVICE,

I still had the same results, windows acts like there is not a device connected when using the EVALBOT board, and windows displays "usb device not recognized" on the LM3S5C51 board. Any help that can be provided would be greatly appreciated!

Joe,

Getting USB to work on the EVALBOT is kind of tricky.  If you insert the following code into usb_dev_serial for the LM3S9B92 before the USBBufferInit() calls, the device should enumerate:

//
// Configure MUX for USB device
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_0);
GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_0, GPIO_PIN_0);
//
// Enable the supply for Host or Device mode
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_6);
GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_6, GPIO_PIN_6);

The supply must be enabled for Host or Device mode per the schematics due to how the signals were designed.  You can see this on page 16 and 19 of the User's Manual.  Unfortunately, this makes it so that the EVALBOT is not a good board to test this errata on.

If you use your board, tie PB0 high and have VBUS connected to PB1, just as you would normally.  Do not use the call USB_MODE_FORCE_DEVICE with USBStackModeSet().  This is exactly what you do not want to do.  This parameter will make it so USBStackModeSet() will call USBDevMode() which in turn sets the DEVMOD and DEVMODOTG bits.  This causes the device to encounter the errata.  In the usb_dev_serial example, you should not have to change anything other than pin-outs to LEDs on your board.  This example already uses the call to get around this erratum:

//
// Set the USB stack mode to Device mode with VBUS monitoring.
//
USBStackModeSet(0, USB_MODE_DEVICE, 0);

Try using this example with only GPIO modifications to work on your board.  If you want to cross-reference your schematics with the suggested configuration for PB0 and PB1, please refer to the schematics on page 26 of the DK-LM3S9B96's User's Manual, but connect PB0 directly to 3.3V.

-Rebecca

Rebecca,

Last week, I tried exactly as you described in the previous post with the same unsuccessful results. I still have the USB Device Not Recognized error message from windows. I tried a simple USB sniffer program and I am not seeing any descriptors in the sniffer's log file. Also, If I use the "USBStackModeSet(0, USB_MODE_DEVICE, 0);" function, there is no voltage on the D+ line indicating a full speed device to the host. If I do use the USB_MODE_FORCE_DEVICE, then at least there is voltage on the D+ line. Do you have another dev board that has the same errata that I can test the usb_dev_serial example on?

Joe,

The EK-LM3S9D90 or EK-LM3S9D92 can both be affected by this erratum.

It sounds like VBUS (PB1) is not at 5V.  If it was, the device would be able to enumerate without using USB_MODE_FORCE_DEVICE.  Without forcing device mode, try USB_MODE_DEVICE with your board and measure VBUS (PB1) and the ID (PB0) pins.  Ensure that PB1 is tied directly to 5V and that there is a pull-up to 3.3V on PB0.  Let me know your results.

-Rebecca

Rebecca,

I have PB1 connected to 5V, and PB0 connected to 3.3V. These voltages have been verified at the micros pins with a meter. I do not have 5V connected to the USB device connector. I am using the USB_MODE_DEVICE setting. I am still getting the USB device not recognized message from windows. Below is the D+ and D- traffic recorded with a bus analyzer. I removed some of the empty SOF records. These are the only messages that I see when connecting the USB cable to the PC. Any ideas?

Joe,

We may want to turn to your code for more answers.  We need to find out where the code faults. 

-Can you tell me where in the code the hard fault occurs while stepping through?  

-Additionally, in the CCS debugger, under registers, go to and expand NVIC_FAULT_STAT and let me know which bits are set.

-Rebecca