Innogrit SSD Data Recovery

Root Cause: Defective NAND Page Handling

The IG5236's quad-core Cortex-R5 firmware manages concurrent operations across 8 NAND channels. Under sustained mixed I/O (simultaneous random reads, sequential writes, & background garbage collection), the controller encounters a defective NAND page during a program operation. The error handler for that defective page triggers a buffer overflow in the firmware's internal command queue.

The overflow corrupts the module tables stored in the controller's working memory. The firmware detects the corruption, aborts all pending operations, & drops to a factory diagnostic state. The drive reverts to its silicon descriptor ("MN-5236") and reports a 2.1GB diagnostic capacity instead of the drive's real size. This panic is permanent; power cycling doesn't clear it. On a Phison or Silicon Motion drive in the same state, ACELab's PC-3000 SSD Active Utility would bypass the corrupted module tables through an SRAM loader. No such utility ships for Innogrit on PC-3000 SSD v3.8.10, so the data path runs through board-level repair to bring the controller back to a state where its own firmware can mount the NAND.

ADATA SSD Toolbox "60% Bug"

A specific trigger for the MN-5236 panic is the ADATA SSD Toolbox Quick Diagnostic Scan. The scan generates a pattern of mixed I/O that hits the IG5236's buffer overflow vulnerability. Users report the scan freezes at 60% progress, then the drive enters MN-5236 state permanently.

The 60% freeze point isn't arbitrary. At that stage, the Toolbox transitions from sequential read verification to random mixed I/O stress testing. The IG5236's firmware encounters the defective-page condition during this transition, triggers the overflow, & locks. The ADATA XPG Gammix S70 Blade is the most frequently affected drive. If your drive shows MN-5236 after running the ADATA Toolbox, don't run the Toolbox again or attempt firmware reflashing. Both actions risk overwriting the existing NAND data structure.

Power Loss Recovery Loop

After an unclean shutdown (power failure, forced restart, BSoD), the IG5236 enters a recovery routine that can take 30+ seconds. The controller attempts to reconcile its FTL state by scanning NAND metadata & verifying committed writes against the DRAM-cached mapping table stored in the reserved service area.

If the user interrupts this recovery routine by power cycling again before it completes, the controller must restart the reconciliation from scratch with an additional layer of corruption. Repeated power cycling compounds the FTL damage. Each interrupted recovery attempt adds another layer of corruption until the controller enters permanent firmware panic. The drive becomes undetectable on the PCIe bus.

Repeated thermal cycling (high temperature during sustained writes, ambient temperature at idle) causes micro-fractures in the BGA solder balls connecting the IG5236 to the M.2 PCB. These fractures are invisible to the naked eye. The drive may work intermittently for weeks before failing permanently. FLIR thermal imaging at our Austin, TX lab reveals the fractured joints as cold spots against the controller's normal heat signature.

PMIC burnout is the second thermal failure mode. The PMIC (power management IC) regulates voltage to the controller & NAND packages. When sustained heat exceeds its thermal limits, it shorts. A shorted PMIC draws excess current and prevents the controller from booting. FLIR shows the failed PMIC as a thermal hotspot at idle. Repair requires desoldering the failed PMIC with an Atten 862 hot air rework station & replacing it with a Hakko FM-2032 on an FM-203 base station.

Why Board Repair IS Data Recovery for Encrypted SSDs

Most data recovery labs outsource board-level failures or declare them unrecoverable. We don't. We locate the failed component using FLIR thermal imaging, replace the shorted PMIC or damaged capacitor with a Hakko FM-2032, & bring the original controller back to life. When the controller boots, the AES-256 encryption keys are intact & the controller's own firmware decrypts the NAND & serves data over standard NVMe to the imaging host.

Board repair isn't a separate service from data recovery for Innogrit SSDs. The encryption keys are fused to the controller silicon. If the controller is dead, chip-off yields only ciphertext. Reviving the original controller is the only recovery path. NVMe board repair: $600–$900.

Per-Controller Key Binding, Not Per-Firmware

The AES-256 media encryption key on an Innogrit SSD is generated dynamically by the controller's random bit generator and wrapped by a key encryption key derived from a hardware-unique root key that is fused into the controller silicon during fabrication. The wrapped media key is held in a reserved system area of NAND; the hardware-unique root key cannot be read back off the die. A donor IG5236 controller carries a different hardware-unique root key and cannot derive the key encryption key needed to unwrap the original media key. Transplanting the donor controller onto the original PCB produces a drive that powers on, enumerates correctly, and returns ciphertext on every LBA read.

Swapping the whole PCB (donor board with its own donor controller, with the customer's NAND packages moved over) fails for the same reason. The donor controller cannot decrypt the original NAND because it cannot unwrap the media key. The controller has no fallback path: there is no vendor-specific "decrypt with alternate key" NVMe command, and no way to re-sign the NAND with the donor's key without already having the plaintext.

The only recovery path that preserves the media key is the one the existing controller chip is on. Board-level repair revives the original silicon: replace the shorted PMIC with a Hakko FM-2032, re-bond a fractured BGA ball using an Atten 862 hot air station and a Zhuo Mao BGA rework platform, restore the failed voltage rail, and let the original controller boot with its key hierarchy intact. At that point, the drive can decrypt and serve LBAs normally. NVMe board repair starts at $600–$900; a donor drive is a matching ssd used for its circuit board. typical donor cost: $40–$100 for common models, $150–$300 for discontinued or rare controllers. +$100 rush fee to move to the front of the queue.

SLC Cache Collapse on DRAM-less IG5220 HMB Drives

The second failure mode worth isolating is SLC cache exhaustion on the IG5220 RainierQX, a DRAM-less Gen4 controller that relies on Host Memory Buffer to hold the FTL working set. IG5220 drives ship with a dynamic pSLC cache: a fraction of the TLC or QLC NAND is operated in pseudo-SLC mode to absorb burst writes at advertised sequential speeds. When the host sustains a write workload longer than the cache can fold back into native TLC, the controller stalls.

Under normal thermal and firmware conditions, the stall is benign: throughput drops to native TLC write speed and the drive keeps serving commands. The failure case is when the firmware cache manager has a defect that mishandles the fold-back transition. On affected IG5220 firmware revisions, a sustained write past the pSLC cache boundary can leave the FTL journal in an inconsistent state. The drive then enters BSY (busy) on the next power cycle and enumerates with a reduced or debug-mode capacity footprint, analogous to the IG5236 MN-5236 controller panic signature documented on ADATA S70 Blade drives.

Recovery is constrained by tool support. The ACELAB PC-3000 SSD supported controller matrix does not currently include a firmware-level Active Utility for Innogrit IG5216, IG5220, or IG5236 architectures. That means no loader injection, no technological-mode FTL reconstruction, and no vendor-utility path comparable to what exists for Phison or Silicon Motion controllers. Recovery on an Innogrit drive with a confirmed FTL fault reduces to board-level hardware stabilization (PMIC replacement, BGA rework, voltage rail repair) to revive the original controller so its own firmware can rebuild state on the next boot. See firmware corruption recovery for the generalized workflow across controller families where active utilities do exist.

How Channel Count Affects Page-Scan Bandwidth

On a supported controller family, FTL reconstruction reads every physical NAND page to extract LBA stamps & sequence numbers from the spare area, & more channels mean more parallel reads. The IG5236's 8-channel design at 1200 MT/s with up to 8 Chip Enable lines per channel in the 15mm FCBGA package gives it more raw parallelism than the IG5220 or IG5216. This architecture detail would matter during a firmware-level recovery if one existed for these controllers; on PC-3000 SSD v3.8.10 it does not, so the figure stays a documentation point rather than a recovery timeline.

The IG5220 offsets its 4-channel limitation with double the interface speed: 2400 MT/s per channel via ONFI 5.0. Raw bandwidth is comparable to the IG5236, but the reduced parallelism means the controller can't interleave as many concurrent read operations. In the absence of an Active Utility for Innogrit, this is a normal- operation characteristic, not a recovery characteristic.

Primary FTL Table & Journal Model

The primary FTL table is a complete logical-to-physical address map stored in reserved NAND service area blocks. On the IG5236, this table loads into DDR4 DRAM at boot. On the IG5220 & IG5216, it loads into the host PC's RAM via Host Memory Buffer. The table is large: a 2TB drive with 4KB LBA granularity requires roughly 2 billion L2P entries.

The journal is a sequential log of every L2P mapping change since the last full FTL flush. When the controller writes a new NAND page, it appends the updated L2P entry to the journal instead of rewriting the entire primary table. Periodically, the controller flushes the accumulated journal entries into the primary table & commits the updated table to NAND. Between flushes, the working FTL is the primary table plus the journal.

Three Corruption Pathways

1. Power loss during journal flush. The controller is in the middle of committing journal entries to the primary FTL table in NAND. A power cut interrupts the write. The primary table now has a mix of old & new entries with no way to determine which entries committed successfully. On the IG5220 & IG5216, the journal in host RAM is lost entirely when the PCIe link drops.
2. Bad block in the metadata NAND partition. The NAND blocks reserved for FTL storage are not immune to cell degradation. If a bad block develops in the service area where the primary FTL table is stored, the controller can't read its own mapping data. The LDPC engine attempts correction, but if the error count exceeds the correction threshold, the affected FTL region is unreadable. The controller can't boot.
3. Thermal event during active NAND programming. The IG5236 draws up to 3W peak power on 12nm FinFET. Sustained writes in an unventilated M.2 slot push junction temperatures past the NAND's rated maximum. A thermal event during an active FTL journal flush can corrupt both the in-flight write & the NAND page being programmed. The IG5220 at 2.5W peak is less susceptible but not immune.

Why FTL Corruption Bricks the Drive

User data corruption affects individual files. FTL metadata corruption affects every file. The FTL is the index that tells the controller where everything is stored in NAND. Without it, 2TB of NAND pages is an unsorted pile of data fragments with no address map.

On boot, the Innogrit controller runs an integrity check on the FTL structure. If the primary table is damaged & the journal can't reconcile the corruption, the controller aborts initialization & drops to its silicon descriptor. That's the MN-5236 state: the controller isn't dead, but it refuses to present user data because it can't trust its own map. On supported controller families (Phison, Silicon Motion, Marvell), ACELab's PC-3000 SSD Active Utility rebuilds the FTL from scratch using spare-area metadata on each NAND page, bypassing the corrupted primary table. No such utility exists for Innogrit in PC-3000 SSD v3.8.10, so the drive cannot be coaxed back to user-data state by firmware-level tooling at any lab in 2026. The only remaining option is board-level repair, on the chance the FTL integrity check is failing because of a marginal power rail rather than corrupt NAND. NVMe board repair on the Innogrit SSD recovery path: $600–$900.

What the System-Block Exception Looks Like

On boot, the controller fetches the FTL anchor descriptor from a small reserved area of the NAND service partition. The anchor descriptor points to the current primary FTL table copy and the active journal segment. If the anchor read returns an uncorrectable LDPC error, or if the descriptor signature does not match the expected magic value, the firmware raises an FTL system-block exception. The exception handler aborts user-space initialization, leaves the AES key wrapping engine offline, and presents the drive with the silicon descriptor capacity instead of the labeled capacity.

On an IG5236 drive (for example, an ADATA XPG Gammix S70 Blade, HP FX900 Pro, Acer Predator GM7000, or early-revision Netac NV7000), the BIOS reports the model string as "MN-5236" and the capacity as 2.1 GB. On an IG5220 drive (for example, a TeamGroup G50 or ADATA Atom 50), the same path produces a 0-byte capacity, because the DRAM-less variant has no host-presented descriptor to fall back on once HMB negotiation fails. Either presentation means the same thing: the NAND user data is intact, the FTL anchor is not.

Why SRAM Loader Injection Is Not Available for Innogrit

On a Phison or Silicon Motion drive in the same FTL system-block exception state, the recovery workflow does not begin with reading user data. It begins with replacing the controller's boot environment. ACELab's Active Utility transmits a vendor-specific SRAM loader to the controller over the PCIe link by issuing a sequence of vendor-defined NVMe admin commands against the controller's diagnostic mailbox. The loader is a small program (under 64 KB) that occupies the controller's on-chip SRAM & executes in place of the corrupted firmware in NAND.

None of that infrastructure exists for Innogrit on PC-3000 SSD v3.8.10. ACELab has not published an SRAM loader binary for the IG5216 / IG5220 / IG5236 BootROM ABI, & the diagnostic-mailbox command sequence for these controllers is not in any shipping release. Without the loader, an Innogrit drive in system-block exception cannot be coaxed into surfacing raw NAND through external tooling. The corrupted anchor descriptor & primary FTL stay in the boot path, & the controller stays stuck at the diagnostic capacity.

This is also why chip-off NAND is not a substitute. The AES-256 root key is fused to the controller silicon, so desoldering the NAND returns ciphertext that no lab can decrypt without the original controller booting against it. The path that preserves the key hierarchy is the same path the rest of this page points to: board-level hardware repair to revive the original controller.

Why FTL Translator Reconstruction Is Not Available Today

On supported controller families, with raw NAND access established through an SRAM loader, the next step is rebuilding the address map without trusting any of the on-NAND FTL structures. Every NAND page on a modern SSD carries a spare area alongside the user data region, holding the LBA the page was written for, a monotonic write sequence number assigned by the controller at programming time, and LDPC parity for both the data region & the metadata itself.

For Innogrit drives, this step is academic in 2026. There is no SRAM loader, so there is no raw NAND access. Even if a page scan could be run, the spare-area encoding (sequence-number width, LDPC layout, LBA-stamp framing) for IG5216 / IG5220 / IG5236 is not documented in PC-3000 SSD v3.8.10. The decoded fields the Active Utility relies on for Phison & Silicon Motion silicon are not available for Innogrit silicon, & the logical-to-physical map cannot be reconstructed blind. The honest answer at intake is that this drive cannot be quoted for firmware-level recovery until ACELab adds Innogrit to a future release.

Why DIY Firmware-Flash Tools Brick the Drive Permanently

A drive in the FTL system-block exception state is, from outside the lab, hard to distinguish from a drive with corrupted firmware code. Forum advice frequently points to vendor or third-party firmware flashers (mass-production tools, MPTools, or rebranded utilities shipped with retail toolboxes) that promise to reflash the controller. On an Innogrit drive in this state, running one of these tools destroys the only remaining path to the data.

The flasher does not just rewrite the controller code partition. To restore the drive to a factory state, it writes a fresh FTL anchor descriptor pointing at an empty primary table & a zeroed journal segment, then erases the NAND blocks that previously held FTL metadata. The user data NAND pages are not erased, but the spare-area sequence numbers in the metadata blocks (the same fields a hypothetical Innogrit Active Utility would need if ACELab ever shipped one) are wiped, & the anchor that referenced the prior map generation is overwritten in place. After the flash completes, the drive boots normally & reports its labeled capacity, but it is presented as empty. The LBA-to-physical relationship the user filesystem depended on no longer exists in any reconstructable form. This is the failure mode behind most "I tried the ADATA Toolbox repair & now the drive shows empty" cases that reach us.

The remediation rule is simple. If an Innogrit drive presents a 0-byte or 2.1 GB capacity, power it down. Do not run vendor toolboxes, do not flash firmware, do not run secure erase, do not run chkdsk. Ship the drive for SSD data recovery so the spare-area metadata stays intact in case ACELab adds Innogrit to a future PC-3000 SSD release that can act on it. In the meantime, the only lab path we can quote on these drives is board-level hardware repair to revive the original controller. Lab NVMe data recovery for an Innogrit drive in system-block exception, board-repair path: $600–$900.

Architectural Position in the Innogrit Family

The IG5208 runs on the same Marvell-pedigree firmware lineage as the rest of the Shasta & Rainier line, but at a lower bandwidth envelope: PCIe 3.0 x2 instead of x4, peak sequential read around 1,750 MB/s & sequential write around 1,500 MB/s. The controller is DRAM-less, leaning on Host Memory Buffer to cache the page mapping table when the drive is attached over an NVMe interface. In the USB adapter form factor (such as the ADATA SE800), the controller sits behind a USB bridge IC (commonly the ASMedia ASM2362) & HMB negotiation is blocked by the USB protocol; the controller falls back to its limited on-die SRAM for FTL caching, which is why sustained random-write performance on these external enclosures is far below the same silicon in a native M.2 slot. The hardware AES-256 encryption engine is inherited from the rest of the family.

Capacity scales up to 2 TB, matching the IG5216, with the bulk of shipping product in the 256 GB & 512 GB tiers. NAND interface is ONFI 4.x at the lower end of the Innogrit interface-speed envelope, with a 4-channel NAND configuration (4CH x 4CE) that maximizes throughput within the x2 PCIe link.

Where the IG5208 Shows Up in the Field

Two product categories dominate. The first is OEM-only M.2 modules & BGA SSDs soldered directly to laptop motherboards, where the IG5208 is chosen for power envelope rather than performance. The second is the USB 3.2 external enclosure segment, where the controller is paired with a USB-to-NVMe bridge to produce a pocket-sized external SSD. The ADATA SE800 is the most-cited example; other branded external SSDs in the same form factor have shipped with the same controller across production runs.

BOM roulette applies here as it does to the IG5236-based drives documented earlier. External enclosure brands silently swap controllers between production batches without changing the model number on the chassis. Physical inspection of the PCB is required to confirm an IG5208 is present before any recovery quote can be issued.

Recovery Posture for IG5208 Drives

The IG5208 is not on the ACELab PC-3000 SSD supported-controller list as of v3.8.10. The support-matrix disclaimer above applies in full: Rossmann does not currently offer in-lab firmware recovery for the IG5208. There is no Active Utility, no Technological Mode loader, & no FTL reconstruction path on the platform every professional SSD lab in North America runs.

The path that remains is board-level repair on the original PCB. On an internal M.2 module the recovery sequence is the same as the IG5236 board path documented in the board-level component map: PMIC diagnosis on a current-limited bench supply, FLIR scan for shorted MLCCs, rework on a Zhuo Mao precision BGA station if a fractured controller joint is in play. On a USB enclosure such as the ADATA SE800, the bridge IC is evaluated first: a dead bridge with a healthy IG5208 behind it is the easier failure mode, because the controller can be removed from the carrier & presented to a host over native NVMe through a lab adapter. If the IG5208 controller die itself is the failure point, the same honest answer applies: no firmware-level recovery path exists on public tooling today. NVMe board repair: $600–$900. +$100 rush fee to move to the front of the queue.