Alliance memory NAND Flash Stuck in OIP - Page 1
Forum section: electronics / beginners

author: HaithamDa
author_rank: Newbie
timestamp: August 21, 2025, 10:25:09 pm
content: Hi all,I’m working on evaluation boards that integrate the Alliance Memory AS5F38G04SND-08LIN QSPI NAND flash device. During our assembly/inspection flow, the boards are subjected to X-ray imaging.Here’s what I’ve observed:Initially, all devices were functional:• Register communication worked fine• Page program and data read were successfulAfter an additional X-ray exposure (~20 min, ~120 rad):• Register interface is still fully functional (read/write to feature registers works)• SPI interface signals look clean and correct on the scope• But we cannot access the NAND flash array anymoreThe main symptom: the device stays stuck with the OIP (Operation In Progress) bit set. This prevents normal read/program operations from completing.My questions:1. Has anyone encountered this OIP-stuck condition with this or similar NAND devices?2. Could this be related to a known status handling or protection feature (Block Lock, WP#/HOLD#, etc.)?3. Could X-ray/TID exposure at levels around ~120 rad be enough to cause this kind of NAND array failure while leaving register access intact?4. Does anyone have insight into the correct sequence for array read (Page Read → Cache Read, etc.) that might clarify whether this is a usage sequence issue versus a device issue?I’ve already reached out to Alliance Memory for guidance, but I’d also appreciate the community’s experience.Thanks in advance for any help!— HaithamReliability Engineer

author: HaithamDa
author_rank: Newbie
timestamp: August 22, 2025, 07:10:42 pm
content: Two clarifications, though:Our added exposure was about 120 rad ≈ 1.2 Gy, which is orders of magnitude below the multi-krad(Si) levels where many studies start reporting widespread failure in NAND (often tens of krad). I realize setups vary by energy and bias conditions, but 1–2 Gy is still relatively modest for TID.The same “OIP stuck” symptom shows up on some unexposed parts under certain sequences/conditions, which suggests a status/sequence or protection/state-machine corner case is also plausible (besides radiation).If anyone’s seen OIP never clearing after 13h (Page Read to cache) on SPI-NAND and has a checklist, I’d love the pointers. For reference, the AS5F38G04SND status/OIP and read flow are standard SPI-NAND (13h → poll C0h until OIP=0 → cache read 03h/0Bh/3Bh/6Bh). A few things I’m checking: ensure FFh reset between operations, but it didn't work, that feels more like an internal state/array path issue than pure host sequencing.(Separate note: I’m aware this device is now EOL, so alternatives are on the table—but I’m trying to close the loop on root cause for our process flow.)— Haitham

author: Kurets
author_rank: Regular Contributor
timestamp: August 30, 2025, 02:16:34 pm
content: I work in space electronics and sub 5 kRad exposure is (typically) not considered to need radiation hardness assurance. There are exceptions like analog switches relying on perfect matching to get low charge injection, but thats a general indicator.I would expect your issue is something else, factory rejects maybe? Were the chips bought via Alliance or authorized distributor? I have encountered Flas ICs with out of spec behaviour (in that case way too many bad blocks) being sold via brokers.

author: Haenk
author_rank: Super Contributor
timestamp: September 01, 2025, 06:22:07 am
content: In our early days of selling flash memory cards, we had reports of multiple cards being destroyed by eastern block airport XRAY machines, which likely put out a lot more power than western ones. Only years later the manufacturers stated "XRAY save" as a sales pitch.So you might want to ask the manufacturer, if the chips are suited for XRAY examination or not.

author: ahsrabrifat
author_rank: Regular Contributor
timestamp: September 04, 2025, 05:37:12 pm
content: “stuck busy / OIP = 1” is a repeatedly-reported symptom with SPI/Quad-SPI NANDs when something in the device’s internal state machine, array transfer, or error handling gets into a bad state.https://forum.allaboutcircuits.com/threads/alliance-memory-nand-flash-stuck-in-oip.207823

author: paulca
author_rank: Super Contributor
timestamp: September 05, 2025, 10:13:24 am
content: I'm watching. I have miss behaving flash chip which locks up in the programmer 20% of the time, only remedy is to "hot plug" it with the programmer running.

author: masterburner
author_rank: Contributor
timestamp: September 08, 2025, 09:28:09 am
content: I'm having the same issue with the exact same part number (I'm TheCrazyInventor over at allaboutcircuits.com where ashrabrifat is linking to. I'm not using any ionising radiation though).When I use a similar NAND chip from a different vendor, the problem goes away, so I'm reasonably confident that this is a hardware issue. All SPI communication has been verified using an oscilloscope and logic analyser. All SPI timings are well within the datasheet spec and the signal integrity is good.Just to summarize my contribution to the allaboutcircuits thread:OIP bit gets stuck sometimes after sending command 0x10 (Program Execute). OIP goes high, but never back low again. The only way to bring OIP low is to completely remove Vcc from the IC.We're using an NRF5340 running Zephyr OS (Build v3.1.99-ncs1-1) and nRF Connect SDK V2.1.2. We've developed the NAND driver and Zephyr disk driver in-house. The file system library which is used by Zephyr is ELM FAT.For reference, the alternative flash chip is a Macronix MX35LF4G24AD-Z4I8. This is a 4Gb chip instead of 8Gb, but is fully pin compatible. The reason we picked this chip for testing, was because this was the only chip we could find that was pin and package compatible.The firmware was adjusted to accept the new device ID and the block count was lowered from 4096 to 2048 to make the new chip work.We aren't able to simply switch to a different flash IC for numerous reasons. I'm hoping someone else has seen a similar issue (and perhaps a work-around) as we need to get our product running reliably.