Problem with programming protected device

[wadi]

Posted on December 19, 2011 at 00:07

Hello. I have problem with upgrading program in my own bootloader.

When procesor is not read-out protected, everything is going ok (verify says ok). Problem occurs when I set <Read-Out Protection> in RFlasher7 (using Ride7 and RLink programmer). Internal program is erased ok (mass erase) but it stops after first full word programming command (flash controller returns FLASH_FLAG_BANK1_WRPRTERR). In Option Bytes non of the WRP0-WRP3 is set (all have 0xFF). Where is a problem ? And one more guestion: Are option bytes erased during mass erase command ? Should I set up readOutProtection again after mass erase command ?

[Tesla DeLorean]

Posted on December 20, 2011 at 22:19

Have you tried to reset/cycle the device after the mass erase (Disable ROP), because I'm pretty sure it gets you back to a usable device

Do you have control of the BOOTx pins? You can definitely read the entire flash array with ROP enabled, both from code running in FLASH/ROM, and code copied to RAM by a loader running in a protected device (inheritance). You can definitely put code in the reset path to call anywhere in RAM, FLASH or ROM, and it's certainly possible to code a boot loader that is small, correct and robust enough that it won't need updating, ever. If you can't make one that is simple enough, then consider a staged boot, with a secondary loader before the application. You should be able to do partial erases and writes on the part. The scheme generally assumes that the part, or at least the loader is OTP'd in the factory. And that you can nuke the part to a blank/reusable state with a couple of manual steps. Can you reprogram the part completly in the field, perhaps, I can see ways of achieving this, not as robustly as I might like, but it would require more time/effort than I'm willing to invest, especially for someone elses problem. The really killer for me is that none of this protects the design against anyone reasonably competent/equipped.

[wadi]

Posted on December 20, 2011 at 22:47

Not quite Erik. First of all code is fully encrypted and while sending to procesor and external backup flash. And is decrypted on the fly while rewriting to internal flash.

And I have some more secure levels to accept only prepared special code. Looking into transmitted code or even into external flash is useless. So I need RDP to be set

[wadi]

Posted on December 21, 2011 at 23:03

Do you have control of the BOOTx pins?

I cannot control BOOTx pins because upgrade is made remotly without physical access to device. Removing RDP on the table with external programmer isnt a problem.You can definitely read the entire flash array with ROP enabled, both from code running in FLASH/ROM, and code copied to RAM by a loader running in a protected device (inheritance). You can definitely put code in the reset path to call anywhere in RAM, FLASH or ROM, and it's certainly possible to code a boot loader that is small, correct and robust enough that it won't need updating, ever. If you can't make one that is simple enough, then consider a staged boot, with a secondary loader before the application. You should be able to do partial erases and writes on the part. Well, I have already understood that mass erase command during internal upgrade is completly useless when RDP is active. Partial erase must used when upgrading software, and unfortunalety some code cannot be erased at all... it's certainly possible to code a. boot loader that is small, correct and robust enough that it won't need updating, ever well, such things as roboust application unfortunatelly not often happens, additionally my experience says then it isnt safe to assume this in mass production... thanks

[colecago]

Posted on December 21, 2011 at 23:52

If you use ST-Link and the command line utility with the hex file Ride makes, you can have it change the option bytes to remove read protect, then mass erase, then program, verify, and re-set the option bytes to be read only.  I'm using the STM32VLDISCOVERY as my ST-Link board, they are like $12.  

You could write a program that takes an encrypted hex file, decrpyts it to a temp file, programs that temp file using ST-Link command line, then erases the temp file and no one would be the wiser.

[Tesla DeLorean]

Posted on January 02, 2012 at 16:55

''.. it's certainly possible to code a. boot loader that is small, correct and robust enough that it won't need updating, ever''

well, such things as robust application unfortunately not often happens, additionally my experience says then it isn't safe to assume this in mass production... Like I said, a small boot loader, when you have to commit something to a ROM Mask you don't get to change it, and the device might get into millions of products.