Win 7 to Win10 and the VCP. Oh and VB6.

[shingadaddy]

Hello ST folks.

Recently, "THE MAN" updated us to Win10. Of course this broke a few (dozen) things.

Oh yes . I know VB6. Unsupported thin ice. Just like they like it around here. The story is we have a load of small TEST applications wrote with this and were quite content with them. Would LIKE to see them work as they did on Win 7. Anyway -

Win 7 :

Happily using VB and the STM32L476 and the VCP app. Modified very little from the CubeL4 Example offerings. Yes - HAL. I know. But it was quick to use.

Win 10:

Busted. As soon as I fire up a VB application that hooks to a VCP com port I get a friendly Winders banner / box. Like so-

(Imagine a box around this next couple of lines. )

RUN time error '8015' Could not set comm state., there may be one or more invalid communication parameters.

I know 8015.

No. Not Blocked with DeviceLock

No. No other device or application hogging the com port. Doesn't matter which com port I force it too I get the same result.

VCP driver tried = ST1.31, ST1.4, ST1.5, Windows INBOX driver usbser.sys. (You probably know where I got that little phrase )

Anyone else have any experience with this one?

It's somewhat of a stumper for me so far.

Thank you all !

[TDK]

I think this is a VB6 issue rather than an STM32 one. Can you connect to the VCP from another program such a PuTTY?

[shingadaddy]

Thanks TDK. Eh. Yeah maybe. So many things change when you swap an OS it could be. Drivers, migrations and on and on. However clinging (somewhat) to "What changed is probably what broke things" and loosely holding to "We didnt change VB" makes me want to lean toward OS and away from VB but you could easily be right!

And YES. I use Termite a lot. Mainly just due to enjoyment of the reactions I get from people hearing the name. It hooks to the port and TX/RX seem normal.

I can easily try other termapps too I guess.

So I don't think it is STM side at all but thought someone here might have run onto this. I trust this forum and the contributors very explicitly. Doesn't mean I didn't LOOK in the STM side however. Mainly because my use has *my* fingerprints all over it. =)

I've seen errant firmware in the device cause some similar weird results but not this one.

Also trying to UNINSTALL drivers in Win10 seem fraught with pot holes too.

Within WIN10 subject matter - This 8015 thing doesn't seem to prevalent in google searches either but the uninstall thing seems widespread.

Its typical MS trying to help us out.

[shingadaddy]

From the ST supplied "version.txt" file supplied with the latest Version1.5 of the ST Virtual Com Port Driver!

* V1.5.0 - 02/05/2018

=====================

New Features

************

    + Install simplified for better user experience depending on Windows OS,

  + For Windows 10, use Microsoft inbox driver and not this package. <------------------------------------------ !!!!!

Well I took that as " the drivers with Win10" :\

Turns out. Maybe not.

So knowing I can always download and re-install the ST drivers ( but I guess I shouldn't NEED too) I go ahead and follow my instincts.

Its ingrained in me too:

Plug the device in

Uninstall it with Device manager and DELETE the driver file. (This does NOT delete the files you downloaded but I humor the intent. )

Delete the 1.4 and freshly downloaded 1.5 driver folders. (Just in case something tries to be sneaky)

Go to Add/Remove programs and look for the DRIVER packages.

Try to uninstall those - RESULT ----- ***** Error ****** Cant find stmcdc.inf file (??)

Okay I'll pursue that weirdness later...

ONWARD!

Unplug device.

Reboot

Plug in device

Windows finds it and near immediately flags it with the feared Yellow triangle and exclamation point.

I figure its still installing and just hadn't found the "INBOX DRIVERS" yet. I wait -----------------------------------------------------------------

But no. Its done. And does not work. BUT!!!!! Device manager shows that the "Windows" (Supplied by Microsoft) driver (usbser) is installed !

I bug MS. They say "Reload the old ST driver." :\

Done. Enumerates seems to work up until my first issue explained above. THAT is still an issue.

I wouldn't throw your 1.4 or 1.5 version ST VCP drivers away just yet.

[shingadaddy]

Okay help me out here a second please - So still tinkering with this. a few findings but not fixed as yet.

Summary

• Windows 7 and ST USB cdc

Using a VB6 application that uses a COM port ---connected to a ST (my) widget with USB that enumerates as - A COM PORT ---- Works.

• I get Win10 put on my computer.

Using a (THE SAME) VB6 application that uses a COM port ---connected to a ST (my - SAME) widget with USB that enumerates as - A COM PORT ---- DOES NOT WORK.

Details -

- Enumerates okay.

- When VB tries to open com port - I get Error. 8015. No matter WHAT com port number I force.

- Using a Terminal applications (putty/termite or whatever - ) = Works .

Me thinks- okay my device is supposed to be acting like a USB to RS232 converter basically. So I go and retrieve a few of those out of the dust

Install driver

Plug in

Poof Virtual com port as expected.

Launch SAME VB application :

Works

????????

So I have WIN10 and VB happy with the converter and ITS driver.

And I have Win10 and VB NOT happy with ST widget and ITS driver. Throwing 8015.

The converter certainly loads different drivers than the ST driver. ( Which is the a Microsoft driver under the hood )

And -- I don't change the ST widget hardware or its loaded firmware.

What do you folks think ??? ST driver oddity with Win10 ????

[Pavel A. · Accepted solution]

Does your firmware properly handle requests to set and get line parameters? You know, the baudrate and so on?

-- pa

[shingadaddy]

Thanks Pavel A. Excellent question and something I've pondered. Quick answer- I don't believe so and since it worked with WIN7, the thought never worried me. On MY end (the ST end) there is NO UART to set parameters into. So I'm pretty sure I have that removed. This does worry me.

Here are some more details I've sent in to MS AND ST to get some answers.

"The ST micro and its driver seem to enumerate as needed but when the port open command is encountered is when the error is thrown. Seems something gets heartburn at that point. VB application seem to get heartburn just before the application tries to communicate. 

On the ST end - there is no COM PORT. The sent com port parameters from the PC over USB com port app over endpoint 0 are not used.

Along with any hints that might prove helpful, is there ANY difference in how Windows 7 and Windows 10 handles USB2.0 device enumeration or COM PORT control responses expected back to the PC, that might be an issue here???"

Why use a com port at all? you might ask.

Well I have to deal with folks on the PC side that are very busy and seem to express somewhat of an aversion to writing drivers. So the instant gratification of a USB hookup magically appearing and being a known entity to write and read data to/from, got things in production QUICKER. I'm seeing possible changes in that now but it is slow. They have been somewhat indoctrinated by D2XX from FTDI. No COMM port. No comm parameters to set. Just direct CDC class USB communication.

But I'm obviously NOT using FTDI hardware for USB. I'm ditching the extra chip and using a micro with built in USB. Hence - Another driver. But probably real similar to their new-found DIRECT experience. I hope...

So yeah. Maybe Win 7 and Win 10 do things a little different on the USB side. Like maybe Win10 tries to confirm the UART settings and === IM NOT SENDING IT ANY!

ASI said = great question! I might be poking some of that UART code back in my project !

[shingadaddy]

Pavel A.

That was It!.

Appears there is some subtle difference in Windows 7 / VB6 and Windows 10 / VB6 with regard to USB to UART converters.

Guesses :

It APPEARS – Windows 7 just flings UART parameters at the USB to UART converters of THAT DAY ---- and hopes it gets it.

Windows 10 appears to fling UART parameters at the USB to UART converters of NOW – and then READS THEM BACK to make sure they got there !

So: 

By carefully dissecting the example code, and plucktus rectus guessing the above --- I re-enable a few slivers of functionality in the UART stuff that I

had commented out since we don’t use UART for this on our end. Those UART “SLIVERS�? were wound into / mixed into the CDC USB side of things.

------------  Line coding responses to USB requests. ( CDC_Itf_Control in usbd_cdc_interface.c )

This is all handled in ST code with Function pointers ( virtual function calls ) which was pretty unfamiliar territory for me. – NOT ANY MORE.  ( Today anyway :beaming_face_with_smiling_eyes: ) 

No more 8015 errors.

Thanks for the responses folks!