You have 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.
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.
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:
However, NeoProgrammer says that the circuit 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](https://obrazki.elektroda.pl/6007025600_1772291747.png "NeoProgrammer “IC not responding” for MX25L6405D")
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:
I repeated the operation in NeoProgrammer - to no avail. This one is stuck on 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
Well yes, the JEDEC ID is 0xFF 0xFF 0xFF....
On the other hand, what happens if we nevertheless send standard data read instructions?
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 Flash bypassing ID verification and with a manual declaration of 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 is it me who is 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 model of Flash I have shown here? />
Cool? Ranking DIY Helpful post? Buy me a coffee.
