MSP430F5510 and FLL

Carloalberto Torghele said:

Therefore over many microcontroller my MCLCK will be:
4.063232 +- 0.4175/2 = 4.063232 +- 0.20875 Mhz

The min/max values are really worst case values. Usually, you'll have a minimum and maximum much closer to each other. But two RSEL settign swill always overlap and the rate of frequency increase is also specified. Additionally, teh steps of the DCO are not equidistant. From DCO_x to DCO_x+1, the increase is also specified. It is more an exponential increase than a linear one.

But basically you're right. That's why there is the modulation. Modulation lets the DCO run for some ticks on DCO_x and for some on DCO_x+1, giving over a range of 32 ticks an average frequency that is between DOC_x and DCO_x+1. With a significant jitter.

That's the static DCO configuration.

The FLL goes one step further. It counts the number of DCO ticks between two reference ticks and adjusts the DCO (inlcuding the modulation) up or down according to the result. So over a longer time period, DCO matches the reference with the given factor. (here I wouldn't go with a x4 divider, but rather increase the factor, as the divider would reduce the adjustment interval)

When using the internal REFO, the results are good enough so that I can get a reliable 115200Bd connection using the hardware uart.

Carloalberto Torghele said:

Do you think it's possible to do a software uart with a 19200 baudrate?

It rather depends on the absolute MCLK frequency. For 19200Bd, the bit time is 52µs. The FLL update interval (without divider) is 1/32768 = 30.5µs. So for the bit timing, the DCO should be as correct as it can get. On 4MHz MCLK, you have 218 MCLK cycles per bit. So the modulation jitter is swallowed by the long time. Leaves only the jitter between two FLL adjustment steps, which is ~1/32 of two DCO_x steps.
Also, 218 clock cycles should be enough to do all the calculations. However, a higher MCLK would be better, especially if you want full duplex. And allows doing the job more precisely on sub-bit timing. Letting a capture and a compare unit do the clock-synchronous timing instead of doign it yourself based on CPU cycle counting, will get even more precise results. IIRC, there is an example fo a timer UART implemented in the LaunchPad demo application.

 

Carloalberto Torghele said:

What i can understand from the manual it's that the modulation produce an intermediate effective frequency between F(dco) and F(dco+1), reducing EMC intereference.

EMI reduction is just a side effect.

Basically, the DCO is an R/C oscillator that oscillates on a base frequency which you can select with RSEL. Then you can switch on several additional resistors that 'tune' it higher.

What modulation does is with every output tick of the DCO, it switches these 'tuning' resistors to the next higher settign and back based on the modulation pattern, from 0 of 32 tick to 31 of 32 ticks, evenly distributed. So the effective DCO output consists of some longer (DOCx) and soem shorter (DCOx+1) ticks. The resulting average frequency then is somewhere between a full DCOx or DCOx+1 setting.

Carloalberto Torghele said:

From the first thing quoted i understand that the right thing it's option 2. But from the second thing quote i would say that the modulation are 32 additional finer steps.

Any single DCO tick is either DCOx or DCOx+1. But if you divide DCO by 32, the resulting (1/32th) frequency has no jitter anymore. And is a finetuned, constant frequency somewhere between DCOx/32 and DCOx+1/32.

If you use the DCO for e.g. UART, then you usually have a divider far bigger than 32 and the clock jitter caused by modulation doesn't count anymore.

The FLL, however, adjusts modulation first, and DCOx only if modulation has reached min or max. So the superimposed jitter caused by the FLL is only a slight change in the modulation and jitter pattern of the DCO, but this change happens only on every reference tick. So it is well in the range of an UART bit clock. Normally not a big problem since it is small. But it is noticeable and should be considered when debugging connection problems.

Sometimes, switching to a different RSEL setting (the ranges overlap) results in a better modulation/FLL pattern and increases the connection.

It is even possible to drive the DCo with a frequency far above the maximum for MCLK and only use a divided DCO for them. In this case, the modulation jitter has already been smoothed by the DCO divider.

Carloalberto Torghele said:

4.063232 * 0.12 = 0.4876 Mhz
and therefore if you assume that my frequency it's in the middle between two taps, the errore is +- 0.2438 Mhz

If you switch from frequency to cycle time, things get clearer.

let's assume that the output frequency on DCOx is 1MHz = 1µs cycle time. On DCOx+1 it is 2MHz = 0.5µs cycle time (I know that's more than 1.12 :) ).

Then with a modulation of 0, you'll get 32 clock cycles of 1µ = 32µs total modulation cycle time = 32/32µs = 1MHz.
With a modulation of 1, you'll get 15 clock cylces of 1µs, one woth 0.5µs and another 16 with 1µs, resulting in 31.5µs total cycle time and 32/31.5µs = 1.01587MHz average frequency (still you only have 1MHz and 2MHz ticks). For modulation = 2 it is 32/31µs = 1.03225MHz. You can see, the second step is bigger than the first.
With modulation=32, you'll get 32/16.5µs = 1.9393MHz. The last step is 0.0606MHz while the first was only 0.01587MHz. Still each individual tick was eitzher 1MHz or 2MHz.

Carloalberto Torghele said:

So I assume that one x 32 is due to the modulator ticks and the other x 32 it's due to that in the worst case you have to scan all the DCO_xs.

Yes.

Carloalberto Torghele said:

So from that i would say that also the modulator it's based on FreqFLLref.

No, not based on, adjusted by (or modulated by, once you found the best match, as there is a very high probability that you won't find a perfect match but rather an over/undershoot).

You can halve this time by manually setting the DCO into the middle (or another start value that is near the likely final value, based on experience). Or you can disable modulation, so you spare the 32 modulation steps and wait until the FLL starts steppign back and forth, then enable modulation again to get nearer.
In theory, the optimum algorithm should be able to rech the perfect result in ~48 reference ticks. However, even worst case is ~30ms only. Which in teh very most applications is not worth mentioning. You only need to know it and wait for this time before you enter any critical timing.

Carloalberto Torghele said:

Is it a configuration (1 Mhz from 32768 Hz) which has to be avoided?

The update mechanism is a bit more complex than liek I described it. It is not only updated on each REF tick. It is rather updated when either a REF tick happened without the required number of DCO ticks (too slow) or when the required number of DCO ticks happened without a REF tick (too fast).

But basically you're right, in this constellation, there may be more updates than modulation patterns. However, the increment/decrement of the modulation does not mess things up that much. The pattern is rather squeezed/relaxed, so the maximum effect is one more or less 'high' pulse during the remainder of the pattern.

Unless you're very sensitive to clock jitter and the jitter of the jitter, you can ignore this.