I changed the enumeration routine to better match what we do in libmaple, only making the count up 3 times as long as the F4 runs much faster, and now the board re-enumerates correctly every time is reset.
The code I used is this:
pinMode(PA12, OUTPUT);
digitalWrite(PA12, LOW);
//HAL_Delay(1000);
for(i=0;i<1512;i++){};
pinMode(PA12, INPUT);
Daniels code seems to use
USB\VID_0483&PID_5740&REV_0200&MI_00
But the Nucleo boards etc use
USB\VID_0483&PID_374B&REV_0100&MI_02
But this could be because I’ve previously installed various USB CDCACM drivers for both of these and perhaps my system is a bit messed up.
I’ll try it on another machine
Daniels code seems to use
USB\VID_0483&PID_5740&REV_0200&MI_00
But the Nucleo boards etc use
USB\VID_0483&PID_374B&REV_0100&MI_02
But this could be because I’ve previously installed various USB CDCACM drivers for both of these and perhaps my system is a bit messed up.
I’ll try it on another machine
OT {
i did a little ‘deep dive’ into usb as i got somewhat interested in usb mass storage
ouch, usb is *complex*, not the basic concept itself, the basic concept is just send IN and OUT packets and 16 ‘endpoints’ per device 
but the whole protocol stack or usb ‘engine’ (the state machines) and the necessity to patch a module (st’s usb framework) that works as ‘call back’ is complex. and the differences between the platforms f1 vs f4 (f4 is v complex because it adds fifo buffers and OTG i.e. f4 can run as usb host – but we’d leave that aside for now)
i did note that the black f407vet6 doesn’t do a usb reset on doing a mcu reset, this in particular happens in the stm’s own dfu mode as well. (i.e. set boot 0, oh to do a dfu-util sketch install on the black vet6, all you need to do is
1) set boot0 and do a reset (for now it is necessary to unplug and re-plug the usb cable)
2) run dfu-util -a 0 -s 0x8000000 -D sketch.bin
no dongles, no uart, no st-link etc, the built-in st’s dfu bootloader 
http://www.stm32duino.com/viewtopic.php … =10#p26027
}
i guess what you are doing here is to pull both the usb lines D+ and D- down to 0 for 10ms (single ended zero)
http://www.usbmadesimple.co.uk/ums_3.htm
this would reset the usb bus and get the host/pc to start enumerating again i suppose.
however, i’m thinking if we should after all use system calls and perhaps use the usb pheriperial registers to do a usb reset instead
in rm0008 stm32f1 rm p629 23.4.2 usb reset << oops note this is for the f1
p640 23.5.1 usb common registers
USB control register (USB_CNTR)
Address offset: 0x40
Reset value: 0x0003
Bit 0 FRES: Force USB Reset
0: Clear USB reset.
1: Force a reset of the USB peripheral, exactly like a RESET signalling on the USB. The
USB peripheral is held in RESET state until software clears this bit. A “USB-RESET”
interrupt is generated, if enabled.
i’m thinking if it would be better if we write 1 into the USB CNTR register bit 0 to trigger this usb reset
for F4 we need to use a different register
rm0009 p1252 34.5.2 Peripheral states
Powered state
Soft disconnect
The powered state can be exited by software with the soft disconnect feature. The DP pull-
up resistor is removed by setting the soft disconnect bit in the device control register (SDIS
bit in OTG_FS_DCTL), causing a device disconnect detection interrupt on the host side
even though the USB cable was not really removed from the host port.
rm0009 p1306 OTG_FS device control register (OTG_FS_DCTL)
Address offset: 0x804
Reset value: 0x0000 0000
Bit 1 SDIS: Soft disconnect
The application uses this bit to signal the USB OTG core to perform a soft disconnect. As
long as this bit is set, the host does not see that the device is connected, and the device
does not receive signals on the USB. The core stays in the disconnected state until the
application clears this bit.
0: Normal operation. When this bit is cleared after a soft disconnect, the core generates a
device connect event to the USB host. When the device is reconnected, the USB host
restarts device enumeration.
1: The core generates a device disconnect event to the USB host.
we’d need to set the reset bits and wait 10ms for the host to start re-enumerating the usb ports
i think there may be some HAL api calls for that
just 2 c
i googled around the web and found this usbreset code
/* usbreset -- send a USB port reset to a USB device */
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>
int main(int argc, char **argv)
{
const char *filename;
int fd;
int rc;
if (argc != 2) {
fprintf(stderr, "Usage: usbreset device-filename\n");
return 1;
}
filename = argv[1];
fd = open(filename, O_WRONLY);
if (fd < 0) {
perror("Error opening output file");
return 1;
}
printf("Resetting USB device %s\n", filename);
rc = ioctl(fd, USBDEVFS_RESET, 0);
if (rc < 0) {
perror("Error in ioctl");
return 1;
}
printf("Reset successful\n");
close(fd);
return 0;
}
Daniels code seems to use
USB\VID_0483&PID_5740&REV_0200&MI_00
But the Nucleo boards etc use
USB\VID_0483&PID_374B&REV_0100&MI_02
But this could be because I’ve previously installed various USB CDCACM drivers for both of these and perhaps my system is a bit messed up.
I’ll try it on another machine
i’ve not yet tried the STM32GENERIC core, but i’d think the issue isn’t really due to the VID / PID.
the issue as i found when i tried the libmaple f4 core (on steve’s black f4 branch) is that the stm32f4 apparently do not issue a *usb reset* when the reset button is pressed.
this i believe is because on the maple mini, there seem to be some additional circuitry (e.g. a transistor at the usb lines) which triggers the usb reset when the reset button on maple (or baite) mini is pressed
while for the f4 (black vet6) board, usb D+ and D- lines is simply plainly connected straight to the mcu and VBUS and ground are routed to the LDO, no special circuits is used.
when that being the case, pressing reset would not generate a usb reset on the usb bus, what would need to be done is to do a ‘single ended zero’ i.e. pull both D+ and D- (PA11, PA12) low for 10ms, so that the usb host controller would detect that as a usb reset and start re-enumerating the devices (i’d think victor’s first post reflects it)
just 2 cents
———————
oops, my goof, i think there are actually 2 separate issues, one is the vid/pid the other is the usb reset, they are actually independent.
it seemed in linux the vid/pid is ‘less of a problem’ as normally that’s manually edited in a udev config file, and in fact it’d work even without editing any udev files.
but i’d think in windows, it would ask to ‘install a driver’ hence the trouble
You should still go ahead and test to see if it works, my memory may be wrong, or perhaps I didn’t test it right.
About forcing a reset from Windows, that would reset the USB device, but not the MCU, so I don’t think that would help you about having to unplug and replug the board after upload.
@Daniel, I changed 2 things to make it work in F4, and I think should not break anything for other series. I just sent a PR with it:
1.- Hold the line down a bit longer. Roger had tunned that to a very short pulse that was just enough for the F1, but may not be enough for faster MCUs (F4 and others), since the loop doesn’t count actual time, so the faster the MCU the faster it runs. Either we just make it longer for all, or add some code to make it longer the faster the CPU is running.
2.- Leave the USBDP pin in input mode after the pull down, so floating, rather than output high. I don’t think that pin needs to be in output high for any reason. There should be already a 1k5 resitor pulling the line high, so all we need is the pull down, and realease, and the resistor will pull it high.
I did not test the changes separately, if you have time go ahead with it, otherwise I will do as soon as I have time.
the issue as i found when i tried the libmaple f4 core (on steve’s black f4 branch) is that the stm32f4 apparently do not issue a *usb reset* when the reset button is pressed.
i’d try them out, as i’ve been meddling with the boot pins, mainly for sketch uploads, i’m currently using that ‘usbreset’ linux utility to work around the issues
i’d think it is possibly to do with st’s dfu mode which may not do a usb reset after reset button is pressed.
Daniels code seems to use
USB\VID_0483&PID_5740&REV_0200&MI_00
But the Nucleo boards etc use
USB\VID_0483&PID_374B&REV_0100&MI_02
But this could be because I’ve previously installed various USB CDCACM drivers for both of these and perhaps my system is a bit messed up.
I’ll try it on another machine
Yes I have installed that driver.
But when I plug in the Maple Mini, I get 2 :STM32 Virtual ComPort” devices in the Windows drive manager, but both show with an exclamation mark next to them, and in the “Driver Software Installation” popup, both devices show a cross (X) and “No driver found”
I think I’ve probably got my machine so messed up, its confused about what driver it should use.
But I’ll try connecting the Maple mini to another machine and see if that works
I tried it on my wife’s computer (also Windows 7), but it still didnt work, however the result was different
I see 2 different device a HID “USB input” device and also the STM Virtual com
But it doesnt load drivers for either.
I have a laptop with Windows 10 on it for testing, so I will try that later, and I expect it will work, because it sound like this is a USB composite device problem on Windows 7