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.

MSP430 - UCS: Why are MCLK and SMCLK similar but different to ACLK, if DIVA = DIVS = DIVM = 0 and SELS = SELM = SELA?

Other Parts Discussed in Thread: MSP-TS430PN80USB, MSP430F5529

Hello readers!

Something is going completely wrong. I thought I would have understand UCS but ... my Oscilloscope shows me something different than I have thought to be selected in the code .

 

Hardware:

I am using a MSP-TS430PN80USB. XT2 = 4MHz (as delivered), XT1 = 32768 Hz.

My uC is a MSP430F5529.

 

My aim:

-  XT2 = 4MHz   --> ACLK

-  XT1 = 32kHz  --> FLL --> DCOCLK --> MCLK (as high as possible)

-  XT1 = 32kHz --> FFL --> DCOCLKDIV --> SMCLK = 216Hz  (This frequency has to be!)

 

My problem:

My oscilloscope is connected to pin1.0 (ACLK) pin7.7 (MCLK) and pin2.2 (SMCLK)

Both pins are showing a frequency of about 180.505Hz.

But  within my code (included a little bit further below)  you will find the following line: "  UCSCTL4 |= SELA_5 + SELM_3 + SELS_4;"

 

My questions:

- Does anybody can tell me why these pins (ACLK and MCLK) are showing a completely strange frequency?

- What further changes needs to be done to get closer to my aim?

- Please see question within subject, too. You will find more detailed description of this question a little bit further down.

 

My code is a mixture of the following sample codes from TI with some changes up to my task:

- MSP430F552x_UCS_07
- MSP430F552x_UCS_03

 

Many thanks in advance!!

 

Here is my code:

//------------------------------------------------------------------------------------------------
 void Init_CLK(void)
 {

//Pins:

   P1SEL |= BIT0; // P1.0 from module (ACLK) - no LED
   P1DIR |= BIT0; // P1.0 output
   P2SEL |= BIT2; // P2.2 from module (SMCLK)
   P2DIR |= BIT2; // P2.2 output
   P7SEL |= BIT7; // P7.7 from module (MCLK)
   P7DIR |= BIT7; // P7.7 output


// External Clock Sources:


         // LF XT1:
   P5SEL |= BIT4+BIT5; // Port select XT1 (P5SEL.5 don't care)

        // HF XT2
   P5SEL |= BIT2+BIT3; // Port select XT2 (P5SEL.3 don't care)
   UCSCTL6 &= ~XT2OFF; // Set XT2 On
   UCSCTL6 |= XCAP_2; // Internal load cap (8.5pF). I am using no external capacitors at the moment.
                                      // (Supposed configuration for used Quartz: 8.7pF)

       // Startup of quartz as XT1:
   // XT1 is by default on as it is used default reference for the FLL - internal load caps?
   // Loop until XT1,XT2 & DCO stabilizes
   do
   {
   UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);
   // Clear XT2,XT1,DCO fault flags
   SFRIFG1 &= ~OFIFG; // Clear fault flags
   }while (SFRIFG1&OFIFG); // Test oscillator fault flag

   UCSCTL6 &= ~XT2DRIVE0;                 // Decrease XT2 Drive according to
                                                                      // expected frequency  
   UCSCTL4 |= SELA_5 + SELM_3 + SELS_4;      // Select sources SACLK=XT2 and MCLK=DCO
                                                                      // SMCLK source = default = DCOCLKDIV
   UCSCTL5 |= DIVA_0 + DIVS_5 + DIVM_0;      // SMCLK = DCOCLKDIV / 32

// FLL
   UCSCTL3 |= SELREF_0; // Set DCO FLL reference = XT1 (default)

   __bis_SR_register(SCG0);                // Disable the FLL control loop
   UCSCTL0 = 0x0000;                         // Set lowest possible DCOx, MODx
   UCSCTL1 = DCORSEL_5;                  // Select DCO range 24MHz operation
   UCSCTL2 = FLLD_4;                         // Set DCO Multiplier for 16,777,216Hz
                                                          // D*(N + 1) * FLLRef = Fdco
                                                          // 16*(31 + 1) * 32768 = 16,7MHz
                                                          // Settings: N = n = defaults, D = 1
                                                          // (Defaults: n=1, D=2, N=31) 
   __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 12 MHz / 32,768 Hz = 375000 = MCLK cycles for DCO to settle
   __delay_cycles(375000);
}

  • The horizontal sweep speed of you scope is too slow. Try a much higher setting.

  • Thanks, old_cow_yellow.

    No, I don't think so. My scope seems to be all right.

     

    ________________

    Now I made some changes:

     "UCSCTL5 |= DIVA_0 + DIVS_0 + DIVM_0;"     instead of  the UCSCTL5 settings from before.

     

    Then I tried out all setting of SELS, SELM and SELA. The frequencies on my scope are the same if SELS and SELM are in the same selection. But SELA to me seems to show the most expected frequencies.

    SELS_0  --> 269kHz

    SELS_1  = SELS_2   --> 4MHz

    SELS_2 = SELS_3 = SELS_4 --> 260kHz

    SELS_5 --> 500kHz

     

    SELA_0 --> 32kHz

    SELA_1 --> 10kHz

    SELA_2 --> 260kHz

    SELA_3 --> 32897Hz

    SELA_4 --> 260kHz

    SELA_5 --> 32786,9Hz

     

    Is this a result of the divider DIVPA?

    From where can this behavior come from?

     

    I have done this measurement again and again, hoping that I am making a mistake during measuring.

    Either I am wrong and not concentrated enough when writing down my measurements or I am right, and  the values of MCLK and SMCLK are changing simultaneously between the values written above.

    - Strange, strange, strange...

     

     

     

  • Strange. SELx_2 should give 32kHz (REFOCLK) on 5x devices.

    The SELx_0 setting may differ. It should normally be XT1CLK, but if XT1OFIFG is set (the crystal is not running properly), ACLK might fall back to REFO while SMCLK runs with whatever comes from XT1.

    Also, SELx_1 should give the ~10kHz VLO for all three.

    Almost none of your results make any sense.

    So unless you post your actual code, I can only say: strange indeed.

    Bob Marley said:
    Is this a result of the divider DIVPA

    This one divides the actual ACLK further before outputting it. And it applies to all SELA_x settings.

    There's another one: FLLD. It forms the difference between SELx_3 and SELx_4 (DCOCLK and DCOCLKDIV). By default this should be a factor of 2.

    Besides the DIVPA, which only applies to ACLK external output, and the fallback in case of failure of the selected clock (ACLK XT1->REFO, MCLK ->DCO), all three clocks are treated identical. Same setting = same result.

  • Thanks Jens-Michael Gross.

    In the meantime I am thinking that either there must be something wrong with the external quartz on XT1 or my uC is damaged.

     

    So my next steps will be

    - making new measurements with DIVPA = 0.  --> But a first attempt showed me no suprisingly difference.

    - Using a other brand new MSP430F5529 with the same code.

    - Investigating the quartz (hardware), finding some suitable capacitors. Unfortunately I have not got some NP0 potentiometers at stock. So I need to solder and resolder... and solder...

     

    I will keep you informed as soon as I will find out something new.

  • I still do not know what is going on.

    I am using now a brand new MSP430F5529. During my measurements I selected DIVPA_0.

     

    What I surely can say is that MCLK and SMCLK are a always have got similar behavior, whereas ACLK tends to be nearly allways to 32kHz. This happens on different uC.

    What can be is that  this behavior changes beween one measurement (using all SELM-, SELS- and SELA-settings) to a other measurement using again all SELM-, SELS- and SELA-settings . But then still MCLK and SMCLK have got about the same frequency.

     

    First Measurements (second uC):

    SELS_0 = SELM_0 = SELS_4 = SELM_4 = 245kHz

    SELS_1 ... SELS_3  and  SELM_1 ... SELM_3 =  4MHz

    SELS_5 = SELM_5 = 505kHz
    SELA_0, SELA_2 ... SELA_5 = 32kHz

    SELA_1 = 10kHz

     

    Second Measurements (second uC):

    SELS_0 ... SELS_5  and  SELM_0 ... SELM_4 =  257kHz

    SELS_5 = SELM_5 = 505kHz
    SELA_0 ... SELA_5 = 32kHz

     

  • Okay, now I measured again SMCLK, MCLK and ACLK with different SELS-, SELA- and SELM-settings. During all of this I used DIVPA_0, DIVS_0, DIVM_0, DIVS_0 and I did not use my own code.

    During this measurement all other settings of USC are made by default.

     

    Second uC:

    - SELS_0 = 1,06MHz, SELS_1 = 275kHz, SELS_2 = SELS_3 = SELS_4 = 1,06MHz, SELS_5 = 275kHz

    - SELM_0 ... SELM_5 = SELS_0 ... SELS_5

    - SELA_0 = 33kHz, SELA_1 = 10kHz, SELA_2 =  32kHz, SELA_3 = 2,18MHz, SELA_4 = 1,06MHz, SELA_5 = 275,5kHz

     

    So to me all ACLK-settings will be all right.

    But still I do not understand the differences between ACLK and (SMCLK or MCLK).

  • Hello Jens-Michael Gross!

    - I hope you will read this.

     

    Hello all other readers!

    As I could not find any quartz signal  I tried to use the old TI source code again (MSP430F552x_UCS_07) which is running via XT1.

    By the way: For measuring the quartz frequency I put a *100 oscilloscope probe directly on the XT1Out-pad, where the 32kHz quartz is soldered.

     

    But I could not run that program as a error occurred:

    "Error connecting to the target:
    Could not find device (or device not supported)"

    - By trying to run the programm my MSP-FET430UIF and MSP-TS430PN80USB-Board were fully connected to my PC as usual.

     

    This reminds me to your words written in a other post of me within this forum "MSP430 - UCS: How does the register DCORSEL needs to be if using FLL?":

     "Bob Marley:
    Can I damage the uC by using a too high CLK (e.g. DCOCLK)?

    Jens-Michael Gross:
    Unlikely.
    Exceeding the allowed frequency range will make it running unstable up to complete failure, but after a reset, it should be okay again.

    BUT there is a chance for locking the device for JTAG usage: if your code executes and sets the clocks too high before the JTAG programmer can kick in, ther eis a chance that it will crash and not respond to JTAG anymore. It's rather unlikely for clock setting - the voltage supervisor can create such a situation easily, as it won't reset on a reset signal, only at power-on, but it is a possibility. In this case, usign the BSL will allow you to access it again, since the clock programming is reset on a reset signal and the BSL will kick in before your code is executes and crashes the device once more."

     

    What do you think, can this be the reason for all my trouble?

    Before all of that I made some experimental changing using DCORSEL-modes.

    But since this there should be some power-ons.

     

    If so, how do I need to reset my yC?

    --> Via pin-reset?

     --> Or by swithing reset within CCP when I have allready accessed the uC via BSL?

    Could you please give me an idea in which datasheet I will find to read more?  SLAU278??

     

    Thank you very much in advance!

     

     

     

  • Bob Marley said:
    For measuring the quartz frequency I put a *100 oscilloscope probe directly on the XT1Out-pad, where the 32kHz quartz is soldered.

    Even the *100 tips introduce a certain capacity. The only probes you can use directly at a crystal are FET probes (some time ago I've seen a circuit how to build one). It has an input capacity of ~1pF.

    The problem is that the probe input capacity is added only to one side of the crystal, exposing an unbalanced, increased load.

    What kind of PCB do you use? on some demo boards, teh XT1 pins are per default routed to a breakout pin. This additional routing introduces so much capacity and als acts as EMI antenna, so that the crystal will not work at all.

    As for teh difference between ACLK and (S)MCLK: the different clocks have different fallback mechanisms.

    If LFXT1 is failing/not yet fired up, FLL, ACLK and (S)MCLK will be automatically switch to REFO (32kHz) instead. If XT1 is in HF mode, failure of XT1 will cause (A/S)MCLK to be switched to DCOCLKDIV instead while the FLL will continue as if there were a signal, driving the DCO down to lowest frequency of the selected RSEL setting. Same happens if XT2 is selected as source.

    To be accepted as a valid clock, the 32kHz crystal must be up and running (which can take several 100 ms) for at least 250ms before the system clocks will be switched to LFXT1 from the fallback REFO.

    So your readings are indeed strange. All three clocks should be the same for DIVPA_0.

    Honestly, I have no idea what's going wrong. Did you double-check the registers you're writing your configuration too?  The default values for SELA and SELS/M are different, SELA running on LFXTA/REFO (fallback) and SELS/M on DCOCLKDIV. So if you don't write the confi to UCSCTL4, this would explain a difference. But then, there would be no difference for different settings. So could you post your complete test code?

    Bob Marley said:
    What do you think, can this be the reason for all my trouble

    For the CPU no longer being found, yes, could be. But if you didn't mess with the DCORSEL setting, the default value of DCORSEL_2 should provide a DCO frequency in the range of 0.3 to 7.4MHz. Which should not lock you up. But you wrote you did change the DCORSELs. DCORSEL_3 is safe too, but from 4 on, you can create situations where MCLK gets out of control.

    Anyway, I remember a different cause for locked-up CPUs. There was a problem with some TI demo code which was intended for one MSP but when flashed to a different one it was not programming the clock module but rather the SVS module, causing the device to stay in an endless reset. But this locked-up MSP was of the 2x series,switched to an external voltage sense on a port pin, which the 5x series hasn't. However, if your code somehow enables the SVS to trigger a reset due to 'undervoltage', this might keep the MSP in permanent reset state. The only way against this is to externally power it by a higher VCC such as 3.6 or even 4V (with current-limiter, and only as last effort, as it is at the edge of permanent destruction). Then it should respond to the programmer again. If it is the SVS.

    Bob Marley said:
    If so, how do I need to reset my yC?

    If the code is somehow locking the MSP so it won't be revived by a reset as triggered by the FET, then the smartest solution is a small electronic on teh reset pin. The problem is that after powqer-on, the MSP starts and may reporgram itself so a power-on is needed to return to working condition. But the programmer won't start is JTAG sequence imemdiately after power-up. So once the programmer tries to reset the MSP and enter JTAG, it's already too late and the device is no longer responding.
    The key here is a small electronic that will hold reset low after power-on until it detects a falling edge on the programmers reset line. Then it will release the processor reset pin when the programmers reset pin goes high too. This way, the MSP will be still in unmisconfigured power-on state when the programmer releases reset and enters JTAG mode. Alternatively, you can try to manually time this: start the programming process at the same time you're applying VCC to the MSP. A very tight timing window but it could work.

    Bob Marley said:
    Or by swithing reset within CCP when I have allready accessed the uC via BSL

    If you got it to respond to BSL, you can access it with a wrong password inside BSL. This should erase the main flash and any bad code should be gone. It could work.
    Provided that your problem is indeed bad code misconfiguring the MSP.

    Bob Marley said:
    Could you please give me an idea in which datasheet I will find to read more?  SLAU278

    278? The one I have for the 5x/6x familiy is slau208.

    One thought just crossed my mind: If it is the DCORSEL setting, maybe lowering VCC to 2.2 or even 2V might help. Since the internal VCore is 1.8V anyway, lowering the VCC might slow down the DCO. Also, coolign the MSP down migh thelp. -0.1% per °C and -1.9% per V. It's possible that the DCO will return into a range where it responds again. Also, it takes longer before your code is executed after a reset, so chances are higher that the JTAG will kick-in before your code locks it up again.

    Another possibility is the usage of a non-USB based FET. e.g. the wireless Olimex is much quicker in its startup sequence, so it might work too.

    But I guess ordering a new MSP is the cheaper way. If you disabled a handful of them during your tests, you can still consider trying some tools to revive tem all. For a single device it might not be worth the effort.

  • Hello Jens-Michael Gross,

    many thanks for your extensive answer!

     

    You asked me which PCB I am using. It's a MSP-TS430PN80USB connected to a MSP430 USB-Debug-Interface.

    This PCB is placed on a other self-made PCB hold together by its multi-pin connector. So for all pins there is a breakout which can be disconnected by jumpers.

    During the last few days all pins have been disconnected so the self-made board isn't in use. But of course there is a chance that the multi-pin connectors are working like antennas.

     

    Today at first I tried to run the TI source code MSP430F552x_UCS_07 again. And "Surprise!" it works!

    So as these problems with letting run some code on my uC only has been yesterday evening I think it wont be a problem with the JTAG. At least now I have got TI code on my uC.

    Of course I measured the output on pin1.0 where according to the program the frequency of XT1 should be.

     

    The MSP430F5529 hasn't got HF on XT1. But you told me that the fall-back of (S)MCLK, ACLK & FLL using XT1 are REFO.

    So could it be possible that I have measured REFO? How could I find out what I am really measuring (REFO/XT1)?

    I mean is there a flag or something that shows me what the uC ist using?

     

    I think if the problem is not with the quartz the other solution is that it is hidden somewhere in the code I have used.

    You have asked me for the complete code. The code at the beginning of this post is 90% of the whole program I made so far.

    During my measurements I change the lines with the UCSCTL4/5 settings only - as mentioned.

     

    Just to make sure here is the code:

    ----------------------------------------------------------------------------------------------------------------------------

    #include <msp430f5529.h>
    #include "motor2.h"

    // Related TI Source Code:
    // - MSP430F552x_tb_03    --> TBIV ISR using "case"
    // - MSP430F552x_tb_10    --> TB0 for PWM without ISR
    // - MSP430F552x_UCS_07   --> Using XT1 with 32kHz quartz
    // - MSP430F552x_UCS_03   --> How to use FFL

    // ******************************************************************************
    // * Function Prototypes (Declarations)
    // ******************************************************************************

    extern void Init_MTRPins(void);
    extern void Init_CLK(void);
    extern void Init_TB0Compare(void);

    // *****************************************************************************

    // * Functions for Initialization
    // *****************************************************************************

    void Init_MTRPins(void)
    {
    // Pins
    //CCR
      P5SEL |= BIT7;    // P5.7 option select (from module), P5.6 remains GPIO
      P5DIR |= BIT7;    // P5.7 output (P5.6-CCR0 unused as TB0 in continuous mode)
      P7SEL |= BIT4+BIT5+BIT6;    // P7.4-7.6 option select (from module)
      P7DIR |= BIT4+BIT5+BIT6;    // P7.4-7.6 outputs  

    //GPIO
      P3DIR |= BIT5;    // P4.7 output 
      P3DIR |= BIT6;    // P5.6 output 

    //during programming
      P1SEL |= BIT0;    // P1.0 from module (ACLK) - no LED
      P1DIR |= BIT0;    // P1.0 output
      P2SEL |= BIT2;    // P2.2 from module (SMCLK)
      P2DIR |= BIT2;    // P2.2 output
      P7SEL |= BIT7;    // P7.7 from module (MCLK)
      P7DIR |= BIT7;    // P7.7 output
    }

    void Init_CLK(void)
    {
    // External Clock Sources
    // LF XT1
      P5SEL |= BIT4+BIT5;    // Port select XT1 (P5SEL.5 don't care)

    // HF XT2
      P5SEL |= BIT2+BIT3;    // Port select XT2 (P5SEL.3 don't care)
      UCSCTL6 &= ~XT2OFF;    // Set XT2 On
      UCSCTL6 |= XCAP_2;    // Internal load cap (8.5pF)
      // (Supposed configuration for Quartz: 8.7pF)

    // Startup of quartz as XT1:
    // XT1 is by default on as it is used default reference for the FLL - internal load caps?
    // Loop until XT1,XT2 & DCO stabilizes
    do
    {
    UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);
    // Clear XT2,XT1,DCO fault flags
      SFRIFG1 &= ~OFIFG;    // Clear fault flags
      }while (SFRIFG1&OFIFG);    // Test oscillator fault flag

      UCSCTL6 &= ~XT2DRIVE0;    // Decrease XT2 Drive according to
    // expected frequency
      UCSCTL4 |= SELA_1 + SELM_1 + SELS_1;    // Select sources SACLK=XT2 and MCLK=DCO
    // SMCLK source = default = DCOCLKDIV
      UCSCTL5 |= DIVA_0 + DIVS_0 + DIVM_0 + DIVPA_0;   // SMCLK = DCOCLKDIV / 32

    // FLL
    UCSCTL3 |= SELREF_0; // Set DCO FLL reference = XT1 (default)

      __bis_SR_register(SCG0);    // Disable the FLL control loop
      UCSCTL0 = 0x0000;    // Set lowest possible DCOx, MODx
      UCSCTL1 = DCORSEL_5;    // Select DCO range 24MHz operation
      UCSCTL2 = FLLD_4;    // Set DCO Multiplier for 16,777,216Hz
    // D*(N + 1) * FLLRef = Fdco
    // 16*(31 + 1) * 32768 = 16,7MHz
    // Settings: N = n = defaults, D = 1
    // (Defaults: n=1, D=2, N=31)
    __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 12 MHz / 32,768 Hz = 375000 = MCLK cycles for DCO to settle
    __delay_cycles(375000);
    }
    //------------------------------------------------------------------------------
    // TB0 - Compare
    //------------------------------------------------------------------------------

    void Init_TB0Compare(void)
    {
    // Interrupt Enable
    // TBCCTL0 = CCIE; // TBCCR0 interrupt enabled

    // while(1) // endless Loop
    // {
    // PWM
      TBCCR0 = 65000;    // PWM Period
      TBCCTL1 = OUTMOD_4;    // CCR1 toggle
      TBCCR1 = 48750;    // CCR1 PWM Duty Cycle 
      TBCCTL2 = OUTMOD_4;    // CCR2 toggle
      TBCCR2 = 32500;    // CCR2 PWM duty cycle 
      TBCCTL3 = OUTMOD_4;    // CCR3 toggle
      TBCCR3 = 16250;    // CCR3 PWM duty cycle 
      TBCCTL4 = OUTMOD_4;    // CCR4 toggle
      TBCCR4 = 8125;    // CCR4 PWM duty cycle

      TBCTL = TBSSEL_2 + MC_2 + TBCLR + TBIE;    // SMCLK, continuous mode
    // CPU on (otherwise MCLK could not be used)
    // }
    }
    // *****************************************************************************
    // * Interupt Service Routines (ISR)
    // *****************************************************************************

    // Timer_B7 Interrupt Vector (TBIV) handler
    #pragma vector=TIMERB1_VECTOR
    __interrupt void TIMERB1_ISR(void)
    {
    /* Any access, read or write, of the TBIV register automatically resets the
    highest "pending" interrupt flag. */
    switch( __even_in_range(TBIV,14) )
    {
      case 0: break;    // No interrupt
      case 2: break;    // CCR1 not used
      case 4: break;    // CCR2 not used
      case 6: break;    // CCR3 not used
      case 8: break;    // CCR4 not used
      case 10: break;    // CCR5 not used
      case 12: break;    // CCR6 not used
      case 14: //P1OUT ^= 0x01;    // overflow
    break;
    default: break;
    }
    }

     

  • Hello Jens Michael Gross,

    as you can see in the code I have used DORSEL_5. So here could be the problem, too.

     

    In the other post mentioned above you told me that I can use DORSEL_6 for frequencies within the range of 12...35MHz.

    How do I get/calculate this range?

     

    In the users guide I read (p.93, chapter 4.2.6.1) 

    "The five DCO bits divide the DCO range selected by the DCORSEL bits into 32 frequency steps,
    separated by approximately 8%.
    "

    Further there is the DCO Frequency table p.59 in the MA?430F552x-Datasheet. 

     

  • At the moment I try to get some clearness what the quartz is doing.

     

    Therefore I detached the XT1IN/OUT-pins from the multi-pin connector just to be sure.

    Using the TI source code MSP430F552x_UCS_07 my oscilloscope showed me what looked like two frequencies added together (32kHz and 64kHz.).

    Changing between different XCAP doesn't showes me any important difference but there has been probably more difference when the XT1 pins wasn't detached.

    Mostly this waveform looks like 60-64kHz. When I can recognize 32kHz the waveform is very flat  compared to the 60-64kHz which has a amplitude of about 100mV.

     

    So I am wondering now from where a further frequency of 60-64kHz could come from.

    By the way:   In which range can the frequency of  XT1 differ so the uC does not change to REFO?

     

     

     

  • I have changed  the quartz now as 100mA should be too less amplitude anyway. But the results are still the same, when using the TI source code.

     

    I think the probes I am using should be all right for this purpose because I can see a clear sinus on my oscilloscope when directly attached to the output pin of the quartz of a watch oscillator circuit. Further I am using a labtop which I have plugged of from power supply just to be sure that there will be no problem made by a ground loop.

     

    As far as I understand the TI source code "MSP430F552x_UCS_07.c"  there needs nothing to be done to run a 32kHz quartz as XT1 exept the setting of the pins P5.4/P5.5 which are belonging to XT1. This is because XT1 is default.

    Is this true or am I using the wrong code?

     

     

     

  • Bob Marley said:
    It's a MSP-TS430PN80USB

    Looks liek on default, there is neither C1, C2, R6 or R8 installed. So if they still aren't, the 32k crystal on Q1 should feel happy. The required capacitive load will be provided by the MSP itself (XCAP). See the datasheet for the crystal for the proper settings. (If a load of 6pF is specified, you'll need 12pF on each side, including 2pF for optimum PCB and the MSP pins)

    What I notced on your code: you wait for OFIFG and try to clear the oterh OF bits on each loop.
    This was okay for the older MSPs but is wrong for the unified clock system.

    Here the OF bits for the indiviual oscillators will automatically clear if the crystal has stabilized for a specified time (it's not just sort of a monoflop anymore). OFIFG, however, won't automatically clear. But then there's DCOOFFG. If will be set (and therefore will keep OFIFG set) if teh DCO has been set to DCO_0 or DCO_31 in UCSCTL0. It does nto indicate that DCO failed, btu rather that teh DCO is on the lowest or highest possible setting and FLL cannot adjust it further. If DCOOFFG is set, it indicates that you'll have to switch to the next higher or lower DCORSEL setting (but set DCO_0 before you raise DCORSEL so you won't crash teh CPU by a too-high initial value before the FLL can adjust)

    You should instead wait for XT1LFOFFG to get celar first 8as this will take the longest time), then XT2OFFG (which will most likely be clear at this moment) then wait for DCO settling (this is the most complex part as there is no 'DCO has settled' indicator - the best way is to wait for several LFXT1 ticks ad check whether DCO/MOD hasn't changed for some time) Inf you see DCOOFFG set for some time (it always will at start before FLL begins adjusting), it's time to chance DCORSEL and wait again.

    Once all is well, you can clear OFIFG (which will stay clear then unless something goes wrong again) and continue.

    All your waiting loops should somehow indicate that you are still waiting, so you can see what's wrong. Let an LED blink differently or whatever. It isn't very enlighthing if you measure the MCLK output or ACLK signal while the crystals are still stabilizing (or never coming at all).

    Bob Marley said:
    In the other post mentioned above you told me that I can use DORSEL_6 for frequencies within the range of 12...35MHz.
    How do I get/calculate this range?


    In teh device datasheet udner DCo frequencie, you'll find the min/max frequency for DCO_0 and DCO_31 for each DCORSEL.  Each combination has a (device variation  dependent) range. The maximum frequency you'll get for DCO_0 on DOCRSEL_6 is 10.7MHz, but may be as low as 4.6. Since the worst case ration between DCO_x and DCO_x+1 is 1.12, I was calculating that you can be sure to get no less than 10.7*1.12 = 11.984 for DCORSEL_6 and DCO_1 (remember, DCO_0 would be considered as DCO fault) but it could be as low as 4.692MHz. And the maximum you can expect for DCO_30 (DCO_31 would be DCO fault too) is 39MHz/1.12 = 34.821MHz while it can be as much as 86.274 as well.
    It's up to you to pick a proper starting point that will under no circumstances exceed the processor limits. DCO_7 (with MOD_0) will be a safe starting point (to speed up FLL adjustment) if you go for 25MHz DCOCLK, while on worst case DCO_8 could already be 26.5MHz and too much. (but could be as low as 5.4MHz). Starting with DCORSEL_6 and DCO_7 in this case, will save you many reference clock cycles (224 = ~7ms alone for stepping up from DCO_0 to DCO_7 by FLL).
    Since FLL adjustment and DCO is done using modulation (which temporarily increases DCO_x), I wouldn't go for 25MHz using DCO. The maximum here would be factor 1.12 less (22.3MHz), so modulation won't ever push DCO above 25MHz. If you use DCOCLKDIV for MCLK source instead of DCOCLK, you can get closer to 25MHz and also decrease the modulation-inflicted clock jitter to a factor of <1.06 instead of <1.12.

    Nevertheless, this kind of calculation cannot be done efficiently by a library function at runtime. It has tobe calculated at compile-time. Either manually or by a macro that knows the datasheet for this particular MSP.

    Bob Marley said:
    So I am wondering now from where a further frequency of 60-64kHz could come from.

    Maybe the crystal is oscillating on its first overtone. Or it comes from anywhere and the crystal is attenuating the incoming frequency to a multiple of its own resonance frequency/the resonance frequency of the LFXT1 input circuit.

    Bob Marley said:
    In which range can the frequency of  XT1 differ so the uC does not change to REFO?

    Again there is no single answer. The fault detection requires a frequency greater than 10 to 10kHz. That means, <10Hz will be detected as fault, >10kHz will not be detected as fault, and in.between it may or may not be detected. In logic level mode (XT1OUT inactive) the datasheet allows a maximum frequency of 50kHz, but this may be caused by the attenuation introduced by the LFXT1 circuit (which will be disconnected in HF mode). tests have shown that any frequency might be put in. So a strong-enough signal will override the crystals resonance frequency, but may be influenced by it and trimmed to a multiple.

    If you desolder the crystal, do you see anything on the X1 pin?

    Bob Marley said:
    UCSCTL5 |= DIVA_0 + DIVS_0 + DIVM_0 + DIVPA_0;

    This line does nto do what you'd expect. It does effectively nothing. All 4 values are 0, so there are no bits to be set in UCSCTL5, while the |= operation will not clear any bit that might be already set. (there are none after reset anyway, but if there were, this line wouldn't change them.
    Generally, you may not |= any *_x values into a register, as it won't clear existing bits. E.g. using x |= Y_1 when x was already containing Y_2, it would hold Y_3 after this operation, not the intended Y_1. I hole this was understandable :)

    |= and &= should only be used with individual bits, not with enumerated values.

    Bob Marley said:
    UCSCTL4 |= SELA_1 + SELM_1 + SELS_1;

    Here it matters. After a reset, SELM_4 and SELS_4 are already set (or, to speak in bit values, SELM2 and SELS2), so this line will actually leave UCSCTL4 with SELA_1, SELS_5 (SELS_4+SELS_1 or more precisely SELS2|SELS0) and SELM_5 are set, which is surely not what you wanted.

    Bob Marley said:
    UCSCTL6 |= XCAP_2;    // Internal load cap (8.5pF)

    Here it happens once more. Since XCAP0 and XCAP1 are set after a reset, your line will result in (XCAP0|XCAP1)/*(XCAP_3, the default)*/|XCAP1/*(XCAP_2)*/ = XCAP_3. Again not the expected result.

    so eitehr contruct the whole register content directly by using = instead of |=, or filter the previous content before you add the bits:

    UCSCTL6 = (UCSCTL6&~(XCAP_3))|XCAP_2;

    XCAP_3 is the maximum value with all XCAPx bits set, so this line will first clear all XCAP bits and then set the ones for XCAP_2.

    |= and &= should be only used for setting or clearing individual independent biots, not enumerated bit combinations.

    Bob Marley said:
    // 32 x 32 x 12 MHz / 32,768 Hz = 375000 = MCLK cycles for DCO to settle
    __delay_cycles(375000);


    This is a very conservative setup. It's much faster to set up a timer to count on the reference clock and wait for 31*32+1 timer ticks (31 because you're already starting with DCO_0, so there are only up to 31 more DCO steps, and DCO_31 is DCO fault even with MOD_0, as you cannot modulate to DCO_32). Since MCLK changes with the progress, the first approach waits way too long, yet you cannot know how much too long (you don't know the actual frequency you start with and the progress).

    Alternatively you can check after every 32 timer ticks whether the FLL has again increased DCOx. If not, it must have settled. That's the fastest approach.

    Bob Marley said:
    there needs nothing to be done to run a 32kHz quartz as XT1 exept the setting of the pins P5.4/P5.5 which are belonging to XT1

    Almost. The XCAP setting might need to be adjusted, depending on the crystal specs. The default is I think okay for teh crystals TI uis using in tehir demo boards, but checking it twice is better. I didn't use a watch crystal ever. My applications are not ultra-low-power and I had always a fullspeed (HF) crystal attached. And out RTC needs are satisfied with an external I2C module which runs independently of the MSP supply (goldcap) and there I can trim the crystal with an adjustable load capacitor to almost the precision of our reference oscillator/counter. Manually with a screwdriver :)

    You seem to have deleted the question but I'll still answer: With the proper XCAP setting, you can operate a watch crystal without any external capacitors (PCB parasitic capacitance must be taken into account). In HF mode, however, the internal capacitors are disabled and wouldn't be large enough anyway for the increased driving currents and energy transport required for e.g. a 16MHz crystal. So you'll need external, low ESR ones then. (energy loss in the capacitors increases with the frequency, internal ones would most likely waste way too much or had to be way too large for the die)

  • Thanks again Jens-Michael Gross!!

    In the moment it will need some days until I can follow your advices and until I can answer with new experiences

    as I am out of office at the moment and Xmas is comming.

     

    I wish you merry Christmas and very nice days with your family or friends!

     

    PS: My next questions will displace  this reply.

  • Bob Marley said:
    I wish you merry Christmas and very nice days with your family or friends!

    Thanks and same to you.

    Bob Marley said:
    PS: My next questions will displace  this reply.

    Don't. Besides breaking the reply chain, edits won't be sent as mail and also won't push the thread on top of the thread list, so it might get lost unnoticed.

  • Thanks Jens-Michael Gross!

    You have been right. The reason of getting different frequencies despite using the same dividers were caused by wrong handling of operators.

    This has been my main fault but there were some other smaller reasons, too. So for example I needed to check my calculations for FLL again... .

     But now it  works very well!

     

    When I have got a little bit more time I will clean up this thread a little bit ( especially at its end) just for a better documentation.

     As I regard my problem as solved  it will be unimportant now for me if this post will be on top of the thread list.

    Thank you very much for your help!

     

     

**Attention** This is a public forum