LMX2571: Sometimes the LMX2571 won't lock

BRUNEAUX Jerome

Part Number: LMX2571

Hi,

We are experiencing a problem with the LMX2571 on our boards. Sometimes, after a few hundreds of 'slots' (we are using the LMX2571 in a TDMA Rf product), the LMX2571 do not lock, resulting in a missing burst (and a Power Amplifier without its input Rf, which is not good).

Here is a brief description of the LMX2571 usage :

* The LMX2571 is always used with the same startup sequence and programmed register values (in our system, everything including SPI are clocked using a precise clock and the programming is done using DMAs, so the programming sequence is perfectly the same over all the bursts)

* The LMX2571 is powered down beween TX burst

* The OSCin is conencted to a 26MHz TCXO which is not powered down between TX bursts).

* This happen at different frequencies (i.e different VCO values, N values, ...)

* At the moment we only see it happen after around one hour of usage

* External loop filter values : same as datasheet values)

Here are the observations I made :

* The 26MHZ input clock is stable even when the problem arise (checked with a spectrum analyzer set in 0-span mode)

* when the problem arrise, the VCO seems not to be started (using the spectrum analyzer in 0-span mode and a 'loop' probe, I'm able to monitor the VCO of the LMX, the spectrum analyser is triggered with some negative delay on an external signal (in my case the TX command, so that every burst triggers a capture on the spectrum analyzer). On the slot where the LMX2571 do not lock, there's no visible power at the VCO frequency (using an other spectrum analyser, it seems that the VCO is not event close to its target frequency, I can't see it in the few MHz around it 'normal' frequency).

* The Lock detect output of the LMX2571 stays at 'low' level.

* I've implemented a read back of the register after each programmation sequence to ensure that all is OK and everything is OK (comparison between what has been written and what has been read back).

* Power lines are good at the moment of the problem (scope triggered on the same source as spectrum analyser, with some negative delay)

I've attached a trace of the SPI programmation (captured using a DSLogic analyzer, their software is free to download. I couldn't add the download link so google 'dslogic dsview' and you will be able to visit the dreamsourcelab website for download).

That way, you can see the programmation sequence as well as other signals of the board. The problem can be seen right before the probe '8' goes high (hardware protection of our product).

Here is the programming sequence to achieve a 36MHz output :

* R0 : 0x2001 (I've made some changes to the software to remove the FCAL_EN bit at this moment, but this do not change the problem. Will keep this modification anyway)

* Wait for 130us (12 samples @ 96Khz)

* R60 : 0xA000

* R58 : 0x8c00

* R53: 0x7806

* R47: 0x2000

* R41: 0x0010

* R40: 0x101c

* R39: 0x11fb

* R35: 0x1047

* R34: 0x0003

* R08: 0x0403

* R07: 0x0084

* R06: 0x9484

* R05: 0x0101

* R04: 0x2016

* R03: 0xffff

* R02: 0x627f

* R01: 0xff27

* R00: 0x0003

* R33: 0x0000

Please, let me know what could be the problem or som advice to find where does this come from ? If you need any further details of our application, please ask.

Regards, Jerome

DSLogic-TX_Fail_WithReadBack.dsl.tar.gz

over 5 years ago

0 BRUNEAUX Jerome over 5 years ago

Prodigy 150 points

Update:

* I've seen that the first R0 was not correct (missin bit 1 set to 1. I've fixed that and this doesn't change the result.

* Other test I've done : I don't power down the PLL between burst but simply disable its output (all the remaining sequence is the same, I mean, I steal send the R0 with reset bit, wait for 130uS then program the registers). I can see on the spectrum analyser that the VCO is only stopped from the time I've sent the spi with reset bit set in R0, until a few uS after the programmation is done. When doing this, there's no lock problems. The only difference is that the VCO stays off less longer because the power-down command (R0 programming with power-down bit set) is replaced with a R7 programming (which was already done in the normal sequence, as a quick test, it is now sent twice).

Regards,

0 Noel Fung over 5 years ago in reply to BRUNEAUX Jerome

TI__Guru** 106740 points

Hi There,

Let's use my language to describe your operation.

1. Vcc power up the part

2. have a stable 26MHz reference clock ready

3. write R0 with RESET=1

4. Program all registers in reverse order from R60 to R0 (with FCAL_EN=1)

5. (LMX2571 locks to the desired frequency)

6. Powerdown the part by writing POWERDOWN=1

7. Resume power up by writing POWERDOWN=0 (assume R0=0x00wxyz)

8. Re-calibration by writing R0 one more time (R0=0x00wxyz) (This step is required as per datasheet section 7.3.11)

9. Repeat step 6 to 8 in TMDA operation.

Did you see problem with the above sequence?

0 BRUNEAUX Jerome over 5 years ago in reply to Noel Fung

Prodigy 150 points

Hi,

That's our sequence, except that due to software architecture, we repeat steps from step 3 to 6 (instead of steps 6 to 8 in your sequence). Power-up is done using POWERDOWN=0 and RESET=1 in R0. There's also a 130uS pause between step 3 and 4 (as per datasheet requirement, upon exit from power down, it is adviced to wait for 100uS).

For you information, it appears that we were able to reproduce the problem on the dev kit (the collegue which has led this experiment should provide a detailled report of its experiment on the dev kit. As soon as I have it, I will let you know its conclusion). The problem on our board appear after a few thousands bursts (at the moment, I mostly see the problem around 1h15 after the test has started, with a burst configuration of 50ms on time, 60ms off time, that's about 41000 power-on/off sequences).

Regards,

Clock & timing

Clock & timing forum

LMX2571: Sometimes the LMX2571 won't lock