MSP430F5249: Clock setup using driverlib

The FLL needs some time to adjust the frequency. Use UCS_initFLLSettle() to wait for it.

PMM_setVCore() automatically increases the level in multiple steps.

I've resolved the problem for now. It is related to entering a low-power mode in my main loop.

- David

Clemens Ladisch said:

The FLL needs some time to adjust the frequency. Use UCS_initFLLSettle() to wait for it.

PMM_setVCore() automatically increases the level in multiple steps.

Hi David,

I'm glad to hear that this has been solved now.
One last comment from my side would be that measuring the clocks during and active debug session might also cause a problem. So you could also check if the issue can still be seen without the MSP-FET connected.

As you've stated that it's working for your purposes I will go ahead and close this thread.
Please reply to re-open in case there are other pending questions.

Thanks and best regards,
Britta

Britta,

There is still something strange here, and I did not want to just move on and ignor it.  My full code is pretty simple.  Initialize the clocks, setup a timer interrupt, and enter LPM3.  In the timer ISR I send something out the USCI_A0_UART.  I actually noticed the problem because the UART communication was failing.  I traced the issue to the wrong clock frequency coming out of the DCO/FLL (and hence the UART was at the wrong baud rate).  This happens with or without the debugger connected.

I replaced the driverlib clock initialization with manual configuration, and the problem went away.  The main difference was an extra delay loop in the manual setup before polling for oscillator fault.  If I go back to the driverlib version and add the same delay after the call to UCS_initFLL(), the driverlib version works.  Alternately, if I remove the __delay_cycles(782000L) from the manual version of the FLL setup, it too fails (that is, MCLK is wrong is the UART comms fails).

I can also look at the MCLK output signal on P4.7.  If I disable interrupts and halt the debugger (while in LPM3), the MCLK signal is dead (flat lined) which is to be expected because the DCO is off.  So far so good.

If I set a breakpoint in the timer ISR however, I can see the MCLK is incorrect without the delay for both the driverlib and manual config versions.

So why do we need this delay?  I took the delay from the TI examples for the F524x devices.

I can send my CCS project if you want to go that route.

Regards,

David

Hi David,

thank you for elaborating on this.
I'd like to reproduce your findings with other hardware to see if there is indeed a software issue related to the driverlib examples.
If I understood you correctly you said that the issue is present when using the exact example from the latest driverlib version, correct? Could you quickly state which exact example you use?
I'd also appreciate if you could send your CCS project for me to test. I'd then come back to you to discuss my findings.

Thanks and best regards,
Britta

Hi Britta,

No, I did not use exactly a DriverLib example as the examples do not do what I am doing, specifically enter LPM3 mode after setting up the clocks.

The problem can be boiled down to a single question to start, and we can get way from DriveLib for now.  In the MSP430F524x software examples SLAC620.f, example msp430F524x_usc_10.c, it initializes the clocks as follows:

I have done similar in my code.  Now if you enter LPM3 mode for your main loop afterward, the clocks are correct when you exit LPM.  That is, MCLK is 25 MHz.  You can see it on a scope.  But, if you remove the __delay_cycles(782000) statement from the above code, MCLK is not correct.  It is about 7.5 MHz.

The question is why do you need this delay?  The do{} loop after the delay checks for DCOFFG faults.  If the DCO was not stabilized, you would continue looping here until it is.  Right?

EDIT: OK, I read more and see the DCOFFG flag is only set when the DCOx is set to either 0 or 31.  It is not detecting stabilization of the DCO but rather endpoint settings.  Still, even without the delay the FLL should eventually stabilize at 25 MHz.  It doesn't.  It never recovers once you enter LPM3 the first time.

END_EDIT

The lack of the delay is why DriverLib fails to work correctly when I enter LPM3 mode as my main loop.  DriverLib does not have this extra delay in the function UCS_initFLL().  So we could ask why DriverLib doesn't have the delay if it is required.

I have attached my CCSv8.1 project.  As it is configured now, it uses manual configuration of the clocks (not DriverLib), and I left the delay in there.  So, everything works.  You can observe MCLK on a scope at pin P4.7 as 25 MHz.  Now go in to clocks.c and comment out that delay.  When you run the code now, MCLK is about 7.5 MHz.  Realize that I am spending much of the time in LPM3 here where MCLK is inactive.  The scope triggers off MCLK however, so you only see MCLK when it is active.  I have a timer that is waking the system up at a 2 Hz rate.

MSP430F5249_UsciA0_UART_DriverLib_2018Aug24.zip

Regards,

David

Hi David,

thanks again for posting your findings here.
I'm glad you've worked it out but understand that this is tricky. I'll see if it makes sense to somehow further highlight this in our documentation.
Thank you for sharing this with the E2E community. I'm sure it will help other running into the same issue.

Best regards,
Britta