µTasker Forum > Luminary Micro TM LM3SXXXX
Flash Protection
paulk:
Hi Mark,
I read your post from some time ago regarding your initial experiments with the LM Flash system. You mentioned that you hadn't worked with the protection mechanisms. Has this changed at all? We would like to do everything possible to protect our code, but also need bootloader capability.
A few interesting peices of information from the LM3S6965 datasheets:
--- Quote ---(Table 8-1): With FMPPEn = 1 & FMPREn = 0:
"The block may be written, erased or executed, but not read.
This combination is unlikely to be used."
--- End quote ---
Isn't this exactly the protection level that we want? Does this mean external (JTAG) reads, or internal (program) reads?
Also, you mentioned that the Protection bits are write-once, but the datasheet states:
--- Quote ---"Once the register contents are commited, the FMPREx and FMPPEx registers can be restored to their factory default values by performing the sequence described in the section called “Recovering a "Locked" Device” on page 62. However, the USER_REGx and USER_DBG registers can never be restored to the factory default values."
--- End quote ---
There is a procedure to restore the registers to factory default (described on pp. 62), but I'm not sure if the LM Flash Programmer is capable of this, so I'm wary of trying it on my demo board.
Moreover, from my previous experiences (Atmel, PIC), the protection is set via programming, whereas here it appears that the code (bootloader??) needs to setup these bits.
Can anyone comment on their experiences with the Flash Protection.
mark:
Hi Paul
The situation remains the same. How to protect the chips seems quite clear but afterwards there is no way to un-protect them (at least not with the initial device classes). This means that testing with a demo board effectively makes that board unusable.
As long as there is a boot loader installed which reliably allows code updates this should be able to continue working, but no more debugging.
See the following: http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/474/p/45789/157353.aspx#157353
There are various thread at the Luminary (TI) forum which seem to confirm this.
Of course when you reach the production phase it should be possible to quite easily add and test the mechanism since locking a couple of chips shouldn't be such a problem.
Regards
Mark
paulk:
Mark,
I can't believe that this is an issue, and I basically assumed that flash protection was the norm now. I am familiar with Microchip and Atmel methods of setting protection bits during programming. The internal code still has access to the internal memory, but external debuggers /programmers read the code back as all zeros. Moreover, in those implementations, a full chip erase sets un-protects all the "fuse bits".
This is a MAJOR deal breaker for us if we cannot protect our code efficiently. It is not feasible to permanently disable JTAG, this takes us back 10 years to the days of OTP.
I am going to get in touch with TI immediately regarding this issue....either I'm missing something here or this is a total joke.
:o :o :o :o :o
mark:
Hi Paul
I believe that they didn't make the best choice of protection strategy - maybe newer classes also allow other options now though (I didn't look just yet but you could check - if changing t^the class is an option).
However I think that a boot loader is the practical solution - possibly with encrypted transfer if there is a risk of this being eavesdropped. The "Bare-minimum" method includes this. The web server boot loader would need something added to do the decryption on-the-fly.
Regards
Mark
paulk:
Mark,
I am in shock for lack of a better word. This is simply idiotic, sorry for the frankness.
What is worse, is that it appears that their literature doesn't correlate:
Here is the exact text from a datasheet I have dated 10/13/2009
--- Quote ---Important: These registers can only have bits changed from 1 to 0 by user programming. Once committed, the FMPREx and FMPPEx registers can only be restored to their factory default values only by performing the sequence described in the section called “Recovering a "Locked" Device” on page 62. The mass erase of the main Flash memory array caused by the sequence is performed prior to restoring these registers.
--- End quote ---
Notice the bold text. The latest datasheet (dated 4/4/2010) has replaced this blub with the following:
--- Quote ---Important: These registers can only have bits changed from 1 to 0 by user programming. Once committed, these registers cannot be restored to their factory default values.
--- End quote ---
Wow is all I can say......the boss isn't going to like this......
Navigation
[0] Message Index
[#] Next page
Go to full version