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.

Sporadic babbling enumeration issue on MSP430F5521

Other Parts Discussed in Thread: MSP430F5521, MSP-TS430PN80USB

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

  • For me, TI USB Stack is just example how things can be done, but it is far from error free and/or perfect solution, that can be used in real products. If you want a real thing (and your target are commercial MSP430 USB devices), make your own USB Stack (like I made mine). Of course, you can try to resolve the problems on TI USB Stack by yourself, or push TI to do it, whatever.

  • Hi Zrno,

    Thanks for the quick response. Personally I would love to rewrite the USB stack especially for the learning experience as I have only started working with MSP430 in the last couple of months (I previously have experience with USB on Cypress FX2, PIC18F and LPC17XX/LPC13XX). Unfortunately it would be very difficult (and counterproductive!) for me to get approval to do this unless I can demonstrate that it will solve our issue; this would require identifying the issue which in turn would allow us to fix the TI stack, saving ourselves significant effort and benefiting the TI community as well. Our product is already released and has passed through V&V, the testing required for our system is not trivial and changing an integral software component of a module would add a significant V&V effort.

    Did you write your own stack because of issues on the TI stack? Did you ever observe the babbling issue whilst developing your stack? Is your stacks source open or available on the internet? If it is either error free or perfect we would certainly pay to use it!

    From analyzing the TI stack and MSP430F5521 datasheet it appears the flow control on the USB link is done in hardware, all the stack does is stuff bytes into the right buffers and set flags indicating data is ready on endpoints. This seems to indicate the problem may be caused by the USB controller in the MSP430F5521 itself. The device also ignores repeated SE0 reset conditions on the USB link, we cannot determine a reason why this would ever happen.

    Cheers,

    Mike

  • My target was CDC/generic bulk, simple, small sized, extremely fast USB stack, and TI solution was far from this. Didn't know much about USB before, so I started from zero. Printed on paper full TI USB Stack source code, inserted lot of logs, and try to figure out line by line, what is going on. Of course, some time was needed for this.

    I don't understand completely (language barrier maybe) how you implemented MSP430F5521, and I worked only with MSP430F5xx USB devices under WinXP. But if you are telling that (sometimes) host is not able to reset device (MSP430F5xx) during enumeration, this is related to stack (software). I hope that you are supplying AVCC/DVCC MSP430F5xx lines from internal LDO (VUSB). During development of my stack I used P1.0 LED for some state indication, and didn't noticed any delays during USB setup, so "USB PLL may not be stabilizing fast enough" is not possible. Don't know on what you think by "flow control on the USB link is done in hardware".

    My USB stack is not open source, but all things about it are published in different topics of 43oh forum.

    http://forum.43oh.com/topic/2775-msp430-usb-benchmark

    AFAIK there is no much MSP430F5xx non-TI open source USB stacks, only from JP Norair.

    http://forum.43oh.com/topic/2775-msp430-usb-benchmark/?p=23478

    http://www.indigresso.com/_blog/?p=33

  • BTW, using debugger with breakpoints for debugging USB can lead to something else and not to source of the problem, because it will disturb USB itself.

    During development of my USB stack, I was using standard logging to text file over MSP430 UART at 1 Mbps, not debugging based on breakpoints.

    Now, (in any project) I am still using logging, but with one extra USB CDC port for this. For example if in my project composite CDC+CDC is used, then if logging is enabled (#ifdef statement) it will be CDC+CDC+CDC, with one extra CDC for debugging. If logging is not needed anymore (final release code), I just disable debugging (#ifdef statement), and all debugging code will disappear, together with extra CDC port.

  • Hi Zrno,

    I will bare that in mind as a potential solution but I don't think I will be able to get the time necessary for it :(

    I will try to clarify our hardware arrangement:

    In our system the MSP430 is powered from a system power supply not the USB bus. Only the D+,D- and GND lines connect from the hub to the MSP430.

    There is no cable in the system, the signals are carried by tracks on a PCB.

    We do not supply the AVCC/DVCC from the internal LDO, we power them from a TLV1117-3.3 LDO. Are there known issues with not powering the MSP430 from it's internal LDO?

    VUSB is connected to ground via a 220nf capacitor, VBUS is connected to our systems 5v supply.

    VBUS is connected to the systems 5V supply.

    To clarify "flow control on the USB link is done in hardware":

    The signals which are sent over D+ and D- data lines are controlled by the USB Serial Interface Engine, the software only chooses the length of data and whether or not to respond to a command i.e. the software will either put a packet into the packet buffer and signal the data is ready to be sent to the USIE or set a stall condition on the end point.


    The problem we see is that there is constantly data being transmitted by the MSP430 on the D+ and D- lines, it never stops. I do not believe it is possible to make the USIE transmit an infinitely long packet by software which leads me to believe we may be experiencing a bug in the USIE.

    Once the MSP430 starts sending the infinite repetition of data onto the D+ and D- lines it does not detect reset conditions (SE0 on the bus, D+ and D- pulled down by hub) so a USB reset will not recover the device. To clarify, a reset condition on the USB bus does not result in the reset ISR being called.

    Yeah I realized it is not possible to debug USB via breakpoints, it is part of the reason embedded software is so much "fun" :P

    We used a logic analyzer and some spare IOs to log the state of the USB state machine when the error occurred and found it was either in the ST_NO_ENUM or the ST_ENUM_SUSPENDED states.


    I really like your approach to debugging by making your device a composite CDC device, I will remember it for the future!

    Thanks for your help!

    Cheers,

    Mike

  • Michael Shaw said:

    We do not supply the AVCC/DVCC from the internal LDO, we power them from a TLV1117-3.3 LDO. Are there known issues with not powering the MSP430 from it's internal LDO?

    VUSB is connected to ground via a 220nf capacitor, VBUS is connected to our systems 5v supply.

    VBUS is connected to the systems 5V supply.

    Don't see any problem in using VBUS connected to system 5V supply. It is better choice to use internal 3.3V LDO for MSP430 and not dedicated external 3.3V LDO. It can be somehow better syncronization on start up sequence between MSP430 and USB module. Don't think that this is source of your problem, but I am using internal LDO also for other things, not only for MSP430 AVCC/DVCC lines.

    Michael Shaw said:

    The problem we see is that there is constantly data being transmitted by the MSP430 on the D+ and D- lines, it never stops. I do not believe it is possible to make the USIE transmit an infinitely long packet by software which leads me to believe we may be experiencing a bug in the USIE.

    Once the MSP430 starts sending the infinite repetition of data onto the D+ and D- lines it does not detect reset conditions (SE0 on the bus, D+ and D- pulled down by hub) so a USB reset will not recover the device. To clarify, a reset condition on the USB bus does not result in the reset ISR being called.

    I done a lot of heavy USB benchmarks on similar chip (MSP430F550x), and didn't find (till now) any strange behavior. If data are coming constantly without any reason, I will search for problems in software, because don't see the way how hardware can reach this locked state. Only USB reset state with MSP430 that I know is coming over ISR (setup packet over endpoint 0).

    Michael Shaw said:

    We used a logic analyzer and some spare IOs to log the state of the USB state machine when the error occurred and found it was either in the ST_NO_ENUM or the ST_ENUM_SUSPENDED states.

    As I mention before, jpnorair done some job on debugging original TI USB stack, so maybe his (open source) version can be useful to you

    http://forum.43oh.com/topic/3112-msp430f5510-usb-how-well-does-it-work/?p=26857

    http://forum.43oh.com/topic/2039-msp430-with-usb-support/?p=23132

  • Hi Mike,

    we are contacted by our distributor about your question. Have you found something else in the meantime?

    One question from myside: 

    - are you using the latest MSP430USBDEVPACK stack (v3.20.02)?

    - Is there anyway to reproduce the issue with our development kit?

  • Hi Leo,

    As explained above we have recreated the situation on the msp-ts430pn80usb development board.

    If you let me know where to send it I have code that will cause the problem although bear in mind it may take many iterations before the problem will be seen, it appears to happen approximately every 200 system boots but individual systems have reached in excess of 600 boots without seeing the problem.

    I updated our code to use the latest stack and we still see the problem.

    Other findings include that neither sleep states nor PLL settings seem to affect the frequency of the problem.

    Cheers,

    Mike

  • Mike,

    i just called one of your colleague, and let's take it offline at the moment.

  • Leo, Mike,

    This is a known bug that has yet to be documented in the errata sheet. This will soon reach the errata sheet but I will give a description and workaround here for you.

    Description:

    When the host sends a SETUP packet for an IN transaction, the SETUPIFG bit should always get set by hardware, and the USB ISR is triggered. While SETUPIFG is high, the host's attempts to continue the transaction with IN packets are automatically NAKed.

    When the SETUP packet has been decoded and the IN data prepared, the USB ISR should clear the SETUPIFG bit. But if it happens to do so within the 2nd CRC bit of an IN packet from the host, the USB module enters an errant state and can begin to "babble" (endless transmission to the host, irrespective of the protocol). The errant state can be cleared by resetting the module with the USB_EN bit; but there's no way for software to reliably detect the condition.

    Since the 2nd CRC bit is only an 83ns window, the problem is extremely rare. However, since the timing of IN packets relative to their preceding SETUP packets can vary according to the host's timing, there's no way to ensure for certain that it will never happen.

    Workaround:

    Clear the UBME bit immediately before clearing SETUPIFG, and set it again immediately after
    <code>
    USBIEPCNF_0 &= ~EPCNF_UBME; // Clear ME to gate off SETUPIFG clear event
    USBOEPCNF_0 &= ~EPCNF_UBME; // Clear ME to gate off SETUPIFG clear event
    USBIFG &= ~SETUPIFG; // clear the interrupt bit
    USBIEPCNF_0 |= EPCNF_UBME; // Set ME to continue with normal operation
    USBOEPCNF_0 |= EPCNF_UBME; // Set ME to continue with normal operation
    </code>

**Attention** This is a public forum