Using 32.768KHz crystal for a microsecond delay

hello Mayank,

You can use timer interrupt  to generate a microsecond delay(Interrupt time = (clock frequency of timer/CCR0)^-1),u can set the timer in UP/DOWN mode and if the clock frequency of the timer is 32.768kHz then,[Interrupt time = (32.768E3/(CCR0 * 2))^-1],where CCR0 = 1 ,if the timer is in UP/DOWN mode then the CCR0 value is internally multiplied by 2.

so for 32.768kHz u can maximum generate 61MicroSecond delay.If u use the internal 16MHz frequency then u can able to give 125ns delay..

Regards,

Saravanan 

Use DOSC at 10MHZ.

Tom

What good would a microsecond delay be? Even with 8MHz system clock, this means 8MCLK cycles. An interrupt takes more than that without even doing anything.

If feeding a 32768kHz signal into a tiemr, you'll get one timer tick every 1/32768s. This is 30.5µs granularity. And I'm not sure whether the timers are capable of producing an itnerrupt on every tick. I guess the minimum is on every second timer tick. Giving you a minimum delay of 61µs.

On my core library, I run a timer with 1MHz (derived from 8MHz crystal). The µs delay function does a busy-waiting delay of at least 10µs with 1µs granularity. funciton call and return and timer register setup are taking that much. And I don't use an interrupt for the delay end - it's too slow and busy-waiting for teh IFG bit is much faster and precise.

What you can do is calibrate the DCO to a higher frequency using a timer and the 32768kHz crystal. (there are some threads with code in this board). Then use the higher DCO frequency to drive the tiemr and generate the delay you want. Or, if you have stabilized the DCO and therefore the CPU MCLK frequency, use __delay_cycles(x) for a busy-waiting delay of x MCLK cycles.

Miro-second is just a unit for time. One could use nano-second too!

Each cycle of a 32768 Hz clock is about 30518 nano-second. (Or about 30 micro-second.)

You will get way better answers if you specify what exactly you need to achieve. Please give short description of your application and circuit, if any. Honestly - msp430 is not right tool for (precision) microsecond timing.

If you are desperate doing this with your launchpad, then - change your 32KHz crystal to 16MHz one, reconfigure CPU clock config accordingly, use pin change interrupt for input, read datasheet about how pin change interrupt works (how many CPU cucles are "wasted" during input sampling and so on), count how many NOPs (as 1/16 microsecond delays) needed before output signal pin shall be set. Do not forget to implement pin reset after some delay too. Oscilloscope will be helpful to check that you are getting what you want - microsecond delay ;)

ILMARS JARGANS said:

Honestly - msp430 is not right tool for (precision) microsecond timing.

Oh, if you don't want an interrupt every µs, the MSP is well suited for handling timings with µs resolution.

ILMARS JARGANS said:

f you are desperate doing this with your launchpad, then - change your 32KHz crystal to 16MHz one

And see that it isn't working. The G devices do not support high-frequency crystals.
Previous experiments have revealed that the chips accept an external TTL frequency of several MHz in bypass mode, even though this is clearly outside the specs.

This thread

http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/221510.aspx

is discussing the microsecond delay for the same application. Mayank Sharma is making the project with me. We thought this thread had been deleted. I just saw it now. Thought to add the 2 threads to make the discussion easier.

Jens-Michael Gross said:

The G devices do not support high-frequency crystals. Previous experiments have revealed that the chips accept an external TTL frequency of several MHz in bypass mode, even though this is clearly outside the specs.

Jens-Michael Gross said:

Oh, if you don't want an interrupt every µs, the MSP is well suited for handling timings with µs resolution.

Well.. It depends on what you call "timing" and what you call "precision". If timing is just program execution delay with NOPs for 1us +/- 5% - perhaps. Unfortunately post author did not specify anything except "microsecond delay" ;) BTW "calibrated" DCO clock is usually modulated (MODx != 0) - frequency jumps between two frequencies. So it means two short (< 32 cycles) consecutive delays aiming to be 1us long most probably will have quite different timings, especially at hi-freq end where DCO "steps" are huge.

ILMARS JARGANS said:

Well.. It depends on what you call "timing" and what you call "precision". If timing is just program execution delay with NOPs for 1us +/- 5% - perhaps.

With a proper 1MHz base frequency (from 16MHz DCO, this mostly eliminates modulation jitter), the timers are capable of giving a highly precise PWm output with 1µs granularity.

Yes, knowing what this timing/delay is required for, would be a great advantage. Also, often people want exact results just to throw the precision away by the very next step they do. Like using a 36bit scanner for 'highest quality' and then compressing the result to a small JPG.

Jens-Michael Gross said:

With a proper 1MHz base frequency (from 16MHz DCO, this mostly eliminates modulation jitter), the timers are capable of giving a highly precise PWm output with 1µs granularity.

 Hi Jens, Jiitter cannot be removed from simple integer division, prescaler toggle is still affected by jiitter then PWM is also affected too.

 TO remove Jiitter counting must be in fixed integer relation to modulation pattern and must appear forever at same point on prescaling chain.

 Precision is not affected by jiitter on long term so average is very precise but single pulse can be affected by lead or lag on one or other front depending were jiitter appear on.

 Long term precision is very high, short term suffer randomized errors from modulation.

Jens-Michael Gross said:

With a proper 1MHz base frequency (from 16MHz DCO, this mostly eliminates modulation jitter), the timers are capable of giving a highly precise PWm output with 1µs granularity.

Not quite. Modulator period is 32 clock cycles, division by 16 will just slightly decrease jitter.

Ilmars said:

Not quite. Modulator period is 32 clock cycles, division by 16 will just slightly decrease jitter.

Division by 16 will completely remove jitter for 15% 50% of all modulation patterns and reduce it to 1/16 for all others. I'd consider this to be more than 'slightly'.

Roberto Romano said:

Hi Jens, Jiitter cannot be removed from simple integer division, prescaler toggle is still affected by jiitter then PWM is also affected too.

Yes and no. Sure, the jitter caused by individual clock pulse width variation is rather white noise and integrating only applies a low-pass fiter. However, the jitter caued by DCO modulation is an intentional programmed jitter, following a fixed repeated pattern and therefore integration over the size of the pattern will 100% eliminate this jitter. For all other occasions it will significantly remove it. Because modulation patterns are chose so that there is no 16* slow followed by 16* fast (which indeed couldn't be removed by integrating over 16 pulses)

Example: Diference between DCO_x and DCO_x+1 is up to 12%. For a 50% modulation, jitter between any two clock pulses is 12% But for integrating over two clock pulses (a /2 divider), jitter between two integration results is 0%. Always (DCO_x+DCO_x+1)

Jens,

Today I put 16MHz modulated clock on spectrum analyser screen and I can say: you are right again (surprise surprise!) :) 16MHz divided by 16 was looking roughly 16 times better. It's clock pulse-by-pulse modulation indeed with all the (good) consequences. Thank you!

Ilmars