MSP430FR2433: DCO without FLL operation

Hello,
the DCO of the FR2433 is not intended to be used without an active FLL.
I understand your intentions, but disabling the FLL would anyway not help you by any means. The locking of the FLL does not mean, that you will not get any DCO clock until it is not locked. It means the DCO clock will not meet the reference accuracy.
Furthermore on the point of the DCO dependency over temperature. We're not specifying this value, as the DCO anyway cannot operate without FLL with these devices, but the temperature drift would be definitely higher than the one of the REFO. In general, when looking at an MSP430 clock system, you can assume in case there is an FLL, the DCO being not stable over temperature, and vice versa, the clock systems, where no FLL is present, we have tried by design to make the DCO as stable as possible.
In terms of the specified lock time of the FLL, please keep in mind this is just a typical value. Thus it does not give you any certainty in neither low side or high side direction of the specified value. The given value it is just a rough indicator, and in this specific case really just a rough value for multiple reasons:
1. The lock time depends on the frequency difference between the desired value and the value of the DCO you're starting off when starting the DCO.
2. It also depends on the clock speed of the DCO, as there is a fixed number of comparison clocks for the comparison of the reference and the DCO, for the derivation of the FLL corrections applied to the DCO settings. Thus e.g. faster reference clock speeds would enable faster lock times.
3. Pushing the DCO closer to the desired frequency by writing certain values into the device by intention, to reduce the difference between target frequency and the frequency you're starting off, also reduces the FLL lock time. The smaller the difference you're starting off, the shorter the FLL lock time will be. So your approach is in respect of this portion correct. Storing values of the DCO and MOD bits for certain desired frequencies in FRAM, and pushing them into the control register of the DCO would make sense. But you need to keep in mind, this probably needs storage of multiple values over temperature, including measurement of the device temperature, before selecting the optimum value and pushing it to the control register. This would also need to be done for each device separately, as the temperature drift could vary from device to device. Of course if done at production, this is very consuming and requires expensive infrastructure. Potentially this could be done in the field during operation. Basically when FLL is locked, you know that this setting is correct for this device for the current temperature, which you can measure with the ADC and the integrated temperature sensor. So you could store the value in FRAM for future use. Of course for the initial operation you could run into longer lock times, when not yet having a suitable value stored in FRAM.
There would be further details, how you could mitigate this issue, during the initial phase of the DCO use, like e.g. waking up more frequently, measuring the chip temperature and in case of reaching a certain target temperature for the DCO table storing the DCO values after FLL lock, and marking the temperature as calibrated. But it depends on your application if you can spend the additional current for these additional activities, and depends on how accurate you need to be, or how fast your lock times of the FLL need to be.

I hope this gives you a sufficient understanding of the DCO/FLL behavior.

Best regards
Peter