1. While you remove the CMOS battery, you should wait long enough time to discharge the capacitors (wait about 15 minutes).
2. Reboot the computer with security jumper removed. After waiting 30 sec-1min, you will see Configuration Menu. After you will see the Configuration Menu, insert USB with the latest BIOS file and press F4 to recover the BIOS.
okay, I've done this now:
- removed CMOS battery, jumper and power plug
- waited one hour
- plugged in power plug
- short tap of power button
The "locking" screen immediately pops up and stays there for at least 30 minutes.
It seems that this goes before anything else. I have not managed getting into the power button menu, whatever I do. I've tried pressing the power button for one, 2, 3, 4 seconds with all combinations of security jumper and CMOS battery now, each time starting with plugging in the power plug.
I think that this model stores its configuration in the SPI flash that is connected to the Intel i3. Removing the CMOS battery does only invalidate the clock and maybe some other minor things, but not this nasty configuration bit.
I just repeated the procedure, maybe I did something wrong in the first time: with the CMOS battery and the security jumper removed, I wait for 30 minutes, then plug in the power plug, then power on the NUC by briefly pressing the power button.
This time, it complained that the CMOS was invalid, and then attempted to boot a system. It showed that it could not find a bootable OS. (There is a bootable Windows on the mSATA drive, it didn't choose that apparently.)
I waited for some minutes, but it just sat there.
Then I pressed the power button to turn it off.
Then I pressed the power button for three seconds.
It showed the CMOS warning again, and thereafter it showed the screen as attached. It again sits there.
I know this screen already. If I choose 1, then it shows the "locking" screen after a few seconds. If I choose 2, then it wants to be power cycled. This route ends with the locking screen as well after having turned it off/on.
IMG_20180102_191301.jpg 36.3 K
The image what is attached to your last message is part of the configuration menu, but menu with F options are missing for some reason. See the attached image how the Configuration Menu looks in my computer. When this menu is displayed and the USB with latest BIOS file WY0045.bio inserted: Download BIOS Update [WYLPT10H.86A] , pressing on F4 shall start BIOS recovery process.
If you prefer the easier method (Power Button menu), follow those steps:
1. Security Jumper shall be installed in place.
2. Connect amplified speaker or headphones to the audio jack.
3. Press and hold the Power Button. You should release the Power Button soon as the system will emit three short beeps. NUC will reboot into Power Button Menu.
4. With the USB containing the latest bios file, press F4 and the recovery shall start.
ConfigurationMenu.jpg 54.4 K
I've just done what you say. The result is the same. When I do this the first time after having waited for 30mins, then I get the CMOS clock error, followed by an attempt to boot from some nonexistent drive ("insert boot media and press any key..."). When I repeat that, I sometimes get to the screen that I have posted last. In all other cases I get to the "lockup" screen that I posted first.
I was also expecting what you see on your NUC, that's what the manual also says. But that's not what is happening here. It's driving me crazy, I have been playing with this for two days now...
My assumption is that the "BIOS setup auto-entry" function somehow has enabled a kind of access protection that I cannot find a way around.
As I said, I can access the BIOS and start Windows when having removed the jumper and battery, but only for the first time after having plugged in the power supply.
In the BIOS, I can start a firmware update and navigate on a valid image on the attached USB stick. But when it starts the update, it reboots for that (I think that's normal), but instead of seeing the flash process I see the lockup screen again!
Move jumper from the 1-2 pins to the 2-3 pins and then power on. You should get into BIOS Setup with keyboard working.
Once in BIOS Setup, use F9 (followed by Y) to reset BIOS Configuration and then F10 (followed by Y) to exit with BIOS Configuration save. Once you see POST occurring, power off and restore jumper to pins 1-2. When you then power back on, use F2 to enter BIOS Setup and then configure as necessary/desired for your hardware configuration (i.e. Boot Order, etc.).
Hope this helps,
@Scott, sorry, but no... Position 2-3 ("lockdown") according to tech spec always leads to my "lock" screen (picture in my first post) in my case.
There is currently only one way to get into the BIOS: remove battery and jumper, remove and plug in power, then power on, then CMOS error, then F2 for BIOS.
What I did then:
- F9 to restore defaults
- F10 to save&exit
- wait for reboot and press power button for long enough (I cannot remove the power plug because there is no battery)
- set jumper 1-2
- power on
Result: "lock" screen ... :-/
This is all the result of having selected that option, hitting F10, and restarting. I have no idea what happened there...
Whenever the "lock" screen appears, the USB keyboard it not initialized. I know that because the NUM lock LED is not lit. There is no way to enter a key in this situation.
First of all, while the CMOS part is supposedly only used for maintenance of the date and time, clearing CMOS *does* make a difference to the BIOS configuration. For years, I have contended that this is the result of bugs in the AMI BIOS Core that, for some reason, have never been fixed. I see that other board manufacturers also recommend clearing CMOS to get around similar issues they are having (same core, same bugs).
When I read your descriptions of the issue and what has been tried, it doesn't make sense. The BIOS Configuration, if reset, should permanently wipe out any setting from the previous configuration. It is stored in a single BIOS variable and this parameter likely resolves down to a value stored in a specific byte of this variable. The only exception that comes to mind is the possibility that a separate BIOS variable has been created in the BIOS flash that indicates BIOS entry is required as an override (such a variable is created by Windows 10 if you choose to say that BIOS Setup should be invoked after a reboot). The strange this is that, once this BIOS variable is acted upon by the BIOS, it is supposed to be deleted (which we aren't seeing, if this is indeed what is going on). So, one way to ensure that any extra BIOS variables are removed is to upgrade the BIOS. Now, because of the keyboard interlock that you have, the normal F7/iFlash/EBU BIOS update process is not going to work. That leaves us with BIOS Recovery.
I am suggesting that you attempt to do BIOS Recovery to the latest available BIOS (even if this is what you have installed already). Further, I suggest that you use the Jumper-based version of BIOS Recovery (it does a better job of unconditionally updating the firmware than does the Power Button Menu method). Here is my process for you to follow; it includes my extended recommendations for avoiding problems with this process:
- Take a USB 2.0 flash disk and, on a Windows-based PC, reformat this flash stick using the FAT32 file system with the Quick option DISABLED. Do not use USB 3.0 flash disks! Do not do this on any Linux- or MACOS-based machine; no matter what they say, their file format is NOT 100% compatible with FAT32! Sorry for how slowly USB 2.0 flash sticks format.
- Download the BN0060.BIO file and save it onto this flash disk.
- Properly use the Windows Eject capability to eject the flash disk, ensuring that it is closed properly (i.e. don't just yank it out).
- Power off the NUC.
- Remove the (yellow) BIOS Configuration Jumper.
- Plug the USB 2.0 flash disk into a USB 3.0 port on the NUC. Best to not use Charging Port.
- Power on the NUC.
- The NUC should proceed with the BIOS Recovery process, providing an onscreen progress indication. When it is complete, it will tell you so.
- Power off the NUC.
- Restore the BIOS Configuration Jumper to pins 1-2 of the header.
- Power on the NUC.
- When POST displays splash screen, use F2 to enter BIOS Setup.
- Use F9 (followed by Y) to reset the BIOS configuration to defaults.
- Use F10 (followed by Y) to save the configuration and exit BIOS Setup.
- When POST displays splash screen, use F2 to again enter BIOS Setup.
- Make any changes to the BIOS configuration (boot order, etc.) that are necessary for your hardware configuration.
- Use F10 (followed by Y) to save this configuration and exit BIOS Setup.
Note: do not combine Steps 12-14 with Steps 15-17; so these separately.
Hope this helps,
All, thanks a lot for all your suggestions so far!
I've executed your procedure step by step. The backup battery was disconnected on the first attempt, and all that the machine did was attempting to boot from some nonexistent media. Then I repeated it with battery, and after a while the BIOS actually started the firmware update. I was quite excited to see that!
The update/recovery completed without errors. I pushed the power button to shut down the system, then removed the power plug, then installed the jumper on 1-2, then plugged in and started the machine.
What happened? The "lock" screen appeared...
This seems to be a serious BIOS bug.
Any other ideas?
If someone could send me a memory dump of the SPI flash in his NUC D43010, mine is a MXIC MX25L6406E. I have the abilities and tools to copy that to mine.
You cannot (well, should not) attempt to recover by copying the contents of someone else's SPI flash. These contents will include the "branding" for that person's NUC - serial number, MAC address, etc. You would thus be cloning their NUC, not something that anyone would want to see happening (I certainly would not volunteer the contents of my SPI flash knowing this to be the case). The contents of the SPI flash are, for the most part, compressed and encrypted. There are no tools that will allow the changing of the NUC's "branding" once it leaves the factory.
I will forward this conversation to the development team. Perhaps they can think of a way around this that I am not...