Re: [avrdude-dev] Problems with avrdude 5.11+

[Joerg Wunsch]

As Bill O'Neill wrote:

Sorry for not repsonding erlier, Bill.  However, I didn't find time to
experimenting with bit-bang programmers until recently.  Apparently,
there are not much other users of bit-bangers on the list either.

> test_input.hex is the file being written to the device.
> 
> dump_ponyser.hex is what got written by the ponyser bit-bang programmer.
> 
> dump_usbtiny.hex is what got written by the USBtinyISP programmer.

Well, the ponyser data don't resemble the input file anymore at all.
Something's severely broken there.

> 1) The problem does not occur with avrdude 5.4  (I only have 5.4, 5.11 and 
> 5.11.1 at my disposal, so I do not know which version the problem got 
> introduced)

Does the very same "ponyser" adapter on the exactly same hardware
(computer's RS-232, AVR target board) really work with 5.4?  I never
got too much trust into these cheap bitbangers, and at a first glance,
I'd discard its results als "completely unreliable".

The USBtinyISP results are different, it's just two bytes that are
wrong:

% cmp -l test_input.bin dump_usbtiny.bin
  129 200 176
  130 201 177

(The address in the left column is decimal, the data bytes are octal.)

I did not try reproducing your problems with the latest release
(version 5.11.1) but with the SVN version instead (as this is what
we are about to release soon).

However, I cannot reproduce this. :-(  I tried three different
programmers:

. a parallel-port bit-banger (type "bsd")
. a "ponyser" programmer
. a USBtinyISP device

I didn't have a 32 KiB controller handy to experiment, so I used an
ATmega16 mounted on an STK500 (just the socket, bypassing the STK's
programming circuitry, of course).  With your test file, I can program
that controller repeatedly without any troubles.

(I noticed some other breakage regarding the USBtinyISP code due to
some recent changes, which I had to fix first.  But that's for sure
unrelated to your problems.)

I'm afraid you have to investigate a little more about what you run
into those issues.  Alas, the usbtiny code isn't able to produce any
useful debug output.  Thus, you could start with the "ponyser" one,
use the options -vvvv (four times option "-v") in order to make it
talk about each detail of programming.  In order to write that output
to a file, use your shell's output redirection:

avrdude <other options> -vvvv -q > logfile.txt 2>&1

(This works on a [Bourne-style] Unix shell as well as Windows'
cmd.exe.)

Try to analyze whether there are any irregularities already by the
time the data are written.

If that doesn't show up anything, I'm afraid you have to find
someone with a logic analyzer to debug the hardware side.
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)