Looking for XMEGA256 Boot Loader programmer.

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Like many of your members, I am writing a boot loader for the XMEGA128 and XMEGA256 based on the AVR1605 application note. It should work fine with the XMEGA128, but AVR1605 (along with the AVRProg and AVROSP programmers) does not support 256KB of flash due to the "Set Address" command being limited to 16 bits. Have the application note and/or the programmers been updated to handle the larger memory devices? (I have heard that AVR-OSPII now has a 24-bit-address "H" command, but I have been unable to find a copy.)

 

Regards,

Peter Clark. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's a bootloader for XMEGA256A3U that's using the NVM controller code from ASF :

https://github.com/ganzziani/Xproto-Watch-Bootloader/blob/master/GccBoardProject1/src/ASF/xmega/drivers/nvm/nvm.h

...

/**
* Data type for holding flash memory addresses.
*
*/
#if (FLASH_SIZE >= 0x10000UL) // Note: Xmega with 64KB of flash have 4KB boot flash
typedef uint32_t flash_addr_t;
#else
typedef uint16_t flash_addr_t;

#endif

via http://www.gabotronics.com/source-code/xscopes-source-code.htm

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Xboot uses the extended address.  I've never used it.  It exists on GitHub.

 

https://github.com/alexforencich...

 

 

Last Edited: Wed. Sep 20, 2017 - 03:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your help, steve17 and gchapman.

AVRProg and AVROSP appear to have been superseded by avrdude. I've just downloaded V6.3 and it looks good. Now I have to decide whether to use XBoot or AVR1605 as my boot loader. It appears that all I need to do to AVR1605 is to add the extended address "H" command and it should work with avrdude. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

peteepoos wrote:
It appears that all I need to do to AVR1605 is to add the extended address "H" command and it should work with avrdude. 

I guess so.  Then it would be up to avrdude to use the H command.

 

I looked at my quick and dirty bootloader and I see I've added the 'H' command.  I can't remember if I've ever tested it.  Normally the AVRs I use only have 128k of app flash.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I've finished my bootloader for the XMEGA256A3 using the AVR109 protocol and the extended addressing 'H' command as per AVR1605, and it works fine. However, I now find that avrdude V6.3 doesn't issue the 'H' command for the AVR109 and AVR911 programmers, so it won't work with flash above 128k words. Is there a solution to this problem, or perhaps an alternative programmer that will work?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this/are these the issues?

bug #46843: avrdude=>6 fails to write from 128k-mark onwards, loops back to 0x0000

avrdude version 6 series fails to write programs bigger than 131.072 bytes to flash on my atxmega256a3bu.

...

bug #51117: Problems with extended address (>128K) and buffer size

via http://savannah.nongnu.org/bugs/?group=avrdude

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, with the avrdude programmer set to AVR109 or AVR911. The 'H' command has been around for some time now, & I thought that avrdude might have been updated accordingly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IIRC from the first bug, AVRDUDE 5.11 may be functional.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You might find something in this thread:  This might be the guy that submitted the bug, and may have a patch.

 

http://www.avrfreaks.net/comment...

Last Edited: Wed. Oct 4, 2017 - 06:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

IIRC from the first bug, AVRDUDE 5.11 may be functional.

 

I installed avrdude-5.11-Patch7610-win32.zip, but it still sends 2-byte addresses using the "Set Address" ("A") command, not 3-byte adresses with the "H" command. avrdude supports a lot of programmers; isn't there another one that uses the AVRProg/AVROSP protocol, but with extended addressing?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Couldn't find a patch for extended addressing in http://savannah.nongnu.org/patch/?group=avrdude

So, the proposed patch is from Steve's suggested solution in http://www.avrfreaks.net/forum/looking-xmega256-boot-loader-programmer#comment-2287906

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW does it have to be avrdude anyway? I cannot access AVR1605 but if Atmel have written a bootloader for Xmega then what were they planning to use for the "other side" of the download?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVROSP

Atmel AVR1605: XMEGA Boot Loader Quick Start Guide

Atmel AVR1605: XMEGA Boot Loader Quick Start Guide

Atmel AVR1605: XMEGA Boot Loader Quick Start Guide

(file size: 765KB, 15 pages, revision B, updated: 07/2014)

This application note describes how to use a boot loader application with one of the Atmel® AVR® XMEGA® family devices (e.g. ATxmega128A1) and how an AVR with the Store Program Memory (SPM) instruction can be configured for Self-programming.

No zip file at http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591160

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There might be a way for a bootloader to work with avrdude that doesn't send the high address bit when the address exceeds 0xffff.  I'm guessing avrdude will send the low 16 and they should wrap around from somewhere around 0xffxx to 0x00xx.  The bootloader could detect the jump from high 16 bit addresses to low ones and stick a 1 in the 17th bit position.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

BTW does it have to be avrdude anyway? I cannot access AVR1605 but if Atmel have written a bootloader for Xmega then what were they planning to use for the "other side" of the download?

 

Good question. I'd like to know the answer to that.

The AVR109/AVR1605 protocol is ideal for a boot loader. Because it's so simple it doesn't take up a lot of flash. 

 

quote=steve17]

There might be a way for a bootloader to work with avrdude that doesn't send the high address bit when the address exceeds 0xffff.  I'm guessing avrdude will send the low 16 and they should wrap around from somewhere around 0xffxx to 0x00xx.  The bootloader could detect the jump from high 16 bit addresses to low ones and stick a 1 in the 17th bit position.

 

That's assuming the code is stored in contiguous memory locations. 

 

gchapman wrote:

Couldn't find a patch for extended addressing in http://savannah.nongnu.org/patch/?group=avrdude

So, the proposed patch is from Steve's suggested solution in http://www.avrfreaks.net/forum/looking-xmega256-boot-loader-programmer#comment-2287906

 

 

I'm not sure that this patch would work. For addresses greater than 16 bit, the programmer needs to handle the Extended Segment Address records in the HEX file.

It seems a lot of work has gone into avrdude. The extended address problem has been put on the bug list at least twice, so why hasn't it been fixed?

 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

peteepoos wrote:

 

quote=steve17]

There might be a way for a bootloader to work with avrdude that doesn't send the high address bit when the address exceeds 0xffff.  I'm guessing avrdude will send the low 16 and they should wrap around from somewhere around 0xffxx to 0x00xx.  The bootloader could detect the jump from high 16 bit addresses to low ones and stick a 1 in the 17th bit position.[/quote}

 

That's assuming the code is stored in contiguous memory locations. 

 

 

 

If not contiguous, at least in ascending memory addresses.  Tozzi searched his hex file looking for :02 and found that was true.  I don't remember the details but I think the :02 in the hex file is where the address is set.   

 

From that thread I pointed to:

Steve17, you might be right onto something here...

:04 doesn't occur.

:02 occurs twice, lines 4097 and 8194.

Lines 4096-4098:
 

:10FFF000ED81FE813196E49180E090E0A0E0B0E8F0
:020000021000EC
:100000008093B1389093B238A093B338B093B4389A
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

:020000021000EC

02 byte count

0000 address of first byte of data

02 record type (02 = extended segment address, multiply this value by 16 and add to all following addresses)

1000 data (extended segment address, so add 0x10000 to all following addresses

 

record type 04 would be extended linear address (upper 16-bits of 32-bit address)

David (aka frog_jr)