• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 20 subscribers
  • Views 240 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LMX2595: Lock detect reports sporadic false lock when REFin removed

Toby Brown
Prodigy 10 points
Part Number: LMX2595

Hello,

We are using the LMX2595 on multiple platforms and have found that the Lock Detect output from the MUX pin (LD_TYPE=1) can report false lock transitions when the REFin oscilaltor is removed. Some devices don't do it, some devices do it very regularly. We have two evaluation boards and one of them does it very badly.

We have found that reducing the state machine clock frequency (CAL_CLK_DIV = 3) and adding maximum LD_DLY value of 65535 improve the situation, but do not resolve it fully.

Is there a way to stop the lock detect reporting false sporadic locked status when the input reference clock is removed ?

Thanks,

Toby

  • 0
    TI__Guru* 81580 points

    Hi Toby,

    I don't aware of this problem. What is your input frequency? If you do a register read back, what do you get from rb_LD_VTUNE?

  • 0 in reply to Noel Fung
    Prodigy 10 points

    Hi Noel,

    Thank you for your reply.

    I'm using a 50MHz reference clock.

    Does rb_LD_VTUNE reflect the status of the MUX pin, or is this defined by something else within the IC ?

    Am I correct in saying the internal state machine uses the REFin clock to function ? If that is correct, how can the MUX pin change state when the REFin signal is removed ?

    Best wishes,

    Toby

  • 0 in reply to Toby Brown
    TI__Guru* 81580 points

    Hi Toby,

    After a VCO calibration is executed and Vtune voltage is within an acceptable range (silicon defined), MUXout pin should go HIGH and rb_LD_VTUNE should read back = 2 (locked). 

    The lock status with both approaches is real time monitoring through Vtune measurement (because LD_TYPE = 1).

    State machine clock is equal to fosc/2^CAL_CLK_DIV. This clock is mainly used for VCO calibration. Lock detection and SPI programming does not need this clock.

    Here in my lab I cannot replicate your problem, no matter how I remove the reference clock, either turning On/Off the signal generator or unplug the cable.

  • 0 in reply to Noel Fung
    Prodigy 10 points

    Hi Noel,

    Thank you for your reply and explanation on the state machine clock versus lock detect.

    I am finding that some PLL devices do not have this 'feature' and some do. Are you able to test more than one PLL sample ?

    I can replicate this on a TI Evaluation board, so I will do that again now and send you the register values. I am finding that the false lock transitions are quite short, in the order of micro seconds, so you will need to have an oscilloscope triggering on a rising edge to capture them.

    This issue is becoming very serious with one of our customer, therefore would it be possible to arrange a conference call with you, to discuss in more detail please ?

    In the meantime, I will collect more data for you.

    Thanks and best wishes,

    Toby

  • 0 in reply to Toby Brown
    Prodigy 10 points

    Hi Noel,

    Earlier, you explained that lock detection and SPI did not need Fosc to function. However, please can you then explain why I see significantly less false locked transitions from the MUX output, when I set LD_DLY from 0 to 65535 ? If the state machine isn't running, how does changing this value significantly alter the result ?

    If I use TICS Pro to set the registers within the LMX2595 and then read rb_LD_VTUNE, I very rarely see a change of state. However, the oscilloscope is continually re-triggering on false locked transitions. Is this simply due to the TICS Pro update rate being very slow ?

    This issue is now very serious with our customer and I really need to speak with someone please. An email exchange once every 24 hours is not a satisfactory solution as we will soon be placed on production stop.

    Thanks and best wishes,

    Toby

  • 0 in reply to Toby Brown
    Prodigy 10 points

    Hi Noel,

    Register dump, as promised :

    R112 0x700000
    R111 0x6F0000
    R110 0x6E0000
    R109 0x6D0000
    R108 0x6C0000
    R107 0x6B0000
    R106 0x6A0000
    R105 0x690021
    R104 0x680000
    R103 0x670000
    R102 0x660000
    R101 0x650011
    R100 0x640000
    R99 0x630000
    R98 0x620000
    R97 0x610888
    R96 0x600000
    R95 0x5F0000
    R94 0x5E0000
    R93 0x5D0000
    R92 0x5C0000
    R91 0x5B0000
    R90 0x5A0000
    R89 0x590000
    R88 0x580000
    R87 0x570000
    R86 0x560000
    R85 0x550000
    R84 0x540000
    R83 0x530000
    R82 0x520000
    R81 0x510000
    R80 0x500000
    R79 0x4F0000
    R78 0x4E02A9
    R77 0x4D0000
    R76 0x4C000C
    R75 0x4B0800
    R74 0x4A0000
    R73 0x49003F
    R72 0x480001
    R71 0x470081
    R70 0x46C350
    R69 0x450000
    R68 0x4403E8
    R67 0x430000
    R66 0x4201F4
    R65 0x410000
    R64 0x401388
    R63 0x3F0000
    R62 0x3E0322
    R61 0x3D00A8
    R60 0x3C0000
    R59 0x3B0001
    R58 0x3A8001
    R57 0x390020
    R56 0x380000
    R55 0x370000
    R54 0x360000
    R53 0x350000
    R52 0x340820
    R51 0x330080
    R50 0x320000
    R49 0x314180
    R48 0x300300
    R47 0x2F0300
    R46 0x2E07FD
    R45 0x2DC8C0
    R44 0x2C3283
    R43 0x2B0000
    R42 0x2A0000
    R41 0x290000
    R40 0x280000
    R39 0x270001
    R38 0x260000
    R37 0x250404
    R36 0x240080
    R35 0x230004
    R34 0x220000
    R33 0x211E21
    R32 0x200393
    R31 0x1F43EC
    R30 0x1E318C
    R29 0x1D318C
    R28 0x1C0488
    R27 0x1B0002
    R26 0x1A0DB0
    R25 0x190C2B
    R24 0x18071A
    R23 0x17007C
    R22 0x160001
    R21 0x150401
    R20 0x14E848
    R19 0x1327B7
    R18 0x120064
    R17 0x110129
    R16 0x100080
    R15 0x0F064F
    R14 0x0E1E70
    R13 0x0D4000
    R12 0x0C5001
    R11 0x0B0018
    R10 0x0A10D8
    R9 0x091604
    R8 0x082000
    R7 0x0740B2
    R6 0x06C802
    R5 0x0500C8
    R4 0x040A43
    R3 0x030642
    R2 0x020500
    R1 0x010808
    R0 0x00251C

    Best wishes,

    Toby

  • 0 in reply to Toby Brown
    TI__Guru* 81580 points

    Hi Toby,

    Let's take this offline.