Woohoo, it realy works) but i failed resetting it by 1200 baud and added simple mapple style reset (if "leaf" trigger recieved) so now it resets and uploads flawlessly using mapple's upload-reset and cubeprog in dfu mode after :)
p.s. tested it with F401

@stas2z
It should be fine to find why it is not reset setting 1200.
Did you try manually without upload scripts?

@stas2z
It should be fine to find why it is not reset setting 1200.
Did you try manually without upload scripts?

yes, ive tried to connect with arduino terminal using 1200 baudrate and also with putty, ive uploaded a simple echo fw to it and it works as expected at 1200 without reset

I've just tested with a Nucleo-F401RE and a USB shield and this work fine...
You set the USB CDC port at 1200 not an HardwareSerial port ?

I've just tested with a Nucleo-F401RE and a USB shield and this work fine...
You set the USB CDC port at 1200 not an HardwareSerial port ?

yes, sure
im using connection to ttyACM0 as my device appeared in dmesg (blackpill F401CC)

Could you try with (several time if needed):
stty -F /dev/ttyACM0 1200

stty -F /dev/ttyACM0 1200

No, its not working for my board

Also i found a problem i got when i tried to implement it by myself, it just reboots without entering a bootloader if any gpio pin initialized, just make pinMode for builtin led and it will stop loading boot.

resolved it by adding following code before remapping and jump to boot

 HAL_RCC_DeInit();
SysTick->CTRL = 0;
SysTick->LOAD = 0;
SysTick->VAL = 0;
__HAL_RCC_SYSCLK_CONFIG(RCC_SYSCLKSOURCE_HSE);
__HAL_RCC_SYSCFG_CLK_ENABLE();

In fact I used the backup register to ensure having original config and no feature configured.
I'm surprise to see HSE in your code as it should be HSI.

In fact I used the backup register to ensure having original config and no feature configured.
I'm surprise to see HSE in your code as it should be HSI.

Ok, it's my fault, HSI is also works and seems like will be better.

But it's not important, cuz SysTick reg values reset do the magic. Reiniting RCC i found by googling, but in my case it can be skipped.

Also ive tried reset by 1200 baud my another F4 board (black F407VE), and still no luck (maple reset works flawlessly), probably problem on my side, will try to find what i did wrong while i appleid this pull request to my local repo copy

Ok. In fact I've made the minimum to work. Resetting systick an RCC could be added, I guess. Maybe also HAL_DeInit as it is init for backup access.

Ok. In fact I've made the minimum to work. Resetting systick an RCC could be added, I guess. Maybe also HAL_DeInit as it is init for backup access.

Anyway, it works already, for me at least :) reset procedure is not so important, also usb is not only way to use it, cuz im going silently update slave devices built with chips with only serial dfu supported, so bootloader reboot requests can be implemented as hwserial commands or gpio pins.

Right, this is not only for USB.

its weird, but 1200 baud reset working under windows for me, without rebuilding
but for linux it's not, even with sudo (any terminal app works fine, but 1200 baudrate reset not)

which Linux OS do you used?

which Linux OS do you used?

mint 19.2 (ubuntu 18.04 based)

Ok, I'v tested on 14.04 and 16.04 anyway this should be the same or a usb driver issue as the speed is not relevant for this kind of device

Ok, I'v tested on 14.04 and 16.04 anyway this should be the same or a usb driver issue as the speed is not relevant for this kind of device

Seems like it was a usb driver glitch, ive rebooted back to linux and everything works as it should, sorry for this inconvinience

OK so now it is fine on Windows and Linux ?

@fpistm yep, both

Good news, Ive successfully rebooted stm32f051c8t6 to bootloader mode using this PR. Will check stm32f030c8t6 a bit later.

i 'tested' this with windows by manually opening the port at 1200 which did in fact kick into the DFU bootloader! then i uploaded. so we need an update to the tool, like linux has, and it should work. @fpistm im not great at bat files but i could try making the change

OK thanks @ladyada for the feedback.
I will update it on monday.

@fpistm This is a very cool feature, I have tested this PR on my Windows10 machine for my 32f411Disco-boards and Blackpill works absolutely fine. this reduces lot of my efforts in uploading code.
It would be great if this feature could be merged.

It would be great if this feature could be merged.

It will be when ready. 😉

There is an issue with the upload.use_1200bps_touch=true

The first time you want to flash a board thanks DFU, there is no com port available, so no port displayed in the menu (port is grayed). The board is manually start in STM32 BOOTLOADER mode thanks the BOOT0 pin and the upload is OK. The 1200 touch does nothing.

@fpistm Could you please tell if this is the only issue with this PR that still remains or there any others?
Thanks.

AFAIK there's still a few other bits of code that work but are too hardcoded or break on some boards, see for example #710 (comment). Also, I think the DFU-descriptor and handling might also need to be slightly more generalized. There might be other issues too.