[avrdude-dev] [bug #37768] Poll usbtiny 100 times at init time to handle low-clock devices

[Joerg Wunsch]

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/