USART BOOTLOADER launched from user application & flash has readout protection set, how can USART BOOTLOADER load new code to flash?

[PMoor.1]

It seems unprotected flash can be programmed and then protected using user application launched native STM32 USART BOOTLOADER, but protected flash can only be cleared, but not reprogrammed without also having access to the boot pin configuration. (Am I missing some something?)

Using the USART BOOTLOADER protocol Readout Unprotect (command 0x92), the STM32 erases the flash and then resets the STM32, but there is now no user code to launch bootloader again to load new code into the now unprotected user flash.

I happen to be using a STM32F100V8T6, but I think this issue is generic to the STM32 family.

[TDK]

You're not missing anything. You need a way to get the chip back into bootloader mode.

> I happen to be using a STM32F100V8T6, but I think this issue is generic to the STM32 family.

Some chips launch the bootloader if the flash is empty.

[Tesla DeLorean]

I think it generally comes down to protecting the integrity and security of the product, and that your own bootloader be secure, and bug free, and remain for the life of the product.

[PMoor.1]

The native bootloader seems to be good enough for many applicaitons when launched from the user application code with flash access protected. (Given enough enough investment, most patterns in flash could be cloned, so one's IP security should not be solely dependent on restricted access to a single memory array.)

[PMoor.1]

For this case, having the product default to launching the bootloader if the flash was blank would make it simple, but perhaps not desirable. The risk of a "dead brick" in the field should be avoided as much as possible, but being able to remotely reconfigure a device from its published default state leaves the door wide open for a 3rd party to repurpose devices in the field, which would be bad for companies involved, and perhaps society in general, depending on the scope and use of the device.

The issue (as I see it) is not having a path back to the bootloader once the flash mass erase and protection bit clearing has occurred specifically from the native bootloader. Something as simple in the boot logic as "if the flash is blank AND the last reset event was triggered by software, then launch the bootloader" could work, but it seems this part is not made that way.