• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 1690 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.

USB_init() results in UNMI on MSP430F5510

TonyKao
Genius 3770 points

Other Parts Discussed in Thread: MSP430WARE, MSP430F5510

Hi all,

 

While experimenting with the MSP430 USB stack v3.11, the following code in USB_init() from usb.c results in a UNMI:

    //configuration of USB module
    USBKEYPID   =     0x9628;    //set KEY and PID to 0x9628 -> access to
                                 //configuration registers enabled
    /* To fix USB9 enumeration issue seen by Matrox*/
    USBPWRCTL = 0;

When the last line is executed, the code branches to 0xFFFA and resets.

Interestingly, in the previous version of the stack as included with MSP430ware, the last line is not present. When I test the code sans the line, the device enumerates properly.

Am I missing something here?

 

Tony

 

[Edit: it just occurred to me that setting USBPWRCTL to 0 also disables the 3.3V LDO, which I'm using to power the rest of the MSP430F5510. So obviously an NMI would occur. Is this a bug then, or are we supposed to just not use the LDO to bus-power the MSP430?]

  • 0
    Prodigy 10 points

    Yes, I ran into the same problem.

    had everything working on the 5529 Eval board (which is not bus powered).

    Migrated to our own board that uses a F5510 and bus powered.  Turning off the 3.3V LDO not good!

    This should be commented of #ifdef'ed in the USB stack code.  Would appreciate an explanation from TI about why this was done in the first place and is there a side effect of commenting out that line  completely?

    Thanks,

    Daraius

  • 0 in reply to Daraius Hathiram
    Prodigy 10 points

    This issue bit me as well.

  • 0 in reply to Jon Bertrand
    Guru 15580 points

    This issue caused me 3 days of debugging a known good piece of hardware. Shame you you TI!

  • 0 in reply to MikeH
    Guru 25210 points

    MikeH said:

    This issue caused me 3 days of debugging a known good piece of hardware. Shame you you TI!

    As frustrating as it is to find bugs in third-party libraries, I think that's harsh. You've never written a bug before?

    Besides that, the libraries are free. I think you're getting your money's worth anyway.

  • 0 in reply to Brian Boorman
    Guru 15580 points

    Brian,

    Brian Boorman said:
    You've never written a bug before?

    No. Never.

  • 0 in reply to Daraius Hathiram
    TI__Guru* 83901 points

    Daraius Hathiram said:
    Would appreciate an explanation from TI about why this was done in the first place and is there a side effect of commenting out that line  completely?

    Hi all,

    This line of code was added to workaround the USB9 erratum (you can see USB9 mentioned in the comments of the code). You can see the USB9 erratum in the document here: www.ti.com/lit/pdf/slaz314

    USB9 erratum text said:

    USB9 USB Module

    Function VBUS detection may fail after powerup

    Description In rare cases, some USB-equipped MSP430 devices may experience a failure in the bandgap that aids in detecting the presence of 5 V on the VBUS pin. Two primary effects of this are:

    - The USBBGVBV bit fails to show the presence of a valid voltage on the VBUS pin.

    and

    - The USB LDOs fail to start.

    Workaround This error state can be "reset" by clearing all of the bits in the USBPWRCTL register, which disables the USB LDOs, among other actions. The bits can then be set again normally, and the device functions properly.

    This has been added to the USB_Init() function in v3.10 and later of the MSP430 USB API. Therefore, this problem is automatically addressed in applications that use the API.

    However, if the integrated 3.3-V USB LDO (the output of the VUSB pin) is used to power the device's DVCC pin, as in many bus-powered applications, and if the rare bandgap error occurs, the CPU fails to power up, because the USB LDO fails to operate. The problem might be resolved by cycling power to the VBUS pin; for example, if the end user responds to the failure by unplugging and replugging the USB cable. 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. However, the only sure way to prevent the problem from occurring in the first place is to avoid making DVCC power reliant on VUSB.

    This line of code was added to workaround the USB9 erratum on parts that use the LDO but do not power their entire device from it. However, you are right - the way the stack is written right now it will cause a problem (regardless of USB9 occurring) if you are powering your whole part from the LDO. So this needs to be reworked so that in the descriptor tool you can not only indicate that you are using the LDO, but indicate that the LDO is actually what's powering your board. This way the code could be modified so that the workaround is only done if you've indicated that you aren't powering your board off of the LDO.

    Daraius Hathiram said:
    is there a side effect of commenting out that line  completely?

    USB9 is something you will run the risk of if you are using the LDO and have an affected revision of the part (for example on F5529 USB9 has been fixed in Rev. H and newer). However, the line in question only fixes the problem if you are using the LDO but powering the device some other way (because if you were powering the whole board from the LDO your device wouldn't start at all and could never even execute this workaround code). So if you are powering the whole part off of the LDO, commenting that line out shouldn't add any additional risk - you just already have the risk of USB9 on affected revisions (without any software workaround)

    I've notified those who maintain our USB stack so that this will be fixed as soon as possible. Fortunately we have a release scheduled very soon, and they are now working to incorporate this fix into the release. I'm really sorry for all of the trouble and frustration this has caused, and I want to thank you for raising the issue to our attention.

    Regards,

    Katie

    P.S. Thank you so much MikeH, for linking to this post and bringing it to my attention so that we can get this fixed.

**Attention** This is a public forum