I went through .inf files and compared the VID/PID combinations to be the same as my device enumerated to - and it was the same, of course. The bat files and inf files looked sane. I have no idea why it didn't install correctly.

mrburnette wrote:Anyone that demands 100% perfect downloads 100% of the time, really should back off the STM32 bootloader and go to a different, less problematic flash methodology.

Ray

A bit over the top is this? I've worked daily for years and years with ARM7/Cortex, re-flashing my dev board with wanton abandon. Read-back verify every time (JTAG or SWD) and/or my own re-flashing code for remote updates. Some days I'm re-flashing for SWD debugging after a recompile at a rate of many per hour.

I've never had flash fail to read-back OK. Call me lucky, but this is NXP, Freescale, Atmel, ST. Several chip types each.
In production, the chips get flashed once. Then maybe 3 times a year due to updates.

The fact it works on some win7 64b, and it doesn't on some (except usb hw issues, which I would consider less probable) it might indicate the driver does not install because of other installed drivers. Zadig simply somehow forces USB CDC to install.
As I wrote above, I did with zadig 2.1 and I did not get an USB CDC offer for Maple. After I had taken the zadig 2.2x it offered me the USB CDC for Maple and it started to work.
So my current understanding is - a driver collision, or other (ie Avira is blocking it??, not tried yet).
I am a long time happy Win user and I do not have any fundamental issue installing drivers for any kind of crazy dongles I am doing last years.. Of course I am using Linux too, but in limited quantities..

stevech wrote:
<...>
I've never had flash fail to read-back OK. Call me lucky, but this is NXP, Freescale, Atmel, ST. Several chip types each.
In production, the chips get flashed once. Then maybe 3 times a year due to updates.

GeeWhiz.... I was discussing the 3 basic OS platforms and the existing bootloader. No reference to the flash integrity. Just download process from IDE click until the sketch comes up...

In my use of Windows and Linux, I perhaps have 1 failure of the "download logic" out of 10 tries. Not bad, but not perfect.

stevech wrote:
<...>
I've never had flash fail to read-back OK. Call me lucky, but this is NXP, Freescale, Atmel, ST. Several chip types each.
In production, the chips get flashed once. Then maybe 3 times a year due to updates.

GeeWhiz.... I was discussing the 3 basic OS platforms and the existing bootloader. No reference to the flash integrity. Just download process from IDE click until the sketch comes up...

In my use of Windows and Linux, I perhaps have 1 failure of the "download logic" out of 10 tries. Not bad, but not perfect.

Ray

Ah, I misread... you are talking about re-flashing / bootloading as a process and protocol, not a failure of the flash media, it seems.

I've installed stm32duino on an older win7 32bit machine (1.6.10 nightbuild, Maple Mini, Bootloader 2).
DFU works, upload is ok.
Serial over USB - it shows in dev manager as "Mass Storage Device", I've used Zadig 2.2.689 to replace it with Serial CDC, but no luck.
Still shows Mass Storage device on COM18..
PS:
After 4hours of messing with drivers it seems the issue was with Bluesoleil Bluetooth driver. After reinstalling it I see Maple as COM13 (without using zadig).
The other issue I see: when hw resetting Maple it ends up in DFU mode after the reset, so it does not continue into Serial (Maple COM13 does not appear in the dev manager). Pluging/unpluging also ends in DFU. Sometimes Maple COM appears, after the upload I get usually (port set to COM13):

Back when I was using Win 8.1 (before my religious conversion to Linux) I had good success with Maple Mini... 90% to 95% success and re-enumeration to serial after download. As I only use Maple Mini clone, I have no other board experience to share.

Disclaimer: I am an ex-MCSE in windows workstation and windows server and my Win8.1 development machine was highly optimized snd I had the machine configured to utilize unsigned drivers.