Hi Bob,
You are right about "...unless you can fit your whole program into
internal flash" and that is what I eventually decided to do (have
chosen AT91SAM7S512 though, 'cos of 512k of flash and 64k of RAM).
And about "Besides the fact that this will use up a significant part
of your internal Flash..." I can say that I have earlyer implemented
DES (56-bit key) decrypting downloader in PIC16Fxxx and the whole
thing took about 1k of flash and 256 bytes of EEPROM for tables
(matrices).
--- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@y...>
wrote:
> Hi,
>
> your observation is correct that any external CODE will destroy
your
> efforts to secure the internal Flash because there is no READ
> protection. The available protection disables all debug channels
and
> if your code does not branch outside the chip, protection is
> available. Even external data is possible but no external code. As
Tom
> already pointed out, an option is to encrypt/decrypt the code you
are
> fetching from external memory. Besides the fact that this will use
up
> a significant part of your internal Flash, it will also slow down
> execution a lot. Nevertheless, if you can put the part of the code
> that needs performance into the flash, together with the
en/decryption
> code this might be an option.
>
> Better would be if you can fit your program (not necessarily your
> data) into the internal flash. In this case the available
protection
> would work.
>
> One other option to protect yourself against tampering with
external
> memory are sanity checks such as checksums of a code segment before
> you execute it, which would prevent you from execute code not
> compliant with checksum rules you would set up. However, this can
be
> cracked rather easily, just requires somebody with a little
experience
> rather than somebody who is just curious ;-)
>
> In a nutshell, of the shelf microcontrollers will probably not fit
> your requirements unless you can fit your whole program into
internal
Show quoted textHide quoted text