Teensy LC Increase EEPROM Size

Status
Not open for further replies.
I did some editing....Seems to work, but I don't know if this is going to cause any other issues.
Code:
#define EEPROM_SIZE 256

#define FLASH_BEGIN (uint16_t *)61464
#define FLASH_END   (uint16_t *)65536
 
It's definitely causing some issues, but I suspect a little more hacking and I might be bale to get this to work.
 
The Teensy LC eeprom emulation code is designed to only go from 0 to 254. The address 255 is used to detect not-yet-used memory.
 
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:

I'm not sure on the maths, but if I need at least 212 bytes, how would I adjust the FLASH_BEGIN define so get optimal wear leveling given that I can sacrifice about 20k of flash.

Regards,
Rob
 
Would these settings preserve the 1 to 16 wear leveling?
Code:
#define EEPROM_SIZE 240

#define FLASH_BEGIN (uint16_t *)61696
#define FLASH_END   (uint16_t *)65536

And could I improve on the 1 to 16....Maybe going up to 1 to 64.
Code:
#define EEPROM_SIZE 240

#define FLASH_BEGIN (uint16_t *)50176
#define FLASH_END   (uint16_t *)65536
 
Last edited:
based on the linked thread there is a physical pool of 2048 bytes. So anything over 128 bytes won't give 16:1. I haven't tried to see the code involved and don't know if there is any overhead or are any boundaries or restrictions on access - but if it handles any case and has 2048 bytes with no overhead then 9:1 would give you 227 bytes 9 times over - and Paul says you can only go as high as 255, resulting in an 8:1 mapping. At some point abusing access to that area over time will render it unusable if you thrash it.
 
as far as I can tell, the size of the pool is controled by the FLASH_BEGIN define. The idea is that you don't only have control over the size of the EEPROM (which is currently maxed out at 254), but also the size of the pool.

Code:
#define EEPROM_SIZE 240

#define FLASH_BEGIN (uint16_t *)50176
#define FLASH_END   (uint16_t *)65536

You can see that the size of my 'pool' here is 15,360 bytes (240 x 64). I'm not sure if my logic is correct here or not. I'm doing some reading....

Regards,
Rob
 
I have found one rather significant issue. My EEPROM is getting erased every time I upload a new sketch. Is this normal behavior for Teensy LC chips, or is this a consequence of my edits. Perhaps I need to change another define somewhere for the the loader not to erase an extra 2k of RAM when programming?

Code:
#define EEPROM_SIZE 256

#define FLASH_BEGIN (uint16_t *)61440
#define FLASH_END   (uint16_t *)65536
 
Last edited:
That's probably the case. I modified my Teensy LC code size in my firmware updater, but the emulated EEPROM is still getting trashed.
 
...I can definitely confirm that if I put everything back to 128 bytes, EEPROM is preserved between uploading of firmware. It also seems that if I keep the pool at 2K and put the EEPROM size to 256, the EEPROM survives....
 
Last edited:
The maximum size is 255 bytes, not 256. If you set to 256 or higher, you will experience problems.
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?
 
In eeprom.c, I've changed the EEPROM size from 128 to 256. I've used 256 instead of 255 because I've read elsewhere that the size needs to be a power of 2.

//#define EEPROM_SIZE 128
#define EEPROM_SIZE 256


I've also edited ..\avr\eeprom.h, changing the E2END from 0x7F to 0xFE (255)

#elif defined(__MKL26Z64__)
//#define E2END 0x7F
#define E2END 0xFE
#else

In my own code I use my own define to limit the addresses I write to.
#define ME_EEPROM_SIZE 255

Am I understanding this correctly. I'm planning to start selling a product using this code soon. Should I be setting the EEPROM_SIZE define to 255 as well?

Regards,
Rob
 
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?
You are looking at the wrong thing. The Teensy LC isn't using hardware flexmem:
https://forum.pjrc.com/threads/2762...low-cost-Teensy)?p=63542&viewfull=1#post63542
 
So I've spent the last couple nights trying to really understand how emulation works, and I feel like I'm getting my head wrapped around it.

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. If I understand the code correctly, doing so would actually make the emulated EEPROM fail more quickly.

Also I was curious about this snippet from the eeprom_read_byte method:
Code:
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;
		}
	}
Wouldn't it be more efficient to start at the last record and work back to the FLASH_BEGIN, returning the first occurrence of the record we are interested in?
 
Last edited:
So I reversed the reading function to start at the latest record and work back to FLASH_BEGIN, and it seems to work fine. Should improve read time significantly. I also added a call to eeprom_read_byte method inside the eeprom_write_byte method to avoid adding duplicate records.
 
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.

Correct, the EEPROM emulation code is already wear leveling your writes across a larger block of flash memory.
 
Status
Not open for further replies.
Back
Top