Follow-up Comment #6, bug #37768 (project avrdude):
OK, as threatened, I used a logic analyzer to see what's
going on.
I attached the LA to the ISP signals (/RESET, MISO, MOSI, SCK),
and to CLKO. The controller had the CKOUT fuse set. The idea
was to monitor when the clock actually changes back from the
prescaled one to the one as defined by the fuses.
Much to my surprise, when using the USBtiny, CKOUT disappeared
as soon as /RESET was pulled low, file "failing.png". Thus,
it could not be noticed when the clock actually changes.
I then used the STK500 programmer module. Interestingly, CKOUT
keeps present here even after /RESET pulled low, see
"init-stk500.png". As already suspected, the clock remains
at the scaled (lower) value even after the reset. That explains
why a slow ISP speed is needed once the firmware reduced the
main clock speed.
The actual clock change happens the moment the "ISP init"
sequence has been successfully decoded, see
"clockchange-stk500.png". That means, the lower ISP clock
has to be maintained for just the init sequence, but could
be made faster later on. This is currently not supported by
AVRDUDE, and implementing it requires some larger-scale
changes.
Therefore, the recommendation that can be given by now for
users where the firmware is running at reduced clock speed
is:
. use a large enough -B value
. if that's getting to slow for overall ISP operation, just
use that value to issue a chip erase (-e), and then
proceed with a second AVRDUDE session at higher speed; use
-D to avoid the automatic erase (as the device has been
erased just before)
I'll add something like this to the documentation.
Btw., see picture "working.png": the SCK on the USBtiny varies
in a fairly large scale. While the -B value given on the
commandline is correctly reflected by the closest edges in the
SCK signal (markers G1/G2 and x/o, both displaying half of
one -B20 period), the average SCK clock speed is more like a
fourth or a fifth of the max clock. This results in a much
slower operation than would be possible.
The reason why your patch might improve the situation in some
cases is probably that by repeatedly pulling/releasing /RESET,
one might sometimes hit a time window where the internal
reset processing causes the clock to be re-evaluated again
based on the fuse setting. However, this does not seem to
be reliable in any way (that's why the patch didn't work for
me).
Given all these explanations, is it OK to close the bug?
(file #29115, file #29116, file #29117, file #29118)
_______________________________________________________
Additional Item Attachment:
File name: failing.png Size:22 KB
File name: init-stk500.png Size:22 KB
File name: clockchange-stk500.png Size:22 KB
File name: working.png Size:26 KB
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?37768>
_______________________________________________
Nachricht gesendet von/durch Savannah
http://savannah.nongnu.org/
_______________________________________________
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
