• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 22 subscribers
  • Views 776 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.

LMX2594: Data sheet vs TICS Pro Questions about initialization

Craig Petre
Prodigy 50 points
Part Number: LMX2594

I've been working on SW to bring up this PLL on a custom PCB.  We have it, for the most part, working, but I did run into some issues and was able to piece together functionality by comparing/contrasting the TICS Pro GUI notes with the data sheet.  I have the below questions that I'm still looking for clarification on though.

- My first issue is with the SEG1_EN R31[14].  The data sheet seems to say this should be set to 0 if the channel divider is 2 and should be set to 1 otherwise.  In my testing, when the channel divider is 2 and SIG1_EN is 0, the PLL will not lock.  If I do enable SIG1_EN for a channel divider of /2 I do get lock.  I do have VCO_PHASE_SYNC enabled and I noticed on the GUI if I try with SIG1_EN disabled it gives me an error stating that I should enable SIG1_EN in a configuration where VCO_PHASE_SYNC is enabled and both MUXOUTs are not configured for VCO.  The last part of that message doesn't make much sense to me, but maybe my answer is if VCO_PHASE_SYNC is enabled, I must also enable SIG1_EN regardless of divider.

- The next thing I noticed while playing with the GUI was that it gave a warning about setting the powered down output (RF_OUT_B in our configuration is unused) to VCO.  I believe the data sheet recommends setting any unused/powered down output mux select to VCO, but the GUI seems to disagree.  In our configuration we'll most likely always have RF_OUT_A set to the channel divider and RF_OUT_B set to powered down, what should the mux select be for RF_OUT_B in this case?

-  We are also having some trouble with the MUXOUT pin.  I initially use the pin for SPI read back and then flip the pin to lock detect after I configure the part and after I see the rb_LD_VTUNE state enter 0x2 in R110.  We have the LD_TYPE set to 0x1 and after I detect lock in rd_LD_VTUNE I set MUXOUT_LD_SEL, R0[2], to 0b1, we don't see the MUXOUT pin being asserted.  Are there any gotchas there or anything I'm missing as far as register configuration goes?

Thanks!

Craig

  • 0
    TI__Mastermind 18070 points
    Hi Craig,

    Let's discuss these one by one. For the first question, at which frequency do you see that PLL fails to lock when SEG1_EN = 0 and channel divider is 2? Because at 7GHz (14GHz divided by 2), it locks with SEG1_EN checked or not. By the way, when we say channel divider is 2, we mean divide by 2, not that the register value equals 2.

    For the VCO_PHASE_SYNC, I think the tooltip is correct. If both outputs are direct VCO output, then SEG1_EN is not needed. Otherwise it needs to be 1.

    Regards,
    Hao
  • 0 in reply to Hao Z
    Prodigy 50 points

    Hi Hao.  I was getting failure to lock on any output frequency that was VCO / 2.  I was primarily using an output frequency of 4000 MHz with a VCO of 8000 MHz.  So the tooltip makes sense, if both outputs are VCO then neither is going down the divided path so disabling SEG1_EN seems sensible. 

    The data sheet is less clear about this (from 7.6.10):

    Enable driver buffer for CHDIV > 2

    0: Disabled (only valid for CHDIV = 2)

    1: Enabled (use for CHDIV > 2)

    Yes my first interpretation was that when you say channel divider is 2, you mean the CHDIV field is 0x0.  My results may have been muddied by VCO_PHASE_SYNC, which I have enabled by default (additional question about that below).

    - One additional question I meant to post originally.  The data sheet contains some conflicting information about how to set "IncludedDivide".  Table 11 has part of the answer, the included divide should be SEG0 * SEG1, but the generalizations it makes I don't think are correct.  For example, the channel divider 96 is divisible by 3 and IS divisible by 24.  According to the table, the include divide should be 4, but according to Table 8 the SEG0 for 96 is 2 and the SEG1 is 3, making the include divide 6.  Section 7.3.10.3 has the rest of the answer I think.  In step 3.2 it outlines that /2 is a special case so even though SEG0 * SEG1 for /2 is 2, this step says we should set include divide to 4 if /2, is that correct?  So my current implementation sets include divide to SEG0 * SEG1 from Table 8, unless /2 then include divide is 4.

    Thanks,

    Craig

  • 0 in reply to Craig Petre
    TI__Mastermind 18070 points
    Hi Craig,

    Let me answer the SEG1_EN question first. By the way, the datasheet calls this register with a different name but it'll be fixed in the next revision (will be on web soon). So I think what the datasheet is trying to say is that, set this register to 0 if using direct VCO output or divide-by-2; set it to 1 otherwise (channel divider >2).

    As for the lock failure, if you just load the default configs (go to Ticspro -> Default configuration -> load latest default) and then uncheck the SEG1_EN, toggle FCAL_EN, I'm sure it can be locked.
  • 0 in reply to Hao Z
    TI__Mastermind 18070 points
    The table 11 is really just bad wording. It means that the number is divisible by 3 but this number is not 24 or 192, not that this number is not divisible by 24 or 192. So the IncludedDivide for 96 should be 6, as auto-calculated in Ticspro.

    Regards,
    Hao
  • 0 in reply to Hao Z
    TI__Mastermind 18070 points
    For the second question, when OUTA_MUX is channel divider, the best practice is to set OUTB_MUX to channel divider as well. Setting output B to VCO is not wrong, but setting it to the same as output A saves 5mA current.

    Regards,
    Hao
  • 0 in reply to Hao Z
    Prodigy 50 points

    Thanks Hao, I'll digest this and do some more testing.  Our main concern at the moment is the lack of lock assertion on the MUXOUT pin.  We are seeing 0V on this pin regardless of the lock state being reported by the read back registers.  Prior to flipping the MUXOUT to lock detect, the read back of the rb_LD_VTUNE register indicates a lock (reads back 0x2), but then I set the MUXOUT_LD_SEL to 1 and we don't observe any change on the MUXOUT pin, still indicates 0V.

  • 0 in reply to Hao Z
    Prodigy 50 points

    Thanks Hao. So I think it is true that you can lock with or without SEG1_EN checked, if you are not in VCO_PHASE_SYNC mode. With the VCO_PHASE_SYNC enabled though, I only get lock if I enable SEG1_EN. The tooltip in the GUI seems to support this. I noticed it will recommend I set SEG1_EN for a /2 channel divider if VCO_PHASE_SYNC is checked. If VCO_PHASE_SYNC is unchecked, it seems to be happy with SEG1_EN checked or not.

  • 0 in reply to Craig Petre
    Prodigy 50 points
    I think we can stand down on the MUXOUT lock detect. That was cockpit error on my part. Because I have to configure the part with one sweeping set of register writes I cache the register values while setting up our configuration and then flush them to the part once our configuration is complete. I had a bug in that implementation.. causing the MUXOUT_LD_SEL to be prematurely flipped. Sorry about that.
  • 0 in reply to Craig Petre
    TI__Mastermind 18070 points
    Hi Craig,

    No problem. It seems that question 2, 3 and 4 are clear. To conclude question 1,

    1. When VCO_PHASE_SYNC = 0, SEG1_EN needs to be checked if channel divider is used and divider value is greater than divide-by-2.
    2. When VCO_PHASE_SYNC = 1, SEG1_EN needs to be checked if channel divider is used.

    Regards,
    Hao