• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 2107 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.

MSP 430 F5525 sample CDC stack problem

A46810
Intellectual 560 points
Other Parts Discussed in Thread: MSP430F5528

Hi I am using the sample CDC stacks available from TI I just change the device from 5529 to 5525 in device.h.

Before the the clock is initialized I can see the normal SMCLK @ 1.048 MHz but the moment the code comes in X2 start function the crystal is not stabilized and it continues infinitely in the loop. Does this have anything with the USB ? The other sample codes for UCS from sample codes work fine and I can see the clock bt here in X2Start function the code just enters the infinite loop hence I cannot see the clock

My USB device is also not being recognized by UC it says device is unknown. Could this be something wrong with my board or the code.

  • 0
    Expert 1790 points

    Hello A,

    Have a try with the code examples MSP430F552x_UCS_07.c and MSP430F552x_UCS_08.c. You can see if X2 stabilizes without USB stack. Depending on the crystal you use you might need to adjust the oscillator drive on register UCSCTL6.

    If your oscillator is not stable then check load capacitance, drive speed or coupling onto connection lines.

    Regards

    Guenther

     

     

  • 0 in reply to Guenther Klenner
    Intellectual 560 points

    Hi Guenther,

    I tried those examples and they seem to work fine. I don;t understand why do we need to program UCSCTL7 twice .

    EDIT: Actually I tried to run those example they appeared to run fine initially byt they did not. They were infinite loops for XT1 and XT2 . All other codes for DCO worked fine. Looks like I have something wrong which doesn't let the crystal stabilize. How do check the capacitance value or change it ?

  • 0 in reply to A46810
    Expert 1790 points

    Hello A,

    You find the values on crystal's datasheet. XT2 has no adjustable capacitive load as XT1 has. You need to add the capacitors. Calculation of capacitor value is a little bit tricky. I can help you, if you want.

    Please have also a look on the traces to the crystal. They should be away from any other dynamic signal sources to avoid coupling and interference. A good way is to have the two traces to the crystal close together (best above each other). In this case any interference does not harm (see: differential line).

    Regards

    Guenther

  • 0 in reply to Guenther Klenner
    Intellectual 560 points

    Well forget what I asked earlier. I did more testing and found that OFIFG is always set when XT1 or XT2 are used that is my main problem and I see the DCO clock not the external crystal clock, I am not sure why. Also would just changing device.h 5529 to 5525 would it effect since 5529 is 80 pin and 5525 is 64 pin

  • 0 in reply to A46810
    Expert 1790 points

    Hello A,

    Well, changing the device descriptor file does not help as XT1 and XT2 on the same ports independend on the pins used.

    The oscillator fault bit (OFIFG) is a sum bit for any oscillator fault (see SLAU208F, Fig 3-4). Please check which oscillator causing the fault: register UCSCTL7, bit DCOFFG, XT1LFOFFG, XT1HFOFFG or XT2OFFG.

    The oscillator fault bit (OFIFG) also indicates that the clock (SMC, MCLK) switched back to DCO. That is why you do see the DCO and not a crystal clock.

    I wish you a successful weekend

    Guenther

    PS: I have no problem with XT1 and XT2 on my 5528 (also 64 pin)

     

     

  • 0 in reply to Guenther Klenner
    Intellectual 970 points

     

    Guenther,

    I have been having a similar problem to what A has been having, but with the 5528. I noticed in the example code that they adjust the oscillator drive in the example program AFTER the stabilization loop. I put modified the oscillator drive before the loop, and now it no longer hangs.

    One thing that is interesting, is that it does not hang indefinately. Try touching the leads of the oscillator with your finger, this causes the crystal to stabilize and exit the loop even if the drive bits are set incorrectly. This is very weird. One thing that bothers me is that this symptom is also present when using the BSL. The device will hang, I'm guessing in a similar loop when booting with the BSL, until I touch it with my finger. Then the device enumerates and the computer recognizes it.

    TI,

    Can anyone from TI give some more insight into this problem? And how to fix this problem in the BSL? I want to make sure everything is working correctly by the time you release the field update software.

    Thanks for all the help guys.

    -NJC

     

  • 0 in reply to NJC
    Expert 1790 points

    Hello NJC,

    From the RF point of view the effect is quite simple. A crystal has also its maximum power for resonance. If you drive it stronger then is starts to clang. You will get harmonics and an instabile oscillation. An attenuation like your finger reduce the power and stabilize oscillation.

    Your hint on oscillator drive is very valid but also depends on the crystal. The datasheet (SLAS590D, page 57) explains driving / frequency relation.

    Changing oscillator drive in the BSL might be tricky. Maybe a HW workaround helps. I would try a resistor to damp the drive. Try a 1M, 100k than 10k in parallel of the crystal or a 3R3, 10R, 33R than 100R in series to the crystal. It's not nice but helpful.

    Regards

    Guenther

  • 0 in reply to Guenther Klenner
    Intellectual 970 points

    Günther,

    Thank you so much for the help. I overlooked the possibility that problem was hardware related since I am using TI's target board. I assumed they had everything as it should be for using the BSL and the example projects. I wonder why in the sample projects they reduce the dive strength after they wait for the device to stabilize, seems counterintuitive to me.

    I guess the most likely explanation is that my crystal is slightly different then they planned for. I'll be trying the resistor idea later today.

    Thanks again,

    NJC

  • 0 in reply to NJC
    Expert 1790 points

    Hi NJC,

    Starting with a higher drive strength speeds oscillation start up. But you are right, it is much better to reduce drive strength before wait for stabilize.

    Regards

    Guenther

  • 0 in reply to Guenther Klenner
    Intellectual 560 points

    Hi NJC and Guenther,

    I am using XT1 10 MHz crystal in that there is no high or low drive setting in XT1Start(). NJC what were you reffering to even modifing the XT1Start() to

     UCSCTL6 &= ~XT1OFF;         // enalbe XT1 even if not used
      UCSCTL6 |= XTS;             // enalbe XT1 even if not used
       UCSCTL6_L &= ~(XT1DRIVE1_L+XT1DRIVE0); // lower drive setting to XT1 for low power

      while (SFRIFG1 & OFIFG) {   // check OFIFG fault flag
        UCSCTL7 &= ~(DCOFFG+XT1LFOFFG+XT1HFOFFG+XT2OFFG); // Clear OSC flaut Flags fault flags
        SFRIFG1 &= ~OFIFG;        // Clear OFIFG fault flag
      }

    does not help and it hangs. Also is there any other file which i need to change for F5525 apart from device.h Do you know what is the product id for F55xx series for the USB part ? Also do I have to change the CMD files I use IAR

  • 0 in reply to A46810
    Intellectual 560 points

    NJC could you please post the working code.Its trivial but this way I can confirm that there is something else wrong in my board rather than just the software code

  • 0 in reply to A46810
    Intellectual 970 points

    A,

    I will try to post the code tomorrow when I have time to. Sorry to keep you waiting, I know how much it stinks wanting to work on your project and waiting on the forums. In the meantime, I do recommend looking into .cmd file. To get you started, (I could be completely wrong here, so try to verify this information by searching in previous posts), from what I understand the .cmd file is specific to CCS, and the IAR IDE has its own version of this file. I do not work with IAR so I do not know what it is. This file contains some necessary things to get the program up and running.

    I don't think this is your problem though, my code would not even compile without this file. Have you tried touching the capacitor leads for the crystal with your finger? Silly suggestion, but it did help me figure out what my problem was.

    -NJC

    _______________________

    www.msp430launchpad.com

  • 0 in reply to NJC
    Expert 1790 points

    Hello A, NJC ,

    Here is my code as reference. XT1 is 32768 Hz, XT2 is 4 MHz, DCO is 20 MHz:

      // Name: Clock::Init()
      // Parameter: none
      //    Speed:  MCLK 20MHz, SMCLK 20MHz       
      //    return: 0 = okay, others fail
      // Descrption:
      //    Init (re)sets all parameters of the Clock class

    void Clock::Init()
    {
    // Adjust Clock::TicksPerUSec acordingly!
    #if defined(__MSP430F5528__)

      // For debugging purposes.
      P1DIR |= BIT0;    // ACLK (P1.0, pin18)
      P1SEL |= BIT0;
      P2DIR |= BIT2;    // SMCLK(P2.2,pin28)
      P2SEL |= BIT2;                          

      // 25 MHz MCU

      PMMCTL0 =  PMMPW + PMMCOREV_2;            // Increase core voltage for 20 MHz operation

      P5SEL |= BIT4+BIT5;                       // Select XT1

      UCSCTL6 &= ~XT1OFF;                       // XT1 On
      UCSCTL6 |= XCAP_1;                        // Internal and external load cap 5.5 + 15pF/2 = 13 pF
      UCSCTL3 = 0;                              // FLL Reference Clock = XT1
      P5SEL |= BIT2+BIT3;                       // Port select XT2

      UCSCTL6 &= ~XT2OFF;                       // Enable XT2
      UCSCTL3 |= SELREF__REFOCLK;               // Start with FLLref = REFO
      UCSCTL4 |= SELA_2;                        // ACLK=REFO,SMCLK=DCO,MCLK=DCO

      // Loop until XT1,XT2 & DCO stabilizes - In this case loop until XT1 and XT2 settle
      do
      {
        UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG /*+ XT1HFOFFG*/ + DCOFFG);
                                                // Clear XT2,XT1,DCO fault flags
        SFRIFG1 &= ~OFIFG;                      // Clear fault flags
      }while (SFRIFG1&OFIFG);                   // Test oscillator fault flag
     
      UCSCTL6 &= ~(XT1DRIVE_3 + XT2DRIVE_3);    // Xtals are now stable, reduce drive strength

      UCSCTL4 = SELA_0 +SELS_4 + SELM_4;        // ACLK = LFTX1 (by default), SMC = DCOCLKDIV, MCLK = DCOCLKDIV


    #define DCO_ON_XT1
    #if defined(DCO_ON_XT1)

      // Initialize DCO to 20 MHz
      __bis_SR_register(SCG0);                  // Disable the FLL control loop
      UCSCTL3 = SELREF__XT1CLK;                 // Use 32768 Hz XT1
      UCSCTL0 = 0x0000;                         // Set lowest possible DCOx, MODx
      UCSCTL1 = DCORSEL_6;                      // Set RSELx for DCO = 20 MHz
      UCSCTL2 = FLLD__1 + 609;                  // Set DCO Multiplier for 20 MHz
                                                // (N + 1) * FLL Div * FLLRef = Fdco
                                                // (609 + 1) * 1 * 32768Hz/1 = ca. 20 MHz
                                                // Set FLL Div = fDCOCLK/1
      __bic_SR_register(SCG0);                  // Enable the FLL control loop

      // Worst-case settling time for the DCO when the DCO range bits have been
      // changed is n x 32 x 32 x f_MCLK / f_FLL_reference. See UCS chapter in 5xx
      // UG for optimization.
      // 32 x 32 x 20 MHz / 32768 = 624657 = MCLK cycles for DCO to settle
      __delay_cycles(624657);
    else

      // Initialize DCO to 20 MHz
      __bis_SR_register(SCG0);                  // Disable the FLL control loop
      UCSCTL3 = SELREF__XT2CLK;                 // Use 4 MHz XT2
      UCSCTL0 = 0x0000;                         // Set lowest possible DCOx, MODx
      UCSCTL1 = DCORSEL_6;                      // Set RSELx for DCO = 20 MHz
      UCSCTL2 = FLLD__1 + 4;                    // Set DCO Multiplier for 20 MHz
                                                // (N + 1) * FLL Div * FLLRef = Fdco
                                                // (4 + 1) * 1 * 4MHz/1 = 20 MHz
                                                // Set FLL Div = fDCOCLK/1
      __bic_SR_register(SCG0);                  // Enable the FLL control loop

      // Worst-case settling time for the DCO when the DCO range bits have been
      // changed is n x 32 x 32 x f_MCLK / f_FLL_reference. See UCS chapter in 5xx
      // UG for optimization.
      // 32 x 32 x 20 MHz / 4 MHz = 5120 = MCLK cycles for DCO to settle
      __delay_cycles(5120);
    #endif
      // Loop until XT1,XT2 & DCO fault flag is cleared
      do
      {
        UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG /*+ XT1HFOFFG*/ + DCOFFG);
                                                // Clear XT2,XT1,DCO fault flags
        SFRIFG1 &= ~OFIFG;                      // Clear fault flags
      }while (SFRIFG1&OFIFG);                   // Test oscillator fault flag


      UCSCTL4 = SELA_0 +SELS_3 + SELM_3;       // ACLK = LFTX1 (by default), SMC = DCO, MCLK = DCO

    #define TICKSPERMSEC 20000

    #else //for MSP430F2xxx MCUs
        // Speed clock to 1MHz
        BCSCTL1= CALBC1_1MHZ;
        DCOCTL= CALDCO_1MHZ;   

    #define TICKSPERMSEC 1000

    #endif
      TicksPerMSec = TICKSPERMSEC;
    }

  • 0 in reply to Guenther Klenner
    Intellectual 560 points

    Hi Guenther,

    Thanks for the code I shall try it out. I am using just connecting one of the crystals, I am testing either XT1 or XT2. I just want to double check whether both of them need to be connected or not. Is it required to connect Xt1 always ?

  • 0 in reply to A46810
    Expert 1790 points

    Hello A,

    For my code: yes. In general: no. For USB: no, only XT2 is required.

    XT1 is needed for an accurate RTC. All MSP430F55xx have a calibrated reference oscillator at 32768 Hz with +/- 1.5% tollerance. It depends on your application to use none, XT1 or XT2 or even both.

    My application is battery operated with RTC and USB communication / charge. So I need both.

    Regards

    Guenther

  • 0 in reply to Guenther Klenner
    Intellectual 560 points

    Hi Guenther,NJC,

    Guenther I tried your code it still failed I also went ahead and bought the EVM for 5528 which works perfectly fine with my code. Turns out my crystal was at fault. Anyway the crystal code works perfect I can see the clock sourced by XT2 now. I tried to load the USB code on the EVM board and it works fine but with my 5525 I am having troubles. I am trying to use breakpoints to detect the where my code stops but its behavng erractically, every time I debug there is a different set of breakpoints getting activated. With this happening there is no way I can debug the problem. I am losing my trust in IAR

  • 0 in reply to A46810
    Expert 2315 points

    We have had very similar problems trying to bring up USB.  When running the dev kit with a 6638 micro installed the code would always hang up in the oscillator fault loop.  I finally discovered that disabling IAR's "run to main" feature allowed the code to get past the oscillator fault problem.  I've talked with TI about this and they have not idea why this might be so.

     

    I finally got the dev kit working, but when we try to run the same code on a custom board we get intermittent USB problems.  We discovered the "hold your finger on the oscillator leads" fix also.  We have tried all sorts of things -- different frequency oscillators, caps, resistors.  Nothing has produced a reliable solution yet.

  • 0 in reply to Dave Hohl
    Intellectual 560 points

    HI Dave:

    On second thoughts, the moment I got the evaluation board it worked and I never bothered about checking my custom board with another oscillator  thinking there could be some problem in my board but I would have to eventually use a custom bord . But now since you said that I think there could be a possibility that something else could be wrong.

**Attention** This is a public forum