• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 21 subscribers
  • Views 769 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LMX2594: Inconsistent readback values from Registers R3, R2, R1, R0

Ted Wolfe
Intellectual 260 points
Part Number: LMX2594


Hello,

We're trying to use the LMX2594 on a COTS board, and are configuring it using the SPI interface from the host Xilinx RFSoC device on the board.  But we're having a hard determining if registers are configured correctly because we get bad/inconsistent readback results on particular registers. We follow the recommended procedure of datasheet Sect. 7.5.1:

1) Power up, 2) Set Reset in R0 (0x002012), 3) Clear Reset in R0 (0x002010), 4) Program registers in reverse order R78-R0 (since not using Ramping)

As we program the registers, we read back each written value to verify.  This works perfectly for R78-R4, the readback values match the written data.  But for registers R3-R0, we get the following:

R3: WR: 0x0642
       RD: 0x0000
R2: WR: 0x0500
       RD: 0x0000
R1: WR: 0x0808
       RD: 0x0808
R0: WR: 0x2010
       RD: 0x0000

Any idea why we would get all-zero readback data from R3, R2, R0?  It doesn't seem like we have a SPI bus issue since the 1st 75 register writes/readbacks worked perfectly.  Not knowing what to try, we then did another write of R0 with 0x2010 to make sure 'MUXOUT_LD_SEL' cleared to 0 for readback, and re-read all registers R78-R0.  This time we got multiple registers with readback values that did not match the programmed data (or the previous readback):

Reg 78: 0x0064 (written value was 0x016F)
Reg 75: 0x0800 (written value was 0x0880)
Reg 71: 0x0080 (written value was 0x0081)
Reg 62: 0x00af  (written value was 0x0322)
Reg 60: 0x03e8 (written value was 0x0000)
Reg 58: 0x8001 (written value was 0x9001)
Reg 57: 0x0000 (written value was 0x0020)
Reg 46: 0x07fd  (written value was 0x07FC)
Reg 45: 0xcedf  (written value was 0xC0DF)
Reg 44: 0x1fa2  (written value was 0x1fa4)
Reg 43: 0x0000 (written value was 0x0009)
Reg 39: 0xffff     (written value was 0x0019)
Reg 38: 0xffff     (written value was 0x0000)
Reg 37: 0x0204 (written value was 0x0504)
Reg 36: 0x0032 (written value was 0x0057)
Reg 31: 0x43e8 (written value was 0x43EC)
Reg 30: 0x2108 (written value was 0x318C)
Reg 29: 0x2108 (written value was 0x318C)
Reg 25: 0x0624 (written value was 0x0C2B)
Reg 20: 0xb848 (written value was 0xF848)
Reg 17: 0x00fa  (written value was 0x012C)
Reg 07: 0x00b2 (written value was 0x40B2)
Reg 03: 0x0642 - Readback correct this time
Reg 02: 0x0500 - Readback correct this time
Reg 01: 0x080b (written value was 0x0808)
Reg 00: 0x2010 - Readback correct this time

On this 2nd readback, Reg R3/R2/R0 readback correctly (despite reading back all zeros on the 1st try), while all the other registers listed readback incorrect values (even though they we had previously readback the correct values). We can't make any sense of this.  Do some of the registers with undefined fields have values that change over time, so readback result depends on when they are read?  Doesn't seem like any register values should be changing until we enable FCAL, which was not done until after the above data collected.

Any ideas of what we're doing wrong, or suggestions of what to try?  Should we be expecting readback to return different results every time?  Is there any C/C++ sample code you can provide that correctly write and reads back registers?

FYI after we initiate FCAL, the LMX2594 fails to lock.

Thanks, Ted    

  • 0
    TI__Genius 11900 points

    Hello Ted,

    This seems odd. The register values shouldn't be changing. Are you certain your SPI protocol meets all the timing requirements mentioned in section "6.6 Timing Requirements" and  "Figure 2. Serial Data Readback Timing Diagram"?

    Looks like for a lot of readbacks the difference is 1 bit or a bit shift, is this something you can debug for?

    Are you able to replicate this, that is every time you power up and follow this sequence the first readback has correct readback apart from last 4 registers and second readback has a lot of errors?

    Unfortunately we do not have any sample code that we can provide for this. Typically a SPI protocol implemented at a frequency under 50 MHz should work? What is your SPI frequency?

    Thanks,

    Vibhu

  • 0 in reply to Vibhu Vanjari
    Intellectual 260 points

    Hi Vidhu,

    Thanks for your reply.  We are using a 6.25MHz SPI clock, so I was not too worried about meeting timing requirements. However I will verify this.

    Yes the issue is repeatable - we seem to get the same results described above every time we execute the sequence.

    One more piece of information:  You may have noticed above that we are programming Reg0 with 0x2010 rather than 0x2410 - only difference being bit D10 cleared rather than set.  If we use 0x2410 (bit D10 set as shown in Table 23/Figure 35), then ALL of our registers readback with all zero values.  This bit Reg0 bit D10 is not described in datasheet but it seems to completely break the readback function???

    Thanks, Ted   

  • 0 in reply to Ted Wolfe
    Intellectual 260 points

    Hi Vidhu,

    We found our problem: a bug in our SPI programming code was causing extra data to be written to multiple registers which caused all sorts for problems apparently.  Didn't realize it until we probed the SPI bus and saw extra clock cycles.  Now we are able to successfully achieve lock.

    Thanks, Ted