EEPROM problem in AVR-Dx series

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

In AVR-Dx_DFP version 1.5.74, eeprom_write_xxxx does not generate the correct instruction.
Am I forgetting something?

This topic has a solution.
Last Edited: Wed. Oct 21, 2020 - 04:29 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The version of avr-libc you have may not support the NVM controller. I've been messing with this to get it working for the new DxCore Arduino core.

 

This works (using the gcc/avr-libc toolchain included with the latest Arduino IDE):

 

#include <inttypes.h>
#include <avr/eeprom.h>
#include <avr/io.h>

typedef uint16_t eeprom_addr_t;

// to write
void my_eeprom_write_byte(eeprom_addr_t index, uint8_t in) {
  while (NVMCTRL.STATUS & NVMCTRL_EEBUSY_bm);
  _PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, NVMCTRL_CMD_EEERWR_gc);
  *(uint8_t*)(eeprom_addr_t)(MAPPED_EEPROM_START+index) = in;
  _PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, NVMCTRL_CMD_NONE_gc);
}

// to read
uint8_t my_eeprom_read_byte(eeprom_addr_t index) {
  uint8_t r;
  r = eeprom_read_byte((uint8_t *)index);
  return r;
}

Apologies for any cut 'n' paste typos. Header requirements may be different outside of Arduino.

 

Mostly hacked from MPLABX MCC-generated code.

 

Last Edited: Tue. Oct 20, 2020 - 02:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If AVRLibc has been updated, wait for it to be reflected in DFP.
It's annoying, but until then I'll write code that doesn't use the library.

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

BTW folks you know that AVR-LibC is an open source collaborative development? If you have developed working EEPROM routines for AVR-Dx then perhaps you might want to contribute it and see your name in lights?

 

(of course Atmel/Microchip have their own branch of AVR-LibC so I'm not sure what the procedure is for getting that merged into their tree?)

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

It's scary just to think that I update the device-independent eeprom_update_xxxx and eeprom_write_xxxx.

 

If I do it, it will cause bugs, so a smarter person should do it.

Once upon a time, my bug report regarding _PROTECTED_WRITE was completely ignored.
Communication is difficult.

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

I'm happy to contribute to Arduino cores and libraries, but having just downloaded (via svn) the current avr-libc source, I see that the eeprom_ routines are implemented in assembler. I wouldn't feel capable or confident messing with that.

 

And as we discovered elsewhere, the updates have already been made to the current version; they just haven't made it to AS7 or Arduino yet. I can't speak for the average AS7 user, but it's not realistic in the Arduino world to expect people to patch parts of the toolchain. Just gotta wait or work around it.

 

 

 

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

One doesn't have to do it all in Asm, sone parts of LibC are C. The usual reason for Asm seems to be driven by efficiency and the attempt to ensure inlining where possible.