Home arrow Support arrow Forums

Luminary Micro Forums
home | post reply | threaded view | PDF | help | rules
Boardwalk :: Forum List Luminary Micro Forums Suggestions

igorp

Gold Boarder 		Click here to see the profile of this user

2007/02/11 15:51

A serious problem

Our poduction presuposes to exchange firmware from time to time because changing of controled units. It's a mistake to develop Stellaris by a way that there is not any posibilities to erase the whole flash memory and reprogam it when we don't want to be read flash memory by a third person.
It degraded your product to one time programming chip so I can't recomend it to use in our products even though I like very much the solution you selected.

I hope you change behaving of LS3xxx in the next silicon version by a way other companies found as the best.

Regards

Igor

login or register to reply

gnuarm

Fresh Boarder 		Click here to see the profile of this user

2007/02/12 11:07

Re:A serious problem

If I understand this correctly, I agree with the objection. I have not read about programming the Flash, but from several posts here it would appear that the Flash security allows for programming the Flash to be permanently disabled. This is in contrast to a method of preventing the Flash from being written or read by the debugger, but still allowing the entire Flash to be erased, including the protection bits. Once erased, the device would be in the same state as it came from the factory and ready for a new upload.

Many products require design protection. But I don't know of many applications that need to make the part a one time programmable device.

login or register to reply

SourceTwo

Expert Boarder 		Click here to see the profile of this user

2007/09/19 13:31

Re:A serious problem

This is indeed a very serious matter - surely Luminary can devise a way for their customers to protect their IP without permenantly eliminating the possibility of on-board firmware updates? The concerns expressed below have languished unanswered for 7 months! Would one of the Luminary representatives please respond to address the concerns and indicate if Luminary is considering a practical means of addressing them? In my opinion, reworking the board to replace the microcontroller is not a realistic option...

Thank you in advance!

Regards,
Dave

login or register to reply

LMI Eric

Moderator 		Click here to see the profile of this user

2007/09/19 13:37

Re:A serious problem

There are various methods that we provide to protect the contents of the flash, ranging from per-page protection all the way to permanently disabling the debug interface. Please refer to application note AN01257 for details.

Even if the debug interface is disabled, you can use a bootloader to update flash over one of the serial interfaces.

login or register to reply

pButler1

Fresh Boarder 		Click here to see the profile of this user

2008/01/07 23:52

Re:A serious problem

App Note AN01257 reads in part:

(FMPPE FMPRE)
(0 0) Execute-only protection. The block may only be executed and may not be read, written or erased. This mode is used to protect code.
(1 0) The block may be written, erased or executed, but not read. This combination is unlikely to be used.
(0 1) Read-only protection. The block may be read or executed but may not be written or erased. This mode is used to lock the block from further modification while allowing any read or execute access.
(1 1) No protection. The block may be written, erased, executed or read.

This IS a problem if the FMPRE bit can not be set once cleared. The fact that these settings may be uncommitted for test is all but useless. These control bits must be committed when product is shipped.

For protecting my stuff I would use the (1 0) setting with the understanding that erasing the entire 2K block also sets FMPRE. But does it? Oh wait . . . If this prevents me from reading the flash with my code then it too is useless. I could see the (0 0) option as possibly useful if some reasonable way existed to erase the entire part while installed on a user PCB. (But only if my code could read its internal data.)

What is needed is a way to prevent the debugger – and only the debugger – from reading flash. It must not stop internal program access. I.e. only prevent a competitor from reading the code. And for some strange applications a way to prevent erasure without some serious “mother may I” setup.

I would make the “don’t allow debugger access” flag one that is erased by the block erase function. Oh wait, debugger writes code to RAM and runs that code… Let’s see… How about one protection flag per block and the debugger can only read those flags and erase the corresponding blocks until all protected blocks are erased.

Field returns need to be reprogrammed without tossing the microcontroller.

login or register to reply

mjbcswitzerland

Expert Boarder 		Click here to see the profile of this user

2008/01/18 13:43

Re:A serious problem

Hi All

I have just skipped through the application note - previously I had also studied the FLASH capabilities (an ddeveloped IAP code) so it was not all new to me.

In addition, I have also experience with projects where code protection is important. Usually it should not be possible for competitors to be able to extract the code from the chip and reverse engineer it.

With this goal in mind I read through the capabilities and the only one which seems to fit is the one marked FMPPE = 1, FMPRE = 0 - The block may be written, erased or executed, but not read. However to my surprise this is marked as "This combination is unlikely to be used"

However it does seem to me that both this the execute-only-protection (FMPPE = 0, FMPRE = 0) have a major drawback in the fact that the blocks can not hold "Literal data". As the AP-note explains, to be able to control literal data to be kept out of protected blocks requires a special compiler, which possibly still has to be developed.... (or else one has to stick to assembler).

The FMPPE = 0, FMPRE = 1 is certainly practical to protect a boot loader so that it can never be destroyed (once it is reliable enough of course..). As long as this boot loader allows a software update in production units to be made via some interface the other protection methods become redundant. In this case the debug interface can be perminently disabled, thus achieving the required protection.

In summary - my understanding is that the protection methods FMPPE = 1, FMPRE = 0 and FMPPE = 0, FMPRE = 0 are more of academic interests due to their additional complications (mainly the loss of const data read capability). For code IP protection the debug interface should be perminently deactivated and updates controlled exclusively by boot loader code.

This is workable, but a more traditional reset of the protection on full chip erase would involve rather less effort on behalf of the user....

Regards

Mark Butcher

www.uTasker.com

login or register to reply
Boardwalk :: Forum List Luminary Micro Forums Suggestions

Luminary Micro Forums