avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] Write byte to flash at arbitrary memory location


From: Joerg Wunsch
Subject: Re: [avrdude-dev] Write byte to flash at arbitrary memory location
Date: Wed, 23 Jan 2013 18:19:17 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

As Lars Andersson wrote:

> Here's a command line example:
> avrdude -cstk500v2 -B4 -pm16 -P/dev/ttyS0 -v -e -Uflash:w:main.hex:i,10,0,6

> Is this implemented in avrdude already or do I have to apply the patch and
> recompile. Also, if not implemented is there a reason for this ?

Reading the calibration data (per appnote AVR053) is supported through
the -O option, but writing it to an arbitrary location is not
supported.

First, I'd like to see a more general syntax for the -U option.  For
example, the "m" file type (immediate value) is currently only useful
for specifying fuses, but could also be extended to specify a
location so it could be useful e.g. for modifying arbitrary EEPROM
locations.  Example:

-U ee:w:@0x20,0x40,0x44:m

to write bytes 0x40 and 0x44 starting at address 0x20.

If we agree on something like this, it could then be applied to all
address-less input methods (namely, arbitrary binary files), so you
could e.g. also program a bootloader from a binary file:

-U fl:w:@0x1f00,bootloader.bin:r

Then, it should be possible to also "divert" the -O result to a
different location but EEPROM address 0 that way.

So far, nobody has made any much attempt towards such a more general
solution, so I took it there's not much demand for it.

I'm against a "special-cased hack" just for the calibration data.

Regarding storing the data in flash, keep in mind that flash can never
be programmed byte by byte, but only in terms of pages.  Except for
Xmega devices, erasing a page is not supported though, so the
respective flash location must be 0xff (from a previous chip erase).
I think this detail makes it completely impractical to store that
value in flash.  Note that this is *not* an AVRDUDE limitation but one
of the programming interface of non-Xmega AVRs.
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]