Part Number: LMX2694-EP
Hi,
We are using LMX2694 to create a 9280 MHz clock from a 300 MHz osc in. We notice that the LMX2694 reports it's "locked" per R110 (readback = 0x0448). However, we notice on triggering the calibration that its output starts at 9280 MHz and drifts over the course of 20 seconds or so to 9200 MHz. Also, when we probe VTUNE, either with an oscilloscope or a DMM, the output frequency of the LMX2694 jumps up to ~9400 MHz. The DC value of V tune is about 365 mV.
I just noticed, in the hex file you provided, there are several hex data which are visibly not matching the address values next to them. Can you check if the sequence that you're writing on your system is actually diverting register writes from R13/R12 and R6/5/4/3/2 to R0?
The new version of TICS Pro should prevent this kind of tcs/hex file corruption, including when reading from older, corrupted files. It also documents when you are reading in from a corrupted file, by highlighting mismatched addresses encoded in the data. As an example, I deliberately set the value of R3, R2, and R1 to 0 in a TCS file, and tried loading the file on the latest TICS Pro (1.7.10.1):
Likewise, when importing the original hex file you provided, it documents that the addresses have been corrupted:
If the actual register data is corrupt (instead of just the appended address), the tool can't protect against that - register data is arbitrary and user-specified. But without the address corruption issue you encountered, it's unlikely that data corruption would occur, because the source of data corruption is usually address corruption causing writes and reads to be misdirected to corrupted addresses. So I think that the latest TICS Pro mostly circumvents this issue, yes, with the caveat that already-broken saved configs or hex files are going to stay broken.
