ATXMega8E5_32E5 undocumented features or errata

Log in or register to post comments
Go To Last Post
27 posts / 0 new
Author
Message
TravelRec
TravelRec's picture
Level: Rookie
Joined: Sat. Aug 23, 2008
Posts: 38 View posts
#1
Posted by TravelRec: Sun. Feb 23, 2014 - 02:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello there,

just working with the XMEGA_E5 series of microcontrollers. Since this family is quite new, I discovered some Extra that is not documented in the datasheet or manual.

- Erasing the application section erases the boot section too and vice versa. This is true for on chip memory programming (Bootloader) as well as for PDI programming. Maybe someone of the community is able to verify this behaviour.

Maybe there are other errata to be found.

BTW: The fact, that the CPU is halted when writing a flash page in the application section from the boot code, is quite worse. It is nearly useless to have a bootloader on the chip with an unidirectional upload interface. So the upload has to wait more than 4ms after the transmission of a page buffer, until the page is finished with writing. This way you can´t use a simple terminal program to update the micro. I can´t understand this step back, since all Megas and XMegas apart from the E5 are able to run the CPU inside of the Boot section when writing the application flash...

Tags:

AVR Microcontrollers, AVR XMEGA
Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 90766 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Sun. Feb 23, 2014 - 04:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Maybe someone of the community is able to verify this behaviour.

That's always been true of all AVRs hasn't it? I don't think there's anything new or unexpected there.

Top
DocJC
DocJC's picture
Level: 10k+ Postman
Joined: Tue. Dec 11, 2007
Posts: 11806 View posts
Location: Cleveland, OH
Posted by DocJC: Sun. Feb 23, 2014 - 04:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm certainly not an Xmega expert, but I think the Xmegas have a number of Lock bits, (Fuses), including the Boot Loader Boot Lock Bits, with 4 states, (Not locked, Write locked, Read locked, Read and Write locked).

Perhaps that will help with the Bootloader erasure problem.

JC

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2068 View posts
Posted by mojo-chan: Mon. Feb 24, 2014 - 09:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should be able to erase just the application section. Otherwise how could your bootloader ever work since erasing the app section would erase the bootloader itself too.

It sounds like you are doing something wrong.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 90766 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Feb 24, 2014 - 10:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You should be able to erase just the application section.

You certainly can using SPM in the bootloader but I think OP was asking about PDI. Now maybe PDI is different to ISP (and the Xmega bootloader is "more separate" from the app flash than in tiny/mega) but in tiny/mega it's the case that ISP starts with issuing a "chip erase" which is a full chip erase that wipes all the flash including the bootloader.

This does not actually matter of course because it will be done when you first ISP (PDI) the bootloader into the chip but once the bootloader is there it will be IT that does further flash programming and in this case it does not do "chip erase"s but "SPM page erase"s so any erasure is localised to a specific SPM page at a time.

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2068 View posts
Posted by mojo-chan: Mon. Feb 24, 2014 - 03:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
You certainly can using SPM in the bootloader but I think OP was asking about PDI. Now maybe PDI is different to ISP (and the Xmega bootloader is "more separate" from the app flash than in tiny/mega) but in tiny/mega it's the case that ISP starts with issuing a "chip erase" which is a full chip erase that wipes all the flash including the bootloader.

He said it affected both self programming and PDI. In AtmelStudio there is now an option to only erase/program the app section, but only certain programmers support it (eg. JTAGICE3). You can ask the NVM controller to just erase the app section.

Top
TravelRec
TravelRec's picture
Level: Rookie
Joined: Sat. Aug 23, 2008
Posts: 38 View posts
Posted by TravelRec: Mon. Feb 24, 2014 - 06:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:
You should be able to erase just the application section. Otherwise how could your bootloader ever work since erasing the app section would erase the bootloader itself too.

It sounds like you are doing something wrong.

Exactly this is the problem. The command "Erase Application Section" erases the whole Flash. That is the Bug. For other XMEGAs the command work fine. The same is with PDI and the "Erase Application" in the Device Programming -> Memories tab. I´m sure that I do nothing wrong here.

Top
TravelRec
TravelRec's picture
Level: Rookie
Joined: Sat. Aug 23, 2008
Posts: 38 View posts
Posted by TravelRec: Mon. Feb 24, 2014 - 06:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
I'm certainly not an Xmega expert, but I think the Xmegas have a number of Lock bits, (Fuses), including the Boot Loader Boot Lock Bits, with 4 states, (Not locked, Write locked, Read locked, Read and Write locked).

Perhaps that will help with the Bootloader erasure problem.

JC

I will try this. Strange anyway.

Top
TravelRec
TravelRec's picture
Level: Rookie
Joined: Sat. Aug 23, 2008
Posts: 38 View posts
Posted by TravelRec: Mon. Feb 24, 2014 - 06:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

You certainly can using SPM in the bootloader but I think OP was asking about PDI. Now maybe PDI is different to ISP (and the Xmega bootloader is "more separate" from the app flash than in tiny/mega)

Since PDI and SPM uses the same Hardware on chip (NVM-Controller) both of the programming modes are affected by the same bug, I think...

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8074 View posts
Location: San Jose, CA
Posted by alexru: Mon. Feb 24, 2014 - 10:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Don't bootloaders usually erase page by page as opposed to erasing entire flash?

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

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2068 View posts
Posted by mojo-chan: Tue. Feb 25, 2014 - 09:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TravelRec wrote:
Exactly this is the problem. The command "Erase Application Section" erases the whole Flash. That is the Bug. For other XMEGAs the command work fine. The same is with PDI and the "Erase Application" in the Device Programming -> Memories tab. I´m sure that I do nothing wrong here.

That would be a pretty epic bug if it were the case. I have an E5 here that I will try to test with, but at the moment I'm waiting for a new PCB for that product.

What programmer do you have? If possibly try using Atmel Studio to erase only the app section and see what happens. If you can create a minimal example of the bug you can send it to Atmel for verification.

Top
TravelRec
TravelRec's picture
Level: Rookie
Joined: Sat. Aug 23, 2008
Posts: 38 View posts
Posted by TravelRec: Tue. Feb 25, 2014 - 03:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
Don't bootloaders usually erase page by page as opposed to erasing entire flash?

For XMEGAs there are special commands for erasing dedicated flash sections, which are very fast compared to the page by page erase.

Top
TravelRec
TravelRec's picture
Level: Rookie
Joined: Sat. Aug 23, 2008
Posts: 38 View posts
Posted by TravelRec: Tue. Feb 25, 2014 - 03:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:

What programmer do you have? If possibly try using Atmel Studio to erase only the app section and see what happens. If you can create a minimal example of the bug you can send it to Atmel for verification.

I use AVR-ISP mkII and ATMEL-Studio 6.1.2730.
I always have problems by sending messages to ATMEL due to account/access problems. I try to catch one from the ATMEL staff on the "embedded world" exhibition on Thursday...

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2068 View posts
Posted by mojo-chan: Tue. Feb 25, 2014 - 03:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unfortunately the AVR-ISP mkII can't do an app section only erase from Atmel Studio.

When I have some hardware I will test it out with my JTAGICE3.

Top
DocJC
DocJC's picture
Level: 10k+ Postman
Joined: Tue. Dec 11, 2007
Posts: 11806 View posts
Location: Cleveland, OH
Posted by DocJC: Tue. Feb 25, 2014 - 08:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Unfortunately the AVR-ISP mkII can't do an app section only erase from Atmel Studio.

Why can't you "lock" the Bootloader and then erase the chip?

JC

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2068 View posts
Posted by mojo-chan: Wed. Feb 26, 2014 - 09:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doing a chip erase normally erases locked areas, otherwise there would be no way to unlock them.

Top
metRo_
metRo_'s picture
Level: Wannabe
Joined: Thu. Nov 19, 2009
Posts: 97 View posts
Posted by metRo_: Wed. Feb 26, 2014 - 11:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm starting developing with E5 too, can you share your bootloader? Thanks :)

Top
dmginc
dmginc's picture
Level: Wannabe
Joined: Mon. Apr 12, 2010
Posts: 91 View posts
Location: Melbourne, Australia
Posted by dmginc: Fri. Apr 17, 2015 - 01:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I ran into this behavior recently: i.e. the ERASE_APP NVM command (0x20) erases the entire flash and not just the application section.

 

Submitted a support case to Atmel and got the following reply (April 16 2015):

"In ATxmega32E5 device, the NVM controller design is such that the entire flash will get erased always when application/bootloader erase is called. We’ve posted a bug to clarify this information in the datasheet and this will be updated in the future updates of the datasheet. Sorry for the inconvenience caused."

 

Hope this clears it up for everyone :)

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2068 View posts
Posted by mojo-chan: Fri. Apr 17, 2015 - 07:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WOW. Just WOW. That's a pretty epic cock-up. Did they not test it at all?

 

So basically the only way to implement a bootloader on the E5 is to erase each flash page in the app section individually, which will take a lot longer.

 

Oh Atmel, I really like the E5, but this time...

 

Top
dmginc
dmginc's picture
Level: Wannabe
Joined: Mon. Apr 12, 2010
Posts: 91 View posts
Location: Melbourne, Australia
Posted by dmginc: Fri. Apr 17, 2015 - 08:03 AM (Reply to #19)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Definitely!

 

Though, I'm pretty sure all (?) XMEGAs have the "ERASE_WRITE_FLASH_PAGE" NVM command (0x25) - so it is not a requirement to explicitly erase the entire application area before writing the application via the bootloader.

 

Below is from the XMEGA E5 datasheet.

 

 

If anyone is interested, I have XBoot working perfectly on the E5 - see the Github pull request here: https://github.com/alexforencich...

 

The (non-functional) ERASE_APP NVM command isn't actually required.

 

Nick

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2068 View posts
Posted by mojo-chan: Fri. Apr 17, 2015 - 09:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You just have to remember to erase unused pages as well, otherwise your CRC won't match.

Top
Fritz E Noll
Fritz E Noll's picture
Level: New Member
Joined: Fri. Mar 20, 2015
Posts: 3 View posts
Location: Raleigh, NC
Posted by Fritz E Noll: Mon. Apr 20, 2015 - 01:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nick, I'm not yet familiar with GitHub. Do I need to implement all the module patches in your ../xboot/pull/17 or is your working version of Xboot for the E5 available for download somewhere?

Top
dmginc
dmginc's picture
Level: Wannabe
Joined: Mon. Apr 12, 2010
Posts: 91 View posts
Location: Melbourne, Australia
Posted by dmginc: Tue. Apr 21, 2015 - 04:10 PM (Reply to #22)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just clone this repo: https://github.com/nickdademo/xboot

 

Or alternatively, download a ZIP of the repo: https://github.com/nickdademo/xb...

Top
Fritz E Noll
Fritz E Noll's picture
Level: New Member
Joined: Fri. Mar 20, 2015
Posts: 3 View posts
Location: Raleigh, NC
Posted by Fritz E Noll: Fri. May 1, 2015 - 03:17 AM (Reply to #23)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nick, Thanks for the ZIP of your work on the E5. I compiled the standard "_.conf.mk" files before creating one for the atxmeta32E5 (these worked as supplied in the standard XBOOT package). I found I had to revert to the original $(MAKE) rather than your change to "$(MAKE)" in file "Makefile" before the same files would compile without error with your mods. (Using WinAVR 4.3.3). Next, I created a "x32e5.conf.mk" file from "x32a4.conf.mk" with appropriate changes. It does not compile because avr-gcc doesn't support the MCU = atxmega32e5 as such. Documentation indicates that the E5 should be compiled as an "avrxmega2", but this doesn't support the parsing necessary in the XBOOT files. What am I missing for compiling your code for the E5? Thanks in advance.

Top
dmginc
dmginc's picture
Level: Wannabe
Joined: Mon. Apr 12, 2010
Posts: 91 View posts
Location: Melbourne, Australia
Posted by dmginc: Fri. May 1, 2015 - 11:27 AM (Reply to #24)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I used the avr-gcc supplied with Atmel Studio 6.2: v4.8.1

 

So maybe it's a good idea to try that?

 

I've also attached my 32E5 XBoot config file to this post.

 

 

Attachment(s): 

Package icon x32e5.conf_.zip
Last Edited: Fri. May 1, 2015 - 11:28 AM
Top
Fritz E Noll
Fritz E Noll's picture
Level: New Member
Joined: Fri. Mar 20, 2015
Posts: 3 View posts
Location: Raleigh, NC
Posted by Fritz E Noll: Mon. May 4, 2015 - 02:33 AM (Reply to #25)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks again, Nick. I downloaded the latest AVR 8-bit toolchain from Atmel with success. I didn't realize that WINavr was so far behind in XMEGA support.

Top
funkwizard
funkwizard's picture
Level: New Member
Joined: Thu. Apr 28, 2005
Posts: 4 View posts
Location: Cape Town, South Africa
Posted by funkwizard: Thu. Jul 13, 2017 - 03:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recently ran into some issues using the original xboot : https://github.com/alexforencich... for the Xmega32E5

 

The following command would fail :

 

avrdude -p atxmega32e5 -P /dev/ttyUSB0 -c avr109 -b 115200 -U flash:w:application.hex

 

And I discovered that using the -e option worked fine :

 

avrdude -p atxmega32e5 -P /dev/ttyUSB0 -c avr109 -b 115200 -e -U flash:w:application.hex

 

So the -e option does not erase the bootloader (and is actually required for this chip) when programming over the UART, but it does erase everything (as discussed above) when programming via pdi (and quite possibly via ISP)

Top