• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Subscribers 21 subscribers
  • Views 401 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LMK04610: Impossible to write registers after RESETN is released

Dilan Albert
Prodigy 20 points
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

  • 0
    TI__Mastermind 28960 points

    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

  • 0
    Prodigy 20 points

    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

  • 0 in reply to Dilan Albert
    TI__Mastermind 28960 points

    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

  • 0 in reply to Derek Payne
    Prodigy 20 points

    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

  • 0 in reply to Dilan Albert
    TI__Mastermind 28960 points

    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

  • 0 in reply to Dilan Albert
    TI__Mastermind 28960 points

    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

  • 0 in reply to Derek Payne
    Prodigy 20 points

    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

  • 0 in reply to Dilan Albert
    TI__Mastermind 28530 points

    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

  • 0 in reply to Dilan Albert
    TI__Mastermind 28960 points

    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

  • 0 in reply to Derek Payne
    Prodigy 20 points

    Hi Derek,

    OK, thank you for this information, as you suggest, I will make some experiments on RESETN pulse width duration and on the delay between RESETN de-assertion and the beginning of SPI programming. I will keep you aware of my results.

    Personnally, I don't think the problem comes from the time duration between SPI writes as the same sequence seems to work but without RESETN => I will try this test in the end.

    Best regards,

    Dilan ALBERT

  • 0 in reply to Dilan Albert
    TI__Mastermind 28530 points

    Ok great, keep us posted.

    73,
    Timothy

  • 0 in reply to Timothy T
    Prodigy 20 points

    Hello Derek, Timothy,

    I coud make some tests and I am able to give you some results. Below, the list of the tests:

    • Test nb 1: at startup, RESETN is set to '1' during 300ms, then RESETN is set to '0' during 300ms, then RESETN is set back to '1' and SPI programming begins approx. 150ns after RESETN de-assertion. The result is that the expected output clock is not generated => this sequence does not work.
    • Test nb 2: at startup, RESETN is set to '1' during 150ns, then RESETN is set to '0' during 150ns, then RESETN is set back to '1' and SPI programming begins approx. 300ms after RESETN de-assertion. The result is that the expected output clock is generated => this sequence seems to work.

    According to these tests, I have the impression that it is necessary to have a minimum delay between RESETN release and the beginning of the SPI programming so that the PLL can accept SPI writes.

    What do you think of these tests? Please, tell me if you need me to make some more tests with different parameters.

    Best regards,

    Dilan ALBERT

  • 0 in reply to Dilan Albert
    TI__Mastermind 28960 points

    Dilan,

    Your results make sense to me. It seems that our prior guidance (that SPI programming could occur immediately after RESETN is deasserted to 1) was incorrect. As this information is not captured anywhere in the datasheet, I think it would be helpful to everyone for us to determine realistic values for the RESETN to SPI timing and include them in the next datasheet revision. I will attempt to identify the minimum delay with someone who can review the device's digital implementation, and let you know what I discover.

    Regards,

    Derek Payne

  • 0 in reply to Derek Payne
    Prodigy 20 points

    Thank you for your reply Derek, I will wait for your investigations and results to update my SPI sequence.

    Best regards,

    Dilan ALBERT

  • +1 in reply to Dilan Albert
    TI__Mastermind 28960 points

    Hi Dilan,

    There is a 2^20 delay counter clocked by an internal 10MHz ±30% POR state machine clock, triggered by RESETN low->high transition. This works out to 2^20/(10MHz * 0.7) = about 150ms worst-case. I suspect our applications team never observed this delay, either because we were manually toggling the RESETN line on an EVM from TICS Pro, or because there is typically around 10ms of delay between each SPI write on USB2ANY due to application latency and USB transaction delays, and the first 16 TICS Pro register writes are to non-critical registers such as die ID and version (or R0, but typically we're not changing anything in R0).

    Since there's no test coverage for the POR number, we suggest that 200ms (-50%) is a reasonable additional margin that should cover the overwhelming majority of devices. Again, since we don't have test coverage on this, 200ms isn't a guaranteed and tested parameter; nevertheless, it's at the point where any device which still doesn't program after 200ms would likely have been screened out for other reasons, so you will likely never encounter a functioning device that also doesn't program 200ms after RESETN low->high. 

    Regards,

    Derek Payne

  • 0 in reply to Derek Payne
    Prodigy 20 points

    Hi Derek,

    Thank you for your detailed answer.

    I tested the value 200ms that you suggested and the SPI programming is still working. Therefore, I will keep this value for my design. Please, let me know if, after more investigations, the value needs to be adjusted (by a greater value). I will, of course, monitor the next revision of the datasheet to check if I need to update this delay Slight smile.

    Thank you again for your support.

    Best regards,

    Dilan ALBERT