* 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
*avr.h: Removed prototypes for moved functions
*avrpart.h: Added prototypes for functions in avrpart.c
*Makefile.am: Added new file avrpart.c
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@388 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
Have avr_read_byte() call pgm->read_byte() or avr_read_byte_default().
Add avr_write_byte_default().
Have avr_write_byte() call pgm->write_byte or avr_write_byte_default().
* pgm.c: Initialize pgm->write_byte and pgm->read_byte.
* pgm.h: Add write_byte and read_byte fields to struct programmer_t.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@296 81a1dc3b-b13d-400b-aceb-764788c761c2
available.
* avr910.c (avr910_vfy_cmd_sent): New function.
(avr910_chip_erase): Add support for chip erase.
(avr910_enter_prog_mode): New function.
(avr910_leave_prog_mode): New function.
(avr910_initialize): Add code to select device type and enter prog mode.
(avr910_close): Leave programming mode before closing serial port.
(avr910_read_sig_bytes): New function.
(avr910_initpgm): Add avr910_read_sig_bytes method to pgm initializer.
* avrdude.conf.in: Add note about deprecating devicecode.
Change all occurences of devicecode to stk500_devcode.
Add avr910_devcode to a few parts for testing.
* avrpart.h (struct avrpart): Change devicecode field to stk500_devcode.
(struct avrpart): Add avr910_devcode field.
* config_gram.y: Add K_STK500_DEVCODE and K_AVR910_DEVCODE tokens.
Generate an error if devicecode is found in the config file.
Handle parsing of avr910_devcode and stk500_devcode.
* lexer.l: Handle parsing of avr910_devcode and stk500_devcode.
* pgm.c: Initialize pgm->read_sig_bytes field.
* pgm.h: Add pgm->read_sig_bytes field.
* stk500.c: Use stk500_devcode instead of devicecode.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@293 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
$HOME/.avrduderc. Entries from .avrduderc take precedence over those
from the system wide config file in ${PREFIX}/etc/avrdude.conf.
Track and display the config file name and line number when we print
out the available parts and programmers. This is useful in case
someone has overridden a definition in their .avrduderc file and is
wondering why the definition in the system wide config file is not
being used.
Remove the default programmer 'stk500' from the distributed config
file.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@222 81a1dc3b-b13d-400b-aceb-764788c761c2
programming mode. Use 'retry_pulse' in the per-part specification
that can currently take values of 'reset' or 'sck', the default being
'sck' which preserves the previous behaviour. Some newer parts
indicate that /RESET should be pulsed, while older parts say to pulse
SCK.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@212 81a1dc3b-b13d-400b-aceb-764788c761c2
say whether parts support these programming modes or not. Possible
values for 'serial' are 'yes' or 'no'. Possible values for 'parallel'
are 'yes', 'no', or 'pseudo'. Add a bit mask of flags to the AVRPART
structure to capture these settings. Use these within
stk500_initialize() to set the device parameters correctly.
Defaults for 'serial' and 'parallel' are 'yes' unless specified
otherwise.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@208 81a1dc3b-b13d-400b-aceb-764788c761c2
PAGEL and BS2 signals and the disposition of the reset pin
('dedicated' or 'io').
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@202 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
This change represents a name change only. There is currently an
effort to port AVRPROG to other platforms including Linux and Windows.
Since Atmel's programmer binary that's included within their AVR
Studio software is named AVRPROG.EXE on the Windows OS, there is the
chance for confusion if we keep calling this program AVRPROG as well.
Up until now the name hasn't really been a problem since there was no
chance to confuse 'avrprog' on Unix with Atmel's AVRPROG because
Atmel's tools only run on Windows. But with the Unix 'avrprog'
possibly being ported to Windows, I felt a name change was the best
way to avoid problems.
So - from this point forward, my FreeBSD Unix program formerly known
as AVRPROG will subsequently be known as AVRDUDE (AVR Downloader/UploaDEr).
This change also represents a time when the AVRDUDE sources move from
my own private repository to a public repository. This will give
other developers a chance to port AVRDUDE to other platforms and
extend its functionality to support additional programming hardware,
etc.
So goodbye AVRPROG, welcome AVRDUDE!
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@170 81a1dc3b-b13d-400b-aceb-764788c761c2
"non-paged" parts. Take advantage of that and use the faster internal
routines of the STK500 for those parts as well.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@162 81a1dc3b-b13d-400b-aceb-764788c761c2
supports paged reads and writes. This greatly decreases the
program/verify time from about 4.5 minutes down to about 10 seconds in
a 12K program size test case.
Print out the hardware and firmware version for the STK500 if verbose
is enabled.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@161 81a1dc3b-b13d-400b-aceb-764788c761c2
that programmers other than the direct parallel port connection can be
supported.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@159 81a1dc3b-b13d-400b-aceb-764788c761c2
appeared in version 2.1.0, but was changed to a 4 byte counter in
version 2.1.1. Reminded by Joerg Wunsch.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@150 81a1dc3b-b13d-400b-aceb-764788c761c2
cycle count stored at the end of EEPROM. It seems as though Atmel was
greatly conservative in claiming a 1000 count reliability for the
FLASH. I current have a part that has been reprogrammed 173330 times,
and counting.
Fix a compiler warning.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@144 81a1dc3b-b13d-400b-aceb-764788c761c2
that it is tracked no matter where the erase was initiated: command
line mode or interactive mode, without code duplicaiton.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@141 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
Display the correct memory name in an error message (previously
hardcoded).
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@137 81a1dc3b-b13d-400b-aceb-764788c761c2
Fix setting of status LEDs under various write-fail conditions.
Add a flag to indicate that a memory type requires the device to
possibly be powered off and back on after a write to it. This is due
to a hardware problem on some Atmel devices, see:
http://www.atmel.com/atmel/acrobat/doc1280.pdf
Add greater verbosity to the part-display code when verbose>1 to
display avrprog's encoding of the defined programming instructions.
This is primarily for debugging purposes.
Part updates:
* add the AT90S4414 part
* add fuse and lock bit access instructions for the AT90S1200,
AT90S4434, and AT90S8515.
* add the pwroff_after_write flag to the fuse bits for the AT90S2333
and AT90S4433 parts
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@123 81a1dc3b-b13d-400b-aceb-764788c761c2
Make the BUFF pin a mask like VCC to allow multiple pins to be
asserted at the same time (STK200 has two buffer enable lines).
Add the STK200 programmer.
Fix EEPROM address line selection for several parts.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@109 81a1dc3b-b13d-400b-aceb-764788c761c2
a memory type different than the previous one.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@103 81a1dc3b-b13d-400b-aceb-764788c761c2
used to make the instruction input more readable in the config file.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@102 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
Add support for reading/writing ATMega163 lock and fuse bits.
Unfortunately, in looking at the specs for other ATMega parts, they
use entirely different instruction formats for these commands. Thus,
these routines won't work for the ATMega103, for example.
Add support for sending raw command bytes via the interactive terminal
interface. This allows one to execute any programming instruction on
the target device, whether or not avrprog supports it explicitly or
not. Thus, one can use this feature to program fuse / lock bits, or
access any other feature of a current or future device that avrprog
does not know how to do.
Add in comments, an experimental instruction format in the
configuration file. If this works out, it would allow supporting new
parts and non-orthoganal instructions across existing parts without
making avrprog code changes.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@99 81a1dc3b-b13d-400b-aceb-764788c761c2
Update read/write status more frequently.
Prefix ATMega parts with an 'm'.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@95 81a1dc3b-b13d-400b-aceb-764788c761c2
Rename the poorly chosen name "bank" to "page" for page addressing.
Atmel calls it "page" in their documentation.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@91 81a1dc3b-b13d-400b-aceb-764788c761c2
checking on the memory parameters for parts that do bank addressing.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@88 81a1dc3b-b13d-400b-aceb-764788c761c2
format using a more human-readable format.
Read part descriptions from the config file now instead of hard-coding
them.
Update usage().
Cleanup unused code.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@79 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
bdean
hinni
troth
bsd