cancel
Showing results for 
Search instead for 
Did you mean: 

enable readout protection and using IAP a problem?

hg-chen
Associate II
Posted on December 08, 2008 at 10:39

enable readout protection and using IAP a problem?

6 REPLIES 6
jgoril
Associate II
Posted on May 17, 2011 at 12:19

There is no problem while using JTAG programming. The unprotection procedure is depicted in flash programming manual (PM0042), chapter 2.4.1. Since there is POR reset necessary, I'm not sure about using any kind of user IAP code, since after reset the flash is empty and RAM content is random. Until now, I have no experience with system boot mode...

hg-chen
Associate II
Posted on May 17, 2011 at 12:19

using IAP and enable readout protection is not possible?

cause when readout protection is enabled, if IAP needed,

it will do mass erase ,including erasing the IAP code, right?

any idea about using IAP and readout protection?

sjo
Associate II
Posted on May 17, 2011 at 12:19

The readout protection does not need removing for IAP.

Also pages 0-3 are write protected when readout protection is on - bootloader protection.

The flash is protected from debug mode access only.

Refer to the stm32 flash programming manual for more details.

Regards

sjo

paulsmitton9
Associate III
Posted on May 17, 2011 at 12:19

Quote:

Also pages 0-3 are write protected when readout protection is on - bootloader protection.

Thanks for the tip! This is extremely frustrating though.

I was wondering why my (

to flash correctly with readout protection on.

This could cost me three pages of flash that I can't afford.

And it seems pointless since anyone could write protect the

first four pages of flash if they wanted to anyway.

I'm guessing nobody knows of a work-around? I tried erasing

the option bytes, but that didn't seem to help.

Paul.

16-32micros
Associate III
Posted on May 17, 2011 at 12:19

Hi,

Once RDP is enabled :

1) Main Flash memory read access is not allowed except for the user code (when booting from main Flash memory itself with the debug mode not active).

2) Pages 0-3 (for low- and medium-density devices), or pages 0-1 (for high-density devices) are automatically write-protected. The rest of the memory can be programmed by the code executed from the main Flash memory (for IAP, constant storage, etc.), but it is protected against write/erase (but not against mass erase) in debug mode or when booting from the embedded SRAM.

3) All features linked to loading code into and executing code from the embedded SRAM are still active (JTAG/SWD and boot from embedded SRAM) and this can be used to disable the read protection. When the read protection option byte is altered to a memory-unprotect value, a mass erase is performed.

Protecting The First Pages of flash: is a important feature that protects your own IAP ( programming code ) to be erased or to be overwritten even after a PC ( program Counter) Loss or a wrong procedure.

Hope this helps you.

Cheers,

STOne-32.

paulsmitton9
Associate III
Posted on May 17, 2011 at 12:19

Thanks STOne,

It seems a shame that it isn't left up to the user to enable the write protection as per usual. I'd be prepared to take my chances that normal flash locking would protect it. As I mentioned, my firmware upgrade code is under 1k, so it's effectively wasting 3kb of flash (since I need all of the remaining flash for upgradable firmware, and flash data).

Incidently, to soften the blow, I'm going to try forcing usb_mem.c and usb_regs.c into the other 3kb since they don't seem to call any other functions or access any global variables. Hence, they should be re-usable by new firmware, so long as I don't upgrade my compiler (which could change their addresses).