F411 (and F401) bootloaders

[stevestrong]

You do need a bootloader if you don't want to press button for upload.
Check the HID bootloader made by Vassilis Serasidis. It may work for F4x1, too.

[stas2z]

You do need a bootloader if you don't want to press button for upload.
Check the HID bootloader made by Vassilis Serasidis. It may work for F4x1, too.

Not exactly, if core have a way to reset to system bootloader with some kind of trigger

[stevestrong]

That is true, just that it requires non-standard solutions. The mentioned bootloaders do not require any additional hack, they work out of the box with Arduino.

[BennehBoy]

That is true, just that it requires non-standard solutions. The mentioned bootloaders do not require any additional hack, they work out of the box with Arduino.

+1 And HID requires no driver installation which is even nicer - although the supplied code is 407 specific.

[stas2z]

That is true, just that it requires non-standard solutions. The mentioned bootloaders do not require any additional hack, they work out of the box with Arduino.

Oh really? Hid bootloader requires "leaf" string trigger handler inside a core to set backup register magic to handle its boot
Same can be implemented to call system bootloader
Yes, it doesnt require driver, but it waste flash space

[stevestrong]

Yes, the USB bootloaders need USB serial com and a special sequence to trigger the bootloader. This is still preferred by some people (like me) versus button press, specially when you do not have access to a on-board reset button.
I cannot see how this can be implemented to trigger a ROM bootloader without using extra hardware (at least one pin).

The waste of flash space is relative. I never had any application which used more than 80% of the available flash, including the bootloader.
If you need more than that, it is a clear sign to upgrade to a MCU with more flash or other platform (F1 to F4).

But I do not insist to show that this is the only right way. Everyone is free to decide which upload mode better suits his own needs/habits.

[ag123]

F4 seem to have some ways to do a 'soft' boot0. but the trouble is that it seemed a 'usb reset' (single ended zero both d+ d- zero) didn't get send to the host during a reset. i often need to do a 'usbreset' using a utility on linux to get the dfu device recognized. In windows, i think that step is 'scan for new hardware'.
i'm wondering if a direct jump to bootloader address may after all work around it. the other way which needs testing as well, is to do a 'single ended zero' just prior to reset so that the host would enumerate (it seemed we'd need to disable usb between). and then set the 'soft boot0' and nvic_sys_reset()

[stas2z]

oh, you don't need to try to set boot0 any way to reach system bootloader
you just need to jump to system memory if your magic set (or remap 0x0 to it and jump to 0x0) at early start, so it can be implemented at core side (sure with trigger handling, but its already done for all cores)
system memory address can be found in datasheet

it works for most series, ive tried it personally with f0 (usart system bl) and f4

[fpiSTM]

We currently working on this.
https://github.com/stm32duino/Arduino_C ... 2/pull/710

[stas2z]

We currently working on this.
https://github.com/stm32duino/Arduino_C ... 2/pull/710

Sure i know, im just tried to tell about possibility here )