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. ;-) _______________________________________________ avrdude-dev mailing list avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
