1AVRDUDE(1)                BSD General Commands Manual               AVRDUDE(1)
2

NAME

4     avrdude — driver program for ``simple'' Atmel AVR MCU programmer
5

SYNOPSIS

7     avrdude -p partno [-b baudrate] [-B bitclock] [-c programmer-id]
8             [-C config-file] [-D] [-e] [-E exitspec[,exitspec]] [-F]
9             [-i delay] [-n] [-O] [-P port] [-q] [-s] [-t] [-u]
10             [-U memtype:op:filename:filefmt] [-v] [-V] [-y] [-Y]
11

DESCRIPTION

13     Avrdude is a program for downloading code and data to Atmel AVR microcon‐
14     trollers.  Avrdude supports Atmel's STK500 programmer, Atmel's AVRISP and
15     AVRISP mkII devices, Atmel's JTAG ICE (both mkI and mkII, the latter also
16     in ISP mode), programmers complying to AppNote AVR910 and AVR109 (includ‐
17     ing the Butterfly), as well as a simple hard-wired programmer connected
18     directly to a ppi(4) or parport(4) parallel port, or to a standard serial
19     port.  In the simplest case, the hardware consists just of a cable con‐
20     necting the respective AVR signal lines to the parallel port.
21
22     The MCU is programmed in serial programming mode, so, for the ppi(4)
23     based programmer, the MCU signals ‘/RESET’, ‘SCK’, ‘MISO’ and ‘MOSI’ need
24     to be connected to the parallel port.  Optionally, some otherwise unused
25     output pins of the parallel port can be used to supply power for the MCU
26     part, so it is also possible to construct a passive stand-alone program‐
27     ming device.  Some status LEDs indicating the current operating state of
28     the programmer can be connected, and a signal is available to control a
29     buffer/driver IC 74LS367 (or 74HCT367).  The latter can be useful to
30     decouple the parallel port from the MCU when in-system programming is
31     used.
32
33     A number of equally simple bit-bang programming adapters that connect to
34     a serial port are supported as well, among them the popular Ponyprog
35     serial adapter, and the DASA and DASA3 adapters that used to be supported
36     by uisp(1).  Note that these adapters are meant to be attached to a phys‐
37     ical serial port.  Connecting to a serial port emulated on top of USB is
38     likely to not work at all, or to work abysmally slow.
39
40     Atmel's STK500 programmer is also supported and connects to a serial
41     port.  Both, firmware versions 1.x and 2.x can be handled, but require a
42     different programmer type specification (by now).  Using firmware version
43     2, high-voltage programming is also supported, both parallel and serial
44     (programmer types stk500pp and stk500hvsp).
45
46     The simple serial programmer described in Atmel's application note
47     AVR910, and the bootloader described in Atmel's application note AVR109
48     (which is also used by the AVR Butterfly evaluation board), are supported
49     on a serial port.
50
51     Atmel's JTAG ICE (both mkI and mkII) is supported as well to up- or down‐
52     load memory areas from/to an AVR target (no support for on-chip debug‐
53     ging).  For the JTAG ICE mkII, JTAG, debugWire and ISP mode are sup‐
54     ported.  See below for the limitations of debugWire.
55
56     The AVR Dragon is supported in all modes (ISP, JTAG, HVSP, PP, debug‐
57     Wire).  When used in JTAG and debugWire mode, the AVR Dragon behaves sim‐
58     ilar to a JTAG ICE mkII, so all device-specific comments for that device
59     will apply as well.  When used in ISP mode, the AVR Dragon behaves simi‐
60     lar to an AVRISP mkII (or JTAG ICE mkII in ISP mode), so all device-spe‐
61     cific comments will apply there.  In particular, the Dragon starts out
62     with a rather fast ISP clock frequency, so the -B bitclock option might
63     be required to achieve a stable ISP communication.
64
65     The USBasp ISP and USBtinyISP adapters are also supported, provided
66     avrdude has been compiled with libusb support.  They both feature simple
67     firwmare-only USB implementations, running on an ATmega8 (or ATmega88),
68     or ATtiny2313, respectively.
69
70     Input files can be provided, and output files can be written in different
71     file formats, such as raw binary files containing the data to download to
72     the chip, Intel hex format, or Motorola S-record format.  There are a
73     number of tools available to produce those files, like asl(1) as a stand‐
74     alone assembler, or avr-objcopy(1) for the final stage of the GNU
75     toolchain for the AVR microcontroller.
76
77     Avrdude can program the EEPROM and flash ROM memory cells of supported
78     AVR parts.  Where supported by the serial instruction set, fuse bits and
79     lock bits can be programmed as well.  These are implemented within
80     avrdude as separate memory types and can be programmed using data from a
81     file (see the -m option) or from terminal mode (see the dump and write
82     commands).  It is also possible to read the chip (provided it has not
83     been code-protected previously, of course) and store the data in a file.
84     Finally, a ``terminal'' mode is available that allows one to interac‐
85     tively communicate with the MCU, and to display or program individual
86     memory cells.  On the STK500 programmer, several operational parameters
87     (target supply voltage, target Aref voltage, master clock) can be exam‐
88     ined and changed from within terminal mode as well.
89
90   Options
91     In order to control all the different operation modi, a number of options
92     need to be specified to avrdude.
93
94           -p partno
95                   This is the only option that is mandatory for every invoca‐
96                   tion of avrdude.  It specifies the type of the MCU con‐
97                   nected to the programmer.  These are read from the config
98                   file.  If avrdude does not know about a part that you have,
99                   simply add it to the config file (be sure and submit a
100                   patch back to the author so that it can be incorporated for
101                   the next version).  See the sample config file for the for‐
102                   mat.  Currently, the following MCU types are understood:
103
104                   Option tag   Official part name
105                   c128         AT90CAN128
106                   pwm2         AT90PWM2
107                   pwm3         AT90PWM3
108                   1200         AT90S1200
109                   2313         AT90S2313
110                   2333         AT90S2333
111                   2343         AT90S2343 (*)
112                   4414         AT90S4414
113                   4433         AT90S4433
114                   4434         AT90S4434
115                   8515         AT90S8515
116                   8535         AT90S8535
117                   m103         ATmega103
118                   m128         ATmega128
119                   m1280        ATmega1280
120                   m1281        ATmega1281
121                   m16          ATmega16
122                   m161         ATmega161
123                   m162         ATmega162
124                   m163         ATmega163
125                   m164         ATmega164
126                   m169         ATmega169
127                   m2560        ATmega2560 (**)
128                   m2561        ATmega2561 (**)
129                   m32          ATmega32
130                   m324         ATmega324
131                   m329         ATmega329
132
133                   m3290        ATmega3290
134                   m48          ATmega48
135                   m64          ATmega64
136                   m640         ATmega640
137                   m644         ATmega644
138                   m649         ATmega649
139                   m6490        ATmega6490
140                   m8           ATmega8
141                   m8515        ATmega8515
142                   m8535        ATmega8535
143                   m88          ATmega88
144                   t12          ATtiny12
145                   t13          ATtiny13
146                   t15          ATtiny15
147                   t2313        ATtiny2313
148                   t25          ATtiny25
149                   t26          ATtiny26
150                   t45          ATtiny45
151                   t85          ATtiny85
152
153                   (*)    The AT90S2323 and ATtiny22 use the same algorithm.
154
155                   (**)   Flash addressing above 128 KB is not supported by
156                          all programming hardware.  Known to work are jtag2,
157                          stk500v2, and bit-bang programmers.
158
159           -b baudrate
160                   Override the RS-232 connection baud rate specified in the
161                   respective programmer's entry of the configuration file.
162
163           -B bitclock
164                   Specify the bit clock period for the JTAG interface or the
165                   ISP clock (JTAG ICE only).  The value is a floating-point
166                   number in microseconds.  The default value of the JTAG ICE
167                   results in about 1 microsecond bit clock period, suitable
168                   for target MCUs running at 4 MHz clock and above.  Unlike
169                   certain parameters in the STK500, the JTAG ICE resets all
170                   its parameters to default values when the programming soft‐
171                   ware signs off from the ICE, so for MCUs running at lower
172                   clock speeds, this parameter must be specified on the com‐
173                   mand-line.
174
175           -c programmer-id
176                   Use the pin configuration specified by the argument.  Pin
177                   configurations are read from the config file (see the -C
178                   option).  New pin configurations can be easily added or
179                   modified through the use of a config file to make avrdude
180                   work with different programmers as long as the programmer
181                   supports the Atmel AVR serial program method.  You can use
182                   the 'default_programmer' keyword in your ${HOME}/.avrduderc
183                   file to assign a default programmer to keep from having to
184                   specify this option on every invocation.
185
186           -C config-file
187                   Use the specified config file to load configuration data.
188                   This file contains all programmer and part definitions that
189                   avrdude knows about.  If you have a programmer or part that
190                   avrdude does not know about, you can add it to the config
191                   file (be sure and submit a patch back to the author so that
192                   it can be incorporated for the next version).  See the con‐
193                   fig file, located at ${PREFIX}/etc/avrdude/avrdude.conf,
194                   which contains a description of the format.
195
196           -D      Disable auto erase for flash.  When the -U option with
197                   flash memory is specified, avrdude will perform a chip
198                   erase before starting any of the programming operations,
199                   since it generally is a mistake to program the flash with‐
200                   out performing an erase first.  This option disables that.
201
202           -e      Causes a chip erase to be executed.  This will reset the
203                   contents of the flash ROM and EEPROM to the value ‘0xff’,
204                   and is basically a prerequisite command before the flash
205                   ROM can be reprogrammed again.  The only exception would be
206                   if the new contents would exclusively cause bits to be pro‐
207                   grammed from the value ‘1’ to ‘0’.  Note that in order to
208                   reprogram EERPOM cells, no explicit prior chip erase is
209                   required since the MCU provides an auto-erase cycle in that
210                   case before programming the cell.
211
212           -E exitspec[,exitspec]
213                   By default, avrdude leaves the parallel port in the same
214                   state at exit as it has been found at startup.  This option
215                   modifies the state of the ‘/RESET’ and ‘Vcc’ lines the par‐
216                   allel port is left at, according to the exitspec arguments
217                   provided, as follows:
218
219                   reset    The ‘/RESET’ signal will be left activated at pro‐
220                            gram exit, that is it will be held low, in order
221                            to keep the MCU in reset state afterwards.  Note
222                            in particular that the programming algorithm for
223                            the AT90S1200 device mandates that the ‘/RESET’
224                            signal is active before powering up the MCU, so in
225                            case an external power supply is used for this MCU
226                            type, a previous invocation of avrdude with this
227                            option specified is one of the possible ways to
228                            guarantee this condition.
229
230                   noreset  The ‘/RESET’ line will be deactivated at program
231                            exit, thus allowing the MCU target program to run
232                            while the programming hardware remains connected.
233
234                   vcc      This option will leave those parallel port pins
235                            active (i. e. high) that can be used to supply
236                            ‘Vcc’ power to the MCU.
237
238                   novcc    This option will pull the ‘Vcc’ pins of the paral‐
239                            lel port down at program exit.
240
241                   Multiple exitspec arguments can be separated with commas.
242
243           -F      Normally, avrdude tries to verify that the device signature
244                   read from the part is reasonable before continuing.  Since
245                   it can happen from time to time that a device has a broken
246                   (erased or overwritten) device signature but is otherwise
247                   operating normally, this options is provided to override
248                   the check.
249
250           -i delay
251                   For bitbang-type programmers, delay for approximately delay
252                   microseconds between each bit state change.  If the host
253                   system is very fast, or the target runs off a slow clock
254                   (like a 32 kHz crystal, or the 128 kHz internal RC oscilla‐
255                   tor), this can become necessary to satisfy the requirement
256                   that the ISP clock frequency must not be higher than 1/4 of
257                   the CPU clock frequency.  This is implemented as a spin-
258                   loop delay to allow even for very short delays.  On Unix-
259                   style operating systems, the spin loop is initially cali‐
260                   brated against a system timer, so the number of microsec‐
261                   onds might be rather realistic, assuming a constant system
262                   load while avrdude is running.  On Win32 operating systems,
263                   a preconfigured number of cycles per microsecond is assumed
264                   that might be off a bit for very fast or very slow
265                   machines.
266
267           -n      No-write - disables actually writing data to the MCU (use‐
268                   ful for debugging avrdude ).
269
270           -O      Perform a RC oscillator run-time calibration according to
271                   Atmel application note AVR053.  This is only supported on
272                   the STK500v2, AVRISP mkII, and JTAG ICE mkII hardware.
273                   Note that the result will be stored in the EEPROM cell at
274                   address 0.
275
276           -P port
277                   Use port to identify the device to which the programmer is
278                   attached.  By default the /dev/ppi0 port is used, but if
279                   the programmer type normally connects to the serial port,
280                   the /dev/cuaa0 port is the default.  If you need to use a
281                   different parallel or serial port, use this option to spec‐
282                   ify the alternate port name.
283
284                   For the JTAG ICE mkII, if avrdude has been configured with
285                   libusb support, port can alternatively be specified as
286                   usb[:serialno].  This will cause avrdude to search a JTAG
287                   ICE mkII on USB.  If serialno is also specified, it will be
288                   matched against the serial number read from any JTAG ICE
289                   mkII found on USB.  The match is done after stripping any
290                   existing colons from the given serial number, and right-to-
291                   left, so only the least significant bytes from the serial
292                   number need to be given.
293
294                   As the AVRISP mkII device can only be talked to over USB,
295                   the very same method of specifying the port is required
296                   there.
297
298                   For the USB programmer "AVR-Doper" running in HID mode, the
299                   port must be specified as avrdoper. Libusb support is
300                   required on Unix but not on Windows. For more information
301                   about AVR-Doper see http://www.obdev.at/avrusb/avr
302                   doper.html.
303
304                   For programmers that attach to a serial port using some
305                   kind of higher level protocol (as opposed to bit-bang style
306                   programmers), port can be specified as net:host:port.  In
307                   this case, instead of trying to open a local device, a TCP
308                   network connection to (TCP) port on host is established.
309                   The remote endpoint is assumed to be a terminal or console
310                   server that connects the network stream to a local serial
311                   port where the actual programmer has been attached to.  The
312                   port is assumed to be properly configured, for example
313                   using a transparent 8-bit data connection without parity at
314                   115200 Baud for a STK500.  This feature is currently not
315                   implemented for Win32 systems.
316
317           -q      Disable (or quell) output of the progress bar while reading
318                   or writing to the device.  Specify it a second time for
319                   even quieter operation.
320
321           -s      Disable safemode prompting.  When safemode discovers that
322                   one or more fuse bits have unintentionally changed, it will
323                   prompt for confirmation regarding whether or not it should
324                   attempt to recover the fuse bit(s).  Specifying this flag
325                   disables the prompt and assumes that the fuse bit(s) should
326                   be recovered without asking for confirmation first.
327
328           -t      Tells avrdude to enter the interactive ``terminal'' mode
329                   instead of up- or downloading files.  See below for a
330                   detailed description of the terminal mode.
331
332           -u      Disable the safemode fuse bit checks.  Safemode is enabled
333                   by default and is intended to prevent unintentional fuse
334                   bit changes.  When enabled, safemode will issue a warning
335                   if the any fuse bits are found to be different at program
336                   exit than they were when avrdude was invoked.  Safemode
337                   won't alter fuse bits itself, but rather will prompt for
338                   instructions, unless the terminal is non-interactive, in
339                   which case safemode is disabled.  See the -s option to dis‐
340                   able safemode prompting.
341
342           -U memtype:op:filename[:format]
343                   Perform a memory operation as indicated.  The memtype field
344                   specifies the memory type to operate on.  The available
345                   memory types are device-dependent, the actual configuration
346                   can be viewed with the part command in terminal mode.  Typ‐
347                   ically, a device's memory configuration at least contains
348                   the memory types flash and eeprom.  All memory types cur‐
349                   rently known are:
350                   calibration  One or more bytes of RC oscillator calibration
351                                data.
352                   eeprom       The EEPROM of the device.
353                   efuse        The extended fuse byte.
354                   flash        The flash ROM of the device.
355                   fuse         The fuse byte in devices that have only a sin‐
356                                gle fuse byte.
357                   hfuse        The high fuse byte.
358                   lfuse        The low fuse byte.
359                   lock         The lock byte.
360                   signature    The three device signature bytes (device ID).
361
362                   The op field specifies what operation to perform:
363
364                   r        read device memory and write to the specified file
365
366                   w        read data from the specified file and write to the
367                            device memory
368
369                   v        read data from both the device and the specified
370                            file and perform a verify
371
372                   The filename field indicates the name of the file to read
373                   or write.  The format field is optional and contains the
374                   format of the file to read or write.  Format can be one of:
375
376                   i    Intel Hex
377
378                   s    Motorola S-record
379
380                   r    raw binary; little-endian byte order, in the case of
381                        the flash ROM data
382
383                   m    immediate; actual byte values specified on the command
384                        line, separated by commas or spaces.  This is good for
385                        programming fuse bytes without having to create a sin‐
386                        gle-byte file or enter terminal mode.
387
388                   a    auto detect; valid for input only, and only if the
389                        input is not provided at stdin.
390
391                   d    decimal; this and the following formats are only valid
392                        on output.  They generate one line of output for the
393                        respective memory section, forming a comma-separated
394                        list of the values.  This can be particularly useful
395                        for subsequent processing, like for fuse bit settings.
396
397                   h    hexadecimal; each value will get the string 0x
398                        prepended.
399
400                   o    octal; each value will get a 0 prepended unless it is
401                        less than 8 in which case it gets no prefix.
402
403                   b    binary; each value will get the string 0b prepended.
404
405                   The default is to use auto detection for input files, and
406                   raw binary format for output files.  Note that if filename
407                   contains a colon, the format field is no longer optional
408                   since the filename part following the colon would otherwise
409                   be misinterpreted as format.
410
411                   As an abbreviation, the form -U filename is equivalent to
412                   specifying -U flash:w:filename:a.  This will only work if
413                   filename does not have a colon in it.
414
415           -v      Enable verbose output.
416
417           -V      Disable automatic verify check when uploading data.
418
419           -y      Tells avrdude to use the last four bytes of the connected
420                   parts' EEPROM memory to track the number of times the
421                   device has been erased.  When this option is used and the
422                   -e flag is specified to generate a chip erase, the previous
423                   counter will be saved before the chip erase, it is then
424                   incremented, and written back after the erase cycle com‐
425                   pletes.  Presumably, the device would only be erased just
426                   before being programmed, and thus, this can be utilized to
427                   give an indication of how many erase-rewrite cycles the
428                   part has undergone.  Since the FLASH memory can only endure
429                   a finite number of erase-rewrite cycles, one can use this
430                   option to track when a part is nearing the limit.  The typ‐
431                   ical limit for Atmel AVR FLASH is 1000 cycles.  Of course,
432                   if the application needs the last four bytes of EEPROM mem‐
433                   ory, this option should not be used.
434
435           -Y cycles
436                   Instructs avrdude to initialize the erase-rewrite cycle
437                   counter residing at the last four bytes of EEPROM memory to
438                   the specified value.  If the application needs the last
439                   four bytes of EEPROM memory, this option should not be
440                   used.
441
442   Terminal mode
443     In this mode, avrdude only initializes communication with the MCU, and
444     then awaits user commands on standard input.  Commands and parameters may
445     be abbreviated to the shortest unambiguous form.  Terminal mode provides
446     a command history using readline(3), so previously entered command lines
447     can be recalled and edited.  The following commands are currently imple‐
448     mented:
449
450           dump memtype addr nbytes
451                   Read nbytes bytes from the specified memory area, and dis‐
452                   play them in the usual hexadecimal and ASCII form.
453
454           dump    Continue dumping the memory contents for another nbytes
455                   where the previous dump command left off.
456
457           write memtype addr byte1 ... byteN
458                   Manually program the respective memory cells, starting at
459                   address addr, using the values byte1 through byteN.  This
460                   feature is not implemented for bank-addressed memories such
461                   as the flash memory of ATMega devices.
462
463           erase   Perform a chip erase.
464
465           send b1 b2 b3 b4
466                   Send raw instruction codes to the AVR device.  If you need
467                   access to a feature of an AVR part that is not directly
468                   supported by avrdude, this command allows you to use it,
469                   even though avrdude does not implement the command.
470
471           sig     Display the device signature bytes.
472
473           part    Display the current part settings and parameters.  Includes
474                   chip specific information including all memory types sup‐
475                   ported by the device, read/write timing, etc.
476
477           vtarg voltage
478                   Set the target's supply voltage to voltage Volts.  Only
479                   supported on the STK500 programmer.
480
481           varef voltage
482                   Set the adjustable voltage source to voltage Volts.  This
483                   voltage is normally used to drive the target's Aref input
484                   on the STK500.  Only supported on the STK500 programmer.
485
486           fosc freq[M|k]
487                   Set the master oscillator to freq Hz.  An optional trailing
488                   letter M multiplies by 1E6, a trailing letter k by 1E3.
489                   Only supported on the STK500 programmer.
490
491           fosc off
492                   Turn the master oscillator off.  Only supported on the
493                   STK500 programmer.
494
495           sck period
496                   STK500 programmer only: Set the SCK clock period to period
497                   microseconds.
498
499                   JTAG ICE only: Set the JTAG ICE bit clock period to period
500                   microseconds.  Note that unlike STK500 settings, this set‐
501                   ting will be reverted to its default value (approximately 1
502                   microsecond) when the programming software signs off from
503                   the JTAG ICE.  This parameter can also be used on the JTAG
504                   ICE mkII to specify the ISP clock period when operating the
505                   ICE in ISP mode.
506
507           parms   STK500 programmer only: Display the current voltage and
508                   master oscillator parameters.
509
510                   JTAG ICE only: Display the current target supply voltage
511                   and JTAG bit clock rate/period.
512
513           ?
514
515           help    Give a short on-line summary of the available commands.
516
517           quit    Leave terminal mode and thus avrdude.
518
519   Default Parallel port pin connections
520     (these can be changed, see the -c option)
521     Pin number   Function
522     2-5          Vcc (optional power supply to MCU)
523     7            /RESET (to MCU)
524     8            SCK (to MCU)
525     9            MOSI (to MCU)
526     10           MISO (from MCU)
527     18-25        GND
528
529   debugWire limitations
530     The debugWire protocol is Atmel's proprietary one-wire (plus ground) pro‐
531     tocol to allow an in-circuit emulation of the smaller AVR devices, using
532     the ‘/RESET’ line.  DebugWire mode is initiated by activating the ‘DWEN’
533     fuse, and then power-cycling the target.  While this mode is mainly
534     intented for debugging/emulation, it also offers limited programming
535     capabilities.  Effectively, the only memory areas that can be read or
536     programmed in this mode are flash ROM and EEPROM.  It is also possible to
537     read out the signature.  All other memory areas cannot be accessed.
538     There is no chip erase functionality in debugWire mode; instead, while
539     reprogramming the flash ROM, each flash ROM page is erased right before
540     updating it.  This is done transparently by the JTAG ICE mkII (or AVR
541     Dragon).  The only way back from debugWire mode is to initiate a special
542     sequence of commands to the JTAG ICE mkII (or AVR Dragon), so the debug‐
543     Wire mode will be temporarily disabled, and the target can be accessed
544     using normal ISP programming.  This sequence is automatically initiated
545     by using the JTAG ICE mkII or AVR Dragon in ISP mode, when they detect
546     that ISP mode cannot be entered.
547

FILES

549           /dev/ppi0     default device to be used for communication with the
550                         programming hardware
551
552           ${PREFIX}/etc/avrdude/avrdude.conf
553                         programmer and parts configuration file
554
555           ${HOME}/.avrduderc
556                         programmer and parts configuration file (per-user
557                         overrides)
558
559           ~/.inputrc    Initialization file for the readline(3) library
560
561           ${PREFIX}/share/doc/avrdude/avrdude.pdf
562                         Schematic of programming hardware
563

DIAGNOSTICS

565     avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED
566     avrdude: jtagmkII_getsync(): ISP activation failed, trying debugWire
567     avrdude: Target prepared for ISP, signed off.
568     avrdude: Please restart avrdude without power-cycling the target.
569
570     If the target AVR has been set up for debugWire mode (i. e. the DWEN fuse
571     is programmed), normal ISP connection attempts will fail as the /RESET
572     pin is not available.  When using the JTAG ICE mkII in ISP mode, the mes‐
573     sage shown indicates that avrdude has guessed this condition, and tried
574     to initiate a debugWire reset to the target.  When successful, this will
575     leave the target AVR in a state where it can respond to normal ISP commu‐
576     nication again (until the next power cycle).  Typically, the same command
577     is going to be retried again immediately afterwards, and will then suc‐
578     ceed connecting to the target using normal ISP communication.
579

SEE ALSO

581     avr-objcopy(1), ppi(4), readline(3)
582
583     The AVR microcontroller product description can be found at
584
585           http://www.atmel.com/products/AVR/
586

AUTHORS

588     Avrdude was written by Brian S. Dean <bsd@bsdhome.com>.
589
590     This man page by Joerg Wunsch.
591

BUGS

593     Please report bugs via
594           http://savannah.nongnu.org/bugs/?group=avrdude.
595
596     The JTAG ICE programmers currently cannot write to the flash ROM one byte
597     at a time.  For that reason, updating the flash ROM from terminal mode
598     does not work.
599
600     Page-mode programming the EEPROM through JTAG (i.e. through an -U option)
601     requires a prior chip erase.  This is an inherent feature of the way JTAG
602     EEPROM programming works.  This also applies to the STK500 in parallel
603     programming mode.
604
605     The USBasp and USBtinyISP drivers do not offer any option to distinguish
606     multiple devices connected simultaneously, so effectively only a single
607     device is supported.
608
609BSD                              June 22, 2019                             BSD
Impressum