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.

LMX2615-SP: Will not lock on initial power on but subsequent attempts are successful

Part Number: LMX2615-SP

I am seeing a behavior where the first attempt to lock the LMX2615 synthesizer after power on will fail, but all subsequent attempts to lock are successful. Have others observed this and any idea on possible cause?

  • Hi Ryan,

    Did you follow the procedure as outlined in the datasheet section 7.5.1?

  • Hi Noel. Yes, I followed the procedure from the datasheet and still saw this behavior.

  • Hi Noel. Yes, I followed the procedure from the datasheet and still saw this behavior.

  • Hi Ryan,

    Could you share your TICS Pro configuration?

    Could you also try, after step 6, wait another 10ms and then program R0?

  • Hello, we do not used TICS Pro, however we have implemented a 10 ms after step 6 and then programmed R0. The behavior was still seen.

  • We are following the procedure outlined in the datasheet and did add a 10 ms delay after step 6. We are not using TICS Pro to configure the device, so we cannot provide that configuration. Are there any known issues, perhaps with certain registers that would be resolved as we attempt to re-lock after the first attempt fails? Would it be possible to setup a virtual meeting via Zoom or similar platform to discuss this issue with the application engineer?

  • Hi Ryan,

    What is the time interval between the first subsequent attempt and the first attempt to lock the LMX2615 synthesizer after power on? Lets say, if the time interval is 1 second, could you try make the delay to 1s after step 6 and them program R0? In the subsequent attempt, did you just program the necessary registers only or did you program all of the registers again? 

    What is your reference clock frequency and could you share your register configuration file?

  • Hello, the interval between the first and subsequent attempt to lock the synthesizer is several seconds. Any attempt to lock the synthesizer is several seconds after power on. We ran a test where we attempted to lock, failed, and then sent only the logic to change the frequency and this caused the synthesizer to lock. Then, we repeated the same test, but sent only the logic to re-cal and this also caused the synthesizer to lock. The reference clock frequency is 150 MHz.

    This is the init sequence used. ignore the column of FFs, the second column is the address, and the 3rd and 4th columns are the register values.

    FF 00 25 1E
    FF 00 25 1C
    FF 72 02 6F
    FF 71 00 00
    FF 70 00 00
    FF 6F 00 00
    FF 6E 00 00
    FF 6D 00 00
    FF 6C 00 F1
    FF 6B 00 00
    FF 6A 00 07
    FF 69 44 40
    FF 68 00 00
    FF 67 00 00
    FF 66 00 00
    FF 65 00 00
    FF 64 00 00
    FF 63 00 00
    FF 62 00 00
    FF 61 00 00
    FF 60 00 00
    FF 5F 00 00
    FF 5E 00 00
    FF 5D 00 00
    FF 5C 00 00
    FF 5B 00 00
    FF 5A 00 00
    FF 59 00 00
    FF 58 00 00
    FF 57 00 00
    FF 56 00 00
    FF 55 00 00
    FF 54 00 00
    FF 53 00 00
    FF 52 00 00
    FF 51 00 00
    FF 50 00 00
    FF 4F 00 00
    FF 4E 00 64
    FF 4D 00 00
    FF 4C 00 0C
    FF 4B 08 80
    FF 4A 00 00
    FF 49 00 3F
    FF 48 00 01
    FF 47 00 80
    FF 46 C3 50
    FF 45 00 00
    FF 44 03 E8
    FF 43 00 00
    FF 42 01 F4
    FF 41 00 00
    FF 40 13 88
    FF 3F 00 00
    FF 3E 03 22
    FF 3D 00 A8
    FF 3C 09 C4
    FF 3B 00 01
    FF 3A 80 01
    FF 39 00 20
    FF 38 00 00
    FF 37 00 00
    FF 36 00 00
    FF 35 00 00
    FF 34 04 20
    FF 33 00 80
    FF 32 00 00
    FF 31 41 80
    FF 30 03 00
    FF 2F 03 00
    FF 2E 07 FD
    FF 2D C0 DF
    FF 2C 1F 23
    FF 2B EE 00
    FF 2A 79 97
    FF 29 00 00
    FF 28 00 00
    FF 27 DA 80
    FF 26 FD 51
    FF 25 84 04
    FF 24 00 43
    FF 23 00 04
    FF 22 00 00
    FF 21 1E 21
    FF 20 03 93
    FF 1F 43 EC
    FF 1E 31 8C
    FF 1D 31 8C
    FF 1C 04 88
    FF 1B 00 02
    FF 1A 0D B0
    FF 19 06 24
    FF 18 07 1A
    FF 17 00 7C
    FF 16 00 01
    FF 15 04 01
    FF 14 F8 48
    FF 13 27 B7
    FF 12 00 64
    FF 11 01 2C
    FF 10 00 80
    FF 0F 06 4F
    FF 0E 1E 70
    FF 0D 40 00
    FF 0C 50 01
    FF 0B 00 18
    FF 0A 10 D8
    FF 09 06 04
    FF 08 20 00
    FF 07 00 B2
    FF 06 78 02
    FF 05 03 E8
    FF 04 0E 43
    FF 03 06 42
    FF 02 05 00
    FF 01 08 0C
    FF 00 21 1C

  • Hi Ryan,

    Basically the register configuration looks fine. 

    Please try below to see if there is improvement.

    Firstly, try FF 01 08 0C  --> 08 0A. If fail, then try FF 72 02 6F --> 02 68

  • Hello, Noel. Thank you for this suggestion. We have implemented these changes but unfortunately we continue to experience issues locking the synthesizer.

    In addition to implementing your suggestion, we have tried a few other tests, varying the timing of commands. I will try to summarize what we are seeing.

    Our default has been to send the register sequence that I previously shared (i.e.):

    1. Send initialization (no pause)

    2. change frequency (no pause)  (Lock detect measured high)

    3. Scrub registers (Lock detect measured high)

    Then we began to see the unit-to-unit variation, where some synthesizers would not lock with this sequence. We implemented you suggestions with no effect, then tried the following. 

     

    Test 1: 

    1. Disable register scrubbing

    2. Send initialization (no pause)

    3. change frequency with no delay + pause (Lock detect measured high)

    3. Enable register scrubbing (Lock detect measured high)

    Test 2:

    1. Disable register scrubbing

    2. Send initialization + pause (Lock detect measured high)

    3. Send change frequency + pause (Lock detect measured high)

    4. Enable register scrubbing (Lock detect measured low)

    The only difference between test 1 and test 2 is a pause added between sending the initialization sequence and the change in frequency. This result is repeatable, but we cannot explain why there is a difference in behavior.


    Test 3: 

    1. Enable register scrubbing

    2. Send initialization (no pause) (Lock detect measured high)

    3. Scrub registers (no pause) (lock detect measured high)

    4. Send change frequency (no pause) (Lock detect measured high)

    5. Scrub registers (Lock detect measured low)

    This timing dependent behavior is something that we are unable to explain. Several of the registers are either under defined or not defined at all in the datasheet. Are you able to provide a complete description of all registers?

    It is becoming urgent that we identify the root cause of this issue are resolve it. This part is being flown on a space mission and this type of unexplained behavior is not acceptable for that environment.

    Is it possible to continue this conversation via zoom or other real time means of conversation? 

  • Hello, 

    E2E is currently undergoing maintenance and will be unavailable until Monday, October 2nd. Responses will be delayed but we will get back to you as soon as possible. 

  • Hi Ryan,

    What does scrub register mean?

  • Hi Ryan,

    I talked to our aerospace expert, he concluded that this part does not need register scrubbing. 

    When you do scrubbing, which register did you write again?

  • Hi Noel,

    We currently scrub the entire register space of the PLL with the exception of the following registers (0x00, 0x28, 0x29, 0x2C).

  • Hi Noel,

    Can your aerospace expert please give some more detail on why register scrubbing is not needed? 

    Would you be able to provide detail on the rad hard design features?

    Are the registers in the LMX2615-SP TMR? 

    It would be be very helpful if you could provide the details behind the conclusion that register scrubbing is not necessary.

    Thanks you!

  • Hi Ryan,

    Feedback as follows:

    The registers of the LMX2615-SP are hardened by design, it is a proprietary technique, not TMR.

    We observed a reset only happened with the Au ion.  When testing at an angle with Xe to achieve the same LET we do not see this reset.

    Our speculation is that the sensitivity is to the Z of the ion and not the LET.

    Since it appears to be related to the Z of the ion, it would be a very rare occurrence in a space environment since there is a huge drop off in the flux of ions starting at iron.