MSP430FR2433: DCO Software Trim in extremely cold environments

Thank you for your question,

An assigned MSP team member will assist you shortly.

Hi christopher and MSP team member,

I post corrections of contents and additional information.

> When debugging, the program counter was stuck in the following loop processing in CS_initFLLCalculateTrim ().

This was my mistake.
Correctly, it gets caught in the loop processing of privateCSComputeDCOFTrim () in CS_initFLLCalculateTrim ().

This process changes dcoFreqTrim in the range of 0 to 7.
However, it seems that there is MSP430FR2433 that DCOFTRIM does not become "endLoop = true" regardless of the value.

<Additional contents>

In MSP430 devices with DCO failure, changing DCORSEL = 2 to DCORSEL = 3 seems to improve the problem even when resetting around -35 ° C.
However, when DCORSEL = 3, trouble phenomenon occurs at around 20 ° C.

The results are shown in the following table.

There are the following questions in addition.

1. In applications where temperature changes occur, does DCORSEL have to be changed each time?
There are the following questions in addition.

2. Is it recommended for you to change DCORSEL according to the environment?

Best regards.
Cruijff

I'll correct the table in the previous post.
The DCO tap is unconfirmed at DCORSEL = 3 and startup temperature at +20°C.

What we want to say is that there is MSP430FR2433 that need to change DCORSEL according to the environmental temperature to operate at 4.9152 MHz oscillation.

Please confirm.
Cruijff

Hi,

Sorry for reply late. I will take time to check your issue and reply you early next week, since I'm busy for other urgent cases this week.

Hi Cruijff,

1. Is it possible for the DCO tap to reach the maximum value even when CS_initFLLCalculateTrim () is executed?

[Wei] If the DCO tap reaches the maximum value, it may get out of range for the current DCO frequency range, so that the FLL can't lock. That why you saw the FLLUNLOCK = 11. So for your screen shot 1&2, it seems the DCO got out of range under -35°C and -30°C. 

2. Are there any workaround for software?

[Wei] I need to get more information about your case to find any workaround.

3. In applications where temperature changes occur, does DCORSEL have to be changed each time?

[Wei] You shouldn't need to change DCORSEL for temperature changes. DCORSEL=2 should work for you.

4. Is it recommended for you to change DCORSEL according to the environment?

[Wei] same to #3

I would like to check some questions for your use case:

1. Why are you configure the DCO to 4.9152 MHz? Which application requires this frequency? could you share the specification your use case?

2. Could you confirm which clock source is used for FLL reference clock, REFO or XT1? Please confirm the FLL reference clock status and frequency when the issue occurs in low temperature.

3. Which code line of privateCSComputeDCOFTrim () did you say "it gets caught in the loop processing of privateCSComputeDCOFTrim () in CS_initFLLCalculateTrim ()"? Could you share me the test project you used for the issue reproducing?

Hi Cruijff,

A comparing test would be helpful to analyse the root cause if you could do it using the original project cs_ex1_DCO1MHzSWTrim, which configure the DCO to 1MHz, under the low temperature to see if the same issue occurs.

Hi Wei

Thank you for your reply!

I understood that it isn't need to change DCORSEL for temperature changes.
But let me ask you the following question.

5.Do you think that Individual difference of MSP430 can cause such symptoms?

Some MSP430F2433s have DCO instability in low temperature environments as the table of the previous thread.
While others have DCORSEL = 2 and DCO = 4.9152 MHz stable at any temperature.
So I guess that this phenomenon will happen by the individual difference on the ICs.

What do you think of this guess?

And, I'll confirm with the customer and post again for the use case to this thread.

Best regards.
Cruijff

Hi wei,

I'll answer the following about my customer's use case.

1. Why are you configure the DCO to 4.9152 MHz? Which application requires this frequency? could you share the specification your use case?

[Cruijff]
An external 19.2 kbps serial data is received via UART communication.
In order to generate the baudrate (19.2 kbps) in USCI, my customer sets DCO = 4.9152 MHz.

2. Could you confirm which clock source is used for FLL reference clock, REFO or XT1? Please confirm the FLL reference clock status and frequency when the issue occurs in low temperature.

[Cruijff]
The system boards use XT1 as the FLL reference clock.
After confirming DCO instability phenomenon when the low temperature, the customer changed the FLL reference clock to the REFO internal oscillator and tested.

But even then, DCO didn't be stabilized when the low temperature.
The source oscillation of XT1 and the clock output of 32,768 Hz were confirmed by waveforms at low temperature DCO instability and normal temperature DCO stability, but there was no waveform difference.

In addition, it is 0x0F51 in CSCTL7 at -30 ° C of my screen shot2.
Since XT1OFFG is "0", I think that the clock input and oscillator of XT1 are not a problem.

3. Which code line of privateCSComputeDCOFTrim () did you say "it gets caught in the loop processing of privateCSComputeDCOFTrim () in CS_initFLLCalculateTrim ()"? Could you share me the test project you used for the issue reproducing?

[Cruijff]
I send test project as zip file.
Based on cs_ex1_DCO1MHzSWTrim, the project has been changed to DCO = 4.9152 MHz.

In line 381 of cs.c, the following code loops to always look for the correct value of DCOtap.
" while(endLoop == false); // Poll until endLoop == 1　"

Can you guess where the cause is?
Please tell me your view.

Best regards.
Cruijff

cs_ex1_DCO1MHzSWTrim_Modify.zip

Hi Cruijff,

Thanks for feedback.

I don't agree with your guess. The device behavior could be different among different part. But all the released devices will follow the parameters on the datasheet. 

waiting for your feedback from customer for questions of my last reply.

Hi wei,

Thank you for your reply!

[Wei]
A comparing test would be helpful to analyse the root cause if you could do it using the original project cs_ex1_DCO1MHzSWTrim, which configure the DCO to 1MHz, under the low temperature to see if the same issue occurs.

[Cruijff]
The customer tested this sample project.
As a result, it oscillated stably at DCO = 1 MHz at low temperature and normal temperature.

In addition, they tested by changing the setting to DCO=2.4576 MHz (half of 4.9152 MHz) for the system board that had symptoms.
As a result, it oscillated stably at DCO = 2.4576 MHz at low temperature and normal temperature.

In the setting of 4.9152 MHz, DCO seems to be unstable at low temperature when DCORSEL is '2' .

[Wei]
But all the released devices will follow the parameters on the datasheet.

[Cruijff]
You mean the customer's set values (DCO = 4.9152 MHz, DCORSEL = 2) are follow the data sheet requirements?
It does not depend on the temperature environment, right?

Best regards.
Cruijff

Hi wei,

Do you have any advice for this phenomenon?
The customers also want your view.
I would appreciate your immediate attention to this matter.

Best regards.
Cruijff

Hi wei,

Thank you for your reply and sorry for my late reply.

I provided feedback to my customers about your view.

I have additional questions and posted in "Ask a related question".

Could you check it?
Thank you for your generous support.

Cruijff