Flash memory connected but programmer does not see it? Problem solved CH341 NeoProgrammer

p.kaczmarek2 28 Feb 2026 16:30 0 1431 Cool? (+13)

📢 Listen (AI):

TL;DR

A Macronix SPI flash from an old HP PSC1410 printer refused to identify through a CH341 programmer in NeoProgrammer and ASProgrammer.
Manually selecting an MX25L1605D-series device in ASProgrammer bypassed the failed Read ID check and enabled a full memory read.
Read ID returned only 0xFF bytes, while the program later logged a successful read with CRC32 0x0149DE9F in 00:01:19.
Standard data-read commands worked, so the author added CH341 flash reading to BK7231GUIFlashTool with ID verification bypass and manual size entry.
NeoProgrammer still reports 'IC not responding,' and the exact flash model remains unidentified.

Generated by the language model.

Have you connected the flash memory correctly to the CH341 programmer, but the PC program does not recognise it at all? NeoProgrammer shows IC not responding, is the chip faulty? The Read ID operation (reading the flash ID) returns 0xFF alone? Don't give up - here I'll show an unusual case demonstrating well that some memory chips simply don't support read ID and yet you can rip data from them.

Close-up of a PCB with a Macronix “MX” memory chip and other ICs

The patient is a Macronix memory, unidentified by me, from an old HP PSC1410 printer. The fact that it is a memory is evidenced not only by the marking, but also by the way the leads are connected. You can see here that only the pins that are responsible for SPI in the case of a typical SO16 chassis are just going to the main processor.

Pin configuration diagram for a 16‑pin SOP (300 mil) SPI memory with labeled signals

I hot-air stripped the memory and soldered it onto the board-adapter from CH341, making sure I positioned the first pin correctly (the so-called notch). Everything looked ok:

SOIC memory chip soldered on a blue adapter board next to a pin header

However, NeoProgrammer says that the chip is not responding. The same error is when there is an empty socket:

NeoProgrammer screenshot showing “IC not responding” error for MX25L6405D [3.3V] chip

ASProgrammer does not detect this memory either:


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

I was about to give up when something tempted me to select one of the memory types rigidly in ASProgrammer. I shot that it was something from the MX25L1605D series:


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

Surprisingly something was able to be read:

Hex dump view with ASCII column; readable strings include “Boot” and “ERIDANI ERROR DETECTED”.

I repeated the operation in NeoProgrammer - to no avail. This one is stuck on the ID anyway.
However, I quickly came to the conclusion that this memory does not support reading ID, but does support reading data.
It was time for a final verification, as I have my own programmer that supports, among other things, Flash memory via CH341 :
https://github.com/openshwprojects/BK7231GUIFlashTool

Screenshot of BK7231 Easy UART Flasher showing green “Reading done” status

Well yes, the JEDEC ID is 0xFF 0xFF 0xFF....
On the other hand, what happens if we nevertheless send standard data read instructions?

Screenshot of a flash read tool showing “Reading done” and a red-boxed log with JEDEC ID FFFFFF

The memory is read correctly, there are no more non-standard protocol changes.
As a result of this observation, I added to my BK7231GUIFlashTool (aka Easy Flasher - yes, the name needs to be changed) the ability to read the Flash bypassing ID verification and manually declaring the expected size.

In summary , it looks like the NeoProgrammer developers don't know about this at all, and the ASProgrammer developers either lucked into it, or forgot to mention it in case it is possible to read the first sector but not the ID. In my opinion, the CH341 handling tools should not give a misleading "IC not responding" message in such a situation (quoting NeoProgrammer), but should attempt to read one side and only then assess whether there is communication. Only this approach will give reliable results.
Have you encountered this type of problem with Flash memory? Or am I the one in the wrong? Well, undoubtedly my Flash was able to be read, and the JEDEC ID it does not return. At least not in the classic way...
PS: Does anyone recognise what specific Flash model I've shown here?

About Author

p.kaczmarek2 wrote 14336 posts with rating 12238 , helped 649 times. Been with us since 2014 year.

Comments

Add a comment

FAQ

TL;DR: If a CH341-based programmer shows “IC not responding” yet SPI wiring is correct, force a compatible chip profile and read anyway—one dump succeeded in 79 seconds, even though “the JEDEC ID is 0xFF 0xFF 0xFF.” [Elektroda, p.kaczmarek2, post #21850986] Why it matters: You can still recover data from some SPI flashes that don’t return an ID, avoiding false negatives and wasted time.

Quick Facts

Read-ID opcodes 0x9F, 0x90, 0xAB, and 0x15 all returned 0xFF on the tested Macronix-marked chip. [Elektroda, p.kaczmarek2, post #21850986]
A forced-read using an MX25L1605D profile completed in 1 minute 19 seconds (≈79 s) and produced CRC32 0x0149DE9F. [Elektroda, p.kaczmarek2, post #21850986]
NeoProgrammer stopped at ID check; ASProgrammer read data; custom BK7231GUIFlashTool added “bypass ID + manual size.” [Elektroda, p.kaczmarek2, post #21850986]
The target board was from an HP PSC1410; only SPI-relevant SO16 pins routed to the MCU confirmed it was SPI flash. [Elektroda, p.kaczmarek2, post #21850986]

Comparison (same hardware: CH341A)	Tool	Requires ID?	Manual size?
NeoProgrammer	Yes	No	Fails (IC not responding)
ASProgrammer	No (can force)	Limited	Read OK
BK7231GUIFlashTool	Optional (bypass)	Yes	Read OK

[Elektroda, p.kaczmarek2, post #21850986]

What does “IC not responding” mean on CH341 programmers?

It indicates the software didn’t get a valid JEDEC ID, not necessarily that wiring or the chip failed. In this case, all ID queries (0x9F, 0x90, 0xAB, 0x15) returned 0xFF, yet a full data read still worked when the chip type was forced. [Elektroda, p.kaczmarek2, post #21850986]

Can SPI flash read successfully if the JEDEC ID is 0xFFFFFF?

Yes. The reported Macronix-marked device returned 0xFF for every ID opcode but produced a valid dump with CRC32 0x0149DE9F after forcing an MX25L1605D-series profile. “The JEDEC ID is 0xFF 0xFF 0xFF,” yet data read was correct. [Elektroda, p.kaczmarek2, post #21850986]

How do I read a flash chip when NeoProgrammer won’t detect it?

Force a compatible chip profile and attempt a direct read. Example steps:

In ASProgrammer, select an MX25L1605D-series profile.
Start a full read; ignore ID errors.
Verify with CRC or compare multiple reads. This approach succeeded despite 0xFF ID responses. [Elektroda, p.kaczmarek2, post #21850986]

Which tools worked when ID read failed: NeoProgrammer, ASProgrammer, or BK7231GUIFlashTool?

ASProgrammer and BK7231GUIFlashTool worked. NeoProgrammer halted at ID verification. The custom tool added “bypass ID” plus manual size selection; ASProgrammer succeeded after forcing an MX25L1605D profile. [Elektroda, p.kaczmarek2, post #21850986]

What concrete timing result was observed during a forced read?

A complete dump finished in 1 minute 19 seconds (approximately 79 seconds) and produced CRC32 0x0149DE9F, confirming data integrity for that session. This result followed selecting an MX25L1605D-series memory in ASProgrammer. [Elektroda, p.kaczmarek2, post #21850986]

Why might some flash memories not support Read ID?

Some legacy or atypical parts don’t implement standard JEDEC ID opcodes, yet still support standard read commands. The reported Macronix-marked chip returned only 0xFF to ID opcodes but responded correctly to normal read instructions. [Elektroda, p.kaczmarek2, post #21850986]

How can I confirm the device is SPI flash without a datasheet?

Trace pins: only the SPI-relevant pins on the SO16 package were routed to the main processor on an HP PSC1410 board, indicating an SPI flash interface. This board-level signal routing is a strong functional clue. [Elektroda, p.kaczmarek2, post #21850986]

What error message can be misleading during CH341 reads?

“IC not responding” can be misleading when it solely reflects a failed ID read. In the reported case, the memory still read correctly once the software bypassed or ignored the ID step. [Elektroda, p.kaczmarek2, post #21850986]

Is there a workflow change suggested for CH341 software?

Yes. Attempt a small sector read before declaring failure. The author states tools should try reading one side first and decide based on actual communication, not only on ID queries. [Elektroda, p.kaczmarek2, post #21850986]

What edge-case behavior should technicians watch for?

A chip may refuse all JEDEC ID opcodes yet allow full data reads with standard commands. Forcing a similar family profile and setting size manually can succeed without nonstandard protocols. [Elektroda, p.kaczmarek2, post #21850986]

What specific opcodes failed and what succeeded in the case study?

ID opcodes 0x9F, 0x90, 0xAB, and 0x15 all returned 0xFF. Standard data read instructions succeeded, producing a consistent binary image and a CRC32 check value. [Elektroda, p.kaczmarek2, post #21850986]

What manual settings helped the custom tool recover data?

Enabling “bypass ID verification” and declaring the expected flash size manually allowed BK7231GUIFlashTool to read the memory over CH341 successfully. This change targeted ID-failing parts. [Elektroda, p.kaczmarek2, post #21850986]

Does forcing an MX25L1605D profile imply the chip is MX25L1605D?

No. Forcing a profile is a compatibility tactic, not proof of identity. The author asked if anyone could recognize the exact model; identity remained unconfirmed. [Elektroda, p.kaczmarek2, post #21850986]

Can you quote the key observation from the case?

Yes. “The JEDEC ID is 0xFF 0xFF 0xFF,” yet a full read via CH341 succeeded after bypassing or ignoring the ID check. This supports attempting reads before failing. [Elektroda, p.kaczmarek2, post #21850986]

What’s a safe, minimal test when detection fails?

Try a small block read first. If data returns with stable CRC across repeats, proceed to a full dump. If reads error or differ, re-check wiring and power before continuing. [Elektroda, p.kaczmarek2, post #21850986]

Where did this issue occur and who reported it?

It was observed on an HP PSC1410 board by user p.kaczmarek2 on February 28, 2026, documenting screenshots, timings, and tool behavior. [Elektroda, p.kaczmarek2, post #21850986]

Generated by the language model.