• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 1757 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F5522 USB and SMCLK with XT2

Simon Santesteban
Prodigy 20 points
Other Parts Discussed in Thread: MSP430F5522

I am using msp430f5522 usb module, together with smclk output on pin P2.2/TA2CLK/SMCLK.

I am using XT2 to drive both smclk and mclk.

I have tried this configuration in some sample prototypes, and usb is not working in 2/3 of them. No usb interrupts are generated.

However, if I don't set SELS_5 in UCSCTL4, this configuration works in all the prototypes.

P2DIR |= BIT2; // SMCLK set out to pins

P2SEL |= BIT2;

P5SEL |= BIT2+BIT3; // Port select XT2

SetVcoreUp (0x01);

SetVcoreUp (0x02);

SetVcoreUp (0x03);

UCSCTL6 &= ~XT2OFF; // Enable XT2

UCSCTL3 |= SELREF_2; // FLLref = REFO

// Since LFXT1 is not used,

// sourcing FLL with LFXT1 can cause

// XT1OFFG flag to set

UCSCTL4 |= SELA_2; // ACLK=REFO,SMCLK=DCO,MCLK=DCO

// Loop until XT1,XT2 & DCO stabilizes - in this case loop until XT2 settles

do

{

UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);

// Clear XT2,XT1,DCO fault flags

SFRIFG1 &= ~OFIFG; // Clear fault flags

}while (SFRIFG1&OFIFG); // Test oscillator fault flag

UCSCTL4 |= SELS_5 + SELM_5; // SMCLK=MCLK=XT2

UCSCTL8 |= SMCLKREQEN;

Do you know what am I doing wrong?

  • 0
    Guru 227245 points

    Simon Santesteban said:
    UCSCTL4 |= SELA_2; // ACLK=REFO,SMCLK=DCO,MCLK=DCO

    Well, no, DCODIV, not DCO. The default config (which you keep here) is DCODIV (= DCO/2).

    Simon Santesteban said:
    UCSCTL4 |= SELS_5 + SELM_5; // SMCLK=MCLK=XT2

    Since the default config is SELS_4, this only coincidentally works as expected. If SELS_2 were set before, this would result in SELS_7 (same for SELM). It's dangerous to |= bitfields and it is dangerous as well to arithmetically add (+) bit values, especially for bitfields or bit combinations.

    However, none of this is related to your problem. Especially if the code works on some but not all prototypes.
    I suspect a hardware problem. Wrong load capacitors for the XT2 crystal, maybe the crystal is a overtone type but swings on ground tone in your hardware (which the MSP won't notice, as it doesn't know what frequency to expect).

    But then, the USB module IMHO doesn't run on SMCLK but on XT2 directly, so its proper operation should be unaffected by the current SELM setting at all.

  • 0 in reply to Jens-Michael Gross
    Prodigy 20 points

    Thank you very much for your tips.

    I have tried changing the crystal capacitors, but still not working.

    My configuration uses a 24MHz crystal rated 10pF. I have tried with 12 and also with 20 pF capacitors, which according to my calculations are in the appropriate range.

    (x+2)/2 + 1 = 10pF    =>  x = 16 pF

    For the time being I will be using the FLL to drive the MCU at 24 MHz, which does not affect the USB connectivity.

    I am also using an external 3.3V regulator to drive VUSB, leaving VBUS unconnected,and configuring

          USBPWRCTL   =     SLDOEN;             // enable secondary LDO (1.8 V)

    which I think is ok.

    Simon

  • 0 in reply to Simon Santesteban
    Guru 227245 points

    Simon Santesteban said:
    For the time being I will be using the FLL to drive the MCU at 24 MHz, which does not affect the USB connectivity.

    Indeed. MCLK etc are independent of the USB. The USB part is directly sourced by the crystal and requires the proper PLL multiplicator setting to get 48MHz.
    The usual setups uses a 4MHz crystal. Because >16MHz, you'll usually get overtone crystals which are difficult to handle, or they will swing on basetone (usually 1/3 = 8MHz). Basetone 24MHz are seldom and more expensive.

    Simon Santesteban said:
    I am also using an external 3.3V regulator to drive VUSB, leaving VBUS unconnected

    Sorry, I have no experience with this, so I cannot confirm or deny this setup.

**Attention** This is a public forum