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.

LMK03033C EVM lock problem

Other Parts Discussed in Thread: CODELOADER

We are trying to debug a temperature problem in our product which uses and LMK03033C. We ordered the evaluation board for this part, and set it up the same way as our product. It has the input reference at 50 MHz, PD running at 2MHz, and the PLL running at 2160 MHz. I am using the same code that our product does, but the EVM will not lock. Here are the register settings:

Current constants for LMK03033C
-------------------------------
Divider #: 0 1 2 3 4 5 6 7
MUX:       1 1 1 1 1 0 0 0
EN:        1 0 0 0 0 0 0 0
DIV:      40 40 2 4 1 1 1 1
DLY:       0 0 0 0 0 0 0 0

DIV4: 0 VCO_C3_C4: 10 VCO_R3_LF: 0 VCO_R4_LF: 0
OSCin_FREQ: 50 PLL_R: 25 PLL_N: 216 VCO_DIV: 5
PLL_MUX: 3 EN_Fout: 1 POWERDOWN: 0 PLL_CP_GAIN: 3
GOE: 1 LD: 0 SYNC: 1

I can cycle the LD pin from the R divider, PD or N divider. The R divider output is exactly as expected, a 1MHz square wave. The LD pin is low. The N divider output is either constant high, constant low, or occasionally 115.7kHz. Looking at Fout, it is either not there or it is somewhere between around 1.6GHz and 2.6GHz, but not locked. The CP_Gain does not make any difference. Sometimes cycling the mux for the LD pin causes Fout to disappear. I have tried other settings for PLL_N, but the results are the same. The C3_C4 setting is as on P 33 of the EVM manual.

Again, this is a standard evaluation board, the only change being to move R7 to R11 to allow an external OSC_IN. The input level is +3dBm, and the output of the R divider is exactly correct.

I have looked through the data sheet, but nothing jumps out at me. The registers are being programmed in the order recommended in the data sheet.

The VCO can clearly cover my frequency, and R divider is working. It seems like the N divider is not working for some reason- and of course then the PLL can't lock. But these same settings in our product give good results.

Any ideas on what can cause this behavior would be greatly appreciated.

  • Are you using the CodeLoader software to program the EVM?

    Sounds like you are doing the right thing to debug an PLL locking issue; outputting the PLL R/2 and PLL N/2 outputs for observation and have identified the feedback as the issue.

    When you program R15 which contains the PLL_N and starts the VCO calibration, what does CPout2 voltage look like?

    73,
    Timothy
  • No, for some reason the EVM came with an adapter for an LPT port lol! So I connected a small board (Pyboard) running Micropython. We have used this before and have drivers written for the LMK03033C, which we also use in our product. I used a DSO and verified bit-by-bit that R15 is being written out as expected. The SPI is running at about 300kHz, so there should not be timing issues, and the active edge is right in the middle of the data. Also, I know that the R divider is being set up correctly, and that I can change the LD MUX. So I believe the interface is all working correctly. It is a pretty simple interface as these things go.
    Occasionally I get LD=1. When that happens, CLKout0 is at 115kHz! And there is no sign of anything on Fout from DC to 3 GHz. It took a while to see this, since my analyzer is normally set up in the GHz range!
    The only way to explain this is that 1) Fout has been turned off and 2) N_DIV has been set to a very large value. Unfortunately there is no way to read back from this chip to see what is going on.
    I even verified that it is indeed an LMK03033C chip, not one of the other members of the family, since I think they all use the same EVM.
    The controller is mounted right on the back of the EVM, so the leads are short. I will investigate grounding etc, just in case I missed something.
  • Okay- I found it. Even though the two units looked to be grounded, one of the plated through holes was not, in fact, a ground! So I must have been getting noise on the SPI, even though it looked totally clean on the scope.
    Sorry for the bandwidth, but sometimes taking a break to write everything down helps get to the bottom of it.