The AMI Capsule header must always be removed when flashing with programmers or general software flashers such as Intel FPT, flashrom etc.
@Winter17
Any luck flashing your rom? I read you were having difficulties. Very important to make sure that the test clip is on correctly and that your using the correct version of the support software for the ch341a. Wonder did the software recognize your chip? Do you have the right drivers installed? How have you connected to your programmer?
OK so just wanna make sure I am doing it correctly:
I downloaded the latest firmware from Asus for Z9PE-D8 WS which is v5802.
Opened it with UEFITool and extracted as is from the Intel section.
Opened the new Intel only section rom and inserted NvmEpressDxe_3.ffs at the end of the 3rd BIOs region section.
Correct!
If that’s what Fernando says at his guide, then that’s what you need to do.
Woot, it worked fast and simple
Nope. No luck. Could not get it to recognize the chip. Think I had the right driver installed. I used a laptop for programmer and clip on bios chip. Tried the board in standby power, no go.
@Winter17 ,
When I did mine I watched a lot of youtube videos studying how the wiring was and making sure pin to pin was setup correctly. I actually bought two programmers. One worked and another didnt. Thats just how it goes I guess.
Most likely your problem is voltage sag. When you put the test clip on a chip in-circuit you are essentially powering the entire 3.3V circuit. USB programmers don’t supply enough current to power the whole circuit so the voltage drops. When I put a multimeter across pins 4 & 8 I watched the voltage drop to 2.5V when trying to power a MXIC MX25L1606E chip in a Lenovo M92p system. Powering up the computer allowed the voltage to remain steady at 3.3V (because the system’s PSU was supplying all the current needed on the 3.3V rail the SPI programmer didn’t have to) but I still had trouble reading the chip. I suspect something with the startup process of the board was holding one (or more) of the data pins high (or low?) and preventing the programmer from reading it.
I finally wired up a variable DC power supply to pins 4 & 8 on my CH341A programmer, used the V-hold function to lock it to 3.3V and slowly increased current until voltage reached 3.3V. At the point I was able to successfully read the BIOS chip in-circuit.
I purchased this unit but the 5A unit should work just as well. Really even a fixed 3.3V DC power supply would work fine, and you can find those pretty cheap. In my testing I didn’t need more than about 600mA to get the voltage to hold at 3.3V.
I have also watched a load of you tube. Would help greatly if I could speak freaking Russian. 
Pretty sure I got the connection correct, not sure the power is being delivered correctly to get it to detect the chip. 
@Winter17 ,
That looks correct assuming you have the adapter in the right slot and match it with a 25XXXX chip. Fwiw I am using version 1.18 of the CH341A software. Non of the other versions worked for me.
Only other possibility is that the clip not making a good contact with the leads running off of the bios chip maybe.
I have the same version of software. I have a new cpu block on the way. When it arrives next week I will be taking mobo out for install. I will take another shot at this then.
My bios chip says MXIC MX 25L12873F M2I - 10G. You can see them just to left of battery.
That chip is not listed in drop down menu for programmer but I suspect this would not matter for detection.
@Winter17 ,
Just wondering using the Asus Flashback procedure does not reset your ME? Is it suppose to in general?
On my Asus board it reset my ME to an older version. Maybe mine wasn’t locked like yours…
I am able to flash a bios to chip # 1, but it does nothing to ME region. All the current bios’s out for my board have the older FW version ending in 1287. Maybe a newer bios with an updated MW FW will take, I have no way of knowing. I am not capable of taking an asus bios and updating the ME FW in that bios.
I have used all methods to flash a bios including Flashback, all flashed fine, but none changed ME FW.
I can’t even load MEI drivers on the bios in question when in windows, just errors out.
@Winter17 ,
Will this work… If you have two bios chips switch to the good working one and update the ME to one version greater (avoiding same issue as before), and then run FPTW64 -d dump.bin. Use Uefitool to re-encapsulate it, rename it according to the flashback naming scheme, switch to faulty bios chip and reflash?
My second bios was updated a few days ago with an update tool Asus released for my board.
Second bios is now running ME FW version 11.11.50.1436. Flash went without issue and all good on second bios. This tool will not work on bios 1.
I have never used UEFI tool, and have no idea how to do what you mentioned.
Now i can open up the update tool and the FW is there, the new one I mean. It is simply called ME.bin
@Winter17 ,
I think Ubu Tool automatically re-encapsulates the rom file. First your going to need to download the latest ME consumer system tools that is compatible with your board. Theres a utility in there called FPTW64 that you can use to dump an image of your bios and even flash your rom within windows in an admin dos window. Not sure if the rom needs to be in Cap form or not. I think if you use that tool probably not but I wouldnt bother. Just Flashback it as a Cap file. This might be an easier path than using a Ch341a programmer… assuming you can flashback to that bios chip.
I appreciate all the ideas but I am going to pull the plug on all this. Editing bios’s is not something I have any experience with. I would be just going in circles at best. Right now my second bios is fine, board is fully functional.
The next bios release from Asus will have an updated ME FW built into it. I will give flashback a try then. Many thanks…
Hello everyone,
I have a problem successfully replacing BIOS chip in my ASUS Z170-A to resolve my Intel ME firmware update issue. I bought two empty Winbond W25Q128FVIQ chips and flashed them using black CH341A programmer with 1.18 version of Windows software and with flashrom from Ubuntu 16.04. I followed the following procedure - download BIOS .CAP file from ASUS, use FD44Editor to copy serial, UUID and MAC from my BIOS backup and create a .bin file, flash .bin file, verify that it flashed correctly.
However, when I replace my old working BIOS chip with one of the newly flashed ones - the only way that I was able to have the system boot was when I replaced the old chip with the new one while the system was shutdown but not disconnected from the powerline (i.e. the PSU is connected and the green light on the motherboard is lit). Computer boots up, works with the new chip and can reboot. However, if I shut it down - it doesn’t boot again with the new chip - computer just powers on, fans are spinning at max rpm, the screen is black and nothing is happening. The only way to get it to work again is to replace the BIOS chip with the old one.
If I disconnect PSU from the powerline and drain the remaining charge by pressing the powerbutton until the lights on mobo shut down, clear CMOS by removing the battery, and only then replace the old chip with new one - same symptoms (max fan rpm, black screen, doesn’t boot).
Chips are the same model as in my motherboard, the only difference I noticed is the 4-digit number (new ones have 1309) below model number (W25Q128FVIQ) on the chip face. The old BIOS chip works fine, except for the wrong Local FWUpdate setting that cannot be changed and prevents ME firmware update. So I prefer not to flash the old one, as that way I at least have a working system.
Can this behavior be caused by the fact that new chips are not from ASUS? Or is the something else I am missing?
By the way, ME firmware update worked with new chips both with the original BIOS (0504) flashed and with the latest (3703).
Looks like something fishy with ME or VSCC table (powering the system off resets the ME, and it can’t start from the new chip). Also QuadSPI may be enabled by default on original one and disabled by default on a replacement one, but if letters are the same, it shouldn’t be the case.
TBH, I don’t know the exact reason and don’t want to speculate. This needs proper investigation with SPI transaction dump…