• TI Thinks Resolved

LMK05028: 10MHz output from 1PPS ref

Prodigy 180 points

Replies: 36

Views: 373

Part Number: LMK05028

Hi,

I'm trying to configure LMK05028 to generate a 10MHz output from a 1PPS reference signal coming from a GPS receiver. The configuratio is the following:

XO: 48MHz

TCXO: 10MHz

IN0: 1PPS

OUT0: 10MHz from DPLL2

DPLL2 Mode: 3-loop

I attached the .tcs file in order to let you have a deeper look to my configuration.

On OUT0, I get 10,000,003MHz rather than 10,000,000MHz; after some tests, it seems that the component do not correctly locks to the 1PPS input: infact, the 10,000,003MHz output is present even if the GPS receiver is not connected.

What would you suggest to solve the problem?

Best Regards,

Michele

1PPS_LMK05028.tcs

  • Hello Michele, 

    Is the status readback already in the .tcs file? It doesn't seem to be the case considering the information you have provided and what's it's showing there.. 

    Please go to status tab and do a readback. 

    Thanks and regards,

    Amin

  • In reply to Amin Eshraghi:

    Hello Amin,

    the component is not directly connected to the PC, but it is already installed on our custom CPU board and configured through I2C: from TICS PRO, we generate 2 configuration files with "Save DPLL1 Register Set with Outputs" and "Save DPLL2 Register Set with Outputs" respectively and we use them as an input for our configuration script. For this reason, a read back from TICS PRO may nnot reflect the actual component configuration.

    Anyway, I attach you the following files:

    DPLL1_v025.txt & DPLL2_v025.txt --> configuration files from TICS PRO

    HexRegisterValues.txt --> Register read back from TICS PRO (offline mode)

    readback.txt --> Read back from LMK05028 through I2C

    Hope this helps to have a closer look to the problem.

    Regards,

    Michele

    DPLL1_v025.txtDPLL2_v025.txt5661.HexRegisterValues.txtreadback.txt

  • In reply to michele pedroni:

    Hi Michele, 

    Since you're seeing a frequency error and mentioned this is irrelevant of the reference input, it suggests even when reference input is available DPLL is not locked. I asked for status readback to understand whether reference was validated and selected. And then to see if DPLL is indeed not locked. 

    Looking at the readback.txt file that you have sent, that's is what it shows, reference is not valid DPLL is in holdover mode. Was this during the time reference was connected to the device? 

    Secondly, the configuration was tested on evm and showed no problem, correct? It's now an issue on the actual cpu board. 

    Thanks and regards, Amin

  • In reply to Amin Eshraghi:

    Hi Amin,

    I confirm that the readback was made with the reference 1PPS connected, and we get the same result even if the reference is not connected. At the moment, we did not test this configuration on the EVM because we do not have it, but we will buy asap to verify the situation.

    I'll be back to you after the tests on EVM.

    Best Regards,

    Michele

  • In reply to michele pedroni:

    Furthermore, I attach you the CPU board schematic.

    Best Regards,

    Michele

    1803.lmk.pdf

  • In reply to michele pedroni:

    Hi Michele, 

    Testing out on EVM should give us a lot more information. 

    I noticed the status 0 and status 1 signals were set to DPLL1 rdiv and ndiv, the GPIO statuses are also monitoring DPLL1. Your configuration is only using DPLL2 / APLL2 with DPLL1 / APLL1 powered down. It would be more beneficial to monitor DPLL2 signals. 

    Secondly, LOL_PLL2 flag is up, indicating APLL2 is not locked. In this situation I wouldn't expect any reasonable type of output... the 10.000003 MHz you're seeing shows just very small frequency error and does not correlate with a LOL_PLL2 status... so something is off.. 

    Regards, Amin 

  • In reply to Amin Eshraghi:

    Hello Amir,

    I come back to this issue after having received the Evaluation Kit and loaded the configuration we already discussed.

    The results we get are the same we saw on our custom board, to this seems just a configuration issue. After that, following your advices, we switched STAT0 and STAT1 to DPLL2 Loss of Lock and DPLL2 Holdover Active respectively. Indeed, having a look to "Status & Interrupt" page on TICS Pro, the following interrupts are raised for DPLL2:

    LOPL_DPLL2

    LOFL_DPLL2

    HLDOVR2

    while LOL_PLL2 is NOT set. So, in my undestanding, the APLL2 is locked but there is no phase and frequency lock, so the DPLL2 is in holdover state. Since we have a 1PPS ref, frequency and phase lock are not available anyway, and we have only a jitter threshold control, isn't?

    At this point, could you give me any advice on how to change the configuration to let it work as expected?

    Best Regards,

    Michele

  • In reply to michele pedroni:

    Hi Michele, 

    The APLL can lock just using XO, so that's why it's showing it's locked. You're output frequency error now will be dependent on the XO ppm error. 

    To get the DPLL locked, we first need a valid reference. From the config you sent, looks like you're using IN0.

    - Is their a 1 Hz signal connected to IN0?

    - On the status readback, does it show REF0 valid?

    - Does DPLL2 select REF0? 

    Thanks and regards,

    Amin 

    Note this just a random capture to show visually - obviously if no reference is valid DPLL can't select any of them. 

  • In reply to Amin Eshraghi:

    Hi Amin,

    we are using the 3-loop configuration and probably the PLL is not only locked to XO but also to TCXO (infact, ignoring the TCXO with a 2-loop configuration leads to a much higher frequency error). That's why the output frequency is so close to the expected value. However, we can say now that the reference is not valid or at least not recognized by the LMK05028: a 1PPS signal is connected to IN0 as it is supposed to be, but REF0VALSTAT is NOT checked and DPLL2_REFSEL_STAT show Holdover state.

    At this point, we should focus on the reference signal. These are 2 oscilloscope screenshots which show the 1PPS reference we have on IN0. Could you check if you see something wrong?

    Best Regards,

    Michele

  • In reply to michele pedroni:

    Hi Michele, 

    Yes, you probably have 2 loops locked, but TCXO is used for TCXO DPLL. So the APLL can get locked just using XO reference. 

    Why is the duty cycle so bad? It looks like the P-duty cycle is only around 20%. 

    Regards,

    Amin