bugAVR Downloader/UploaDEr - Bugs: bug #22699, Errors in AVR910 Device Codes

 
 

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

bug #22699: Errors in AVR910 Device Codes

Submitter:  None
Submitted:  Sun 23 Mar 2008 03:32:07 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Wont Fix Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  Mike Perks
Originator Email:  -email is unavailable- Open/Closed:  Closed
Release:  None Programmer hardware: 
Device type: 

Jump to the original submission

Tue 04 Nov 2008 01:18:56 PM UTC, comment #9: 

I believe the new -x devcode=VALUE option is a good enough
compromise to work around the various mutually incompatible
AVR910 device code extensions.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 24 Mar 2008 09:23:36 PM UTC, comment #8: 

Reply to comment #7:

> Changing the devicecode scheme to an Signature based decision
> within the avr910 Firmware is also a mess. To be backward
> compatible (with AVRprog and others) at least the "official"
> Devicecodes have to be there.


Well, they'd only need to be there in order to "offer" them
to avrprog.exe.  Upon receiving a selection, just don't care
what it was (unless it's a 0x13, indicating an AT90S1200),
go ahead initializing ISP, and then query the signature.

I just added the extended parameter -x devcode=VALUE to the
avr910 implementation.  It allows the user to override the
device code that is sent to the programmer.  That might
hopefully serve as a stop-gap measure so at least no separate
avrdude.conf is required.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 24 Mar 2008 01:06:37 PM UTC, comment #7: 

The more I think about the future of this, the more I come close to Joergs opinion. Let's RIP the good old avr910.

For the existing avr910 programmers and implemented devices anyone who is interested could edit the avrdude.conf and that's it.

This worked for the last years, and should for the next.
If we always improve the old avr910, this story will never stop.

Changing the devicecode scheme to an Signature based decision within the avr910 Firmware is also a mess. To be backward compatible (with AVRprog and others) at least the "official" Devicecodes have to be there.

Klaus Leidinger <kllei>
Mon 24 Mar 2008 07:28:40 AM UTC, comment #6: 

Followup on comment #2:

> As I wrote in the avrfreaks forum, ist is not so important
> whom code you use, important is that avrdude gives some
> devicecode for the newer devices. Any distributor of a
> avr910 Firmware should be interested to be compatible with
> avrdude.


Since I wouldn't want to roll a dice on each new device, I'd
like to get an opinion on an algorithm for this.  Sigh, I
wish we could drop that entire AVR910 mess completely. :-(
We almost settled to automatically generate the AVRDUDE
part configuration from Atmel's XML files in future, but due
to that AVR910 stuff, this can't be fully automated since
naturally, Atmel refuses to give out messy device codes for
a protocol that has been abandoned by them anymore.  So
there will always be manual work involved.

My personal opinion: I don't want to invent these.  We'll
add each new part based on the information in the XML files.
The first one to claim an AVR910 device code for each new
part can file a bug report for it, and we'll add that code
then.  The person filing that bug report is responsible to
ensure no clashes occur.

> There's no official assignment for the ATmega162 bootloader,
> or the ATmega162 at all.


> In the avr109 Sourcecode gcc section is a Parts.txt or the
> preprocessor.xls) which lists the devicecode for m162 to 0x63


But this is for the bootloader device codes (which are not
even to be used anymore by protocol AVR109).

Not that I ever really understood why a bootloader requires
a separate device code at all.  However, as AVRDUDE has been
using that device code in the past (and yes, I think that's
because I once messed up the bootloader codes with the basic
codes after having a look at AVR109 myself), I think we should
just keep it the way it is.

I've got a completely different suggestion: all AVR910 firmware
vendors should stop using device codes as well, and essentially
go the AVR109 route: whatever device code is presented to the
programmer, just accept it, go read the signature bytes, and
decide based upon the signature.  The only thing that still
needs a different device code then is the (now almost obsolete)
AT90S1200 since it required a different ISP initialization, but
that ought to be easy enough to do.  All other AVRs do have the
same ISP initialization, so you should always be able to read
the signature then.

Still, AVR910 is always in a poorer situation than STK500v2:
for each new part, a firmware upgrade of the programmer is
required.  In STK500v2, all device dependant parameters are
passed down from AVRDUDE, so no new firmware is needed.  Yet
another strong argument for abandoning AVR910 completely, and
move all standalone programmers to a more sensible protocol.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 24 Mar 2008 07:16:35 AM UTC, comment #5: 

Followup on comment #4:

> It should have said 0x78 (mega169).


OK, that makes sense.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 24 Mar 2008 04:17:18 AM UTC, comment #4: 

Followup to Joerg's comment on #2:

>> 2. The following devices use device code 0x75 although that
>> is already allocated to the mega16 bootloader. I suggest
>> that device code 0x73 might be better: mega329, mega329p,
>> mega3290, mega3290p, mega649, mega6490.
>
> I agree that 0x75 is a poor choice, and should be avoided.
> But in which respect would 0x73 (ATmega32 BOOT) be better
> here?

This is a typo on my part - I couldn't read my own writing. It should have said 0x78 (mega169).

Mike Perks <mperks>
Mon 24 Mar 2008 04:06:04 AM UTC, comment #3: 

Klaus Leidinger wrote:

> In the avr109 Sourcecode gcc section is a Parts.txt or the preprocessor.xls)
> which lists the devicecode for m162 to 0x63

This doesn't match your programmer which it what I was looking at. We should change the programmer to match AVR109 and we can take this item off the list for this bug.

Mike Perks <mperks>
Sun 23 Mar 2008 09:50:53 PM UTC, comment #2: 


> Klaus Leidinger uses 0x31, 0x33, 0x35, myAVR uses 0x6, 0x7,
> 0x8, respectively. Which one to chose, and why that one?


As I wrote in the avrfreaks forum, ist is not so important whom code you use, important is that avrdude gives some devicecode for the newer devices. Any distributor of a avr910 Firmware should be interested to be compatible with avrdude.

I think there are at least 3 implementations of avr910 with different devicecodes, where the devicecode scheme seems not to follow any  rule.

I'm willing to change the devicecodes and would strongly agree to a new list given by the avrdude.conf to get rid of this incompatiblities. 

>> 3. The device code for mega162 is listed as 0x63 but this
>> should be 0x62 because device code 0x63 is for the mega162
>> bootloader.


> There's no official assignment for the ATmega162 bootloader,
> or the ATmega162 at all.


In the avr109 Sourcecode gcc section is a Parts.txt or the preprocessor.xls) which lists the devicecode for m162 to 0x63

So my suggestion is that avrdude should declare devicecodes and  I expect the devicecode mess is over soon. (except the bootloader code mess ;-) )

Kind Regards,
Klaus


Klaus Leidinger <kllei>
Sun 23 Mar 2008 09:16:21 PM UTC, comment #1: 


> 1. The following devices do not have AVR910 device code
> in the conf file: mega48, mega88, mega168. These should
> be added so a AVR910 can be used for these devices.


Klaus Leidinger uses 0x31, 0x33, 0x35, myAVR uses 0x6, 0x7,
0x8, respectively.  Which one to chose, and why that one?

> 2. The following devices use device code 0x75 although that
> is already allocated to the mega16 bootloader. I suggest
> that device code 0x73 might be better: mega329, mega329p,
> mega3290, mega3290p, mega649, mega6490.


I agree that 0x75 is a poor choice, and should be avoided.
But in which respect would 0x73 (ATmega32 BOOT) be better
here?

> 3. The device code for mega162 is listed as 0x63 but this
> should be 0x62 because device code 0x63 is for the mega162
> bootloader.


There's no official assignment for the ATmega162 bootloader,
or the ATmega162 at all.

The closest match would be the ATmega161 which is kind of a
predecessor of the ATmega162 (code 0x60), but I don't know
for sure whether both use the exact same programming
parameters.  Further, both Klaus Leidinger's and myAVR's
AVR910 implementation agree on using device code 0x63 for
the ATmega162 so changing that right now will cause further
incompatibilities.

Joerg Wunsch <joerg_wunsch>
Group administrator
Sun 23 Mar 2008 03:32:07 AM UTC, original submission:  

It is important to maintain support for AVR910 programmers and therefore a few corrections to the AVR910 devices codes is required (looking at AVRDude 5.5):
1. The following devices do not have AVR910 device code in the conf file: mega48, mega88, mega168. These should be added so a AVR910 can be used for these devices.
2. The following devices use device code 0x75 although that is already allocated to the mega16 bootloader. I suggest that device code 0x73 might be better: mega329, mega329p, mega3290, mega3290p, mega649, mega6490.
3. The device code for mega162 is listed as 0x63 but this should be 0x62 because device code 0x63 is for the mega162 bootloader.

Anonymous

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mperks (Posted a comment)
  • -email is unavailable- added by kllei (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by None (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-11-04 joerg_wunsch StatusNeed Info Wont Fix
        Open/ClosedOpen Closed
    2008-03-23 joerg_wunsch StatusNone Need Info
        Assigned toNone joerg_wunsch

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code