• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 81 subscribers
  • Views 2295 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5510 USB CDC not enumerated (at all?/correctly?) in rare cases

Hendrik van den Boogaard
Prodigy 220 points
Other Parts Discussed in Thread: MSP430F5510

I recently ran a project that is largely based on one of the CDC examples of the (latest) MSP430 USB stack. Although in the absolute majority of cases the device works fine, there is one exceptions that occurs very rarely:

If a PC with one of our devices starts up, the device does not always enumerate properly. The device manager then shows that there is a USB device but it only shows as 'unknown device'. In most cases (I guess 99%+) the device is listed as serial port and works fine.

I tried multiple computers, multiple of our boards and Windows 7 and 8 but the result is the same although some PC's seem to exhibit the problem a bit more often (still it hardly ever happens).

You can make the problem go away by unplugging our device and plugging it back in, or by restarting the computer. I guess both cases could have the problem to re-appear, but as it is so rare I have never seen it fail twice in a row. And also because rebooting the computer (when the device had not been found) is easy to test by some scripts, this was the way to go. Still it takes hours (sometimes days) of continuous rebooting for the problem to appear on our test devices, but at our customer it happens more frequently and that is a problem for them.

First I thought that the MSP430 might have ended up in 'ST_PHYS_CONNECTED_NOENUM_SUSP' as I could end up there by connecting the USB connector loosely to the USB port. Probably just enough for the USB device to be detected by the host but not to enumerate it properly. I added some blinking LEDs when it had ended up there but after 2 more days of rebooting the reboot process had stopped but the device was not in that state.

Unfortunately I have never seen it fail with a debugger attached and connecting the debugger when the failure had occurred, made the MSP430 reset so I really have no idea where it ends up and the stack is also mostly event driven so there is a chance that the MSP430 is in LPM anyway leaving me even more clueless. When the device is detected and enumerated correctly it seems to work just fine (at least for as long as we have tested this).

Does anyone have any idea what else to look for? Could it be a hardware error or something in the stack?

  • 0
    TI__Expert 6760 points

    Hello,

    Have you checked the MSP430F5510 errata, slaz301j.pdf?  Especially USB9?  Since you do not mention the version of the USB stack you are using or device hardware and powering source, the errta might help with soloving your issue.

    Regards,

    Arthi Bhat

  • 0 in reply to Arthi Bhat1
    Prodigy 220 points

    I am using the latest available version. I think it is v4.10.01 (06-19-2014) as I downloaded a couple of months ago just before development began.

    I checked the errata for USB problems but I don't always understand the full scope of the errata description because I don't have a real in-depth knowledge of all registers and stuff that is going on. My bad I know but fast development was of the essence. Therefore I used one of the complete CDC examples as basis (together with the MSP430 driverlib). I also took most of the hardware design from the development board schematics and the Olimex MSP430F5510 board. My application only gets active inside the ST_ENUM_ACTIVE case (except for some initializing).

    The USB9 error should have a work-around in the USB stack later than 3.10  and I use a separate LDO voltage regulator directly on the USB 5V line so it is self powered. This regulator powers some side-hardware and the MSP430. I don't use the USB LDO inside the MSP430 to power the MSP. So the circumstances for USB9 don't seem to match.

    It would probably help if I could sniff the USB bus, and also check what's going on inside the MSP430 but the problem only occurs so sporadically that you don't want to keep an eye on it all the time. Also; the easiest work-around is to simply reboot the host, but that sounds more like avoiding the problem than tracking/solving it.

    EDIT: maybe it is also a good idea to run the repetitive reboot-test on one of the examples. If that one fails, it cannot be in my own code, but then it must be my hardware/PCB or the TI stack.

  • 0 in reply to Hendrik van den Boogaard
    Prodigy 220 points

    Unfortunately I am still seeing this problem. I am logging the USB states to ROM that are cycled through during the USB life cycle. States that are often visited are ST_USB_ENUM_ACTIVE, ST_USB_ENUM_SUSPENDED and ST_USB_ENUM_IN_PROGRESS. Every now and then also ST_USB_ERROR occurs. I don't know why it is in the list of saved states but the device generally works ok so it seems some intermediate state.

    BUT: a couple of minutes ago a continuously rebooting Windows 7 machine ended up with an Unknown Device in the device manager. Rebooting did not resolve the issue anymore, the MSP430 never came back as CDC device but was always listed as Unknown Device. Only turning the machine off resolved the problem. Apparently USB power is never interrupted when rebooting this particular machine.

    After powering down and up again, the states list now tells me that the device has ended up in SYSUNIV_BUSIFG. The USB API has some comments about a possible cause when the CPU access USB memory while the USB module is suspended. Interestingly the previous state in our case is ST_ENUM_ACTIVE and not some suspended state.

    ALSO: to overcome this state my code is modified to:

    case SYSUNIV_BUSIFG:
    SYSBERRIV = 0;
    USB_disable();
    sleep(50);
    PMMCTL0 = PMMSWBOR|PMMPW ; // Forces reboot

    Those last 2 lines should pause a bit and then force the MSP430 to restart (which should result in the complete USB connect procedure) But the MSP430 does not seem to have rebooted at all as there are no states indicating that it went through the complete init procedure.

    Does anyone have any idea why this problem occurs? And perhaps a way to overcome it? For our needs it is really problematic if user intervention is needed to get everything up and running.

  • 0 in reply to Hendrik van den Boogaard
    Guru 318740 points

    In Linux, it is possible to reenumerate a USB device. It is also possible to cut power to a device if you have a hub that supports this.

    It is hard to trace what's going just with the ST_USB_xxx values. You should let the host log all activity on the bus (this is easy with Linux; don't ask me about Windows).

    BUSIFG indicates that the USB PLL was disabled; in theory, this happens only in response to SUSRIFG. Can you check if this interrupt happend (but ST_(NO)ENUM_SUSPENDED was not set)?
    Alternatively, the USB PLL not running could indicate a problem with the XT2 crystal.

  • 0 in reply to Hendrik van den Boogaard
    Genius 4680 points

    Sound like a problem on slow DVCC ramp, addressed on the errata USB9.

    MSP430F4410 Device Erratasheet
    www.ti.com/.../slaz301m.pdf

    USB9: VBUS detection may fail after powerup
    The bandgap failure is also known to occur more often with slow DVCC ramps > 200 ms; for example, when there is excessive capacitance on the DVCC pin, in excess of what the USB specification allows.


    The errata refers to the on-chip LDO, but the problem should also occur on your external LDO, because the on-chip bandgap reference is powered by DVCC.

    1) As of a workaround, insert a self-powered USB hub (ie. a hub powered by a wall-mount adapter) between your device and the PC. A self-powered USB hub keeps VBUS supply to your device, while PC shuts down / reboots.

    2) Check the value of the capacitor after your external LDO, and also  the current limit of the LDO. When the current limit is relatively lower than the in-rush caused by the capacitor, slow DVCC ramp should occur. Tune the capacitor value or the LDO current limit.

    Tsuneo

  • 0 in reply to Tsuneo Chinzei
    Prodigy 220 points
    @Clemens: there is a case in usbEventHandling.c (uint8_t USB_handleClockEvent () -- 'If this function gets executed, it's a sign that the output of the USB PLL has failed'). I added another 'save point' in code if we get there, but thus far this save point has not been hit while the handler for 'BUSIFG' has. Furthermore I am not sure if I can find out what happens on the USB bus as this problem only seems to occur when the computer is booting and the device is iterated. At least that is something that I can automate quite easily by auto rebooting the machine. I once tried to unplug/replug a lot of times to see if I could get the same behaviour but that did not work (or I did not try for long enough). In the end the most important this is that the device should 'always' work in a non-user-operated environment. Maybe there is another reason for BUSIFG to occur? I can's seem to find a lot of information about it.

    @Tsuneo: I will try with a powered USB hub and see if that changes anything but it seems a bit unlikely as this particular test computer does not take the power off of the USB bus when rebooting (it's a Shuttle DS437). In my 'state log' I can see a whole list of 'enumerating in progress', 'suspended' and 'enumerated' states. The startup sequence when powering on and before entering the actual USB states is also logged but not listed in the device after it hangs and I restart it. Furthermore I wait for a short while when powering up before I run USB_Init so there is time for everything to settle. The device is powered by USB with a separate LDO on the PCB, so when the MSP430 starts it seems likely that there VCC is already high enough to start the MSP.

    Will keep you posted but thus far it does not really look good.
  • 0 in reply to Hendrik van den Boogaard
    Prodigy 220 points

    @Tsuneo: unfortunately the device also stopped working when on a powered USB HUB, so that does not change things. I think the only option left is to test if the problem also occurs on the default TI CDC example :(.

**Attention** This is a public forum