Post Go back to editing

Some questions about the AD9545

Hello, engineer, I am working on a project, hoping to generate any frequency through AD9545. I completed the following test corresponding to the CSO file on my PCB board. In the test, I wrote the register bits in the CSO file into AD9545 through STM32 single chip microcomputer, but the system clock could not be locked.DPLL0 also has no normal feedback, but DPLL1 can lock frequency and phase. My system input OCXO signal of 20Mhz, REF A is 1PPS, REFB is 26M, this problem has bothered me for several days, I hope to get your help!

Best wishes for you

  • Hi,

    it is not a good idea to have the 20MHz OCXO clock the system clock PLL. The reason is that the OCXO usually has a duty cycle somewhere between 45% and 55% (look into its data sheet) and this makes the AD9545 outputs to have worse phase noise than normally. I recommend using the 52MHz crystal resonator to clock the system clock PLL and then supply the OCXO at one of the unused reference inputs and use the auxiliary DPLL to lock onto it and stabilize the system clock at the DPLLs and TDCs.

     Then you say the system clock could not be locked. If this is true, then I do not see it possible for the DPLL1 to reach fully lock status. 

    Here are my additional comments regarding the cso file you sent:

    - make sure REFA=1Hz and REFB=26MHz are always valid. Set  one or two Mx pins to output the REFAMON_VALID and REFBMON_VALID and observe them with the oscilloscope. They should stay continuously high. 

    - then put on Mx pins DPLL0_ACTIVE and DPLL1_ACTIVE. When they go high, it means the AD9545 considers the corresponding reference as valid and they started to work

    - the system clock compensation is not set correctly. It does not make sense to set the auxiliary DPLL to lock onto a 1Hz clock with 50 Hz bandwidth. It also does not make sense to compensate DPLL0 based on REFA when REFA is the reference of DPLL0. See above my recommendation.

    - you set up AuxTDC0 for 26KHz, but you did not set any Mx pin to receive it. You have to set a Mx pin to receive AuxTDC0 first, click Apply All, then go into the Auxiliary TDC menu and introduce the frequency. Note the 26kHz  clock must be CMOS, with the voltage related to the voltage on VDDIOA or VDDIOB pin.

    Please tell me how you want to go about the OCXO and then I can create an AD9545 configuration for you.


  • Hi! Petre, I am honored to receive your prompt response!
    Sorry, as a beginner of AD9545, I have made a lot of mistakes. My demand is very simple. I want to make a frequency generator that can output multi-channel arbitrary frequency through STM32 and AD9545.For example, I want to be able to input 1PPS signal and 26MHz OCXO signal in REFA and REFB respectively, and then output 5 channels of arbitrary signals of different frequencies. For the system clock frequency, I can use 20MHz square wave OCXO or 16.384mhz SMD crystal to provide, can you give me some suggestions?thank you!

  • HI,

    I already told you to use a 52 MHz crystal resonator as the system clock source. 16.384MHz is too low. See this from the data sheet:

    Yes, you can use the AD9545 to generate "arbitrary" frequencies, but please note that the clock outputs per channel must meet the following condition: the APLL0 VCO divided by 2 must be an integer  multiple of the minimum common multiple of the OUT0A, OUT0B and OUT0C output frequencies. Same condition for the APLL1 VCO that deals with OUT1A and OUT1B.

    The Wizard will give you an error if you do not meet this condition.

    In the configuration you sent, I left the system clock being created from a 20 MHz oscillator (I'll let you change it when you procure the 52MHz crystal resonator), but I changed the system clock compensation scheme: REFB=26MHz OCXO can be used as reference to the auxiliary DPLL to stabilize DPLL0 and TDCs (REFB is used as reference to the DPLL1, so it does not make sense to use the Auxiliary DPLL to compensate DPLL1). I also disabled the DPLL0 to compensate DPLL1 because it is not very probable that the REFB OCXO goes down. More probable is that the REFA=1Hz will do down and then the DPLL0 enters holdover and the outputs are as stable as the REFB OCXO.


    Attached is the new cso file. Please take out the txt extension after you download it


  • Hi! Petre.Thank you very much for your patient answer. I will give you feedback after learning and experimenting!

  • Hello,  Petre. There are several questions which I do not understand. The first question is, after I send the relevant register data to AD9545 using the STM32, do I need to configure the IO_UPDATE register?Another, when should data be written to the calibration register 0x2000?Is it automatically configured?

  • HI,

    please see the Initialization sequence section at page 164 in the rev C AD9545 data sheet. You should follow it. It shows that after you write the registers into the chip, you need to execute an IO Update  (write 0x01 into register 0x000F) and then you need to calibrate the system clock PLL and the two APLLs following the procedures outlined in the section.


  • Hello,Petre, I am now facing a new problem that I need to consult you.1. My system clock still adopts OCXO 20M, external access reference signal REFA 1PPS,REFB 10MHz. The current state is that DPLL1 can be locked, DPLL0 can achieve frequency locking but not phase locking.The AuxDPLL fault bit is 1, I am sure I have updated the IO status, what is the cause of this?2.Another problem is that although DPLL1 can be locked and OUT1A can output a stable 50M signal, after a period of time, DPLL1 will lose its lock and OUT1 frequency will have no output,I noticed that my Temperature_Alarm return is always 1. Is the chip overheating?I'm not doing any heat dissipation at the moment.Attached is my CSO file.

    Best wishes for you!

  • Hi,

    if you create the system clock with a OCXO, there is no need to use the AuxDPLL to stabilize it. The REFB=10MHz clock you use as the reference for the system clock should be more stable than the OCXO for this approach to make sense. Just disable the AuxDPLL compensations and then the DPLL0 and DPLL1 should function undisturbed and they should lock and remain locked because the system clock is as stable as the OCXO.

    I do not have a clear explanation on why DPLL1 lost lock.  You say OUT1 clocks stopped generating outputs. This should never happen. Even if REFB, the DPLL1 reference, becomes invalid, the DPLL1 should enter holdover and the outputs should still be generated. I recommend making yourself a function in the controller that reads all the status registers, so you can then take a look at their bit content and understand what the chip is doing when similar situations occur.

    I do not have a clear explanation for the fact the DPLL0 locks in frequency but never in phase, either. The system clock should be stable and the DPLL0 should gradually lock onto REFA=1Hz. Maybe the DPLL0 was affected by the AuxDPLL system clock compensation. It is very weird the AuxDPLL had not locked onto REFB. I am skeptical this had happened because you said the DPLL1 locked, so REFB was valid. Not clear what AuxDPLL fault bit you are referring to.

    BY default, the temperature sensors alarms are 0, so it is normal that the chip indicates a non zero degrees Celsius temperature. You can program the temperature thresholds to your desired values.


  • Hi,Petre,very thanks for your patient answer, I think I am not far from success, the AuxDPLL fault I said means that the second bit of 0x3002 is always 1, I seem to know the reason, because I REFB serves as the input of DPLL1 and AuxDPLL at the same time, am I correct in my understanding?How do I close AuxDPLL?Leave him in default mode?I tried, and the second bit of register 0x3002 was always 1, and DPLL0 was out of lock.Also, the jitter of my 1PPS signal was about 30ns, I don't know if it matters, the AD9545 feedback says REFA(1PPS) is always valid;

  • Hi,

    if by "second bit" of register 0x3002 you mean bit 2, this means the AuxDPLL reference, that is REFB is not valid. If you instead mean bit 1, AuxDPLL is not locked. It is very strange that AuxDPLL does not lock onto a valid reference. Maybe the system clock is not stable enough.

    I recommend reducing the configuration of the AD9545 to some basic functionality, with DPLLs functioning in free run and monitoring the system clock bit 1 and bit 0 in register 0x3001. Or, better yet, put one of the Mx pins to output one of these bits and so you can monitor them on a oscilloscope. Forget about AuxDPLL because the system clock is created by a OCXO, so it should be already stable.

    After you assure yourself the system clock is continuously locked:

    Then you can apply REFB and see if DPLL1 locks and remains as such. Monitor is lock status on an Mx pin with the scope.

    Then you apply REFA=1Hz and monitor DPLL0 status flags at one of the Mx pins with the oscilloscope.

    30 ns jitter on 1Hz mean 30 ppb of 1s. The REFA=1Hz monitor has an offset tolerance of 1E5 ppb. So the reference monitor should deem REFA as valid without any problem.