bugAVR Downloader/UploaDEr - Bugs: bug #43577, Extended address not sent with...


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

bug #43577: Extended address not sent with avr109

Submitted by:  None
Submitted on:  Tue 11 Nov 2014 02:14:43 PM UTC  
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  Arne Rossius
Originator Email:  -email is unavailable- Open/Closed:  Open
Release:  None Programmer hardware: 
Device type: 

Tue 11 Nov 2014 07:41:51 PM UTC, comment #3:

OK, sorry, then I misunderstood it. Reopening it, so I can
handle that (hopefully) alltogether.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Tue 11 Nov 2014 06:23:38 PM UTC, comment #2:

AFAICS, bug #29896 calls for additional memory types, while this bug is about accessing the area above 128 KiB of the regular flash memory (not bootloader area which is above 256 KiB for xmega256a3), so IMHO it's not a duplicate.

There is already a function in butterfly.c to send the 'H' command (butterfly_set_extaddr()), but it seems that the old butterfly_set_addr() is called instead. Surely this can't be right?

Arne Rossius <arossius>
Tue 11 Nov 2014 04:48:58 PM UTC, comment #1:

The "extended address" is not part of the original AVR109

bug #29896 has already been filed to request adding this
protocol extension, but has not been handled so far. (Sorry
for that.)

Joerg Wunsch <joerg_wunsch>
Project Administrator
Tue 11 Nov 2014 02:14:43 PM UTC, original submission:

When programming the ATxmega256a3 with avrdude 6.1 (windows version), the extended address is not sent when jumping across a 128 KiB boundary. I have created a text hexfile which only contains data for flash pages 0 (word address 0x00000) and 511 (word address 0x1FF00). However as can be seen from the attached log, after programming the first page only a 16-bit address command ('A') is sent instead of the 24-bit address command ('H'), resulting in an address of 0x0FF00 instead of 0x1FF00. Verify doesn't fail because the same happens when reading, but does fail when programming an actual application (without a gap) larger than 128 KiB.

The programmer is the "xboot" bootloader <https://github.com/alexforencich/xboot/wiki>. The avrdude.conf is unchanged.

Programming the attached hex file does work with the older avrdude 5.11 because this version programs pages 1 to 510 with 0xFF, only sending the address once before the first page and then relying on the bootloader's auto-increment to reach the high addresses. As can be expected, it takes a very long time though.

Also, as can be seen from the xboot source, it resets the extended address byte to zero when receiving an 'A' command. I'm not sure if this behaviour is correct, but if it is, this means that avrdude must send an 'H' command for all flash pages above 128 KiB (unless no address is sent at all between adjacent pages).



Attached Files
file #32419:  avrdude-error.txt added by arossius (86KiB - text/plain)
file #32418:  napftest.hex added by None (3KiB - application/octet-stream)


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 arossius (Updated the item)
  • -email is unavailable- added by None (Submitted the item)

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

    Only logged-in users can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-11-11 joerg_wunsch StatusDuplicate => None
        Open/ClosedClosed => Open
    2014-11-11 joerg_wunsch StatusNone => Duplicate
        Open/ClosedOpen => Closed
    2014-11-11 arossius Attached File- => Added avrdude-error.txt, #32419
    2014-11-11 None Attached File- => Added napftest.hex, #32418

    Back to the top

    Powered by Savane 3.4