Request support for standard (ST) DFU bootloader upload

[edogaldo]

As per title, it would be useful to allow uploading via the standard ST DFU bootloader (where available).
This could be a good compromise for boards like the Black F407VE which else would require an external tool for initial load..

[ppescher]

I have done this in our OpenTracker fork.

See board/platform configuration files:
https://github.com/RoboTech-srl/opentracker-stm32-core/blob/7fbe63f592d32d0f7aac16dd4e6d4949937ddf4e/boards.txt#L46 (and below)
https://github.com/RoboTech-srl/opentracker-stm32-core/blob/7fbe63f592d32d0f7aac16dd4e6d4949937ddf4e/platform.txt#L150 (and below)

I am using STM32CubeProgrammer in DFU mode. I'm using this on Windows, there is still an issue with the wrong driver being loaded because the new one does not have a digital signature, however it can be manually switched in the Device Manager. I also briefly tested it on linux. Not sure about MacOSX, but I think I got the application path right.

The implementation of the boot call in this commit:
fortebit@61d98b5
Later modified in:
fortebit@83ca6ee

In the first attempt I reserved a variable (boot flag) in the newly created ".noinit" section, otherwise it would have been zero-initialized by the reset handler.
In the second one I moved the checkBoot() call inside the reset handler, before zero-init. I left the ".noinit" section in the modified linker script, even if no longer required.
I thought it was less invasive change to not requiring all the linker scripts to be modified. Even if kind of hacking or hijacking the reset handler (I count on the fact that all reset handlers are equal and have defined the label LoopCopyDataInit).

And the "1200 baud trick" is in my USB CDC attempt:
https://github.com/RoboTech-srl/opentracker-stm32-core/blob/b6f0b430c4049bd801d27be074034f58cb5de6b7/cores/arduino/stm32/usbd_cdc_if.cpp#L171

If you think this is a proper solution I might prepare a pull request.

[edogaldo]

Thanks Paolo, just to let you know that v1.2.0 of the CubeProgrammer provides a signed DFU driver (ref #310). Cheers, E. Il Ven 21 Set 2018, 18:56 Paolo Messina <notifications@github.com> ha scritto:

…

I have done this in our OpenTracker fork. See board/platform configuration files: https://github.com/RoboTech-srl/opentracker-stm32-core/blob/7fbe63f592d32d0f7aac16dd4e6d4949937ddf4e/boards.txt#L46 (and below) https://github.com/RoboTech-srl/opentracker-stm32-core/blob/7fbe63f592d32d0f7aac16dd4e6d4949937ddf4e/platform.txt#L150 (and below) I am using STM32CubeProgrammer in DFU mode. I'm using this on Windows, there is still an issue with the wrong driver being loaded because the new one does not have a digital signature, however it can be manually switched in the Device Manager. I also briefly tested it on linux. Not sure about MacOSX, but I think I got the application path right. The implementation of the boot call in this commit: ***@***.*** <fortebit@61d98b5> Later modified in: ***@***.*** <fortebit@83ca6ee> In the first attempt I reserved a variable (boot flag) in the newly created ".noinit" section, otherwise it would have been zero-initialized by the reset handler. In the second one I moved the checkBoot() call inside the reset handler, before zero-init. I left the ".noinit" section in the modified linker script, even if no longer required. I thought it was less invasive change to not requiring all the linker scripts to be modified. Even if kind of hacking or hijacking the reset handler (I count on the fact that all reset handlers are equal and have defined the label LoopCopyDataInit). And the "1200 baud trick" is in my USB CDC attempt: https://github.com/RoboTech-srl/opentracker-stm32-core/blob/b6f0b430c4049bd801d27be074034f58cb5de6b7/cores/arduino/stm32/usbd_cdc_if.cpp#L171 If you think this is a proper solution I might prepare a pull request. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#330 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATTZblTY3iuLjz9l7IlxTVIj--iTrUxjks5udRomgaJpZM4Wv7Vq> .

[ppescher]

Cool, thanks Edoardo!
It would have been nice to let us know in the same post where we both wrote on the ST Community forum.
This is good news anyway.

[edogaldo]

... :) Il Sab 22 Set 2018, 10:18 Paolo Messina <notifications@github.com> ha scritto:

…

Cool, thanks Edoardo! It would have been nice to let us know in the same post where we both wrote on the ST Community forum. This is good news anyway. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#330 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATTZbvUf6bG1XaRmbn7K5UVYrJkFPqf1ks5udfJCgaJpZM4Wv7Vq> .

[fpistm]

This will be handled thanks #351 thanks @chrissbarr

[ppescher]

It seems that #351 only handles loading a new image via DFU after the bootloader has been activated somehow. I would still need a method to reset the board in boot mode automatically.

Since you have DFU you also have USB and probably that's the main communication interface with a PC anyway, so it makes sense to have some method to update the firmware without any human intervention, just like other arduinos do, and the 1200 baud trick does exactly that.

Given that there is no official CDC yet, maybe I should have a look at #344 and compare it with my implementation (when I find some time).

[fpistm]

Yes, this only handle DFU upload, that's the request.
I agrred, the management of the bootmode is a nice thing to have but I think this could be done in a second step as it depends on CDC.

[chrissbarr]

I think the 1200 baud rate trick is a great idea @ppescher.

Yeah, the dfu-util implementation will only handle the upload part, and needs the board to be in the right state - so a way to reset the board first would be needed. Boards with custom bootloaders should then be able to accept an upload after being reset (assuming they enter DFU mode for a short time, which is I think common behaviour a la Maple). Boards with only the built-in DFU bootloader will still need the BOOT0 pin set accordingly - I don't know that there's an easy way to use that bootloader without the user interacting with the hardware (though it looks like it is possible, but probably hard to generalise to all chips).

I think ideally the reset and upload methods should be separate - it's likely there are upload methods besides DFU that could be used on reset.

[edogaldo]

Just a tip for sw jump to standard STM bootloader: https://stm32f4-discovery.net/2017/04/tutorial-jump-system-memory-software-stm32/
this could work around the need to set boot0=1..

[ppescher]

Hi @chrissbarr
Yes it is definitely possible to call into the ROM bootloader to activate DFU. That's what I did (see my #330 (comment)).

I used a similar approach to what micropython does (see https://github.com/micropython/micropython/blob/338635ccc64204b6f388cfaafca00e120090c622/ports/stm32/modmachine.c#L260) even though I jump to the bootloader after resetting the system (to make sure hardware is in the same state as if you used the BOOT0 pin).