avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

a couple small proposed fixes for avrdude


From: Britton Kerin
Subject: a couple small proposed fixes for avrdude
Date: Thu, 7 Nov 2019 12:50:07 -0900

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
appreciated.


Problem:
  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.

Proposed solution:
  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.


Problem:
  -B affects programmers besides the JTAG ICE (e.g. the AVRISPmkII).

Proposed solution:
  document this, with some effort to sort out which programmers are affected


Problem:
  -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.

Proposed solution:
  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.


Problem:
  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.

Proposed solution:
  Document this fact, and suggest f_cpu / 8


Problem:
  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...

Proposed solution:
  None, I don't know enought about this issue yet



reply via email to

[Prev in Thread] Current Thread [Next in Thread]