Main Site Documentation

Windows10 USB drivers


#1

Hello,

I know this subject has appeared before, but I can’t find an answer, so I’m going to ask again.

Installing drivers for EMX has never been a flawless process even on Win7. Somehow you need to go to list of devices, find GHI category and then propose a device. After that magically EMX becomes EMX.

For Windows10 no such luck. EMX appears as in the list of devices as unknown device and nothing works. Legacy drivers are not working.
Latest release doesn’t propose remedy either.

So what should I download, install in order to EMX appear as EMX device USB device ?

Thanks
M


#2

I am not aware of any issues when using win 10. Is this a virtual machine?


#3

I’ve been having a similar problem with Windows 10 and GHI drivers although it’s on a much older board; a Panda II running 4.1.8.0 firmware and SDK 4.1. The bootloader driver seems to be the most problematic. Whenever I try to start the bootloader Windows 10 installs a Microsoft USB Serial Device driver dated 6/21/2006, version 10.0.14393.0. Even updating the driver by pointing to the specific GHI driver does not work and results in the attached error message image.

I know I’m referring to a system that is long out of production but when I saw the current posting I thought the problems might be related. Besides I still have over 80 Panda II’s that I’m working with and would hate to have to write off that many because of a driver issue. Any ideas?


#4

@ idafez -
Have you tried to update the driver?

I have Windows10 PRO
Yours
Windows 10 installs a Microsoft USB Serial Device driver
dated 6/21/2006
version 10.0.14393.0.

My Windows 10
dated 3/28/2016
version 16.1.1.0

File version 10.0.14393.0 (rs1_release.160715-1616)


#5

@ idafez - 4.1 did not use win USB drivers. This would explain why.


#6

@ Gus -

You even work on Sundays! ;D


#7

@ Gus & @ willgeorge

I know 4.1 didn’t use Win USB drivers but Windows 10 is preventing me from using the GHI driver from the 4.1 SDK. It’s as though WIN 10 sees the GHI hardware (Panda II) and then defaults to the Windows USB driver without asking if I want to point to a specific GHI driver. Then when I attempt to update the driver it fails as noted in my first post. Because of this behavior I’m thinking it’s a Windows 10 issue unless there’s something amiss in the registry. Page 31 of the old USBizi manual had a reference to a potential registry problem:

Important Notes:
• Be CAREFUL when changing the USB configuration and settings, as you go on
with development and creating your USB device and connecting it to the PC,
Windows might save the device information in its registry. Therefore, if you change
the USB device settings/interfaces and connect it again, it might not work correctly.
Make sure to be careful with changing your USB device settings. You may also
need to delete all the settings from Windows registry manually.

And willgeorge I see what you are saying but would that new driver work with an old 4.1 firmware/hardware and if so where would I get it? - The latest SDK?

As for Sunday work, this isn’t work is it? More like the Sunday times crossword puzzle, but thanks to you both for being around.


#8

@ idafez - The latest 2016 R1 SDK should be the only thing you need to use 4.1 and the latest 4.3, including drivers. I’d uninstall everything GHI related and then follow the steps on https://www.ghielectronics.com/support/netmf. Make sure to go into the advanced options to select 4.1 in the installer.


#9

Thank you, John. I will give that a try. I see that Visual Studio 2017 supports .NET 3.5-4.6.2 so I suppose I should upgrade that also, right?


#10

@ idafez - If you are using NETMF, we recommend Visual Studio 2013. The support for .NET 3.5 to 4.6.2 in VS 2017 is different than supporting NETMF 4.1 to 4.3.


#11

@ John -

On new machine (windows 10) I have EMX marked with yellow triangle.
I did complete uninstall and downloaded latest GHI Electronics NETFM SDK 2016 R1.
EMX appears in device manager marked with yellow triangle (no driver).

Tried old drivers. Tried legacy. Tried pretty much everything.
Just spent another 2 hours on that.
Doesn’t work.


#12

@ SFR75 - When you get the yellow error mark, can you open up the device in the Device Manager and see what Device Status on the first sheet tells you?


#13

@ John -
I updated everything as you recommended, VS2013, GHI 2016 R1, and similar to SFR75 the problem of seeing the bootloader persisits. I’ve attached a screen shot of Device manager that shows the newest GHI driver but the details tab points to a MS driver if that is relevant.

Another odd thing is that sometimes it works but very infrequently and I can’t discern a pattern.


#14

@ idafez - The actual driver itself is the default one that comes with Windows. We only provide an inf file to tell Windows to use it.


#15

@ John -
OK, thanks. Let me know if you can think of any other reason why the bootloader can’t start. Otherwise I’ll just keep digging.


#16

Another piece of information. In one of the rare times when Device Manager drops the ! point and it looks like the device might work (although still not recognized by either Fezconfig or TeraTerm) I get the following message:

“Device USB\VID_1B9F&PID_0104\5&34a978af&0&1 requires further installation.”

See also the attached screen shot.

Does this generate any new ideas for how to solve the problem?


#17

@ idafez, you did do the INF file edit and reinstall based on that INF? That seems to me to be that your device doesn’t have the right association to bind the driver correctly


#18

@ Brett - Thanks for the reply. I’m not sure what edit you refer to. I’m installing the inf file dated 3/28/2016 that came with the GHI SDK 2016 R1. Does that file need something corrected?


#19

@ idafez - On the Windows 10 machine, are you still seeing the “the device cannot start (Code 10)” error in the device properties in Device Manager?


#20

Sorry, there’s a different thread with an INF change. Ignore that.

John, he said that most times it fails but occasionally it does not. That second screenshot mush have been one of those times when the error was potentially different.