Hi Folks,
Been reading these forums for a while and found they have resolved 95% of our issues without having to make a post, thanks :)
Unfortunately now we have run into a problem which doesn't appear to be documented anywhere in the forums or errata, we would greatly appreciate any help in figuring out our current issue.
We have a module within one of our products that uses an MSP430F5521 to communicate via USB with a single board computer module. The connection between the SBC and the MSP430F5521 is tracked on a PCB instead of a cable. On the SBC we are running Ubuntu 11.04 (kernel 2.6.38-8-generic). The module uses the HID device class. The module is connected behind a USB 2.0 hub.
We have discovered during testing that approximately one in every 250 reboots our module will fail to enumerate with the linux kernel. It was found that the MSP430F5521 either needs to have it's USB disconnected and reconnected or to be power cycled in order to recover the situation, resetting the hub and re enumerating devices has no effect. During the process of testing the modules firmware has been updated to use the latest TI stack but the problem still remains. The problem was also recreated using a MSP430-PN80USB development board and a stripped out version of our firmware which just implements our USB interface without running any of our application code which makes us relatively confident it is not a specific issue to our hardware or firmware. The latest version of the firmware which still shows issues also has all the sleep states stripped out and USB_DISABLE_XT_SUSPEND set to 0 in descriptors.h as we suspected the USB PLL may not be stabilizing fast enough.
We tried inserting a 15s delay before the MSP430 brings up it's USB interface and found that this decreased the frequency of problems. It was noticed when attempting this that it caused the USB bus on the system to enumerate in a different manner. When there is no delay all the devices in the system enumerate at ~12s with very little delat between them (~10ms), the module enumerates first. When the delay is present the other USB devices enumerate at ~3s and then the module comes up at ~12s, as if the module having it's USB interface initialized causes the system to wait ~10s. This leads us to suspect the SBCs BIOS may be trying to enumerate the device and getting stuck.
We scoured the TI USB stack and MSP430F5521 documentation and as far as we can see the arbitration on the USB bus is carried out fully in hardware, could somebody correct us if we are wrong about this?
Attaching the debugger to a failed unit revealed it was perpetually in the ST_NO_ENUM state. Failed units have also been observed in the ST_ENUM_SUSPENDED state. It has been observed that when the units fail there appears to be constant USB traffic being sent out by the MSP430F5521 and that it ignores SE0 reset signals on the USB bus (These can be seen superimposed on the babble being emitted by the MSP430).
The messages emitted by dmesg of a failure are:
[ 4.247822] usb 2-1.5: new full speed USB device using ehci_hcd and address 5
[ 4.339719] usb 2-1.5: ep0 maxpacket = 8
[ 4.342350] usb 2-1.5: skipped 1 descriptor after interface
[ 4.342723] usb 2-1.5: default language 0x0409
[ 4.346226] usb 2-1.5: udev 5, busnum 2, minor = 132
[ 4.346231] usb 2-1.5: New USB device found, idVendor=XXXX, idProduct=XXXX
[ 4.346236] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4.346241] usb 2-1.5: Product: MSP430-USB Example
[ 4.346245] usb 2-1.5: Manufacturer: Texas Instruments
[ 4.346401] usb 2-1.5: usb_probe_device
[ 4.346405] usb 2-1.5: configuration #1 chosen from 1 choice
[ 4.346607] usb 2-1.5: can't set config #1, error -32
[ 4.510727] usb 2-1.5: USB disconnect, address 5
[ 4.510731] usb 2-1.5: unregistering device
[ 4.510736] usb 2-1.5: usb_disable_device nuking all URBs
[ 4.608496] hub 2-1.8:1.0: port 3: status 0101 change 0001
[ 4.635871] hub 2-1:1.0: debounce: port 5: total 100ms stable 100ms status 0x101
[ 4.651869] hub 2-1:1.0: port 5 not reset yet, waiting 10ms
[ 4.667868] hub 2-1:1.0: port 5 not reset yet, waiting 10ms
[ 4.683869] hub 2-1:1.0: port 5 not reset yet, waiting 200ms
[ 4.707777] usb 2-1.8: link qh128-0e01/d389de80 start 3 [1/2 us]
[ 4.887869] hub 2-1:1.0: port 5 not reset yet, waiting 200ms
[ 5.095892] hub 2-1:1.0: port 5 not reset yet, waiting 200ms
[ 5.095896] hub 2-1:1.0: port_wait_reset: err = -16
[ 5.095898] hub 2-1:1.0: port 5 not enabled, trying reset again...
[ 5.299936] hub 2-1:1.0: port 5 not reset yet, waiting 200ms
[ 5.503928] hub 2-1:1.0: port 5 not reset yet, waiting 200ms
[ 5.707996] hub 2-1:1.0: port 5 not reset yet, waiting 200ms
[ 5.708004] hub 2-1:1.0: port_wait_reset: err = -16
As of yet we have not used a USB protocol analyzer, we do not have one available and are currently trying to convince the rest of the team that it is essential to catch the cause of this issue.
I have a pile of dmesg logs and a copy of firmware which showed the problem on the MSP430-PN80USB. I can also provide oscilloscope traces of the babble being emitted by the MSP430F5521 but it appears to be different repeating pattern on each occurrence.
Any help towards resolving this issue would be greatly appreciated.
Cheers,
Mike