LMK04616: RESETN Recovery Time

jh840

Part Number: LMK04616

We’re using an LMK04616 in a single stage configuration (bypassing the first stage). We found that we have to add a 100ms delay during the initialization steps for the device to function correctly and we’d like to know if this is expected.

The first portion of our initialization sequence is below. The 100ms delay has to occur anywhere after step 3 and before step 11. When the delay is removed or reduced or placed outside of these steps, the device doesn't lock and the output frequency is incorrect. We also tried inserting multiple smaller delays between steps 3 and 11 and the device works as long as the total delay is at least 100 ms.

RESETN is being asserted (active-low) for at ~400ns and each SPI write to the device takes ~3us.

1:   Drive RESETN pin high
2:   Drive RESETN pin low
3:   Drive RESETN pin high
                             <= 100ms of delay added between here...
4:   Write 0x80 to 0x08D
5:   Write 0x00 to 0x011
6:   Write 0x0E to 0x010
7:   Write 0x04 to 0x012
8:   Write 0x00 to 0x013
9:   Write 0x00 to 0x014
10: Write 0x08 to 0x015
                             <= ...and here
11: Write 0x48 to 0x016
.
.
.
199: Write 0x01 to 0x011

Thanks,
Justin

over 5 years ago

0 Timothy T over 5 years ago

TI__Mastermind 28550 points

Hello Justin,

I presume you have confirmed that all power supplies are powered up before you release RESETN?

Looking at the flow chart in figure 50 discusses an internal LDO settling time. Can you confirm that the PLL1_CAP, PLL2_LDO_CAP, and PLL2_VCO_LDO_CAP are to final voltage before you start programming? Or if this changes during your programming, such that your delays allow this to reach a final voltage?

73,
Timothy

0 jh840 over 5 years ago in reply to Timothy T

Prodigy 30 points

Thanks, Timothy.

The LMK is connected to an fpga. RESETN is pulled-up (de-asserted) during power-up and as soon as the fpga configures, it drives RESETN low. We may stay in this state for seconds or minutes before executing the initialization steps described above. We get the same behavior if we repeat the initialization without power-cycling.

I'll put a pull-down on RESETN and see if that helps. I'll also probe the CAP pins to verify they've settled.

Justin

0 jh840 over 5 years ago in reply to jh840

Prodigy 30 points

We added a 10K pull-down to RESETN to hold the device in reset during and after power-up. The FPGA continues to drive RESETN = 0V after it is configured. We stay in this state for several seconds. All voltages and clock inputs look good. However, we still have to add the 100ms delay after releasing reset somewhere within the first 7 transactions for the device to come up correctly.

It seems to me that this is related to when RESETN is released. Is there a detailed description of what RESETN is controlling and what happens after it is released? If the device has a POR circuit, why does it need the external RESETN to be asserted as well?

Justin

0 Shawn Han over 5 years ago in reply to jh840

TI__Genius 9920 points

1, Measure RESETN pin waveform to confirm rising edge is not too slow as 100 ms. Remove big cap on RESETN pin.
2, TI recommends programming registers in numeric order -- for example, 0x000 to 0x1FFF -- to achieve proper device operation.
TICS Pro can export hex register file, which shows registers programming sequence. Reserved registers can be ignored.
4: Write 0x80 to 0x08D // Only write operation, never mind 3-wire or 4-wire SPI, this step can be ignored until you need read registers.
5: Write 0x00 to 0x011 // Default value, self clear bit, delete this step
3, Make sure SPI clock < 20 MHz and high width and low width > 25 ns.

Clock & timing

Clock & timing forum

LMK04616: RESETN Recovery Time