Mon 07 Mar 2016 09:16:44 PM UTC, comment #3:
This must have been something in my environment. I rebuilt everything from scratch, using gcc 5.3.0, binutils 2.26 and avr-libc 2.0.0, and now it works.
Could you please close this bug as invalid?
|
Wed 10 Feb 2016 10:03:38 PM UTC, comment #1:
Sorry, I was writing the bug as I was debugging. The paragraph that starts out "In the XMegaE series" is confusing and conflicting.
The problem is this:
For the XMegaE5, the #if defined() statement is making the wrong choice. It should be compiling in the #else block, but it is not. If only the #else block is left in the code (that is what the attached patch does) then it works.
|
Wed 10 Feb 2016 09:53:54 PM UTC, original submission:
This bug is in 2.0.0.
None of the eeprom write or update functions work on the XMega32E5. It seems to be a problem stemming from this block of code starting at line 119 in libc/misc/eewr_byte.S:
#if defined (NVM_EEMAPEN_bm)
std Z + NVM_DATA0 - NVM_BASE, r18
#else
movw XL, addr_lo
subi XL, lo8(-MAPPED_EEPROM_START)
sbci XH, hi8(-MAPPED_EEPROM_START)
st X, r18
#endif
In the XMegaE series the memory mapping can't be turned off (it doesn't have NVM_EEMAPEN_bm) so it uses the code in the #else. However, this code seems to do nothing. If the code is changed so that it uses the line under the if statement, it writes the eeprom properly. I tested it using the patch attached, but I don't know enough about the other XMega processors to know if it will break anything else.
As I dig into this more I am confused, though. NVM_EEMAPEN_bm is not defined for the E5 series, in the ioxXe5 header files. Yet if the code, before this patch, seems to be building like it has that defined. The patch was just removing the #if statement, only leaving what is in the #else block. That should have been what was built for the E5.
|