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:

(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."

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:

"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."

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.

 

[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

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.

Notice the bold text.  The latest datasheet (dated 4/4/2010) has replaced this blub with the following:

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.

Wow is all I can say......the boss isn't going to like this......

[paulk]

Here is a reply I got from our TI rep:

"Yeah, I would agree that the datasheet section 8.3.2 gives the impression that you cannot clear the flash protection once you commit it.  Well, that is not the case.  Refer the customer to datasheet section 5.2.4.1 (April 4, 2010 datasheet), "Recovering a Locked device".  By performing the proper JTAG pin toggling sequence, you can trigger a mass-erase of the device, which will clear the protection bits.  You can then get back into the device."

Now I need to figure out how to generate the "proper JTAG pin toggling sequence"

[mhoneywill]

The luminary Micro LM Flash Programmer will do this for you. Look under the "Other utilities" Tab at the "Debug Port Unlock" section. The following is from the help file.

Cheers

Martin

Debug Port Unlock Utility
The Debug Port Unlock utility allows the JTAG/SWD debug pins to be unlocked if you configure the pins as GPIOs or there is some other issue that causes the device to lock up, such as configuring to system clock out of specification.  This utility has some restrictions for the Sandstorm class of microcontrollers. There are three options for the Debug Port Unlock utility:

·         Sandstorm Class Revision C

·         Fury and DustDevil Classes

·         Tempest Class

Sandstorm Class Revision C
When you select this option, the SWD pins are used to communicate to the microcontroller and perform a mass erase of the internal flash. Since the SWD pins are used, the utility with this option does not work if pins PC0 or PC1 are configured as GPIOs.

Fury and DustDevil Classes
When you select this option, the utility unlocks the JTAG/SWD debug pins for all revisions of the Fury and DustDevil classes of microcontrollers by performing a mass erase of the internal flash using the JTAG/SWD recovery sequence.  This utility works regardless of which pins are configured as GPIOs.

Tempest Class
When you select this option, the utility unlocks the JTAG/SWD debug pins for all revisions of the Tempest classes of microcontrollers by performing a mass erase of the internal flash using the JTAG/SWD recovery sequence.  This utility works regardless of which pins are configured as GPIOs.

[paulk]

Hi, thanks for the reply.  Sorry if I'm thick, but I'm still a little confused.  Here is what I want to do:

1) Protect our code from competitors doing a read-back of the device
2) Protect the bootloader from getting overwritten (by firmware)
3) Allow the firmware to be written by the bootloader
4) Allow the firmware to read its own flash area, as parameters and user data are stored there
5) Allow the device to be "reset" such that the device can be wiped / re-programmed via JTAG or SWD

I don't mind disabling JTAG / SWD for another layer of protection, so long as we can revive it somehow if needed (ie: devices coming back from the field, etc).

What is the recommended method for protecting a device, yet allowing external firmware updates (via bootloader)?

Section 5.2.4.1 of the latest datasheet states:

Performing the sequence below causes the nonvolatile registers discussed in “Nonvolatile Register Programming” on page 158 to be restored to their factory default values. The mass erase of the flash memory caused by the below sequence occurs prior to the nonvolatile registers being restored.

So it seems to contradict the blurb in section 8.3.2

[Xylifrost]

Hi..

is there a way to protect my flash movie from being saved or printed by users on their PCs?