logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
Build faster with M5Stack »
Build faster with M5Stack » Stick • Unit • Cardputer
ADVERTISEMENT
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

Solid State Systems SSS6692-BE, Toshiba 983C98B37672 NAND, GoodRam 32GB USB: Controller & Recovery

Ask a question on the Forum

User question

Solid State Systems 0xBE
983C98B37672

Artificial Intelligence Response

Direct answer to the question

• “Solid State Systems 0xBE” is the internal (Mass-Production-Tool) code for an SSS6692-BE USB-flash-drive controller made by Solid State Systems Inc.
• “983C98B37672” is the 6-byte NAND Flash ID that decodes to a Toshiba / KIOXIA 128 Gbit (16 GB per die) TLC/MLC Toggle-DDR NAND device (part family TC58TFG8T2x / TC58NC66xx).
• Together they describe the exact controller/flash pairing typically found in 32 GB GoodRam or other OEM pendrives.

Key points
– Controller: SSS6692-BE (USB 2.0/USB 3.0, UFD class, supports 1CE/4CE NAND).
– Flash: Toshiba/KIOXIA, JEDEC manf. code 0x98, 128 Gbit die, 16 K page, Toggle-DDR 1.0/2.0.
– Relevant for firmware repair, low-level formatting, or data-recovery tool selection.

Detailed problem analysis

  1. Controller identification
    • Vendor ID: Solid State Systems (SSS, Taiwan)
    • Family: SSS66xx (2013-2016 generation).
    • MP-tools label the -BE firmware branch simply “0xBE”. Hence ChipGenius/FDI shows:
    “Controller Vendor : Solid State Systems
    Controller Part-Number : Unknown(0xBE)”.
    • Hardware features
    – USB 2.0 High-Speed (some -BE lots also carry internal USB 3.0 PHY but usually routed as HS).
    – 8051-based MCU, integrated ECC engine (BCH 40-bit/1024 B), wear-levelling + FTL.
    – Supports 1–4 CE, Toggle or ONFI 2.x NAND at up to 200 MT/s.

  2. NAND Flash identification (983C98B37672)
    The first byte (0x98) is the standard JEDEC code for Toshiba / KIOXIA.
    A typical Toshiba Toggle-DDR ID layout is
    • 1st byte – Manufacturer (0x98 = Toshiba)
    • 2nd byte – Device, density & organisation (0x3C → 128 Gbit, 2 kB/8 kB/16 kB page families)
    • 3rd-6th bytes – internal revision, voltage, interface, ECC requirement.
    Cross-references in Toshiba datasheets and recovery databases map 98 3C 98 B3 76 72 to
    – TC58TFG8T22/23TA0D (TLC, 16 kB page) or
    – TC58NC6626G6F (MLC, 8 kB page, older lot).
    Two such dies (2 × 128 Gbit = 256 Gbit) give 32 GB user capacity after formatting/over-provision.

  3. Why these codes matter
    • Mass-Production (MP) or Repair tools need both controller code and Flash ID to load an appropriate configuration table (timings, die map, ECC strength, bad-block table format).
    • Firmware corruption, vendor-specific write-protection, or exhausted bad-block reserve will cause symptoms such as “0 MB”, “no media”, or write errors. Selecting a mismatched Flash-table bricks the drive.

  4. Typical failure scenario
    – Drive suddenly shows 8 MB/0 MB → FTL metadata lost.
    – ChipGenius reports SSS 0xBE, FlashID 98 3C … but no capacity.
    – The fix is a low-level re-initialisation with SSS MPTool v2.xx that contains the 98 3C98B3 table.

Current information and trends

• SSS controllers are gradually disappearing from new UFDs; Phison PS2251-xx and SiliconMotion SM328x dominate today.
• KIOXIA’s replacement parts keep the same manufacturer byte (0x98) but move to BiCS4/5 QLC; repair tools therefore need updated flash-tables (>2022 releases).
• Community-maintained databases (usbdev.ru, elektroda.pl) are still the primary source for legacy MPTools because SSS stopped public distribution after 2017.

Supporting explanations and details

• Hex-ID vs Device Name: NAND vendors rarely publish the mapping; reverse-engineering by recovery labs populates public lists.
• Toggle-DDR vs ONFI: Toggle uses DQS strobe similar to SDRAM, giving higher bandwidth on the same 8-bit bus. Controller firmware must match the interface.
• FTL (Flash Translation Layer): Holds logical-to-physical tables, wear counters, and bad-block lists in hidden meta-blocks; when corrupted the controller enumerates but exposes no LUN → “0 MB”.

Example workflow for repair

  1. Read full descriptor with ChipGenius → confirm 0xBE + FlashID.
  2. Download SSS6692 MPTool 2.117_BEx (or closest).
  3. Start under Win7-x86, USB2 root hub, run as Admin, password “1234”.
  4. In Flash tab choose “98 3C 98 B3 76 72 TLC 16K”.
  5. Low-level format → PASS → Windows re-detects 31,5 GB removable.

Ethical and legal aspects

• Mass-production utilities are usually NDA-covered; redistributing them may breach licensing.
• Re-flashing destroys all user data – explicit consent of the owner is mandatory.
• Chip-off recovery involves handling of personal data; GDPR/CCPA rules apply if the data belong to third parties.
• Ensure electrical safety when shorting test-pads to force “Test-Mode”.

Practical guidelines

Implementation
– Prefer a native USB 2.0 port on Intel/AMD root hub (no hubs, no USB-C adapters).
– Disable power-save for USB in BIOS/OS to prevent brown-out during long erase cycles.
Best practices
– Keep two different MPTool versions; if one fails at 10 %, switch to another build.
– After successful low-level format, perform Windows “Full format”, not “Quick”, to force every block write/verify.
Challenges & mitigation
– “Flash ID not supported”: edit *.ini to insert the table or hunt a newer DB file.
– “Too many bad blocks”: the NAND is genuinely worn; drive is scrap.

Possible disclaimers or additional notes

• Drives repaired this way are suitable for non-critical use only; wear-levelling tables start from zero but underlying P/E cycles are already consumed.
• Some GoodRam batches used epoxy-potted COB packages; if the device does not enumerate at all, hardware rework is impractical.

Suggestions for further research

• Investigate open-source FTL alternatives (Open-NAND-Flash-Manager) for legacy controllers.
• Explore FPGA-based universal NAND readers that can auto-reconstruct SSS FTL layouts for chip-off recovery.
• Monitor KIOXIA BiCS6 Flash ID evolution to keep repair databases up-to-date.

Brief summary

“Solid State Systems 0xBE 983C98B37672” uniquely identifies a USB flash drive built around an SSS6692-BE controller and Toshiba/KIOXIA 128 Gbit Toggle-DDR NAND dies. Knowledge of these two codes is essential when selecting a compatible Mass-Production tool for low-level formatting or data-recovery operations. While a firmware re-initialisation can often revive a “dead” 32 GB pendrive, it irretrievably erases existing data and offers no guarantee of long-term reliability.

User question

Solid State Systems SSS6692-BE, Toshiba 983C98B37672 NAND, GoodRam 32GB USB: Controller & Recovery

Artificial Intelligence Response

Direct answer to the question

  • Controller: Solid State Systems (3S/SSS) SSS6692-BE (“0xBE” in many tools).
  • NAND: Toshiba/Kioxia Toggle‑DDR, Flash ID 98 3C 98 B3 76 72 (128 Gbit per die, 16 KB page; usually two dies → 32 GB raw).
  • Recovery: Use an SSS6692‑capable Mass‑Production (MP) utility (3S/SSS MP Utility v2.17x–v2.18x range is typical) and select the flash table that exactly matches ID 98 3C 98 B3 76 72. If data matters, do NOT run MP tools; image/chip‑off first.

Key points

  • “0 MB / write‑protected / please insert a disk” → almost always FTL metadata corruption; MP low‑level re‑init fixes many cases.
  • Choose the tool by controller family (SSS6692), not by brand or NAND alone.
  • The correct flash entry must match the 6‑byte ID; wrong table = mis‑timing, errors, or brick.
  • MP operation is destructive; for data recovery, use professional controller‑level imaging or chip‑off.

Detailed problem analysis

  • Architecture: SSS6692 is a classic 3S USB 2.0 high‑speed controller with an 8051‑class core and an on‑chip BCH ECC engine. It supports Toggle‑DDR NAND and multiple chip enables (CE).

  • NAND ID 98 3C 98 B3 76 72 decodes to a Kioxia/Toshiba 128 Gbit Toggle‑DDR part with 16 KB pages. A common 32 GB build is two 128 Gbit dies. Depending on the PCB, those dies may sit behind one CE (two LUNs) or two CEs (two packages).

  • Failure modes:

    • Logical: Corrupted FTL, exhausted mapping tables, controller WP flag set → device shows 0 MB, RAW, or write‑protected.
    • Physical: Many bad blocks, NAND wear, or marginal timing → MP scan fails or capacity shrinks after re‑init.
    • Electrical: USB PHY/power issues → intermittent enumeration or no VID/PID.

  • Why MP tools help: The MP flow erases, tests, classifies blocks, sets timing, programs firmware params, and rebuilds the translation layer using a per‑ID flash table (page size, planes/LUNs, timings, ECC strength, interleave rules).

Current information and trends

  • Stable practice for SSS6692 remains: identify with ChipGenius/FDIE, then use an SSS6692‑aware MP utility whose database contains the exact 98 3C 98 B3 76 72 table.
  • Tooling drift: Many older 3S tools work best on Windows 7/8 (32‑bit) with a native USB 2.0 root hub. Windows 10/11 x64 and pass‑through via VMs can be unreliable without tuned USB settings.
  • Community archives of MP utilities exist; builds around v2.178–v2.182 commonly include the needed table for this NAND ID. Treat downloads cautiously (see Ethical/legal).

Supporting explanations and details

  • What you should see in identification tools:

    • Controller: “Solid State Systems,” “SSS6692,” or “Unknown (0xBE).”
    • Flash ID: 98 3C 98 B3 76 72.
    • Nominal capacity: ~29–30 GiB after formatting.

  • Geometry notes you typically don’t need to hand‑enter if the table matches:

    • Page: 16 KB + OOB.
    • Planes: usually 2 per die.
    • Dies: 2 dies total for 32 GB assemblies.
    • ECC: controller‑selected (BCH; strength depends on table).
    • Interface: Toggle‑DDR; timing in the table (cycle time ~25 ns typical for this family).

  • Common MP errors and meaning:

    • “Flash ID not supported” → wrong/old tool; get a build with this ID.
    • “Init/Scan fail at block 0” or error 255 → wrong flash table or marginal NAND.
    • “Too many bad blocks” → NAND worn; recovery may pass but reliability is poor.

Ethical and legal aspects

  • MP utilities are intended for OEM production; redistribution is often unofficial. Use at your own risk and scan downloads for malware.
  • Running MP low‑level format irreversibly destroys data; obtain owner consent when applicable.
  • Chip‑off work may implicate privacy/chain‑of‑custody; follow local regulations and lab procedures.

Practical guidelines

Implementation method (destructive repair to make the stick usable)

  1. Confirm identity
    • Use ChipGenius or Flash Drive Information Extractor on a direct USB 2.0 root‑hub port.
    • Verify: SSS6692/0xBE and Flash ID 98 3C 98 B3 76 72.
  2. Prepare the environment
    • Prefer Windows 7/8 (32‑bit). Run MP tool as Administrator.
    • Disable USB selective suspend. Avoid hubs/front panels.
    • If the tool asks for a password, older 3S builds often use “1234”.
  3. Configure the MP tool
    • Select controller family: SSS6692 (or 3S 6692).
    • Pick the flash entry that exactly matches: ID 98 3C 98 B3 76 72 and the 32 GB Kioxia/Toshiba mapping (TLC, 16K page).
    • Do not override page/block/ECC unless the vendor table is missing.
  4. Run low‑level format
    • Start the process; allow full scan/erase/verify. Do not interrupt power.
    • On PASS, re‑plug; perform a full OS format (exFAT recommended).
  5. Post‑checks
    • Run H2testw or F3 write/read to validate the full LBA range.
    • If repeated write or verify errors appear, retire the device.

Decision tree by symptom

  • 0 MB capacity or write‑protected: Try MP as above. High success if NAND health is decent.
  • “Flash ID not supported”: Acquire a newer SSS6692 MP build; do not force a “nearby” table.
  • Not detected (no VID/PID): Inspect PCB, try different ports/cables; if still dead, advanced methods (test‑pad boot/ISP) or chip‑off only.
  • MP passes but speed is extremely low or capacity unstable: NAND is worn; retire the drive.

Potential challenges and how to overcome them

  • Multiple similar flash tables for the same ID: pick the one labeled for 32 GB TLC/16K; if in doubt, try the newest entry first.
  • CE/LUN ambiguity: Some 32 GB boards use a single package (1 CE, 2 LUNs); others use two packages (2 CEs). Let the correct table handle this; avoid manual CE overrides unless you have PCB evidence.
  • VM passthrough flakiness: If you must use a VM, ensure USB 2.0 passthrough and disable power management; physical Windows host is safer.

Possible disclaimers or additional notes

  • Block geometry (pages‑per‑block) and ECC strength vary by die revision; rely on the tool’s table rather than fixed “2048 KB vs 4096 KB block” assumptions.
  • Even after a successful low‑level re‑init, previously marginal NAND can deteriorate quickly; treat the device as non‑critical storage.

Suggestions for further research

  • Obtain the exact ChipGenius/FDIE report (VID/PID, controller rev, Flash ID, reported capacity). Share it and PCB photos (front/back) to determine CE count and confirm the optimal table.
  • If data recovery is required: consider professional tools/workflows (e.g., PC‑3000 Flash, VNR, Rusolut) with dump readout, XOR removal, ECC correction, and translator reconstruction for SSS6692 families.
  • Review Toggle‑DDR NAND behavior (timing margins, read‑retries) for tuning unstable reads if you proceed with chip‑off.

Brief summary

Your GoodRam 32 GB stick pairs an SSS6692‑BE controller with Toshiba/Kioxia Toggle‑DDR NAND (ID 98 3C 98 B3 76 72). To restore functionality, use an SSS6692‑capable 3S MP utility and select the flash table that exactly matches this ID; run a full low‑level format, then a full OS format and verification. If data matters, do not run MP—perform controller‑level imaging or chip‑off first. If you can provide the ChipGenius readout and, ideally, PCB photos, I can narrow the exact MP build and configuration line for your unit.

Ask additional question

Wait...(2min)
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.
Report illegal content (Article 16 DSA)