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 ... =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.

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.

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?

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.

'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)