Post Go back to editing

Restrictions on jumps between different frequencies using manually programmed VCO calibrations settings

Thread Summary

The user is experiencing occasional lock failures with the ADF4368 synthesizer when using manually programmed VCO calibration to jump between frequencies, particularly from 6.0 GHz to 12.2 GHz. The issue can be resolved by toggling the PD_ALL bit or the MUTE_NCLK bit, but this adds an extra 120 us of delay. The support engineer suggests optimizing the register write sequence and confirms that the lock loss is related to a meta-stability issue in the N counter. The user will test these suggestions and verify if they can reduce the delay.
AI Generated Content
Category: Hardware
Product Number: ADF4368

We are using the manually programmed VCO calibration to jump quickly between various frequencies (about 10 or so frequencies spanning the full range of VCO cores).  We dwell on each frequency for about 10ms.

We have found that occasionally the ADF4368 will not lock when a new frequency setting is applied.  It is a bit unpredictable when this will occur.  When it does occur, subsequent frequency changes using the manually programmed VCO calibration will continue to fail. Something appears to be locked up.  To clear the lock up, we have to either program a new frequency with automatic VCO calibration enabled or cause a brief power down of the IC by asserting the PD_ALL bit and then de-asserting it.

As a workaround, we are now always doing a brief power down of the IC after the last step of a frequency change using  manually programmed VCO calibration (the last step being to write register 0x10).  But this then causes about another 150us of delay to the frequency change.  While, this is still much faster than using the automatic VCO calibration, but we'd like to avoid this additional delay.

  • Are there some restrictions regarding jumps between frequencies using the manually programmed VCO calibration procedure?  (i.e. is it okay to jump from a frequency using a different VCO core?). 
  • Is there any other way (faster) to clear a lockup without the use of the PD_ALL bit?

Thread Notes

  • I will investigate this. Are you able to reliably reproduce the issue or is it always apparently intermittent?

  • Thank you for replying.

    Yes, its is repeatable, but random as to how long it takes to occur.  We generally switch between more frequencies, but for the simplest case were a just switching between two frequencies. The dwell time at each frequency for this simplest case is 1 msec.  So there are 1000 frequency changes per second. The failure time varies and can be as little as under a minute.  But it can also go for more than 10 minutes before occurring.

    In our system, the reference clock is 100MHz.  We are enabling the doubler, so it will be at 200MHz.

    For this test case, the 2 output frequencies used are:

    • 6.0 GHz    (VCO core = 3, VCO Band = 135, VCO Bias =   8)
    • 12.2 GHz  (VCO core = 3, VCO Band = 112, VCO Bias =   9)

    The VCO parameters were determined using a normal autocalibration programming sequence and then capturing the values from the read only registers at 0x5A, 0x5E and 0x60.

    Since 6.0 GHz is below 6.4 GHz, it is also using the fastest VCO core at 12.0 GHz with a divide by 2 at the output.  We can see the actual settings are pretty close to each other.

    The failure always seems to be the transition from 6.0GHz to 12.2 GHz. I can supply the entire memory map for both settings if it helps.  After the failure, I have verified that all the registers have been written as expected with a complete readback.  I can also verify that by briefly asserting and de-asserting the PD_ALL bit, the synthesizer will then lock to the desired frequency successfully (with no other registers altered).

    One note is that even though these frequencies are suitable for integer mode, we are leaving the INT_MODE bit in register 0x11 set at 0 (fractional mode).  We have found that mixing between integer mode and fractional mode causes issues when using manually programmed VCO calibration settings.  Specifically, once we program a fractional mode frequency, we cannot subsequently program an integer mode frequency.  So we have left everything in fractional mode. However, this is not an issue when we enable auto-calibration.

  • I've been reading up on this. As far as I can tell there are no restrictions to moving between the four VCO bands as long as you have the data stored that was collected in the original Auto-Cal. I have a few thoughts and suggestions.

    1. Do you leave the INT_MODE bit always set to 0 even during the Autocal routine?

    2. After a failure, are you able to read back the registers and verify that the correct data was written? I guess that I'm wondering if the problem might be cause by a bit write error during a SPI write.

    3. As you are testing the system and waiting for it to fail, does the temperature change much? One easy test you might want to try would be to stick or lay a heat sink (or just a piece of metal) on top of the chip and see if the frequency of the failures changes. 

    4. There is an application note, AN-2005  that  was written about this topic. It focuses on ADF4371 and ADF4372 but the approach is the same. I had a look though the ap-note and did not come across any smoking gun. But it you have not read, it, it might be worth a look through. 

    Eamon

  • Answering you questions below:

    1. Do you leave the INT_MODE bit always set to 0 even during the Autocal routine?

    Yes, we always leave the INT_MODE bit set to 0.

    2. After a failure, are you able to read back the registers and verify that the correct data was written? I guess that I'm wondering if the problem might be cause by a bit write error during a SPI write.

    Yes. We have verified that after a failure, all of the SPI registers are read back as what was expected to be written.  Also, to clear the lockup, we only toggle the PD_ALL bit in register 0x2B.  We do not write any other register and the synthesizer will then end up at the correct frequency.  I would not expect that to be the case there was a SPI write error.  We have also checked on the timing of the bus and it meets the datasheet requirements.

    3. As you are testing the system and waiting for it to fail, does the temperature change much? One easy test you might want to try would be to stick or lay a heat sink (or just a piece of metal) on top of the chip and see if the frequency of the failures changes. 

    The temperature is relatively steady.  The system has a fan blowing air constantly over our PCB and reading back the internal temp sensor shows it to be only vary by about 3-4 C over time.

    That being said, I did use some cold spray to try to rapidly cool the IC.  When I do this, I can force a failure almost immediately.  So, this does seem to imply some sort of thermal dependency.  (NOTE: If I put back the code to always toggle the PD_ALL bit after a frequency update, the cold spray will not cause the failure).

    How valid are the manual VCO parameters over temperature with respect to both steady state and being able to lock on initially?  Based on this, it does seem that those settings may not allow the internal PLL to lock under all temperature conditions.  I assume that the auto-calibration must do some sort of a sweep over the various VCO parameters and can always find a valid setting.  Is there possibly some sore of "safe" VCO parameter settings we can use as an intermediate step before changing to our final settings?

    4. There is an application note, AN-2005  that  was written about this topic. It focuses on ADF4371 and ADF4372 but the approach is the same. I had a look though the ap-note and did not come across any smoking gun. But it you have not read, it, it might be worth a look through. 

    We will have a look to see if there is any additional information there.

  • I need to take this issue to some colleagues with more expertise on this product. One background question I'm sure that they are going is whether you are using the ADF4368 eval board or if the part is already on your own board. Thanks - Eamon

  • We have developed our own PCB and all these results are from that.  Up to this point, we have pretty much exclusively used auto-calibration and have never had any issues. We did some initial experiments about a year ago to verify that manual calibration did work.  But we hadn't developed our software to use the manual calibration to do rapid frequency hops.  We are now in the process of doing so and are observing the issues.

    We do have access to the ADF4368 evaluation board and can conduct experiments with it if you have suggestions.  But we can't run our software on the evaluation board.  

    We did some further experiments and can verify that in the failed state, the input signal to the VTUNE pin is railed (~4.5V).  When it is working properly, it centers at 2.26V. Our loop filter is similar to the default one on the evaluation board - but the loop bandwidth is slightly reduced from about 500k to 370k.  Could this tighter filter reduce the pull-in range enough to sometimes prevent manual VCO settings from achieving lock?

  • Thanks for that additional information. I've reached out to some colleagues with more expertise in the part and am waiting to hear back from them. The team is in Ireland so they are off on Friday and Monday for Easter. So it's going to be next week before we hear back. One other comment, just in case you missed it (I doubt that you did) is that the register programming order detailed in Table 18, must be followed.  - Eamon

  • I got this feedback from my colleagues.

    For ADF4368, all of the steps required for manual VCO programming should be contained in the datasheet on page 24 'Fast Power-Up and Initialization, Manually Programmed VCO Calibration Settings'. I've been cross referencing them with the ADF4382 datasheet (which is exactly the same procedure for programming this mode). One difference I found is that the O_VCO_DB bit field (Reg 0x39) isn't listed in the steps in the ADF4368.

    Another bit field that is not shown in the (ADF4368) datasheet is the MUTE_NCLK (Reg 0x30). It was discovered that unlock is seen occasionally when going between Int and frac frequencies and vice-versa. But since you are  staying in frac mode,  this shouldn't be needed. Still, I think it's worth trying, to see if it fixes the issue. 

    The step would be: 

    Toggle Mute_NCLK bit (register 0x0030[7]) after writing register 0x0010:

      - Write address `0x0030 = 0x80`

      - Then write address `0x0030 = 0x00`

    If you can you  provide your  reg map contents and the register you write for each frequency change, we can investigate in the lab. If you are able to make the problem happen by continually switching between two frequencies, providing the settings for those two frequencies would be easiest. I think that you mentioned below that you can reproduce the problem by just switching between 6.0 and 12.2 GHz. 

    Thanks

    Eamon

  • We tried out the technique you described and it behaves pretty much identically as toggling the PD_ALL bit that we are already doing.  Both ensure that the synthesizer will lock when using manually programmed VCO calibration settings and both add about 150 us of extra settling time.

    It's good to have a second work around, but is there any additional information on why this was seen?  It is a recommended step when using manually programmed VCO calibration settings in general?

    I have lost access to my test board for a couple of days. But when I get it back, I will extract the register settings between 2 frequencies when it fails and post them here.  I will also see if either of these methods will allow us to mix between integer and fractional mode settings. That may have some benefits in some applications for us.

    Thanks for the assistance.

  • We received our board back and captured the synthesizer settings between the 2 frequencies.  I've attached the captured files.  The input reference frequency is 100MHz.  Please let us know if there is anything you find.

    0x0000 0x3c
    0x0001 0x00
    0x0002 0x00
    0x0003 0x06
    0x0004 0x07
    0x0005 0x00
    0x0006 0x00
    0x0007 0x00
    0x0008 0x00
    0x0009 0x00
    0x000a 0x00
    0x000b 0x01
    0x000c 0x56
    0x000d 0x04
    0x000e 0x00
    0x000f 0x00
    0x0010 0x1e
    0x0011 0x40
    0x0012 0x00
    0x0013 0x00
    0x0014 0x00
    0x0015 0xe2
    0x0016 0x87
    0x0017 0x00
    0x0018 0x00
    0x0019 0x00
    0x001a 0xff
    0x001b 0xff
    0x001c 0x01
    0x001d 0x2d
    0x001e 0xe8
    0x001f 0x1e
    0x0020 0x41
    0x0021 0x09
    0x0022 0x00
    0x0023 0xf0
    0x0024 0x38
    0x0025 0x80
    0x0026 0x84
    0x0027 0x1e
    0x0028 0x20
    0x0029 0x99
    0x002a 0x00
    0x002b 0x00
    0x002c 0xab
    0x002d 0x31
    0x002e 0x00
    0x002f 0x07
    0x0030 0x1b
    0x0031 0x61
    0x0032 0xd3
    0x0033 0x32
    0x0034 0x98
    0x0035 0x04
    0x0036 0xd6
    0x0037 0x1a
    0x0038 0x06
    0x0039 0xa9
    0x003a 0x43
    0x003b 0x8a
    0x003c 0x00
    0x003d 0xc0
    0x003e 0x22
    0x003f 0x83
    0x0040 0x00
    0x0041 0x00
    0x0042 0x09
    0x0043 0x09
    0x0044 0x18
    0x0045 0x08
    0x0046 0x00
    0x0047 0x00
    0x0048 0x00
    0x0049 0xff
    0x004a 0x00
    0x004b 0x5d
    0x004c 0x2b
    0x004d 0x00
    0x004e 0x1e
    0x004f 0x00
    0x0050 0x00
    0x0051 0x00
    0x0052 0x00
    0x0053 0x25
    0x0054 0x00
    0x0055 0xd4
    0x0056 0x77
    0x0057 0x1c
    0x0058 0x69
    0x0059 0xff
    0x005a 0x03
    0x005b 0x44
    0x005c 0x00
    0x005d 0x93
    0x005e 0x87
    0x005f 0x43
    0x0060 0x08
    0x0061 0x09
    0x0062 0x00
    0x0063 0x03
    
    0x0000 0x3c
    0x0001 0x00
    0x0002 0x00
    0x0003 0x06
    0x0004 0x07
    0x0005 0x00
    0x0006 0x00
    0x0007 0x00
    0x0008 0x00
    0x0009 0x00
    0x000a 0x00
    0x000b 0x01
    0x000c 0x56
    0x000d 0x04
    0x000e 0x00
    0x000f 0x00
    0x0010 0x3d
    0x0011 0x00
    0x0012 0x00
    0x0013 0x00
    0x0014 0x00
    0x0015 0xe6
    0x0016 0x70
    0x0017 0x00
    0x0018 0x00
    0x0019 0x00
    0x001a 0xff
    0x001b 0xff
    0x001c 0x01
    0x001d 0x2d
    0x001e 0xe8
    0x001f 0x1e
    0x0020 0x41
    0x0021 0x09
    0x0022 0x00
    0x0023 0xf0
    0x0024 0x38
    0x0025 0x80
    0x0026 0x84
    0x0027 0x1e
    0x0028 0x20
    0x0029 0x99
    0x002a 0x00
    0x002b 0x00
    0x002c 0xab
    0x002d 0x31
    0x002e 0x00
    0x002f 0x07
    0x0030 0x1b
    0x0031 0x61
    0x0032 0xd3
    0x0033 0x32
    0x0034 0x98
    0x0035 0x04
    0x0036 0xd6
    0x0037 0x1a
    0x0038 0x06
    0x0039 0xa9
    0x003a 0x43
    0x003b 0x8a
    0x003c 0x00
    0x003d 0xc0
    0x003e 0x22
    0x003f 0x83
    0x0040 0x00
    0x0041 0x00
    0x0042 0x09
    0x0043 0x09
    0x0044 0x18
    0x0045 0x08
    0x0046 0x00
    0x0047 0x00
    0x0048 0x00
    0x0049 0xff
    0x004a 0x00
    0x004b 0x5d
    0x004c 0x2b
    0x004d 0x00
    0x004e 0x1e
    0x004f 0x00
    0x0050 0x00
    0x0051 0x00
    0x0052 0x00
    0x0053 0x25
    0x0054 0x00
    0x0055 0xd4
    0x0056 0x77
    0x0057 0x1c
    0x0058 0x69
    0x0059 0xff
    0x005a 0x03
    0x005b 0x44
    0x005c 0x00
    0x005d 0x93
    0x005e 0x70
    0x005f 0x43
    0x0060 0x09
    0x0061 0x09
    0x0062 0x00
    0x0063 0x03