@plutomaniac
Sorry for the delay in getting back to you on this. Here’s meinfo -verbose when run under FreeDOS.
https://pastebin.com/sQtFjyzq
Cheers.
The log doesn’t help because the firmware is not reporting back its read/write status due to corrupted MFS. Let’s test it manually. Dump the CSME region (fptw -me -d me.bin) and then try to flash it back (fptw -me -f me.bin). Does it work? If not (cpu access error), you’ll need to try the other methods mentioned above.
@plutomaniac
As you predicted, I get “Error 451: The host CPU does not have write access to the target flash area. To enable write access for this operation you must modify the descriptor settings to give host access to this region.
FPT Operation Failed.” when trying to flash me.bin back. I’m heading off to work now, but I’ll give your EFI method a go later tonight/tomorrow and let you know how that goes.
Thanks again for your help with this, it’s very much appreciated.
Hi again @plutomaniac
Booted into the EFI/grub shell provided in your earlier post and ran “setup_var 0x6ED 0x01”. The command seems to have run okay; “setting offset 0x6ed to 0x01” was the last line of output from the command (after a few errors complaining about non-matching GUIDs, if that’s relevant?).
My system then refused to boot no matter what I did - the fans would spin up, but I’d get no video even from the onboard video card. After putting the latest BIOS onto a flash drive and using the BIOS flashback button on the board, that got me back into the BIOS and I was able to boot back into Windows once again. I was still getting the “HECI disabled” errors on POST.
I’m now still getting 'Error 451: Host CPU does not have write access to the target flash area.'
Out of frustration when my board wouldn’t POST at all after running the setup_var command, I decided to contact Amazon and they’ve agreed to send me a replacement board, so I guess this is the end of this saga.
Many thanks for your help, @plutomaniac - it’s been much appreciated.
------------------------------------
Just as a follow up to all of this - I figured before I go and swap out my motherboard I’d try re-seating my RAM one DIMM at a time. Turns out I have one faulty DIMM. The system wouldn’t POST at all with just the faulty DIMM. Removing the faulty DIMM now gets rid of the HECI disabled error and allows me to update the Management Engine as expected.
I was fed up with particularly (by FWUpdLcl64.exe) updated ME being downgraded again after BIOS flashing. So I took the risk and updated the ME region in the BIOS file following virtualfred’s guide.
Everything went flawless: Gigabyte Z77, new ME version 8.1.70.1590.
So what’s wrong with that guide? Is it applicable to older platforms only?
Many things are wrong with it (old version, wrong assumptions, redundant steps etc), there is no point in explaining in detail. Follow the CleanUp Guide to do what you want.
Should I bother trying to update v11.8.50.3425 to v11.8.50.3426?
Also, is it as easy as replacing the .bin that’s with the Intel ME Update Tool_ME118H download from MSI?
(done it before in the firmware thanks to help from here, just wondering if they where derp enough to let the updater work with newer versions)
I think i accidentally used FPT with wrong parameter (i think i used: fpt -i me.bin) trying to revert Intel ME 9.1 to 9.0 firmware using FDO jumper on motherboard (to unlock flash descriptor), the system is unable to boot, fans are running, but no post screen or whatsoever 
Anyone knows how to recover BIOS? Do i need to program EEPROM?
The FDO jumper is not documented very well, only relevant info i could find was:
@ Net7:
It is as easy as using FWUpdate tool, as explained at the first post. OEM “updaters” are just pretty-looking FWUpdate wrappers.
@ RvdH:
Honestly, if you think you used the wrong parameter then you don’t take SPI flashing seriously, which is the fastest way to end up with a brick. FPT is a very dangerous tool when used carelessly. Parameter “-i” does not do flashing, only shows info, so that’s not what you used. You haven’t explained what “me.bin” is but I’ll assume that it is an Engine firmware region only (not full SPI/BIOS with FD). I’ll also assume that you used parameter “-f” so you basically flashed an Engine region at the entire SPI chip. Another assumption is that you ignored the warning gave by FPT that the size of the firmware to be written is smaller/different that the SPI chip’s. If I’m right then yes, obviously that lead to a brick-fest and yes, you’ll need to use an external programmer to re-write the entire SPI chip.
@plutomaniac
Yeah, i know I f**ked up big time, i should have come here to ask for advise first 
I ordered both the black and green CH341A-based programmers on ebay, should arrive here any day now
The motherboard has a ROM_RECOVERY header, so I am going to try (this method) to restore the bios using the CH341A
I hear the green version supplies proper voltage so I would start with that first.
Yeah, only if I had just 7(6 used for recovery) pins, my board has 2 additional pins above GND and SPI_CLK as displayed on that other topic…don’t know what these are for!?
Or could these be just to store/place the jumper removed from SPI_CS# pins?
Yes I see, your header has two extra pins. The motherboard is from Pegatron, but they don’t make motherboards themselves anymore so finding info online is even harder. Since I don’t know these things, I suggest you ask HP support, both at the forums and their official channels. I don’t think they’ll mind explaining the pinout of the 10-pin ROM_Recovery header but you never know. The above picture does come from their forums. Otherwise, I would personally treat the extra two as irrelevant and try my luck with the known header pinout (8).
@plutomaniac
You are the only person left who can help with this.
Prema has been trying to help me but even he has been unsuccessful
My ME is stuck in “temporarily disabled” mode yet doesn’t seem to be “Corrupted”, because I disabled the ME (under PCH FW) to see what would happen. But now it’s in temporarily disabled mode even if I re-enable it.
Every time I try to ‘enable’ or ‘disable’ it again and save/exit the Bios, the Bios does a FAST reset, like a 1 second on/off, instead of the proper 5 second off. I noticed that, back before i started messing with that, when I went to Intel ICC and changed Spread Spectrum from .50% to 0, when I saved that, it also did a ‘fast’ reset. I don’t know if that is the cause of the problem or if the spread spectrum is being ‘forced’ to 0% because the ME is temporarily disabled, but why is this happening? why would it ‘warm’ (fast) reset when I try to re-enable it and it says ME temporarily disabled?
Here is the output from MEMANUF -verbose.
----------
CurrentState: Disabled
ManufacturingMode: Disabled
FlashPartition: Valid
OperationalState: Transitioning
InitComplete: Initializing
BUPLoadState: Success
ErrorCode: Disabled
ModeOfOperation: Temporary Disable mode
SPI Flash Log: Not Present
Phase: BringUp
ICC: Valid OEM data, ICC programmed
ME File System Corrupted: No
PhaseStatus: UNKNOWN
FPF and ME Config Status: Match
Error 86: Communication error between application and Intel(R) ME module (FWU client)
Error 125: Internal error (Could not determine FW features information)
Error 117: MEManuf Operation Failed
Do you need the hex flags above this?
You have given no details about what system you have or what you did to cause the issue. I assume you’re using modded BIOS which has unlocked (unsupported/untested) settings. Provided that the Engine region was not touched, this should be bad BIOS NVRAM. Re-flash your backup BIOS or the stock one (including NVRAM), clear CMOS and see if that solves the problem.
Hi, sorry, it’s a MSI GT73VR 7RE laptop. And I set the option “ME State” in PCH FW field, from enabled to disabled, which “temporarily disables ME” Yes the bios is unlocked!
However it won’t re-enable.
I’ve tried clearing the CMOS (full cmos clear; date resets to 01/01/2010), no effect.
Tried reflashing an older Bios (Up to 1 year old), no effect. I tried disabling and re-enabling the ME in the oldest bios available (1 year old), no effect; still ME temporarily disabled.
I tried flashing a Bios backup (APTIO user capsule only, 6144 MB size); I made sure of course I flashed officially to the same version I backed up first. it did not have the ME backed up as I had no read access for that, but did have the NVRAM backed up. flashing worked but still “ME temporarily disabled”. I tried pulling the battery out for 5 minutes, etc…nothing worked.
The system is still fully functional, except I don’t have BCLK Control, Intel ICC (integrated clock controller) section is not accessible except for the Watchdog on/off field, and I can’t access the original setting I changed which caused the “warm” reset originally (Only happens the first time), setting spread spectrum from 0.50% to 0%.
Whenever I try to re-enable the ME (or I try to use “disabled”) again, the system does a fast reset instead of a slow (5 second) one.
If I turn off the value in the “ME Debugging” section, “don’t Ignore DID message” to disabled (forgot if this is the exact name, but the default value is enabled), the system takes about 60 seconds to POST, then i see the ME version (11.8.50.3425, instead of 0.0.0.0) and the ME status looks normal, but it’s still not working since CPU speed is still 0 mhz, ME firmware integrity is 2, but firmware status 1 shows 0x80000000 (status 2 has a different hex code). Needless to say it’s clearly not initialized right. If I changed that don’t Ignore DID option back to enabled. it goes back to “ME temporarily disabled”
It can be either bad NVRAM or bad CSME configuration. The latter can be fixed by re-flashing MSI’s Engine region. Do you have read/write access to the Engine region of the SPI chip? Try to dump it via Flash Programming Tool’s “fptw -me -d me.bin” command. Does it work or do you see a cpu access error? If you have a “Me FW Re-Flash” option (or similar) at the BIOS and enable it, can you then dump the Engine region? Otherwise, do you have a programmer?
Yes I do have a Skypro Programmer and a Pomona 5250 clip, although I’d rather not break that out except at last resort (would have to re-do liquid metal paste and pads on the GPU, since MSI, in their infinite wisdom, put the Bios chip UNDER the MXM GPU! (marked red dot, there is a blue dot on the underside of the mainboard (requires disassembly) which is either the EC firmware chip or a backup chip).
Yep I get the CPU permissions access error when I try to use FPT in DOS. (CPU does not have read access, or write access). Same error in windows. Unfortunately, the ME FW Reflash option does not work because of the ME Disabled state. If I enable that option, it disables again on the next POST.
I manually extracted the EC from the original MSI UEFI/bin firmware file, with uefitool and tried writing it and got the write permissions error.
I also THINK while I was messing around, I saw a “ME firmware downgrade failed” very briefly, and not sure why.
It was after trying to force one of those options to work again. Might have to disable the MSI logo splash and see again.
Usually there are two options there: ME FW Reflash (default-disabled) and Local FW Update (Default:enabled).
When the ME was still activated, there was no problem with these options. But the “Local FW Update” setting is completely gone now, with the ME in a disabled state.
I know about the setup_var and EFI boot disk option as I already made one. Should i use that setup_var setup_var 0x6ED 0x0 command you mentioned or the setup_var 0x6A9 0x01"? What is the difference between them? Your instructions said to :
3. At the EFI shell, run “setup_var 0x6A9 0x01” command
4. Reboot manually/forcefully via Ctrl+Alt+Del or similar
5. Run Flash Programming Tool with the command "fptw -me -d me.bin"
6. If it completes successfully, compress & upload me.bin file
But you also mentioned 0x6ED 0x0 command, which scared me because the poster who tried that had a Bios Brick when he tried to reboot.
I’m not exactly in the biggest hurry because I really do not want to break out the programmer if I don’t have to. Repasting liquid metal and reapplying foam dams (to stop any LM runoff) is a huge pain (plus my back medical issues). My laptop is otherwise fully functional (no shutdowns, no time-outs, no spammed windows event viewer logs), and BIOS upgrades do not fail, so at the moment, it’s stable. Unfortunately, MSI’s own UEFI firmware updater (done through bios) won’t downgrade the ME if its a higher version–even if it’s fully functional (Checked on NBR forums); MSI pulled the .320 bios version because of the intel ucode recall, and put up .31E.
Thank you greatly for your assistance, by the way.
The setup_var method is used to trigger the hidden “Me FW Re-Flash” BIOS option so it is of no use to your case. Its offset is BIOS specific too, not constant. There are three options before resorting to using the programmer:
a) Use the in-BIOS “UEFI BIOS Update” and make sure to have “Reset NVRAM” Enabled before flashing.
b) If that does not help, you can extract the latest stock MSI BIOS region via UEFITool and flash it via “fptw -bios -f bios.bin” (just in case the in-BIOS flasher does not do its job properly - unlikely)
c) If that does not help, it is almost certain that the CSME firmware settings need to be repaired. You can try the “pinmod” method which requires shorting two pins at the audio chip during POST in order to unlock FD access until the next reboot. What audio chip do you have? Have you found its datasheet which shows pinout?
If you believe that you’ve already repaired the BIOS and/or NVRAM (“Reset NVRAM” was indeed selected at your prior attempts and you returned to stock menu layout + CMOS reset) then you can try option C first. By the way, when I say “stock” MSI BIOS I mean exactly that. Don’t reflash the modded one for now. The goal is to remove as many parameters to figure out where the problem is exactly.
Thank you for all the time you have spent to help me so far.
I should say I AM Using the FULLY STOCK BIOS. There is a bios unlock key combination you can press that unhides the Bios menus.
There is a ‘different’ combination which access “Hybrid Power” which I do not know how to access or what the combo is, but that’s a different story.
I THINK there may be a way for me to get the “local FW update” (which is vanished) and possibly ME Image re-flash to ‘stick’, if I can deal with the 60 second posts.
If I set “ME DID Disable” to disabled, this prevents the DID from being sent, which lets the ME get “seen” by the Bios instead of reporting 0.0.0.0, but it is still not functioning properly as I said (no BCLK control), but the 2 'missing" options that are not appearing, wind up appearing if I do this.
I may then be able to try force flashing the ME file after I do that. I’ll keep you posted.
I’m not in a hurry to do this because as I said, unlike many people who had 30 minute reboots or bizarre issues, my laptop is still working “perfectly” otherwise. The MSI official flasher (done through BIOS) does reset the NVRAM, but it does not manage to remove the ME temporarily disabled status. I know for a fact that in the OLD version of the ME, the bios COULD restore it if you disabled it (i last did that last August, succcessfully).
Thank you 