logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

Alcor Micro VID 058F PID 6387 USB Flash Repair with AlcorMP Tool – AU698x Controller Firmware

User question

I need software for this flash

Artificial Intelligence Response

Direct answer to the question

  • Use the Alcor Micro Mass Production utility (AlcorMP) to repair/reinitialize a USB flash drive identified as VID 058F, PID 6387 (Alcor controller).
  • Key points:
    • Identify the exact controller (e.g., AU698x/AU699x) and NAND ID first.
    • Choose an AlcorMP version that matches your controller/NAND.
    • The MP process will erase all data and will set the true physical capacity (may be less than 128 GB on counterfeits).
    • Validate the result with a full-capacity test (H2testw/F3).

Detailed problem analysis

  • Why AlcorMP: Alcor controllers store firmware, timing, and Flash Translation Layer (FTL) parameters internally. Corruption, bad-block growth, or fake-capacity programming causes write/read failures and “write-protected” states. AlcorMP can:
    • Re-detect NAND type and CE configuration.
    • Rebuild the bad-block map.
    • Recreate the FTL and repartition.
    • Program correct VID/PID and device strings.
  • What must match:
    • Controller family/revision (e.g., AU6989SN-GT, AU6998).
    • NAND characteristics (vendor, die count, interleave, page/block size, TLC/MLC/QLC).
    • Some tool builds (U2/U3 lines and specific versions) include NAND tables supporting only certain Flash IDs. Mismatch yields “No Support Flash” or “Init Fail”.

Current information and trends

  • AlcorMP releases come in series (commonly 13.xx, 14.xx, 15.xx, 19.xx). Newer builds broaden support for newer AU698x/AU699x and 3D TLC NAND, but older sticks sometimes work only with earlier builds. It’s normal to try 2–3 adjacent versions to find one that recognizes your NAND.
  • Increasing numbers of “128 GB” drives are reprogrammed fakes. After a proper MP, capacity often drops to the real size (e.g., 8–64 GB). This is expected and indicates the controller is now correctly mapped.

Supporting explanations and details

  • Terminology
    • FTL (Flash Translation Layer): Maps logical sectors to physical NAND pages/blocks while managing wear-leveling and bad blocks.
    • NAND ID/Flash ID: JEDEC-like code read from the NAND that determines vendor and geometry.
    • CE/Interleave: Number of chip enables and parallelism lanes; affects timing and performance.
  • Typical messages
    • “No Support Flash”: The loaded NAND table doesn’t include your Flash ID; try a different AlcorMP version.
    • “Read DCR/Init Fail”: Power/USB signal quality issue, or incorrect timing; use a short cable and a motherboard port.

Ethical and legal aspects

  • The MP process voids typical retail warranty and wipes all data.
  • Use trusted sources for tools to avoid malware; MP utilities are OEM-oriented and not officially distributed to end users.
  • Do not reprogram drives to misreport capacity; that is deceptive and can cause data loss for others.

Practical guidelines

  • Before you start (data first)
    • If you need files, attempt data recovery before any MP action. Imaging tools: ddrescue (Linux) or hardware imagers; logical recovery: R‑Studio, DMDE. MP will irreversibly erase.
  • Step-by-step repair workflow
    1. Identify hardware
      • Run ChipGenius or Flash Drive Information Extractor.
      • Record: Controller PN (e.g., AU6989SN), firmware string (e.g., FA00), Flash ID (hex), reported VID/PID (058F/6387).
    2. Obtain AlcorMP versions
      • Acquire 2–3 nearby versions known to support AU698x/AU699x (for example a mid 14.xx and a later 15.xx/19.xx build). Use reputable community repositories.
    3. Prepare environment
      • Windows PC with admin rights; plug directly into a rear motherboard USB port (no hubs).
      • Close other USB storage operations; ensure stable power.
    4. Configure AlcorMP
      • Open settings; set VID=058F, PID=6387; single removable LUN; one public partition.
      • Enable Full Scan/Capacity Optimize; Auto-detect NAND where available.
      • Leave passwords at default if prompted; do not alter advanced timings unless necessary.
    5. Run process
      • Start low-level format; allow full bad-block scan and FTL build to finish.
      • On errors, try the next AlcorMP version; re-read Flash ID each time to confirm recognition.
    6. Verify outcome
      • Replug the drive; quick format NTFS or exFAT.
      • Run H2testw (Windows) or F3write/F3read (macOS/Linux) across 100% of capacity. Expect 0 errors on a stable result.
  • Troubleshooting
    • Persistent “write protect”: Some sticks require a special flag clear; use the same AlcorMP version that recognizes your NAND and enable “Clear Write Protect/Force MP”.
    • Capacity unexpectedly small: This reflects true NAND size on fake-capacity products; this is normal after a correct MP.
    • Device drops during scan: Try a different USB port, shorter cable, or a powered USB add-in card.

Possible disclaimers or additional notes

  • Success is not guaranteed; severely worn or mismatched NAND, or damaged PCBs, will fail MP.
  • Cross-flashing with the wrong MP build can brick the controller until power-cycled; always proceed incrementally and note original parameters.
  • Antivirus may flag MP tools because of driver components; verify hashes and scan with multiple engines.

Suggestions for further research

  • Share these details and I can pick an exact AlcorMP build and provide a ready .ini:
    • Controller PN/revision, firmware string, Flash ID, number of CE/dies (if shown), and any current error messages.
  • If MP fails across versions, consider:
    • Dumping the NAND via a programmer (e.g., RT809H/TL866 + TSOP adapters) for chip-off analysis.
    • Evaluating solder quality and connector integrity under magnification; intermittent VBUS/D+ can mimic NAND faults.

Brief summary

  • For an Alcor-based USB flash drive with VID 058F, PID 6387, the correct software is AlcorMP. Identify the exact controller and NAND first, choose a matching AlcorMP version, run a full MP/low-level format to rebuild the FTL, and validate with H2testw/F3. Expect true capacity to be enforced after repair, which may be lower on counterfeit or degraded media.

If you provide the ChipGenius/FDIE readout (controller model, Flash ID, firmware code), I’ll recommend the specific AlcorMP version and supply a step-by-step configuration for your unit.

User question

recupero usb VID 058F / PID 6387

Artificial Intelligence Response

Direct answer to the question

  • Your USB device with VID 058F / PID 6387 uses an Alcor Micro controller. The correct repair path is to reinitialize it with the Alcor Mass‑Production utility (AlcorMP). This rebuilds the controller’s firmware tables (FTL) and can restore the stick to working order, but it erases all data.
  • First, identify the exact controller part (e.g., AU6989SN, AU6998, FA00 family) and the NAND Flash ID with a detector (ChipGenius or Flash Drive Information Extractor). Then use a matching AlcorMP version and run a full, low‑level “MP” format.

Key points

  • VID/PID alone are not enough; controller revision and NAND ID determine the right AlcorMP version and settings.
  • Use recent AlcorMP that supports your controller/NAND; enable Full Scan and Auto‑detect NAND; set 058F/6387; single public partition.
  • Validate the result with H2testw (Windows) or F3 (macOS/Linux).
  • If you need the data, stop and consult a lab—MP will destroy it.

Detailed problem analysis

  • What VID 058F / PID 6387 means
    • 058F is Alcor Micro’s USB Vendor ID. 6387 is a common Product ID seen on multiple Alcor UFD controllers (often AU698x/AU699x or the FA00 family). Because multiple controller revisions can share the same VID/PID, you must read the internal controller string (e.g., AU6989SN-GT, firmware tag like FA00/FB00) and the NAND Flash ID.
  • Why identification is mandatory
    • AlcorMP embeds NAND “tables” (timings, ECC, die/topology profiles). A mismatch causes “Flash Not Support,” capacity errors, or unstable media. Different AlcorMP builds target different controller families and NAND generations (planar MLC/TLC vs. 3D TLC/QLC).
  • Tools and information to collect (from ChipGenius or Flash Drive Information Extractor)
    • Controller: exact string (e.g., AU6989SN, AU6998, AU6983).
    • Firmware/ROM tag: FA00/FB00/etc. plus version string.
    • Flash ID: hex bytes (e.g., 98 3A 98 A3 …) identifying vendor/density.
    • Reported capacity and any write‑protect flag.
  • Version selection logic (typical, based on field experience)
    • AU6983/AU6986 (older): AlcorMP 13.xx–14.xx often works.
    • AU6989 (very common): AlcorMP 14.xx–16.xx frequently fit; newer NAND may need 17.xx+.
    • AU6998/AU6990 (newer): AlcorMP 15.xx–19/20.xx, depending on NAND (3D TLC/QLC).
    • FA00 family: choose AlcorMP builds whose Setting.ini/Release notes explicitly list FA00 support (commonly mid‑16.xx+ and later).
  • What the MP process does
    • Puts the controller in manufacturing mode, interrogates NAND dies, maps bad blocks, selects ECC parameters, creates the Flash Translation Layer (FTL), then exposes a logical LUN with the requested file system layout.

Current information and trends

  • Recent Alcor controllers ship with 3D TLC or even QLC NAND. Successful repair increasingly depends on using AlcorMP builds with updated NAND tables (later 16.xx through 19/20.xx). Older tools may initialize the drive but yield low performance or instability.
  • Many consumer sticks with issues are counterfeit-capacity devices; after MP they show the true, smaller capacity. This is expected and indicates the FTL now matches physical NAND.

Supporting explanations and details

  • Recommended workflow (precise)

    1. Detect:
      • Plug the stick into a native USB 2.0 port on the back panel (avoid hubs/adapters).
      • Run ChipGenius or Flash Drive Information Extractor as Administrator.
      • Copy these lines: Controller, Firmware/ROM tag, Flash ID, VID/PID.
    2. Choose AlcorMP:
      • Pick a build matching your controller/NAND generation (per logic above).
      • Verify the package includes the UFD executable and a Setting.ini mentioning your controller family or FA00 if applicable.
    3. Prepare Windows:
      • Close all apps that may access USB storage.
      • Disable USB Selective Suspend temporarily (optional) to avoid power dips.
      • On some systems, accept/allow the unsigned filter driver the tool installs.
    4. Configure AlcorMP (Setup → All):
      • VID: 058F; PID: 6387.
      • Device Mode: Removable Disk.
      • LUN: Single, Public Partition only.
      • Flash Type: Auto Detect (enable Full Scan/Full Scan 4).
      • Options: Capacity Optimize; Clear Write Protect; Force MP if needed.
      • Filesystem: FAT32 for ≤32 GB; exFAT for larger (you can reformat later).
    5. Execute:
      • Start MP/Low Level Format; allow 5–30 minutes depending on capacity/USB speed.
      • Expect “PASS” in green. If “FAIL,” note the error code (see below).
    6. Post‑process:
      • Replug; if Windows asks to format, do a quick format in exFAT or NTFS.
      • Verify real capacity and integrity with H2testw (Windows) or F3 (macOS/Linux). Write/verify 100% capacity.
  • Minimal parameter set you can mirror in your Setting.ini (conceptually)

    • [USB] VID=058F, PID=6387
    • [Mode] Removable=1, PublicPartitions=1
    • [Scan] AutoDetect=1, FullScanLevel=4, CapacityOptimize=1
    • [Protect] ClearWP=1, ForceMP=1
  • Frequent errors and engineering‑level causes

    • “Flash Not Support”: AlcorMP build lacks NAND table for your Flash ID. Solution: try a newer/different build.
    • “Bad Block Exceeded” / very low capacity: NAND is worn/damaged; MP may down‑bin capacity or fail.
    • “Check CTL/CE Fail” / “Init Fail”: signal integrity or NAND interface issue; can also occur if the controller is stuck in ROM mode. Try another port/cable/PC; if persistent, hardware fault is likely.
    • “Write Protect”: enable ClearWP/ForceMP; if still locked, controller may have permanent WP due to media failure.

Ethical and legal aspects

  • Using factory MP tools may void warranty and will erase data irreversibly.
  • Some MP packages include unsigned drivers; ensure you trust the source, scan for malware, and comply with local software licensing.
  • If personal or regulated data is on the stick, consider secure erasure requirements before disposal or RMA.

Practical guidelines

  • Best practices
    • Always attempt data recovery first if data matters; MP is a last resort for functionality, not recovery.
    • Use a desktop’s rear USB 2.0 port; avoid front panels/hubs.
    • Test the entire capacity after repair (H2testw/F3). Keep the log as proof of health.
  • Potential challenges and how to overcome them
    • Tool doesn’t see the device: try a different PC/OS, disable aggressive antivirus, or plug directly. Some devices require hot‑plug after starting MP.
    • Multiple AlcorMP versions needed: systematically try 14.xx → 16.xx → 18/19/20.xx following your controller generation.
    • Persistent failures: the NAND may be at end‑of‑life or the controller ROM damaged; replacement is more economical than further attempts.

Possible disclaimers or additional notes

  • Not all devices are recoverable. Severe NAND degradation, counterfeit controllers, or ROM defects can make MP ineffective.
  • Reported capacity after MP may be lower than the label; this is normal when the original capacity was faked or when spare blocks are consumed by remapping.

Suggestions for further research

  • Community knowledge bases and forums dedicated to USB controller repair (search for “AlcorMP FA00 AU6989” and “Alcor AU6998 MP”).
  • Whitepapers on Flash Translation Layers, NAND endurance, and ECC strategies to understand why capacity may change after MP.
  • Tool repositories that archive historical and recent AlcorMP versions.

Brief summary

  • Your 058F:6387 stick is Alcor‑based; repair is done with AlcorMP, but only after correctly identifying the controller revision and NAND Flash ID.
  • Choose an AlcorMP version that matches your controller/NAND, run a full MP with Auto‑detect and Full Scan, then validate with H2testw/F3.
  • Expect total data loss during MP; if recovery is the goal, stop and use a data recovery service instead.

If you want precise, pre‑tuned settings, please paste the full ChipGenius (or FDIE) report—Controller line, Firmware/ROM tag, and Flash ID—and I will map it to a specific AlcorMP build and parameter set.

User question

Description: [E:]USB Mass Storage Device(Generic USB Flash Disk) Device Type: Mass Storage Device Protocal Version: USB 2.00 Current Speed: High Speed Max Current: 100mA USB Device ID: VID = 058F PID = 1234 Device Vendor: Alcor Micro Device Name: Mass Storage Device Device Revision: 0001 Manufacturer: Generic Product Model: USB Flash Disk Product Revision: 7.76 Controller Vendor: Alcor Micro Controller Part-Number: Unknown [FA00] - F/W 82C4 Flash ID code: 2CC30832EA30 - Micron - 1CE/Single Channel [TLC] -> Total Capacity = 1GB Tools on web: http://dl.mydigit.net/special/up/alcor.html Possible Flash Part-Number ---------------------------- Unknown Flash ID mapping table ---------------------------- [Channel 0] [Channel 1] 2CC30832EA30 -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- --------

Artificial Intelligence Response

Direct answer to the question

  • Your stick is an Alcor Micro FA00-family controller (very often AU6989SN variant) with Micron TLC NAND (Flash ID 2C C3 08 32 EA 30), single CE/channel, real capacity ≈1 GB.
  • Repair/reinitialize it with the Alcor Mass Production (AlcorMP/UFD MP) utility build that supports FA00 and Micron TLC. In practice, the most reliable bracket for FA00 is AlcorMP UFD 14.xx → 16.xx (try 14.04.x, 15.09.x, 16.09–16.11). If one build fails with “Flash Not Support,” step one version up/down until it recognizes your Flash ID.
  • The current PID 1234 typically means factory/diagnostic or corrupted firmware mode. After a successful MP, set a normal Alcor PID (commonly 6387) and confirm VID/PID = 058F:6387.

Key points

  • Expect complete data loss; do any data recovery first.
  • Use a native USB 2.0 port on the motherboard; avoid hubs.
  • In AlcorMP: Auto-detect NAND, Full Scan Level 4, Capacity Optimize, Clear Write Protect, Force MP; 1 LUN, 100% public.
  • Verify the result with H2testw (Windows) or F3 (Linux/macOS). A healthy outcome is ~0.95–1.0 GB, 0 errors.

Detailed problem analysis

  • Controller and firmware

    • FA00 identifies an Alcor UFD controller family; in field repairs this maps most often to AU6989SN/SNL/SN-GT revisions. Your firmware label 82C4 is a controller microcode build; MP will either preserve it or replace it with a compatible bundle shipped in the tool package.
    • PID 1234 is characteristic of pre-initialized/test mode or a device whose FTL (Flash Translation Layer) metadata is corrupted. That state is exactly what AlcorMP expects to take control and reprogram.
  • NAND flash device

    • Flash ID 2C C3 08 32 EA 30 decodes as Micron TLC (2C = Micron). ChipGenius shows 1CE/Single Channel and “Total Capacity = 1GB,” which matches an 8 Gbit (≈1 GB) die configured for a low-end, single-channel controller.
    • Being TLC on a small die and single channel means modest performance and limited endurance. If the tool reports “Bad Blocks > Limit,” the die may be worn-out beyond usable mapping.
  • Why MP is needed

    • The FTL and bad-block tables live in reserved NAND pages. Power-loss, fake-capacity tampering, or wear can corrupt them, leading to symptoms such as 0 MB size, write-protect, or sporadic I/O errors. MP rebuilds: NAND characterization, bad-block map, ECC parameters, FTL layout, partitions, and USB descriptors (VID/PID/product strings).
  • Version selection rationale

    • FA00-era controllers are best handled by mid-generation AlcorMP (14–16 series). Too old lacks newer NAND tables; too new can sometimes drop legacy support or change driver behavior on modern Windows.
    • Micron TLC tables for C3h families are included in many 15.xx/16.xx builds; if a given build shows “Flash Not Support,” try the adjacent build. It is normal to test 2–3 packages before finding the one with the right NAND database and timing set.

Current information and trends

  • Windows 10/11 driver signing increasingly blocks older MP filter drivers. Workarounds: run as Administrator, temporarily disable AV, and if needed use a Windows 7/8.1 machine or a Win7 VM with USB 2.0 passthrough to ensure stable enumeration.
  • Fake-capacity drives remain common; MP will force the stick to its physical capacity (≈1 GB in your case). Post-MP capacity lower than the shell label is expected and correct.
  • Community-maintained tool bundles tend to cycle; if one mirror is stale, look for another repository of AlcorMP UFD 14–16 packages. Always verify hashes and scan downloads.

Supporting explanations and details

  • Recommended AlcorMP configuration (FA00 + Micron TLC)

    • Device/Info:
    • VID: 058F
    • PID: 6387 (recommended retail PID) or leave 1234 during bring-up and change to 6387 in final pass
    • Removable Disk, LUNs: 1, Product string optional (e.g., “USB Flash Disk”)
    • Flash/NAND:
    • Auto Detect NAND: enabled
    • Full Scan / Scan Level: Level 4 (deep scan) to map weak/bad blocks
    • Capacity Optimize: enabled
    • ECC/Timing: Auto (do not force unless directed by a known-good INI)
    • Protection/Advanced:
    • Clear Write Protect: enabled
    • Force MP (or Force Low-Level): enabled
    • Uninstall driver on exit: optional, helps if driver conflicts reappear
    • Partitioning:
    • Public: 100%
    • FS: FAT32 (1 GB is fine); you can also leave Unformatted and format in OS later
  • Execution flow

    • Start MP: device enumerates, controller handshake, NAND ID readout, table lookup
    • Characterization: page/block size, timing set, BBM (bad block management)
    • FTL build and low-level format, partition creation, descriptor write
    • Re-enumeration: device comes back with final VID/PID; OS may prompt to format
  • Target checks after MP

    • Device Manager → Hardware IDs should show USB\VID_058F&PID_6387 (or your chosen PID).
    • Disk Management: ~0.95–1.0 GB healthy partition; quick format FAT32 if needed.
    • Integrity test: H2testw or F3 must complete with 0 errors; any verification error points to marginal NAND.
  • Typical error codes and remedies

    • Flash Not Support / Unknown Flash: use a different AlcorMP build (adjacent version).
    • CTL/Init Fail: change to a rear-panel USB 2.0 port; avoid hubs; try another PC; ensure no loose connector.
    • Write Protect: ensure ClearWP is set; power-cycle and rerun; persistent WP often indicates worn-out NAND or controller latch failure.
    • Bad Blocks > Limit: too many BBs; try Capacity Optimize; if still failing, the die is at end-of-life.

Ethical and legal aspects

  • MP tools are factory utilities; distribution can be restricted by licensing. Use them for repair of your own hardware and respect local laws and any remaining warranty terms.
  • All data will be irretrievably erased; if data recovery is needed, do that first (chip-off or professional services). Running MP first will reduce recovery chances to near zero.
  • Download only from reputable archives, verify checksums, and scan for malware.

Practical guidelines

  • Environment and setup

    • Prefer Windows 7/10 on a desktop machine with native USB 2.0 ports.
    • Close other storage utilities; temporarily disable AV if it interferes with unsigned drivers.
    • If Windows 11 blocks the driver, try compatibility mode or a Win7 VM with USB 2.0 passthrough.
  • Step-by-step summary

    • Acquire 2–3 AlcorMP UFD packages spanning 14.xx, 15.xx, 16.xx.
    • Run AlcorMP as Administrator; connect the stick to a rear USB 2.0 port.
    • Configure as above (Auto Detect, Full Scan 4, Capacity Optimize, ClearWP).
    • Start; wait 5–15 minutes. On PASS, unplug/replug.
    • Format FAT32; run H2testw/F3 for full-capacity verify.
  • What success looks like

    • Stable detection as 058F:6387, capacity ≈1 GB, zero verify errors.
  • What failure looks like

    • Repeated “Unknown Flash” across several MP versions (wrong family or rare NAND).
    • “Bad Blocks > Limit” even with Capacity Optimize (NAND worn/damaged).
    • Persistent write-protect despite ClearWP (controller fault).

Possible disclaimers or additional notes

  • The FA00 family spans multiple silicon spins; an exact AU6989SN variant is likely but not guaranteed. That’s why testing a small range of MP versions is standard practice.
  • The firmware label 82C4 may change after MP; that is normal if the tool bundles a newer microcode for your controller.
  • Very small TLC dies can be more fragile; if the stick passes H2testw today but later shows new errors, retire it from important use.

Suggestions for further research

  • Look up community repair threads for “Alcor FA00” and “AU6989SN” with Micron C3h TLC IDs for version-to-ID matches and known-good Setting.ini examples.
  • If you capture AlcorMP logs (often saved in the tool’s Log subfolder), compare the selected timing/ECC set across versions to understand why one build works and another doesn’t.
  • For persistent failures with important data, consult professional data recovery focused on Alcor controllers; they use vendor-specific readers and custom FTL reconstruction.

Brief summary

  • Your device is an Alcor FA00-class USB controller with a Micron TLC 1 GB die. Rebuild it using AlcorMP (best odds with 14–16 series), configured for Auto NAND detect, Full Scan Level 4, Capacity Optimize, and Clear Write Protect. Finish by setting a normal PID (e.g., 6387) and verifying integrity with H2testw/F3. If multiple adjacent MP versions cannot recognize the NAND or if bad blocks exceed limits, the flash is likely worn out and the stick should be replaced.

Disclaimer: The responses provided by artificial intelligence (language model) may be inaccurate and misleading. Elektroda is not responsible for the accuracy, reliability, or completeness of the presented information. All responses should be verified by the user.