LMK61E2: See above

Dear Connor,

Second reply. (My first reply email was returned, file size too large.)

Let’s try again.

Dear Connor,

Thank-you for the prompt reply, it makes such a good impression!

Yes, I can supply the schematic and more. Please open RFOsc1-Synth.pdf:

Please note:

1. LMK61E is U5 on left hand side.
2. Total schematic is part of a bigger project. Separately, not shown is the control PCB with the PIC32MK1024GPK064 connected to P1 at bottom.

U3 LMX2592 is not yet soldered in. All passives surrounding U5 are soldered. All power supply regulators are fitted and measured.

All digital voltages are 3.3V. U5-6 was measured 3.3V. Most passives are 0402. Decoupling capacitors are 0603 or Tantalums, local adjacent decoupling 0.1uF capacitors eg C23, C27, C42 are 0402.

R30 (12K) was replaced with a link to GND. ADD (U5-2) is now grounded, connect U5-2 to U5-3.

Not shown are the I2C3 connections SDA and SCL from P1-19 and 20, to U5-7 and 8. Connection is made at I2C3 SCL >= 100KHz (~106KHz).

1. The I2C3 connections all work fine because I managed to read the LMK61E2 registers R0 – R73 using my PIC32MK. Handshake acknowledges from LMK61E2 (I2C3 slave) and PIC32MK (I2C3 master) all good and tested with a 16 channel logic analyser.
2. Please open the Excel spread sheet TiData.xlsx

The first column is the LMK61E2 register address.

The second column “Pic-Read” is the actual data read from the LMK61E2, columns A and B automatically created by MPLAB XIDE emulation. MPLAB and my I2C3 software reads all of the “in-between” registers (e.g R10 – RR15) as zero.

Columns C (Freq forgotten) and D (Freq = 156.25 MHz) were generated by the Ti APP CodeLoader. I manually spaced the data according to the correct register addresses.

Column F = “RESET”  are the RESET values according to the datasheet.

1. In software XC32, I use the SlaveADD (type char) in 8-bit mode, then set or clear bit 0 for Read or write. Software is easier to write. XC32-Software function I2C3_transmit(char) sends 8-bits.
2. EEREV R9, row 11 all columns are still = 0. No EEPROM writes yet.
3. R16 and R17 XO_CAPCTRL_BY1 are different. Why?
4. R21 and R22 are all the same. Outputs all turned on and type LVPECL.
5. R32 PLL_FRACDEN_BY0 row34 are different. All other frequency control parameters are the same.
6. R50. (NVMLCRC) The datasheet does not describe R50. Is this an error? Anyhow, there is a difference.
7. R53. RAMDAT. I am not sure of the significance of this difference?
8. R56. NVMUNLK. I am not sure of the significance of this difference?
9. Outputs at R27 and R28 measured with Hantek DSO5202P oscilloscope [200MHz] (10:1 probes.)

Thank-you for your response, in anticipation.

Regards

Deryck G. Lauf.

Hi Deryck, 

It looks like your schematic (named RFOsc1-Synth.pdf) didn't go through, can you try resending it? Here are a few comments about your register configuration:

1. R16 and R17 XO_CAPCTRL_BY1: These should be reset to the default values of 0x0 for R16 and 0x80 for R17. It's possible that it's pulling the XO frequency too far and making it difficult for the PLL to lock correctly. Do these values get reset after you write them?

2. R32: Since you're in integer divide mode this may not be as important, but I would still recommend reprogramming to 0x01 since that's what the tool recommends for the default profile. 

3. R50: Even though there's a difference, I wouldn't worry since the device is most likely resetting these bits after you write 0x00 for some internal uses.

4. R53: These are just the last bits that were written into SRAM, most likely not important here 

5. R56: After an EEPROM write sequence is finished, this should be rewritten to 0x00 to avoid rewriting the EEPROM with unwanted values. I expect this could be causing some unwanted behavior. 

Besides R16, R17, and R56, I didn't notice anything else that could be causing issues in your register settings. Can you provide the read values of R66 and R72 as well? This can tell us if the PLL is locked or not. If it's not locked, you can try writing a '1' to bit 1 of R72 to reset the PLL. 

Regards, 

Connor