[Need Help] NUC7i5BNH BIOS

[Rajserp]

Hello. I have a NUC7i5BNH. It used to work perfectly fine. I sold it and the buyer claimed DoA. I refunded, got the item back and found the following;

1
2
3
 

Will power on with power button, LED goes from orange to Blue.
No HDMI display or USB-C video output via adapter
No USB as keyboard will not show Caps / Scroll lock LEDs for example.
 

Things that happen;

1
2
3
 

After power on, the NUC power cycles back to standby (orange LED) then back to On (blue LED). Cycle continues.
CPU fan will spin after a short time, board gets warm to touch.
Removal of all RAM causes the correct 3 slow flash of blue LED on startup.
 

What I have tried;

1
2
3
4
5
 

Check PSU power during operation. Correct 19V
Remove all power, disconnect CMOS battery for several hours
Reseat RAM, different slots, entire different DIMMS, etc
Remove BIOS security jumper, connect fat32 format USB as per the Intel NUC hardware BIOS recovery. No indication of BIOS flash. After a short time the NUC will return to standby.
 
 

Thread attachments;

I have dumped the BIOS three times got the same CRC check
CRC64 [40023CA5E05425D0]
NUC7i5BNH-W25Q64FV-Dump1.zip - BIOS File (Opens in UEFITool_NE_A59)

There is also a SPI chip on the other side of the board that I originally dumped in error I have also attached in case it is useful
CRC64 [4518BADB920C0602].
NUC7i5BNH-W25X10CL-Dump2.zip - Chip on RAM side of board.

I have the ethernet MAC address from when it was working as I had it static IP in my router.
f4:4d:30:6e:84:f4

Greatly appreciate any input.

NUC7i5BNH-W25Q64FV-Dump1.zip (5.45 MB)

NUC7i5BNH-W25X10CL-Dump2.zip (25.4 KB)

[lfb6]

What makes you think this might be a bios/ firmware problem?

Static parts of bios region are 100% identical to stock bios, the EC firmware you dumped from the other chip is 100% identical to the EC cirmware in latest update.

You might empty the NVRAM in case the buyer fiddled with rare settings (like trying to undervolt / whatever), but there’s not much hope. Look here for the procedure

In case this didn’t help (as expected) you could clean the ME region according to this guide (but that seems even less probable): [Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization

[Rajserp]

I dont really know if it would be the bios or not but as the unit has no output on HDMI and won’t startup correctly there isn’t much else I could do other than toss it in the scrap bin. Intel said it is too far out of warranty for them to help. Finding these forums has given me a last option to attempt repair.

Thank you, I will try your suggestions. Would these steps essentially reset the non static parts of the bios?

Is there some way I could have the bios reset all the supporting modules?

[lfb6]

@Rajserp

…Would these steps essentially reset the non static parts of the bios? Is there some way I could have the bios reset all the supporting modules?

There’s no more you can do to the firmware than the two steps mentioned. GD and GbE are static, ME gets initialized and NVRAM stores settings (and is written to all the time by OS, too). Dont forget to clear the CMOS. There’s a flash decriptor (identical to the one in your dump) and a configured ME region in the update file, too.

[Rajserp]

@lfb6

You might empty the NVRAM in case the buyer fiddled with rare settings (like trying to undervolt / whatever), but there’s not much hope.

Hello! I have good news. I was able to get the system booting again by clearing the NVRAM partitions following the example in that link. Although it is missing some images / details that would make the steps easier. But I worked it out!

To get the NUC to boot after flashing the cleared bios I had to remove the security jumper and power on. After a couple of automatic restarts I got an image and menu. I then flashed the latest bio bios image from Intel.

Thank you very much for your suggestion! You saved me approx $300!

[lfb6]

Good news indeed- thanks for the feedback! Since those settings won’t change in switched off state under transport ‘something’ actively was done on buyers side?

I never owned an Intel NUC, so the function of this security jumper and when it should be used isn’t clear/ known to me. In addition it’s not completely clear what the bios update is ‘repairing’?! Those volumes were bitwise identical to stock, but maybe there are some values regarding ‘completion of last update’ missing in NVRAM making the update process think that last run wasn’t properly done…

Where do you think additional pictures / details are missing in the description?

[Rajserp]

@lfb6

Where do you think additional pictures / details are missing in the description?

I would perhaps reword these sentences;

NVRAM can be emptied easily- there are two NVRAMs in the beginning of bios region:
[Existing Image 1]
[Existing Image 2]

Some NUCs seem to have the machine specific information stored in NVRAM, this should be kept- in addition the GUID for the entries isn’t stored in the GUID store. In addition the default values need to be kept, too.

Search for the start adddress of the first NVRAM entry after StdDefaults in UEFIToolNE
[Existing Image]

Search for the start adddress of the next volume in UEFIToolNE. The last bytes before this next block is the GUID store, containing all the GUIDs of the NVRAM, one line one GUID, all bolcks despite the last in reverse notation and all GUIDs written from bottom (=last line) up.

Open the firmware image in an Hex editor (HxD for example), go to the start address of the first NVRAM entry after StdDefaults in UEFIToolNE, ‘select block’ to the start address of the next uefi volume minux 0xF- in this example 0x8019F6, next block start adderss 0x820000 minus 0xF = 81FFFEF, fill with FF
[Existing Image]

Check if the last line of the NVRAM volume contains the GUID for the StdDefaults!

To something like;

NVRAM can be emptied easily- there are two NVRAMs in the beginning of bios region:
[Existing Image 1 - Good]
[Existing Image 2 - Are you showing the GUID Store line? The yellow lines are not part of NVRAM?]

Some NUCs seem to have the machine specific information stored in NVRAM, these should be kept in addition to the GUID store Padding. Data between StdDefaults and GUID store is safe to clear.

[Add an image to show these entries inside NVRAM, show what is safe to clear in the example]

Select the the first NVRAM entry after StdDefaults in UEFIToolNE. Note the start address [Base number]. This will be used as StartOfBlock below.
[Existing Image - Good]

Select the last entry in the NVRAM, GUID store, in UEFIToolNE. Note the start address [Base number]. Use a HEX calculator to subtract F from this number. This will be used as the EndOfBlock below.
[New image for this example]

Open the firmware image in an Hex editor (HxD for example). Right click in the window and use ‘select block’ or equivalent. Enter StartOfBlock into Start-offset and calculated EndOfBlock into End-offset
[New image to show the example Select block window]

Right click inside the selected block and select Fill selection. Fill with Hex-values of FF and save-as the file.

[New image to show the example of Fill window]

Open the modified file and view the first NVRAM entry. It should still show the GUID for the StdDefaults, followed by FreeSpace and then GUID store.
[Existing Image - Good]

[lfb6]

Thanks for the feedback, appreciate it! Unfortunately this forum software is not capable of editing a larger post with some more pics, it destroyed the older parts of the post while editing. For now it’s emptied since I don’t have the time to restore the whole post…

EDIT- Restored the thread, I think the part about deleting the NVRAM at least is rather detailed now…