Hello, I have hundred of boards where I need to update our custom bootloader which resides in blocks 0/1/2/3/4 (the bootloader "partition" is 5KB). The new bootloader code resides inside the firmware binary, when the firmware boots, it checks if the actual bootloader is up to date, and if not, it erases it and update it.
It works perfectly well in my development board on my desk. But the bootloader update fails on already delivered products. Yesterday I found the problem, the delivered boards have read protection activated in option byte (and it is not activated on my development board) but no write protection on any blocks is activated. But I found in the flash programming manual that when read protection is activated, it automatically activates the write protection on blocks 0/1/2/3 !!!!!
Why do ST implemented this incredible logic !!?? If we decide to activate read protection, why also activate write protection on some block !? There are write protection bits in option byte if we need write protection !!!!
Of course, we can not access the delivered boards to physically update the bootloader with st-link...
We can not remove the read protection configuration by software with the firmware, because it will starts a mass erase and the board will be bricked....
If anybody knows a way to bypass/hack this write protection on block 0/1/2/3 when read protection is activated in option byte, it would be great !!
Regards,
Cyril
