the AD9648 that we use in our design randomly fail to power-up correctly. This seems to depend on order of power up of analog and digital voltages vs. powering up the VCXO that feeds the AD9648's clock. Unfortunately the data sheet does not document any of these issues, so that we are unsure whether the power-up sequence we found by trial-and-error will reliably work with future batches of the AD9648.
It seems that others have encountered similar issues before and asked in this forum, however no solution is documented:
ad9648 can't start work
More details follow:
Symptoms that I describe as "fail to power-up":
- the AD9648 does not react to SPI commands telling it to enable the clock output
- Sending a digital reset (0x00 0x08 0x03 / 0x00 0x08 0x00) does not have any noticeable effect
- During normal power-up, approximately 2ms after power-up, the clock input will be visible on the clock output (probably kind of IC-internal cross-talk, as we didn't explicitely enable clock-out). In the failed state, the clock output does a few transitinos 2 ms after power-up, but then stays constantly high.
For now we mitigated the issue by disabling the VCXO that feeds the AD9648's clock input while the AD9648 is powered up. Waiting for some 5 ms after power-up before enabling the VCXO seems to fix these issues (or maybe they just happen so seldom now, that we didn't see them yet).
This is how failed power-up looks like on a scope:
(C2 is SPI CS which exactly corresponds to VCC enable, C1 is SPI data, C4 is clock output)
Second SPI data transfer enables clock output but does not have any effect. Note the transitions on C4 about 2 ms after power-up. Are we seeing some artifacts of the internal reset state-machine?
Doing the exact same power-up sequence, usually power-up looks like that:
Note how the second SPI data transfer enables clock output in LVDS mode, as reflected by change of C4. The signal on C4 before enabling the clock input is something bogus that doesn't even match the applied input clock. Maybe caused by intra-IC crosstalk. Clock output does not see much load.
After a lot of trial and error we changed the power-up sequence to delay the power-up of the VCXO that drives the AD9648's clock input (we use a 1.8V CMOS single ended clock to clock the AD9648):
This hows digital (1DV8) vs. supply analog voltage (1V8A) vs. supply voltage of the VCXO (3V0XO) driving the AD9648 and the AD9648 clock output (clk out).
We suspect that this may actually work reliably. However lacking any official information from Analog about requirements of the power-up sequence, we don't feel completely sure that this is always going to work, even with different batches of the AD9648.
So what we would like to get from Analog is:
* confirmation that the AD9648 getting unrecoverably stuck at power-up is something that is "normal" and you are aware of (i.e. there is nothing specially broken about the batch of AD9648 that we are using).
* information about whether the modified power-up sequence that we found by trial-and-error is actually "guaranteed" to work reliably for all AD9648 parts under all normal operation conditions.
thanks in advance,
This dialog is being continued by email.
Hi Dougl,I have the same problem. can you help me?thanks in advance,
I'm sorry you are having this issue.
I recommend that you bring up DRVDD after AVDD is powered and the sample clock is stable. In other words, bring up DRVDD last. Is this something you can try?
thanx for your reply,
my sequence is AVDD -> DRVDD -> Clock Stable.
Do you mean we separately enable the DRVDD regulator, and turn it on with clock stability flag.witch sequence is true? i can try in next PCB version.
AVDD -> Clock Stable -> DRVDD .
Clock Stable -> AVDD -> DRVDD .
The main thing is that DRVDD is powered up AFTER the other events.
How often do you see the problem? By any chance are you driving the clock single ended?
Almost every five times I turn on, It happens once.
i drive clock as differential with AD9522. after fpga loaded from flash i config AD9522, and set clock to 60MHz.
if we enable the DRVDD regulator with AD9522 lock flag, and then assert digital reset, do you think the problem will be solved?
Your suggestion is certainly worth a try. If DRVDD comes up after everything is stabilized I believe it will work.
The other thing that helps is reduce the size of your clock AC coupling capacitors. For example, if you are using 0.1uF AC coupling capacitors, as an experiment try 0.001uF and see if that helps.