Weird xmega flash wraparound at 0x2000

[E]

Hey guys,

I have a weird problem with my xmega256a3u. Whenever I try to program memory above 0x802000 (aka 8KB after the flash start), the writing process wraps around and writes over the 0x800000 area, which results in the final memory being the AND of the first and the second 8KB block of my application.

(Example: first byte in app: 0xfd, byte at 0x2000 in app: 0x7f, first byte in flash after writing: 0xfd & 0x7f = 0x7d)

When reading out the chips memory, this 8k block is repeated over and over again until the address 0x820000, at which the memory is empty. Writing to that address with more than 8k results in the same problem just in the second half of the memory, so 0x822000 wraps around to 0x820000. The bootloader section 0x8400000 which directly follows the xmegas application flash is 8k in size and can be written without problem.

I've tried writing with an AVR ISP MKII and with xBoot, both showing the same problem, both in writing and reading.

Any ideas what could cause this, how I could solve it or what I should do?

Thanks!

E

[TerminalJack505]

I don't know much about the xmegas.  In fact, your post reminded me that I got a xmega development board some time ago and I've never got around to playing with it.

Something weird like that might be caused by not-so-kosher fuse settings, I suppose.  You might check those or even reset them to the factory defaults.

[E]

I looked through the fuse settings and was unable to see any fuse settings that would have this effect. I also checked all fuses and they seem to be on factory defaults. (0xFF on all except one, I think it was the JTAGUID, which is 0x00 in the datasheet by default)

[MikeK]

I'm not familiar with Atmel...Is there a hex file generated from the compiler?  Does it have the right address offsets?  This would tell you if the problem is the compiler or the programmer.

[TerminalJack505]

Well, I'm pretty much out of ideas then.  Other than making sure you're running the latest versions of everything that might be a factor.  The latest version of the programmer firmware, especially.  Early firmware versions of the AVRISP MkII did not support the xmegas. 

You might also try a different uploader.  avrdude, for example. 

[TerminalJack505]

You might look at this post over at AVR Freaks.

[E]

I'm using avrdude and xBoot, so I already tried two independent versions to flash. Out of ideas so far myself 
Offsets etc should all be right, I'll have a read at the topic linked before.

[Harvs]

Open then intel hex file in a text editor.  This is one of the optional outputs in the AVR build process so you may need to turn it on in the project properties (assuming you're using avrstudio tool chain.)  You can verify exactly what the programmer should be putting where. Check out http://en.wikipedia.org/wiki/Intel_HEX on how to read intel hex files if you haven't deciphered them before (quite straight forward.)


That should halve your problem (i.e. programmer or tool chain.)


If you've got something weird going on in your hex file then check out the memory map/linker script.  See where you're telling it to place stuff in memory.  This will have the file extension .map on an avr and will be located in the debug/release directory.  Obviously this map should reflect what you're getting in your hex file.

[Harvs]

I just had a quick look at the flash memory section of the datasheet.  What you're saying doesn't make sense, the flash memory starts at address 0, not 0x800000, what's the story?  You might want to check you're not programming the SRAM section or something odd like that.

[E]

Hey Harvs, thanks for your interest in this problem. The ihex file is irrelevant, the problem occurs with different programmers and with simple binary patterns as well.

The offset 0x800000 is the base offset of the application flash memory location as can be seen in the XMega A Family Manual (http://www.atmel.com/Images/doc8077.pdf) in Figure 30-3 on page 367.

I looked at the thread posted before and came to the conclusion that it's not related to mine. I tried reenabling JTAGEN which I previously had disabled because I need those pins, but the problem is the same.

Basically it looks to me as if the Z-pointer is faulty in bits  [16:13] so it loops 0x2000 -> 0x0000 etc. up to 0x1e000 -> 0x0000 and then does the same separately for 0x22000 -> 0x20000 and so on.

My conclusion so far is that unless I find something that's unknown to me, the device must have a hardware fault within the NVM or Z-pointer.

[Harvs]

Ok right, that's the offset for the Programming Debug Interface.  In 32-bit controllers that I've used you have a continuous address range (like spec'd in that map) that the processor would address.  Where as that offset is only relevant to the PDI and JTAG, no doubt because they have separate instructions for addressing each of the different memory types (because the 8bit processor would choke on a 32bit address.) My bad, but it is confusing when they have different memory offsets depending on how you're accessing it (i.e I was looking at the flash memory section of the datasheet right at the beginning.)


So how are you doing this.  I assumed you were programming the device with the AVR ISP, then doing a read back, and comparing to the two files?   

[E]

I tried a lot of different stuff. Here's some of the things I did:

Using the Olimex AVR ISP mkII:

I cut my app after the first 8k, erased the chip and uploaded that, then read it back and used vbindiff (a binary diff tool) to check the files, and they are 100% equal in the first 8k, but the data is repeated every 8k until 0x20000 is reached, the rest is filled with 0xFFs.

I erased the chip again and uploaded the whole app (~10k, CDC example from ASF compiled with newest avr-libc) and read it back, vbindiff again as before. After a while I realized that what I see is the binary AND of the first 8k and the remaining data of my app with length 8k repeated every 8k.

I tried some other stuff which all ended up with the same result described above.

I tried writing to 0x820000 instead of 0x800000 and got the same result, only that that the repeated area was from 0x20000 to 0x40000 in 0x2000 steps again. So exactly the same as before just with a 0x20000 offset.

I tried programming the "boot" area at 0x840000: apps with < 8k worked with 0x0-0x400000 being empty (0xFF), apps with > 8k gave the expected "app too large" error.

Finally to check whether the programmer's at fault, I modified the xBoot bootloader for xmegas and made it program a 256 byte buffer filled with 0x00, 0x01, ..., 0xfe, 0xff at various offsets, read them back and activated different LEDs depending on the result. I found out that the behaviour is exactly as before: writing at 0x2000 overwrote 0x0000, writing at 0x2001 overwrote 0x0001 and so on.

Also tried reading back that result with avrdude via PDI to get the results confirmed again.

There's only two things that don't exactly add up:
a) when using avrdude, a page erase > 0x2000 did not erase the page at 0x0000 as described above, but the page erase when using xBoot did erase at 0x0000 when trying to erase 0x2000
b) when I played around with writing at 0x0000, then 0x2000 and then 0x4000 over xBoot, I did not always get the binary AND of all three bytes, for example I tried writing
0b11111111 at 0x0000
0b11110000 at 0x2000 and
0b00111100 at 0x4000 and got
0b00000000 as result, instead of the expected 0b00110000, but I'm not sure if I maybe made some mistake, because later tests worked and it was late at night already, so I had no more patience to properly test this.

Anyways, thanks for reading this WoT.
There's only few things that could still be the culprit: I thought I read something about the NVM shuffling areas in flash to increase lifetime, but I can't find it anywhere in the docs anymore; and also there's the apptable which is 8k as well and can be protected, maybe it's doing something fishy. Currently still reading through the manual and datasheet line for line.

[amyk]

I thought I read something about the NVM shuffling areas in flash to increase lifetime

That's likely a recommendation that you do wear leveling, not that it will do that automatically for you.

Do you have another device you can work with? It might be a damaged chip.

[E]

Unfortunately I don't right now. The supplier sent me to Atmel which told me to go to the software supplier which is... themselves? (tried AVR Studio too, same issue)

I'm just wondering... is it possible that I damaged the chip that way? My guess would be it's impossible to destroy a chip that selectively (everything works perfectly when using a firmware < 8k) with a heat or ESD.

If it wasn't me I'd like to get a free replacement, but no idea if that's realistic with Atmel. Never had any damaged chip from them before.

[TerminalJack505]

From the sounds of it you have pretty much ruled out everything but the chip itself.

Since it is just one chip you would think Atmel would be more than happy to exchange it for a different one.  If I were them I'd want to inspect the chip and see what happened to cause the problem.

[Kremmen]

Unfortunately I don't right now. The supplier sent me to Atmel which told me to go to the software supplier which is... themselves? (tried AVR Studio too, same issue)

I'm just wondering... is it possible that I damaged the chip that way? My guess would be it's impossible to destroy a chip that selectively (everything works perfectly when using a firmware < 8k) with a heat or ESD.

If it wasn't me I'd like to get a free replacement, but no idea if that's realistic with Atmel. Never had any damaged chip from them before.

If AVR Studio has the same problem without you having done any odd tweaking, and the chip is defined correctly for the project, then it almost has to be a problem in the chip itself. Or hardware at any rate. Of all the times (and there are many) i have compiled an executable with Studio and programmed it to a chip using one of STK500, STK600, JTAGICE II and /or JTAGICE III, not once has this kind of issue come up.

[E]

It's my own manufactured board and I'm rather certain that I hooked up everything correctly (the chip works with <8k firmware) so in my opinion it's impossible that some external misconnection can cause this behavior. It has to be a fault in the NVM or the actual silicon chip. I'll hopefully receive another reply from Atmel on monday.

Odd tho, that noone ever seems to have heard of this problem.

Thanks for all the help tho!