"mc" skrev i meddelandet news:rvpBg.31$ snipped-for-privacy@bignews6.bellsouth.net...
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
formatting link
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
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 the problem is, there is no standard method for doing this simple task ....
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 ?
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.
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.
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.
"Mike Harrison" skrev i meddelandet news: snipped-for-privacy@4ax.com...
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
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.