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 
Well it doesn’t really matter if the problem is urgent to fix or not. As long as it got reported here and a discussion is underway, I will try to help solve it. The rest is up to the user. Our goal is to get read/write access to the Engine region (verifiable by “fptw -me -d me.bin” command) in order to repair it. If that requires a one time 60 second boot then I believe that’s more than acceptable. Once you have read/write access to the Engine region, re-flash it with the stock MSI SPI/BIOS Engine region, as extracted by UEFITool, using the command “fptw -me -f me_stock.bin” followed by “fptw -greset” upon success.
I disabled the DID From being sent
(and enabled Local FW update and ME image reflash)
and I saw an error:
(a7): Me FW Downgrade - Request MeSpiLock Failed
Then it booted to windows.
Still can’t read or write it with FPTw64 
Disabling the “DRAM Initialization Done” (DID) message does not help in this case because, AFAIK, the ME needs to be operational in order to accept messages such as the one send by the BIOS option “Me FW Image Re-Flash” which is called “Host ME Region Flash Protection Override” (HMRFPO). If you cannot get the “Me FW Image Re-Flash” option to work (on some BIOS it doesn’t do anything if it is not accounted for by the OEM as a recovery method) then you have to attempt option C, as explained above.
That makes sense, thank you!
I have the Realtek HD audio chip, with Nahimic and ESS Sabre, but I have no access to it, because that would require removing the mainboard. I would have to completely tear down my laptop and I’m not prepared for that right now.
Would just SPI flashing the entire MSI 8MB bios file into the Bios chip (it’s exactly 8192 MB) fix this issue? Repasting the GPU video card would be far easier than me dissembling the laptop completely. I’m not disassembling it now, but when I do wind up reflashing, do I just do the usual load->Auto-Erase->Flash->Verify with the Skypro software? (I’ve flashed my video bios before with it so I know the routine). Or would this not fix the CSME issue?
I don’t have any datasheets. I’m just a gamer. I bought the skypro, 1.8v adapter and Pomona clip and jumper cables for hard modding the GTX 1070 video Bios (TDP modding). I know the mainboard doesn’t use the 1.8v adapter (Pascal vbios does), but if it’s that simple, I can flash it on my next GPU teardown.
MSI’s latest SPI/BIOS update does include the contents of the entire SPI chip (FD + BIOS + ME), including the “stock” Engine region. So yes, a full SPI flash will solve the issue. I’m not sure if your BIOS contains system specific info such as Serial Number, Windows Key or similar but these will be lost if the default SPI/BIOS is flashed via a programmer, without the in-BIOS menu I mean. That’s not really important considering the other issue but I thought I should point it out.
I understand your point of view, I got it from all the mods you mentioned. Noone has datasheets at hand, you can just google them. But it doesn’t matter because if reaching the audio chip is even harder than using a programmer then obviously it’s not a good solution.
Yeah I’ll be ok. I know about the loss of DMI information. I was not aware that flashing the main chip directly would wipe that. This does explain a LOT why people who send their MSI laptops to the factory for service get 0000000’s and “Please change product name” for the DMI product information–because the incompetent repairmen (NOT the MSI engineers in Taiwan) just reprogram the entire chip and forget about the DMI information that is supposed to be preserved; they’re supposed to program that stuff back before they send it to the customer.
Thank you for the heads up.
There was actually a buggy MSI bios release where if you cleared CMOS, DMI information was lost. What I can do is dump the entire bios chip as is with a programmer, then ask a modder to mod the “broken” ME bit which is set to disabled, flash it back, as fixing that won’t be difficult. That will probably be the best way to go. I’ll wait for now until something actually requires the “MBEX” To be enabled (since the ME isn’t actually disabled, just the bios extension, otherwise I would be getting those 30 minute shutdowns, etc), then I’ll take a programmer to the laptop.
Taking out and repasting liquid metal always gives me the shivers. Nothing like a conductive ball of doom to ruin your day (even with proper prep work!).
I have both a disassembly and reassembly video for this laptop (was taken from some MSI FTP site). Assembling desktop motherboards is scary enough, even with proper ESD discharge precautions and steady hands. But those tiny EDP and other ribbon cables look like they could break if you stared at them too hard. And I had a problem with the keyboard cable which caused a few characters to not output (all on the same cluster, which I found from searches, other people having the exact same keys issue on Steelseries laptop keyboards–CAps lock, S, 6, 7 and Z). I fixed that with some Deoxit D5 and cleaning and trying to ‘straighten’ any bends in the cable. I would hate to have to have that issue happen again if I had to take out the mainboard. So, programmer it is!
Thank you very much for your help, @plutomaniac . I’ll take it from here with my programmer.
I updated the firmware on my Dell Inspiron 5559 on 1/22/2018 before knowing about the reboot problems. Now I can’t boot to Windows 10.
I tried to revert to an earlier version of the firmware, but the Intel ME update failed. It was trying to downgrade from 11.8.50.3426 to 11.0.0.1194. I gather from plutomaniac’s 1/25/2018 post that the SVN of 11.0.0.1194 was lower than SVN 3 for 11.8.50.3426.
From a bootable USB drive, MEINFO on the Dell reports 11.8.50.3426 LP and SVN 3.
I want to use the Flash Programming Tool (FPT) with a binary file to return to an earlier 11.8.x.x that has an SVN of 3, but where can I get one? (Or should I be using the FWUPDATE?)
I looked in the 4th entry under section B1 Consumer Systems, and it contains a binary file that looks like it would work with FPT. But this is the same version I already have. All the other files I looked at seem to be Windows install versions.
Thanks for the good post.
Flash programming tool is on the tools linked on the very front page of this thread, along with that fwupdate and meinfowin64 and other files. Did you look there?
Sorry, I missed the link to Intel Engine Firmware Repositories.
@ Rob:
From the first post, make sure you read the first 6 warnings of Section B: General Notice, Firmware Regions (RGN/EXTR), Firmware Updates (UPD), Security Version Number (SVN), Version Control Number (VCN) and Production Version Status (PV). Hopefully now you know that you cannot downgrade to such a firmware via FWUpdate tool and that you must never use FPT with the firmware provided here or at the repositories thread.
Now, I don’t understand why you want to mess with the Engine firmware in the first place. The health of the Engine firmware is deduced by MEInfo and MEManuf tools, as explained at the first post. But what does it have to do with your problem? The reboot issues have to do with problematic CPU microcode updates, not Engine firmware. If you can boot enough to initiate a BIOS update then download the latest update from Dell and flash it to fix the issue. They should have removed the BIOS with the problematic microcode, otherwise pick the previous one.
Even if that does not help and you know the peoblem was caused by Dell’s BIOS update, I suggest you contact them instead and, if push comes to shove, use the warranty on such a new system.
@ plutomania:
Thanks for the clear and unambiguous statement that I should not do what I was thinking about doing. And thanks for clearing up my confusion about the cause of the reboot issues.
I had already downloaded and installed the previous BIOS update from Dell, but when the ME firmware failed to load, I thought that was the cause of my reboot issues.
Thanks again for the help.
@plutomaniac my ME issue was fixed by Svet from the MSI forums. He took my APTIO dump, unlocked ME Access somehow and wrote a flasher which reflashed my capsule with an older ME (11.8.50.3399)
Everything’s in working order now. Not going to mess with “temporarily” disabling the ME ever again. No-sirreeee.
Is this 3399 version of 11.8.50 considered secure?