When Flash Memory Won’t Identify: A Case of Missing JEDEC ID but Working Reads

Have you connected a flash memory chip correctly to your CH341 programmer, only to have the PC software fail to recognize it entirely? NeoProgrammer shows “IC not responding.” The Read ID operation returns nothing but 0xFF. Is the chip faulty? Don’t give up just yet. I’ll show an unusual case where certain memory chips simply don’t support the standard Read ID command – yet you can still extract data from them.

The Patient: A Macronix Chip from an Old Printer

The chip in question is a Macronix memory, removed from an old HP PSC1410 printer. I couldn’t identify it by marking alone, but the pin connections confirmed it was SPI flash. Only the pins corresponding to SPI (in a typical SO16 package) were connected to the main processor.

After hot‑air desoldering, I soldered the chip onto an adapter board for the CH341 programmer, carefully aligning pin 1 (using the notch). Everything appeared correct.

The Problem: No Response from Software

NeoProgrammer reported that the chip was not responding – the same error you get with an empty socket. ASProgrammer also failed to auto‑detect it:

Current programmer: CH341
ID(9F): FFFFFF (Unknown)
ID(90): FFFF (Unknown)
ID(AB): FF (Unknown)
ID(15): FFFF (Unknown)

The Workaround: Manual Chip Selection

I was about to give up when I decided to manually select a memory type in ASProgrammer. I guessed something from the MX25L1605D series. Surprisingly, the read worked:

14:03:45
Reading memory...
Done
Execution time: 00:01:19
CRC32 = 0x0149DE9F

A hex dump showed readable strings like “Boot” and “ERIDANI ERROR DETECTED”. NeoProgrammer, however, remained stuck on the ID check. The conclusion: this memory chip does not support reading its JEDEC ID, but it does support standard read commands.

Independent Verification Using BK7231GUIFlashTool

I tested the chip with my own tool: BK7231GUIFlashTool. The JEDEC ID came back as 0xFF 0xFF 0xFF. Yet, when I sent standard data read instructions, the memory read correctly with no protocol abnormalities. Based on this, I added a feature to my tool to bypass ID verification and allow manual declaration of the expected flash size.

Summary & Recommendations

It appears that the developers of NeoProgrammer may not be aware of such chips. ASProgrammer seems to work either by luck or because it attempts a read even when ID fails. In my opinion, CH341‑based tools should not give a misleading “IC not responding” error. Instead, they should attempt a sector read first and only then determine whether communication is possible. That approach would yield reliable results.

Have you encountered similar issues with flash memory? Or am I the one in the wrong? One thing is certain: my flash chip was readable, even though it didn’t return a JEDEC ID – at least not in the classical way.