I have the issue with my HE pedals, which is using the Bodnar controller.
Moving the device to other USB port eventually allowed me to boot with all devices attached and powered, no issues.
It’s dependant on a combination of motherboard model and USB controllers…I’ve even had this with my Bodnar SS2 wheel, as well as other devices.
Try to use on-chip USB ports as opposed to those making use of 3rd party controllers, like Via, for example. Check your motherboard manual to see which ones you should use.
I occasionally and randomly get this, the first couple of times I basically reset my bios as it seemed to “move” the boot devices etc. On research USB 3.0 issue a “non boot” came up occasionally.
Solution for me:- When it happens I remove my USB hubs and devices from the back of the computer and restart it. The computer boots as normal and I carefully replug them back into the same slots.
I run 2 7x 3.0USB powered Hubs and if I get the “before BIOS” stop I unplug one powered Huds power cable, the system runs as normal and replug the power cable back in.
This happened when running Fanatec CSW base and pedals, and it does the same for the Mige HPP pedals. I also have 2 other bodnar boards…
Why is a complete mystery and it is random. Microsoft was of no assistance.
Firstly many thanks to you and the team for an awesome product!
I upgraded recently from MMos to the Simucube firmware and have been having the same issue where the PC doesn’t boot when the device is switched on. I followed the steps you suggested to test this, and can confirm that the PC booted successfully when the Simucube was switched to firmware upgrade mode. After power cycling the Simucube to return in to its normal state, the PC again would no longer boot with it switched on.
Basically I have the same issue described by Elliot:
I’ve tried both USB 2 and 3 slots with the same results. In case it’s of any use, other hardware is as follows:
Asus Maximus Hero vi mobo
I7 4700k CPU
Logitech G25 shifter via Bodnar adapter
Fanatec V3 pedals
Fanatec BMW rim with Bodnar “Formula Rim” USB mod
Small Mige with 10,000 encoder
IONI Pro HC
Incidentally since I’m here, here are some other thoughts since installing Simucube
Assetto Corsa feels great, better than MMos!
rF2 has been a struggle so far to get it feeling smooth, but I’ll need to do some more tweaking before I reach a conclusion
Automobilista again feels great - much better than MMos.
Just bought ETS2 in the xmas sale, and am looking forward to having some kind of FFB as currently there’s nothing whatsoever. It seems the upcoming firmware fixes this?
Anyway hope this helps and let me know if you need any more testing…
Yes, it will be fixed! I’ve already driven it with all effects. I will have to adjust some things in the configuration tool, and then it will be ready for release. Most likely next week!
Can you test again with the following procedure: Put the SimuCUBE into the IONI USB Configuration mode, and then restart the computer. In that mode, it won’t send any USB HID reports to PC, but of course the USB interface is the same. This would help in pinpointing if it is indeed the descriptor OR the USB report sending OR both that makes this happen.
No worries.
Excuse the noob question, but does the Granity USB cable need to be connected for this? Currently I’ve just the one USB connected for the Simucube.
No need to have it connected. The other one needs to stay connected. It is important that it is in the IONI USB Configuration mode, where it won’t send reports to PC.
OK, so the PC boots fine with the SimuCube switched on, but in IONI Config mode.
Just to confirm, after switching it back to normal operation mode again, the PC failed to boot until the SimuCube was switched off.
So this issue is likely just because SimuCUBE is sending the USB reports as fast as it can to PC. Maybe these bioses get overwhelmed by this, and are not successful in trying to figure out if the device is a keyboard, mouse or something else.
Based on the recent round of your test, I have figured out how to handle RESET and SUSPEND callbacks from the USB stack, and disabled report sending if state is suspended. This change will be included in the next version, to be released this week.
Further analysis late at night revealed that the stack will just silently return the function call anyway, so the manual callback shouldn’t be required.
I will leave the code there, though. Who knows if it does fix something.
Now that I know what could solve the issue (disabling usb report sending when a suspend or reset request comes from a pc), I was thinking about just manually pausing the report sending for, for example, 30 seconds at those events.
How would people react if wheel started to update only after a while of being connected? I would make it so that updates would start right away when Configuration Tool requests any status reports.
Yep, nice one Mika. I should be installing the new F/W tomorrow (WOOT!) so I’ll let you know if it changes any of this behaviour…
Otherwise your last suggestion sounds fine.
Can you think of anything in my hardware setup that might be causing this? The Bodnar adapter for the G25 shifter used to do the same thing in fact, then Leo recommended me a different version of the firmware which sorted it out. Also, installing a PCI-e USB card and using that instead was another way of fixing it.
A fix for this would be nice, but tbh it’s not a massive inconvenience, and it doesn’t seem to be a very widespread issue? Plus I’m kind of in the habit now anyway of booting up the PC before I switch the wheel on
