• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 22 subscribers
  • Views 590 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.

Original question:

LMK04828: SPI 3-wire read timing

LMK04828: SPI Verification of LMK04828B programmed correctly - stable / PLLs locked...

Nathan Jachimiec
Prodigy 20 points
Part Number: LMK04828

On the LMK04828 - I got SPI reads working and I would like to be able to read the status of the synthesizer so that I know if its PLLs are locked and generating the frequencies that I programmed into it via my TICs project.  So basically, I would like to know what SPI registers do I need to access in order to be able to have my control SW know that it was successful in programming the LMK04828B?  I also use this LMK to provide clocks to another two downstream LMX chips.  I would like to be sure before I take the LMX chips out of reset and program them too, that the LMK clocks are stable first.  This is why I'd like to be able to read some SPI registers to know if the clocks are ready and stable.

Regards,

Nathan

  • 0
    TI__Genius 12560 points

    Hi Nathan,

    The PLL lock detect status can be seen by Status_LD1 or Status_LD2 I/O pins and it can be set by registers 0x15F and/or 0x16E.

    Thanks!

    Regards,

    Ajeet Pal

  • 0 in reply to Ajeet Pal
    Prodigy 20 points

    I am using one of the Status pins for SPI Readback.  I was hoping that I could read back my PLL digital lock detect (DLD) status via a SPI readback.  Our board routes the Status pins to LEDs and one to a SPI interface.  Since working remotely, one cannot physically see the LED anymore so I need a method to readback via SPI.   

    Thanks.

    Nathan

  • 0 in reply to Nathan Jachimiec
    TI__Mastermind 18950 points

    Hi Nathan,

    Looking through the datasheet and TICS Pro, I found register R386 (0x182) and register R387 (0x183). You should be able to read the DLD status for PLL1 and PLL2 from them. See Table 81 and Table 82 in the datasheet for more details.

    Best,

    Evan Su

  • 0 in reply to Evan Su
    Prodigy 20 points

    Thanks Evan,

      I thought that would work.  I am reading back on R386 0x182 - the RB_PLL1_LD is 0 for some of my TICs projects and then other times I get a 1 for that bit.  I am not sure why some of my TICS projects give me back PLL1 lock detected and other do not.  I also readback PLL2 and I get 0 on all of my TICs projects.  I'm not worried about PLL2 because I don't think those TICs project enable dual PLL usage.  However, I am concerned that PLL1 is not reading back as high for all my projects.  I would assume would have to be if I am getting what appears to be stable clocks on the various clock outputs I have enabled.
      Is there something that I would need to enable first to be able to get a RB_PLL1_LD true?  I saw the note in the datasheet about PLL2 having requirement that I set the MUX first.  However, there was no such warning on PLL1.  Also, I am doing my SPI readback via the STATUS_LD2 so I cannot change the mux or readback LD2 anyway.
      Thanks,

    Nathan

  • 0 in reply to Nathan Jachimiec
    TI__Mastermind 18950 points

    Hi Nathan,

    That sounds unusual. Normally if a device's PLL is unlocked, it should not be producing a stable and correct output. This is a jitter cleaner with holdover, so it can maintain a fairly correct output if the input is invalid by basically freezing the VCO in place, and if this happens the PLL should be considered unlocked. But that assumes holdover is enabled and the input isn't always reliable. Out of curiosity, for the projects where you're reading back RB_PLL1_LD = 0, what's the value of the field RB_PLL1_LD_LOST at bit 2 of the same register?

    The datasheet doesn't have any notes for RB_PLL1_LD compared to RB_PLL2_LD but we might as well check the analogous condition: is PLL1_LD_MUX set to PLL1 DLD?

    Best,

    Evan Su

  • 0 in reply to Evan Su
    Prodigy 20 points

    Hi Evan,

      I wrote a SPI command to restore the PLL2_LD_MUX to the LED and take away the SPI readback.  I now see that on those TICs files that I've inherited, the PLL2_LD is high, so PLL 2 is in use on these particular set of synthesizer options and not others.  So it seems that because I turn SPI readback on, I lose the ability to observe if PLL 2 is in lock state.  I only got confirmation via the LED lighting up.  I also had to make sure the LED was in "push-pull" mode for our board but eventually it made sense to me.  I mentioned that I inherited these designs, the previous engineers only archived the exported TXT files.   I notice that TICS when it reads back the imported TXT file doesn't seem to update all of the GUI prompts so it would have been better to archive the actual TICS project as well as the TXT file.

      btw, PLL1_LD_MUX is on PLL1_DLD.  That was the default and I left it alone.  PLL2_LDL_MUX I had switched to SPI Readback.  I would forward on to engineering that we need to be able to use SPI to readback more status.  We cannot always look at an LED to see if we are locked.

    Thank you,

    Nathan