ISP programming and code prrotection

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,

I know that many products support ROM upgrade or in system programming
(ISP). However, from my brain that logically to enable this feature the
mcu should not be locked.

So I have a question that whether the above thinking is right ro not.
Or if it is right, is it possible to make ISP possible and
simultaneously protect our firmware code from being read during
verification?

Thanks!


Re: ISP programming and code prrotection
Quoted text here. Click to load it

Depends on the micro. Often, ISP is locked out once you enable the
protection bits. Sometimes the verification process works by sending
the new data to the micro twice; first time to burn, second time to
verify. Sometimes you simply can't verify after setting the protection
bits, in which case the procedure is to erase the device, program code
memory, verify code memory, then program security bits.

By definition, anyone who has the power to ISP-burn your micros has
enough information to copy them.


Re: ISP programming and code prrotection
Quoted text here. Click to load it
You can put an AVR in a state where you cannot read out and verify but you
can still erase it.
Protection AND reprogrammability.
You can also have a selfprogramming application where you send down a
3DES encrypted file which is decrupted and programmed into the flash.
There is an application note available on that subject.


--
Best Regards
Ulf at atmel dot com
We've slightly trimmed the long signature. Click to see the full one.
Re: ISP programming and code prrotection
Quoted text here. Click to load it
but you

How?

I only know there are 3 kinds of lock bits.

1: Mode
2: Application Protection mode
3: Boot Loader Protection mode


Re: ISP programming and code prrotection
Most firmware is encrypted and us e a bootloader with the right key. Look at
the avr site and search for DES application.

SFC


Quoted text here. Click to load it



Re: ISP programming and code prrotection
Quoted text here. Click to load it

On what do you base that assertion?  It certainly runs counter to my
(limited) experience and none of the micros's I've worked with support
this.

The closest I've seen is a few chips that have an unlock key to enable
reading of the OTP/EPROM on board but the firmware certainly wasn't
encrypted.

Robert

Re: ISP programming and code prrotection
Maybe he's thinking of this...

http://www.atmel.com/products/SecureAVR/Default.asp

--
MT



Re: ISP programming and code prrotection
says...
Quoted text here. Click to load it

Beg pardon?  Context man, context.  Who's thinking of it in respect to
what?

Robert

Re: ISP programming and code prrotection
Quoted text here. Click to load it


I'm sorry for your confusion Robert.  I was referring to SFC's post where he
suggested searching for DES on Atmel's website.

--
MT

To reply directly, please remove all 5 occurrences of the letter 'y' from my
address.



Re: ISP programming and code prrotection
says...
Quoted text here. Click to load it

Thanks Mark, that makes a lot more sense.

Robert

Re: ISP programming and code prrotection
how _exactly_ did this:

1: "I was referring to SFC's post where he suggested searching for DES on
Atmel's website."

help _you_ to understand this:

2: "Maybe he's thinking of this...
http://www.atmel.com/products/SecureAVR/Default.asp"

For me (and I'm going to make a wild assumption that it's the case for the
vast majority of people), it's plainly obvious what the context is in the
second example: i.e someone (It makes no difference to me who it was) was
referring to something to do with 'secure avr' on Atmel's website - a link
was provided for anyone that was interested.

In other words what part of "Maybe, he's thinking, Atmel, Secure, AVR" did
you not understand?  (Because, it really looks to me like you were just
making a point of the fact that the poster in question didn't quote - and if
you were making a point, why were you not honest about it and just say so,
rather than pretending to be baffled?).

What is it that I'm failing to see here?

Joe



Quoted text here. Click to load it
snipped-for-privacy@execyulinky.comy
Quoted text here. Click to load it
where he



Re: ISP programming and code prrotection
spammers-paradise.com says...
Quoted text here. Click to load it

Strangely enough it did provide enough extra information for it to make
sense.  This thread did start off on ISP code protection and the link
made no sense (to me anyway) in that context but there was a branch off
to Atmel providing DES support and that was enough extra information to
bring the context back.  Now someone who read those two responses without
getting and remembering the branch could certainly be forgiven for being
completly bamboozled at this point.  And we've veered off topic well into
the woods.

<snip>
Quoted text here. Click to load it

Mainly, what its relation to ISP was and what line of thought was being
followed up.

Quoted text here. Click to load it

Hey, just because you're baffled doesn't mean you can't make a point ;)  
I really wasn't following the line of thought though.  

Robert

Re: ISP programming and code prrotection
Quoted text here. Click to load it

You should realize that there is no reason that previous posts
should be available at a given location, nor that they ever were
there in the past.  Thus quotations should include all the germane
material, and excise everything that is not germane to a reply.  An
article should stand by itself.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: ISP programming and code prrotection

Quoted text here. Click to load it
programming
the

Well you can't verify code if you can't read it!! What happens is you
verify and then you set the code lock fuses, the code cannot be read
then. To upgrade you have first to bulk erase the chip. The code is
protected against all but the most determined attackers, some chips are
better than others, in practice there are only a few instances where
it's not easier to do your own. You need to take precautions when using
chips with a self programming ability to make sure they don't modify
themselves during powerup, brown outs, glitches, noise spikes ect.


Re: ISP programming and code prrotection

Quoted text here. Click to load it

For those chips that have self-programming capability, it would be possible to
program using an
encrypted comms protocol implemented in the bootloader. The bootloader would
contain the decryption
key.
Some chips have limitations on the code protection possibilities when
self-programming is enabled,
but these can be worked around, e.g. by the main code making calls to routines
'hidden' in the
protected bootloader area, and the bootloader validating the main code before
allowing execution.
 
 

Re: ISP programming and code prrotection
Hi,

Alot of the new Motorola ( freescale ) parts have code protection based
around the interrupt vector table in flash... so to unlock the CPU for
reading/writing you need to have the hex file of the previously loaded
firmware in that device. When the device programmer wants to unlock the CPU
it starts the programming cycle by sending the vector table down, if it
matches the table on the device, the device is unlocked.

Renesas CPUs allow you to set a 10 byte code when your ISP programming the
device, then the next time you want to access the device ( to read / write
flash ) you are required to send the 10byte code, much like the Motorola
method above.

Most of the ISP programmers I've seen do this for you automatically, in the
first case they ask for the previous hex file and in the second case it can
load the 10 byte unlock code manually or from a file.




Quoted text here. Click to load it



Site Timeline