Oh boy.
All the things I assumed were completely wrong. If you not only got the VCOM working yourself, but set up the Primer to function as a virtual NI instrument, you’re already working at a level of complexity a couple of notches above anything I’ve done. Apologies for the lack of respect!
Aside from the usbdisconnect pin that you already mentioned, the only important difference I see between my Primer2 and the Olimex board is that the Primer2 has an external 12MHz oscillator, while the Olimex board has an 8MHz crystal connected to the STM32 oscillator pins. So in your startup config for the Olimex board you’d have to clear (or not set) the HSEBYP bit in the RCC_CR register, and your PLL multiplier would probably be 9 instead of 6.
I say my Primer2 because the usbdisconnect on my Primer2 is D.3 rather than D.9. If we have different flavors of Primer, the oscillator circuit might be different as well.
Regarding the vendor and product ID, I suggest during the debug stage you continue to use the values from the ST VCOM example.
I don’t have an Olimex header board, but I tried a simple modification of the ST VCOM example on two budget (Chinese) boards as well as my Primer2, with just the differences mentioned above. Each worked ok with HyperTerminal. (Windows did report “new hardware found” for each one. I know there is a section of the VCOM code that reads the unique serial # of the STM32. Perhaps that is involved.)
This is well outside my area of expertise, but I know that if you use a different VID and / or PID, you’ll have to supply a .inf file for use with windows. (I’m not clear on the equivalent process with Linux.) If you search the forum at ST.com (a slow and painful process) you’ll find a thread where ST support says they’re willing to supply a product ID for products using their chipset. The product would then have the ST VID and its own unique PID. But my impression was that they were talking about products for commercial production.
It sounds as if you based your application on the ST VCOM example? If so, the supplied code responds to interrupts generated by the USB hardware and takes care of all the enumeration. You should not need to add anything except the hooks you used with the Primer. (I’m still wading through the details myself; the app-specific code starts with stm32f10x_it.c, a lot of it is in usb_prop.c, and of course the bulk of the generic code is in the usb library.)
Best Regards,
-Hugh