"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
"linnix" skrev i meddelandet news: snipped-for-privacy@m79g2000cwm.googlegroups.com...
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:
Put it up on
In Production..?
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.
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.
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.
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 ?
-jg
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.
The parallel programming will allow you to erase the chip, but not read it out.
High Voltage Serial programming is available on some devices.
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.
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
Just look at how Microchip do it. This works fine.
It has to be in the .hex file, as this is the only thing the chip itself needs out of the compiler.
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...
Do Atmel and other companies routinely publish application notes written by outsiders?
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.
Only if Atmel also commit to following it for all new parts as they are released.
Right. It needs to be implemented in a release of AVR Studio.
Microchip (PIC) does it, even though their MPLAB is in some ways less up-to-date than AVR Studio.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required