NUC8i7HVK BIOS not booting directly whenever my logitech Bluetooth (non-unifying, non-nano) receiver is plugged in

[PRom0]

I have a logitech MX 5500 Revolution Keyboard Mouse combo. Pictured and described at this link:

https://www.newegg.com/p/N82E16823126038?item=9SIAHU37ZG7766&source=region&nm_mc=knc-googlemkp-pc&cm_mmc=knc-googlemkp-pc-_-pla-itmaxware-_-keyboards-_-9SIAHU37ZG7766&gclid=EAIaIQobChMIxsj8ir6G5AIVFx6tBh1sJgVbEAQYBCABEgLSgvD_BwE&gclsrc=aw.ds

It's 11 years old and pre unifying receiver days. Still works perfectly. I prefer using the receiver to onboard bluetooth as my mouse and keyboard will not be usable during S3, S4, S5 to wake up the NUC and during BIOS, as per the NUC specs. However, whenever I go through a restart cycle, the BIOS stalls before booting to windows and powers down my NUC before powering it up again to present me with a message to make changes in visual BIOS for new hardware. Y to make changes and go into BIOS or N to boot with last user settings.

If I press Y and change nothing, press F10 to save and restart, my system will boot to windows even though I haven't removed the Logitech USB receiver during this whole process. If I press N and boot with last BIOS user settings, my system will also boot fine to Windows. And, yes, my mouse and keyboard both work in BIOS thru the problematic USB receiver that's causing this mess. I've reset BIOS to all default settings if that wasn't already the case. It still makes no difference.

Every reboot prompts this same cycle of stalling after restarting, powering down before booting to windows, powering back up, presenting me with the Y or N choice to adjust BIOS, and booting regularly into windows regardless of what I choose (I don't make any changes in BIOS from default settings).

I also have mice and keyboards that work through the newer Logitech unifying receiver. They too cause this issue when they're plugged into a USB port, but not as consistently. Again, all BIOS power settings and USB settings are at default values.

[LeonWaksman]

1. Try to connect your Bluetooth receiver using USB extension cable (rather than inserting it directly to the USB port on your NUC) https://www.amazon.com/AmazonBasics-Extension-Cable-Male-Female/dp/B00NH13UFQ/ref=sr_1_5?crid=1A27DDCJYW9P4&keywords=shielded+usb+extension+cable&qid=1565949369&s=gateway&sprefix=shielded+usb+extension+cable%2Caps%2C263&sr=8-5 . Or if you have USB port on your monitor or USB HUB, try to relocate the transmitter there.
2. Try to use other USB port on your NUC

Leon

[PRom0]

Thank you, but I've moved the receiver around to the other ports, I've used an extender as you suggested and I removed the other USB devices plugged in just to zero in on the problem (2 external hard drives). The problem still persists as described. Here is a picture of the error message that appears

Edit so the BIOS error is searchable:

BIOS has detected unsuccessful POST attempt(s).

Possible causes include recent changes to BIOS

Performance Options or recent hardware change.

Press 'Y' to enter setup or 'N' to cancel and attempt

to boot with previous settings.

[PRom0]

Searching around for relevant posts regarding this issue, I found this:

Use the F2 key when the BIOS Splash screen appears, in order to enter BIOS Setup (Visual BIOS). Click on Advanced and then Devices and then on the SATA tab. In the left-hand Window (Chipset SATA Controller Configuration), set parameter Hard Disk Pre-Delay to a value of 5 (five seconds). Press the F10 key and then click on Yes to save this BIOS configuration change and exit from Visual BIOS. Now, run your experiment as you originally did with the WD HDDs hooked up and see what happens. Hopefully, by inserting this delay in the boot process, it will avoid the WDT going off.

If that doesn't work, go back into BIOS Setup and reset that parameter to 0 (zero seconds). Then, click on Boot and then the Boot Configuration tab. In the right-hand Window (Boot Display Config), uncheck parameter Failsafe Watchdog. Press the F10 key and then click on Yes to save this BIOS configuration change and exit from Visual BIOS. You can now test again; you should not see the problem occur.

This proposed solution DID NOT WORK for me. I experienced the same boot loop cycle when I set the Hard Disk Pre-Delay to 5 seconds and even when I increased it in the allowable increments of 5 seconds all the way to the maximum of 30 seconds. Turn off the Failsafe Watchdog didn't prevent the two-boot loop I was experiencing but it did prevent the message from appearing asking whether I wanted to change BIOS settings. So, on every boot with the watchdog turned off, it would boot once, fail, reboot and instead of displaying the BIOS message it would just boot into Windows on the second boot.

The only solution is what I knew going in: the removal of the logitech external receiver. Moving the receiver to other ports on my NUC and using an extender doesn't prevent this problem.

[Alberto_R_Intel]

PRom0, Thank you for posting in the Intel® Communities Support.

Just to let you know, for this specific scenario the problem could be related to compatibility between the Intel® NUC Kit NUC8i7HVK and the Logitech MX 5500 Revolution, the fact that it does a boot loop cycle when that specific receiver is connected indicates that the source of the problem is that the devices are not fully compatible.

In the link below you will find different devices tested and validated by Intel® as fully compatible with the Intel® NUC Kit NUC8i7HVK, in there you will see Bluetooth "Keyboard and Mice" for you to verify them and have them as an option to use with the Intel® NUC:

http://compatibleproducts.intel.com/ProductDetails?activeModule=Intel%C2%AE%20NUC

Do you have the option to test the Intel® NUC with a different Bluetooth kit or Bluetooth receiver?

If you have the chance to connect a wired USB keyboard and mouse directly to the Intel® NUC, is the problem the same?

Regards,

Alberto R.

Intel Customer Support Technician

A Contingent Worker at Intel

[Alberto_R_Intel]

PRom0, I just wanted to check if the information posted previously was useful for you and if you need further assistance on this matter?

Regards,

Alberto R.

Intel Customer Support Technician

A Contingent Worker at Intel

[Alberto_R_Intel]

PRom0, Since I have not heard back from you, we are closing the case, but if you have any additional questions, just reply back or post a new question.

Regards,

Alberto R.

Intel Customer Support Technician

A Contingent Worker at Intel