looking at Paul's core github (eeprom.c), the LC appears to be configured for only 128 bytes of EEPROM.
#define EEPROM_SIZE 128
Hopefully your writes and changes to that EEPROM area will be minimal as it doesn't have the size and support for robust wear leveling on the T_3.2 processor - especially when you are going from 1 to 16 mapping to a 1 to 2 mapping:
#define EEPROM_SIZE 240
#define FLASH_BEGIN (uint16_t *)61696
#define FLASH_END (uint16_t *)65536
#define EEPROM_SIZE 240
#define FLASH_BEGIN (uint16_t *)50176
#define FLASH_END (uint16_t *)65536
#define EEPROM_SIZE 240
#define FLASH_BEGIN (uint16_t *)50176
#define FLASH_END (uint16_t *)65536
#define EEPROM_SIZE 256
#define FLASH_BEGIN (uint16_t *)61440
#define FLASH_END (uint16_t *)65536
Right, Paul.The maximum size is 255 bytes, not 256. If you set to 256 or higher, you will experience problems.
You are looking at the wrong thing. The Teensy LC isn't using hardware flexmem:Right, Paul.
I did a bunch of reading, mainly on this page:
http://cache.nxp.com/files/32bit/doc/app_note/AN4282.pdf
In fact I had to read it several times even too get my brain loosely wrapped around how flexmem works. It seems that we are stuck using power's of two, so I went with 256. However the define I use in my sketches is 255. I assume this is the correct approach?
if (offset < EEPROM_SIZE) {
//STARTING FROM FLASH_BEGIN AND GOING TO THE LAST RECORD
while (p <= end) {
val = *p++;
//IF THIS IS A RECORD OF INTEREST, UPDATE data
if ((val & 255) == offset) data = val >> 8;
}
}
I would seems for controllers using emulated EEPROM (Teensy 3.x, Teensy LC) there is no reason to implement some sort of EEPROM write leveling inside sketches.