I've recently run into some small issues with avrdude. Here I describe the
issues and some proposed fixes. I'm wondering if the fixes are acceptable and
what the procedure is for getting them in. Should I just submit as bugs with
patches to the savanna page? These days I really dislike to spend time on
patches that are never integrated so early feedback would be greatly
When programming with the AVRISPmkII (and probably other programmers in the
stk500 family at least), avrdude doesn't always ensure that the ISP
frequency is set to the value implied by the command line options or lack
thereof. In particular if the -B option isn't supplied, avrdude doesn't
ensure that the ISP saved on the programmer has any normal default value.
The fact that this programmer stores the ISP frequency is not well documented
in the man page, so trying a -B option then removing can result in a
confusing persistent failure after the option use is backed out.
document the stateful nature of this programmer in the man page, and when the
device is opened check to be sure it's saved ISP value matches the default.
If neither -B nor default_bitclock (in the config file) are defined, print a
run-time warning if the default value is not set on the device. The avrdude
default should match the default for a virgin device (125 kHz for
AVRISPmkII). I think it would be good to print an informative message about
the statefulness of the setting whenever -B or default_bitclock are used
also. At this point in the life of avrdude and AVRISPmkII I don't think it
makes sense to always ensure that the value saved on the device gets set to
match what the non-options imply, because this could be quite an annoying
breaking change to somebody.
-B affects programmers besides the JTAG ICE (e.g. the AVRISPmkII).
document this, with some effort to sort out which programmers are affected
-V (skip verification) should implicitly disable safe mode, because without
verification the fuse settings can't be checked. avrdude currently tries
anyway and gives a bogus warning that can change from run to run.
Make -V disable safe mode and document it. If default_safemode = no and -u
and -V are both given, generate a fatal error. Generate a run-time message
unless default_safemode = no.
At least one AVRISmkII clone (this one:
https://www.waveshare.com/usb-avrisp-xpii.htm) doesn't seem to always
work right at ISP = f_cpu/4. Verification sometimes fails at a random
address. Pretty annoying since it copies all the hw/firmware versions from
the actual Atmel programmer.
Document this fact, and suggest f_cpu / 8
It looks like PARAM_VTARGET might have similar issues to ISP freq. I guess
I've only ever used AVRISPmkII at 5V. I had idea that it adapted
automagically but maybe that isn't the case...
None, I don't know enought about this issue yet