Quick answer
If a USB-to-serial adapter reports PID 0000, record its exact identity and symptoms before changing its configuration. The identifier can be relevant to a documented historical FT232R-compatible adapter problem, but it does not establish the cause of every current failure or prove that a chip is counterfeit.
Start with non-destructive checks. Consider recovery only when you can identify the hardware and obtain a suitable documented procedure. If its provenance or expected configuration cannot be established, a dependable replacement is usually the more practical choice.
This is USB-to-serial adapter troubleshooting. It is separate from restoring MiniPwner router firmware.
What PID 0000 tells you
USB devices report vendor and product identifiers that help the operating system select a driver. Linux's FTDI serial-driver ID definitions include FTDI's vendor ID 0403 and multiple product identifiers. PID 6001 is common for FT232R-compatible devices; it is not correct for every FTDI product or board.
A device reporting 0403:0000 may not match the expected driver configuration. That does not mean the USB device is electrically dead. Conversely, a familiar identifier does not establish genuine hardware, correct wiring or a working serial interface.
A missing serial port is a symptom with several possible causes, including driver configuration, cabling, hardware faults and device permissions. Do not infer a particular cause from the absence of a COM port alone.
Why the old MiniPwner resource mattered
MiniPwner's historical /index.php/unbrickftdi000 resource addressed an adapter-recovery problem that affected electronics projects beyond MiniPwner.
In his February 2015 account, Peter Scargill linked to that resource, described seeing PID 0000 with Linux's lsusb, and reported restoring his adapter using a historical Linux utility. His account associated the problem with the driver behaviour reported on counterfeit-compatible chips at the time.
That is one person's historical recovery report, not an Impulsec test or a guarantee for another board. It does not establish that current drivers behave the same way. This article preserves the troubleshooting subject; it does not claim to reproduce the original page word for word.
For project context, see our MiniPwner history and safe lab guide.
Check the adapter without rewriting it
Separate the adapter from the target
Disconnect the target-side serial leads and any target power connection before inspecting the USB adapter on its own. Record the board name, chip markings, supplier documentation and stated signal levels.
A board label or marketplace description alone may not establish authenticity. The purpose of recording it is to identify the right documentation and avoid applying instructions for a different component.
Check the USB connection
Use a known working data cable and another suitable USB port. If practical, remove an intermediate hub from the test. Note whether the adapter appears consistently or repeatedly disconnects.
If the computer does not enumerate a USB device at all, do not jump to an EEPROM rewrite. A cable, connector, power or hardware problem needs consideration first.
Read the reported identifiers
On Linux, this command lists USB devices without programming the adapter:
lsusb
Find the entry corresponding to the adapter and record its vendor/product pair. An example such as 0403:0000 illustrates the format; it is not a result measured by Impulsec.
On Windows, locate the device in Device Manager, open its properties, and inspect Hardware Ids on the Details tab. Also record any error and the driver status. Exact labels can vary with Windows version and device state.
Compare what the computer reports with documentation for that particular board. Do not assume that another adapter's expected PID is appropriate.
Match the next action to the symptom
| Observation | Possible explanation | Useful next check |
|---|---|---|
| No USB device appears | Cable, port, connector, power or hardware fault | Check the physical connection and whether another system enumerates it |
| The adapter reports PID 0000 | Unexpected configuration or the specific historical fault pattern | Identify the chip and its documented expected configuration |
| Expected IDs appear but no serial port is available | Driver, permissions, configuration or OS compatibility issue | Check the supported driver and the actual system error |
| A serial port appears but communication fails | Wiring, signal levels, port settings, target state or adapter fault | Verify the documented electrical and serial requirements |
These are diagnostic possibilities, not conclusions from a laboratory test. Rewriting a PID is not a general solution to all four cases.
Recovery options and their limits
FTDI publishes FT_PROG, an EEPROM-programming utility, and a manufacturer user guide. Use the documentation applicable to the exact supported device. A configuration utility is not evidence that every zero-PID adapter or clone can be discovered and repaired.
Historical accounts also describe ft232r_prog on Linux. Their outcomes concern particular adapters and software environments. A surviving old command or download reference does not establish a trustworthy current binary or compatibility with your hardware.
Before a documented configuration change:
- Confirm the exact chip and the expected configuration from its own documentation.
- Connect only the adapter you intend to inspect or change.
- Record the existing configuration and save a recoverable copy where the supported tool permits it.
- Check which settings a procedure will change and stop if it does not match your device.
This guide does not supply a universal EEPROM-write command. Erasing configuration or copying another board's settings can cause additional problems. Do not install an obsolete or unsigned driver solely to make an unidentified adapter resemble a different device.
If identification or a suitable procedure remains uncertain, seek the board supplier's guidance or replace the adapter.
Choose a suitable replacement
Select an adapter with documented provenance and requirements that match the target. Check:
- Required logic levels and the adapter's actual signalling specification.
- Whether the target requires TTL-level UART or an RS-232 interface.
- Pinout, connector and grounding requirements.
- How the target and adapter are powered.
- Driver support for your operating system.
A selectable power-output voltage does not necessarily establish the UART signal voltage. Verify both in the board documentation. FTDI, CP210x and CH340-family products are not automatically interchangeable or pin-compatible.
For supported FTDI hardware, consult the manufacturer's VCP driver page. A different chip family needs its own applicable driver guidance.
For the router and storage requirements behind these serial connections, see our historical MiniPwner build guide. Our OpenWrt troubleshooting guide covers separate filesystem and package issues.
Verify the result before reconnecting
After a documented recovery or replacement, reconnect the adapter to USB and inspect the identifiers and driver status again. Confirm that the expected serial interface is available.
Only then reconnect a target whose voltage, pinout and power arrangements have been verified. Test communication using the target's documented serial settings. Enumeration alone does not prove that every function works, and a restored serial adapter does not prove that router firmware has been repaired.
Decide from the evidence you actually have
PID 0000 is a reason to investigate identification and configuration, not a complete diagnosis. Preserve the existing state, identify the hardware, and use an applicable recovery procedure only when those prerequisites are satisfied.
Replacement is a sensible outcome when undocumented hardware prevents a dependable repair. A recognised adapter with a supported driver and correct electrical requirements is more useful than a guessed configuration that merely produces a familiar USB ID.
Frequently asked questions
Does PID 0000 prove a chip is counterfeit?
No. It reports an identifier, not authenticity. Historical reports describe a particular driver-related problem, but the cause of your adapter's state still needs investigation.
Should every affected adapter be changed to PID 6001?
No. Expected IDs depend on the chip and board. Use the specific device documentation rather than assuming another product's value is correct.
Will repairing the adapter unbrick a MiniPwner router?
It may restore an affected serial connection. Router firmware recovery is a separate, model-specific process, and an adapter repair does not establish that it is complete.
Related Articles
Share this article
Stuart Kerr Spindlow is Impulsec’s Publisher, Chief Editor and Lead Reviewer. He writes and maintains coverage of consumer cybersecurity and digital-safety software, with a focus on practical suitability, limitations and the evidence behind product claims. Read Stuart’s full profile.