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.

XIO3130: intermittent operation after reset

Part Number: XIO3130
Other Parts Discussed in Thread: XIO2001

We using the XIO3130 on our PCB for our new product, and hope to go to production shortly.

We have built several PCBs ( > 20 ) but we have two boards with the same intermittent problem.

We have strapped all 3 downstream ports for PCI hotplug (DNX_DPSTRP pulled high), but sometimes do not see the PWRON# handshake signal (nor downstream PCI refclk).

This does not seem to be a power-up only issue, since under software control I have tried toggling the UP_PERST# line with the same intermittent results.

We don't use the EEPROM option, but as an experiment I enabled that feature. Again if I probe the SCL / SDA lines sometimes after reset there is no activity on these lines.

I have verified (and experimented with different input levels) the signal condition of 100 MHz PCI reference clock delivered to the XIO3130.

The +3V3 and +1V5 are ferrite-bead filtered as recommended.

Please help me narrow in on this problem before we release our product, thanks.

  • Hello Steve,

    Have you checked to see if the issue follows the unit (e.g. putting the bad unit on a good and putting a good unit on a failing board? Also, can you share the schematic?

    Regards,
    I.K.
  • Hi Steve,

    Have you checked to see if the issue follows the unit(s)? Additionally, are you following the Power-Up/Power-Down Sequencing described in the datasheet?

    Regards,
    I.K.
  • Anyiam,

    The BGA part is soldered to the PCB. I cannot experiment by moving the part around.

    Steve

  • The datasheet says that 1V5 and 3V3 my come up in any sequence.
  • Hi Steve,

    Sorry for the delay, and thank you for your patience.

    Can you try toggling GRST# instead of UP_PERST#? There may be power-up sequence that incorporates GRST# (similar to the XIO2001) that's not specified in the datasheet.

    Regards,
    I.K.
  • Anyiam,

    Without cutting traces I do not have a way to toggle GRST#.
    I quickly looked at the XIO2001 power-up sequence, and this is exactly what my implementation follows;
    - GRST# and UP_PERST# are low and stay low when the power rails come up.
    - 1V5 comes up first then ~1ms later 3V3 ramps up
    - after ~10ms GRST# is driven high
    - after 100's of ms the reference PCI clock is generated
    - about 100ms later UP_PERST# is driven high

    Steve
  • Hi Steve,

    From the schematic provided it looks like GRST# is controlled through CPU. Can't you toggle it this way? If not, can try just momentarily grounding it? There should be no need to cut traces.

    Regards,
    I.K.
  • Anyiam,

    If I short out GRST# the chip seems to behave well.

    Unfortunately this means I would have to spin the PCB.

    Can you please tell me what I have done incorrectly.

    And if you believe that I have followed the datasheet correctly, can you please issue an official errata for future designers.

    Thanks,

    Steve

     

  • Hello Steve,

    I have learned that the the power-up-down sequencing for the XIO2001 also needs to be followed for the XIO3130. The current sequence in the XIO3130 datasheet is incorrectly defined. We will be issuing an application note soon to address this issue. I apologize for the inconvenience this is causing you since you have to spin your PCB, and thank you for your patience with this issue.

    Regards,
    I.K.
  • Anyiam,

    Please tell me exactly how I am not following the power-up sequence.
    Please see my reply from Jun 25, 2018 4:59 PM.

    Thanks,
    Steve
  • Anyiam,

    Please tell me exactly how I am not following the power-up sequence.
    Please see my reply from Jun 25, 2018 4:59 PM.

    Thanks,
    Steve
  • Hi Steve,

    Are 1V5 and 3V3 stable and valid before GRST# is deasserted (maybe 10ms is not enough time)? Would you be able to provide a screenshot of the waveforms? Also, is it possible to delay the deassertion of GRST# until UP_PERST# is deasserted?

    I'm also still a little confused about why you need to modify the board. The schematic I'm looking at says GRST is controlled by a CPU. It's dated as Jan 9, 2018 though, so is it possible that the schematic is outdated?

    Regards,
    I.K.

  • Anyiam,

    Please see attached scope images. GRST-3V3, GRST-1V5, GRST-UP_PERST

    GRST is sourced by the CPU and is generated automatically for WARM Reset (re-boot).

    This signal goes to MANY other chips on the board in order to ensure that a WARM reset sets up initial conditions similar to POR. (You do not have all the pages of the schematic). Thus I cannot "delay" this signal.

    Regards,

    Steve

  • Hi Steve,

    Thank you for the clarification about the conditions of GRST# in your system. It really does not look like you're doing anything incorrectly in regards to the sequence. Our only other theory is that perhaps 10ms just is not enough time before GRST# is deasserted.

    Can you perhaps try cutting the trace from the CPU and blue wiring GRST to UP_PERST# so they come up at the same time?

    Regards,
    I.K.
  • Anyiam,

    I could try hooking GRST# to UP_PERST#, and will definitely allow this option on the PCB spin.

    I just want to point out again that according to the datasheet at any time (not just at power up) toggling only the UP_PERST# low-to-high should reset the XIO3130 properly, but does NOT.

    It is unfortunate that everyone in the future using this chip (and checking the ERATTA) may encounter the same problem as myself.

    Though the forum email I have chatted to Gilbert Vellet who has / had this  SAME problem 2+ years ago: 

    e2e.ti.com/support/interface/digital_interface/f/130/t/472216

    Thanks for your help.

    Regards,

    Steve

  • Hi Steve,

    You're correct, the datasheet for the XIO3130 does not mention this, so we'll need to update some documents to ensure people in the future don't run into the same issue.

    Since I am not very familiar with the XIO devices, I actually referenced that same e2e post while trying to resolve the issue. I was unable to confirm if this was the same issue Gilbert faced though, since Elias no longer works here and it looks like they handled the rest of the conversation over email.

    But again, sorry for the inconvenience this has caused you, and thank you for your patience in resolving this issue.

    Regards,
    I.K.