LMK05318B-Q1: Can't get DPLL to lock when outputs are CMOS +/+ and using sync

Hi George,

I will review your question and reply today or tomorrow.

Regards,

Jennifer

Hi George,

(Once again, I did not hit the Reply button yesterday! Sorry about the delay.)

Some questions for you:

1. If you configure the SYNC_AUTO_APLL and program the EEPROM. Do the outputs boot OK or are they unstable? Are you seeing the instability with EEPROM programming or in-system (after-boot) programming?
2. Can you specify how you are determining the outputs are unstable? Do they not output at all?
3. Setting the LVCMOS outputs as +/- is recommended to reduce EMI and improve jitter performance. However, it should not cause the outputs to be unstable.
4. Is this a custom board or the evaluation module? Can you share your schematic of LMK05318B if you're using a custom board?

Regards,

Jennifer

Jennifer Bernal said:

Once again, I did not hit the Reply button yesterday! Sorry about the delay.

Oh please, If I had a nickel for every time I did something like that over the last 50 years, I'd have retired to Aspen before the turn of the century.

Jennifer Bernal said:

If you configure the SYNC_AUTO_APLL and program the EEPROM. Do the outputs boot OK or are they unstable? Are you seeing the instability with EEPROM programming or in-system (after-boot) programming?

The issue happens both ways.

Jennifer Bernal said:

Can you specify how you are determining the outputs are unstable? Do they not output at all?

I have the OUT4-7 P and N pins routed out to 8 SMA bulkhead jacks with the P pins connected to my o-scope with 50-ohm inline terms and the N pins terminated with 50ohm SMA terms.  The o-scope trigger comes from a 10MHz GPS disciplined oscillator so when the outputs are locked and synced I get 4 nice stable square waves with the rising edges right on top of each other. They're not phase aligned with the trigger or with PRIREF (a jittery 10MHz square wave from a different GPS) but I expect that and don't need it anyway. When I have SYNC_MUTE enabled, I get nothing or flickering square waves when the issue happens.  I also have STATUS0 following DPLL_LOPL and STATUS1 following DPLL_LOFL with both pins connected to a host that prints pin changes.  Here's an example of what I get when things don't work...

2025-07-23 14:46:42.934 Phase Unlocked -- PHASE: Unlocked FREQ: Locked -- LOPL: 7976 LOFL: 37
2025-07-23 14:46:42.947 Phase Locked   -- PHASE: Locked FREQ: Locked   -- LOPL: 7976 LOFL: 37
2025-07-23 14:46:42.948 Phase Unlocked -- PHASE: Unlocked FREQ: Locked -- LOPL: 7977 LOFL: 37
2025-07-23 14:46:42.960 Phase Locked   -- PHASE: Locked FREQ: Locked   -- LOPL: 7977 LOFL: 37
2025-07-23 14:46:42.965 Phase Unlocked -- PHASE: Unlocked FREQ: Locked -- LOPL: 7978 LOFL: 37
2025-07-23 14:46:42.977 Phase Locked   -- PHASE: Locked FREQ: Locked   -- LOPL: 7978 LOFL: 37
2025-07-23 14:46:42.981 Phase Unlocked -- PHASE: Unlocked FREQ: Locked -- LOPL: 7979 LOFL: 37
2025-07-23 14:46:42.994 Phase Locked   -- PHASE: Locked FREQ: Locked   -- LOPL: 7979 LOFL: 37

If I don't have SYNC_MUTE turned on and there wasn't ever a good DPLL phase lock, APLL1 will be using the XO which isn't a perfect 12.8MHz so the outputs will be slightly off-frequency and they'll look like they're free-running compared to the GPSDO trigger.  If it did manage to get a DPLL phase lock for a bit, then the outputs will be good but every few seconds I'll get a few DPLL_LOPL and a HOLDOVER and eventually they'll drift away from PRIREF if they the DPLL never phase loks again..  

Jennifer Bernal said:

Setting the LVCMOS outputs as +/- is recommended to reduce EMI and improve jitter performance

Yep and I can verify that setting at least 2 of the channels to +/- does make things stable but I really do need those rising edges to be aligned as they get routed to the clock inputs of software defined radios.

Jennifer Bernal said:

However, it should not cause the outputs to be unstable.

Yeah, that's what's confusing me.  I don't understand why output crosstalk would cause the DPLL to have phase lock issues?

Jennifer Bernal said:

Is this a custom board or the evaluation module? Can you share your schematic of LMK05318B if you're using a custom board?

It's not an EVM.  Right now, it's a prototype arrangement that follows the sample application schematic from the datasheet but that's changed about 100 times as I try to minimize the output crosstalk.  The only real differences are...

• The chips themselves are mounted on Proto-Advantage QFN48 to 52pin DIP adapters.  The ground pad is well connected to the 4 extra pins. This allows me to swap chips and baseboards around as the design evolves.  I don't use OUT0-3 at all and OUT4-7 are on the opposite side of the adapter so there's no chance of crosstalk to PRIREF or SECREF.
• The VDD pins don't have ferrite beads on the lines but they all have their bypass caps and I've checked each pin for ripple and voltage with the scope. 
• I have 2 VDD regulators, one 3.3v for logic and another that has a selectable output for 1.8v, 2.5v and 3.3v. for the VDDOs.  Both are 3A and fed from a 5v 4A PSU.  Total current draw at the PSU hovers around 350ma and the voltages at the pins always remain in spec.
• I do have a small heat spreader and a fan on the chip because my IR camera was showing >100°C temps on the top of the package and even though the ground pad is well mechanically and electrically connected to the adapter. the adapter wasn't really designed to sink that much thermal energy.  With the spreader and fan, the package temp seems to hover around 60°C.

Some of the things I've tried...

• Switching from coax to twisted pair.  Oddly enough, the twisted pair helped even though the outputs aren't balanced.
• Not aligning the SMA jacks with the output pins (randomly criss-crossing the cables) also helped a bit.
• Double checking that the jack shells were all properly bonded.  They were.
• Changing the VDDO supply voltage between 1.8v, 2.5v and 3.3v.  No help.
• Changing the GPS output/ PRIREF input to a random  frequency like 7.326719MHz just to make sure that there was no crosstalk between the outputs and input.  No help.

Jennifer, unless you see something in the tcs files or have some quick suggestions, don't spend a lot of time on this.  It has to be a hardware issue on my end and for all I know, it could be the office cat messing with me.  Now that I think about it, it could also be the u-blox GPS but at this point, I'm not sure if that's more or less likely than the cat. Anyway, I've got a few more things to try.

Hi George,

I appreciate the understanding. Let me give it a test in lab today and get back to you if I see similar results.

Regards,

Jennifer

George,

I had issues loading the file, lmk05-10mhz-rev11-chan4567-++-sync-mute.tcs. TICS Pro gave a load error upon importing the tcs, so I regenerated it based on what I understood were your settings. Please let me know if these vary from your original settings:

e2e_2025-07-24_lmk05-10mhz-rev11-chan4567-++-sync-mute.tcs

Using the above file, I did not observe issues using the +/+ CMOS output. The DPLL could phase lock to a 10 MHz input with or without SYNC_AUTO_APLL.I also tried loading the config from EEPROM and experienced no issue (DPLL achieved phase lock).

If DPLL phase lock is being impacted by the CMOS +/+ outputs, then I'm thinking there could be some routing issues that is causing the crosstalk with VDD_DIG / CAP_DIG and the output clocks.

Can you please share the VDD and VDDO supply filtering schematic? Do you use a setup like the datasheet or user's guide: 3.3V --> ferrite bead --> capacitor to gnd --> pin?

Regards,

Jennifer

Jennifer Bernal said:

I had issues loading the file, lmk05-10mhz-rev11-chan4567-++-sync-mute.tcs. TICS Pro gave a load error upon importing the tcs

Ah, I uploaded a version of the file with Unix line endings by mistake instead of the original Windows line endings.  I've attached the original file below.

Jennifer Bernal said:

If DPLL phase lock is being impacted by the CMOS +/+ outputs, then I'm thinking there could be some routing issues that is causing the crosstalk with VDD_DIG / CAP_DIG and the output clocks.

Can you please share the VDD and VDDO supply filtering schematic? Do you use a setup like the datasheet or user's guide: 3.3V --> ferrite bead --> capacitor to gnd --> pin?

It would be strange if that were the case.  The schematic is loosely based on the "Typical Application" schematic from the LMK05318B datasheet.   I don't have the ferrite beads or the 10uf caps that form the filters (mostly because I didn't have any beads handy and I kept forgetting to order them) but I do have the 0.1uf bypass caps right next to the pins.  I did check the power at the all of the VDD pins with the o-scope to make sure there was no ripple or voltage drops.  The QFN to DIP adapter does put pins 1-24 and 25-48 on opposite sides so there's no output stuff in the vicinity of pins 3 and 4.  Pin 6 is PRIREF_P of course but it's routed away from pins 3 and 4.

I'm getting more and more convinced that I have a ground problem between the u-blox, the baseboard, the host and the o-scope.   If you could just take a look at the updated tcs file below and let me know if there's anything "off" about it, that's all I really need.  The refclock validation params are looser than normal because the clock coming from the u-blox gets jittery at frequencies above 5MHz but everything else was auto-calculated by the wizard.

7268.lmk05-10mhz-rev11-chan4567-++-sync-mute.tcs

After pulling everything apart, there was a cold solder joint in the ground connection between the u-blox and the lmk05318b.  It was causing the ground to prefer running through the baseboard, out the sma jack shells, through the o-scope, out it's USB shell to the host usb hub, out the usb hub to the u-blox via its shell.  I'd fire the guy that did it but it was me.  The official story however is that the office cat distracted me at the exact time I was soldering that connection.  Nobody's buying it.

Anyway...  Thanks for being patient with me Jennifer!  I do have a few more TICS Pro oddities to report but I'll post them separately.