SimuCUBE Open Source Firmware: Beta version 0.5.X BUG Reports

I am not sure if this is a Bug or Not, could be could just be a strange issue BUT… I am working on setting up a new computer and have the SimuCUBE Firmware 0.5.2 installed on the Discovery… I have a New Fresh install of Win 10 Professional Creators on the computer and connecting the SimuCube comes up with Unknown USB Device (Device Discriptor Request Failed) all USB controller drivers are at their latest according to windows… so I am not sure if it is just not telling Windows it is an HID device and to download a certain driver or if I am having some other issue… I have tried multiple USB ports as well… I think I am going to try back grading to MMOS and see if that will load the correct driver and then return to the SimuCUBE Firmware as that was the sequence of course for the original.

OK this is fixed on my computer but it is something to look into (as it is an issue)… I had to put the SimuCube in DFU mode and then just the restart loaded the STM driver into windows. Once that was done I took it out of DFU mode and all was good to go… So there is an issue with it being recognized as a correct device to load the STM USB driver into a newly installed system… Something to look at re: new systems and in the meantime I guess that is the fix (into and out of DFU mode)…

Hi Brion,
You may also want to restart the PC to ignore driver signing. I think that fixed the issue for me on another system with a fresh install - pretty sure that was the case.

Cheers,
Beano

I tried that at first… I tried Restarting, many times then with different USB ports, 2 and 3, then I tried updating all of the USB Drivers… then the last thing was to flip the thing into DFU mode… once I started with it in DFU mode Windows installed the ST USB Driver automatically for DFU Mode… then without doing anything but flipping it back to Run Mode and starting again it works fine…

So I am guessing that Windows initially is not knowing what driver to use on it so it is throwing the “Device Descriptor Failure” I think it was Code 49… and instead of a standard HID Device Driver it is requiring the STM Driver which it loads when it senses DFU Mode.

It is possible that MMOS used to send the right device description after an initial restart which caused the correct driver to load, that is why I was originally going to try to reinstall MMOS but I didn’t have to do that, as i found out.

This is why Its an issue but it is a PAIN to recreate as it will more than likely only occur on fresh installs, not upgrades as its correct driver will have already been loaded at some point.

Im not sure how to erase those drivers to re-test maybe it will only take uninstalling the SimuCUBE to test.

Ha ok, good feedback :wink: I may have had that as well when I tested it on a Core 407V board, can’t recall exactly…

But anyway, Mika will be able to shed some light for us, I’m sure.

Have a good one that side, chat later.

There shouldn’t be any requirement to load any drivers, as the firmware uses default Microsoft driver. However, this is news to us and I will be investigating this. The limitation is that there is a finite supply of laptops / windows computers to try on…

don’t you need to have direct x installed for the driver tho?

No, because DirectX is installed in all windows versions from way back in the XP days at least. Also, the default Microsoft driver is the Human Interface Device driver, the same one that supports any generic mouses, keyboards, etc…

OK i thought the direct x needed to be updated first which normally isn’t a problem as most software checks for this fist on install. to be honest is been years since i poked around under the hood with programming anything more than an arduino.

Bundled DirectX in games is generally for updating those components in very old Windows 7 and 8 systems, as there have been numerous patches and new DirectX versions since Windows 7 was first released. If everyone had Windows 10, it wouldn’t even be required.

I tested quite heavily over the last 2 nights, Mika, with and without GUI active, but cannot seem to replicate the earlier suspected ffb /USB Comms bug.

Did maybe 100 laps total without any ill effects.

Not sure how others are going though…

Cheers,
Beano

1 Like

Had a similar problem with my new computer and a Z1 usb screen,
Looks like starting with new installations of Windows 10, version 1607 and newer, Windows will not load any new kernel mode drivers which are not signed by the Dev Portal,
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later
I found this kind of procedure that solved the problem:
http://datakey.com/downloads/Datakey_Windows_10_Driver_Install_REV.B.pdf
Hope this might help.

George

I find it difficult to believe that Microsoft’s own driver would not be signed.

There was no need to install any driver either with the Z1 screen,
it was working straight out of the box,
it stop being recognized properly after the fresh install.
I had to contact the guy who makes the screens to figure out a solution to this.

George

Yep, but still shouldn’t affect SimuCUBE as we are not using any non-signed drivers. On my system, it shows that the driver is signed.

@George - It sounds like a similar issue but not the same issue resulting in the same result though. The only problem is I think windows is confused as to what driver is actually needed for it and since we don’t actually have that driver on a disk that procedure won’t work as the Automatic finding doesn’t work… In the end whatever drivers worked are all signed.

@Mika - Im thinking that it may need an STM Driver in there first on a clean instal as well as the HID Driver to work Properly in that it needs to load the STM USB Driver to communicate and then finds out that it is an HID Compliant Device and then uses that driver for the SimuCUBE. I wonder what driver loads when you connect the board in DFU mode as that driver is the one that caused everything to then work properly.

It is sort of weird because I can’t now de-install it from recognizing it is a Game Controller with a USB Driver as well for the HID and a Serial Bus on the Granity Port…

I did notice that the Firmware keeps the IONI Serial Bus from being recognized while this issue is going on so I was not able to talk to the IONI through Granity until I got the SimuCUBE recognized.

This is expected, as the firmware takes control of the RS485 bus, and control has to be manually given to the USB port. Thats why there is that button in the configuration tool. There can’t be two masters in RS485 bus.

I figured that but I wrote it just to confirm that it was seemingly doing what it was supposed to. Therefore I didn’t panic… lol and to basically say that during this issue that port was invisible to Windows.

New bug found.

I have a new control that I built which I had installed MMOS initially then upgraded to the first beta.
I just tried to install MMOS back on the Simucube as I sold the control.
When using DfuSeDemo to put mmos dfu back on it takes a long time to update. Approx 1min. I do get the successful update message.

After installing Ionifw 1.5.8 firmware and reloading proper drc to Ioni when launching mmos the USB key symbol next to setup button is red.
I tried several times to install the mmos dfu back on simucube with no luck.

Has anyone else tried to revert back to mmos and been successful?

Wasn’t the icon red in MMOS until the wheel was turned over the index point? Not sure…

Yes that is correct Mika.
I never got the blinking light on the simucube.

I just tried to install mmos dfu on another control and have same issue. Now I am guessing if something got corrupt on my pc?