• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 47 subscribers
  • Views 1192 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.

LM98640CVAL: DLL False lock & serial interface problems

Bradley Harden
Prodigy 160 points
Part Number: LM98640CVAL
Other Parts Discussed in Thread: WAVEVISION5, STRIKE

Hi,

I recently purchased the LM98640CVAL evaluation board, and I have been having trouble communicating with the analog front-end (AFE) via the serial interface.

In most cases, I am able to successfully read from and write to the AFE register map. However, I occasionally observe inconsistent and irreproducible errors. For example, sometimes the value read from a register does not reflect the value last written to it. Other times I seem to get erroneous outputs.

In one particular instance, I came to realize that the False Lock signal had been set by the AFE. During subsequent testing, I have consistently observed instances of the False Lock bit, and there appears to be a strong correlation between the presence of the False Lock bit and the misbehavior described above. Furthermore, resetting the DLL by writing to bit 0 of register 0x28 appears to have no effect.

Before I describe my test setup, I would like to note two things. After reading through comments here on the forum, I have identified at least two instances where the behavior of the evaluation board during my testing did not agree with statements made by TI engineers:

  1. In this post, an engineer contradicts the datasheet and claims that INCLK is not required during serial communication. During my initial testing of the serial interface, I did not apply INCLK. However, I was completely unable to communicate with the AFE until I followed the datasheet and supplied INCLK.
  2. In this post, an engineer claims that TI has found no cases in which a False Lock is observed in the DLL. However, I am consistently encountering a False Lock, and resetting the DLL does not seem to correct it.

Could you please advise me on how to proceed with debugging? The following describes my test setup:

  • I am providing +5V through JR4
  • For INCLK, I am supplying a 5 MHz, 3.3V CMOS signal produced by an FPGA development board
    • I am setting registers 0x25 and 0x06 appropriately for INCLK = 5 MHz
    • I have disconnected J31 and connected J33. Rather than supply INCLK through the SMA connector, I am supplying it through header pin 1 on JF1.
      • Could this be the source of the problem? I'm a bit skeptical, because the signal is buffered by U3 and driven by U4.
  • I have connected the serial interface pins in JF3 to the same FPGA development board.
    • I am using an SCLK frequency of 1 MHz
    • I have observed these signals with an oscilloscope to ensure that all of the timing requirements are being met, and that the byte received by the FPGA reflects the actual signal

Thank you for your help.

Bradley

  • 0
    TI__Genius 14540 points

    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

  • 0
    TI__Genius 17115 points
    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.
  • 0 in reply to Kirby Kruckmeyer96848
    Prodigy 160 points

    @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

  • 0 in reply to Bradley Harden
    TI__Genius 17115 points
    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.
  • 0 in reply to Kirby Kruckmeyer96848
    Prodigy 160 points

    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

  • 0 in reply to Bradley Harden
    TI__Genius 17115 points
    Thanks for the update and I am glad you were able to figure out your problems.

    As far as the registers go, the status bits will either can not be written or will self reset.

    Some of the reserved bits are for special test modes we use when testing the part and changing these can put the part into a different state.