BIOS Recovery 990FX Extreme9

wardog wrote: parsec wrote: Now to identify the reason. The 9xx chipsets do not have native USB 3.0. Instead relying on 3rd party Etron or whoever USB 3.0 controllers.

But will the USB flash drive even be recognized by Instant Flash in one of the Etron USB 3.0 ports?

wardog wrote: Odd. I just yesterday built the 990FX Extreme9/9590 in my sig and used Instant Flash from within the BIOS to go to 1.80. Knock on wood apparently, w/o issue. I wonder if folks who've this has happened are using the correct rear usb 2.0 and not the incorrect Etron usb 3.0 ports.

Perfect timing.

That seems to explain the lack of more complaints about the 1.80 update.

If you are not dead in the water immediately after the 1.80 update, apparently you won't ever be.

Now to identify the reason. Your comment is one possibility. There's a guy that apparently bricked his Intel board using an NTFS formatted USB flash drive for an Instant Flash update.

justin wrote: I do not have any NVMe, just two older Vector SSDs in RAID 1 via Sata3 for OS and HighPoint card in RAID 10 for data. My experience was the same--1.7 worked fine with FX8350 until I did the update to 1.8 in May. I used instant flash from inside of the BIOS and the result said "successful, press finish to continue" or similar. Result was straight to 00. Reseating CPU and memory made no difference. Also tried the battery removal for an hour and then CMOS clear. It was out of warranty, so simply purchased a new 990FX extreme9 and took the opportunity to upgrade to an FX9590. Worked fine until last night when my brain went out for a break without informing me and I clicked update on the BIOS again. Now back to 00 code. Tried the battery out for an hour thing and the CMOS clear button to no avail. Anyone have any luck at all?

First I want to say that I am NOT questioning your statement about this happening to your boards and UEFI 1.80, or implying anything else in any of the following.

I'm somewhat surprised you bought another Extreme9 board after your experience with the 1.80 UEFI. Meaning I doubt I would have done the same thing.

FYI, whatever it is that causes this to happen would not automatically disappear in any new UEFI updates, unless this situation is specifically listed as fixed in the description of the new version. So don't update your UEFI again unless you know it is safe. I know you did it accidentally this time.

I am surprised that we have not heard of this situation happening from more owners of this board. If it happened to every owner of this board, we should be flooded with complaints about it, but apparently that is not the case. It would be extra strange if this only happens to a handful of users of this board. The question then would be, why?

I am not aware of any simple fix for this problem, since this thread ended abruptly until your post woke it up.

I can tell you that replacing the UEFI chip with the 1.70 UEFI version should get the board working again. The UEFI chip is in a socket, not soldered in place, and can be replaced.

You can get that chip from ASRock, or from sources on eBay, both will load the chip with the UEFI version of your choice. I'll provide the link for ASRock as the source. Sorry but the forum's link tool is broken for some links, that is the correct URL:

http://www.asrock.com/support/index.asp?cat=RMA

If I had my choice, I would send you one free of charge, but I can't do that. I assume the lack of any update implies that this situation is not common, or that the 1.80 UEFI is the cause and will happen to anyone that owns this board. You said it happened with two FX processors models, which is odd. There is no reason I can think of why adding NVMe support would cause a CPU failure.

One of the moderators here is now using an 990FX Extreme9 with an FX-9590. I'm curious what UEFI version he has in his board.


Edited by parsec - 27 Oct 2016 at 8:40am

I don't see this as a NVMe SSD issue, since eire1274 is not using the new Corsair SSD yet. Plus the 00 Dr Debug code is CPU failure, and the POST checks of drives is done at the end of POST, CPU POST tests happen first. So I don't think this is SSD related.

Sorry we missed the OP, who posted in May...

Quite a jump in time between 1.70 and 1.80, almost two years.

If POST fails as it has with the 00 code, the PC is non-functional, no chance of getting into the UEFI/BIOS at all to change to 1.70, or whatever.

You consistently get 00 on the Dr Debug display, right?

All I can suggest now is removing the board's battery for an hour, but don't clear the UEFI/CMOS yet. If the battery removal does not work, then try a CMOS clear, which is normally not recommended right after a UEFI/BIOS update. I have done that once or twice without ruining anything.

Have you done UEFI/BIOS updates with the Crossfire setup in the past without any problems?

Perhaps the 1.80 UEFI has a bug, but we haven't been flooded with posts about it.

Please keep us updated if you made any progress, or not.