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 19, 2011 at 01:23

Try power cycling the board after turning off ROP and mass erasing.

[wadi]

Posted on December 19, 2011 at 09:46

But programming and mass erasing is executed inside my program - upgrade function is executed from RAM.

I wonder what is the difference beetwen flash programming with Read-Out Protection ON and OFF. I my opinion, when I execute mass erase command and next I programm data to flash, Read-Out Protection setting shouldnt be important it that situation.

[Tesla DeLorean]

Posted on December 19, 2011 at 11:20

One thing I think you'll discover about ROP is that configuration states are latched at reset and not dependent of the flash array subsequently.

[wadi]

Posted on December 19, 2011 at 11:57

I have found in documentation potential problem: when RDP jest activated, first pages of the flash are automatically write protected, and thats why upgrade stops.

How I have to check if it be possible to deactivate this write protection....

[emalund]

Posted on December 19, 2011 at 19:46

it would not make sense if you could do a partial erase on a protected chip.  If you could the protection would be worthless (you could earase a small piece and insert code to read out the remainder to e.g. the UART.

thus it should be (and probably is) IF protected only full erase possible

Erik

Erik

[wadi]

Posted on December 19, 2011 at 21:23

But I do execute full erase command...

I dont understand why full erase command automatically protect first sectors of flash ??

And why after removing protection (and automatically erasing device) CPU need to be POWERED ON to reload RDP bits I dont see any sence of such behaviour, and it makes difficult to make full flash upgrade...

Is it possible to remove this protection of thr first sectors without removing RDP?

[Tesla DeLorean]

Posted on December 20, 2011 at 00:00

I think you'll find ROP purposefully obtuse, it is designed to make things difficult and constraining. You will need to invest your own time determining if this is more of a hindrance than a benefit.

The bottom line is ROP is not a die level protection, and someone with a moderately equipped lab could extract the code. Providing an update opens another vector of attack, one that does not require physically compromising the device.

[wadi]

Posted on December 20, 2011 at 01:17

Thnaks for reply.

Ok, maybe I dont understand something.

So have You got any suggestions how to remotly fully upgrade program in flash without using programmer when RDP is active ? Mass erase function cannot be used obsviously because first sectors of flash will cannot be written after that. Puting bootloader into this space isnt good idea, because bootloader will be not upgradable remotly anymore.

Is it possible to leave this space (2 first sectors of flash) empty and unused, and force processor to boot from from fully upgradables pages after that region (reset vector should point to third sector) ?

(I use STM32F105 and Ride7 environment)

with best regards,

[emalund]

Posted on December 20, 2011 at 15:19

your request is totally meaningless.  If you provide code for field updates, it makes no sense to read protect the memory. It is far easier to look at the file you send than to try and xtrac t from the chip.

Erik

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