@lfb6
Thanks for your interesting experience.
On my side the BIOS chip is very recent as the mboard is a very recent design (ASUS Prime Z390M-Plus).
As you can see on my screenshots posted the CH341A Software does indicate: “Device state: connected”
Device state Connection is quite stable: No alternate red warning ‘not connected’ message with ‘connected’. So, I don’t suspect any ‘bad’ electric contact.
My CH341A Pro Programmer and Clip are also recent.
Do you use a CH341 or a CH341A Programmer ?
Do you use W7 or W10 interface ?
I got a green and a black CH341, both are CH341A, the black one states CH341APro. W10Pro, 1809, 64bit (1709 did work, too- never worried about Win10??). Not reading 128MbChips is possibly software related, never tried newer CH341.exe versions than 1.29, but could today program a Winbond 25Q128FV properly with a CH341A and ASprogrammer 1.3.14.
Yes, recognizing a disconnected programmer is quite easy. But when I disconnected ground (pin4), everything worked fine, "reading" the chip without any complaints but delivering only FFs.
This does confirm the problem is more a hardware problem somewhere and not really a W10 problem.
Do you plan to use CH341A Software v1.34 and ASProgrammer v1.4 for your tests ?
ASprogrammer 1.4 seems to work with both CH341A programmers for Winbond 25Q128FV, too. I think that’s good enough for me…
I never spared a thought on Windows 10 by the way, I always use the programmer/programming software as a normal user (UAC fully enabled) and there was no difference between Windows 7 and Windows 10?
Thanks for the information that for you ASProgrammer v1.4 does work fine under W10 as well as under W7.
On my side I am stuck with no Programmer solution working for the BIOS chip for any of my two ASUS Prime Z390M_Plus mboards.
I didn’t check ASprogrammer 1.4 under W7, I used the CH341A with Software 1.29 and TL866 under Win7.
But: Just to be sure I tried now ASprogrammer 1.4 under W7 in a virtual machine (host W10P x64 1809) and it’s working fine with a DIP8 25Q128FV. I assume that a native W7 would do, too.
Made some experiments, though:
For a DIP8 25Q128FV you can disconnect GND(4), IO3(7), IO2(3)- it doesn’t matter. If you in addition disconnect CLK(6) or IO1(2) or IO0(5) you get everything FF FF (means both chip identification and data).
More interesting, maybe:
If you disconnect CLK(6) or IO1(2) or IO0(5) alone you still get everything FF FF, ASprogrammer14 not complaining at all!
@lfb6
Thanks a lot for sharing your experiments.
You are right I had a contact problem with the Clip Board !!
I do significant progress and finally do succeed today under W10 x64 with ASProgrammer v1.4 as well with CH341A Software v1.34:
@Lost_N_BIOS
I "ll send you a PM about ASUS Z390M-Plus modded BIOS file to use for CH341A programmer.
However, a strange situation because Read/Verify operation does fail with CH341A Software v1.34 and is OK with ASProgrammer v1.40 (test done twice):
So, what Programmer Tool is good ?
Tested with CH341A Software v1.40 the Read/Verify operation is OK under W10:
Nota: I do observe CH341A Software v1.34 Read/Verify operation always does fail at about 50% of the operation. Is it a buffer size limitation bug ?
With my Z390 board I had to use the 1.4 programmer from LostNBios for it to work right. And I used Windows 7 but dunno if it works in Windows 10.
@KedarWolf
With CH341A Software v1.40 Free under W10 interface the Read/Verify operation is OK on my side.
Which Z390 mboard do you tested ?
Z390 Aorus Master. It reads, writes and verifies correctly, and I can boot from the BIOS when done.
I really don’t know, which programmer tool is "best". And: Do you mean hardware or software?
I would never rely on the verify function of the software alone. I program the chip, read it back and compare source- file and the file read from the chip on the PC. (For all Windows versions and back to MS-DOS a simple ‘fc /b source.rom readfromchip.rom’ in a command window will do)
You actually don’t know what happened with these three softwares when you don’t read back the SPI and compare it with the source. When comparing results you should also compare the rom read back from ASp1.4 with the roms read back from both versions of the CH341- programmer. Worst case is that all three are different…
The CH341A is a nice cheap tool, but there is sometimes a lot to worry about (mostly software)!
I don’t remember. It’s a removable socketed BIOS, but I don’t recall what it was detected as.
My BIOS chip is soldered (not socketed removable) and is a MICRONIX MX25L12873F, so may be very different from yours.
@lfb6
Thanks for your very interesting comments:
So, in my case (ASUS Prime Z390M-Plus) I do keep only 2 software programmer solutions running under W10 64bit v1809 interface :
1) CH341A Software v1.4
2) AsProgrammer v1.4.0
I have triple checked that for the both tools a “Read/Verify” operation is OK
and for the both tools a “Read/Verify/Save” operation does produce identical 16MB .bin saved file (checked with Hex Editor HxD tool v2.2.1.0)
Question: 'You don’t rely on the Verify function of the software alone.'
But, I am not sure to understand your ‘verify’ method:
Does your “Verify” method consist of these successive operations :
1st_Read_IC_Memory => Save ‘File_1’ => Program from the saved ‘File_1’ => 2nd_Read_IC_Memory => Save ‘File_2’ => Compare (HxD tool) ‘File_1’ and ‘File_2’.
‘File_1’ and ‘File_2’ should be detected as identical files via the ‘Compare’ function of HxD tool.
But if the files are not identical you have programmed your BIOS with may be one uncertain file and may be your BIOS is bricked ?
Do you confirm I have well understood your ‘risky’ Verify method ?
Normally I start with a changed bios file I want to flash, that’s my source file. I program it into the chip and if the program says ‘Verify OK’ I read the content of the newly programmed chip again, save it and compare it to the source file once again on the PC.
May be a bit paranoid, but I don’t trust especially the CH341 programmer software too much here. What do you mean is risky?
I understand you check that your changed bios file is well properly programmed into the bios chip.
But if your changed bios file does brick the bios chip contents you have to recover the bios chip contents with a good reference bios file.
So, I assume you have somewhere archived a 100% sure reference bios file for a ‘recover’ operation to avoid the risk to have a definitevly bricked BIOS.
Is it correct ?
Like you, my preference is definitively AsProgrammer v1.4.0 under W10 interface.
Do you use ‘Blank check’ function ? What is it ? What is the purpose ?
When we use “Erase” function it is a “FF” fullfillemnt or a “00” (blank ?) fullfilement with this tool ?
So, all sorted out now finally @100PIER ? Sorry I was gone for a lot of your recent hassles with this, I’m so far behind it’s not even funny! 
Some PM’s I’m behind a month, and new reply threads I need to get into on the forums I’m behind 6-7 pages or more
Blank check is used to ensure your previous erase command fully erased all the chips contents, erase fills with FF
Thanks, don’t worry. I understand.
So erase fills with FF and that does mean to “blank” the chip and the “Blank check” does seem only offered by CH341A Software v1.34 (not v1.4).
Morover AsProgrammer v1.4.0 does offer Erase but not the Blank Check function.
Erase means blank in a general sense yes, and then blank check checks and confirms that the entire chip was FF’d - I’ve not used it, but I can see blank check in 1.31/1.4 version, and all previous too.
ASProgrammer has blank check too, it’s to the right of the erase icon, in the verify drop out menu