bugAVR Downloader/UploaDEr - Bugs: bug #22520, Programming Tiny25 with AVR-Prog...

 
 

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

bug #22520: Programming Tiny25 with AVR-Prog AVR109 style programmers does not work

Submitted by:  Holger Metschulat <estw>
Submitted on:  Sun 09 Mar 2008 04:00:48 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: Wont FixPrivacy: Public
Assigned to: Joerg Wunsch <joerg_wunsch>Originator Name: Holger Metschulat
Open/Closed: ClosedRelease: None
Programmer hardware: Device type: 

Sun 09 Mar 2008 02:46:12 PM UTC, comment #1:

avr109 aka. butterfly is meant for exactly that purpose: to
drive a bootloader, which normally can only handle a single
device anyway. What you're seeing there is the consequence
of the infamous "device code" mess that is implied into the
entire protocol here, where the device code itself is already
a clumsy idea to begin with, and where Atmel gave up
maintaining device codes years ago. What you can see is done
in the butterfly implemenation now is essentially a workaround
that brokeness by design, to get bootloaders at least working
at all, even for modern devices.

So you ought to use avr910 for a standalone programmer.
However, given the mess with the device codes, it's virtually
impossible to find a single set of device codes that would
be supported by multiple vendors of "modern" AVR910 firmware.
To add to this, several incompatible versions of AVR910
firmware implementations have been developed over time, to
make the mess complete.

My strongest recommendation would be to completely give up
AVR910 protocol as a standalone programmer protocol, and
urge all the vendors of those tools to migrate their firmware
to the much better defined STK500v2 protocol. My major
concern with AVRDUDE's AVR910 implementation is to provide
an implementation that is backwards compatible to AVR910
programmers out in the field (so to not break historical
implementations that are still around in production use),
rather than providing a feature-rich implementation for
new AVR910 firmware. Users of new devices could always
chose to abandon the AVR910 protocol in favor of STK500v2,
while users who've got an established installation base
cannot.

As such, I welcome any patches to help improving the code,
but I'll be very cautious to assure they won't break the
existing installed base. One idea I've already tossed
around with another developer in a private conversation
is to use the new -x option to offer additional options
for just these programmer types. That would e.g. allow
for the user to specify things like

-x devcode=0x42

to override the device code to send to the programmer,
or maybe also something like

-x use_blockmode

if someone were to implement an optional block transfer
mode into the avr910 module. For the latter, I simply
hesitate to use any form of "negotiation" because it is
virtually impossible to predict how existing programmers
would actually react to that.

Again, my strongest recommendation is for any standalone
programming tool to migrate to the STK500v2 protocol, which
is, after all, not "rocket science" to implement. If, for
whatever reason, certain vendors of AVR910 tools don't want
to go that path, they are welcome to contribute patches that
implement things like the above mentioned -x options. Me
personally, I don't have much interest in spending my own
time into extending an (IMHO) obsolete protocol myself, and
I think I explained my major concern of maintaining backwards
compatibility in the avr910 module.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Sun 09 Mar 2008 04:00:48 AM UTC, original submission:

In butterfly.c, when opening the connection to the programmer device, the device capability list is requested with "t", but then the device to use (sent to the programmer with "T") is selected as just the first of the received capability list.

While this may be feasible with bootloaders (that don't really need the T command), using the butterfly fast programming routines is not possible e.g. with a Tiny25 and an external programmer, like the AVR-Prog AVR910 from Klaus Leidinger using -c avr109 or -c butterfly.

In my case the programmer sent the 2313 as the first item back to avrdude, so avrdude set the 2313 (device code 13) as the device to program, however, with that setting, flashing a Tiny25 did not work with -c avr109 (but worked with the slow -c avr901 routines).

My suggestion would be to either create a new avr109 programmer device that sends a device code to the programmer ("T" command) derived from avrdude.conf (avr910_devcode) or to modify butterfly.c appropriately if that does not interfere with bootloader devices (I have none to verify). I have tested modifying butterfly_initialize() comparable to what avr910_initialize() does when selecting the device and it worked for the Tiny25. Diff available if deemed necessary.

Cheers,

Holger

Holger Metschulat <estw>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 09 Mar 2008 02:46:12 PM UTCjoerg_wunschStatusNone=>Wont Fix
      Assigned toNone=>joerg_wunsch
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1