Upgrade the Xmega chip

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

Hi there.

Had anyone out there change a lower flash xmega to higher flash xmega without encounter any bug?

I had been using ATXmega64A3U. I had plan to put in more flexable data in to the EEPROM, but the ATxmega64A3U EEPROM too small.

So I change the chip to ATXmega256A3U. As my flash firmware still the same, but increase in the EEPROM only.

 

I had encounter problem using my old firmware which complie using ATxmega64A3U. From my understanding this should not happen as normally it can be upgraded, that the frimware should be able to run in the higher flash.

 

CS

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

Did you re-compile the program, or just load the X64's .hex into the X256 uC?

 

JC

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

You might need to re-compile your code for the correct part. There are differences, such as the location of the bootloader section and the way that the large memory support registers need to be manipulated.

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

Hi JC

I didnt re-complie it, just load x64 into x256.

 

Hi mojo.

Since you mention it. Now I know why one of the code will the other dont.

Maybe the latest use too much of the memory until it may use the bootloader on the x256 but not x64

 

cs

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

AVR devices are binary-compatible up to 128 K. After 128 K, the program counter (PC) register size changes from 2 bytes to 3 bytes. This messes up call returns - the code puts 2 bytes on the stack, but MCU takes 3.
 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

AVR devices are binary-compatible up to 128 K.

I think you probably mean "between 8K and 128K"? Below 8K they lose CALL and JMP and only have RCALL and RJMP.

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

Also, the bootloader section moves between 64k and 128k devices. If your code puts stuff in the bootloader it will need to be recompiled.

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

CS,

 

Within the family, the code should be compatible, but you DO need to recompile for the new chip.

 

Just do that, and give it a try.

 

Please report back on your progress, (your success!).

 

Jumping from one family to another, perhaps to the Xmegas with the battery back up options, can break the code compatibility if those specific pins / features are used.

This should not be an issue in your case.

 

Likewise, jumping between families will change the number of USARTs, Timer/Counters, etc.

This can again break the code.

Again, this should not be a problem in your case.

 

JC

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

Hi all,

Thanks for the information.

This mean the hardware (IC pins) is compatable but not all the firmware.

 

Noted. Thanks again

CA