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