Recovering a card that will not enumerate
What bricked really means for an FPGA card. Why a bad bitstream is almost always recoverable over JTAG, and the narrow set of cases where a board is genuinely dead.
Short answer
A card that stops enumerating after a flash is almost never dead silicon. At power-on the FPGA loads its bitstream from SPI flash. A bad image means configuration never completes, so no PCIe endpoint appears. But JTAG does not depend on what is in the flash, so the fix is almost always a reflash.
On this page10
What bricked means here
In this stack the word usually describes a symptom, not a diagnosis. The card no longer appears as a PCIe device, so nothing downstream works. That symptom has one common cause and several rare ones. The common cause is a flash holding an image the FPGA cannot successfully configure from. That leaves the device unconfigured, and therefore invisible to the host. Unconfigured is not damaged. An unconfigured FPGA is a chip waiting for a valid bitstream, and supplying one is a normal operation.
The power-on sequence, and where it stops
Five stages. Knowing which one you failed at tells you whether this is a flash problem, a seating problem or a hardware problem.
- 1. Slot power
- The card draws power from the PCIe slot. No power means no LEDs and nothing else happens
- 2. Configuration
- The FPGA reads the SPI flash and loads the bitstream. A corrupt or partial image fails here
- 3. Done
- Configuration completes and the design starts running. Until this point there is no PCIe endpoint
- 4. Link training
- The PCIe link negotiates with the host. A configured card that never trains is a seating or slot issue
- 5. Enumeration
- The host reads configuration space and the device appears. This is the first stage anything in Windows can see
Why JTAG survives a bad bitstream
JTAG is a test and debug interface implemented in the silicon itself. It comes up with the chip. It does not care what configuration mode the board is strapped for, and it does not care what is sitting in the flash. That is the property the whole recovery path rests on. The FPGA can be completely unable to configure and still be reachable over JTAG. In practice the tool loads a small helper bitstream into the FPGA over JTAG. That helper gives it a path to the SPI flash, so the flash can be rewritten. The card being invisible on the PCIe side has no bearing on any of it.
The recovery path
This is the ordinary flashing procedure, not a special mode. If you were able to flash the card once, you can flash it again.
- Shut the game PC down fully and confirm the card is properly seated, then power it back on
- Move the USB cable to the card's JTAG port and into a rear USB port on the second PC
- Close everything that might hold the USB device — reader software, MemProcFS, any other flash tool
- Open the flash tool and confirm it can see the device and open the JTAG chain before you select a file
- Select the FPGA part that matches the silicon on the board
- Flash a known-good image for this exact board and this DNA ID, with the format set to BIN
- Let it run to completion without touching the machine
- Cold-boot the game PC, move the cable to the data port and re-run a connection test
Reading the symptom
The useful question is not whether the card is bricked, it is which stage of the power-on sequence it reached. These rows map symptoms to stages.
| Symptom | Likely cause | Fix |
|---|---|---|
| No LEDs at all with the game PC powered on | Stage 1. No slot power: not seated, dead slot, or genuine board damage | Reseat in a different PCIe slot with the machine fully off. If there is still no light in a known-good slot, this is one of the few genuine hardware cases |
| LEDs on, but no device anywhere in the host | Stage 2. The FPGA never configured, which means the flash content is bad or incomplete | Reflash a known-good image over JTAG. This is the common case and it is recoverable |
| The flash tool cannot open the JTAG chain | Wrong port, missing CH347 driver, a process holding the device, or the wrong part selected | JTAG port, install the driver, close other tools, run as Administrator, and select the correct part. Chain access is independent of flash contents, so this is not a brick |
| Device appears but as the wrong thing, or with an error code | Stage 5. Configuration succeeded, so the image is running — it is simply not the image you wanted | Confirm you flashed the file issued for this board, then reflash the correct one. The card is healthy |
| Flash completes, card still invisible after a cold boot | The image does not match this board or this DNA ID | Check the filename against your order and confirm the FPGA class. Send support the tool output rather than reflashing the same file a fourth time |
| Worked yesterday, nothing today, no flash in between | Almost never firmware. Usually the slot, the cable, the USB port or a hung card | Full shutdown of the game PC for ten seconds, then a cold boot. Then reseat, then swap the cable. Reflashing is not the first move here |
When a card genuinely is dead
It happens, and it looks different. Physical damage is the usual cause. A bent PCIe finger, a torn USB-C socket, a scorched component, or a board that was hot-seated into a powered slot. The signature is failure at stage 1 rather than stage 2. Either no LEDs in a slot you have proven works with another card, or a JTAG chain you cannot open. That second case counts only with the correct driver, correct port and correct part selection, on a card that is definitely powered. Corrupt flash content does not produce those symptoms.
Before you declare a card dead
Seven things. Most reported bricks stop being bricks somewhere in this list.
- Game PC fully shut down for ten seconds, then cold-booted — not restarted
- Card reseated with the retention clip closed and the bracket flush
- Tried in a second PCIe slot
- Cable swapped for a known data-rated one, into a rear USB port with no hub in the path
- Confirmed you are on the JTAG port for flashing and the data port for reading
- CH347 or WCH driver installed, with reader software and MemProcFS closed
- One clean reflash attempt of the correct image, allowed to finish without interruption
Tip
What to send support
State which stage you reached, in the terms above. Whether the LEDs light. Whether the flash tool can open the JTAG chain. The exact filename you flashed and the part you selected. The full tool output, pasted rather than summarised. A photo of the board including the silkscreen and the FPGA marking. Your order ID. That set is usually enough to answer the question in one reply instead of five.
Recovery questions
Did I destroy the FPGA by flashing the wrong image?
Almost certainly not. Writing a bad image leaves the FPGA unable to configure, which reads as a missing device. The silicon is untouched and JTAG is still reachable.
Does the card need to be in the game PC to be recovered?
It needs power. On most boards that means seated in the game PC with the game PC on. Some boards can take power from the flashing port alone — follow your board's documentation.
Can I recover it without JTAG?
Not practically. The PCIe path is unavailable precisely because configuration failed, so JTAG is the way in. That is why the flashing port exists as a separate socket.
Will a recovery flash need a new DNA read?
No. The DNA is in eFUSE and unaffected by anything you write to flash, so the image you already own still matches the board.
The tool says success every time and the card still does not appear. What now?
Stop reflashing. A successful write of an image built for a different board or DNA behaves exactly like this. Verify the file against your order and take the tool output to support.
Sources
The stage map and the symptom rows are ours. They come from cards that stopped working on our bench and in tickets.
- 01AMD/Xilinx UG910, Vivado Design Suite User Guide: Getting Started
programming a device and its configuration flash over JTAG, the path the whole recovery rests on
docs.amd.com
Read next
Still stuck? Open a ticket on Discord
All guides