help... again with flash security

[jah]

reference mc9s08rd32dwe processor
codewarrioir ide v5.7 & debugger v6.1

in the project S19 file i am asserting m(FFBF) = 0xFC and this should enable security. i start a a debug scession with this build and load it into the target. I notice the targets memory is displayed all zero's and this is an indication security is set. note m(FFB0 - FFBE) are set to 0xFF.

with the code loaded i remove the target from the debugger, do a reset on the target and begin normal target operation. I notice the targets firmware can write to its flash even tho the target is set secure. is this normal????

-i thought i have to use the back door key to do internal writes on a secure part
-the backdoor is one method. is another method to have a blank page of flash, do a blank_ck command (0x05) on the blank page of flash and the security will temporarly be removed?

[LuisF]

That´s it thank you very much!

[LuisF]

Hi

A basic question, how does one set the value of this bits in the compiler, wich directive should I use to set those values in the flash?



thanks

[LuisF]

Hi, can somebody please help me,

My question is about, if one can secure the device from the IDE, so, when the device is programed, the memory will be already secured (because security bits was properly wrote all together with the uC code), or if it has to be accomplished through dedicated code in the uC (code that has to be loaded in RAM in order to write the corresponding bits in flash to secure the device memory)

Any help appreciated

Thanks 

[bigmac]

Hello,

The unprogrammed state, for the flash register that contains the security bits, actually represents a secured state.  If this location remains unprogrammed by the application code, the MCU will automatically remain secure after programming.

To permanently disable security would require that the flash register be explicitly programmed, at the same time as the remainder of the application code.

Regards,

Mac

[jah]

I AM REALLY TRYING TO SECURE THE PART

SECURE:
PREVENT EXTERNAL READ OF FLASH CONTENSE.

-does setting 0xFFBF=0xFC SECURE the part... ONLY... and internal software can still write to its own flash.


thanks!

[peg]

Hi jah,

Yes that is correct!

Regards

Peg

[Alban]

Dear Jah,

You are mixing SECURE and PROTECTED

SECURE means no external read access = no BDM. The CPU has FULL access to all the memory read/write.

PROTECTED means Flash cannot be erased (see Flash Block Protection) by the application or the cable = needs Mass Erase to unlock.

Cheers,

Alban.