ATXMega8E5_32E5 undocumented features or errata

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 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...

  • 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.

  • 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

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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...

  • 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.

  • 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.

  • 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.

  • 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...

  • 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.

  • 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

  • 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.

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

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

  • 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 :)

  • 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...

 

  • 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

  • 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.

  • 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?

  • 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...

  • 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.

  • 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): 

Last Edited: Fri. May 1, 2015 - 11:28 AM
  • 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.

  • 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)