LMK04610: Impossible to write registers after RESETN is released

Part Number: LMK04610
Other Parts Discussed in Thread: USB2ANY

Hello,

I have been facing an issue with the use of the LMK04610.

According to the datasheet of the LMK04610, RESETN should be toggled after power-up before configuring SPI registers (paragraph 9.5.1 in the datasheet). There is no delay between RESETN release and the beginning of SPI programming in the datasheet but I have read in some posts that no delay is necessary: SPI can be used right after the release of RESETN.

We use one LMK04610 on a specific board and we made the following observation: when we toggle the RESETN and try to program SPI registers afterwards, the registers configuration do not change as if the write into registers were not taken into account. But when we try to program registers without toggling RESETN we are able to configure registers.

It is surprising because toggling RESETN before SPI programming should work.

Could you provide us some support please ?

Best regards,

Dilan ALBERT

  • Hi Dilan,

    Apologies if post formatting is disorienting - mobile posting on the new site makes it difficult to accurately assess/correct text size.

    How are you confirming register programming? Checking for a specific device behavior? Reading back the registers?

    Note that LMK04610 requires programming DEV_STARTUP=1, about 25-30ms after programming all other registers.

    Regards,

    Derek Payne

  • Hi Derek,

    Thank you for your quick reply.

    To give more details, LMK programming is done just after power-up by a FPGA device (so it is quite fast). Then, we are checking the registers configuration by reading back the registers values (via the same FPGA). This reading is done several seconds after LMK programming. We observe that all registers kept their default values and the output clock we are expected to see on one LMK output is not generated.

    When RESETN is never asserted, we observe that the registers have the correct configuration and the output clock is correctly generated.

    I can confirm that DEV_STARTUP configuration is done at the end of the programming sequence in both cases.

    Best regards,

    Dilan ALBERT

  • Hi Dilan,

    Can I get a copy of your register programming? I would like to confirm that the programming sequence and values can be replicated in our lab.

    Regards,

    Derek Payne

  • Hi Derek,

    Of course, please find below a copy of the register programming sequence that we use.

    lmk04610_prog_seq.txt
    #ADDR  DATA
    0x0011 0x00
    0x0010 0x1C
    0x0012 0x04
    0x0013 0x10
    0x0014 0x80
    0x0016 0x28
    0x0019 0x29
    0x001A 0x3A
    0x0028 0x08
    0x002A 0x08
    0x002C 0x80
    0x002E 0x14
    0x002F 0x08
    0x0030 0x01
    0x0031 0x0C
    0x0034 0x43
    0x0035 0x10
    0x0037 0x14
    0x0038 0x43
    0x0039 0x10
    0x003A 0x03
    0x003C 0x02
    0x003E 0x63
    0x0040 0x63
    0x0042 0x03
    0x0044 0x06
    0x0046 0x06
    0x0048 0x06
    0x0049 0x02
    0x004A 0x00
    0x004C 0x08
    0x004E 0x06
    0x004F 0x02
    0x0050 0x00
    0x0051 0x02
    0x0052 0x00
    0x0055 0x00
    0x0056 0x0D
    0x0059 0x61
    0x005A 0x0A
    0x005B 0x02
    0x005E 0x00
    0x005F 0x61
    0x0060 0xA8
    0x006B 0x01
    0x006C 0x0F
    0x006D 0x09
    0x006E 0xFF
    0x0072 0x14
    0x0074 0x04
    0x0077 0x01
    0x0080 0x0A
    0x0085 0x00
    0x0086 0x00
    0x0096 0x00
    0x009C 0x20
    0x00F7 0x40
    0x0127 0x24
    0x0128 0x21
    0x0129 0x25
    0x012A 0x21
    0x012B 0x04
    0x012C 0x25
    0x012D 0x24
    0x012E 0x21
    0x0130 0x05
    0x0131 0x05
    0x0133 0x05
    0x0134 0x05
    0x0135 0x05
    0x0138 0x05
    0x0139 0x05
    0x013A 0x05
    0x013C 0x05
    0x013D 0x05
    0x0140 0x0A
    0x0141 0x09
    0x0142 0x40
    0x0146 0x3C
    0x014E 0xC8
    0x0151 0x14
    0x0152 0x0F
    0x0011 0x01
    

    Don't hesitate if you have questions about it.

    Best regards,

    Dilan ALBERT

  • Hi Dilan,

    Had a bit of trouble getting our lab EVM working today, but I think I figured the problem out. Apologies for the delay, I'll be able to dig into this in detail tomorrow.

    Regards,

    Derek Payne

  • Dilan,

    I loaded your programming on an EVM, things appear to be working, and I have readback capability (even after RESETN toggle). This points to a SPI communication issue. I suggest you double-check that your SPI timings are conformant to the datasheet SPI timing diagram. One non-obvious result of the timing diagram is that the SCL pin should be low before SCS* goes low.

    As a side note, I see that you have configured one of the outputs as a SYSREF. Please note that it is not possible to trigger a SYSREF pulse in distribution mode unless a clock is present on the output of the PLL2 prescaler, implying a need to lock PLL2 (regardless of whether PLL2 is used).

    Regards,

    Derek Payne

  • Hi Derek,

    Thank you for your reply.

    I already checked the timings linked to the SPI interface to be sure that we are compliant with the LMK04610 datasheet. If you can check on your side, I inserted below a chronogram of SPI communication with the LMK.

    For me, everything should be fine:

    • RESETN is toggled before SPI communication (1 -> 0 -> 1). RESETN low pulse width duration is more than 100ns
    • SCL is maintained low as you suggest before SCSN is set low
    • Delay between CS* falling edge to SCL rising edge is about 30ns
    • SPI clock frequency is about 15MHz

    The fact is, when RESETN is toggled as depicted in the chronogram, LMK SPI registers don't change and keep their default values despite the programming sequence. But, if we tie RESETN to '1'  at startup (RESETN is never asserted), the same SPI sequence works perfectly.

    One reassuring thing is that the sequence seems to work on your board. Could you eventually share what are the SPI timings implemented on your SPI interface to see if I can make it work with them ?

    For your note about the SYSREF, yes, you are right, we are still working on a sequence with the use of the PLL2 to be able to generate a SYSREF signal as we need. Thank you for this observation.

    Best regards,

    Dilan ALBERT

  • Hello Dilan,

    Thanks for the details, we'll check into it on our side.  I know it's not 15 MHz... Probably closer to 1 MHz.

    73,
    Timothy

  • Dilan,

    Our own SPI is running much closer to 1MHz as Timothy suggested. That said, I don't think the SPI frequency should be the issue: something about the reset pulse you generate appears to be selectively preventing the device from communicating.

    Just for testing purposes, have you tried other durations on the RESETN pin? Because I'm manually toggling my RESETN line, the reset pulse width is close to 300ms and the delay between RESETN 0 -> 1 and the beginning of SPI programming is more like 1s... you could try individually varying both of these parameters to see if one makes a difference.

    The USB2ANY also introduces a programming delay of 10-25ms between each SPI write... This is more trouble to test, but may be worth exploring should other options become exhausted. I'd start this arm of the investigation by inserting some delay between bulk SPI programming and the device startup bit programming...

    Regards,

    Derek Payne