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!

[Danish1]

Posted on July 13, 2018 at 11:13

The code-readout-protection prevents 'outside agents' (by which I mean people using JTAG debuggers or sending commands to the st-supplied bootloader) from reading (or writing to) the built-in FLASH memory.

But it does not prevent your program, running from FLASH, from erasing and reprogramming parts of the FLASH.

Flash memory is divided into pages, and erase can only happen to whole pages. You won't want to erase the page that your code is actually running from.

So a firmware-upgrade process could be to download the new firmware to <somewhere>, verify it is good and if so, erase and reprogram the FLASH. Then jump to and start executing the new firmware.

The <somewhere> wants to be local to your microcontroller. It could be your FLASH memory, but then you have to think what might happen if the download was interrupted part-way, or if (once the download was complete) you realised it wasn't for this particular model of hardware or whatever other reason why you find you have to go back to the old firmware - which you might have just overwritten!

Some stm32 allow the memory to be seen as two 'banks' so you can download/program the new firmware into one bank while running old firmware from the other bank. If your old firmware is happy that the upgrade is complete, you then just need to start afresh running from the other bank.

For other stm32, you could have the <somewhere> as a spare bit of your FLASH memory - your application code must never exceed half the total FLASH for this to work. Some people have thought of using 'position-independent code' so they wouldn't need to copy the new firmware into its 'proper place' before running it, but I do not know if anyone has succeeded in this.

Hope this helps,

Danish

[Huzaifah Limbada]

Posted on July 14, 2018 at 08:01

Hope this helps

Yes off course it is,

As you clarify some things so i can go with that and trying do something that can help me to implement whatever i&39m trying to do, i&39ll let you know if i found something or lost somewhere

Thank you

Ali.Danish