search

NETMF / netmf-interpreter

.NET Micro Framework Interpreter
http://netmf.github.io/netmf-interpreter/
Other
487 stars 224 forks source link

Device not showing in MFDeploy #376

Open DerekGn opened 8 years ago

DerekGn commented 8 years ago

I have implemented a USB driver for the SAMA5D3 xplained board. The device enumerates correctly and shows up in device manager as a WinUsbDevice.

Below is the device information:

Information for device SAMA5D3XPLN (VID=0x03EB PID=0xA08F):

Connection Information:
------------------------------
Connection status: Device connected
Device actual bus speed: HighSpeed
Device is hub: No
Device address: 0x0002
Current configuration value: 0x01
Number of open pipes: 2

Device Descriptor:
------------------------------
0x12    bLength
0x01    bDescriptorType
0x0200  bcdUSB
0x00    bDeviceClass   
0x00    bDeviceSubClass   
0x00    bDeviceProtocol   
0x08    bMaxPacketSize0   (8 Bytes)
0x03EB  idVendor
0xA08F  idProduct
0x0200  bcdDevice
0x01    iManufacturer   "Microsoft OpenTech "
0x02    iProduct   "SAMA5D3XPLN"
0x00    iSerialNumber
0x01    bNumConfigurations

Device Qualifier Descriptor is not available. Error code: 0x00000001

Configuration Descriptor:
------------------------------
0x09    bLength
0x02    bDescriptorType
0x0020  wTotalLength   (32 Bytes)
0x01    bNumInterfaces
0x01    bConfigurationValue
0x00    iConfiguration
0xC0    bmAttributes   (Self-powered Device)
0x32    bMaxPower   (100 mA)

Interface Descriptor:
------------------------------
0x09    bLength
0x04    bDescriptorType
0x00    bInterfaceNumber
0x00    bAlternateSetting
0x02    bNumEndPoints
0xFF    bInterfaceClass   (Vendor specific)
0x01    bInterfaceSubClass   
0x01    bInterfaceProtocol   
0x00    iInterface

Endpoint Descriptor:
------------------------------
0x07    bLength
0x05    bDescriptorType
0x81    bEndpointAddress   (IN Endpoint)
0x02    bmAttributes    (Transfer: Bulk / Synch: None / Usage: Data)
0x0040  wMaxPacketSize   (64 Bytes) 
0x00    bInterval

Endpoint Descriptor:
------------------------------
0x07    bLength
0x05    bDescriptorType
0x02    bEndpointAddress   (OUT Endpoint)
0x02    bmAttributes    (Transfer: Bulk / Synch: None / Usage: Data)
0x0040  wMaxPacketSize   (64 Bytes) 
0x00    bInterval

Microsoft OS Descriptor:
------------------------------
0x12    bLength
0x03    bDescriptorType
Hex dump: 
0x12 0x03 0x4D 0x00 0x53 0x00 0x46 0x00 0x54 0x00 
0x31 0x00 0x30 0x00 0x30 0x00 0xA5 0x00 

String Descriptor Table
--------------------------------
Index  LANGID  String
0x00   0x0000  0x0409 
0x01   0x0409  "Microsoft OpenTech "
0x02   0x0409  "SAMA5D3XPLN"

------------------------------

Connection path for device: 
ASMedia XHCI Controller
Root Hub
Generic USB Hub
SAMA5D3XPLN (VID=0x03EB PID=0xA08F) Port: 4

When MFDeploy is launched the device does not show up in the list of USB devices. When I debug MFDeploy the EnumeratePorts method fails to find any device with a GUID of {D32D1D64-963D-463E-874A-8EC8C8082CBF}.

private static IEnumerable<PortDefinition> EnumeratePorts( Guid guid )
        {
            var devInfo = NativeMethods.SetupDiGetClassDevs( ref guid, null, 0, NativeMethods.DIGCF_DEVICEINTERFACE | NativeMethods.DIGCF_PRESENT );

            if( devInfo == NativeMethods.INVALID_HANDLE_VALUE )
                yield break; 
``
I am looking for some pointers on what may be missing.
smaillet-ms commented 8 years ago

Double check your USB configuration data structure. It looks like the OS descriptor is there but the Extended property setting (That auto populates the interface guid) doesn't seem to be picked up. Also what OS are you running against?

DGoslin commented 8 years ago

I copied the USB configuration from the STM discovery and just modified the VID and product name.

I am running against windows 7.

I will dump the USB set-up messages exchanged to serial port to see if I can see what is going on.

smaillet-ms commented 8 years ago

I'd recommend verifying the configuration against the official reference implementation in the MCBSTM32F400 platform - that one is known to work correctly.

DGoslin commented 8 years ago

I will double check the configuration. I wont get to it till the weekend.

Off the top of your head, is there any possibility of padding/alignment issues when the configuration is changed? Should I ensure dword alignment?

DerekGn commented 8 years ago

I think this is windows 7 driver issue. When I dump the USB request and response messages I can see that the host does not request the Extended Property information (wIndex == 5), so the device DeviceInterfaceGUID is not set.

I found this which is similar to the issue I am having http://blogs.msdn.com/b/usbcoreblog/archive/2012/09/26/how-to-install-winusb-sys-without-a-custom-inf.aspx#10372932

It might be time to upgrade from 7 to 10.

smaillet-ms commented 8 years ago

The WinUSB support for this was made available to Windows 7 via an update as I recall. We tested this feature against a clean install of Windows 7 with current updates when we enabled it for v4.4. Does the system in question have automatic updates enabled? Is it up to date?

DGoslin commented 8 years ago

Yep windows update is enabled, I believe the winusb driver is up to date.

I suspect that there is some other driver related issue specific to this dev machine. As I have seen other weird behaviour with the device enumeration, it will enumerate the .net 4.4 device via a 2.0 usb hub but not when connected directly to the 2.0 or 3.0 usb ports. Its a development machine that has had numerous usb devices and drivers installed. I have also use a winusb driver for a netduino device that I suspect was not completely removed.

At least after working through this I have a better idea of what should happen when the device is enumerated.

I think it would be better for me to do a clean install and start from there as I could be chasing my tail if I continue with the OS in its current state.

I will close this one off if I figure out what the problem is. Thanks for the help

smaillet-ms commented 8 years ago

Another common issues is a different driver already associated with that particular device VID+PID, even if it is Win USB based the VID+PID registration wins and the extended properties support is never used.

DerekGn commented 8 years ago

I have checked the VID+PID driver mapping and it is correct. The driver used is WinUSB.sys, the following are some of the details from the driver.

0       Name: winusb.sys
1       Size: 41.0 KB
2       Item type: System file
3       Date modified: 21/11/2010 03:23
4       Date created: 12/02/2016 13:02
5       Date accessed: 12/02/2016 13:02
6       Attributes: A
8       Offline availability:
9       Perceived type: System
25      Copyright: © Microsoft Corporation. All rights reserved.
33      Company: Microsoft Corporation
34      File description: Windows USB Class Driver BETA
155     Filename: winusb.sys
156     File version: 6.1.7601.17514
185     Language: English (United States)
270     Product name: Microsoft® Windows® Operating System
271     Product version: 6.1.7601.17514

I am not 100% sure that it is the correct version. I will attempt to reinstall the driver from the update catalog. If not I will make a clean windows 7 install and see how that goes

doingnz commented 8 years ago

See #215

Got it to "work" on Win7 after I manually defined a Multi String registry entry. DeviceInterfaceGUIDs with value {D32D1D64-963D-463E-874A-8EC8C8082CBF}.

Not clear why Win7 needs this defined manually for device to appear in MFDeploy/

josesimoes commented 8 years ago

That GUID is the ID for the NETMF debug class over USB. When MFDeploy is querying a "candidate" WinUSB device, if that class is not defined, is a reasons for it won't get "promoted" to be recognized as a valid NETMF USB device.

smaillet-ms commented 8 years ago

In v4.4 MFDeploy by default (and design) uses the Device interface GUID to filter out the set of WinUSB devices in the system to identify the ones that are explicitly NETMF MFDeploy capable devices. With a correct USB configuration based on the sample provided for the MCBSTM32F400 that should be all that is needed on Win7 or later OSes. Many devices don't have the correct configuration in them (Mostly due to a broken example in previous releases from MS) To support those devices MFDeploy (and the VS integration for NETMF) support a "legacy WinUSB" mode, where they will list any WinUSB device that contains a string in the USB configuration with a specific descriptor index ( I believe it is 5). which is where a NETMF device stores the device name. This is where the name that appears in the UI for MFDeploy and VS is derived from. This is actually what MFDeploy used to do - and leads to other issues where some devices that happen to have a string at that index but are most definitely NOT a NETMF device will still appear, causing confusion - or worse cause device failures when MFDeploy or VS try sending it commands assuming it is a NETMF device.

DerekGn commented 8 years ago

I meant to update this thread way back

I reinstalled win7 and the OS did not request the extended property information wIndex = 5.

I am using wireshark usb capture to trace the requests and some on board debug to serial.

I also added the Multi String registry entry and it shows up in mfdeploy.

smaillet-ms commented 8 years ago

The OS won't request the ID string(5) MFDeploy/VS integration will but ONLY if you enable the Legacy WinUSB option (by default it will ONLY show devices that advertise the NETMF debugger Interface GUID) This prevents conflicts with devices that aren't actually NETMF devices but happen to have a string at index 5. (which was a bug in previous releases)

doingnz commented 8 years ago

@smaillet-ms

Please note I am using the stock standard STM32F4DISCOVERY sample solution as provided in NetMf on GitHub.

I have compared "dev/Solutions/STM32F4DISCOVERY/DeviceCode/USB/usb_config.cpp" and "dev/Solutions/MCBSTM32F400/DeviceCode/USB/usb_config.cpp" and there are only minor cosmetic differences with strings.

What other places do I need to check in the supplied STM32F4DISCOVERY sample solution to look for differences in USB configuration between it and the "sample provided for the MCBSTM32F400"?

I may be missing the point, re the legacy USB support. It is not something I have knowingly enabled. How can I disable it or check that it is not enabled? Device manager lists the STM32F4DISCOVERY as a WinUSB device.

Regarding the MULTI STRING in the registry. If I remove the string or rename it, then MFDeploy cannot find the STM32F4DISCOVERY board on the WIn7 system. The WIn10 systems I have tried always just worked.

smaillet-ms commented 8 years ago

Actually Legacy WinUSB is disabled by default, in your case you want to enable it in MFDeploy so it can see your device.

BTW: is this a 32 bit or 64 bit install of Win7? IIRC we only tested against 64 bit, though I can't think of a reason it wouldn't also work on 32bit.

smaillet-ms commented 8 years ago

FYI: Full specs for the OS descriptors support used can be found here: https://msdn.microsoft.com/en-us/windows/hardware/gg463179 Additional info here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff537430(v=vs.85).aspx That second one has an interesting point about detection of the extended support only once per vid+pid. E.g. if the device is plugged in before getting the NETMF firmware but using the same VID=PID as the NETMF firmware would use, then it will be flagged as not supporting the extended support and the OS will not attempt to check it again. The status of that is stored in the registry so you might check and clear that setting to see if it can see your device. The extended support is spec'd as viable back to XP.

josesimoes commented 8 years ago

Windows will ask for the device descriptors ONLY ONCE. Doesn't matter if there is a suitable driver, if the device gets properly installed or not. Each device is flagged here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\ The combination for the NETMF Discovery solution should be 0483A08F0200. So you may want to delete that entry there before any testing so it behaves like the very first time that device is plugged in.

doingnz commented 8 years ago

I now have a clean Win7 in a VM.

When i route the STM32F4Discovery USB device to this VM, it works as expected and can be _found _ by MFDeploy !!!

However, it is still not found in the other Win7 VM using the same method of routing the USB device to that VM. This older Win7 VM has older Visual Studio installed and other dev tools. I am busy uninstalling them to find the guilty party.

Thank you for the pointer re usbflags\osvc. That is being set to the expected value on both the working and failing Win7 system. i.e. osvc is 0x00 0xA5

As per the link you gave, the expected value is defined to be:

0x01xx: The device provided a valid response to the Microsoft OS string descriptor request, where xx is the bVendorCode contained in the response.

the A5 is defined in DeviceCode\include\USB_decl.h as

#define OS_DESCRIPTOR_STRING_VENDOR_CODE  0xA5

Note that .netMF SDK is not installed on the working Win7 system. I am just running the NetMF 4.4 out of a copy of the BuildOutput folder copied to that VM.

smaillet-ms commented 8 years ago

Well, that's good news and some progress. Though I am curious about what is causing the fail case, you aren't the first to have a problem and I'd love to be able to have more info to help anyone else who might get stuck. (And see if there's anything we can do to prevent that in the first place)