• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 21 subscribers
  • Views 894 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Absolute drift between two outputs of CDCE949?

Erik Walthinsen
Prodigy 230 points
Other Parts Discussed in Thread: CDCE949, CLOCKPRO

I've got a system that uses a CDCE949 with a 24.576MHz crystal to generate a 4.096MHz clock for an ADC, and a 32.0MHz clock for the controlling MCU.  The purpose for doing this is that I can lock multiple units' ADC sampling times together as long as I can lock the MCU clocks together.  The bus between them has a reference packet, and the MCUs have cycle counters, with a PID loop driving the Vctrl of the CDCE949.


However, now I'm seeing behavior (which I don't remember seeing earlier) that is very troubling: the timestamps of the ADC capture points that started out closely locked to millisecond boundaries are slowly drifting away from those boundaries.

My question would be this, if somebody has an answer pending me running my own experiments as soon as I can:


Are fractional PLLs that calculate out to have zero error in them subject to drift otherwise, relative to other outputs?  In other words, if I started counters connected to the 4.096MHz and 32.0MHz clocks at the same time, would I be able to let it run for infinite time and still get the exact same ratio of 'ticks'?  E.g. run it for 1000 seconds and get EXACTLY 4.096 billion counts on one and 32 billion on the other?

If I can't rely on this particular aspect, I'm not exactly sure how I can solve it.  I can run the MCU at an 'overclocked' 32.768MHz, but that clock would be derived from a PLL generating it from 24.576MHz.  If the ADC clock remains a 6x divide of the input clock, I'll have the same problem.  I'd have to set up the ADC clock to derive from the 32.768MHz PLL, and that would require that I re-spin the board, since my outputs are on Y1 and Y7....

<sigh>

  • 0
    TI__Mastermind 32575 points

    Hi Erik,

    Could you please provide your CDCE949 configuration, perhaps a screenshot or setup file from the ClockPro GUI software?

    Assuming the PLL is locked/stable and 0-ppm synthesis error is truly achieved, then there should not be any frequency drift relative to the two outputs.  There will only be a difference in short-term jitter between the outputs.

    Regards,
    Alan

  • 0 in reply to Alan O
    Prodigy 230 points 
    Here's my config with comments.

    // Y1: PLL1/3 -> 32MHz to MCU
// Y7: bypass/6 -> 4.096MHz to ADC
// Y8: disabled to interface
const uint8_t CDCE_REGISTERS_ATTRIBUTES cdce_registers_low[] =
{
  0x00, 0x07,                                   // write 7 bytes to offset 0x00
  0x81, 0x04, 0xbc, 0x03, 0x02, 0xA0, 0xa0      // 2nd byte 0x04 means VCXO
};

const uint8_t CDCE_REGISTERS_ATTRIBUTES cdce_registers_high[] =
{
  0x10, 0x40,                                   // write 64 bytes to offset 0x10
  0x00, 0x00, 0x00, 0x00, 0x6A, 0x00, 0x83, 0x03, 0x07, 0xD0, 0x43, 0xEC, 0x00, 0x40, 0x02, 0x08,       // 32MHz
  0x00, 0x00, 0x00, 0x00, 0xE0, 0x02, 0x01, 0x01, 0x00, 0x40, 0x02, 0x08, 0x00, 0x40, 0x02, 0x08,       // disabled
  0x00, 0x00, 0x00, 0x00, 0xEF, 0x02, 0x86, 0x06, 0x00, 0x40, 0x02, 0x08, 0x00, 0x40, 0x02, 0x08,       // 4.096Mhz
  0x00, 0x00, 0x00, 0x00, 0xE0, 0x02, 0x01, 0x01, 0x00, 0x40, 0x02, 0x08, 0x00, 0x40, 0x02, 0x08,       // disabled
};

    The annoying part is that I haven't been able to reproduce the issue in a while now.  It seemed to be exacerbated by the functioning of higher and higher levels of my codebase, but now that it doesn't happen *at all* anymore I can't determine if it's something wrong with the MCU or my code.

    I have a scope connected to the 1.0mS timer overflow event (so no software in the loop) and the ADC's DRDY# line, and since I started watching (as expected, the exact same time the bug vanished) I have not seen any drift between the two at all.

    I would assume there'd be no drift, but I wanted to make sure there wasn't something I was overlooking that might make it possible.  Guess now all I can hope for is that the  bug shows up again so I can figure out what the heck it is.... ;-(

  • 0 in reply to Erik Walthinsen
    TI__Mastermind 32575 points

    I'll close this thread for now, and you can repost the issue if you suspect an issue with the CDCE part.  Thanks.

  • 0 in reply to Alan O
    Prodigy 230 points

    OK, so I've narrowed down what's going on.


    The clock capture routine in my MCU has been annoyingly glitchy in dealing with register overflows (2x 16bit timers cascaded in hardware, overflowing to a 32-bit seconds counter in interrupt, a capture near overflow can be +-1sec in some cases I still haven't hammered out).  As such sometimes the PID algo that is trying to keep the clocks together gets thrown for a loop.


    What I'm finding is that when the PID pushes the Vctrl too far, I *immediately* get an absolute slip between the two output clocks (4.096 straight divide, and 32MHz via PLL).  "Too far" in the first example where I've confirmed that behavior is with a DAC output of 0.492V, adjusted from 0.735V at a point 182mSec prior (yes, PID is oscillating).

    Obviously I'm going to go back and check what the deal is with my sync edges not capturing properly (either grabbing the wrong edge or corrupting the captured counters) and try to fix that, but I'm also going to need to find a "safe zone" in which the PLL is *not* going to start slipping like this, since such slips are fatal to my system.  Whether that's a range around center or a maximum delta per change is yet to be determined.


    If the assumption is that multiple outputs of the CDCE949 will maintain absolute "sync" in all cases, I've demonstrated that this is not true.  Once narrowed down I suspect an errata ought to be issued.

  • 0 in reply to Erik Walthinsen
    TI__Mastermind 32575 points

    If a fast change in the Vctrl voltage causes an abrupt step change to the crystal oscillator frequency that is higher the PLL bandwidth, it is possible that this change cannot be tracked by the PLL and thus can cause a slip between the PLL-based output vs. Non-PLL (divide only) output.  Could you somehow try to limit the slew rate to the Vctrl input to insure the adjustment to the crystal frequency is within the PLL bandwidth and can properly track?

  • 0 in reply to Alan O
    Prodigy 230 points

    The extreme slew of the Vctrl is due to a bug that has been driving me insane for at least the last 3 days, hopefully I can finally track it down and kill it.  I can also code up a test-case where I slew the Vctrl abruptly and see if I can narrow down exactly how much slew it takes to slip the PLL.  My concern with limiting the rate "artificially" is that a PID is in control of it, and PIDs don't tend to work quite right when their output is externally limited.  OTOH, I know from the aforementioned bug that my PID is way too aggressive, so...