3.5 EEPROM SIZE increase

Status
Not open for further replies.

BHAYES

Active member
Hi all. I need a little guidance.. I can't seem to find any documentation on increasing the eeprom size on the 3.5. I need more room to store some values. I've pretty much filled up the 4096. Any help would be greatly appreciated.
 
Ok after hours of reading what I get from all this info is that I can set the FlexNVM to 126k of eeprom which is already done in the eeprom.c file. But the maximum set size is 4096 bytes. Or 4k. That makes no sense. I've also read that you can set up multiple partitions but no real info on how to do that and is also frowned on or is not ideal. So I'm at a loss.
 
And in the eeprom.c file he used EEPARTITION and the documentation says to us DEPART. So which is right I don't see anything in the docs that says EEPARTITION.
 
It's easy to understand: The flash memory tends to wear out and become unreliable after a few thousands of erase/write cycles. Reading does not affect the flash cells' lifetime.

In order to increase the longevity of the cells, the FlexNVM controller user a much bigger FlexNVM area to emulate a smaller size of EEPROM, using a refined algorithm to map or spread consecutive writes to one EEPROM address on one of 32 totally different cells. This process is called wear leveling. So, the number of reliable write operations and thus the lifetime of emulated EEPROM is multiplied by 32.
 
I don't want to add to the design. The sd has been removed and is too slow for this application. Why is it so hard to increase the size when there is more than enough space there to do what ever is needed. If I can run another 4096 byte partition that would be fine I just can't find how to do it. The documentation states that you can do this. Just doesn't say how.
 
What about a simple and cheap external SPI or I2C flash chip? Or using the SD slot?

Agreed - given T_3.5 has a built in SD socket - if not already used - it would be easy to find a way to quickly write blocks to that. Or adding a larger EEPROM or FLASH chip to store data too big to fit in the EEPROM.

Maybe the data can be compressed or compacted
 
I don't want to add to the design. The sd has been removed and is too slow for this application. Why is it so hard to increase the size when there is more than enough space there to do what ever is needed. If I can run another 4096 byte partition that would be fine I just can't find how to do it. The documentation states that you can do this. Just doesn't say how.

Above post was cross posted - if speed is essential - then it sounds like the updates may be frequent? Even if there is a way to expand the usable write area - that would reduce the redundant data blocks available for sparing the wear for a longer usable life.

Removed the SD socket?
 
Above post was cross posted - if speed is essential - then it sounds like the updates may be frequent? Even if there is a way to expand the usable write area - that would reduce the redundant data blocks available for sparing the wear for a longer usable life.

Removed the SD socket?

Yes this is a custom design. So the sd card was left off. And I'm not talking about a lot of space required. There is 128k of space. I'm looking for 8k of that space. So there will be 120k left. I don't see the issue.
 
Yes this is a custom design. So the sd card was left off. And I'm not talking about a lot of space required. There is 128k of space. I'm looking for 8k of that space. So there will be 120k left. I don't see the issue.

the 128 K of space is segmented - AFAIK all used - and overwritten in turn to minimize reuse of the same area as it would wear out. It also allows a fresh space to be written - perhaps hiding the time to reformat the space before the next write. There is special code and mapping to facilitate this - that implementation is likely were the limitation comes from.
 
Ok I just came across a spec sheet that said it has a 4k x 8 eeprom size. So why is it so hard to find this info.
 
You simply seem to not fully understand the MK64 architecture. You can’t directly access the FLexNVM. If the EEPROM emulation is enabled, the 128kB FLexNVM hide behind the 4K of FlexRAM. Reads and writes from and to the FlexRAM are then dispatched to the FLexNVM by the the memory controller and its wear leveling algorithm.

The reference manual states that the FlexRAM can be divided into 2 partitions, so that a part of the FlexRAM might serve for the EEPROM emulation and another part for other flash acceleration functions. But it states also clearly that the size of the EEPROM emulation can’t exceed the size of the FlexRAM which represents the transparent access door to the EEPROM emulation behind. Sorry, but it’s graved into the silicon and you should not complain here but at NXP.

Basically, the T3.5 data sheet and reference manual were available before you started your project, so you should have been aware of that limitation. Now, I wonder why you decided for the Teensy 3.5 and did even a custom PCB when your software specs don’t fit and you need more EEPROM than provided. It appears to me that something in your engineering process has gone horribly wrong. Normally, if you haven’t been aware of the EEPROM conflict in the design phase, you’d normally have stumbled latest during the prototyping, still with a “series” Teensy, before manufacturing your custom PCBs. Now that the hardware limitations are there, I’d rather consider optimizing my software to deal with the available EEPROM space, if I were you.

Perhaps some runtime-length-encoding could help decreasing the needed EEPROM size.
 
Ok thanks guys. I've read over nxp docs that explains what you've been trying to tell me.. I'm just crap out of luck unless I add some eeprom or put the sd back on.. siggggghhh. Oh well.
 
The simple answer, which I tried to say in msg #2, is "4096 is already the maximum".

But to muddy the waters here with a much more complex answer, indeed the data flash area is 128K. The wear leveling built into FlexNVM has a maximum of 4K. If you wish to use the 128K with wear leveling provided by FlexNVM, then the maximum is 4K. That 4K limit is built into the chip's hardware, so no amount of wishful thinking can cause the FlexNVM hardware to give you more than 4K with the wear leveling.

However, if you write some low-level code to manipulate the flash controller directly, you could instead use the 128K directly, without the wear leveling. But you would need to be careful, because you'd be accessing the raw lower-endurance flash directly. Maybe you would implement your own wear leveling approach in software?

The hardware also supports the ability to partition the 128K, so some is used by FlexNVM with wear leveling to emulate EEPROM, and the rest you can use directly without wear leveling (or with whatever wear leveling you implement yourself in software). So you might assign 64K to FlexNVM, which means you'll be cutting the 4K EEPROM endurance in half. But half is still pretty good. Then you'd have 64K without any wear leveling. Maybe that'd be useful if you have certain data which rarely changes?
 
When you read the reference manual, and when we talk of partitioning, don't confuse divvying the low-endurance flash between FlexNVM wear leveling and direct access with another unrelated FlexNVM feature...

The FlexNVM wear leveling can be configured so that some of the 4K (or less than 4K) uses more of the flash than the rest. It's still using the same amount of flash and giving you the same amount of emulated eeprom, but the flash isn't wear leveled equally. The idea is you have some data which changes more frequently, so you put it at the beginning of the emulated eeprom. That first small section of the eeprom wear levels across half of the data flash memory allocated to FlexNVM, so it has even higher endurance because it wear levels over as much flash as the rest. Obviously the trade-off is the rest of the emulated eeprom has lower endurance, but still much better than using the raw flash.

The reference manual can be quite difficult to read. It's very easy to get unrelated things mentally mixed up. Don't confuse these 2 unrelated partition features. One is how much of the data flash gets used for wear leveling to emulate the eeprom. The other is how the emulated eeprom actually wear levels within that portion of the data flash.
 
To give you a better Idea of what is going on. This is for a engine control unit or aftermarket ecu. The eeprom data is just the tuning variables for the car or motorcycle or whatever it's on. So the changes to the variable will be minimal compared to other projects. Because the tuning only changes every now and then not all the time. So I think using the flash like you were saying really wouldn't be an issue I think. And just to be clear I am a very inexperienced programmer. I know to make pins do what I need them to do and very minimal coding. So what you are talking about is greek to me. LOL. The main core programing for the unit is already done and I'm just adding what I need. I'm eager to learn and want to learn more but I do need guidance on how to do this.
 
Status
Not open for further replies.
Back
Top