Document the addition of the latest safemode update in the change log.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@522 81a1dc3b-b13d-400b-aceb-764788c761c2
* add support for parts with just 'fuse' memory
* if any fuse memories are altered, reflect those changes in the
post-programming safemode check so that safemode no longer
complains about fuses which were intentionally altered; this
eliminates the need to completely disable safemode using -u in
order to program fuses.
* provide -s option which will not ask to restore fuses, it will
just do it
Submitted by: Colin O'Flynn <coflynn@newae.com>
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@519 81a1dc3b-b13d-400b-aceb-764788c761c2
was the whole programmer submission which was already added through
another request, but the former lacked the VCC definition. Pick it up
from this patch.
Submitted by: tmohr@s.netic.de
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@511 81a1dc3b-b13d-400b-aceb-764788c761c2
avr910 programmer.
Original Submission: The attached patch against avrdude 4.4.0 fixes
the following problems with paged writes in avr910.c:
- failure to re-set address after page writes;
- no polling or delay after page writes;
- no page writes when not using auto-increment;
- an extraneous page write when data ends on page boundary.
Submitted by: "Nic" <avrdude@schraudolph.org>
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@510 81a1dc3b-b13d-400b-aceb-764788c761c2
This fixes EEPROM access using the STK500V2 programmer, partially
undoing part of a previous general fixup commit. Choose the correct
read/write operations with the stk500v2 program function - the correct
one depends on the memory type. EEPROM is byte addressable so uses
read/write. FLASH is word addressable and so uses read_lo/write_lo.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@501 81a1dc3b-b13d-400b-aceb-764788c761c2
to 'i' (input). Even though this bit should be ignored, it should not
be changed. The 'x' setting sets the bit to zero which programs it
and could cause undefined behaviour. Setting to 'i' enables it to be
rewritten to its old value.
A better solution might be to read the fuse byte, apply the new value
while leaving the 'x' bit alone, then writing the value back. The
current fix is a workaround which allows the developer to change the
bit.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@494 81a1dc3b-b13d-400b-aceb-764788c761c2
when passing unsigned char * when char * is in the prototype and vice
versa. Clean these up along with a few others.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@491 81a1dc3b-b13d-400b-aceb-764788c761c2
#13693, #13871, and #14212.
This provides bug fixes to the STK500V2 programmer type. From the
patch information:
- incorrect token used from avrdude.conf.in
- wrong command sent to programmer, hence no write to eeprom.
- programmer was said to start writing at 0x0000 and continue page
by page and was not repositionned when a gap was found in the
hex file, or when the hex file start address was not
0x0000. Hence the verify procedure was correct, not the write
procedure.
- speed up of flash write to skip empty pages (full of 0xFF) by
re-enabling a dedicated function for that task.
- stk500v2_paged_load() was not returning the number of byte read,
so empty hex files were generated when reading memory.
Submitted by: Bernard Fouch <bernard.fouche@kuantic.com>
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@490 81a1dc3b-b13d-400b-aceb-764788c761c2
main_exit: label to ensure the programmer is released correctly.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@483 81a1dc3b-b13d-400b-aceb-764788c761c2
thus it was falsely reporting that it failed when it was actually
working correctly. Fixed.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@482 81a1dc3b-b13d-400b-aceb-764788c761c2
doc are either not available on all systems or are at best
inconvenient to build and install. The doc can still be built, one
just needs to specify --enable-doc at configure time.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@445 81a1dc3b-b13d-400b-aceb-764788c761c2
encoding is correct, specifically the address bits don't exactly match
those of the preliminary datasheet that I have, but I don't see how
they could be right. Tested with STK500 and it works there.
Instruction encodings have not been tested due to lack of a parallel
port on my Mac.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@436 81a1dc3b-b13d-400b-aceb-764788c761c2
switch. The specified baud rate will override the default serial port
baud rate for a particular programmer.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@416 81a1dc3b-b13d-400b-aceb-764788c761c2
return an error code when building on MacOS X. This commit makes
AVRDUDE compile and run fine on my PowerMac G5 running MacOS X. In
theory it would be possible to support parallel ports on the Mac using
a PCI multi-port card and/or USB<->Parallel converters. If/when such
support is added we can flesh out these functions as needed, but for
now, only serial port programmers are currently supported.
Note that I tested avrdude on the G5/MacOS X with an STK500 programmer
and used a Keyspan model USA-19HS USB<->RS232 adapter device which
simply shows up in /dev as a POSIX serial port. None of the serial
port handling needed any changes.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@415 81a1dc3b-b13d-400b-aceb-764788c761c2
* The second poll value for flash is corrected for all devices
* Delays are corrected for all devices, I have a datasheet for on my
harddisk
* mega161 is added
* avr910_devcode added for all devices except mega64, mega162,
mega169 and mega8535. Numbers are taken from uisp-source.
Contributed by Jan-Hinnerk Reichert <jan-hinnerk_reichert@hamburg.de>
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@382 81a1dc3b-b13d-400b-aceb-764788c761c2
Contributed by Erik Christiansen <erik@dd.nec.com.au>
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@378 81a1dc3b-b13d-400b-aceb-764788c761c2
eeprom, efuse, hfuse, and lfuse on a single command line. Much of the
output had to be ommitted from the example since the texi commands for
formatting the example don't allow page breaks within the example. If
someone knows a better way to format it, please feel free to do so.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@361 81a1dc3b-b13d-400b-aceb-764788c761c2
stk500 initialization routine. However, allow one to use the -F
option to ignore a bad return code from that function. I think this
still allows what Joerg intended, i.e., providing a way to still get
into terminal mode so that one can recover from setting bad STK500
values which may keep the chip from entering programming mode.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@359 81a1dc3b-b13d-400b-aceb-764788c761c2
anywhere specified to be written by any of the -U requests.
To remain backward compatible with previous versions, disable this
feature if any of the old-style memory specification operations are
specified (-i, -o).
Implement the -D option to explicitly disable the auto erase default.
Deprecate the old-style memory specification options (-f, -i, -I, -m,
and -o) in favor of the new -U option which allows one to operate on
multiple memories on a single command line.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@356 81a1dc3b-b13d-400b-aceb-764788c761c2
memory read or written (or up to where continuous 0xff begins in the
case of flash memory). An 'int' should be plenty big enough for that.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@354 81a1dc3b-b13d-400b-aceb-764788c761c2
Add the supported programmer list to the manual.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@343 81a1dc3b-b13d-400b-aceb-764788c761c2
argument is a 4 field string (fields seperated by colons) which
indicate what memory type to operate on, what operation to perform is
(read, write, or verify), the filename to read from, write to, or
verify against, and an optional file format field. Multple -U options
can be specified to operate on more than one memory at a time with a
single invocation. For example, to update both the flash and the
eeprom at the same time one can now specify the following:
avrdude -p -e -U flash:w:main.hex:i -U eeprom:w:eeprom.hex:i
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@341 81a1dc3b-b13d-400b-aceb-764788c761c2
reported that this patch fixes verify errors on the Windows platform
that are apparently timing related. Submitted by: Alex Shepherd
<ashepherd@wave.co.nz>, who indicates that this patch was based on
code from the UISP project.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@340 81a1dc3b-b13d-400b-aceb-764788c761c2
Submitted by Larry Barello <larryba@barello.net>.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@333 81a1dc3b-b13d-400b-aceb-764788c761c2
Extend ATmega8 calibration memory to support all 4 calibration bytes.
Savannah bug #3835. Submitted by Francisco T. A. Silva
<ftas@geodigitus.com.br>.
Add a few AVR910 programmer device codes. Savannah bug #3569 - sorry
I can't tell who submitted this to give proper credit.
Add support for the ATtiny12. Submitted by Pontifex <pontifex@isys.ca>
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@332 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
file format type to 'immediate mode' where the filename is assumed to
be the memory data itself.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@318 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
Daniel Williamson <dannyw@maconmgt.co.uk>
and
Ruwan Jayanetti <rjayanetti@sri.crossvue.com>
The resulting part definition used was actually somewhat of a merge of
the two submitted definitions.
Thanks for the contributions!
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@302 81a1dc3b-b13d-400b-aceb-764788c761c2
name when checking to see if we should default to the default_serial
port instead of the default_parallel port. This has us do the right
thing for the new 'avrisp' programmer.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@262 81a1dc3b-b13d-400b-aceb-764788c761c2
command be 128 bytes. This cuts 6 seconds off the programming time
for uploading a 6K file into an AT90S8515 vs the time loading the same
file using a 16 byte buffer, and the response feedback is still good.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@261 81a1dc3b-b13d-400b-aceb-764788c761c2
all on non-paged-memory parts. The problem was that the page size was
defaulting to 256 (maximum for the stk500), but the timeout for a
response from the stk500 before declaring it dead was only 0.5
seconds. But it takes much longer than 0.5 seconds to program 256
bytes, so we just weren't waiting long enough.
Fix this in two ways - increase the timeout to 5 seconds, and decrease
the page size to 16 bytes for non-paged parts. The programming time
for 16 bytes is short enough to provide the user with some feedback
that something is happening.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@260 81a1dc3b-b13d-400b-aceb-764788c761c2
itself is paged as it doesn't appear to work otherwise.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@259 81a1dc3b-b13d-400b-aceb-764788c761c2
causes some shift-reduce conflicts, but I think they are OK.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@255 81a1dc3b-b13d-400b-aceb-764788c761c2
Brian S. Dean