ISP programming and code prrotection

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.

Most firmware is encrypted and us e a bootloader with the right key. Look at the avr site and search for DES application.

SFC

"eeh" schreef in bericht news: snipped-for-privacy@o13g2000cwo.googlegroups.com...

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.

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.

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

Maybe he's thinking of this...

-- MT

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
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

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

Robert

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.

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.

Thanks Mark, that makes a lot more sense.

Robert

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

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

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

snipped-for-privacy@execyul> > >> Maybe he's thinking of this...

where he

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.

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

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

but you

How?

I only know there are 3 kinds of lock bits.

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