• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 21 subscribers
  • Views 112 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.

LMK61E2: I2C shadows registers.

Pawel Piwowarski87949
Intellectual 805 points
Part Number: LMK61E2
Other Parts Discussed in Thread: LMK03318

Tool/software:

Hello.

I have a question about presence of shadows registers for >8 bits settings.

It is common practice to implement such registers when the stored value exceeds 8 bits. For example, in timer configurations or ADC readings. The transmitted or read LSB value is not written to the register until the MSB value is also sent (and then they are updated together).

But the LMK61xxx datasheet did not mention that such a technique was used for any of the PLL_NDIV, PLL_NUM, PLL_DEN, or XO_CAPCTRL registers.
I am especially interested in the XO_CAPCTRL registers because I want to use fine-tuning during the device's operation (not only at startup, but in runtime).
I'm worried that there might be glitches when crossing the boundaries of 255-256, 511-512, and 767-768, since the values will be transmitted over a relatively slow I2C interface.

Thank in advance!

  • 0
    TI__Genius 12750 points

    Hi, 

    As far as I know LMK61E2 does not use shadow registers to handle fields that are spread across multiple register addresses. I don't expect this to be a major risk for XO_CAPCTRL since bits 1:0 are stored in R16 and 9:2 are in R17, so there shouldn't be major jumps in the XO cap code from the delay between register writes to R16 and R17. Could you share some more details about your use case? We also have an app note describing how to calculate the XO cap code's impact on frequency here: https://www.ti.com/lit/an/snaa283/snaa283.pdf 

    Regards, 

    Connor 

  • 0 in reply to Connor Lewis
    Intellectual 805 points
    Connor Lewis said:
    . I don't expect this to be a major risk for XO_CAPCTRL since bits 1:0 are stored in R16 and 9:2 are in R17, so there shouldn't be major jumps in the XO cap code from the delay between register writes to R16 and R17.

    I expect them to be huge, for the same reason.

    My project has to synchronize to external, precise and known CLK.

    So I set NDIV, NUM and DEN to known values, and synchronize it by only changing XO_CAPCTRL.

    I2C frames sending only XO_CAPCTRL values, so they consist 4 bytes (I2C address, I2C register address, XO_CAPCTRL LSB and MSB).

    Frames are sent at a repetition rate of few k/sec, so even at an SCL frequency of 400 kHz, the next frame is immediately after the previous one.

    Therefore, the distance between XO_CAPCTRL LSB and MSB writes is significant.

    I sending relatively small XO_CAPCTRL changes (1...5), so glitch on boundary (256) may be significant. But I haven't tested this yet.

  • 0 in reply to Pawel Piwowarski87949
    TI__Genius 12750 points

    I might be misunderstanding, but my assumption is that since the 2 LSB bits are stored in R16, at most the XO_CAPCTRL error could be off by 3. For example to set the code to 255, you would write 0x3 to R16[1:0], then write 0x3F to R17. Then if you updated the value to 256, you would write 0x0 to R16[1:0] which temporarily sets XO_CAPCTRL to 252. In the next I2C transaction 256 would get written to R17. So essentially XO_CAPTRL would go from 255 ->252 -> 256 in this example. 

    If you're trying to lock to a known clock frequency, would it make sense to use the clock directly as an input to a PLL-based clock generator for your application? 

    Regards, 

    Connor 

  • 0 in reply to Connor Lewis
    Intellectual 805 points

    Sorry, my mistake. I overlooked that in R16 there are only 2 LSBs, and in R17 there are 8 MSBs. So, glitches will occur every 4 values, but their amplitude will be small (not 256, but only 4).

    Connor Lewis said:
    If you're trying to lock to a known clock frequency, would it make sense to use the clock directly as an input to a PLL-based clock generator for your application? 

    Maybe yes, but I couldn't find any PLL with such low jitter as LMK6xxx family.

  • 0 in reply to Pawel Piwowarski87949
    TI__Genius 12750 points

    No worries, let me know if you have any issues getting LMK61E2 working in your system. 

    We also have a few PLL clock generators that have similar jitter performance to LMK61E2. You could look into LMK03318, it has around 150fs max jitter for a 156.25MHz output when the PLL is operating in integer mode. What kind of frequency output do you need to lock to / generate, and what are your jitter requirements? We may have other devices that are a better fit. 

    Regards, 

    Connor