LMK04832EVM: 983.04MHz Clk out and 10MHz external sync

Alex,

The SYNC pin should not be involved, and I think you may be misunderstanding how the SYNC pin works. The SYNC pin is a CMOS input port that controls the timing of divider resets, or serves as a trigger for the SYSREF divider. It is not involved in locking the PLL, and you shouldn't have anything connected to this port.

If your signal generator is providing 122.88MHz to the locked LMK04832 PLL, and the same signal generator (or another signal generator sharing the same 10MHz reference port) provides the test signal to the ADC, the reference clock from the locked PLL to the ADC (at 983.04MHz) and the test signal to the ADC from the SigGen should be frequency-locked (e.g. if your test signal is 10MHz, you will count exactly 983,040,000 clock pulses from the locked PLL for every 10,000,000 pulses from the SigGen at the ADC, with no missing or extra pulses).

I've tested the configuration file below and confirmed that, when I provide 122.88MHz at +6dBm from the signal generator to CLKin1, I get 983.04MHz out of CLKout2. I made three changes to the default configuration:

• Set 0x144 to 0xFF; this guarantees that there will be no output divider resets from activity on the SYNC pin (we want this)
• Reprogrammed DCLK2_3_DIV to divide-by-3
• Enabled DCLK2_3_DCC to activate duty cycle correction for odd clock divides, since we must divide-by-3 to get 983.04MHz.

The procedure I used to load the file:

• Load TICS Pro and select LMK04832
• Ensure I have a USB2ANY plugged in and detected
  
  
  • If not, check under the USB communications -> Interface menu, and with the USB2ANY plugged in, confirm that USB2ANY is a selectable interface option in the Communication Setup dialog.
    
  • The serial number should be auto-detected as long as this is the only instance of TICS Pro and there is only one USB2ANY connected.
  • You can also double-check if the USB2ANY you have connected is responding from this menu by clicking the Identify button.
• File -> Load the config file

1537.983p04MHz_LMK04832.tcs

PLL2 should automatically lock once you've loaded this file, regardless of the state of PLL1. If you're not seeing at least PLL2 lock after loading this file, something's gone wrong either in communication or on the PLL. Likewise, if you're not seeing PLL1 lock after providing +6dBm 122.88MHz at the CLKin1 port and loading this file, something's gone wrong (but it may not be related to communication and is probably isolated to the reference path or the CPout1 components). You can attempt some other basic diagnostics:

• Double check that the LDO output test point (LDO_OUT_LP3878) is producing 3.3V. You should be supplying at least 4.3V, 1.5A to the supply connection at J39 or J40.
• Check for communication: on the User Controls page, under the General tab, try setting POWERDOWN=1 and observe the supply current; it should drop significantly in the powerdown state (any remainder is likely the VCXO).
  
• Probe the CPout1 and CPout2 nets to check the voltages.
  • CPout1
    • Low voltage (< 1V) suggests the reference input is too low relative to the VCXO frequency; the reference power may not be high enough, or the reference may not be connected properly. Consider probing the CLKin1 path close to the device with an oscilloscope (be aware that the high-frequency signal will be distorted by the probe to some extent unless proper low-inductance probe grounding is respected)
    • High voltage (> 2V) suggests the reference input is too high relative to the VCXO frequency; there may be noise on the reference path creating nonmonotonic edges, or the VCXO may be faulted and not producing a signal. Consider probing both CLKin and OSCin paths to make sure the signal is present and monotonic as expected.
  • CPout2
    • Low voltage (< 1V) suggests the reference input is too high relative to the VCO frequency; there may be noise on the VCXO input, or the VCO path may be misconfigured. I tested this configuration so there should be no issues with the VCO path, suggesting only the VCXO path (OSCin) should be checked.
    • High voltage (> 1.5V) suggests the reference input is too low relative to the VCO frequency; the VCXO may not be oscillating, or the OSCin signal may not be seeing it. Again, I tested this configuration, so this could only imply an issue with OSCin.

We'll start with this for now. If you've gotten to this point and are still having trouble, please provide the signal generator model number, some info about what CLKout2 is doing (is it producing a frequency close to 983.04MHz None at all? etc) and the results of the previous tests above. 

Regards,

Derek Payne

Hi Derek, 

Thanks for the detailed response. It seems there is something still wrong.  I ran through the debug you provided and found the following:

Derek Payne said:

output test point (LDO_OUT_LP3878) is producing 3.3V

This is true, the LDO measured 3.3V

Derek Payne said:

should drop significantly in the powerdown state

The setting POWERDOWN = 1 did not change the current both readings showed Icc = 538.64

After loading the configuration file in this thread neither PLL1 or PLL2 LED indicators came on with or without the external reference clock connected (I also double checked the external reference clock with our spectrum analyzer). 

I switched back to the 'Default Configuration', here I still do not see a PLL LED indicator turn on, only after playing around with the settings could I get the D2 LED to come on.

Derek Payne said:

about what CLKout2 is doing

 The frequency I see on CLKout2 using the configuration file provided above is 779.4MHz.

Derek Payne said:

provide the signal generator model number

I've tried two, one is R&S SMA100B and the other is Tektronix TSG4104A, both to no success.

Derek Payne said:

CPout1

I don't see where CPout1 and CPout2 are on the board but I see it on the schematic after the external loop filter of the VCXO... on the PCB VTUNE1 initially reads around 1V but drops to ~0.3V in around 20 seconds as I probe the pin.  The test pin VCO_VCXO is shorted to ground and test point PLL2_VTUNE measures 3mV. 

Would it be helpful to setup a debug session?

KR, 

Alex 

Apologies for the delay, I ended up out of office Friday and only just got a chance to look at this.

The supply current sounds correct, though it's weird that POWERDOWN = 1 did not put the device in the low-current state... you describe being able to communicate with the device in other conditions, so I'm not totally sure why toggling POWERDOWN = 1 didn't work for you. It's also exceptionally strange that the device did not lock either PLL with the default configuration. Something seems wrong with your device or your VCXO.

I've got one more step for you to try: can you configure PLL1_LD_MUX and PLL2_LD_MUX to show PLL1 R/4 and N/4, then probe the status signals with an oscilloscope and tell me what you see? I would expect the signals to be approximately 10MHz/4 and 122.88MHz/4, and if you're seeing something different it would be good to know. I'd also like to repeat the exercise with the signals set to PLL2 R/4 and N/4 as well, this time the signals should be very similar in frequency.

If PLL1 N/4 or PLL2 R/4 signals are in some way corrupted or off-frequency, this points to an issue with the VCXO or the OSCin path that would be consistent with both charge pumps dropping to ~GND voltage.

At this point it might also be a good idea to just probe the VCXO signal directly. You'll need a low loop inductance so use a scope probe with a pigtail and measure directly across the 50Ω termination at R62 or R63 (whichever is populated; let me know if both are unpopulated), and double-check that the VCXO is actually producing a signal.

If we suspect there is something wrong with the VCXO, you can try modifying the input path for manual bypass of the VCXO to test the PLLs... instructions below:

• R62 = 0Ω
• R70 = 50Ω
• R64 = DNP
• Move the 0.1µF from C20 to R72
• Remove FB12 to deactivate the VCXO

You'd then insert a signal from the signal generator on the OSCin SMA at 122.88MHz, reload the register configuration I sent, and check if PLL2 locks. If you make it to this step and PLL2 is still not locking, and you know you have communication with the board (checked by toggling POWERDOWN = 1 and observing reduced board current), either your part or your PCB is a lemon.

Regards,

Derek Payne