LM98640CVAL: DLL False lock & serial interface problems

Hi Bradley,

Can you please confirm the power supplies you have provided to the CVAL EVM.  You state putting +5V on JR4 which is confusing to me since this is labeled -5V on the schematic. Did you mean JR1?  How is U3 and U4 getting power?  Have you confirmed correct power supplies to all active devices by probing at the device pins?

Thanks

Christian

Hi Bradley,
Thanks for the feedback.

The datasheet lists the min SCLK frequency as 1 MHz, because that was how the part tested and qualified. We have found that the part will function properly with lower SCLK frequencies, but have not characaterized it.
In our testing of the part, we use a TI WaveVision5 to communicate with the LM98640. The SCLK frequency from the WV5 board is 41 kHz. In this setup, a signal on INCLK was not required to communicate with the LM98640 SPI. It may be possible at higher SCLK frequencies, that INCLK is required. I will update the post with these details.

The statement about False Lock was in reference to once the part was up and running properly. The False Lock and DLL Reset were designed in for cases when the DLL might lose lock due to an external factor such as ion strike. It was found that in those cases, the DLL would automatically relock and the DLL reset was not needed.

In addition to Christian's comments:

I agree that it is likely that you are likely getting a good INCLK signal. You can verify it by probing at test points TP22 and TP23.

The LM98640 does not have power on reset, and all registers must be written after power up. Also see the datasheet for the order of writing the registers. This can make a difference sometimes, depending upon what mode you are putting the part in.

@Christian Yes, sorry. JR1 is correct. I misread the schematic as I was typing my post.

Before powering the rest of the board, I checked that I was getting the correct voltages on pin 5 of both JP6 and JP7. Once verified, I connected pins 5 and 6 on both jumpers to supply the rest of the board.

U3 and U4 should be powered by the board. Is there some reason I should think otherwise? When applying INCLK, I did verify that I was seeing the proper signal at TP22 and TP23, so I think I can assume that U3 and U4 are correctly powered.

@Kirby Ah ok. Perhaps I'll try the serial interface at lower speeds without INCLK, just to see what happens.

I did check the INCLK signal at TP22 and TP23, and everything looked correct. I will double check this though.

And yes, I'm writing all registers at startup and I'm aware of the comment in the datasheet that says I should write register 0x3D before register 0x09. Could you please advise on the best write order at startup? I think my current strategy has been the following:

1. Write registers 0x25 and 0x06 to ensure proper INCLK configuration
2. Write all of the remaining registers in order (including reserved registers), starting at 0x3F and ending at 0x00.

I have tried a few different approaches here, including:

• skipping the reserved registers
• writing registers 0x25 and 0x06 in order with the rest of the registers
• skipping register 0x28 so as not to disturb the DLL

But it seems like I inevitably have problems, regardless of the write order.

You say that I should not be experiencing a false lock and that the false lock bit should never bit set in normal operation. Can you suggest any other possible causes of false lock? Would you expect a false lock to cause intermittent and irreproducible problems with the serial interface?

Thanks for your help,

Bradley

Bradley,
I will send you a set up instructions for doing test pattern mode. You could try this and if it works, work backwards from there for your set up.

Kriby and Christian,

Sorry for the delay; I meant to write you yesterday.

I am fairly certain I have identified the problem. I found that my FPGA development board was sending additional, erroneous write commands to the AFE, above and beyond those I would expect based my software commands. Using an oscilloscope, I had previously confirmed that the timing requirements were being met and that the data was correct. However, until my further testing, I hadn't captured one of the erroneous write commands. I believe this fully explains the behavior I am seeing. I want to implement further testing of the HDL before re-programming the FPGA, so I cannot confirm full functionality just yet.

I have one last question before you can close this thread. What is the expected result when writing to status bits and reserved bits? For example, if I were to write a 1 to the False Lock bit, should I expect to read a 1 from it on the following cycle? Or are writes to status bits ignored? What about reserved bits?

Thanks for all of your help. Sorry for the issue on my end. I had suspected there was a problem with the HDL, but the oscilloscope was telling me otherwise. In the future, I'll be sure to consider that it might be missing something.

Bradley