LMK04832: PLL Looses Lock when rewrite registers.

Additional information is as follows:

The 10MHz reference clock (CLKin1) is always input stably.

When Xilinx's Microblaze CPU sets LMK04832 during initial booting, both PLL1 and PLL2 are locked. If the register is not rewritten, the lock is stable.

When both PLL1 and PLL2 are locked, if setting PLL2, PLL2 becomes unlocked.

However, if PLL2 is set while PLL1 is unlocked and PLL2 is unlocked, PLL2 becomes locked again.

But PLL1 is never locked again.

Hello,

We'll get back to you by next week.

Best,

Andrea

Hello, 

Sorry for the delayed response. Could you share a .tcs file of the configuration during the initial booting, and of the config that's being programmed afterwards? 

Note that we generally recommend programming the registers in numeric order. Particularly for registers 0x163 through 0x168 which set the PLL2_N and PLL2_N_CAL registers, the VCO calibration needs to be ran again after programming otherwise the device might not be able to lock. See section 8.5 of the datasheet for more details:

Regards, 

Connor 

Hello,
I also understand section 8.5 of the datasheet.
I programmed the registers in the attached order.
Then, I programmed the same data again.
I will share the .tcs file you mentioned soon.
We created a register set from TICS pro. And on the board we made, we programmed it using the microblaze CPU in the xilinx FPGA.

Regards,
BK

R0 0x000090
R0 0x000010
R2 0x000200
R3 0x000306
R4 0x0004D1
R5 0x000563
R6 0x000650
R12 0x000C51
R13 0x000D04
R256 0x010013
R257 0x01010A
R258 0x010210
R259 0x010340
R260 0x010400
R261 0x010500
R262 0x010601
R263 0x010711
R264 0x010813
R265 0x01090A
R266 0x010A10
R267 0x010B40
R268 0x010C20
R269 0x010D20
R270 0x010E01
R271 0x010F41
R272 0x011013
R273 0x01110A
R274 0x011210
R275 0x011340
R276 0x011410
R277 0x011500
R278 0x011601
R279 0x011711
R280 0x011813
R281 0x01190A
R282 0x011A10
R283 0x011B40
R284 0x011C20
R285 0x011D20
R286 0x011E01
R287 0x011F11
R288 0x012013
R289 0x01210A
R290 0x012210
R291 0x012340
R292 0x012410
R293 0x012500
R294 0x012601
R295 0x012741
R296 0x012813
R297 0x01290A
R298 0x012A10
R299 0x012B40
R300 0x012C10
R301 0x012D00
R302 0x012E01
R303 0x012F11
R304 0x013013
R305 0x01310A
R306 0x013210
R307 0x013340
R308 0x013420
R309 0x013520
R310 0x013601
R311 0x013711
R312 0x013811
R313 0x013900
R314 0x013A00
R315 0x013B98
R316 0x013C00
R317 0x013D08
R318 0x013E03
R319 0x013F07
R320 0x014003
R321 0x014100
R322 0x014200
R323 0x014301
R324 0x0144FF
R325 0x014500
R326 0x01461A
R327 0x01471A
R328 0x014802
R329 0x014942
R330 0x014A33
R331 0x014B06
R332 0x014C00
R333 0x014D00
R334 0x014EC0
R335 0x014F7F
R336 0x015001
R337 0x015102
R338 0x015200
R339 0x015300
R340 0x01547D
R341 0x015500
R342 0x01567D
R343 0x015700
R344 0x015896
R345 0x015906
R346 0x015A00
R347 0x015BD4
R348 0x015C20
R349 0x015D00
R350 0x015E1E
R351 0x015F0B
R352 0x016000
R353 0x01610F
R354 0x01628C
R355 0x016300
R356 0x016400
R357 0x01650C
R361 0x016958
R362 0x016A20
R363 0x016B00
R364 0x016C00
R365 0x016D00
R366 0x016E13
R371 0x017310
R375 0x017700
R386 0x018200
R387 0x018300
R358 0x016600
R359 0x016700
R360 0x01684C
R1365 0x055500

Hello, 

Understood, so you are writing the attached config to the device, then re-writing the same values again but only for registers 0x138, 0x147, 0x161, and 0x168? Assuming PLL2_FCAL_DIS = 0 then writing to 0x168 should trigger a VCO calibration and I would expect the device to be able to lock properly. Could you share the use case for re-writing these specific registers after the initial boot up? 

Also please note that most of our team is out of office for the Easter holiday so our responses may be delayed until early next week. 

Regards, 

Connor 

Hello,

I programmed the registers in the attached order. Both PLL1 and PLL2 are locked.
Then, I programmed the exactly same 25 registers again. I found that PLL1 or PLL2 are unlocked.

So, I checked whether the PLL was unlocked when a certain address was written.
Programming addresses other than addresses 0x138, 0x147, 0x161, and 0x168 remained locked.
PLL1 or PLL2 or Both PLL is unlocked only when programming addresses 0x138, 0x147, 0x161, and 0x168.
The values used when checking are the same values used during the initial program.

Bit [2] of 0x166 is the PLL2_FCAL_DIS bit. I did not enable PLL2_FCAL_DIS on TICS pro. And I programmed 0x00 in address 0x166 as I attached file.

Regards,
BK

.tcs file : 

MODEM_LMK04832_230905_clkin1.tcs

Hello,

We are out of office for a US holiday. Please expect a response by Monday.

Thanks,

Kadeem

BK,

I am taking this thread over from Connor.  Using your .tcs I am unable to reproduce your issue on my first test in the lab.  My first question is how are you checking the lock status of the PLL, because after rewriting their will be a small lock time delay that will occur before the PLL's are locked?

Regards,

Will

Hello,

I was also unable to reproduce this issue on EVM.

pin 31 Status_LD1 and pin 48 Status_LD2 of LMK04832 are connected to Xilinx FPGA. LMK04832 and Xilinx FPGA are mounted on my board. And then I can read the values of the LD pins.
As you know that the digital lock detect signal can be monitored on the Status_LD1 or Status_LD2 pin.
To program to output the status of lock detect for PLL1, PLL2, or both PLL1 and PLL2, the Address 0x15F is programed as 0x0B and Address 0x16E is programed as 0x13.

Regards,
BK

BH, 

Interesting.  Is the register writing sequence the same on bootup as it is on the subsequent writes? It is very odd that it locks on the EVM and on bootup but only fails to lock when re-writing.  Also doing some tests on the bench, the registers you identified as causing problems all change PLL register values.  It seems from this that the re-writing command may be writing a different register map?  Let me know what you think?

Regards,

Will

Hello,

Interesting.
Is the register writing sequence the same on bootup as it is on the subsequent writes?
BK : Yes, it is. The strange thing is that initial writing of the registers of LMK04832 is not performed when booting, and even if all registers are written after booting, the PLL is not locked.
It is very odd that it locks on the EVM and on bootup but only fails to lock when re-writing. Also doing some tests on the bench, the registers you identified as causing problems all change PLL register values. It seems from this that the re-writing command may be writing a different register map? Let me know what you think?
BK : I measured the SPI writing signal using a scope. I confirmed that it was the same value.

SPI Write/read can be controlled for each address using the UART terminal.
Like what I wrote a few days ago,
Programming addresses other than addresses 0x138, 0x147, 0x161, and 0x168 remained locked.
PLL1 or PLL2 or Both PLL is unlocked only when programming addresses 0x138, 0x147, 0x161, and 0x168.

Regards,
BK

BK,

BH KIM said:

BK : Yes, it is. The strange thing is that initial writing of the registers of LMK04832 is not performed when booting, and even if all registers are written after booting, the PLL is not locked.

How are the registers of the LMK04832 written when the PLL locks?

Regards,

Will

Hello,

All registers were programmed to the same values that were locked during initial booting.

Regards,
BK

BH,

BH KIM said:

he strange thing is that initial writing of the registers of LMK04832 is not performed when booting

I am confused when and how the registers are being written correctly at the beginning.  What is the startup sequence that allows the PLL to lock?

Regards,

Will

Hello,

I'm very sorry for confusing you.
There are two types of test.

test 1
Board's Power is ON ->
FPGA is configured ->
Microblaze(MB) CPU is intialized. and then MB firmware automatically programs the LMK04832 registers, and then PLL1 and PLL2 are locked. ->
With the PLL locked, I rewrite the LMK04832 with same values, and then PLL is unlocked.

test 2
Board's Power is ON ->
FPGA is configured ->
Microblaze(MB) CPU is intialized. and then MB firmware does not program the LMK04832 registers(because I blocked the SPI writing process). Then, of course, PLL1 and PLL2 are unlocked. ->
I write the LMK04832 registers, and then PLL is unlocked.

I thought that LMK04832 would be locked when programmed for the first time and unlocked when reprogrammed.
In test 2, when LMK04832 was programmed once, it was not locked.
That's why "The strange thing is that initial writing of the registers of LMK04832 is not performed when booting, and even if all registers are written after booting, the PLL is not locked."

The solution isn't complete yet, but I'm very grateful for your help in resolving this strange case.

Regards,
BK

Hello, 

Will is out of office today, but he should be able to get back to this on Monday. Thanks for your patience here. 

Regards, 

Connor 

Hello BK,

Could you please attach your schematic? Are you using CLKin0, 1, or 2? And you did not change anything between the rewrites correct? You are still providing your input frequency to the same input? It doesn't seem you did from the explanation above but want to double check.

Best,

Andrea