bugAVR Downloader/UploaDEr - Bugs: bug #37768, Poll usbtiny 100 times at init...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #37768: Poll usbtiny 100 times at init time to handle low-clock devices

Submitter:  Keith Packard <keithp>
Submitted:  Sun 18 Nov 2012 07:21:16 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  In Progress Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  keithp
Open/Closed:  Open Release:  None
Programmer hardware:  Device type: 

Jump to the original submission

Thu 12 Sep 2013 11:34:21 AM UTC, comment #7: 

A respective paragraph has been added to doc/avrdude.texi,
SVN r1218.

Joerg Wunsch <joerg_wunsch>
Group administrator
Thu 12 Sep 2013 09:16:50 AM UTC, comment #6: 

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?


Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 11 Sep 2013 09:27:20 AM UTC, comment #5: 

Btw., applying your patch doesn't help here either, it still
requires the -B20 (where it will work even without the patch).

I'm afraid I have to fire the logic analyzer onto this ...

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 11 Sep 2013 07:20:56 AM UTC, comment #4: 

For another test, I tried the attached testcase.  It sets
the clock prescaler to 32 (= 250 kHz clock using default
fuses), makes timer 1 overflow each 256 ms to toggle a LED,
and puts the device on sleep otherwise.

I need to specify -B20 on the commandline (50 kHz ISP clock),
but otherwise, the USBtiny works fine with this constellation.

OTOH, since after a reset, the device is being clocked with
the default clock according to the fuses (i.e., 1 MHz), it
is somewhat surprising that -B20 is needed which in turn
slows down the entire ISP.  I'll try analyzing that a bit more.

(file #29099)

Joerg Wunsch <joerg_wunsch>
Group administrator
Tue 10 Sep 2013 09:47:18 PM UTC, comment #3: 


> I wonder if this affects how it responds to the reset?


It probably does, but just the other way around: upon reset,
no application code is running, so the CPU clock is just
the clock as configured by the fuses (whatever it might be,
including the effect of the CKDIV8 fuse).

Maybe it's some other effect, like the device waking up
from sleep?

I don't pretend to fully understand the existing USBtinyISP
code though.  As I read it, it asserts /RESET rather early,
and that should certainly get the target into its
fuse-configured speed sooner or later.

If you can come up with a (firmware) testcase that
reproduces the issue, that would be welcome.  I'd like to
understand what's going on before changing the code (in
particular since I didn't write that code myself).

Joerg Wunsch <joerg_wunsch>
Group administrator
Tue 10 Sep 2013 09:39:08 PM UTC, comment #2: 

Hrm. I'm not using the fuse to adjust the clock, rather I'm letting the chip come up at full speed and then clocking it down once the OS starts. I wonder if this affects how it responds to the reset?

I can try messing with the fuses and see if that makes things happy; that would at least let us know where the difference lies.

Of course I understand why you're reluctant to take a patch which doesn't seem to have any effect that you can see :-)

Keith Packard <keithp>
Tue 10 Sep 2013 09:14:17 PM UTC, comment #1: 

I'm not completely reluctant to accept the patch, but in
trying to reproduce the problem, I failed so far.

First, I picked an ATmega16, and clocked it externally down
to 100 kHz.  Running AVRDUDE with the USBtinyISP and the
argument -B100 (resulting in a 10 kHz ISP clock) allowed me
to successfully connect to it.

Then, I picked an ATtiny45, and changed the low fuse to
0xe4, resulting in it being clocked from the 128 kHz watchdog
oscillator.  Again, using -B100 gave me a success in
connecting.

Finally, I changed the low fuse of the 'tiny45 to 0x64, so
the 1:8 prescaler is active, resulting in a total CPU clock
of 16 kHz.  Obviously, -B100 is still too fast now, but
-B1000 (1 kHz ISP clock) makes it work again.

Am I missing something?

Joerg Wunsch <joerg_wunsch>
Group administrator
Sun 18 Nov 2012 07:21:16 PM UTC, original submission:  

I've got an ATtiny85 project that clocks the CPU down to 250kHz at boot time. That's too slow for programming. To fix this, I need to hold RESET low when first powering up the device.

Here's a patch which polls the programmer 100 times at init time instead of polling only twice. As reset is held low while polling, this allows me to start avrdude and then power up the device. As soon as the power switch is flipped, programming starts.

Devices which aren't broken like this won't see any changes.

Keith Packard <keithp>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #29115:  failing.png added by joerg_wunsch (22KiB - image/png - Various LA traces)
file #29116:  init-stk500.png added by joerg_wunsch (22KiB - image/png - Various LA traces)
file #29117:  clockchange-stk500.png added by joerg_wunsch (22KiB - image/png - Various LA traces)
file #29118:  working.png added by joerg_wunsch (26KiB - image/png - Various LA traces)
file #29099:  t45.c added by joerg_wunsch (498B - text/x-csrc - Testcase with 250 kHz main clock and sleep)
file #26926:  0001-Poll-usbtiny-100-times-at-init-time-instead-of-twice.patch added by keithp (2KiB - text/x-diff - Patch adding polling loop)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by keithp (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-12 joerg_wunsch Attached File- Added failing.png, #29115
        Attached File- Added init-stk500.png, #29116
        Attached File- Added clockchange-stk500.png, #29117
        Attached File- Added working.png, #29118
    2013-09-11 joerg_wunsch Attached File- Added t45.c, #29099
        StatusNeed Info In Progress
    2013-09-10 joerg_wunsch StatusNone Need Info
        Assigned toNone joerg_wunsch
    2012-11-18 keithp Attached File- Added 0001-Poll-usbtiny-100-times-at-init-time-instead-of-twice.patch, #26926

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code