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

xds100v2 putting overvoltage on CPLD?

Matthijs van Duin
Mastermind 8030 points
Other Parts Discussed in Thread: OPA2363

Looking at the XDS100v2 (rev 2) schematic, dual opamp U6 (OPA2363) is being used for two purposes:

  • (ch A) as comparator to produce the "target voltage ok" (PWRGOOD) signal
  • (ch B) as part of a voltage follower circuit generating the target-side I/O bank supply

Because of the second purpose the opamp is powered directly by the USB 5V "VBUS".  However, this also means the comparator output will be at 5V.  This output is connected to the CPLD, which is not 5V tolerant, with only a series resistor in between (which offers no protection against overvoltage).

Am I overlooking something here?  Otherwise this rather seems like a significant design flaw.  As the Xilinx documentation puts it: "If you drive 5V into the CoolRunner-II, the long-term reliability of the device is compromised."

  • 0
    TI__Guru**** 169224 points

    Hi,

    Thank you for the information. We reached the same conclusion as you; some measurements I did showed VBUS injected into pin 16 of the FPGA, which is void by the device specifications. This will be fixed in a future revision of the schematics and I need to check how this will be communicated to the third party manufacturers.

    I will also post a remark on the XDS100 wiki page for current users.

    The simplest way to workaround this is to add a 10kΩ resistor in the trace that connects R31 (5.1kΩ) to pin 16 of the XC2C32A. This voltage divider would then bring down the voltage to 3.3V.

    Despite this, the fact that I (and several others) have XDS100v2 emulators in fully working order for several years now probably attests for the quality of the FPGA device itself. 

    Thank you again and I apologize for the inconvenience.

    Regards,

    Rafael

  • 0 in reply to desouza
    Mastermind 8030 points

    desouza said:
    Despite this, the fact that I (and several others) have XDS100v2 emulators in fully working order for several years now probably attests for the quality of the FPGA device itself. 

    Yes, I'm a big fan of the Xilinx CPLD since it also makes the XDS100v2 (unlike most other low-cost debuggers) safe to hot-plug and safe to "cold-spare" (leave it connected to the target while the debugger is unpowered itself).

    Xilinx actually gives a formula for estimated oxide lifetime, which yields this plot:

    VBUS versus estimated gate oxide lifetime (months)

    So even at the USB-spec max of 5.25 V the CPLD isn't going to die instantly (the Xilinx document mentions that at 7.5 V you can expect to enjoy the functionality of your CPLD for about 10 minutes).  Lifetime can also be much increased by lowering the VBUS somehow (USB spec min is 4.75 V iirc), e.g. by inserting a bus-powered hub in the chain or adding more bus-powered devices.  This may be a simpler workaround for most end-users than patching a resistor onto the XDS.

  • 0 in reply to desouza
    Mastermind 8030 points

    desouza said:
    This will be fixed in a future revision of the schematics

    If you're going to modify the schematic anyway, consider connecting unused target-side CPLD pins (P22, P23, P32) to EMU2-4.  This would allow the possibility of future enhancements to XDS100v2 functionality by updating the CPLD. (Especially since I think the coolrunner-II allows reprogramming the SRAM while leaving the backing Flash unmodified, which would enable temporary reprogramming of the XDS100v2 to some alternate mode of operation without any risk to its power-on default functionality.)

  • 0 in reply to Matthijs van Duin
    TI__Guru**** 169224 points

    Hi,

    Thanks for the comments. Unfortunately I can't promise the reference design will incorporate the addition of EMU2~4, as I don't make this decision. Nonetheless it is an interesting suggestion. 

    Regards,

    Rafael

  • 0 in reply to Matthijs van Duin
    Mastermind 8030 points

    A late addendum to this:

    I noticed that USB suspend causes the CPLD to shut down the opamp. Linux by default disables auto-suspend of USB devices because there are apparently too many devices which handle it poorly, but you can easily enable it by adding

    ,ATTR{power/control}:="auto"

    the udev rule for the XDS100v2.  For example, something like:

    SUBSYSTEM=="usb",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="a6d0",GROUP:="dev",MODE:="0664",ATTR{power/control}:="auto"

    or

    SUBSYSTEM=="usb",ATTRS{product}=="Texas Instruments Inc.XDS100 Ver 2.0",GROUP:="dev",MODE:="0664",ATTR{power/control}:="auto"

    with group/permissions set as desired of course. (I don't remember what the original rule that CCS installed looked like, but it should be easy enough to adapt).  You then (re)connect the xds, you'll see the green led light up for a few seconds only and then go off again; this indicates the XDS was put in suspend.  If you start a debug session, the led will go on again. End the session, and seconds later the led goes off again.

    This means that the 5V signal will only be driven while a debug session is active, rather than continuously while connected to a powered target.

    Since this is quite a simple fix, I would suggest to include it in some future update of CCS to increase the longevity of Linux users' XDS100v2 devices. (I'd presume something similar should be possible on Windows, but I'm simply not familiar with how things work there.)

  • 0 in reply to desouza
    Mastermind 8030 points

    desouza said:
    This will be fixed in a future revision of the schematics and I need to check how this will be communicated to the third party manufacturers.

    I will also post a remark on the XDS100 wiki page for current users.

    More than a year later... no revised schematics or even a note on the XDS100 wiki page. :-/

    BTW, I just noticed the XDS100v3 (revision 2) has the same problem, and the voltage divider workaround is applicable to it also. Unlike the XDS100v2, suspending the device has no effect since the enable-input of the opamp is tied high.

    Also a bit worrying, the XDS100v3 specifies the A3PN125Z as FPGA part, of which the datasheet says "The Z feature grade does not support the enhanced nano features of Schmitt trigger input, cold-sparing, and hot-swap I/O capability." Needless to say this seems rather undesirable to me for a JTAG debugger, although the datasheet is not really specific about the exact implications for its I/O characteristics. Since the Z-grade is currently "not recommended for new designs" and does not appear to be cheaper than the standard grade, I suggest changing the part number to A3PN125.