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.

FN_3 and FN_4 for SCFI0 (MSP430F47186)

Other Parts Discussed in Thread: MSP430F47186


I would like to know about FLL control for MSP430F47186.

What I am trying is to use 16MHz SMCLK and generate 57600bps UART function.

In my code, I set
  SCFQCTL = ((32 * 16)-1);
  FLL_CTL0 |= DCOPLUS;
  SCFI0 = FLLD_4 + FN_3;
and
  UCA0CTL1 |= UCSSEL1; // Use SMCLK
  UCA0STAT = 0;
  UCA0BR0 = (int)(277) % 256;
  UCA0BR1 = (int)(277) / 256;
  UCA0MCTL = (7 << 1);
etc, to obtain 57600bps UART.

However, with above setting, the UART bps seems around 70% of 57600bps.
I also confirmed that I2C clock signla generated from SMCLK is slow by a factor of 70%.


However, when I modified into
  SCFI0 = FLLD_4 + FN_4;
I obtained 57600bps and I2C clock signals are what I expected.

What's the difference of FN_4 and FN_3 in SCFI0 control register?

According to User Guide for MSP430F4xxx p5-16 , FN_3 is for up to 17.9MHz, and FN_4 is for up to 26.6MHz. So FN_3 seems O.K. for 16MHz SMCLK, but not correctly working.


Best regards

  • OKY said:
    ... What's the difference of FN_4 and FN_3 in SCF.I0 control register?

    According to User Guide for MSP430F4xxx p5-16 , FN_3 is for up to 17.9MHz, and FN_4 is for up to 26.6MHz. So FN_3 seems O.K. for 16MHz SMCLK, but not correctly working...

    For FN_3 and DCO=27, the Typ frequency is 17.9MHz like you said. Thus, typically, FN_3 may work for FLL 16MHz. However, not every chip is typical. In the worst case, the MIN frequency for that setting is only 10.3MHz. Thus that setting will not work for some of the chips.

    Both FN_4 and FN_8 work for FLL 16MHz.

  • Thank you very much, old_cow_yellow.

    So now all chip can be used with FN_4.

    Now I am sure that I should use FN_4 instead of FN_3.

    Best regards

  • Not related to the clock problem, but...

    OKY said:
    UCA0BR0 = (int)(277) % 256;
      UCA0BR1 = (int)(277) / 256;


    These two lines do two integer divisions. Which is rather slow because the MSP does not has a hardware divider.

    using

    UCA0BR0 = (277) & 0xff;
    UCA0BR1 = (277) >> 8;

    uses bit operations which take only zero and one clock cycle. In your case, since 277 is a constant, it may be that the compiler calculates the value at compile time and you won't get a speed penalty at runtime, but don't trust on that. And it's better to use binary operations whereever possible, just to not forget it when it really counts.
    The typecast to int is superflueous too, as signed int is the default size for constants unless they are too large for a signed int.

    BTW: even when using the FLL, one should wait until the DCO has settles before continuing. E.g. by counting 1024 reference clock cycles with a timer(easiest but always waits maximum time) or checking whether DCOx/MODx still changes (more difficult but faster) In your case yoU'd gotten a DCO fault because the FLL tries to raise DCO beyond its max. A sure sign for a wrong DCORSELx setting :)

  • Thank you very much, Jens-Michael Gross.

    About bit operations, you're correct. I had better use the bit operations instead of % and divisor. I had better to make it a rule for myself on this.

    And the "int" is not needed. 

    About wait until DCO stable, I will make sure the wait should be taken before using the DCO.

    Best regards

**Attention** This is a public forum