[hpsdr] Mercury FPGA toast... need chip!

Graham / KE9H KE9H at austin.rr.com
Sun Jan 31 17:32:19 PST 2010


Hi Chris:

Unfortunately, every case of a "shorted 3.3V" supply that I have seen has
been an FPGA with a blown I/O driver.  Pretty much all that the 3.3 V
supplies are the FPGA I/O pins.  This is true for Mercury and Penelope and
Ozy.  The 3.3V regulator is current limiting and self protecting, so its
output will drop down close to ground, and it will run hot, but it is just
protecting itself and the PCB traces.

I don't know of any other source for the parts than Digikey and other
distributors. And as you say, Digikey is quoting several months lead time, 
currently.

I am not aware of any firmware issue that can short an I/O pin driver.

The causes I am aware of are over voltage, like a short to +12V on one
of the FPGA I/O lines, plugging and unplugging the cards while the power
is on, or static electricity due to improper ESD protection/handling.

--- Graham / KE9H

==

Chris Hinkle wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> Hi,
>
> For some reason Mercury's FPGA seems to have an internal short,
> apparently just the 3V3 I/O(led D17 lights briefly when cold), as the
> other 1V2 and 2V5 dummy lights are still lit and the regulators are
> running at normal temps.  I have removed U15 and all else seems to be
> running at normal temps and thankfully, for now, the 2208 appears to
> be OK.
>
> The main problem is acquiring a new chip, all the normal trusted
> outlets (Newark, Digi-key) are showing 90+ day lead times, and I would
> rather not pay for the extra 15K gates of the next available chip.  If
> there is anyone out there that knows where the EP3C25Q240 can be
> purchased or has an extra that I could purchase; I would be highly
> appreciative.
>
> This occurred during the testing of the LPU, the setup ran for ~28
> hours, I left the room for a drink and came back to silence (no
> diagnostic leds lit on either TX or RX.)  The LPU is fine, Ozy appears
> to be operational (is recognized and lodes code) but the FPGA seems to
> be running hot.  I have never had a reason to check the temps of any
> of the large arrays until this happened so I have no reference.  Also
> Penelope's FPGA appears to be suffering the same fate, as the 3V3 reg
> is extremely hot and the FPGA gets extremely hot.  Checked for shorts
> in the passive components and operation of the regulators involved and
> those check good.  I just wanted to throw this out there in case there
> was a possibility that some firmware failure or ... has caused my
> predicament.
>
>
> Thanks for reading,
> Chris
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
>   



 1264987939.0


More information about the Hpsdr mailing list