Lpc2000

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

Cheers, Bob

--- In lpc2000@yahoogroups.com, "mirax_ua" <mirax_ua@y...> wrote:
> Hello ppl,
> Those processors don't have any flash copy protection, do they? As 
> long as there is some executable code in external memory and that is 
> what external flash is meant for. You can hook up some of you code 
> into external flash that will read the contents of internal flash and 
> give it away via say serial interface. What protection are we talking 
> about here?
> Acctually, I couldn't find any 32-bit processor that has both external 
> memory bus and internal flash with read protection.