Read/Write protection mechanism.

[Huzaifah Limbada]

Posted on May 31, 2018 at 11:51

Hey all!

I'm working on a project(on STM32L1) where i have to set the Read/Write protection so no one can access my code,

but the actually i want to build such a mechanism where if i want to make a change in code so i can make it by passing a data on the UART or CDC(i.e serially).

Can anyone help me out for this!

Thanks,

Regards.

#access-point #stm32l1 #read-write-protection

[Huzaifah Limbada]

Posted on July 10, 2018 at 08:48

st.mcu

‌ do you have any idea about this??

[Danish1]

Posted on July 11, 2018 at 10:56

Read-protection and write-protection are two different things.

Read-protection (code readout protection CRP) is to prevent someone from reading out the contents of your FLASH memory by way of a debugger - whether over the JTAG interface or through standard commands to the bootloader firmware that ST put into every stm32 microcontroller. It does not block your own program, running from FLASH, from accessing the FLASH memory. (But it does block, for example, a program in RAM downloaded there by JTAG or the bootloader from reading the FLASH).

CRP level 0 means no protection.

CRP level 1 means the flash cannot be read or written by JTAG or bootloader, but you can go back to level 0 with a full erasure of the FLASH memory.

CRP level 2 means the 

flash cannot be read or written by JTAG or bootloader, and also you cannot change the CRP level any more.

But even in level 1 and level 2, your own program already in FLASH can still access the FLASH.

Write-protection is to prevent your own code, running from FLASH, from accidentally overwriting/erasing the FLASH.

When might that happen? Probably only in a horrible crash.

But when you consciously and deliberately do wish to erase/write the FLASH e.g. to upgrade the firmware, you can turn off the write-protection, make those changes you want, and turn it back on.

Of course protection this only reduces the risk of accidental overwriting, because the horrible crash just might turn off the write-protection prior to doing writes/erases to the FLASH. But it does make such things less likely.

The precise sequence-of-events for updating firmware are complicated by the fact that the old firmware that you're currently running probably wants to occupy the same area of memory as the new firmware you wish to install. And the very fact that you want to upgrade the old firmware might imply that there is a bug in it. So some people separate off the 'firmware upgrade' code into their own bootloader, which never (or hardly ever) changes.

Please could you explain what help you want.

You do need to describe your current level of understanding and what you have done so far.

And you do need to study the appropriate sections of the reference manual for your stm32, as well as application notes on bootloaders and code-readout-protection

Danish

[Huzaifah Limbada]

Posted on July 12, 2018 at 07:26

Thank you so much

Ali.Danish

for your reply, this really clear some doubts,

i have one doubts regarding Write protection, like when we enable it we can read our code using utility (as per my understanding from STM documents) is it??

If this is correct so it won&39t help me out for my problem because i need a solution to prevent my code from read and write too and when i want to update new firmware so i can easily update it without FULL ERASE if you have any solution for this please help me so i can move forward in that way.

Thanks in advance!

[Huzaifah Limbada]

Posted on July 12, 2018 at 11:01

For that problem i'm already created one thread please check n reply if you found something helpful,

https://community.st.com/0D50X00009XkWW5SAN

Thanks!