scanning the program header table, the offsets from a program
header entry must never be used directly when checking the bounds
of the current AVR memory region. Instead, they must always be
checked based on the corresponding section's entry. That way,
Xmega devices now properly take into account whether the segment
fits into any of the application/apptable/boot memory region.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@1085 81a1dc3b-b13d-400b-aceb-764788c761c2
program header segment, subtract `low' from ph[n].p_paddr in order
to correct the magic section offsets for the AVR's non-flash
memory regions.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@1080 81a1dc3b-b13d-400b-aceb-764788c761c2
any given section maps straight to a program header segment, use a
more sophisticated decision that matches any section as long as it
fits into the segment. This is needed for situations where the
program header segment spans a larger area than the section data
provided. (This can e.g. happen in an ELF file that contains no
data at address 0, like a bootloader only.)
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@1079 81a1dc3b-b13d-400b-aceb-764788c761c2
supported error
* stk500v2.c: Handle all Xmega memory sections (except
"prodsig" which is not documented in AVR079)
* fileio.c: Treat the "boot", "application", and "apptable"
regions (which are actually subregions of "flash") all as
being flash, i.e. suppress trailing 0xFF bytes when reading
them
* avr.c: (Dito.)
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@1075 81a1dc3b-b13d-400b-aceb-764788c761c2
(Extended Linear Address Record)
Replace the change from r928 (handling of 0x8000000 offset in AVR32
files) by a completely different logic that no longer breaks hex files
for other devices starting with an offset; also apply a similar change
to S-record files, as well as when writing files.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@1017 81a1dc3b-b13d-400b-aceb-764788c761c2
Each memory image byte is now tagged as it's being read from a file.
Only bytes read from a file will be written or verified (modulo page
granularity requirements).
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@1007 81a1dc3b-b13d-400b-aceb-764788c761c2
bug #33345: File auto detection as binary doesn't open
file in binary mode on Windows
* fileio.c: Move the decision about opening files in
binary mode until before the fopen() call.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@964 81a1dc3b-b13d-400b-aceb-764788c761c2
0x10000 bytes
* fileio.c: Revert the changes from r851 and r880, respectively.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@928 81a1dc3b-b13d-400b-aceb-764788c761c2
* fileio.c: Do not close the input/output stream when working on an
stdio stream.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@816 81a1dc3b-b13d-400b-aceb-764788c761c2
patch #6141: accept binary format immediate values
Detect a 0b prefix, and call strtoul() differently in that case.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@754 81a1dc3b-b13d-400b-aceb-764788c761c2
- Make all internal functions "static".
- Make sure each module's header and implementation file match.
- Remove all library-like functionality from main.c, so only
the actual frontend remains in main.c.
- Add C++ brackets to all header files.
That effectively leaves the various module C files as something like
an "avrdude library", with main.c being the currently only frontend
program for that library. In theory, it should be possible to write
different frontends using the same library backend functions though.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@722 81a1dc3b-b13d-400b-aceb-764788c761c2
declarations in each file by a central header file "avrdude.h".
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@721 81a1dc3b-b13d-400b-aceb-764788c761c2
and binary numbers.
Closes bug #16129: more output formats for fuse bits (avrdude
enhancement request)
* fileio.c: Implement fileio_num() and the itoa_simple() helper function.
* fileio.h: Add new file formats to FILEFMT.
* main.c: Parse the new file formats.
* avrdude.1: Document all this.
* doc/avrdude.texi: (Ditto.)
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@654 81a1dc3b-b13d-400b-aceb-764788c761c2
resides above the last non-0xff data value in the address space. Only
do this for flash memory since writing a 0xff to flash is a no-op.
This has the affect of creating smaller output files when dumping
memory contents from flash if the program in flash does not consume
the whole memory space. It also results in shorter programming times
when avrdude is asked to load a file into flash that has lots of 0xff
filled data past the last non-0xff data value.
I think this is basically where Alexey was going with his s-record
routine, but this should have a similar affect for all the I/O
routines. The main difference is that Alexey's also optimized 0xff
from the beginning of the address space and was not limited to flash.
I think that these optimizations should be limited to the flash since
it is currently the only memory that treats 0xff as special.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@331 81a1dc3b-b13d-400b-aceb-764788c761c2
output routines (don't optimize away 0xff data before and after non
0xff data). Also, fix a bug where the data contents sometimes weren't
written out completely.
Initial bug reported by Tom Harris <TomH@optiscan.com>. Fixes
provided by Alexey V.Levdikov <tsar@kemford.com>.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@330 81a1dc3b-b13d-400b-aceb-764788c761c2
main.c : print out '<stdin>' and '<stdout>' instead of '-' when using
stdio for I/O.
Thanks to Francisco T. A. Silva <ftas@geodigitus.com.br> for catching
this, and the error fixed by the previous commit as well.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@325 81a1dc3b-b13d-400b-aceb-764788c761c2
specify byte values on the command line instead of via a file. This
can be good for specifying fuse bytes and eliminates the need to
create single-byte files or using interactive terminal mode for these
single-byte memories. Requested by several folks on the mailing list.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@317 81a1dc3b-b13d-400b-aceb-764788c761c2
* .cvsignore: Ignore autoconf files.
* AUTHORS: New file.
* ChangeLog: New file.
* Makefile: Removed file.
* Makefile.am: New file.
* NEWS: New file.
* README: New file.
* bootstrap: New file.
* configure.ac: New file.
* avr.c: Include ac_cfg.h (generated by autoconf).
* config.c: Include ac_cfg.h.
Include config_gram.h instead of y.tab.h.
* config.h: If HAS_YYSTYPE is not defined, define YYSTYPE.
* config_gram.y: Include ac_cfg.h.
* fileio.c: Include ac_cfg.h.
* lexer.l: Include config_gram.h instead of y.tab.h.
* lists.c: Include ac_cfg.h.
* main.c: Include ac_cfg.h.
* par.c: Include ac_cfg.h.
* pgm.c: Include ac_cfg.h.
* ppi.c: Include ac_cfg.h.
* stk500.c: Include ac_cfg.h.
* term.c: Include ac_cfg.h.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@192 81a1dc3b-b13d-400b-aceb-764788c761c2
This was intended to be used for identifying code in the field for
incoming bug reports, but I've never really found it all that useful.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@171 81a1dc3b-b13d-400b-aceb-764788c761c2
undergone. This utilizes the last two bytes of EEPROM to maintain a
counter that is incremented each time the part is erased.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@138 81a1dc3b-b13d-400b-aceb-764788c761c2
serial programming instructions are not very orthoganal, i.e., the
"read fuse bits" instruction on an ATMega103 is an entirely different
opcode and data format from the _same_ instruction for an ATMega163!
Thus, it becomes impossible to have a single instruction encoding
(varying the data) across the chip lines.
This set of changes allows and requires instruction encodings to be
defined on a per-part basis within the configuration file. Hopefully
I've defined the encoding scheme in a general enough way so it is
useful in describing the instruction formats for yet-to-be invented
Atmel chips. I've tried hard to make it match very closely with the
specification in Atmel's data sheets for their parts. It's a little
more verbose than what I initially hoped for, but I've tried to keep
it as concise as I could, while still remaining reasonably flexible.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@100 81a1dc3b-b13d-400b-aceb-764788c761c2
has a 128K flash.
Due to the bank addressing required, interactive update of the flash
is not supported, though the eeprom can be updated interactively.
Both memories can be programmed via non-interactive mode.
Intel Hex Record type '04' is now generated as required for outputing
memory contents that go beyond 64K.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@78 81a1dc3b-b13d-400b-aceb-764788c761c2
file. This makes supporting other programmers much easier.
Rename AVRprog.pdf to avrprog.pdf.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@67 81a1dc3b-b13d-400b-aceb-764788c761c2
component module. This is intended for support purposes, so that I
can tell unambiguously what version a binary out in the field is.
Additionally, display a revision timestamp along with the version
number. This also is intended for aiding in support and is the Unix
time of the latest component module. Having this, should allow me to
do a "cvs co -D timestamp avrprog" and get exactly the source of the
version that is being reported.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@55 81a1dc3b-b13d-400b-aceb-764788c761c2
bytes written. The presence of an Intel Hex address record can cause
these two number to be different; but the callers of this routine need
the former.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@54 81a1dc3b-b13d-400b-aceb-764788c761c2
fileio.c: Properly handle all the Intel Hex record types that I can
find information about.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@52 81a1dc3b-b13d-400b-aceb-764788c761c2
joerg_wunsch
rliebscher
dhoerl
bdean
kiwi64ajs
arcanum
troth
bsd