Hi! This is technically a continuation of this issue below:
https://ez.analog.com/clock_and_timing/f/q-a/540382/ad9514-low-frequency-de-sync
In summary, we are attempting to run an AD9102 at a low frequency setting. The clock driver that we were using to facilitate this has a rise time of approx. 100 nS. We could not identify any rise/fall time requirements on the datasheet for the AD9102 (the only thing we found was the Maximum clock speed of 180 Msps.) Initially we were having difficulties with the AD9514 on the dev board, an issue we now know is due to the AD9514 requiring a 1V/nS slew rate, which we don't have. Because of this, we decided to bypass the AD9514, thinking that the AD9102 wouldn't have these issues.
Unfortunately, that doesn't appear to be the case. When we use our clock driver and program the AD9102, we do initially see the programmed signal, but shortly after we begin to see "glitches" of the signal appearing scrambled or having some values apparently overridden. Sometimes these glitches are persistent, and are seemingly "attached" to the pattern being generated. Finally, after some seeming arbitrary amount of time, the signal becomes completely random (as if it is reading a pattern from randomly initialized spots in RAM) and then remains constant at the highest possible value indefinitely, even when the trigger is no longer driven low.
When we use a lab-bench function generator to generate the input clock, we don't see any of this, and the output appears as expected. Further, when we increased the rise time on the function generator (we just used a capacitor) the improper behavior reappeared. Therefore, it seems like there is a rise time requirement for the AD9102 that we didn't see in the datasheet.
We're currently working on improving the clock driver we're using to have a faster rise time to prevent this issue, but it has raised a few questions we would like help in answering:
* What exactly is the maximum rise time/ slew rate that can be handled by the AD9102?
* Why does this behavior occur as a result? (My hypothesis is that the slow rise time messes with the internal SRAM pointer, randomly incrementing the pointer and thus skipping values. Eventually this happens at the end of the pattern, and thus skipping the stop address. Once that happens, the check for whether the stop address has been reached will never occur, and thus the pointer begins reading the random values determined at initialization, and eventually gets confused at the end of the memory bank. However, I'm not sure how to verify this, as the SPI interface does not have access to the current internal SRAM pointer.)
*Due to the fact that this failure results in the device being stuck in the high state, this represents a possible safety concern. I know there might not be an answer to this, given that this is technically undefined behavior, but would there be any method of adjusting that, or at least detecting that something has gone wrong? (We can just use an external monitor to detect the problem and reset the chip if that occurs, but a software-only solution would be preferred.)
Thank you very much for your help!