Xmega DFU (via FLIP). An "address is out of range" error.

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

Hi All

My question is about device firmware upgrade via FLIP. I'm using ATxmega128A4U, and according to Atmel Studio 7 my program is:

 

Program Memory Usage : 36054 bytes   25.9 % Full

Data Memory Usage : 1674 bytes   20.4 % Full

 

An error comes up when trying to load a hex file of my program to a FLIP buffer. So it says "address is out of range", although the xmega's flash memory is 128 kB(application) + 8 kB(bootloader).
 

What should I change in my program or in FLIP in order to make writing the hex file possible?

Appreciate any help.

 

Thanks,
Roman

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

Are you using something like -Wl-Ttext= or -Wl,-section-start=.text= or similar?

 

Or are you doing something to defeat the discard of .eeprom, .fuse, .lock etc from the ELF during the objcopy?

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

clawson wrote:

Are you using something like -Wl-Ttext= or -Wl,-section-start=.text= or similar?

Yes, I use "-Wl,-section-start=.BOOT=0x20000" to point out where my bootloader section begins. 

So how do you think it can influence on the situation?

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

I made a research and found out that FLIP doesn't allow us to burn a .hex file which somehow touches a bootloader section. 

So in my application I use the NVM library for controlling flash memory and almost all the methods of the library are SPM instructions after all. SPM instructions are located in the bootloader section

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

I'm guessing this may be a bug in Flip. It maybe does not account for chips (Xmega) where the bootloader section is BEYOND the end of the main flash. In a lot of previous AVRs the boot code just stole a small area within the bounds of the chip. So if you had a 32K chip and a 2K bootloader section then it was at 30K but everything was within 32K.  Now, with Xmega you really would have 32K of application and then +2K of bootloader. I wonder if someone has told Flip ?

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

Unfortunately the bootloader section starts at 0x2000. So I had to remove all NVM related methods from my app in order to provide a possibility of DFU via FLIP.

So do you know any alternative way of Xmega DFU excpt for FLIP? Would be veeery glad to know.

Thanks, 
Roman

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

Well if this is a bug in Flip then I would be looking to see if there is an update version that "knows" about the extra flash that Xmega have for the bootloader. if not I would report it to Atmel and see if they have some kind of immediate workaround.

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

I've downloaded and installed the last version from the Atmel's web site. Reporting to Atmel is a good suggestion, thanks.

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

dfu-programmer

http://dfu-programmer.github.io/

...

... and this is a lightweight alternative to Atmel's own FLIP/BatchISP program.

...

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