RTOS/MSP430G2553: MSP430G2553 measure frequency problem;

Hello,
there might be various reasons for the inaccuracy you're experiencing in your application. The range of 240-266MHz is a -5,88% - +4,313% deviation. As clock source and reference for your measurements you're using the DCO. The accuracy of your measurement can never be better than the used reference. The DCO's calibration accuracy is already in the range of +/-1%.
Furthermore, the DCO is not a equal pulse width oscillator, but deriving the final frequency from modulating, in dependency of the DCO and MOD bits the DCO's frequency between two neighbored frequencies.
By dividing the used reference frequency from 16MHz to 2MHz you're even decreasing the resolution and increasing the impact of this modulation, as the resulting jitter of the DCO's modulation are not mitigated by the division.
With all these aspects I think the experienced error in your measurement setup is related to your implemented measurement approach.

Best regards
Peter

So, if the accuracy range is almost 1%.
Then if i measure the solid freq of 266hz it may get 266 +-1% ?
So i will get almost 263hz~268hz?

But i can't find the reason of my code bug.

If i can't find , then i will no goal to debug

Hello,
I am not sure whether my point about the nature of the DCO clock and its modulation and the impact on the accuracy was clear enough. The mentioned +/-1% are just the calibration accuracy across a certain period of DCO clock pulses. The given resolution with the selected DCO and Timer settings would to some portion degrade the +/-1%.
But as stated, the biggest portion of deviation is related to the modulation of the DCO. Please see chapter 5.2.6 DCO Modulator in the User's Guide www.ti.com/.../slau144j.pdf . There you can find a detailed explanation of the DCO behavior.
The divided DCO clock in combination with this modulation increases the inaccuracy.
But certainly with ~ +/-1% and the over temperature and Vcc variation (see DCO accuracy specification in the MSP430G2553 datasheet) only worse accuracy results than the DCO accuracy can be achieved.

Best regards
Peter

Hello,
please let us know, whether you need further support on this topic. Many thanks in advance.

Best regards
Peter

not resolved

if i change another MCU maybe resolved this problem?

It look like such DCO cause the error on the result.

If in the normal,the DCO clock may be has 5% range of error.

so , i think i can change the mcu to test. At the same code to tesy by msp430F5529. 

the result maybe difference.

Do u have suggestion, if i used msp430F5529 to replace the mps430g2553?

Hello,
have you performed an error calculation of the achievable accuracy, based on the nature of the DCO clock and your SW approach? I would recommend you to do so. Derived from that you can also assess, whether you're getting additional errors from your code, or whether the observed accuracy limitations are just related to the DCO.

Regarding your question on the optional change to another MSP430 derivative, the above calculation would also in this respect give you an answer.
From top level point of view, there are two things to consider, when thinking about selecting another MSP430 derivative. The DCO is in all MSP430 devices using the modulation approach to increase the DCO frequency resolution. The only difference between the DCO variants implemented in MSP430 devices are as follows:
1. The DCO and MOD bits resolution, means DCO step size varies across different MSP430 families, and thus the resulting error from modulation. (please see respective device datasheets for the specified values)
2. There are two fundamental differences in the clock systems implemented across the MSP430 families. Some have a DCO without FLL, where the DCO accuracy is in the range of single digit %. And there is the other variant, where the DCO itself is not as stable, but stabilized by an integrated FLL, where the resulting DCO accuracy is equal to the used reference frequency accuracy for the FLL. This means e.g. if a 32kHz crystal is used for the FLL, then the DCO will reach the long term accuracy of the 32kHz crystal, if you would use the REFO as reference clock for the FLL, then of course the final accuracy would be as well only at the level of the REFO's accuracy.

In any case the highest accuracy can be achieved, when using a crystal clock for the measurements, while of course also with a crystal one needs to consider the resolution. Means if you want to measure a frequency with 1% resolution, the used clock for the measurement needs to be at least 100x higher, if the target is 0.1% it needs to be at least 1000x higher.

Best regards
Peter

but my code use 2MHz to measure the frequency;

and the Analyte is only 0~266hz.My source is big than 7518 Magnification;

As you say ,the Precision should be the 0.1%;

So my result should be 266hz but the result is not it has a range about 258~270hz ,

when i used  the solid AC power supply which is supply the 266Hz and 5.0 AC voltage to measure.

This is my draw picture of flow chart.

Is there has obvious bug on my flow chart ?

I can't find where the bug is ??:

Comment:Sorry,the time is <1 sec ,diagram need to fix.

Hello,
according to your flow chart, it looks like you're clearing the Timer value with the first capture event?
Is this correct? What is your intention doing so? In any case, this is not a good practice, as this would introduce an additional error.
Basically, when looking at the pure timer operations for measuring the pulses should be as follows:

1. enable/configure timer for capture interrupts (e.g. falling edge)
2. store the timer value of the first capture event (1st falling edge)
3. store the value of 2nd capture event (2nd falling edge)
4. build the difference between 2nd and 1st capture event ( ideally, with 266Hz and perfect 2MHz this should be as stated 7518, with DCO calibration accuracy, this can minimum 7443 - 7593. If there is a temperature deviation from the value the DCO has been calibrated at, there will be additional errors, and from DCO modulation, there will be also some error (have you calculated that portion?))

The other question would be also the nature of your frequency signal. Is it a digital, means square wave, with steep edges, or are you measuring an analog signal, e.g. sine wave or similar signal?

Best regards
Peter

1. enable/configure timer for capture interrupts (e.g. falling edge)

postive edge is i am used.
2. store the timer value of the first capture event (1st falling edge)

yes,but why can't clear the timer value ?

3. store the value of 2nd capture event (2nd falling edge)

yes,but why can't used 2nd-1nd(zero)??

4. build the difference between 2nd and 1st capture event ( ideally, with 266Hz and perfect 2MHz this should be as stated 7518, with DCO calibration accuracy, this can minimum 7443 - 7593. If there is a temperature deviation from the value the DCO has been calibrated at, there will be additional errors, and from DCO modulation, there will be also some error (have you calculated that portion?))

I am measure the square wave which is always repeat for freq (range is 0~266HZ)

Hello,

the point about clearing the timer is the following:

1. It is not needed, as due to the 16Bit CPU architecture and 16bit Timer length, the difference is even correct with any starting value of the timer unless you have more than one transition through FFFFh. That's why there is the overflow flag, indicating this case.

2. Even more important one for the accuracy. When clearing the timer, the only chance to do so is by interrupt. Interrupt means, there is a certain latency between the actual capture event and the execution of the clear of the timer. Dependent on which instruction is being executed, whether there are potentially some other interrupts active and served, and even with RTOS, there are higher latencies probable. If using the capture as intended, you avoid these errors.

"yes,but why can't used 2nd-1nd(zero)??"

As mentioned above the CPU based clearing of the timer introduces errors difficult to control.

for point 4.

Sorry, but you have not answered the question on the device temperature. Please keep in mind, the DCO drifts also over temperature. Actually I also need to correct myself. The DCO calibration accuracy, please see the device datasheet is at 30degC +/-3%

Best regards

Peter

But if i store the 1st & 2st value,that may be complicated for cal the time if the over_flow occur;
that may be many situation ;
such like
if the
1.TACCR1(1st)>TACCR1(2nd) ---> OVER_FLOW??
=> not over_flow => t = TACCR1(2nd)-TACCR1(1st);
=> over_flow => t = TACCR1(2nd)-TACCR1(1st)+over_flow_times*65536;
=> over_flow => t = TACCR1(2nd)-TACCR1(1st)+???
if over_flow_value has a range; how can i sure that where is it go?
such like over_flow_time > 40 --> over times =0;
2.TACCR1(1st)<TACCR1(2nd) ---> the value is native; occur OVER_FLOW
=>time = 65536-TACCR1(1st)+TACCR1(2nd);
=>over_flow need to dec 1;
--------------------------------------------------------
such the first 1 => build 3 situation. and the priority is fst;
that i will consider the situation 1 to design the situation 2
=> that may be many formula , so how can i design?

------------------------

The temp may be 25'C~40'C;

if the tol may be 3%.

This project maybe have a big trobule;

266*1.03 =>273.98

266*0.97 =>258.02

if the tol is sure, ,my result is such this data 

As fst I say and post , I measure the 266HZ　get almost 258~270HZ....

Hi,

sorry, but you still have not understood my statement about the 16bit format of the Timer and the 16bit architecture of the CPU, which inherently solves the problem with the single overflow.

To try to explain it based on an example:

Keep in mind the range of the 16Bit values is from 0h - FFFFh

Please see here the behavior of a 16bit timer with a 16bit CPU.

So as you can see, as long as the measured pulse length does not exceed the length of one FFFFh timer period the flip from FFFFh to 0h does not generate an error when calculating the difference, which is definitely not the case with 266Hz.

Best regards

Peter

ok,but I think that method difference maybe just less calm one count. it seems not a major problem of this code.

As I tried to explain, the error caused by clearing the Timer by the CPU after the first capture event, can introduce an unpredictable error. I'd recommend to include the recommended procedure, and check the behavior with that approach. If this should not be sufficient, we can take the next step.

Best regards
Peter

Hello,
have you been able to make a step forward? What is the outcome of the recommended tests?
Please let me know, if you need further support on this? Many thanks in advance.

Best regards
Peter

not resolved

ok,if i change the code for

get fst value & snd value
then value = snd-fst value-> that i can understanding but it only for 32.768ms down singal
if the singal is big then 32.768 it will overflow why didt u say that will resolve by it self?

OK,u want to Explanation.

That measure the (0000H~FFFFH)--->(0~65536)=>1 value =0.5us
(0~65536)=>(0~32.767ms) the capture is low error.
It mean the value of ( inf ~30) ,it mean the feq bigger than 30HZ ,the signal is almost ok?
but the result is not equal the Theory.
and if i want to measure the Following singal which is 32.767ms(30hz), the capture may overflow
so how can i fix in my code??

Hello,
many thanks for the updates from your side. I was just trying to solve the multiple problems step by step.
So point number one for me was explaining the principle of avoiding errors by clearing the Timer register. I hope I was able to clarify that point, and you're able to measure the frequency of 266Hz now with the expected accuracy.
So the next point is of course extending the possible input range of frequencies to the desired range of yours. Now as you correctly mentioned, at a certain input frequency, you would run into multiple overflows, or better to say, at the very moment, your measurement interval exceeds FFFFh, means the length of your timer, you need additional SW features to address that. I would use the capture overflow interrupt for this purpose. So in the ISR you would count the number of overflows, and add accordingly the number of Timer periods to your calculation.
In addition it might make sense to have also another algorithm / feature included to address this point. But it depends on whether you want to include that complexity in your code and on the other hand how fast you want to measure the frequency, and if you could run multiple measurements for "one" frequency or not. The thing I am talking about is to scale the timer frequency, coming from a clock speed, where you would avoid overflows, which is potentially impossible, when starting at 0Hz, and then step by step, when seeing a low resolution, increase the timer clock speed.

Best regards
Peter