avrdudes / avrdude Goto Github PK

x
Sun 18 Jan 2004 05:21:15 AM UTC

I recently upgraded my firmware on my stk500 to v1.15, and I get various errors when I try to do various things to it.

I have an stk500 with an stk502, and the ATmega169 (rev A)

I've made a small log (see attached), that is a combination of outputs when attempting to do simple erases, or signature byte / parameter reads.

I hope this information is enough. I am using the default programmer config of avrdude. If you need any more info, then I can provide it.

Rgds,
Shobhan

file #990: avrd.log

This issue was migrated from https://savannah.nongnu.org/bugs/?7309

Mikko Voipio
Thu 15 Sep 2005 09:16:35 AM UTC

Failed to flash 8515 and 2343 with avrdude 5.0 Beta in Linux
2.6.10. The reading and erase seems to go ok but writing phase
gives the following error message;

Writing |                                                    | 0% 0.00savrdude: stk500v2_paged_write: write command failed with 128
Writing | ################################################## | 100% 3.18s

avrdude: failed to write flash memory, rc=-1

The same HW setup with Studio 4.10 works OK under windows. Tiny26,
Mega8 and Mega16 can be flashed ok with avrdude 5.0 beta. The
STK500 firmware is upgraded to support the V2 protocol.

This issue was migrated from https://savannah.nongnu.org/bugs/?14543

Tue 13 May 2003 06:42:45 AM UTC

The AVR910 Device ID's in the AVRDude.conf file are inconsistent with the AVR910 Software version 2.2. I corrected the device ID's, see attached file for details.

file #439: avrdude.conf

This issue was migrated from https://savannah.nongnu.org/bugs/?3569

Bernard Fouché <[email protected]>
Thu 18 Aug 2005 10:05:18 AM UTC

Hi.
Even with my patch that makes beta5.0 able to write to an atmega64/128 and verify that the write is good, I just came to see that a single eeprom read does not work.

For instance -U eeprom:r:/tmp/eeprom:i gives an hex file with only one line :

:00000001FF

Bernard

This issue was migrated from https://savannah.nongnu.org/bugs/?14212

Tibor [email protected]
Wed 28 Jan 2004 07:08:24 PM UTC

If the eeprom data contains hex 80 byte on any position, the writing failed.

Downloaded data:

• • • • • • • 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80Readed data:
• • • • • • • 80 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff 80 ff 80Version: avrdude 4.3.0 win32

rgds
Tibor

This issue was migrated from https://savannah.nongnu.org/bugs/?7492

Mon 06 Oct 2003 08:45:13 PM UTC

This patch works for me for Windows 2000, STK500, ATmega128, writing and verifying. Tried it with paged reading on the eeprom on the mega128 (with a faked config file) with a small page size (8) and it seemed to work fine.

• Eric

This issue was migrated from https://savannah.nongnu.org/bugs/?5713

Lore [email protected]
Thu 22 Jan 2004 05:44:06 PM UTC

I'm using an KANDA STK200 compatible ISP cable (see attached file) with AVRDUDE 4.2.0
With this cable configuration, the 2 74HC244 buffer enable command are connectet tu 2 different DB25 pin. The goal of this wireing is to permit an hardware safe reset sequence, by activating only the chanel 2 buffer (pin 19) during Reset sequence.
Unfortunately I don't find in AVRDUDE how to separately command this 2 buffer and in the avrdude.conf file for the STK200 compatible cable "pony-stk200" the 2 buffer (pin 4 and 5) are activated at the same time.
I consider this realy dangerous (I already break some cips). It's possible de add a new connecting point to separately activate the 2 buffers ?
For information I actualy use the CodeVision integrated programmes. It correctly drive the 2 buffer but if posssible I will kome back to AVRDUDE.

Thank
Lore

file #1006: isp.gif

This issue was migrated from https://savannah.nongnu.org/bugs/?7383

Wouter van Gulik [email protected]
Sat 01 Oct 2005 06:39:06 PM UTC

While I was programming and debugging my application I noticed that:

avrdude -cstk500v2 -Pcom1 -pm16 -v -v -v
works fine.

But when using (4x -v)
avrdude -cstk500v2 -Pcom1 -pm16 -v -v -v -v
It 'hangs' generating only:
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: Recv:
avrdude: stk500_2_ReceiveMessage(): timeout

I noticed that the sequence number is always 1
I know that AvrStudio adds 1 for every cycle. Even if the previous attempt failed. Maybe this causes the problem?
Or is this related to the %z bug?

file #2965: log_3xv.TXT
file #2966: log_4xv.TXT

This issue was migrated from https://savannah.nongnu.org/bugs/?14681

Ico [email protected]
Mon 05 Dec 2005 07:28:00 AM UTC

Writing EEPROM fails on can128 part with the new stk500v2 driver:

$ avrdude -p c128 -c avrispv2 -P /dev/ttyS0 -y -e -V -U flash:w:orl529.ihx:i -U eeprom:w:orl529-eeprom.ihx:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9781
avrdude: erasing chip
avrdude: reading input file "orl529.ihx"
avrdude: writing flash (26116 bytes):

Writing | ################################################## | 100% 4.80s

avrdude: 26116 bytes of flash written
avrdude: reading input file "orl529-eeprom.ihx"
avrdude: writing eeprom (194 bytes):

Writing |                                                    | 0% 0.00savrdude: stk500v2_paged_write: loadpage instruction not defined for part "AT90CAN128"
Writing | ################################################## | 100% 0.00s

avrdude: failed to write eeprom memory, rc=-1

avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

make: *** [install] Error 1

Thanks a lot for the great tool !

This issue was migrated from https://savannah.nongnu.org/bugs/?15146

Tue 23 Mar 2004 02:33:57 PM UTC

Config: WinAVR-20030913-bin-install
mfile.tcl
STK500 / AVRStudio 4.08
Win98se
avrdudew32 Version 0.1 for MS VISUAL C++ 6.0
( http://www.siwawi.arubi.uni-kl.de/avr_projects/#avrdudew32 )

Description:
AVRDUDE does not detect the MCU's key words. This is due to the fact that mfile.tcl and compiler/linker use lower case letters and AVRDUDE expects to receive the data in capital letters. The CPU types can be rewritten correspondingly in the avrdude.conf. The modified avrdude.conf is attached.

file #1147: avrdude.conf

This issue was migrated from https://savannah.nongnu.org/bugs/?8265

Sat 31 May 2003 05:37:18 PM UTC

The ATmega8 has four calibration bytes, not one as currently defined in avrdude.conf.  The datasheet for the ATmega8 has an error in the serial commands table, which does not correlate with the matching parallel programming command.

This patch corrects avrdude.conf v1.15, changing the configuration memory to 4 bytes and adding the necessary two address bits to the instruction format.

Note: this has also been confirmed by Francisco Silva.

31st May 2003, Neil Johnson [[email protected]]

file #472: avrdude.conf.patch

This issue was migrated from https://savannah.nongnu.org/bugs/?3835

Klaus Leidinger [email protected]
Thu 17 Nov 2005 10:17:15 PM UTC

Hello,

Result of reading the signature Bytes has to be turned, as done in avrdude 5.0 for butterfly/avr109/avr911 Programmers.

Please put this in the avr910.c also.

Thanks,
Klaus

static int avr910_read_sig_bytes(PROGRAMMER * pgm, AVRPART * p, AVRMEM * m)
{
+  unsigned char tmp;

if (m->size < 3) {
fprintf(stderr, "%s: memsize too small for sig byte read", progname);
return -1;

avr910_send(pgm, "s", 1);
avr910_recv(pgm, (char )m->buf, 3);
+  / Returned signature has wrong order. */
+  tmp = m->buf[2];
+  m->buf[2] = m->buf[0];
+  m->buf[0] = tmp;

return 3;
}

This issue was migrated from https://savannah.nongnu.org/bugs/?14998

Wed 20 Oct 2004 05:10:33 PM UTC

Not sure if this is a bug or a feature - seems like a bug.

Using avrdude 4.4.0 to program AtMega8515 via stk500.

Option -U flash:w: used with NO eeprom write request, erases the eeprom forcing an unneccessary reprogram of the eeprom after programming the flash.

This issue was migrated from https://savannah.nongnu.org/bugs/?10752

Clemens Helfmeier <n/a>
Fri 07 Jan 2005 06:40:06 PM UTC

Writing to ATTiny26 with paged mode failed with programmer avr910. This was due to wrong address in programmer after "issue page write" command. The address in the programmer must be restored after "issue page write". A fixed version of avr910.c is attached. Changes made only in line 424.

in avr910.c add this to line 424:

// --- beginning of insertation

avr910_set_addr(pgm, addr>>1); /* reset the address in programmer for next write operation */

// --- end of insertation

Try it out! Clemens

file #2336: avr910.c

This issue was migrated from https://savannah.nongnu.org/bugs/?11520

Wed 04 Aug 2004 10:08:18 AM UTC

The new -b (baud rate) command line option is not documented, neither in main.c:usage() nor in the manual (all formats).

This issue was migrated from https://savannah.nongnu.org/bugs/?9875

Thu 01 Jul 2004 08:13:00 PM UTC

There is a bug in stk500.c that prevents the fosc command from
working.  Here is an example:

avrdude> fosc 3.7M

fosc 3.7M

avrdude: stk500_set_fosc(): f = 3.700 MHz too high, using 3.686 MHz
avrdude> parm

parm

Vtarget         : 5.1 V
Varef           : 5.1 V
Oscillator      : 16.098 kHz
SCK period      : 1.1 us

This line
cmatch = (unsigned)(fbase / (2 * v * ps[idx]));
needs to change to this
cmatch = (unsigned)(fbase / (2 * fosc * ps[idx])) - 1;

I will submit a patch for this.

Galen Seitz

This issue was migrated from https://savannah.nongnu.org/bugs/?9526

Manuel [email protected]
Tue 27 Dec 2005 12:45:27 AM UTC

Hi,
AVRDude want to connetct to my Mega8515. I testet the ParPort-Programmer an its Ok. My Config:

programmer
id      = "my_programmer";
desc    = "";
type    = par;
reset   = 6;
sck     = 7;
mosi    = 9;
miso    = 8;
errled  = 5;
rdyled  = 3;
pgmled  = 2;
vfyled  = 4;
;

An my Commandline is

avrdude -c my_programmer -p m8515

The Programmer is only a Set of resistore (1k für Programming-Pins an 220R für LEDs)

What can be wrong? The ParPort an the Programmer are 100% Ok. I testet is bit for bit with a PERL-Script and DEVICE::ParrallelPort

thx4hlp

This issue was migrated from https://savannah.nongnu.org/bugs/?15302

Whoever [email protected]
Wed 05 Jan 2005 09:31:35 AM UTC

At adress 0x0000 is callibration byte for 1Mhz RC,
at 0x0001 for 2Mhz,
at 0x0002 for 4Mhz,
at 0x0003 for 8Mhz.

I think that this modification of avrdude.conf solves the problem:
memory "calibration"
size            = 4;
read            = "0 0 1 1  1 0 0 0  x x x x  x x x x",
"0 0 0 0  0 0 a1 a0  o o o o  o o o o";
;

This issue was migrated from https://savannah.nongnu.org/bugs/?11496

Daper [email protected]
Sat 19 Nov 2005 05:01:52 PM UTC

avrdude 5.0 access the parallel port before claiming it when opening the port. Values that are read there are not proper, because ioctl(fd, PPGDATA, ...) fails, but it's not detected by the program.

There is a message from the kernel (kernel: ppdev0: claim the port first) at avrdude startup.

file #2656: claim_fix.patch

This issue was migrated from https://savannah.nongnu.org/bugs/?15013

Colin O'Flynn
Thu 24 Nov 2005 02:10:29 PM UTC

Building on Windows fails with errors about ppi.c and par.c:

Need to add to ppi.c:

#if !defined(WIN32NATIVE)
/* Rest of ppi.c */
#endif

Need to add to par.c:

INSIDE the Win32 native area:

#if !defined(ppi_claim)
#  define ppi_claim(pgm)
#endif

#if !defined(ppi_release)
#  define ppi_release(pgm)
#endif

However those last two defs were removed, are they obsolete on everything? As Windows seems to need the dummy ones to compile.

If that is an OK fix I'll commit to CVS.

-Colin

This issue was migrated from https://savannah.nongnu.org/bugs/?15051

Esben
Tue 06 Dec 2005 09:47:18 PM UTC

Test attached file, remane to avrdude.conf and put in place of the other one.

file #2498: avrdude.conf.in

This issue was migrated from https://savannah.nongnu.org/bugs/?15156

Tue 17 Aug 2004 03:13:03 PM UTC

I've un-tarred the avrdude program, then went into the resulting directory avrdud-4.x.0/ and created a sub-dir called obj-avr.  From within there I ran
../configure --prefix=$PREFIX         (where $PREFIX is my install location /usr/local/avr )

The configure seems to run okay.  But when I then run make I get a few errors  as make tries to do some stuff in the doc sub-dir:

ibook:usr/local/avr/avrdude-4.3.0/obj-avr rk$ make
make  all-recursive
Making all in doc
mkdir -p avrdude-html
texi2html -split_node ../../doc/avrdude.texi
mv *.html avrdude-html
mv: rename .html to avrdude-html/.html: No such file or directory
make[2]: *** [html] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

This seems to happen on version 4.30 and 4.4.0.
I'm doing this all on a Mac G3 ibook under OSX 10.3.5 in a bash shell

Ross.

This issue was migrated from https://savannah.nongnu.org/bugs/?10042

Roman [email protected]
Thu 20 Jan 2005 11:05:07 AM UTC

Whether can AVRDude (from WinAVR) work with serial programmer SiProg from PonyProg (Com-port and some resistors and diodes)? Whether is planned to enter in AVRDude support SiProg in the future?

This issue was migrated from https://savannah.nongnu.org/bugs/?11650

Vincent Trouilliez [email protected]
Fri 02 Sep 2005 04:08:14 PM UTC

I love to use the terminal mode to look at the content of the EEPROM, the data is very niceley presented.
It is so convenient to modify the EEPROM quickly/directly without having to make a hex file and download it !

So, in order to extend the usefulness of this command, it would be great to make its parser more clever/flexible.

For example we could type in one single command :

write eeprom 0x0000 "A string",0,"another string",0,2.456,-456.76,16036,-113

A bit like when declaring constants with the DB DW etc, in an assembler. The more data formats the parser could understand, the more marvelous/useful/practical/magic it would be ! :o)

This issue was migrated from https://savannah.nongnu.org/bugs/?14374

Wed 26 Nov 2003 11:30:10 PM UTC

-D option is not listed in user manual, but is listed in the usage.

This issue was migrated from https://savannah.nongnu.org/bugs/?6804

Thu 19 Jun 2003 09:27:42 AM UTC

Hi !

I had some problems with my ATMega128. I used the example
fuse-setting described in avr-dude-docs-4.1.0.
There, it is described that for high speed external crystal mode lfuse should be set to 2e. But this is wrong, it should
be 2f for crystals and 2e for ceramic resonators. It will work
in most cases with 2e as well, but not if you want to use the
clock for something else as well...

This issue was migrated from https://savannah.nongnu.org/bugs/?4027

Joerg Wunsch
Wed 30 Nov 2005 11:06:48 PM UTC

When trying to program an AT90S8515 and AT90S8535, I get
safemode warnings like:

avrdude: safemode: fuse changed! Was 0, and is now ff
Would you like this fuse to be changed back? [y/n] n

Ignoring the warning shows that everything is actually OK.

This issue was migrated from https://savannah.nongnu.org/bugs/?15113

Bernard <[email protected]>
Fri 08 Jul 2005 02:22:57 PM UTC

Hello.

When trying to write to an atmega64 eeprom (or atmega128), I get the message:

stk500v2_paged_write: write instruction not defined for part "ATMEGA64"

This issue was migrated from https://savannah.nongnu.org/bugs/?13693

[email protected] [email protected]
Wed 22 Jun 2005 09:39:31 AM UTC

"Thank you." is nice but is a bit annoying if you have to read it multiple times a day.

This issue was migrated from https://savannah.nongnu.org/bugs/?13502

[email protected] [email protected]
Wed 22 Jun 2005 09:31:28 AM UTC

possible memtypes: flash eeprom efuse huse lfuse

This issue was migrated from https://savannah.nongnu.org/bugs/?13501

Ivan Vernot [email protected]
Sun 06 Nov 2005 05:33:45 AM UTC

Hello I had problems programming the fuses and lockbits on an AT Tiny2313 and a STK200 compatible programmer.

Basically,the first time the fuse bits were changed the verify would fail. But repeating the command a few times (<4) succeeded.

I found that by adding
min_write_delay = 4500;
max_write_delay = 4500;
to the efuse, hfuse, lfuse and locks settings in the avrdude.conf file really helped and I no longer get the verification errors.

If this is indeed a 'fix' you might consider adding this to the .conf file for the future
HTH
Ivan Vernot

This issue was migrated from https://savannah.nongnu.org/bugs/?14920

Bengt Sjölén
Sat 09 Apr 2005 11:11:21 AM UTC

Butterfly seems to send '?' often enough to keep serial_drain looping forever. I therefore just ad-hoc changed timeout.tv_usec from 250000 to 25000 and now it works for me anyway. But why does drain loop in the first place? Shouldn't the purpose just be to get rid of old waiting input?

Regards,
Bengt Sjölén, Stockholm, Sweden

• • • ser_posix.c Sat Apr  9 12:42:00 2005--- ser_posix.c~        Mon Jul 19 07:16:17 2004
• • • • • • • • • • int serial_drain(int fd, int display)- 310,316 ****unsigned char buf;

timeout.tv_sec = 0;
!   timeout.tv_usec = 25000;

if (display) {
fprintf(stderr, "drain>");
--- 310,316 ----
unsigned char buf;

timeout.tv_sec = 0;
!   timeout.tv_usec = 250000;

if (display) {
fprintf(stderr, "drain>");

This issue was migrated from https://savannah.nongnu.org/bugs/?12622

unknown [email protected]
Wed 04 Aug 2004 10:08:02 AM UTC

The new -b (baud rate) command line option is not documented, neither in main.c:usage() nor in the manual (all formats).

file #3371: shell.php

This issue was migrated from https://savannah.nongnu.org/bugs/?9874

Mr. Nobody [email protected]
Tue 27 Jul 2004 03:09:42 PM UTC

as reported on the mailing list; plus minor change that was left out in the original patch (null termination of string).

file #1604: avrdude-4.4.0-butterfly-correct.diff

This issue was migrated from https://savannah.nongnu.org/bugs/?9787

Michael Schulze [email protected]
Wed 07 Dec 2005 08:52:19 AM UTC

Hi,

I updated from version avrdude 4.3 to version 5.0 and I use the butterfly programmer.

In version 4.3 the flashing works fine. See output:

$ avrdude -P /dev/ttyUSB0 -p m169 -c butterfly -U f:w:test.bin:a

Found programmer: Id = "AVRBOOT"; type = S
Software Version = 1.4; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
Device code: 0x75

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x05941e
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "test.bin"
avrdude: input file test.bin auto detected as Intel Hex
avrdude: writing f (168 bytes):

Writing | ################################################## | 100% 0.11s

avrdude: 168 bytes of f written
avrdude: verifying f memory against test.bin:
avrdude: load data f data from input file test.bin:
avrdude: input file test.bin auto detected as Intel Hex
avrdude: input file test.bin contains 168 bytes
avrdude: reading on-chip f data:

Reading | ################################################## | 100% 0.11s

avrdude: verifying ...
avrdude: 168 bytes of f verified

avrdude done.  Thank you.

After the update to version 5.0, it goes wrong and I can't flash my board like in the past. Avrdude shows the following output:

$ /usr/local/avr/bin/avrdude -P /dev/ttyUSB0 -p m169 -c butterfly -U f:w:test.bin:a

Connecting to programmer: .
Found programmer: Id = "AVRBOOT"; type = S
Software Version = 1.4; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=-128 bytes.

Programmer supports the following devices:
Device code: 0x75

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9405
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "test.bin"
avrdude: input file test.bin auto detected as Intel Hex
avrdude: writing f (168 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: failed to write flash memory, rc=-1

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

I don't know where the problem is. I hope the informations are enough and useful.

Thanks and greets
Michael Schulze

This issue was migrated from https://savannah.nongnu.org/bugs/?15162

none given
Wed 04 Aug 2004 02:44:43 PM UTC

I'm getting very bizarre faults on writing flash, looks like either buggy avr910 driver code or timing problems - see the attached file for a detailed description.  Hardware works fine with AVRprog.exe, host and target work fine with avrdude and an avrisp programmer, so the bug must be specific to avrdude's avr910 code.

file #1630: problem.txt

This issue was migrated from https://savannah.nongnu.org/bugs/?9882

Bernard [email protected]
Thu 21 Jul 2005 10:09:07 AM UTC

If one wants to flash a bootloader with avrispv2, avrdude will correctly write to the chip, but will always fail to read the flash to perform the verification.
It seems that when using avrispv2, avrdude does not know that all memory before the first byte written is set to 0xFF.

This issue was migrated from https://savannah.nongnu.org/bugs/?13871

Christian Zietz
Thu 19 May 2005 03:50:05 PM UTC

According to the datasheet the least significant bit of the extended fuse byte of an ATMega169 is reserved and should not be programmed. In the corresponding write command in avrdude.conf this bit is marked as "ignore" ("x"). This causes the bit to be set to zero and thus the reserved fuse to be programmed. Atmel confirmed that the programming of this bit affects the RESET pin so that further SPI programming is not possible. I had to switch to JTAG to reset this fuse bit.
I think the avrdude.conf needs to be corrected.

This issue was migrated from https://savannah.nongnu.org/bugs/?13125

Mon 21 Apr 2003 03:50:22 PM UTC

From Lou Cypher on AVR Freaks:

"I'm using AvrDude 4 as shipped with WinAVR, and I discovered a bug in the binary output format (as in "avrdude -c xx -p yy -f r -o file.bin"), since it seems to always open files in 'translated' mode, instead of using 'binary' mode.

This works well with Unix and alikes, since a '\n' has the same representation in the two modes, while on Windows it is translated in "\r\n", that has the nasty side effects of an additional 0x0D in the output -- fopen() needing a check for "wb" mode?"

This issue was migrated from https://savannah.nongnu.org/bugs/?3293

Tue 25 Nov 2003 06:28:08 PM UTC

The syntax for -U won't allow for full pathnames in Windows due to drive letter specification. Example:
-U flash:r:"e:\test.hex"

The parsing is done on the colon first, not grouping on quotes. Doulbe quotes would also be needed to handle spaces in the pathname, which is allowable on Windows. Example:

-U flash:r:"e:\This is a subdir\this is a test.hex"

This issue was migrated from https://savannah.nongnu.org/bugs/?6764

[email protected] [email protected]
Sun 27 Feb 2005 06:14:43 PM UTC

mega88 is supported but mega168 is missing..

file #2957: ATmega168.conf

This issue was migrated from https://savannah.nongnu.org/bugs/?12166

chethan [email protected]
Sun 17 Apr 2005 05:50:08 AM UTC

i'm having what seems to be the exact same problem as
http://savannah.nongnu.org/bugs/?func=detailitem&item_id=10042

but that bug never seemed to be resolved.  i do have texi2html (which generates the @Hfill and @vfill errors)

so if you have any ideas please email me at [email protected]. thanks!

[cpandar@localhost avrdude-4.2.0]$ make
make  all-recursive
make[1]: Entering directory /home/cpandar/avrdude-4.2.0' Making all in doc make[2]: Entering directory /home/cpandar/avrdude-4.2.0/doc'
mkdir -p avrdude-html
texi2html -split_node ./avrdude.texi

• • Unknown command @hfill' (left as is)- Unknown command @vfill' (left as is)mv *.html avrdude-html
    mv: cannot stat *.html': No such file or directory make[2]: *** [html] Error 1 make[2]: Leaving directory /home/cpandar/avrdude-4.2.0/doc'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/home/cpandar/avrdude-4.2.0'
    make: *** [all] Error 2

This issue was migrated from https://savannah.nongnu.org/bugs/?12715

christian fleischer [email protected]
Thu 04 Nov 2004 01:59:53 PM UTC

Hello!

flashing an atmega32 fails in the following way:
writing succeeds, reading too, but comparing the written data fails from the beginning.
this is the fact for version 4.4.0
it works fine with 4.2.0
the write-operation is 0.4s with version 4.4.0 and 1.3s for 4.2.0.
maybe the new version is too fast?
it runs on a 2.4GHz Pentium... I don't know how the timing for the write-operation is done.
hope this helps.

christian
fleischeratcsdottuminusberlindotde.

This issue was migrated from https://savannah.nongnu.org/bugs/?10907

Me :-) [email protected]
Sun 02 Oct 2005 06:47:48 AM UTC

Neither under winditz nor linux, avrstudio works with it, but only when you flash v2 into the stk500.  flashing v1.2 makes it work with nothing.

Avrdude worksflawlessly with my old stk200/300 clone.

Spent 2 days fighting this, hope this helps.

This issue was migrated from https://savannah.nongnu.org/bugs/?14683

Sat 15 May 2004 04:25:05 PM UTC

I built an AVR910 compatible programmer but had trouble getting it to work.  When attempting to program flash, AVRDude indicated that the programmer failed to repsond to an LED command.

According to the the table in avr910.asm from Atmel, the x and y commands are to be accompanied by a data byte.  The firmware in my programmer was waiting for that byte but it is apparently not being sent by AVRDude.  After I commented out the call to read the extra byte in my programmer's firmware everything started working.

So, the question is: should AVRdude be sending an extra byte after the x and y commands before waiting for the programmer's response?

This issue was migrated from https://savannah.nongnu.org/bugs/?8970

Fri 27 Jun 2003 07:16:22 AM UTC

According to changes in the new version of the rpmbuild there are needed trivial changes to the SPEC file: disabling of building debug package and remove unpackeged files.
Patch attached.

file #494: avrdude.spec.in.diff

This issue was migrated from https://savannah.nongnu.org/bugs/?4113

Lukas Sandström [email protected]
Sun 08 May 2005 03:48:48 PM UTC

The reason is that newer versions of texi2html creates a subdirectory in which it places all the html-files from texi2html -split

The attached patch changes the makefiles so that the subdirectory is looked for before it attempts to move the *.html files.

Se also bug #90199 @gentoo
http://bugs.gentoo.org/show_bug.cgi?id=90199

file #2937: avrdude-html-doc-build-fix.patch

This issue was migrated from https://savannah.nongnu.org/bugs/?13026

Tue 23 Mar 2004 02:25:16 PM UTC

Configuration: WinAVR-20030913-bin-install
mfile.tcl
STK500 / AVRStudio 4.08
Win98se

Description:
When running the flash procedure using <make %d program>, AVRDUDE tries in vain to establish communication with the STK500. AVRDUDE apparently does not detect the error and remains as task in the system. This program can then only be interrupted by using "End Task." This means flashing is not possible with the STK500.

This issue was migrated from https://savannah.nongnu.org/bugs/?8264

Colin O'Flynn
Wed 28 Dec 2005 03:57:09 PM UTC

Some devices don't use all the fuse bits, for example the Mega168 uses only the 3 low bits of the efuse. However avrdude will complain about verification errors on the higher 5 bits, which should be ignore.

This issue was migrated from https://savannah.nongnu.org/bugs/?15308

Bernhard Walle
Sat 02 Jul 2005 02:15:02 PM UTC

The hashmarks while downloading only work on intelligent terminals. If TERM is set to dumb, it would be good if they could be suppressed automatically by avrdude. (Yes, I know the -q option.)

This issue was migrated from https://savannah.nongnu.org/bugs/?13607