AVR trivia question

Jim Granville wrote:
> Mike Warren wrote:
>> Jim Granville wrote:
>>
>>> What Atmel should do (have done), is simply specify a HEX file
>>> mapping that INCLUDES the fuses, in the data sheets.
>>
>>
>> Atmel have done this? I couldn't find any documentation. Can you
>> point me to it?
>
> OOps, [Sorry to get your hopes up..... ]
>  Re-reading that, I should have more correctly written (have done?)
> or this
> What Atmel should do (_should_ have done)...

Ah, ok. In that case I propose that my system becomes the standard. ;-)

If anyone wants my program and the circuit of the simple hardware
you are welcome to it. Just ask. I have already given it to a couple of
people. If there is some interest I'll put it up on a web page.

-Mike

"mc" <look@www.ai.uga.edu.for.address> skrev i meddelandet 
news:rvpBg.31$Uq1.6@bignews6.bellsouth.net...
> "larwe" <zwsdotcom@gmail.com> wrote in message 
> news:1154872927.566773.5910@m79g2000cwm.googlegroups.com...
>
>> Ulf, this really sucks. For every other micro I use, I can give a
>> single HEX (or .TXT, for MSP430) to test engineering, and a checksum
>> that covers every byte of the device including the fuse settings.
>>
>> It's not like Atmel would have to make any silicon changes; just tell
>> vendors a standard method for adding a fake memory segment to the end
>> of the .HEX file with a magic start address that means "here be fuses".
>> While you're about it, roll the EEPROM data in there as well.
>
> 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.

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

"linnix" <me@linnix.info-for.us> skrev i meddelandet 
news:1154890016.341947.183300@m79g2000cwm.googlegroups.com...
>
> Mike Harrison wrote:
>> On Sat, 5 Aug 2006 22:38:53 -0400, "mc" <look@www.ai.uga.edu.for.address> 
>> wrote:
>>
>> >There isn't a way to specify the fuse bit settings of the Atmel AVR as
>> >directives in the assembly language program, is there?  Have I 
>> >overlooked
>> >something?  It seems awkward to have to begin every program with a 
>> >comment
>> >telling me what boxes to check on the STK500 "Fuses" menu.
>> >
>> No - this is one the dumbest things Atmel have (not) done - it is truly 
>> insane that you can't have a
>> single hex file that contains ALL the info for a chip.
>
> No, that's the second dumbest things.  IMHO, the dumbest things is to
> disable Jtag (or other programming modes) with the fuses.  Once it's
> messed up, there is no way to reset them to factory defaults.
>

I think that is a security thing.
If you can enable JTAG, you can read out the contents.

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.

-- 
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 Warren" <miwa-not-this-bit@or-this-csas.net.au> skrev i meddelandet 
news:44d698d7$0$506$61c65585@uq-127creek-reader-03.brisbane.pipenetworks.com.au...
> Jim Granville wrote:
>> Mike Warren wrote:
>>> Jim Granville wrote:
>>>
>>>> What Atmel should do (have done), is simply specify a HEX file
>>>> mapping that INCLUDES the fuses, in the data sheets.
>>>
>>>
>>> Atmel have done this? I couldn't find any documentation. Can you
>>> point me to it?
>>
>> OOps, [Sorry to get your hopes up..... ]
>>  Re-reading that, I should have more correctly written (have done?)
>> or this
>> What Atmel should do (_should_ have done)...
>
> Ah, ok. In that case I propose that my system becomes the standard. ;-)
>
> If anyone wants my program and the circuit of the simple hardware
> you are welcome to it. Just ask. I have already given it to a couple of
> people. If there is some interest I'll put it up on a web page.
>


Put it up on www.avrfreaks.net and maybe it will become the (defacto) 
standard ;-)



> -Mike
>


-- 
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 10:19:47 +0200, "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote:

>"mc" <look@www.ai.uga.edu.for.address> skrev i meddelandet 
>news:rvpBg.31$Uq1.6@bignews6.bellsouth.net...
>> "larwe" <zwsdotcom@gmail.com> wrote in message 
>> news:1154872927.566773.5910@m79g2000cwm.googlegroups.com...
>>
>>> Ulf, this really sucks. For every other micro I use, I can give a
>>> single HEX (or .TXT, for MSP430) to test engineering, and a checksum
>>> that covers every byte of the device including the fuse settings.
>>>
>>> It's not like Atmel would have to make any silicon changes; just tell
>>> vendors a standard method for adding a fake memory segment to the end
>>> of the .HEX file with a magic start address that means "here be fuses".
>>> While you're about it, roll the EEPROM data in there as well.
>>
>> 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.

In Production..?

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

Ulf Samuelsson wrote:
> "linnix" <me@linnix.info-for.us> skrev i meddelandet
> news:1154890016.341947.183300@m79g2000cwm.googlegroups.com...
> >
> > Mike Harrison wrote:
> >> On Sat, 5 Aug 2006 22:38:53 -0400, "mc" <look@www.ai.uga.edu.for.address>
> >> wrote:
> >>
> >> >There isn't a way to specify the fuse bit settings of the Atmel AVR as
> >> >directives in the assembly language program, is there?  Have I
> >> >overlooked
> >> >something?  It seems awkward to have to begin every program with a
> >> >comment
> >> >telling me what boxes to check on the STK500 "Fuses" menu.
> >> >
> >> No - this is one the dumbest things Atmel have (not) done - it is truly
> >> insane that you can't have a
> >> single hex file that contains ALL the info for a chip.
> >
> > No, that's the second dumbest things.  IMHO, the dumbest things is to
> > disable Jtag (or other programming modes) with the fuses.  Once it's
> > messed up, there is no way to reset them to factory defaults.
> >
>
> 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.

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

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

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

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.

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