STM32F4-DISCOVERY not visible in VS nor MFdeploy

[piwi1263]

Call me thick, but after having compiled the FW, SDK and deployed as usual. I wanted to make my first blinky and it kind of surprised me that VS2013 did not recognize the device neither did MFDeploy 4.4 and those 4 colored LEDs are on. However, MFDeploy of 4.3.1 does recognize the device.

Any directions or instructions or help to this basic question.

[piwi1263]

Cleared me self, was usb driver issue. In device manager uninstalled usb driver, usb unplug, plug cycle and STM32F4DISCOVERY board was back. Could deploy and ran from VS2013 the typical blinky.

[cwalker-secretlabs]

To add to this report, I am also experiencing a variant of this issue. The device appears fine in MFDeploy (and pings, etc.) But neither Visual Studio 2013 nor Visual Studio 2015 RC can see the STM32F4DISCOVERY boards. The USB transport device dropdown simply lists .

At this moment, it is not possible to use .NET MF 4.4 beta with STM32F4DISCOVERY on my laptop.

The SDK build is standard. The PK build is /p:flavor=debug with no changes.

I also uninstalled the device from Device Manager. And tried rebooting.

I am running Windows 10 Build 10162.

[piwi1263]

Hi Chris,

happy to see I'm not the only one suffering from this USB whatever. But than again, soyry to see this happening at all.

I've got a .netmf device with the same VID/PID as used in the usb_config.cpp maybe that intermix is not good, dunno, I'm not an USB expert. Sometimes that device shows up as a STM32F4DISCOVERY but shows in the VS USB selectbox as its real name and deploy can be done. And sometimes I have to deleted the driver in dev.mgr. unplug/plug cycle and it works as well. But at the next system start the probs are back again. So I guess my Win8.1 64bits is not at an optimum to put it mildly.

Kind Regards,

Peter.

[smaillet-ms]

@piwi1263, having multiple unique device types with the same VID/PID is always a recipe for disaster as the VID/PID is used by an OS to determine which drivers to load when that device is detected.

Also note; The "V" in VID is a Vendor Id issued by USB.org and paid for by the owning vendor so you should always use your own VID and not one found in sample code when releasing your device. We've considered modifying our published samples to have an invalid VID/PID by default to prevent accidental mis-use.

[smaillet-ms]

@cwalker-secretlabs, Was that with unmodified sources for STM32F4DISCOVERY? While I'm stuck without JTAG debug on my board, it does have TinyBooter and the CLR on it and they work fine with VS2015 and the V4.4 MFDeploy.

[smaillet-ms]

Sadly my Discovery board went belly up (well, more accurately the STLINK part went belly up so I cant reprogram or debug on it. :cry: We've got some more on order, but purchasing can take a while. However, it does have TinyBooter and the CLR on it which are working fine with MFdepoly and with VS.

For those experiencing issues are you on a 32bit or 64bit version of Windows?

[piwi1263]

@smaillet-ms, in my case the devices, actually most of the devices are from ST, so a VID=0x0483 is in order as far as I know. On my Win8.1 machine it is recognized as a Nucleo411RE with PID=0xA08F and using winusb. The same device, an STM32F4DISCOVERY, plugged into a Windows 10 Build 10162 machine is listed as it should be STM32F4DISCOVERY. No changes made to the board. And if I plug in the real Nucleo411RE board it is listed as another device with probably the same VID/PID combination. So I'm guessing, my win8.1 dev machine is kind of messed up and needs to be setup again. And I think the USB mess up has become even more by installing the 4.4. alfa software in addition.

These are different boards, so I reckon they must have different PIDs for USB OTG connector ?

The DeviceInterfaceGuid for WinUsb (?) should/can/must be the same correct ?

So the boards must have some ID where they can be recognized and as far as I am correct that would be the PID.

I mean, MB1136=NucleoF411, MB997C=407DISCOVERY, MB1075B=429-DISCO and MB1191B=STM32F746-DISCO are diff physical boards and they should have different PIDs, the questions is which ones. Are these to be made up oneself, or is there a list of to be used PIDs ?

Looks like I've got some reading to do ... any help/clarification/links to more info is much appreciated.

[piwi1263]

@smaillet-ms, Oh, I'm sorry for the loss ... If I order at digi key they are over here in europe mostly in about 3 days. They've got 700+ on stock so you can try http://www.digikey.com/product-search/en?KeyWords=497-11455-ND&WT.z_header=search_go if you want to.

Oh, and I only use 64 bit windows versions.

[smaillet-ms]

@piwi1263: " in my case the devices, actually most of the devices are from ST, so a VID=0x0483 ", That would be incorrect! Unless you bought and paid for that vendor ID you can't use that VID in a shipping product. The entity that can use that is the one that bought it. The PIDs are entirely defined by the VID owner so if you aren't the owner and you use someone else's VID with a PID you picked you are risking a collision, not to mention a visit from some unhappy lawyers knocking on your door. The NETMF tools all use the DeviceInterfaceGUID to find a NETMF debug/deploy device. They don't care about the VID/PID.

The DISCOVERY board firmware uses the same technique the reference MCBSTM32F400 platform uses for a "no driver install" experience. The USB configuration data contains extended OS descriptors that identify it as a WinUSB enabled device and the OS can then load WinUSB as the driver for that device. Furthermore, the descriptors also include an extended property descriptor that provides the DeviceInterfaceGUID for NETMF debugging. The OS knows hows to read that property descriptor and adds the GUID to the set of interface guids for the device, so that no additional registration is required. Thus MFDeploy and VS can search for devices supporting that interface. In the end this means the days of every vendor needing to build the USB driver source or at the least building a signed INF file to describe the device based on VID/PID is not needed anymore. (As such we've completely removed all the old legacy USB driver stuff from the tree). It should be as simple as plug it in and the OS automatically takes care of loading the correct driver (WinUSB) an when that's completed MFDeploy/VS see it.

@piwi1263: Oh if it were only so easy to purchase things here, I could order same day delivery from Amazon... But we're a big company with complex procurement procedures to avoid fraud and even the appearance of any impropriety, thus everything goes more slowly...

[piwi1263]

@smaillet-ms, Thank you for the clarification in the (Win)Usb logic. Got that with the VID/PID and the legal etc.

I assume, the boards descriptive details are retrieved through some flavor of get descriptor functions. So the VID/PID is just treated as one of the properties of the board as the text displayed in the device manager. WinUsb is used as the means over which the property data is transported.

However, strange that when I plug-in board a being recognized as board b and board b as board c ... I guess there must be some custom drivers flying around on my system messing up the usb stuff, but that is for me to solve.

Yeah, working for a big company has it's moments, I work for one as well. Luckily I'm doing this more privately so I've got a little advantage on the purchase process but not on the price in the end ... well, I guess there's always something ...

[smaillet-ms]

Yes, the VID/PID are pretty much the first descriptor items read by the OS. If it finds a driver registered for the VID/PID pair it loads it - done. Otherwise it goes on to check for standard class/interface descriptors and if found loads checks for a registered driver for that and loads it. If after that it still hasn't found a driver it moves on to the extended OS descriptors, which should be present for all new NETMF v4.4 devices and it see's it marked as WinUSB so it loads WinUSB, then sees the additional extended OS property for the DeviceInterfaceGUID and applies that setting to the driver to announce to the system a device with the interface specified by that GUID is now present in the system.

[cw2]

@piwi1263, @cwalker-secretlabs: Could you please try building the solution with different USB VID/PID?

@smaillet-ms: Is there any kind of "invalid" or "reserved" USB VID/PID (or any other mechanism) that could be used to skip the driver loading and force extended OS descriptor query?

[smaillet-ms]

@cw2 No, VID and PID are required as defined by the USB specification. On Windows you can remove any stored bindings by opening Device manger finding the device and right clicking on it. This brings up a context menu where you can select to uninstall the device. This option brings up a confirmation dialog and, if the device has a driver associated with the VID/PID, an optional checkbox to remove the driver as well. This will force uninstall the driver so the next time the OS sees an insert with that VID/PID it searches for a new driver. (There are likely programmatic means of doing this with the driver setup or WMI APIs but I've never had reason to think about trying that so I can't give any particulars)

[piwi1263]

@cw2 - In addition to what @smaillet-ms said if you select to view the properties (same window where you have the selection to uninstall the device) you will see if the winusb driver has been taken as it is in my case now. I didn't get that optional check box in the uninstall confirmation window so before continuing I choose to have a closer look at the facts and they state that what I'm expecting. In this case the winusb driver is selected that would mean no device specific driver for the VID/PID combination has been chosen. In my case the test VID/PID as used in the usb_config.cpp source.

Details from the Driver props: Device USB\VID_0483&PID_A08F\5&1b53c060&0&1 was configured.

Driver Name: winusb.inf Class Guid: {88BAE032-5A81-49F0-BC3D-A4FF138216D6} Driver Date: 06/21/2006 Driver Version: 6.3.9600.16384 Driver Provider: Microsoft Driver Section: WINUSB.NT Driver Rank: 0xFF2000 Matching Device Id: USB\MS_COMP_WINUSB Outranked Drivers: oem52.inf:USB\VID_0483&PID_A08F:80FF0001 Device Updated: false

However, one thought has crossed my mind though, I would expect to have a winusb driver datestamped DriverVer=01/24/2012,6.2.8181.0 since I use win8.1, but the window states the win 7 date stamp and version. Plus it mentions the ClassGUID = {88BAE032-5A81-49f0-BC3D-A4FF138216D6} and that is the win 8 one. So I'm not sure why this is as it is.

[cw2]

@smaillet-ms Ok, I did not mean not to use VID/PID at all, but rather to use some special value to 'ensure' there is no driver. I guess the best solution would be to have a dedicated (Microsoft ?) VID/PID for a generic NETMF board, because ST test pair (0x0483/0xA08F) is used multiple times (ST boards firmware demos).

[smaillet-ms]

Actually my point was there is no such thing - USB specs require every vendor to get their own unique Vendor ID. STM has apparently purchased one for use in their development boards, but in any such scheme (even if Microsoft were to provide one) there will always be clashes on the PID since there is no central control over what device gets what PIDs. To paraphrase an old Don Box rule on COM interface GUIDs. - If you ship a USB device more than 2 cubicles away, you need your own VID to prevent clashes.

[cpfister]

Note that STMicroelectronics provides USB product IDs for their vendor ID upon request, of course only if you use an STM32. Here the form that we filled out for our Mountaineer boards. Please contact your ST representative for that though, not us ;-)

Cuno

---

ST Microelectronics provides the service of product ID / vendor UD sub-licensing to its small customers. This sublicensing is under special agreement between USB-IF, ST and ST customers. It is valid only when STM32 MCUs are used here You need to provide the details below. ST only offers one PID for a product that you will sell. This means if you have several products, they need one request by product (for follow-up purposes, the USB end-product can be the “USB device descriptor string”, and the ST contact is your usual ST support person). Company Name *
Customer Contact Name *
Customer E-mail address *
Customer Full Address *
Sales-Type of the Microcontroller *
Name of USB End-product *
Qty/Year *
Production Quantity per Year Production Start date *
ST Requester Name *

[doingnz]

I appear to have the same issue with the STM32F4 Discovery solution where the Discovery board is enumerated by Windows 7, and the WinUSB driver is assigned, however MFDeploy cannot find the device.

I have tried changing the PID to a different number and the device is again detected and the WinUSB driver assigned to the new PID, ... but still not visible in MFDeploy.

I can plug the device into another PC running Win10 or route the USB device on the host Win7 to a Win10 client OS (inside VirtualBox VM). The SMT32F4Discovery board is detected by MFDeploy/VS2015 in either Win10 machine.

On Win7, Device manager lists it under "Universal Serial Bus devices" as "WinUsb Device".

On Win10, Device manager lists it under "Universal Serial Bus devices", but it is listed as "STM32F4DISCOVERY"

Device manager on Win10 lists the following Device USB\VID_0483&PID_A08E\5&35f564d4&0&3 was configured. Driver Name: winusb.inf Class Guid: {88bae032-5a81-49f0-bc3d-a4ff138216d6} Driver Date: 06/21/2006 Driver Version: 10.0.10240.16384 Driver Provider: Microsoft Driver Section: WINUSB.NT Driver Rank: 0xFF2000 Matching Device Id: USB\MS_COMP_WINUSB Outranked Drivers: Device Updated: false

Has anyone solved why MFDeploy cannont find the dev board?

[smaillet-ms]

That suggests to me that for some reason the WinUSB support on that system isn't updated. (Automatic updates should cover that) The support necessary to auto recognize a device was introduced in Windows 8 but AFAIK was back ported to Win7 at least. You could try enabling the "Legacy USB option". This basically ignores the Device interface GUID and shows any device with a USB string descriptor at a specific location that, for a NETMF device, is the name. (IIRC the string id is 5 but that doesn't really matter) Using the legacy mode will, as a result, also show none NETMF devices that happen to have a valid string at that descriptor index. (The legacy mode was a compromise fix for bugs reporting that we showed invalid devices or junk noise in the list )

[doingnz]

I have tried 3 different Win7 systems, all appear to be up to date as far as the Windows Update service is concerned. All do the same thing.

Is there anyone with Win7 using WinUSB successfully currently?

If I uninstall the WinUSB driver, Windows dutifully goes online and downloads the driver and installs the WinUSB driver again.

During that process, the STM32F4Discovery name is displayed with a warning symbol under "Other devices" in Device manager. When the install finishes successfully, that name and warning is removed and the device is listed as a WinUSB device under "Universal Serial Bus devices" with the correct PID/VID.

Is there a WinUSB tool I run to check that it can find the installed SMT32F4Discovery device?

[doingnz]

I have found that MFDeploy can find the STM32F4Discovery on Win7 if I manually create a Multi-String registry entry named DeviceInterfaceGUIDs with value {D32D1D64-963D-463E-874A-8EC8C8082CBF}

In my case it is created as below as I have the VID=0483 and PID=A08E.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_A08E\6&2ef5ba4&0&4\Device Parameters]

i.e.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_A08E\6&2ef5ba4&0&4\Device Parameters]
"DeviceInterfaceGUIDs"=hex(7):7b,00,44,00,33,00,32,00,44,00,31,00,44,00,36,00,\
  34,00,2d,00,39,00,36,00,33,00,44,00,2d,00,34,00,36,00,33,00,45,00,2d,00,38,\
  00,37,00,34,00,41,00,2d,00,38,00,45,00,43,00,38,00,43,00,38,00,30,00,38,00,\
  32,00,43,00,42,00,46,00,7d,00,00,00,00,00

Note specifically that it does NOT work if I manually create a String registry entry named DeviceInterfaceGUID. Only the Multi string version works correctly on my Win7 machine.

I tried a quick hack to USB config to use MULTI_SZ. This did not work. (i.e. with the registry item removed, and MULTI_SZ in device descriptor.

EX_PROPERTY_DATA_TYPE__REG_MULTI_SZ, //EX_PROPERTY_DATA_TYPE__REG_SZ,                      // data type (unicode string)

Maybe other changes, not just replace REG_SZ with REG_MULTI_SZ?.

[valoni]

i bought recently STM32F407VGT6 and in Win10 x64 under Universal Bus Serial devices it show me STM32 Link device

used ST-Link utility uploaded HEX for 4.4 and restarted

but on MFDeploy do not list this USB

another info what i see after checking throught ST-LINK is it show me (through USB - mini B type cable) Device : STM32F405xx/F407xx/F415xx/F417xx Device ID : 0x413 Revision ID : Rev 2.0 Flash System : 1MBytes

maybe it need to change Device Id Descriptor to be recognized or need to modify USB Drivers to include on MFDeployment 0x413