SSD Controller Architecture
Innogrit IG5236 / IG5220 / IG5216 Controller Architecture
ACELab's PC-3000 SSD supported-controller list does not include Innogrit silicon. Rossmann does not currently offer in-lab recovery for the Innogrit IG5216. Rossmann does not currently offer in-lab recovery for the Innogrit IG5220. Rossmann does not currently offer in-lab recovery for the Innogrit IG5236.
What remains is controller-level board repair: PMIC replacement, MLCC repair, or BGA reflow, viable only when the controller die itself survives. NVMe board repair: $900–$1,200. No diagnostic fee.
This page is the architecture reference our ssd data recovery services desk uses when an Innogrit-based NVMe drive comes through intake. Innogrit's NVMe controllers include the Shasta series & the Rainier series. The IG5216 Shasta+ is a Gen3 Shasta controller. On the Rainier side, the IG5220 RainierQX is Gen4 & DRAM-less, & the IG5236 Rainier is Gen4 with DDR4 DRAM. When the IG5236's firmware panics, the drive stops presenting its real capacity. Because the media key on an encrypting Innogrit drive is generated on and wrapped by the original controller, recovery on a dead Innogrit drive is a controller-level NVMe board repair problem, not a chip-off job. ACELab's PC-3000 SSD supported-controller list does not include Innogrit. The path that remains is reviving the original controller through PMIC repair, MLCC replacement, or BGA reflow so its own AES-256 engine boots & decrypts the NAND. NVMe board repair is $900–$1,200. No diagnostic fee.
Which Innogrit Controller Is in Your SSD?
Innogrit ships three NVMe controller families. Two are DRAM-less (IG5216, IG5220), caching the Flash Translation Layer in host RAM via Host Memory Buffer. The IG5236 has dedicated DDR4 DRAM & 8 NAND channels.
| Controller | Interface | DRAM | Common Drives | Failure Signature | PC-3000 Support |
|---|---|---|---|---|---|
| IG5216 (Shasta+) | NVMe Gen3 x4 | No (HMB) | HP EX900 Plus, VisionTek DLX3 | FTL corruption, HMB loss after power cut | Not supported (board repair only) |
| IG5220 (RainierQX) | NVMe Gen4 x4 | No (HMB) | TeamGroup G50, ADATA Atom 50, VisionTek DLX4 | FTL corruption, HMB loss, silicon descriptor | Not supported (board repair only) |
| IG5236 (Rainier) | NVMe Gen4 x4 | Yes (DDR4) | ADATA XPG Gammix S70 Blade, HP FX900 Pro, Acer Predator GM7000 | Firmware panic; wrong capacity reported in BIOS | Not supported (board repair only) |
BOM roulette warning: some drives labeled with one controller ship with different silicon between production runs. The Netac NV7000 has turned up with both the IG5236 & the Phison E18. We have to physically inspect the PCB to identify the actual controller before quoting a recovery path.
ACELab PC-3000 SSD Support Status
Rossmann does not currently offer in-lab recovery for the Innogrit IG5216. Rossmann does not currently offer in-lab recovery for the Innogrit IG5220. Rossmann does not currently offer in-lab recovery for the Innogrit IG5236.
The ACELab PC-3000 SSD supported-controller list does not include Innogrit silicon. There is no Active Utility, no loader injection, & no Technological Mode FTL reconstruction path for IG5216 Shasta+, IG5220 RainierQX, or IG5236 Rainier.
The one recovery option that's still technically viable is board-level hardware repair to revive the original controller. Once it's running again, it can decrypt the NAND with the silicon-bound AES-256 key & serve LBAs over the standard NVMe interface. We can perform consultative diagnostic evaluation on Innogrit drives at no charge & will tell you honestly whether a board-repair attempt is worth quoting.
If ACELab adds Innogrit to a future PC-3000 SSD release, this page will be updated. Until then, we will not claim a recovery service we cannot honestly perform.
How Do Innogrit SSDs Fail?
Innogrit SSD failures split into three categories: firmware corruption, controller death from electrical damage, & NAND degradation from cell wear.
Firmware Corruption
The drive shows up in BIOS with a wrong capacity, or without its consumer brand name. Your data is still in the NAND chips; the controller just can't read its own corrupted firmware modules to locate it.
On a Phison or Silicon Motion drive, ACELab's PC-3000 SSD active utility would inject a loader at this stage, work around the corruption & rebuild the FTL. No such utility ships for Innogrit in PC-3000 SSD, so the data path on a panic-locked Innogrit drive runs through board-level hardware repair to revive the original controller & let its own firmware mount the NAND. This failure pattern follows the same SSD firmware corruption mechanics seen across other controller families.
Controller Failure
The IG5236 generates sustained heat under Gen4 write loads. Recovery starts with FLIR thermal imaging to locate the failed component, then board-level repair with a Hakko FM-2032 microsoldering iron. NVMe board repair: $900–$1,200.
NAND Degradation
NAND flash cells have a finite write life. The IG5236 pairs with various TLC NAND from Micron & SK Hynix. As cells wear, bit-flip rates climb until the controller's LDPC error correction can't keep up. On supported controller families (Phison, Silicon Motion, Marvell), PC-3000 SSD can apply voltage threshold shifts during extraction to pull data from degraded cells the controller has abandoned. No equivalent utility ships for Innogrit silicon on PC-3000 SSD, so a read-only or progressively slowing Innogrit drive should be powered down & shipped before the controller drops off the bus permanently.
When Recovery Software Works (and When It Doesn't)
Recovery software like Disk Drill, EaseUS, PhotoRec, & R-Studio works when the SSD is physically healthy but has a logical problem: accidental deletion with TRIM disabled, a corrupted partition table, or a formatted volume. These tools talk to a working controller through your operating system.
That changes when the controller is dead or the firmware is corrupted. Software can't communicate with a drive that won't power on or misreports itself in BIOS. For Innogrit-based drives, the path is board-level hardware repair to revive the original controller; PC-3000 SSD ships no Innogrit active utility. On modern SSDs with TRIM enabled (the default on Windows 7+ & on macOS for Apple-shipped SSDs), deleted files are gone within seconds to minutes. The OS sends a TRIM command telling the controller which blocks are free. The controller's garbage collection process erases those NAND pages. No software & no lab can recover data from erased NAND cells.
How Much Does Innogrit SSD Recovery Cost?
All Innogrit controllers (IG5216, IG5220, IG5236) are NVMe. Cost depends on failure severity, not the controller model. No diagnostic fee. No data, no recovery fee. Full SSD recovery cost breakdown. +$100 rush fee to move to the front of the queue.
NVMe SSD Recovery (IG5216, IG5220, IG5236)
Low complexity
Simple Copy
Your NVMe drive works, you just need the data moved off it
Functional drive; data transfer to new media
Rush available: +$100
$200
3-5 business days
Low complexity
File System Recovery
Your NVMe drive isn't showing up, but it's not physically damaged
File system corruption. Visible to recovery software but not to OS
Starting price; final depends on complexity
From $250
2-4 weeks
Medium complexity
Circuit Board Repair
Your NVMe drive won't power on or has shorted components
PCB issues: failed voltage regulators, dead PMICs, shorted capacitors
May require a donor drive (additional cost)
$900–$1,200
3-6 weeks
Medium complexity
Most Common
Firmware Recovery
Your NVMe drive is detected but shows the wrong name, wrong size, or no data
Firmware corruption: ROM, modules, or system files corrupted
Price depends on extent of bad areas in NAND
$900–$1,200
3-6 weeks
High complexity
PCB / NAND Swap
Your NVMe drive's circuit board is severely damaged and requires NAND chip transplant to a donor PCB
NAND swap onto donor PCB. Precision microsoldering and BGA rework required
50% deposit required; donor drive cost additional
50% deposit required
$1,200–$2,500
4-8 weeks
Hardware Repair vs. Software Locks
Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.
No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. NAND swap requires a 50% deposit because donor parts are consumed in the attempt.
- Rush fee
- +$100 rush fee to move to the front of the queue
- Donor drives
- 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.
- Target drive
- The destination drive we copy recovered data onto. You can supply your own or we provide one at cost plus a small markup. All prices are plus applicable tax.
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.
Innogrit Firmware Architecture
Dr. Zining Wu founded Innogrit in October 2016. Wu spent 17 years at Marvell Technology, including a tenure as Chief Technology Officer, & holds over 200 U.S. patents. The company is headquartered in San Jose, California. Innogrit is a fabless IC designer; TSMC manufactures the silicon.
IG5236 Rainier: DRAM-Equipped Flagship
The IG5236 is a PCIe 4.0 x4 NVMe 1.4 controller with 8 NAND channels & a dedicated DDR4 DRAM cache. It reads up to 7,400 MB/s, writes up to 6,400 MB/s, & reaches up to 1M IOPS random read. The onboard DRAM stores the active FTL, reducing vulnerability to power loss compared to DRAM-less controllers. The FTL backup flushes periodically to reserved NAND service area blocks.
All four Cortex-R5 cores manage concurrent NAND channel operations.
IG5220 RainierQX & IG5216 Shasta+: DRAM-less Budget Controllers
The IG5220 (Gen4 x4, tri-core ARM Cortex-R5, 4 channels) & IG5216 (Gen3 x4, 4 channels) are DRAM-less. Both cache the Flash Translation Layer in host RAM through NVMe Host Memory Buffer. The IG5216 maxes out at 3,400 MB/s read & 3,000 MB/s write with 500K IOPS random.
The HMB dependency creates the same vulnerability seen in Silicon Motion & Maxio DRAM-less NVMe controllers: a power cut severs the PCIe link, the in-flight FTL update in host RAM never commits to NAND, and the controller boots with a corrupted mapping table. The drive reports its silicon descriptor or 0 bytes & won't mount.
- Flash Translation Layer (FTL)
- The mapping table that converts logical block addresses (what your operating system requests) to physical NAND page locations (where data is stored on the flash chips). Every SSD maintains an FTL. When it corrupts, the controller can't locate any data even though the NAND still holds it.
- AES-256 Hardware Encryption
- Innogrit's NVMe controllers carry a hardware AES engine. Where that engine is active, the media key is generated on the controller & wrapped by a key tied to that controller's hardware-unique root, so it never leaves the silicon; if the controller dies, the NAND contents read as ciphertext. Chip-off is not a viable path on these drives either way, because the controller's scrambling & LDPC error correction sit in front of the data.
IG5236 Firmware Panic
In an IG5236 firmware panic, the NAND data is intact. The controller's firmware state machine has entered an irrecoverable error state that consumer tools can't clear.
The IG5236 firmware manages concurrent operations across 8 NAND channels. When it panics, it aborts pending operations & drops to a factory diagnostic state, reporting a capacity that has nothing to do with the drive's real size. That state 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 a loader. No such utility ships for Innogrit on PC-3000 SSD, 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.
What Not to Do After a Panic
A drive in this state should be left alone. Vendor toolbox scans and firmware reflashes both write to the drive, and a reflash in particular can overwrite the data structures on the NAND that a recovery depends on. Power it down and send it in for evaluation instead.
Why Firmware-Level Recovery Tooling Does Not Exist for Innogrit Today
A firmware panic isn't the end of the road on Phison & Silicon Motion drives. ACELab ships Active Utilities that force the controller into a vendor diagnostic mode, inject a loader, & rebuild the FTL. None of that infrastructure ships for Innogrit on PC-3000 SSD. This section names the specific pieces that have to exist for a firmware-level recovery to be real, & confirms each piece is absent for IG5216, IG5220, & IG5236.
What Has To Exist for a Firmware-Level SSD Recovery
- A documented entry path into a vendor diagnostic mode (variously called Safe Mode, Technological Mode, or BootROM mode) reachable from a panic-locked controller via test-pad shorting or a vendor command sequence.
- A vendor-specific loader binary that runs in place of the corrupted NAND firmware & exposes raw NAND read commands without booting the failed FTL.
- An encryption-key extraction path that keeps the controller alive long enough for its own AES-256 engine to decrypt the NAND during imaging.
PC-3000 SSD doesn't have any of these pieces for Innogrit.
What Is Missing for IG5216, IG5220, & IG5236
The published PC-3000 SSD release notes don't give recovery engineers a diagnostic-mode entry point for these controllers. ACELab hasn't released a loader binary that matches the IG5216 / IG5220 / IG5236 BootROM ABI either. Without the loader, even a controller that responds to a hypothetical safe-mode entry sequence cannot be coaxed into surfacing raw NAND over the PCIe link.
There's no spare-area metadata parser for these controllers either. Innogrit's LDPC layout, sequence-number width, & LBA stamp encoding are not documented in any release of PC-3000 SSD that has shipped to the recovery industry. A page scan run blind against an Innogrit drive returns bits that cannot be assembled into a logical-to-physical map. And because the media key never leaves the controller, even a successful raw-NAND extraction would yield ciphertext with no decryption path.
The honest summary: no Active Utility, no loader, no metadata parser, no key-extraction path. Until ACELab adds Innogrit to a future PC-3000 SSD release, the only recovery path on these drives is the one that does not depend on vendor tooling: board-level hardware repair that revives the original controller so its own firmware boots its own AES engine against its own NAND.
Per-Controller Panic Descriptor: PCIe Trains vs Total Disappearance
The public tool matrix doesn't have a firmware-level recovery for either state today. Which state the drive is in changes what the board-level engineer inspects first.
- Silicon-Descriptor Panic State (PCIe Link Trains)
- The drive surfaces with a diagnostic capacity in place of its real one, on the IG5236, IG5220, and IG5216 alike. On a supported controller family this would be the case where an Active Utility loader gets injected; on Innogrit silicon no such utility exists, so the case is triaged for board-level inspection & the customer is told that firmware reconstruction is not on the menu.
- Total Drive Disappearance (No PCIe Link Training)
- The host BIOS does not enumerate any device at the M.2 slot. Recovery path: board-level stabilization. The engineer inspects the PMIC & surrounding rails with a FLIR thermal camera to locate hotspots or shorted decoupling caps, repairs voltage rails with a Hakko FM-2032, & reflows the controller BGA with Atten 862 hot air on a Zhuo Mao BGA rework station if a fractured joint is suspected. If the repair succeeds, the original controller boots its own firmware against its own NAND.
Drive-Model Failure Signatures: Diagnostic Fingerprint by Host Drive
The general NVMe context lives on the NVMe data recovery hub and the NVMe PCIe SSD recovery page.
- IG5236 Rainier drives
- A diagnostic capacity in place of the real one, described in detail under Firmware Panic on this page. On the IG5236 we triage the case for board-level inspection. If the controller die itself has failed, we send it back & tell you we can't quote it.
Board-Level Repair for Innogrit Drives
Because no firmware-level Innogrit tooling exists in PC-3000 SSD, board repair is not a fallback for Innogrit drives; it is the primary recovery path. The engineer skips firmware-level diagnosis entirely & goes straight to electrical fault analysis on the original PCB.
The recovery engineer uses a FLIR thermal camera to locate the failed component. A shorted PMIC shows as a thermal hotspot before the drive reaches operating temperature. Component-level replacement uses a Hakko FM-2032 on an FM-203 base station for fine-pitch SMD work & a Zhuo Mao BGA rework station for controller reflow.
When the original controller boots again, the AES-256 encryption keys are intact & the drive serves data over the standard NVMe interface. If the controller die itself is the failure point, we will say so on the diagnostic call rather than quote work we cannot deliver. NVMe board repair: $900–$1,200.
Firmware Panic vs Controller Death: How to Tell
- Firmware Panic (PCIe Link Trains, NVMe Identify Fails)
- The PCIe link trains successfully. The drive may briefly identify with a wrong capacity, or it may complete link negotiation but fail NVMe initialization. On a Phison or Silicon Motion drive this is the case where an Active Utility would inject a loader. On Innogrit silicon, no such utility ships, so this state is triaged for board-level inspection in case a marginal power rail or weak passive is making the firmware boot erratically. NVMe board repair, when viable: $900–$1,200.
- Controller Death (Board Repair Required)
- No PCIe link training occurs. Board-level microsoldering must restore electrical function before the drive presents on the PCIe bus again. NVMe board repair: $900–$1,200.
IG5236 Thermal Stress
The IG5236 draws sustained current at Gen4 speeds. Rated by Innogrit for up to 7,400 MB/s sequential read, the controller generates enough heat during continuous writes to stress BGA solder joints & PMIC components.
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 PMIC (power management IC) regulates voltage to the controller & NAND packages. 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
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 generated on and bound to the original controller. If the controller is dead, chip-off yields only ciphertext. Reviving the original controller is the only recovery path. NVMe board repair: $900–$1,200.
Why a Donor PCB Swap Does Not Recover an Innogrit SSD
Customers who recognize that chip-off NAND recovery fails on encrypted SSDs often ask a follow-up question: can you move the NAND packages to a matching donor PCB, or transplant a fresh controller from a donor drive? On Innogrit IG5216, IG5220, & IG5236 drives, neither approach returns readable data. The reason is the AES-256 key binding model.
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 can't 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.
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 $900–$1,200; 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.
pSLC Cache Behavior on IG5220 Drives
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.
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 Does Innogrit Recovery Differ from Silicon Motion & Phison?
| Attribute | Innogrit IG5236 | Silicon Motion SM2262EN | Phison E18 |
|---|---|---|---|
| CPU Cores | 4x Cortex-R5 | 2x Cortex-R5 | 3x Cortex-R5 |
| NAND Channels | 8 | 8 | 8 |
| PC-3000 SSD Support | Not supported (no Active Utility) | Full Active Utility | Active Utility (E12); repair-only (E18) |
The IG5236 & the SM2262EN each have a hardware AES engine. The SM2262EN's primary failure mode is ROM mode with a 0GB capacity. Under stress, the Phison E18's firmware throttles aggressively.
Silicon Motion controllers (SM2258XT, SM2262EN) have mature PC-3000 SSD active utility support with documented loader databases. Phison E12 has full Active Utility support; the E18 is limited to repair-only mode with no FTL reconstruction. Innogrit is a newer player & sits in a different category. ACELab's PC-3000 SSD supported-controller list doesn't include any Innogrit part, so there's no Active Utility, no loader, & no FTL reconstruction path for IG5216 / IG5220 / IG5236.
With no Active Utility, there's no firmware-level way to act on an IG5236 firmware panic. The path is board-level hardware repair to revive the original controller; everything else has to wait for ACELab to add Innogrit to a future PC-3000 SSD release.
See also: Silicon Motion architecture | Phison architecture | Maxio architecture | SandForce / Marvell legacy
NAND Interface Protocols & Channel Architecture
Innogrit's three controllers use different NAND interface speeds & channel counts, which directly affect both drive performance & recovery scan duration. The IG5236's 8-channel design at 1200 MT/s reads NAND pages in parallel during FTL reconstruction; the IG5220 compensates for 4 channels by running at 2400 MT/s per channel.
| Controller | Channels | Interface Speed | NAND Protocol |
|---|---|---|---|
| IG5236 (Rainier) | 8 | 1200 MT/s | ONFI 4.1 / Toggle Mode |
| IG5220 (RainierQX) | 4 | 2400 MT/s | ONFI 5.0 / Toggle 5.0 |
| IG5216 (Shasta+) | 4 | 1200 MT/s | ONFI 4.1 |
How Channel Count Affects Page-Scan Bandwidth
Channel count would matter during a firmware-level recovery if one existed for these controllers. PC-3000 SSD doesn't have one, so the channel count is a documented spec. It doesn't tell you how long a recovery takes.
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.
- ONFI (Open NAND Flash Interface)
- An industry standard defining the electrical & protocol interface between the SSD controller & the NAND flash dies. ONFI 4.1 runs at 1200 MT/s; ONFI 5.0 doubles that to 2400 MT/s. The controller's ONFI version determines which NAND dies it can address & at what speed.
- Chip Enable (CE)
- The IG5216 supports 4 CE per channel, & the IG5220 supports up to 4.
LDPC Error Correction & Read Retry Recovery
Innogrit controllers use LDPC (Low-Density Parity-Check) error correction to compensate for bit errors in aging NAND cells. The IG5236 runs an advanced 4K LDPC engine. When LDPC can't fix a page, the controller triggers Read Retry sequences that shift voltage thresholds & re-read the data.
How LDPC Differs from BCH Error Correction
LDPC uses probability graphs: it models relationships between bits across a NAND page & iteratively converges on the most likely original data pattern. This lets LDPC correct more bit errors per page than BCH at the same redundancy overhead. For TLC NAND storing 3 bits per cell, the difference matters.
The LDPC engine is part of how the drive works in normal use. No vendor utility ships for Innogrit on PC-3000 SSD, so a recovery tool can't drive or adjust that engine.
Read Retry Voltage Threshold Shifting
TLC NAND stores 3 bits per cell by dividing the cell's charge window into 8 voltage levels. Electrons leak, and the voltage thresholds drift. The controller reads data by comparing the cell's charge against reference voltages. When drift moves a cell's charge past its reference boundary, the controller reads the wrong value.
Read Retry compensates by shifting the reference voltages to match the degraded cell's actual charge distribution. The controller stores a table of alternative voltage offset sets & cycles through them until it gets a page read with an error rate below the LDPC correction threshold. Each retry attempt adds latency, which is why degraded SSDs slow down before they fail entirely.
Why Manual Voltage Control Is Not Available for Innogrit Drives Today
On supported controller families, ACELab's PC-3000 SSD active utility lets the recovery engineer push voltage offsets beyond the controller's built-in retry table, page by page, to pull readable data from cells the firmware abandoned. That utility does not exist for Innogrit silicon on PC-3000 SSD. There is no published interface for adjusting IG5216 / IG5220 / IG5236 read-voltage thresholds outside the controller's own firmware logic, & no loader path that would let an external tool issue those commands. Drives with widespread NAND degradation that present this failure mode on an Innogrit controller cannot be quoted for firmware-level recovery today.
- Raw Bit Error Rate (BER)
- The number of bit errors per bits read before error correction. When BER exceeds the LDPC correction threshold, sectors become uncorrectable through normal controller operation.
- Program/Erase (P/E) Cycles
- Each write operation programs electrons into a NAND cell's floating gate; each erase operation removes them. Every cycle degrades the oxide insulation. Consumer TLC NAND is rated for 1,000-3,000 P/E cycles. Enterprise TLC may reach 10,000.
FTL Corruption Pathways
Primary FTL Table
On the IG5236, the primary FTL table loads into DDR4 DRAM at boot. The IG5220 & IG5216 are DRAM-less, so their working mapping table sits in the host PC's RAM through Host Memory Buffer.
Corruption Pathways
- Power loss. On the IG5220 & IG5216, a power cut drops the PCIe link, & the mapping table sitting in host RAM is gone.
- Thermal event during active NAND programming. The DRAM-less IG5220 runs cooler, but it isn't immune to one.
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.
If the primary table is damaged, the controller aborts initialization & drops to its silicon descriptor. That's the firmware-panic state: the controller isn't dead, but it refuses to present user data because it can't trust its own map. On a supported Phison, Silicon Motion or Marvell controller, ACELab's PC-3000 SSD active utility rebuilds the FTL. No such utility exists for Innogrit in PC-3000 SSD. The 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: $900–$1,200.
Wear-Leveling
Every modern SSD distributes program/erase cycles across the NAND array through wear-leveling. Dynamic wear-leveling balances writes across the pool of free blocks so no single block accumulates cycles faster than its peers.
PC-3000 SSD has no utility for Innogrit silicon. Rossmann does not currently offer in-lab recovery for the IG5216, IG5220, or IG5236. The only path back to data when an Innogrit drive enters this state is board-level hardware repair to revive the original controller boot, on the chance the integrity check is failing because of a marginal power rail rather than physically corrupt NAND service-area blocks. NVMe board repair: $900–$1,200.
- NAND Service Area
- On supported controller families, PC-3000 SSD accesses the service area through a vendor diagnostic mode to read & reconstruct corrupted firmware structures. No such interface ships for Innogrit silicon on PC-3000 SSD.
Wrong-Capacity Reads on Innogrit Drives
When an Innogrit IG5236 or IG5220 fails its FTL boot integrity check, the controller does not always disappear from the PCIe bus. A common presentation is a drive that still trains a PCIe link and answers an NVMe Identify Controller command, but reports a capacity of zero bytes, or some other value that is not the labeled user capacity.
On an IG5236 drive, the BIOS reports a capacity that isn't the labeled one.
Why Loader Injection Is Not Available for Innogrit
On a Phison or Silicon Motion drive in the same state, the recovery workflow doesn't begin with reading user data. It begins with replacing the controller's boot environment. The loader is a small program that sits in the controller's RAM & runs in place of the corrupted firmware in NAND.
None of that infrastructure exists for Innogrit on PC-3000 SSD. ACELab hasn't published a loader binary for the IG5216 / IG5220 / IG5236 BootROM ABI. Without the loader, external tooling can't get raw NAND out of an Innogrit drive in this state. So the controller stays stuck at the diagnostic capacity.
This is also why chip-off NAND is not a substitute. The media key is wrapped by a key tied to the original controller's hardware-unique root, so desoldering the NAND returns ciphertext that no lab can decrypt without that 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 a supported controller family, once the loader is running, the next step is to rebuild the address map.
For Innogrit drives there is no 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. 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
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.
Once the flash finishes, the drive boots normally & reports its labeled capacity, but it shows up empty.
The remediation rule is simple. If an Innogrit drive presents a 0-byte or otherwise wrong capacity, power it down. Don't flash firmware, & don't run vendor toolboxes on it. Ship the drive for SSD data recovery. The only lab path we can quote on these drives is board-level hardware repair to revive the original controller. For an Innogrit drive in this state, NVMe data recovery by board repair in our lab is $900–$1,200.
- Loader
- A small vendor-specific program an Active Utility injects into a controller's RAM on supported controller families (Phison, Silicon Motion, Marvell). It runs in place of the corrupted NAND firmware so the FTL can be rebuilt. No loader has been published for any Innogrit controller on PC-3000 SSD.
- Spare-Area Metadata
- The Innogrit-specific encoding of spare-area metadata isn't documented in PC-3000 SSD. Vendor firmware-flash tools wipe the service-area sequence record either way. That's why a reflash on an Innogrit drive in this state takes away any future chance of recovery, even if ACELab later ships Innogrit support.
Innogrit Drive-to-Controller Reference
This table maps verified US-market drives to their Innogrit controllers. Chip-off recovery is not viable on any drive listed here.
| Drive | Controller | NAND | Interface |
|---|---|---|---|
| ADATA XPG Gammix S70 Blade | IG5236 (Rainier) | TLC | Gen4 |
| HP FX900 Pro | IG5236 (Rainier) | Various TLC | Gen4 |
| Acer Predator GM7000 | IG5236 (Rainier) | Various TLC | Gen4 |
| Mushkin Redline Vortex | IG5236 (Rainier) | Various TLC | Gen4 |
| Patriot Viper VP4300 | IG5236 (Rainier) | Various TLC | Gen4 |
| Netac NV7000 | IG5236 (Rainier) | Various TLC | Gen4 |
| TeamGroup G50 | IG5220 (RainierQX) | TLC | Gen4 |
| ADATA Atom 50 | IG5220 (RainierQX) | TLC | Gen4 |
| VisionTek DLX4 | IG5220 (RainierQX) | TLC | Gen4 |
| HP EX900 Plus | IG5216 (Shasta+) | TLC | Gen3 |
| VisionTek DLX3 | IG5216 (Shasta+) | TLC | Gen3 |
BOM roulette applies. The Netac NV7000 has been found with both the IG5236 & the Phison E18. Sabrent Rocket 4 Plus, TeamGroup Cardea A440 Pro, & Inland Performance Plus use Phison E18, NOT Innogrit. We have to physically inspect the PCB to confirm the controller before quoting a recovery path.
Board-Level Component Map for IG5216, IG5220 & IG5236 Reference PCBs
Because the support-matrix disclaimer above forecloses firmware-level recovery on Innogrit silicon, the only avenue left is reviving the original controller through electrical repair. That work is bounded by which components on the reference PCB tend to fail & how each failure presents on the bench. The map below is the engineering basis for any quote we would issue on an Innogrit drive.
We diagnose with a multimeter pass on each rail at the PMIC output pads, with the drive on a current-limited bench supply. We replace a failed MLCC with a Hakko FM-2032 microsoldering iron on the FX-951 base, & we only bring in hot air from the Atten 862 when the surrounding components need protection from prolonged iron contact. We rework these BGA packages on a Zhuo Mao precision BGA station with a controlled ramp profile. A generic hot-air gun will lift adjacent passives off their pads.
Diagnostic Procedure Before Quoting
Every Innogrit drive that arrives gets the same opening sequence.
- Visual inspection under stereo microscope for physical damage, burn marks, or missing passives.
- Current-draw test on a current-limited bench supply at the M.2 connector to classify the failure as PMIC death, controller short, or live controller in panic.
- FLIR scan under power if any current flows, to map any thermal hot spot back to a specific component.
- Multimeter verification of each derived rail at the PMIC output pads.
Only after that sequence completes do we decide whether a board-repair quote is worth issuing.
IG5208 Shasta: Entry-Tier PCIe 3.0 x2 & USB External Drives
The IG5208 (Shasta) sits below the IG5216 in the Innogrit family. It is a PCIe 3.0 x2 DRAM-less controller designed for low-power M.2 modules & BGA client drives, & it is also adapted into external USB 3.2 enclosures such as the ADATA SE800. The codename "Shasta" belongs to this part & the IG5216 Shasta+; the "Tacoma" designation that appears in some forum posts refers to the enterprise-grade IG5668 / IG5669, not the IG5208.
Architectural Position in the Innogrit Family
The IG5208 is slower than the rest of the Shasta & Rainier line. It's PCIe 3.0 x2 instead of x4, with 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 hardware AES-256 encryption engine is inherited from the rest of the family.
Capacity scales up to 2 TB, matching the IG5216.
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.
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. 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.
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. NVMe board repair: $900–$1,200. +$100 rush fee to move to the front of the queue.
Innogrit Product-Line Tiers: Shasta, Rainier & the Enterprise IG5638
Innogrit's NVMe lineup splits into three tiers, & for a recovery lab the tier tells you the target market, not a different recovery method. Shasta (IG5208 / IG5216) is the Gen3 entry tier. Rainier (IG5220 / IG5236) is the Gen4 consumer flagship. Above both sits Innogrit's enterprise tier, where the IG5638 targets data-center storage.
The shared invariants matter more than the tier: an Innogrit controller keeps its media key with itself, none appear on ACELab's PC-3000 SSD supported list, & all of them are board-repair only. The differentiation below is framed around what changes for recovery, not around spec-sheet marketing.
ACELab PC-3000 SSD Support Status
Rossmann does not currently offer in-lab recovery for the Innogrit IG5208. Rossmann does not currently offer in-lab recovery for the Innogrit IG5216. Rossmann does not currently offer in-lab recovery for the Innogrit IG5220. Rossmann does not currently offer in-lab recovery for the Innogrit IG5236. Rossmann does not currently offer in-lab recovery for the Innogrit IG5638.
No Innogrit controller, Gen3 Shasta through the enterprise tier, appears on the ACELab PC-3000 SSD supported-controller list. There is no Active Utility & no FTL reconstruction path for any of these parts. The only technically viable option across the whole line is board-level repair to revive the original controller so its own AES-256 engine decrypts the NAND. Our NVMe SSD recovery service handles the board-repair side of that work in-house in Austin, TX.
What Changes Per Tier for a Recovery Lab
Moving up the tiers doesn't open a firmware-level recovery path on any of them. The enterprise IG5638 is missing from the tool matrix the same way Shasta & Rainier are. Rossmann does not currently offer in-lab recovery for the Innogrit IG5638. Our SSD data recovery workflow treats all three tiers as one recovery posture: revive the original controller or there is no path.
The failure-mode anchors are tier-specific only where they are publicly documented. Rainier's IG5236 has the firmware panic & diagnostic-capacity drop documented in the controller firmware-panic & ROM-mode reference. The Shasta entry tier shares the same physical recovery constraints as the rest of the line.
The enterprise IG5638's specific firmware-panic descriptors aren't publicly documented. So we can only describe it in general terms. After a controller FTL panic or a PMIC failure, the only path is board repair to revive the original controller, exactly as on the consumer parts. Rossmann does not currently offer in-lab recovery for the Innogrit IG5638.
Tier Comparison
The table below extends the family reference earlier on this page across all three tiers. For the IG5638 we only list what matters for recovery. Rossmann does not currently offer in-lab recovery for the Innogrit IG5638.
| Tier | Controllers | PCIe Generation | Target Market | PC-3000 SSD Support | Recovery Path |
|---|---|---|---|---|---|
| Shasta | IG5208 / IG5216 | Gen3 | Entry / client | Not supported (board repair only) | Board-level repair of the original controller |
| Rainier | IG5220 / IG5236 | Gen4 | Consumer flagship | Not supported (board repair only) | Board-level repair of the original controller |
| Enterprise | IG5638 | Gen4 x4 | Enterprise / data center | Not supported (board repair only) | Board-level repair of the original controller |
The tier changes the interface generation. Reviving the original controller is still the only way to reach the data. Board repair on these PCBs is $900–$1,200 for the NVMe tier. +$100 rush fee to move to the front of the queue.
Encryption Barrier: Why Chip-Off Will Not Work on Innogrit SSDs
Customers researching SSD recovery often arrive with the assumption that NAND can be desoldered from a dead drive & read on an external programmer to reconstruct the data. Where the AES engine is active it sits between the NAND & everything else, & the key never leaves the controller die. This section explains the constraint in concrete terms & ties it to the recovery decisions we make at intake.
Inline AES Engines in the Innogrit Data Path
Innogrit's own product page lists AES 128/256 as a security feature on the IG5208 Shasta, IG5216 Shasta+, IG5220 RainierQX & IG5236 Rainier. Where that engine is active, data written from the host is encrypted on the way to NAND & decrypted on the way back, and the key that unwraps it stays with the original controller.
See the donor PCB swap section for why moving the encryption engine off the original controller does not preserve access to the data either.
What Chip-Off Actually Returns
The user data region is encrypted & indistinguishable from random bytes without the media key. Reading the NAND off the board does not yield files; it yields ciphertext.
Donor-controller transplants fail in practice for the same end-result reason. A donor IG5236 or IG5220 can't decrypt the original NAND. This holds whether the donor controller is transplanted onto the customer's PCB or the customer's NAND is migrated onto a fully donor board.
The Path That Preserves the Key Hierarchy
The only recovery path that keeps the AES-256 key hierarchy intact is the one where the original controller wakes up & boots its own firmware. That is what makes board-level hardware repair the legitimate Innogrit recovery service, & it is the path the support-matrix disclaimer points to. PMIC replacement, MLCC repair, voltage-rail restoration, & BGA reflow on the original controller are the procedures that bring the silicon back online with its encryption engine intact. Once the controller boots, it decrypts its own NAND & presents plaintext LBAs over standard NVMe to the imaging host.
If the controller die itself is the failure point (not the PMIC, not a discrete passive, not a cracked solder joint, but the silicon itself), the encryption engine is unreachable. NVMe board repair pricing, when the repair path is viable, is $900–$1,200; 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.
Power-Rail, Reference Clock & PHY Drop-Out Diagnostics
Power-Rail Diagnostics
The M.2 connector supplies only 3.3V to the drive.
The diagnostic pass is a multimeter sweep at each PMIC output pad with the drive on a current-limited bench supply. The repair is a Hakko FM-2032 microsoldering job on the original PCB, not a chip-off & not a donor-controller swap.
PCIe Reference Clock
PCIe Gen4 runs at 16 GT/s on the wire. The host motherboard supplies a 100 MHz reference clock over the slot. Separately, ASMedia PCIe bridge designs use a 25 MHz external crystal.
Intermittent PHY Drop-Out vs. Permanent Firmware Panic
These two failures arrive on the same drive families & sound similar over the phone. They have different diagnostics & different repair scopes, so the bench separates them early. The shorthand below is what we apply to every Innogrit drive that boots far enough to enumerate at all.
| Signature | Intermittent PHY / Thermal Drop-Out | Permanent Firmware Panic |
|---|---|---|
| Capacity reported | Correct capacity between crashes | Same wrong capacity across every reboot |
| Behavior after cold reboot | Drive reappears. Fails again under thermal or write load. | Drive remains in the firmware-panic state. No path back through power cycles. |
| Repair scope | Board-repair candidate. Hakko FM-2032 on the PMIC, MLCCs, or crystal; Atten 862 for oscillator swap. | Reball / reflow candidate on the controller package using Zhuo Mao precision BGA rework, only if the fracture is the cause. |
On the host side, a drive in permanent firmware panic enumerates with the silicon descriptor & the wrong capacity. There's no BSOD, just no data.
The honest limit is still the ACELab support matrix. If the controller die itself has failed internally rather than at a solder joint, no public PC-3000 toolchain in 2026 has a firmware-level recovery path for Innogrit silicon. Board repair returns drives where the controller is alive & the PCB around it is broken; it does not return drives where the controller die is dead. NVMe board repair: $900–$1,200. +$100 rush fee to move to the front of the queue.
Innogrit SSD Recovery FAQ
How much does Innogrit SSD data recovery cost?
What does it mean when my Innogrit SSD reports the wrong capacity in BIOS?
My Innogrit drive stopped working during a vendor diagnostic scan. What now?
Can recovery software fix a dead Innogrit SSD?
Can chip-off recovery work on Innogrit NVMe SSDs?
Can a power outage permanently damage an Innogrit SSD?
What is the difference between the IG5236 and IG5220 for recovery?
My Innogrit SSD takes 30+ seconds to boot after a crash. Should I keep restarting?
Why can't you use PC-3000 SSD on my Innogrit drive the way you would on a Phison drive?
What does it cost to attempt board-level repair on a dead Innogrit SSD?
Can chip-off recover data from a dead Innogrit SSD?
What can Rossmann actually do for an Innogrit drive with a dead controller?
Does Rossmann recover data from IG5208 Shasta drives & USB enclosures like the ADATA SE800?
My ADATA XPG S70 Blade throws KERNEL_DATA_INPAGE_ERROR but reappears after reboot. What is happening?
Why does the IG5236 controller still die even though it has a heatsink and good case airflow?
Can wear-leveling exhaustion on my Innogrit SSD be repaired in software?
Can I send my Innogrit-based ADATA or Netac SSD to Rossmann for recovery?
What is the difference between the Innogrit IG5236 and IG5638 for recovery?
Can Rossmann recover data from an Innogrit IG5638 enterprise SSD?
Since 2008
Established
As Featured In
If your Innogrit-based drive is locked in a firmware panic or dropping off the PCIe bus, send it to our Austin, TX lab for ssd data recovery evaluation. No diagnostic fee. No data, no recovery fee.
Related services
Need Recovery for Other Devices?
M.2, U.2, PCIe NVMe drives
Mechanical HDD recovery
Soldered SSD recovery
SSD array recovery
Similar NAND flash
View complete catalog
Directory of SSD controllers: Silicon Motion, Phison, Samsung, Marvell, Maxio, Realtek, InnoGrit
Innogrit SSD reporting the wrong capacity, stuck in firmware panic, or not detected?
Free evaluation. NVMe recovery from $200. No data, no fee.