TI E2E Community
MSP430 Ultra-Low Power 16-bit Microcontroller Forum
MSP430F5834A FLL and DCO
I cannot get the DCO / FLL to operate at the desired frequency.
1) I cannot set UCSCTL0 to estimated values. Each time I set it it changes. Seems input should only come from FLL. I have SCG0 set (bit value 1) which is supposed to disable the FLL. I note also that the code in void Init_FLL(uint16_t fsystem, uint16_t ratio) from the TI F5xx_F6xx_Core_Lib has the same problem. There USCTL0 is set to 0. adding code to read it back immediately and it is not 0. The code in the TI example is
__bis_SR_register(SCG0); // Disable FLL
UCSCTL0 = 0x0000; // Set DCO to lowest Tap
nTest=UCSCTL0 // added to test UCSCTLO reads back 0x14F8
2) It seems the lock condition of the FLL / DCO should be given by the following (assuming DCORSEL is set to the proper range)
DCO freq / prescale (FLLD) / divider (FLLN) = FLLREFCLK / divider (FLLREFDIV)
This is not working properly. Could it be related to UCSCTL0 is not close. It seems that it should not change when SCG0 is set.
Have you tried that on multiple chips or only on one?
I tried to recreate the problem, but it's working fine for me, I can set and read back 0x0000; just fine.
--------------------------------------------------------------------------------------Use the verify answer button to mark your questions as solved.
There is a chance that FLL and CPU are updating the UCSCTL0 register at the same time, resulting in a racing condition. It may happen when a reference clock is received (and therefore a register update is triggered) in the middle of a CPU operation that alters the same register. It's possible (but not confirmed to ever have happened) that the newly written value is not used for the update then, but the previous value.But even if this will ever happen, it is more than unlikely to happen all the time. And not with FLL disabled.On 5438 non-A, there was the UCS5 erratum, which caused the FLL not to accept changes to UCSCTL0-2 when a register was written more than once during one reference cycle. However, this erratum is no longer lsited for the 5438A.
One also not likely possibility is that your register definitions point to the wrong physical address. Then you're trying to alter a memory location that might be read-only. (and the TI code would be linked to the wrong addresses too, so having th esame problem).
It would be interesting to see the actually generated assembly/binary code. And check the register address.
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
Thanks for the replies.
I have got this working. I started over and rewrote all of the code. Along the way I developed a spread sheet that calculates values for the desired clock speed. Using the TI library was not working for me. Perhaps my fault. Anyway so as to help others I am attaching the Excel file. It does have macros and I cannot guarantee it but it works for me. Instructions are in the file. When I use the generated values to set up the DCO and FLL, I get good results.
I still cannot get the DCO to lock correctly with FLLN =1 so the macros will not allow this as a result. What happens is that the oscillator may start but will often jump frequencies. Not very good if you are dependent on the frequency. Note this is repeatable on the MSP - EXP430F5438 board. I am using XT2 as FLL source and some higher freqency crystals. Perhaps I will change in the final board.
The file has macros. I tested download by pasting the link into my browser. Upload of xlsm files is not allowed. Soo don't know what moderators might do or if others can download. Hope to help.
great data, found very useful. was getting frustrated with not being able to set DCO tap bits and MOD bits as they kept getting reset by FLL. Asserting SCG0 disabled the FLL and allowed me to update the DCO tap bits.
Thanks for info, and spreadsheet.
Thanks for sharing the spread sheet. I too had problem with DCO not locking when N was set to 1, not sure why.
Nimish Hirekodi I too had problem with DCO not locking when N was set to 1, not sure why.
Besides this, he FLL will be unable to lock if reference and target frequency are too close(fDCO=fREF or fDCO = 2*fREF or so). Because every single clock cycle would cause the FLL to update the DCO: either there was no reference tick when the DCO tick comes (DCO assumed too fast) or no DCO tick when the reference tick comes (DCO assumed too slow).The closer reference and target frequency are, the faster the adjustment updates happen. Worst case twice every clock cycle (once on the DCO tick, once on the reference tick).
Thanks for your detailed explanation. More details follow -
We need to configure SMCLK/MCLK at 24 MHz.. Our reference is a 12 MHz oscillator.
We tried to use DCOCLKDIV as input for SMCLK/MCLK with N =1 and n = 1 [ DCOCLKDIV = (N + 1) × (FLLREFCLK ÷ n) ]. This did not work.
Below configuration has worked -
__bis_SR_register(SCG0); UCSCTL0 = 0x0008;UCSCTL1 = 0x0060;UCSCTL2 = 0x0018; UCSCTL3 = 0x0054; UCSCTL4 = SELA__XT1CLK | SELS__DCOCLKDIV | SELM__DCOCLKDIV; UCSCTL5 = 0x0000;UCSCTL6 = 0x910C; __bic_SR_register(SCG0);
Nimish HirekodiUCSCTL0 = 0x0008;
Nimish HirekodiUCSCTL1 = 0x0060;
Nimish HirekodiUCSCTL2 = 0x0018;
Nimish HirekodiUCSCTL3 = 0x0054;
So the FLL is set up to adjust the DCO to 24* fREF = 24MHz. DCOCLK and DCOCLKDIV will be 24MHz.
1) use FLLD_1. This puts DCOCLK on 48MHz and DCOCLKDIV on 24MHz. The resulting DCOCLKDIV has a smaller jitter as two (modulated) clock cycles are joined.
2) use FLLREVDIV_5 to further increase the ref/DCO ratio to 32. 32 is the size of the modulation pattern, so one reference clock cycle matches one full modulation pattern. Of course, FLLN must be 0x20 then.
You'll get a more stable (less FLL updates) and less jittery DCOCLKDIV as a result.
Of course, this slightly increases the DCO current consumption as it now runs on 48Mhz instead of 24.
We'll use the values you suggest. Thanks for your support.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.