AVR trivia question

>>
>> I think that is a security thing.
>> If you can enable JTAG, you can read out the contents.
>
> If I really want to protect that, I would cut the pins.
>
> If you really want to copy the content, you would remove the chip and
> go for parallel probe anyway.
>

The parallel programming will allow you to erase the chip, but not read it 
out.

>>
>> When you do a full chip erase you can erase the JTAG disable so you can 
>> use:
>> * High Voltage Parallel programming:    (That is difficult to use for 
>> most
>> customers)
>> * ISP.
>
> Exactly, especially when it's difficult to isolate port B and D
> in-circuit.
>
> I would suggest a simple chip erase mode (+12V to VCC and RESET) to
> erase the chip and put it back into factory defaults.
>
High Voltage Serial programming is available on some devices.


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

On Mon, 7 Aug 2006 09:21:42 -0400, "mc" <look@www.ai.uga.edu.for.address> wrote:

>"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message 
>news:6bFBg.55$oT6.87@nntpserver.swip.net...
>> "mc" <look@www.ai.uga.edu.for.address> skrev i meddelandet
>>>
>>> Hear, hear!  The .hex file should contain everything needed to program 
>>> the micro.
>>
>> One could of course argue that in many cases, you don't have a hex file.
>> Instead you are burning directly from AVR Studio using the project file + 
>> COFF/ELF object files.
>> I think that www.equinox-tech.com supports a single hex file for 
>> production AVR programming.
>
>Right... Let's not solve the wrong problem.  What I really want is a way to 
>state the fuse settings as directives in the assembly language program (or 
>as something in a C program that would have the same effect) so that they 
>would stay with the program automatically.
>
But this has to start with a standard way, defined by Atmel,  to embed them in the hex file. 
Only then can the compiler/assembler writers  implement it. 

On Mon, 7 Aug 2006 09:21:42 -0400, "mc"
<look@www.ai.uga.edu.for.address> wrote:

>"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message 
>news:6bFBg.55$oT6.87@nntpserver.swip.net...
>> "mc" <look@www.ai.uga.edu.for.address> skrev i meddelandet
>>>
>>> Hear, hear!  The .hex file should contain everything needed to program 
>>> the micro.
>>
>> One could of course argue that in many cases, you don't have a hex file.
>> Instead you are burning directly from AVR Studio using the project file + 
>> COFF/ELF object files.
>> I think that www.equinox-tech.com supports a single hex file for 
>> production AVR programming.
>
>Right... Let's not solve the wrong problem.  What I really want is a way to 
>state the fuse settings as directives in the assembly language program (or 
>as something in a C program that would have the same effect) so that they 
>would stay with the program automatically.
>

I had the same problem, and asked about it on the avr-gcc list. What
came out of that was a suggestion to define a new section in which you
place your fuse bytes. One can easily create macros and defines to be
able to easily define the fuse bytes contents. Using GCC, it is easy
to extract the fuse bytes and to program them. 

Regards
  Anton Erasmus

On Tue, 08 Aug 2006 08:08:41 +1200, Jim Granville <no.spam@designtools.co.nz> wrote:

>mc wrote:
>> "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message 
>> news:6bFBg.55$oT6.87@nntpserver.swip.net...
>> 
>>>"mc" <look@www.ai.uga.edu.for.address> skrev i meddelandet
>>>
>>>>Hear, hear!  The .hex file should contain everything needed to program 
>>>>the micro.
>>>
>>>One could of course argue that in many cases, you don't have a hex file.
>>>Instead you are burning directly from AVR Studio using the project file + 
>>>COFF/ELF object files.
>>>I think that www.equinox-tech.com supports a single hex file for 
>>>production AVR programming.
>
>but the problem is, there is no standard method for doing this simple 
>task ....
>
>> 
>> Right... Let's not solve the wrong problem.  What I really want is a way to 
>> state the fuse settings as directives in the assembly language program (or 
>> as something in a C program that would have the same effect) so that they 
>> would stay with the program automatically.
>
>Correct, and a memory mapped dataspec IS the most portable way to handle 
>that.
>If you need a real example, look at Philips LPC7xx series.
>I think those can also READ the fuse bytes, which can also be useful.
>
>eg a common request of users, to be able to hang/change if they find the 
>security fuses not-set. (==production slipped up) - many uC cannot
>prove they are secure, at run time. (but that's another problem...)
>
>Here is a simple rules suggestion for a HEX (or COFF) memory map,
>that could be 100% SOURCE CODE created ( project file agnostic )  :
>
> From the Bottom-Up: ( eg AVR and 80C51 cores )
>a) Code Space
>b) EEPROM space appends on top of Code space [sort of done now]
>TopDown:
>c) Fuse Bytes, packed in alphabetical order (highest byte=last alphabet 
>name)
>
>For devices that lack the Fuse-read, the SW could duplicate c) onto
>the top of a) using the same rules. With ALL the info in ONE file, it is 
>now much harder for production to miss-step the code and fuses.
>
>Programmers should then be able to load, and save, such files.
>
>This just needs to go into each device's programming spec ?
>
>-jg

Just look at how Microchip do it. This works fine. 

On Mon, 7 Aug 2006 19:10:01 -0400, "mc" <look@www.ai.uga.edu.for.address> wrote:

>"larwe" <zwsdotcom@gmail.com> wrote in message 
>news:1154990368.506971.17470@m73g2000cwd.googlegroups.com...
>>
>> Ulf Samuelsson wrote:
>>
>>> > Hear, hear!  The .hex file should contain everything needed to program 
>>> > the
>>> > micro.
>>> >
>>>
>>> One could of course argue that in many cases, you don't have a hex file.
>>> Instead you are burning directly from AVR Studio using the project file +
>>
>> Okay, so what you are saying is that AVR is designed specifically for
>> one-time prototypes and should never be used in mass production?
>> Please, Ulf, this is clearly specious.
>
>Anyhow, the point is, whether it's .hex or something else, the fuses should 
>be able to be specified in the source program file (assembly, C, or whatnot) 
>rather than on a menu, so that they are textually explicit and can't be 
>separated from the program.

It has to be in the .hex file, as this is the only thing the chip itself needs out of the compiler.

Ulf Samuelsson wrote:
> >>
> >> I think that is a security thing.
> >> If you can enable JTAG, you can read out the contents.
> >
> > If I really want to protect that, I would cut the pins.
> >
> > If you really want to copy the content, you would remove the chip and
> > go for parallel probe anyway.
> >
>
> The parallel programming will allow you to erase the chip, but not read it
> out.

Why doesn't Atmel simply disable jtag reading, but not erasing.  AVR's
jtag is unreliable, since it's subject to software and hardware
gitches.  I have a prototype board that lost jtag immediately after
messing with the fuses.  My customer and I are nervous that software
gitches can render the chip useless.

>
> >>
> >> When you do a full chip erase you can erase the JTAG disable so you can
> >> use:
> >> * High Voltage Parallel programming:    (That is difficult to use for
> >> most
> >> customers)
> >> * ISP.
> >
> > Exactly, especially when it's difficult to isolate port B and D
> > in-circuit.
> >
> > I would suggest a simple chip erase mode (+12V to VCC and RESET) to
> > erase the chip and put it back into factory defaults.
> >
> High Voltage Serial programming is available on some devices.
>
>
> --
> Best Regards,
> Ulf Samuelsson
> This is intended to be my personal opinion which may,
> or may not be shared by my employer Atmel Nordic AB

"Mike Harrison" <mike@whitewing.co.uk> skrev i meddelandet 
news:n7lgd2dhl3npcas39br8cr5tu1psq0vd8i@4ax.com...
> On Mon, 7 Aug 2006 09:21:42 -0400, "mc" <look@www.ai.uga.edu.for.address> 
> wrote:
>
>>"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message
>>news:6bFBg.55$oT6.87@nntpserver.swip.net...
>>> "mc" <look@www.ai.uga.edu.for.address> skrev i meddelandet
>>>>
>>>> Hear, hear!  The .hex file should contain everything needed to program
>>>> the micro.
>>>
>>> One could of course argue that in many cases, you don't have a hex file.
>>> Instead you are burning directly from AVR Studio using the project file 
>>> +
>>> COFF/ELF object files.
>>> I think that www.equinox-tech.com supports a single hex file for
>>> production AVR programming.
>>
>>Right... Let's not solve the wrong problem.  What I really want is a way 
>>to
>>state the fuse settings as directives in the assembly language program (or
>>as something in a C program that would have the same effect) so that they
>>would stay with the program automatically.
>>
> But this has to start with a standard way, defined by Atmel,  to embed 
> them in the hex file.
> Only then can the compiler/assembler writers  implement it.

If I were deciding things for Atmel tools, I would work with Equinox to try 
to establish
their format as the standard.
They have long been a partner to Atmel so it would make sense to encourage 
the use of their format.
No need to invent a new one...
There is nothing stopping people from working with Equinox without Atmel 
involvement of course.

Another way is for someone to use AVRfreaks.net/sourceforge to develop a 
defacto standard.
Then write an application note which gets published by Atmel, and voila, the 
standard is there...

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message 
news:ebb2be$pu6$3@emma.aioe.org...

> Then write an application note which gets published by Atmel, and voila, 
> the standard is there...

Do Atmel and other companies routinely publish application notes written by 
outsiders?

On Wed, 9 Aug 2006 00:07:49 +0200, "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote:

>"Mike Harrison" <mike@whitewing.co.uk> skrev i meddelandet 
>news:n7lgd2dhl3npcas39br8cr5tu1psq0vd8i@4ax.com...
>> On Mon, 7 Aug 2006 09:21:42 -0400, "mc" <look@www.ai.uga.edu.for.address> 
>> wrote:
>>
>>>"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message
>>>news:6bFBg.55$oT6.87@nntpserver.swip.net...
>>>> "mc" <look@www.ai.uga.edu.for.address> skrev i meddelandet
>>>>>
>>>>> Hear, hear!  The .hex file should contain everything needed to program
>>>>> the micro.
>>>>
>>>> One could of course argue that in many cases, you don't have a hex file.
>>>> Instead you are burning directly from AVR Studio using the project file 
>>>> +
>>>> COFF/ELF object files.
>>>> I think that www.equinox-tech.com supports a single hex file for
>>>> production AVR programming.
>>>
>>>Right... Let's not solve the wrong problem.  What I really want is a way 
>>>to
>>>state the fuse settings as directives in the assembly language program (or
>>>as something in a C program that would have the same effect) so that they
>>>would stay with the program automatically.
>>>
>> But this has to start with a standard way, defined by Atmel,  to embed 
>> them in the hex file.
>> Only then can the compiler/assembler writers  implement it.
>
>If I were deciding things for Atmel tools, I would work with Equinox to try 
>to establish
>their format as the standard.
>They have long been a partner to Atmel so it would make sense to encourage 
>the use of their format.
>No need to invent a new one...
>There is nothing stopping people from working with Equinox without Atmel 
>involvement of course.

This standardisation HAS to come from the chip manufacturer, to ensure everyone does things the same
way and there is no room for arguing between third parties etc. It is also essential that  it is
defined for new chips as soon as they are released, i.e. in the first release of the programming
spec and datasheet, which would also define standard names for all the fuses, and these would be in
the device-specific .inc files.  
Only the manufacturer can do this effectively. 

Come on guys, this is not rocket science. 

On Tue, 8 Aug 2006 18:29:24 -0400, "mc" <look@www.ai.uga.edu.for.address> wrote:

>"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message 
>news:ebb2be$pu6$3@emma.aioe.org...
>
>> Then write an application note which gets published by Atmel, and voila, 
>> the standard is there..

Only if Atmel also  commit to following it for all new parts as they are released.