Enabling Bootloaders

[BennehBoy]

I'm porting some work from Roger's core which enables maple BL, rogers BL2, and HID BL2+

I have the core code sorted (easy part) to recognise the leaf magic word and magic numbers.

I'm concentrating on HID BL for this core because the v3.0 only takes up 2K of flash for F1 so is much better suited than Roger's BL.

But what I need now is to be able to set a definition within the upload part of boards.txt

Eg

• F4 I need to pass -DVECT_TAB_OFFSET=0x4000 -DHIDBL_F4
• F1 I need to pass -DVECT_TAB_OFFSET=0x1000 -DHIDBL_F1

The intention is then to parse within the linker script to set things up accordingly.

Is this doable, or is there a way around it?

[fpistm]

I think you should add new menu entry to select or not bootloader. Then option can be add to extra flag.about linker with the ld preprocessing it is now simple to update the ldscript.

[BennehBoy]

OK will give that a try.

[BennehBoy]

I'm struggling to figure out how to glue my menu build options into platform.txt - when selected they don't appear in any of the build output....

I added this in boards.txt:

GenF4.menu.boot.none=None
GenF4.menu.boot.HIDBL_F4=HID Bootloader 2.0
GenF4.menu.boot.HIDBL_F4.build.enable_boot={build.boot_flags} -DVECT_TAB_OFFSET=0x4000 -DHIDBL_F4

I tried adding an boot_flags section to platform.txt (and a few other things) and all this results in is a boot=HIDBL_F4 tagged into the Arduino compiler line...

Help! 😃

[BennehBoy]

OK, figured it out....

GenF4.menu.boot.none=None
GenF4.menu.boot.HIDBL_F4=HID Bootloader 2.0
GenF4.menu.boot.HIDBL_F4.build.extra_flags=-D{build.product_line} {build.enable_usb} {build.xSerial} -DVECT_TAB_OFFSET=0x4000 -DHIDBL_F4

So I can now upload via hid_flash.exe and my code executes, but after the next restart it's just back into the bootloader perpetually :( (not sure if this is a BL issue, or what - will try STM32GENERIC and see what happens).

[fpistm]

You have to declare the menu on top of board.txt:

Arduino_Core_STM32/boards.txt

Line 8 in 86f4f82

menu.opt=Optimize

ex:
menu.boot=Bootloader

Then you can add in extra_flags
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/boards.txt#L566
Ex:
GenF4.build.extra_flags=-D{build.product_line} {build.enable_usb} {build.xSerial} {build.boot}

Finally, declare the menu either for all GenF4:

GenF4.menu.boot.none=None
GenF4.menu.boot.HIDBL_F4=HID Bootloader 2.0
GenF4.menu.boot.HIDBL_F4.build.extra_flags=-DVECT_TAB_OFFSET=0x4000 -DHIDBL_F4

nor per boards declaration:

GenF4.menu.pnum.BLACK_F407VE.build.boot.none=None
GenF4.menu.pnum.BLACK_F407VE.build.boot.HIDBL_F4=HID Bootloader 2.0
GenF4.menu.pnum.BLACK_F407VE.build.boot.HIDBL_F4.build.extra_flags=-DVECT_TAB_OFFSET=0x4000 -DHIDBL_F4

I did it on the fly, I did not test but this is the way to do that.

[BennehBoy]

OK I have a work in progress here -> https://github.com/BennehBoy/Arduino_Core_STM32/tree/HIDBootLoader

F1 works fine
F4 there looks to be an issue with the actual bootloader

The glue from boards.txt etc probably needs cleaning up.

[BennehBoy]

Confirmed that F4 HID BL has the same issue against Roger's core - I need to check this is not a problem with my personal build...

[BennehBoy]

...used supplied .hex and same issue

[BennehBoy]

UPDATE, pressing the reset button on the board executes the user sketch - have asked the bootloader author if this is by design.

[BennehBoy]

PR submitted -> #415

[BennehBoy]

DIYMROE tested and working. (and what a pain that was, the USB connector snapped off so I had to resolder it... I hate working with SMT parts).

@fpistm don't merge this yet - Vassilli just updated hid_flash.exe to force V3.0 firmware usage, I need to update the menu options accordingly and submit the new flash tool into the tools repo.

Is it worth me supplying known good bootloader bin's for each of the tested boards - will save people some trouble building there own (the 2 supplied in the core HID bootloader repo don't cover all the requirements).

PS the reason I was having to hit reset was that the supplied .hex's were expecting a different BOOT1 pin - which was obviously just floating.

PPS Tested so far:

Bluepill
Blackpill
Black407VET6
Black407ZET6
DIYMROE_F407VGT

[fpistm]

Don't worry. I always perform several tests before merge. Moreover, I think, will release 1.5.0 before merge this, this is safer I guess.

[BennehBoy]

DFU bootloader support added

Works with the Maple original bootloader & Maple Bootloader 2.0

Tested & working on Maple Mini & BluePill

[crackwitz]

I'm on Win7 x64. I've just grabbed fresh Arduino 1.8.8 and Boards Manager URL from the wiki... in this configuration, Arduino won't show me any way to upload to a Maple Mini using the bootloader (2.0) anymore, only STlink, Serial, BMP. Maple's presenting as a COM port, yet "Serial" fails. This used to work just a few months ago. What changed?

Failed to init device.
stm32flash STM32duino_0.5.1
Using Parser : Raw BINARY
Interface serial_w32: 115200 8E1
An error occurred while uploading the sketch

[BennehBoy]

There's no bootloader support via the boardmanager version, you have to use the github version and apply PR #415.

Regarding the ROM based Serial bootloader (your post above shows output from trying to use it), I doubt you'll be able to activiate it easily on a maple mini, it does not have BOOT0 or BOOT1 jumpers.

See this wiki page -> http://wiki.stm32duino.com/index.php?title=Bootloader

I suspect what was working a few months ago was a different core, ie Roger's leaf labs based one.

[crackwitz]

Thanks, I'll have to do it the less convenient way then.

No, I wasn't meaning to use the ROM bootloader, that was just one of the vaguely labeled options I tried. This is all about using USB (CDC?) for firmware transfer, the thing that should always work.

Is this functionality planned to show up in the boardmanager version? I did not see this from the wiki.

[BennehBoy]

CDC isn't used for firmware tarnsfer, it's just used as a mechanism to trigger it. What actually happens is that a 'magic word' is sent across CDC, the CDC code on the board then jumps execution into the DFU bootloader, dfu-util then can upload the via DFU. For all intents and purposes it looks that way to the end user because they must specify which COM port to use in the IDE. Anyhow, if you install the core from github (there's a link on the repo front page showing how to do so), then apply the PR, you'll have DFU bootloader available for Maple Mini - be sure to choose the 0x5000 variant if it's the original bootloader as shipped.

…

On Wed, Mar 6, 2019 at 11:30 AM Christoph Rackwitz ***@***.***> wrote: Thanks, I'll have to do it the less convenient way then. No, I wasn't meaning to use the ROM bootloader, that was just one of the vaguely labeled options I tried. This is all about using USB (CDC?) for firmware transfer, the thing that should always work. Is this functionality planned to show up in the boardmanager version? I did not see this from the wiki. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#411 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AX0eXlMjufLTlZro2FR70dzWDaLOBcx1ks5vT6bUgaJpZM4aJpfp> .

[BennehBoy]

I noticed the 'Help Wanted' label, what needs doing @fpistm - the PR just needs converting to use the STM32cubeprogrammer now right, I had thought you were looking at that? 😄

[fpistm]

Right, i've just set label. 😉