MSP430F5529: A stable sinewave generation

What are you comparing the phase with? Or are you observing variation in frequency?

To get high frequency accuracy, you'll need a high-quality crystal; I think commercial signal generators talk about 1ppm or better.

More generally: How are you generating the wave? I don't see a DAC in the F5529 data sheet.

Thanks for the reply sir Bruce,

I'm comparing it with Analog discovery 2 digilent and I'm using AD5663 dac to generate sinewave..

I generated square wave directly from msp430 to compare it with the analog discovery 2

I replaced few crystal crystals which I have.. but still faced that issue sir Bruce..

Please give me few other suggestions to test it..

Thanks and regards,

Tex

How are you generating the square wave?

Are you using interrupts to send the data to the DAC?

I think we need to see your code. What frequency do you want?

Hi Keith,

Comparision did with square wave only using one of the timer examples..

No interrupts used while using the dac..

I observed phase shift happening from our controller side only observed by generating square in msp430 & also generated same square wave from the signal generator..

Best regards,

Tex

A quick first-experiment would be to adjust the frequency of the Waveform Generator to see if you can "lock" it with the F5529 signal. This will tell you (a) whether the frequency is (dynamically) varying and (b) how far off you are.

I haven't used the AD5663, but with a DAC like this the key is the accuracy of /LDAC. I suppose you're driving that with a timer, which moves the issue (back) to the underlying clock (SMCLK presumably). It may be worth checking SMCLK directly, by putting it out on P2.2.

Things you can try:

1) Tune the /LDAC period by adjusting the timer constants (CCR0 in particular). 

2) If you're using the DCO+FLL, you can adjust UCSCTL2:FLLN to adjust MCLK/SMCLK, which might provide more resolution than the timer.

3) You might learn something by using the other Waveform Generator to input a clock to (e.g.) TA0CLK to drive /LDAC, so you know the clocks match. That's not an long-term solution, but it would tell you whether the F5529 clock is really the problem.

Thanks for the reply, 

I'll get back to you with the test results..

If you are just trying to create a sync signal for your sine wave, it might be better to do it from the code that sends the data to the DAC.

I should point out that if you simply have a loop in main that updates the DAC, it is possible for any interrupts to steal cycles that will gradually put the main loop out of sync with any timers.

Bruce McKenney said:

If you're using the DCO+FLL, you can adjust UCSCTL2:FLLN to adjust MCLK/SMCLK, which might provide more resolution than the timer.

Is there any example programs for better understanding bruce ??

Keith Barkley said:

I should point out that if you simply have a loop in main that updates the DAC

Yes keith! i have loop in main

Keith Barkley said:

it is possible for any interrupts to steal cycles that will gradually put the main loop out of sync with any timers.

How it is possible keith ? where i can learn about this ??

I don't know of any TI examples of making adjustments to FLLN. There's no magic, though -- in (e.g.) example MSP430F55xx_UCS_02.c:

https://dev.ti.com/tirex/explore/node?node=A__ACRVkGHiAiOjRIE2BAsg5A__msp430ware__IOGqZri__LATEST

that "249" is just (8.192MHz/32.768kHz)-1. If you increase it, the FLL (clock) output will speed up slightly.

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

That said: As Keith pointed out, this sort of fine adjustment won't help if you're not driving /LDAC (and the SPI output to the DAC) using a timer. How are you doing this?

Tex said:

Keith Barkley said:

it is possible for any interrupts to steal cycles that will gradually put the main loop out of sync with any timers.

How it is possible keith ? where i can learn about this ??

It is called an interrupt for a reason. You only have one processor. When an interrupt happens, the main loop is paused while the processor services the interrupt. At the end of the interrupt, the main-loop state is restored and the main loop resumes where it left off.