Re: [avr-gcc-list] Patching EEPROM image for production

[Andy Warner]

On 10/5/06, dimax un <address@hidden> wrote:
> Hi Folks,
>
> I'm trying to find clean solution for the following system problem.
> I have configuration structure in EEPROM:
> struct VPD_t
> {
>    char sn[10];
>    char id[20];
> }VPD EEPMEM;
> [...]

Is the location in eeprom fixed between releases of the
code (usually true for firmware upgrade purposes..) ?

If so, I split the problem into two pieces - programming the
invariant parts, and then programming the serialisation. I then
have two makefile targets, one for each. The serialisation target
can do lots of different things, like get the next serial number from
a mysql database, update manufacturing records etc etc. For a
simple case where I can write all of eeprom, I just use a perl script
along the lines of:

      #
      # do whatever it takes to dream up $serial and $id
      #
      $eeprom = pack("Z10 a20", $serial, $id);
      print STDOUT $eeprom;

then pipe that to "avrdude <other options> -U eeprom:w:-:r"

For more complex operations, for instance where you're not writing from 0 in
eeprom, or need to write 2 or more disjoint sections of eeprom, then
you can try all
all kinds of cuteness: creating temorary c files, compiling and
downloading them;
directly generating hex/srec files; or using tools such as avr-objcopy
or srecord
utilities before feeding them to avrdude.

I also have a habit of putting build/programming data (host, time, user etc)
in any unused eeprom locations. You never know when that info might help
you isolate the root cause of a bad batch of widgets.

Does this help at all ?
What you are trying to do is totally reasonable, and easily accomplished.
--
Andy