Page 1 of 1

Maple Mini bootloader updater sketch issues and improvements

Posted: Wed Jan 25, 2017 9:12 pm
by victor_pv
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.

Re: Maple Mini bootloader updater sketch issues and improvements

Posted: Thu Jan 26, 2017 8:39 pm
by RogerClark
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)

Re: Maple Mini bootloader updater sketch issues and improvements

Posted: Fri Jan 27, 2017 10:52 am
by ahull
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.

Re: Maple Mini bootloader updater sketch issues and improvements

Posted: Fri Jan 27, 2017 12:11 pm
by zmemw16
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

Re: Maple Mini bootloader updater sketch issues and improvements

Posted: Fri Jan 27, 2017 5:53 pm
by victor_pv
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?

Re: Maple Mini bootloader updater sketch issues and improvements

Posted: Fri Jan 27, 2017 10:57 pm
by ahull
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.