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.

AFE5832LP: AFE initialization issue

Part Number: AFE5832LP

Hi,

We have observed an issue on certain AFE devices, where the device comes up in a bad state after power-up and initialization. The symptom is as follows:

  • Data is successfully received through the LVDS interface, but the recieved samples hold constant, seemingly random, values. In some cases, only certain LVDS lines from the AFE is affected.
  • The symptom is the same regardless of transmitting test-pattern or ADC data.
  • The static sample values change when a TX_TRIG is issued.

As a workaround, either of these have resolved the problem:

  • Extending the RESET pulse width. The required length to resolve the issue varies between devices, but it needs to be considerably longer than the 100 ns specified in the datasheet.
  • Issue two RESET pulses. In this case, the width of the pulses has no importance (the issue is resolved with pulse widths well below the 100 ns requirement).

The Device Initialization procedures described in chapter 10.4 and 11.1 of the datasheet have been followed, with the possible exception of the delay between rise of DVDD_1P2 and other supplies. Can that be of relevance here?

  • Hi,

    As recommended in the datasheet, DVDD_1P2 supply should be up and stable before all the other supplies. This is a must requirement because DVDD_1P2 controls the digital blocks and SPI. If this supply is not up before the rest of the supplies, there is high chances of undefined states for clock dividers, references, comparators etc. Which may lead to data inaccuracy. Timing constraint mentioned in section 11.1 for power sequencing must be strictly followed.  

  • Thanks for your answer Sheetal,

    Looking at Section 11.1 of the datasheet, it only states that AVDD_1P8 will draw higher-than-normal current until DVDD_1P2 reaches 1.2V. There is no mention of the digital blocks entering undefined states, clock divider issues, or resulting data inaccuracies if this sequence is not strictly followed. Is this documented somewhere else? Should it be mentioned in the data sheet?

    It seems we are able to recover through multiple / longer resets, could this be a viable workaround? Why / why not?

    Do you have other suggestions for a firmware workaround? The power supplies are not currently individually controlled, so altering the power-up sequence would require hardware modifications.

    Thanks for your support.