Posted on March 11, 2013 at 15:55I loaded data into ROM page 11. I then changed from 1’s to 0’s from my running code. So far so good.
Now I want to prevent my code from being read via a debugger.
I can set FLASH_OPTCR bits 8..15 to 0xBB in my code. If I read the RM correctly this protects my code from being read and manipulated by a debugger. I am using ST-LINK to load my code. Have I have missed some strange extra option that automatically sets FLASH_OPTCR for code protect when I load my code?
Yet, if I understand correctly, this setting goes away on reset. That’s useless for protecting my code from debugger inspection.
I know about the option bytes location 0x1FFFC000. Using IAR tools and ST-LINK its default value appears as 0x5500AAFF. I can change that with my code to 0x5500BBFF (or 0x550022FF if I can’t change a 0 to a 1.) I assume this changes the default value of FLASH_OPTCR.
But will doing that prevent me from loading code with the debugger? I would hope that I would be limited to erasing the entire part before I can do anything else with the debugger. I only have 2 F4 discovery boards and I would hate to have to buy another.
My plan is to have the option bytes set to AA, level 0, read protection not active. Load code that way with ST-LINK. Then run the code using an external source to download the final updates to ROM page 11. After that I would change the option bytes for RAM and ROM read protection from debuggers and other nefarious attempts to discover what is going on inside the microcontroller.
Side issue:
About how long is the processor suspended during a single word ROM write? I am running with 3.3V.
I ask because I will be unable to interrupt to transfer external data during the time the ROM is dedicated to the update process. If this time is over 200 microseconds I will have to suspend 38K baud RS-232 for the duration. If ROM write time never exceeds 100 microseconds I can ignore the temporary break in execution without worry.
