Maple Mini bootloader updater sketch issues and improvements

Discussion about the Maple and other bootloaders
victor_pv
Posts: 1077
Joined: Mon Apr 27, 2015 12:12 pm

Maple Mini bootloader updater sketch issues and improvements

Postby victor_pv » Wed Jan 25, 2017 9:12 pm

I am creating this thread to keep track of some issues we recently found, and seems like are mostly addressed, but in case we find other issues or anyone has doubts.

What we know so far is:
Some people use the bootloader updater sketch to replace the maple bootloader with the stm32duino bootloader version (Bootloader 2.0).
Some Chinese vendors of Maple mini clones are write-protecting the first 16KB of flash.
Due to that, the original bootloader updater was having trouble updating the bootloader.
The solution was to use either STLink or the Serial bootloader tool from STM to remove protection and next to replace the bootloader.
In another thread http://www.stm32duino.com/viewtopic.php?f=28&t=1715&start=10#p22604 I worked with Phil to test some changes in the bootloader updater, and now the sketch is able to remove write protection, and on the next reboot update the bootloader.

There is a possibility that read protection may be enabled. Currently the sketch only check whether it is or not and keeps it the same way, but does not warn the user about it. If the sketch was to clear Read protection, that would cause a mass erase of the flash and the user would need another method to write a bootloader again in the flash.

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

Re: Maple Mini bootloader updater sketch issues and improvements

Postby RogerClark » Thu Jan 26, 2017 8:39 pm

Thanks Victor

Pherhaps we should add this to the wiki as well.

And possibly the FAQ ( I can add to the FAQ by editing my post)

User avatar
ahull
Posts: 1422
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: Maple Mini bootloader updater sketch issues and improvements

Postby ahull » Fri Jan 27, 2017 10:52 am

Would it be worthwhile to add the ability to write protect the bootloader 2 once installed or do you think that is un-necessary and will lead to further confusion.

I can see that protecting the bootloader avoids the obvious problem of a accidentally over-writing it... which would cut down the number of returned devices to the vendor, but for most of us. if we overwrite the bootloader we can probably re-flash it without difficulty.

The exception to this might be those users that rely on the updater sketch.. for whom this might be a useful tweak, or use cases where the device is reprogrammed in the field exclusively with the USB cable and bootloader, and therefore the bootloader is vital.
- Andy Hull -

zmemw16
Posts: 1072
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: Maple Mini bootloader updater sketch issues and improvements

Postby zmemw16 » Fri Jan 27, 2017 12:11 pm

addition of recovery technique ( and also to the wiki ) might help with this post
http://www.stm32duino.com/viewtopic.php?f=27&t=1743#p22900

probably help me as well, well i'd at least know how :(
stephen

victor_pv
Posts: 1077
Joined: Mon Apr 27, 2015 12:12 pm

Re: Maple Mini bootloader updater sketch issues and improvements

Postby victor_pv » Fri Jan 27, 2017 5:53 pm

ahull wrote:Would it be worthwhile to add the ability to write protect the bootloader 2 once installed or do you think that is un-necessary and will lead to further confusion.

I can see that protecting the bootloader avoids the obvious problem of a accidentally over-writing it... which would cut down the number of returned devices to the vendor, but for most of us. if we overwrite the bootloader we can probably re-flash it without difficulty.

The exception to this might be those users that rely on the updater sketch.. for whom this might be a useful tweak, or use cases where the device is reprogrammed in the field exclusively with the USB cable and bootloader, and therefore the bootloader is vital.


It could re-protect the first 8KB after the update. But wouldn't anyone able to wipe the flash without write protection also be able to clear the write protect and wipe it anyway?

User avatar
ahull
Posts: 1422
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: Maple Mini bootloader updater sketch issues and improvements

Postby ahull » Fri Jan 27, 2017 10:57 pm

victor_pv wrote:
ahull wrote:Would it be worthwhile to add the ability to write protect the bootloader 2 once installed or do you think that is un-necessary and will lead to further confusion.

I can see that protecting the bootloader avoids the obvious problem of a accidentally over-writing it... which would cut down the number of returned devices to the vendor, but for most of us. if we overwrite the bootloader we can probably re-flash it without difficulty.

The exception to this might be those users that rely on the updater sketch.. for whom this might be a useful tweak, or use cases where the device is reprogrammed in the field exclusively with the USB cable and bootloader, and therefore the bootloader is vital.


It could re-protect the first 8KB after the update. But wouldn't anyone able to wipe the flash without write protection also be able to clear the write protect and wipe it anyway?


Yes they would, but it would be far harder to accidentally overwrite the bootloader if it was write protected.
- Andy Hull -

ag123
Posts: 317
Joined: Thu Jul 21, 2016 4:24 pm

Re: Maple Mini bootloader updater sketch issues and improvements

Postby ag123 » Tue Apr 11, 2017 5:58 pm

'old' thread, but just putting in my 2 cents, leaving the boot loader flash area unprotected
(1) makes it easier to install a new boot loader - not very common for newbies
(2) allows some boot loading gizmo tricks such as to save some data in the boot loader flash area so that we can change the boot behavior between reboots (e.g. to boot info DFU mode if a particular flag is set http://www.stm32duino.com/viewtopic.php?f=16&t=1549)
or it can even store configuration e.g. you could store the scaling multipliers there so that you could run at a different mhz after reboots (assuming that the sketch is 'too lazy' to setup clocks)
:lol:


Return to “Maple Bootloader”

Who is online

Users browsing this forum: No registered users and 1 guest