MSP430F5438 and LPM3/LPM4 guidelines

Nikolaos Agianniotis

Other Parts Discussed in Thread: MSP430F5438, MSP430F169

I would like to get some guidelines regarding putting the MSP430 uC in a low-power mode. I am mostly interested in using the LPM3 and LPM4 modes. Let me first make a list of the peripherals that the uC uses :

three SPI interfaces (connected to different peripherals, like a flash memory, digital sensor etc.)
one I2C interface, connected to a digital sensor
the ADC12
the timers (A and B)

I use a 32768kHz crystal connected to XT1 and use this clock as the main clock source for all clocks needed. During normal operation the max clock (MCLK) can go up to 18MHz or more. Periodically, I would like to put the device in low power mode to save energy, either in LPM3 or LPM4. The points that trouble me are the following:

When in low power mode, what should I do with the USCI peripherals that I have previously configured and initiated? Does it matter if I leave them running or should I put them in reset? What I haven't understand is whether these modules draw current when there are no active transactions in progress (they are actually idle). The USCI peripherals draw current through their BRCLK, isn't that correct? Hence, I am thinking that while there are no transactions no current should be required for them.
Another concern of mine is the state of the pins of the device. The pins can be divided in 3 categories in terms of functionality:
1. Unused pins: These pins have been left unconnected on the PCB. What is the best configuration for them for low power? Output direction or input direction with internal pullups (or pulldowns)?
2. Pins used as analog inputs for the ADC: Do I have to treat these pins as unused pins during sleeping periods and configure them as inputs with internal pullups (or pulldowns) or they should be left at their alternative function (inputs for the ADC)?
3. Pins used for the digital interfaces (connected to external peripheral devices). Do I have to change the functionality of these pins, configure them as GPIOs, with output or input direction with internal pullups (or pulldowns)? Or should I keep them as they are?
Another concern is how to wake-up the device from LPM. My intention is to wake it up in a time based fashion, i.e. after 1 min or something like that, without any other external interrupt. What is the best way to do that, in order not to increase the current consumption? I was thinking of either using one of the timers available (Timer_A / Timer_B) or the Watchdog (in interval timer mode). The difference is that the Watchdog can use the VLOCLK, whereas the timers can only use the ACLK. Is there any observable difference in the power consumption of the two clocks? In fact, as far as I understand, the VLOCLK is active during LPM4 whereas ACLK is not, isn't that correct? Hence, I could put the MCU in LPM4, enable the VLO and wake it up with the WDG or put it in LPM and wake up using the Timers.

Additionally, I have some questions regarding the clock system of the uC.

First of all can a board be fully operational without the need of an external crystal, just by using the REFO? What would be the drawback of such a solution?
Moreover, which solution consumes less current, using the REFO or the XT1?
And lastly, if I have an external crystal of 32.768kHz connected at the XT1 pins but the function of these pins is not changed to the analog function, what happens to the XT1? Does it remain disabled in that case? And where does the ACLK is sourced from? Because in my code, I haven't configured properly the XT1 pins ( I just start using the device after power-up ) and however no problem exists. I guess that in that case the XT1 is never enabled through-out the program? Can I use the device only at this mode, without enabling the XT1?

Apologizing for the length of my post, I would like to say that I would be really grateful if you could give me some directions towards minimizing the current consumption of the uC during sleep.

Thank you in advance for your help.

Nikos

over 15 years ago

0 Jens-Michael Gross over 15 years ago

Guru 227245 points

Nikolaos Agianniotis said:
When in low power mode, what should I do with the USCI peripherals that I have previously configured and initiated?

You should set their SWRST bit to shut them off. While they won't draw much current themselves while idle, they cause their assigned system clock to stay active (unless you disabled the conditional clock requests), so even LPM4 won't deactivate SMCLK or ACLK if there is an active USCI sourced by them.

Nikolaos Agianniotis said:
Unused pins: These pins have been left unconnected on the PCB. What is the best configuration for them for low power?

Pullups cost power. The lowest power consumtion should be low outputs. Inputs without pullup might float which can cause transitions in the input schmitt trigger. Up to maximum frequency.

See Section 1.6 of the users guide.

Nikolaos Agianniotis said:
Pins used for the digital interfaces (connected to external peripheral devices). Do I have to change the functionality of these pins, configure them as GPIOs, with output or input direction with internal pullups (or pulldowns)? Or should I keep them as they are?

It depends ont he peripherals and the state of the connection. Sometimes leaving them as-is fits best, sometimes switching to input may be better. There is no general advice possible. Figure out yourself where currents may flow and where not.

Nikolaos Agianniotis said:
My intention is to wake it up in a time based fashion, i.e. after 1 min or something like that, without any other external interrupt. What is the best way to do that, in order not to increase the current consumption?

I think th elowest current consumption is to use any of the timers clocked by the VLO (which is very inaccurate but also very low-power). The timer ISR will then fire up the DCO and any other crystals when being triggered. Keep in mind that when the IRQ comes, any crystal might be offline, so the CPU is clocked by DCO until the crystal is on again. In your case, it might be better to deactivate the crystals totally before entering LPM, and when you need them, fire them up completely outside the ISR (leaving LPM). THis way they won't consume power even in the short periods of timer wakeup in a futile attempt to come oniline while this short interruption of LPM lasts.

Nikolaos Agianniotis said:
The difference is that the Watchdog can use the VLOCLK, whereas the timers can only use the ACLK

Yes and no. It doesn't consume noticeabley more power to source ACLK by VLOCLK and use it on the timers than using VLOCLK directly on the WDT. It depends on whether you want to use the WDT in its original role or not. But if you have other modules using ACLK, they will be clocked too - it all depends on project configuration.

Nikolaos Agianniotis said:
First of all can a board be fully operational without the need of an external crystal, just by using the REFO? What would be the drawback of such a solution?

. Besides REFO, there's always the DCO and the VLO available. With DCO usually being the main clock source. But yes, in theory, you can operate solely on REFO. MCLK, SMCLK and ACLK can be sourced by REFO if you want it. (and never need more processor power). REFO, however, isn't as precise as a watch crystal (still +-1.5% tolerance). Also, a DCO trimmed by REFO for a higher frequency will only have an average frequency with a certain jitter. Also, even this average frequency has the same +-1.5% tolerance.

Nikolaos Agianniotis said:
Moreover, which solution consumes less current, using the REFO or the XT1?

REFO consumes more power (3µA compared to max 0.3µA) and is less accurate. (see the datasheet for values). However, cheap capacitors or crystals can significantly increase the LFXT1 power consumption.

Nikolaos Agianniotis said:
if I have an external crystal of 32.768kHz connected at the XT1 pins but the function of these pins is not changed to the analog function, what happens to the XT1? Does it remain disabled in that case?

It then is simply a capacitor across these pins. Bascially, a crystal is a frequency-dependent capacitor.

Nikolaos Agianniotis said:
And where does the ACLK is sourced from?

If ACLK is set to LFXT1 and LFXT1 has its fault flag set (no crystal or not running), ACLK is sourced by REFO. Else to DCOCLKDIV. See chapter 4.2.12 of the users guide.

0 Nikolaos Agianniotis over 15 years ago in reply to Jens-Michael Gross

Intellectual 290 points

Thank you very much for your reply and for the time you consumed reading my post! I think that all my questions have been answered.

Nikos

0 Jens-Michael Gross over 15 years ago in reply to Nikolaos Agianniotis

Guru 227245 points

You're welcome.

If you encounter anything during your experiments that could be of interest for others, please share this information with us.
That's the payback for the time we invest.
Why inventing the wheel over and over again (as long as this invention does not belong to our employer)? That's why most of us stay here after their initial question ahs been answered.

0 Pentleman over 15 years ago in reply to Jens-Michael Gross

Intellectual 990 points

I have a similar set of requirements as stated above with the addition of the need to support 3 UARTS and the following baud rates 9600, 38400, and 115200. The application is a data logger that is deployed 2000m down in the ocean for 2 to 3 years (approx. 4 to 10 degree C operating temp). The MSP430 will have external power control circuitry so I need a reliable power on and clock stabilization.

I've designed the board to use XT1 and a 32768 crystal.

I've looked at the User Demo code that has come with the EXP5438 experimenters board, looking at the hal code and as well the examples. With the examples as a guide and the details discussed in the MSP430F54xx family UG and the chip specifics in MSP430F5438 doc I believe I understand how the device is supposed to work.

The problem I'm having is getting SMCLK (and MCLK) to be 5.76MHz

The XT1 clock appears to be stable, as I'm not seeing faults or timeouts waiting.

When changing the mulitplier for the FLL, I do not see changes in SMCLK output on P1.6 - I am using a scope and see approx. 100nsec square wave (10MHz). I've left the commented out settings I've tried all with the same result - 10Mhz SMCLK..

Also, after loading and running my code in CCS 4.2.1, I see emulator issues with subsequent code load and I need to power cycle my board to not have emulation errors - this behaviour started after I began mucking with the UCS. Here's my UCS clock setup code:

I'd appreciate it if anyone can spot the problem wih clock setup.

Thanks,

thom

void msp430_clock_init(void)
{

//                MSP430F5438 (not A)
//             -----------------
//        /|\ |              XIN|-
//         | |                 | 32kHz
//         ---|RST          XOUT|-
//            |                 |
//            |            P1.6 |--> SMCLK = 5.76MHz
//            |                 |

WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer

// for debug, put SMCLK out on P1.6
P1SEL |= 0x40; // select SMCLK output special func

   // Initialize LFXT1
   P7SEL |= 0x03;                            // Select XT1
   UCSCTL6 &= ~(XT1OFF);                     // XT1 On
   UCSCTL6 |= XCAP_3;                        // Internal load cap

   // Loop until XT1 fault flag is cleared
   do
   {
      UCSCTL7 &= ~XT1LFOFFG;                  // Clear XT1 fault flags
   } while (UCSCTL7 & XT1LFOFFG);               // Test XT1 fault flag

// fDCO(3,0) DCO frequency (3, 0) DCORSELx = 3, DCOx = 0, MODx = 0 0.64 1.51 MHz
// fDCO(3,31) DCO frequency (3, 31) DCORSELx = 3, DCOx = 31, MODx = 0 6.07 14.0 MHz

   // Initialize DCOCLK to 5.76MHz (good for SMCLK to gen baud rates 115200, 38400, 9600
   __bis_SR_register(SCG0);                  // Disable the FLL control loop
   UCSCTL0 = 0x0000;                         // When FLL selected, DCOx, MODx are adjusted automatically by FLL (p67 of MSP430F5xxx family UG)
   UCSCTL1 = DCORSEL_3;                      // Set DCORSELx=3 for DCO = 4.9 MHz
            // TODO: bit.0 is modulation, set to enable (not sure)
   //bit.12-14 are FLL loop div, 000=1, 001=/2, 010=/4
   // 0b 0 011 000 <n nnnn nnnn>
   //UCSCTL2 = FLLD_1 + 175;                    // Set DCO Multiplier for 5.76MHz
                       // (N + 1) * FLLRef = Fdco
                      // (175 + 1) * 32768 = 5.76MHz
                       // Set FLL Div = fDCOCLK/2
   //UCSCTL2 = FLLD_2 + 100;
   UCSCTL2 = 0x3000 + 100;
   //FLLREFDIV=bit.0-2, FLLREFCLK=bit.4-6=000 (XT1), bit.0-2 000=/1, 001=/2, 010=/4, 011=/8, 100=/12, 101=/16
   //UCSCTL3 = 0x0000;       // bit.4-6 FLLREFCLK SELREF
   UCSCTL3 = 0x0001;       // bit.4-6 FLLREFCLK SELREF
   // SMCLK does not change - stays at ~10.0 Mhz

   // 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 5.76 MHz / 32,768 Hz = 180000 = MCLK cycles for DCO to settle (wow)
   //for(indx=0; indx<3; indx++)
   // __delay_cycles(60000);

   //ACLK src = bit.8-10, SMCLK src = bit.4-6, MCLK src = bit.0-2
      //000 XT1CLK UCSCTL4_L Bits 6-4
      //001 VLOCLK
      //010 REFOCLK
      //011 DCOCLK
      //100 DCOCLKDIV
      //101 XT2CLK when available, otherwise DCOCLKDIV
   // 0b 0000 0001 0011 0010   XTQ MCLK=DCOCLK, SMCLK=DCOCLK, ACLK=REF0CLK
   UCSCTL4 = 0x0132;  // MCLK=DCOCLK, SMCLK=DCOCLK, ACLK=REF0CLK

   UCSCTL5 = 0x0000;  // ACLK src divider at pin, ACLK src divider, SMCLK src divider, MCLK src divider

UINT16 timeout = 60000;

UCSCTL6_L |= XT1DRIVE1_L+XT1DRIVE0_L; // Highest drive setting for XT1 startup

__bic_SR_register(SCG0); // Enable the FLL control loop

   P1OUT |= BIT3;       // DEBUG bit
   while ((SFRIFG1 & OFIFG) && timeout--) // check OFIFG fault flag
   {
      P1OUT &= ~BIT3;      // DEBUG bit
      UCSCTL7 &= ~(DCOFFG + XT1LFOFFG + XT1HFOFFG + XT2OFFG); // Clear OSC flaut Flags fault flags
      SFRIFG1 &= ~OFIFG;           // Clear OFIFG fault flag
      P1OUT |= BIT3;
   }

   // it timeout occurs, hang here and wiggle debug bit
   while(timeout == 0)
   {
      P1OUT |= BIT3;
      P1OUT &= ~BIT3;
   }

}

0 Jens-Michael Gross over 15 years ago in reply to Pentleman

Guru 227245 points

Thom Maughan said:
UCSCTL2 = 0x3000 + 100;

This should result in a multiplier of 800. Which gives 26MHz (something that cynnot be reached with RSEL3, even if it were valid). RSEL3 is only 0.64..14MHz and only 1.51..6.07MHz are guaranteed. You're hitting the maximum that the DCO can give.

Thom Maughan said:
//UCSCTL2 = FLLD_1 + 175;

Even this will result in a factor of 350 = 11.5MHz. (FLLD_1 is a /2 divider as it is the second, 0-based, FLLDx option. I guess you meant FLLD__1, which is the divider 1)

All of the settings you tried are hitting the maximum DCO frequency for RSEL3, which happens to be 10MHz on your specific device.

The correct setting would be UCSCTL2=176 for 5.767168MHz or 175 for 5.734400MHz. Keep in mind that both, FLL and modulation, only give an average frequency. In case of the FLL, the average frequency is guaranteed over a larger interval (is it 1/Fref?) while the modulation will produce its average output over 32 clock cycles. This means, that individual clock cycles can still be much (up to 8%, the distance between two DCO taps) higher or lower than the expected frequency.

0 Pentleman over 15 years ago in reply to Jens-Michael Gross

Intellectual 990 points

Jens-Michael, Thanks for the reply.

I was misreading the effects of the FLLD bits in UCSCTL2 register definition from figure 3-1 in the users guide. I had been experimenting with various values (0x3000 selects /8) to operationally understand the effect of the divider thinking it divided the frequency not multiplied.

For the benefit of others trying to generate a baud clock using a 32768 crystal on XT1

1) Pick a DCOCLK that will divide to give the desired baud rates balancing DCOCLK freq with processor power consumption. I need 9600, 38400, and 115200 bauds, so I selected 5.76 Mhz as the desired freq.

2) Understand the UCS. Refer to Figre 3-1 diagram for the FLL in the UCS (MSP430F54xx family uses guide), but then make sure to read section 3.2.6 Digitally-Controlled Oscillator (DCO) of the users guide, specifically the formula for DCOCLK:

DCOCLK Freq = D ´ (N + 1) ´ (FLLREFCLK Freq / n), where n is set by FLLREFDIVx (n = 1, 2, 4, 8, 12, or 16) in UCSCTL2, and FLLREFCLK source is selected by bits.4-6 in UCSCTL3 (000 = XT1 (32768)) and bits.0-2 in that register select FLLREFDIV (n=1 is selected in the 5.76Mhz case).

For a desired DCOCLK = 5.760 Mhz, with n=1, and D=1, the value of N, bits.0-9 in UCSCTL2 is determined by the forumula:

N = 5760000 / (D * FLLREFCLK / n) - 1 = (5760000 / 32768) - 1 = 175.8 - 1 = 175

Pluggin the integer value of N back into the formula DCOCLK Freq = (175+1) * 32768 = as noted by Jens-Michael, UCSCTL2 = 175 yields 5.767168MHz which is about 0.125% off from the desired 5.760 Mhz which is close, but with the caveat noted about the modulation effect of up to 8% between the DCO taps.

Results from testing:

When these UCSCTL2 and 3 values (D=1,n=1, N=175, XT1=32768) are used and the SMCLK is output on P1.6, I'm measuring with a Tektronix scope (TDS2024B) that the frequency is coming in dithering between 5.632 to 5.633 Mhz with is 2.3% off.

Experimenting with different values (note I'm running the MSP at 2.7v), I found 179 to produce the desired frequency at room temp.

UCSCTL2 = 0x0000 + 179; // 175 = 5.632 Mhz (Tek TDS2024B), 176 = 5.664 Mhz, 177=5.696 Mhz, 178 = 5.73x Mhz, 179 = 5.760 Mhz

It should be noted, that since I started changing the default UCS, I consistenly get "Failed to load program... "Cannot write target"" in CCS 4.2.1 when trying to load. The work around is to power cycle the board before the load and then the program loads and runs fine. I'm suspicious there is another register that isnt set right.

I've had 9600 baud working with the default UCS settings (along with SPI peripherals such as atmel AT45DB041 data flash and microSD card and i2c for a dallas DS3231 RTC). I've now got the task of re-setting up each peripheral with the new internal clock settings. SMCLK is planned for I2c, SPI and UART.

Thanks again for the help.

0 Jeff Tenney over 15 years ago in reply to Pentleman

Guru 12160 points

Thom,

Just curious about your application. I'm about to deliver a dozen satellite tags that will spend 2 to 3 years at the bottom of the ocean just waiting for a specific event. Then they will surface and uplink the timestamp of the event and hopefully be recovered. Is your equipment riding in the same payload with mine?

Jeff

PS - If you are planning on running the FLL continuously, you should carefully reconsider. Erratum UCS10 causes UART I/O to fail periodically if you're using 19200 baud or faster. Characters are transmitted/received incorrectly. I use the FLL to run a DCO "alignment" as a discrete operation during UART down time, and then I (carefully) turn off the FLL at the end of the alignment. I also use a 32kHz quartz as the reference, but I picked 7.3728 MHz (32768 * 225) because it is very baud-rate friendly. (The factorization has 2 three's and 2 five's, and most baud rates don't have more three's or five's than that.)

0 Pentleman over 15 years ago in reply to Jeff Tenney

Intellectual 990 points

There is a researcher studying low rate fluid flow thru bore holes in the sea floor. The researcher is at the University of Alaska and is a collaborator with MBARI (an ocean research institute). I took this on as a consulting job (pay is nearly pro bono though) to construct a data logger that logs the flow rate (and some other sensor data) from a siemens electromagnetic doppler flow meter that is coupled to the bore hole. The siemens flow controller, idles back to 50 uA and I should be able to get my logger to idle well below 30 uA. Logging is done a couple times a day, and then once a week it's done every 30 minutes. This goes on for 2 to 3 years. I'll possibly be adding an optical IO device (a design in my head at this point) to allow an ROV that dives at the site to retrieve data from the logger.

Does this sound like a related project to the one you are working?

I have written most of the peripheral drivers with the default UCS setup and have the flash memory, rtc and 9600 baud uarts working. I need to get the higher UART baud rates working in order to interface to the serial devices and have been working this (midnight engineer style) since last weekend.

The cruise for deployment is in August, but there is a lot of test and integration and the data logger needs to be working ideally by the end of Feb (yikes). I may have picked a problem child processor with the MSP430F5438 given that I am now not able to reliably download code to the processor now that I've adjusted the UCS to 5.76. FYI, I considered 7.3728 MHz, but thought I'd save a little power clocking slower and for the baud rates I need to support (9600, 38400, 115200) 5.76Mhz looked ok.

Because I've found ultra low power MSP430 software design to be a bit tricky to get to the marketing numbers in a real application, I designed some external processor power control circuitry around a DS3231 RTC (2 ppm time drift) so I have the luxury given the low duty cycle of logging to be a little wasteful when the processor is on so 7.3728 is definitely an option.

I have downloaded my code to the MSP430F5438 Experimenters board (has an A chip) and first download went no problem, the Experimenter board now exhibits the same problem with successive downloads causing FET and CCS instability. I am going thru every bit in every register to try and understand what could be causing the problem. I think I may just punt on the XT1 32768 since I believe it may be too fragile to be trusted (I had similar problems with an MSP430F169 back in 2001 or 2002 and wound up just putting a clock osc on the MSP and burning a couple of mA). I've successfully used the LTC6900 low power osc on other MSP430 projects to dodge the XT1 problems and am considering resorting to that approach - I'll decide by Saturday whether to respin the board.

Thanks for the pointer on the FLL problem, I have not looked thru the errata lists much yet but it is likely time to do so. If I can get code downloaded, it is the direction I'm heading (partly due to how long it takes to stabilize). I've made a number of silly mistakes on the UCS so far and I believe it is likely that I've done something, or not done something that is causing the grief.

If you don't mind sharing your UCS or UART setup code, it would be useful to compare register settings.

Thom

0 Jeff Tenney over 15 years ago in reply to Pentleman

Guru 12160 points

Thom,

Small world! I think it's the same project, but I can't be sure. Monterey Bay Aquarium Research Institute is studying sediment transport events in submarine canyons.

I'm going ahead on the assumption that I have a vested interest in the success of your project. ;-)

A few thoughts after reading your code:

- Don't write to UCSCTL0. It's under FLL control and your write may conflict, even writing zero.

- Your fault timeout detection doesn't seem to work. The post-decrement operation leaves <timeout> set to 0xFFFF after a timeout condition, but your timeout catch looks for 0.

- Can your Tek scope show you a "trigger frequency" measurement? If so, it is infinitely better than having it measure a single cycle and do the math. See JMG's point about any given cycle of the DCO. Based on your quoted measurements, you might already be on top of this one.

- Having a 2.3% clock error when your reference is a 32768Hz quartz crystal is a red flag. It should be lower (< 0.1%). Can you drive ACLK from XT1 and then turn on external ACLK? Then you can measure XT1 at ACLK.

The register values I use for the UCS are here:

UCSCTL2_L = 225-1;     // 32768 * 225 = 7372800 DCOCLKDIV
                       // 7372800 * 2 = 14745600 DCOCLK

UCSCTL1_L = DCORSEL_5; // DCORSEL_5: 6.0 ... 23.7 MHz

// UCSCTL3 = default setting OK: XT1 / 1 as FLL ref
// UCSCTL4 = default setting OK:
// DCOCLKDIV drives SMCLK, MCLK
//   XT1CLK drives ACLK
//
// And all other UCS registers left at defaults.

If you post updated / current code in a new thread, maybe folks will search for an explanation for your JTAG / power cycle issues. I'll definitely take a look.

Jeff

0 Pentleman over 15 years ago in reply to Jeff Tenney

Intellectual 990 points

Jeff,

Thanks for your post. After quite a bit of struggle, I was finally able to download code again - this with my UCS code disabled. Once I got back the ability to download I reviewed the code and was able to find the UCS clock setup problem - your note about UCSCTL4 defaults was helpful, thanks.

I had setup UCSCTL4 incorrectly - MCLK was being driven by VLOCLK and ACLK was being driven by DCOCLK. CCS is now reliably downloading code again.

ACLK, SMCLK and MCLK have been output on pins P1.0, P1.6, P2.0. I was gathering data with an older scope by measuring period, but I do have access and have verified frequency using trigger. SMCLK measurement is dithering from approx. 3.89 MHz to 4.08 Mhz. I still need to check if XT1 is properly functioning - I'm using XT1 fault check code I borrowed from examples and it's on my todo list to verfiy that I'm not having a fault and operating off REF0CLK.

I switched to 4.00MHz for SMCLK and MCLK based on bit error in table 15-4 for UART setup since after reviewing uart register settings from code I'd pulled in from other examples I also found incorrect settings. The uarts are now functioning (tested at 9600, 38400 and 115200), but not thoroughly tested. Routines for i2c and spi appear to be working, but also on my list to thoroughly review reg settings against the users guide.

Thanks again for your help.

Thom

0 Jens-Michael Gross over 15 years ago in reply to Pentleman

Guru 227245 points

The resulting frequency of the FLL is quite accurate. It is, however, only accurato over a certain interval. It seems readonable to say that it can vary over two reference periods (which would be ~60µs) but will be correct in average. But individual clock pulse can be far off. First due to FLL adjustment lazyness (the FLL will not adjust based on ecvery single clock pulse but only after a certain number of pulses) and second by the DCO modulation jitter (which is also up to 1.2% off for every single cock pulse)

So you cannot simply let the scope calculate the timing error based on analysis of a single clock pulse (that's how they usually work). You need to look at an interval and count the number of pulses for the average frequency.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430F5438 and LPM3/LPM4 guidelines