Auto-enter persistent-bootloader mode on upload

STM32duino bootloader aka Maple bootloader
Post Reply
devan
Posts: 50
Joined: Sat May 14, 2016 1:45 am

Auto-enter persistent-bootloader mode on upload

Post by devan » Thu Aug 11, 2016 2:49 am

I've made some tweaks to the STM32duino bootloader and IDE so that when you upload code, boards with the updated bootloader will automatically go into persistent bootloader mode before it uploads the code.

The gory details:
On the IDE side, I've added a new "STM32duino Bootloader (RTC)" upload option that changes reset behavior when the 1eaf sequence is sent. Before it resets so that the bootloader can run, it writes a magic value to one of the RTC backup registers, which persists across reset while the board is still powered.

On the bootloader side, I've modified it so that it checks for that magic value in the backup registers. If it detects the magic value, it clears that register and enters the persistent bootloader mode. This ensures that when the IDE resets the board to upload code, it will stay in the bootloader until it's detected, instead of having a race to see whether the IDE can query the DFU device after it's enumerated but before it exits.

The IDE and bootloader branches (with updated binaries for STM32F1 targets) are up on GitHub:
https://github.com/devanlai/STM32duino- ... bootloader
https://github.com/devanlai/Arduino_STM ... bootloader

I've successfully tested it with a bluepill board (generic_boot20_pc13.bin) on Arduino 1.6.9 on Linux, though none of these changes are OS-specific anyways.

User avatar
RogerClark
Posts: 7447
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Auto-enter persistent-bootloader mode on upload

Post by RogerClark » Thu Aug 11, 2016 5:41 am

Sounds like an excellent idea.

I will take a look at the weekend when I get some free time.

ozolive
Posts: 6
Joined: Thu Oct 06, 2016 11:09 am

Re: Auto-enter persistent-bootloader mode on upload

Post by ozolive » Thu Oct 20, 2016 6:20 am

Thanks devan

I have tested your patches (on a bluepill STM32f1c8t6) and found them working good and very usefull.

One small drawback is that you have to be conscious that as the generated sketch have to contain a hook, the compiled code will depends on the upload method "STM32duino bootloader (RTC)" selected on the IDE. But, on the first time i uploaded i did not have such a sketch included so i needed to use the "button" or resistor to enter perpetual bootloader mode, in a right timing.

Afterwards it works really good, allowing many code uploads without to touch the circuit. I find this so much conveniant that i believe it is a good candidate for inclusion.

I also believe that next step should be to implement a way for the bootloader to know that a hooked sketched is present, so that it can boots directly into the sketch without wait time, and without going to dfu. Also maybe it should default to dfu mode when no hooked sketch is present. Then i feel it could become the "default" upload method, user-friendly in an arduino way..

What do you think ?

devan
Posts: 50
Joined: Sat May 14, 2016 1:45 am

Re: Auto-enter persistent-bootloader mode on upload

Post by devan » Fri Oct 21, 2016 2:36 am

Hi ozolive,

I'm glad to hear that the changes are useful for you.

I like the idea of reducing the wait time at boot. If we only enter DFU on request (either from an IDE reset or from pressing a button during boot), then the default DFU phase after reset can be skipped. The boot wait could be reduced to a few seconds to allow the user to manually trigger persistent-bootloader mode from a button.

Unfortunately, since the bluepill doesn't come with a button, that manual intervention could be very inconvenient on the occasions when it is necessary (for example, when using the wrong upload method).

There are probably people who wouldn't mind trading a minute of fumbling with a resistor once a month in exchange for shaving 3-4 seconds off of every reset cycle, so it would be a nice option, but probably not the default bootloader to steer beginners towards.

User avatar
RogerClark
Posts: 7447
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Auto-enter persistent-bootloader mode on upload

Post by RogerClark » Fri Nov 11, 2016 7:23 am

I think this is a good idea.

Apart from people who use the BKP register for their own use (hardly anyone I think, but I'll need to check with @ahull for his sunrise timer)

Then we could add the BKP code into the core now, as it won't do any harm as far as I can tell

I presume the bootloader also partially speeds the whole process, because at the moment I think the bootloader waits for upload for a few secs, and presumably starts and finishes the DFU upload, but then the bootloader is reset by DFU util, and then waits around again before jumping to user code.

I'm not sure why the bootloader does not jump straight to the user code after the DFU upload is finished.
I've no idea about DFU, but it seems odd that the DFU protocol would not have some flag etc to indicate when the upload was complete.

I'd like to fix this if possible, but I have a feeling that LeafLabs may have needed to reset the bootloader for some reason, and I'm not sure why that was, because we have no way to contact them :-(

devan
Posts: 50
Joined: Sat May 14, 2016 1:45 am

Re: Auto-enter persistent-bootloader mode on upload

Post by devan » Sat Nov 12, 2016 9:13 pm

RogerClark wrote: I presume the bootloader also partially speeds the whole process, because at the moment I think the bootloader waits for upload for a few secs, and presumably starts and finishes the DFU upload, but then the bootloader is reset by DFU util, and then waits around again before jumping to user code.

I'm not sure why the bootloader does not jump straight to the user code after the DFU upload is finished.
I've no idea about DFU, but it seems odd that the DFU protocol would not have some flag etc to indicate when the upload was complete.

I'd like to fix this if possible, but I have a feeling that LeafLabs may have needed to reset the bootloader for some reason, and I'm not sure why that was, because we have no way to contact them :-(
The DFU protocol does provide a way for dfu-util to know when the upload is finished, but it's still up to dfu-util to trigger the USB reset.
Jumping straight to the user code is a possibility, though you would have to make sure that everything is reset correctly so that you don't get different results launching the code immediately after an upload vs after a full reset.

We could use a different value in the BKP register to indicate a fast boot mode that skips DFU. This would be set after a successful upload so that the first reset after the upload would be fast.

User avatar
RogerClark
Posts: 7447
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Auto-enter persistent-bootloader mode on upload

Post by RogerClark » Sat Nov 12, 2016 9:25 pm

devan wrote:
The DFU protocol does provide a way for dfu-util to know when the upload is finished, but it's still up to dfu-util to trigger the USB reset.
Jumping straight to the user code is a possibility, though you would have to make sure that everything is reset correctly so that you don't get different results launching the code immediately after an upload vs after a full reset.
That explains why the DFU-util on the PC has to send reset to the bootloader.

I'm not sure if we need a BKP flag for this or not.

We could clear a variable during the init of the bootloader e.g. UPLOAD_IN_PROGRES, then set this flag when uploading (actually we need to store the upload address as it saves checking for it when we jump to the user code)
Then if the bootloader gets a reset event, it could check this flash (probably just LAST_UPLOAD_ADDRESS), it could jump to that address.

If the board was actually reset manually or power cycled that variable would be cleared, so if the bootloader somehow got a reset command while waiting for DFU upload, it would not jump to the user code as LAST_UPLOAD_ADDRESS would be 0x00000000

Or we could use BKP, but we may be able to clear all the registers and flags etc prior to jumping to the user code, so that a full reset is not needed

However I'm not sure why Leaflabs didnt originally do this, as it seems the logical thing to do, and they are clever guys

User avatar
RogerClark
Posts: 7447
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Auto-enter persistent-bootloader mode on upload

Post by RogerClark » Sun Nov 13, 2016 12:16 am

I tried just jumping to the user code after DFU upload, but even if I turned off interrupts and powered down the USB it didn't work (perhaps I should not have powered down the USB)

So using BKP looked easier, so I had a quick look at doing that way, but I did something wrong at the moment and USB didnt work in the sketch

User avatar
RogerClark
Posts: 7447
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Auto-enter persistent-bootloader mode on upload

Post by RogerClark » Sun Nov 13, 2016 9:13 am

Devan

I finally got the improved bootloader to work, and its much faster

I merged in your code by hand, but additionally put some code to set a different value as soon as the bootloader gets the DFU upload command.

So that when DFU resets the bootloader it also checks for this new value and skips all the code flashing the LED etc, and just runs the code that checks whether a sketch is in flash etc

Of course it would be even better if I add your code into the core to set the BKP register prior to resetting the MCU for upload, as we could shorten the upload wait period for the cold reset etc, as it would not be so critical that we left a long time delay.

At the moment I'm trying to work out if I can just rebuild all the bootloader binaries, or if there is some drawback to my change that I've not considered.

Post Reply