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.

MSP430F6638 USB enumeration issue

Other Parts Discussed in Thread: MSP430F6638, MSP-TS430PN80USB, MSP430F5529, MSP430F5528, MSP430F5636

I have been trying to fix an enumeration issue for a few days now...without any luck. I am using a MSP430F6638 Rev A MCU with MSP-TS430PZ100USB target board. My board came installed with a 4 Mhz crystal for XT2 (the case of the crystal reads FT4.000)...although I cant seem to see that frequency on the scope.

I downloaded the latest USB developer package and am trying to run both the CDC and HID examples included in the package. First, I try CDC mode...I follow the directions and make the descriptor files and the inf file using the tool making sure I input correct VID/PID values...I check the self powered button because I am powering the device from the JTAG connector and not USB and finally I input 25 Mhz for MCLK frequency and 4 Mhz for XT2 frequency. I then overwrite the descriptor files in the config folder of each example with the newly created ones. Before running the first CDC example, I make sure to change the CCS build to the write microprocessor. Then I build and run.

The first time I ran this, the program would just run without windows seeing a USB connection. So, I went into the code step by step and found out that the program was getting stuck in a while loop that tries to clear the OFIFG fault flags in the init_FLL function of the HAL_UCS.c file. When I watch the registers, I can see that apparently the XT1LFOFFG flag never goes 0...I suppose this flag is what keeps the program in that loop forever. But its strange because I have not XT1 crystal connected to the board and the USB module doesn't even need the XT1 crystal...and I can tell by UCSCTL6 that this program tries to drive both the XT2 and XT1 for some reason.

Anyway, so next, I just comment out the while loop that tries to clear these flags in the HAL_UCS.c file and then run the program. This time, the program execution makes it through to the USB initialization code. Now, I see windows pop up an unrecognized USB device prompt. I click update drivers and point it to the folder with the inf file. But strangely, windows seems to reject the driver...it doesn't install it and says that windows has determined there is already a better driver installed. I even tried to point it to the exact file but it says windows did not find a compatible driver and fails. So, enumeration fails and the program hangs on the USB_handleVbusOnEvent function.

I tried to verify that my XT2 crystal is working by running the MSP430F66xx_UCS_08.c file in the MSP430F6638 code examples. During step by step execution, I see the XT2OFFG flag go on during  UCSCTL6 &= ~XT2OFF. But then there is a loop that tries to clear the OFFG flags...and this time the loop is successful...all flags are cleared and the program continues past the loop. So, I guess I can assume my XT2 crystal is working.

I have no idea why I cannot get the device to successfully enumerate. I even tried this with HID examples (with the proper procedure in using the descriptor tool to generate HID descriptors) but it still doesn't enumerate. Could someone please help me diagnose this problem? Its driving me insane! Thanks!

 

  • Hi Krutarth,

    > I am using a MSP430F6638 Rev A MCU with MSP-TS430PZ100USB target board.

    I'm going to order MSP-TS430PZ100USB target board today. Then, your pain will be mine, too.

    1) Jumpers
    This board is very similar to MSP-TS430PN80USB target board, except for the ZIF socket size. On MSP-TS430PN80USB board, I run USB examples on MSP430F5529 with this jumper settings successfully. The functions and numbering of jumpers are the same as those of MSP-TS430PZ100USB board.

    With debug adaptor,
    JP3: 1-2 (int-Vcc)
    JP4: OFF

    For stand alone,
    JP3: 3-2 (ext-Vcc)
    JP4: ON


    2) Silicon revision
    Try it with a newer revision chip.

    According to the errata, Rev A silicon of MSP430F6638 has a couple of silicon bugs on USB PLL. It may be the cause of your trouble.

    MSP430F663x, MSP430F563x Device Erratasheet
    http://focus.ti.com/lit/er/slaz060e/slaz060e.pdf
    - USB7: USB PLL may fail to initialize when XT1 is not used
    - USB8: USB PLL may fail to initialize when DCO is not used

    I had USB troubles on rev A silicon of MSP430F5529, attached to the MSP-TS430PN80USB target board. In this case, the troubles had disappeared when the chip was replaced with rev E.

    Tsuneo

  • Wow...I would never have thought in a million years that the chip would be an issue! Thanks for pointing that out. I had concluded that the problem was in the driver file and I was about to learn how to write a .inf file so I could write my own. I will get try to get a newer version of this chip asap! I'll update this post as soon as I try it out.

  • Just wanted to leave an update on this. Yes...the problem is the absence of the XT1 crystal...so the errata sheet is correct. When I connect an external clock for XT1, it enumerates just fine. We just received a Rev B MCU, which according to the errata sheet should have this issue fixed...but apparently it does not...I have the same problem with Rev B...if XT1 is not there, no enumeration. So, we gave up and finally ended up ordering 32 kHz crystals and installed one on the board.

  • Where did You find MSP430F6638 rev. B ? I have only XMS430F6638 Rev. A received as sample. Has Texas Instruments started the production of MSP430F6638 ?

  • I just solved a similar problem with an MSP430F5528 running on TI's MSP-TS430RGC64USB board.

    The USB stack initialization hangs in the XT2_Start function in HAL_UCS.c

    I noticed that the USB stack is setting the XT2DRIVE bits to value 3 when the datasheet suggests they should be 0. I fixed that in the stack code and the board enumerated.

    Hope that helps!

  • Good for you. I didn't have that issue since I believe they updated it when I checked. BUT I did find something strange in the MSP430 USB Descriptor Tool (3.0.10). Not sure if there is a newer one but when the Self-Powered is checked it produces the code 0xc0 instead of 0x40 in the descriptor.h output file. This had caused me about an entire day of work and headache trying to figure out why windows would see it but will not load the outputted .inf file for it.

  • I don't think 0xC0 vs 0x40 would make a difference. The usb 2.0 spec says MSB of bmAttributes is reserved and must be set to 1. That makes 0x40 into 0xC0

  • I am having enumeration problems also. Where did you find the suggestion the XT2DRIVE be set to 0?

  • > Where did you find the suggestion the XT2DRIVE be set to 0?

    The crystal frequency falls in the frequency range specified for each XT2DRIVE value.
    Refer to the XT2DRIVE bits on UCSCTL6 register on the MSP430 User's Guide.

    MSP430x5xx/MSP430x6xx Family User's Guide (Rev. I)
    http://www.ti.com/litv/pdf/slau208i

    Unified Clock System Control 6 Register (UCSCTL6) - p108
    XT2DRIVE
    00 Lowest current consumption. XT2 oscillator operating range is 4 MHz to 8 MHz.
    01 Increased drive strength XT2 oscillator. XT2 oscillator operating range is 8 MHz to 16 MHz.
    10 Increased drive capability XT2 oscillator. XT2 oscillator operating range is 16 MHz to 24 MHz.
    11 Maximum drive capability and maximum current consumption for both XT2 oscillator. XT2 oscillator operating range is 24 MHz to 32 MHz.


    On the USB example code, XT2DRIVE value is given in this line.

    xx_Example\USB_API\USB_Common\usb.c
    BYTE USB_enable()
    {
        ...
        XT2_Start(XT2DRIVE_3);    // <--- XT2DRIVE_0


    Tsuneo

  • Dan,

    It's in the 5xx 6xx Family User Guide, page 105 of slau208h (UCSCTL6). Proof of the pudding is in the eating!

    The TI Stack value of 11 for bits 15-14 corresponds to a 24-32 MHz crystal, and 00 corresponds to 4-8MHz. When I changed the bits to 00 (to match the 4MHz crystal on the TI board) everything worked. With the bits set at 11 (per the unmodified stack) the CPU hangs waiting for the crystal to start. That was with the MSP430F552x which was supplied with the TI socket module board. The fix has worked fine on my own boards also.

    This is my 4th attempt at posting this message, apparently the TI website doesn't like IE9!

    - Neil.

    p.s. Check out Tag-Connect's great debug cables for MSP430 and SPY-BI-WIRE! See www.Tag-Connect.com

     

     

     

     

  • ahhh I didn't catch you were using 4Mhz XT2. I'm using 24Mhz so obviously that was not the issue. Turns out USB8 from the errata was my issue. Seems like the errata seems to be getting alot of people in this family

  • Hi,

    I am having the same enumeration issue. The code works perfectly fine on the target board, but does not work on the new PCB I designed. The only difference between the two boards is that the MSP is powered externally on my PCB, while the target board is powered through Vusb. 

    When I connect my PCB via USB, it detects the presence of a device, but it shows up as "unknown device". I fixed the XT2_DRIVE issue explained above, but it didnt help. Any feedback would be really helpful!

    P.S. I am using Rev D of the MSP430F5636.

    Thanks,

  • You need to be more specific. There are alot of things that can go wrong with enumeration.

    Does your pcb connect to the usb VBUS and have its own DVCC supply?

    Are you connecting to Windows? Linux?

    Are you using CDC example? HID example?

  • 1. My PCB has its own DVCC supply. It does not draw power from VBUS.

    2. I am connecting to Windows 

    3. Using CDC example_06. 

    The only difference between PCB and the TI target board is that the MSP is powered externally on the PCB, while the MSP on the target board derives power from VBUS.

**Attention** This is a public forum