Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 14 of 14

Thread: TEENSY 4.0 EEPROM & RAM Questions

  1. #1

    TEENSY 4.0 EEPROM & RAM Questions

    Hi all, i see everywhere that 64K are allocated to recovery and EEPROM but what's the actual size that is used by the EEPROM library?

    Also I see that its has 1MB of RAM but says 512KB rightly coupled, can anybody elaborate on how this is different to an end user from a T3.6?

    sorry if this has been asked before but i couldn't find any info on the forum

    PS: i also was wondering whats the Processor def for the 4.0, i use these for the other teensy models i use

    #if defined(__MK66FX1M0__)
    // Teensy 3.6

    #elif defined(__MK64FX512__)
    // Teensy 3.5

    #elif defined(__MK20DX256__)
    // Teensy 3.2 / 3.1

    #elif defined(__MK20DX128__)
    // Teensy 3.0

    #elif defined(__MKL26Z64__)
    // Teensy LC

    #endif


    Would it be __MIMXRT1062__?

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,551
    Quote Originally Posted by neroroxxx View Post
    Hi all, i see everywhere that 64K are allocated to recovery and EEPROM but what's the actual size that is used by the EEPROM library?
    The EEPROM lib provides 1080 bytes, using wear leveling across 60K of the flash. The last 4K stores the recovery program.


    Also I see that its has 1MB of RAM but says 512KB rightly coupled, can anybody elaborate on how this is different to an end user from a T3.6?
    For most end users using Arduino and libraries, you would just write code the same way as Teensy 3.x and pretty much all other boards.

  3. #3
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,248
    Quote Originally Posted by neroroxxx View Post
    Would it be __MIMXRT1062__?
    No, drop the leading 'M'. It is __IMXRT1052__. There are two leading underscores and two trailing underscores.

  4. #4
    Thank you for the answers! just waiting to see the 4.0 in stock somewhere to get my hands on it!

  5. #5
    Quote Originally Posted by MichaelMeissner View Post
    No, drop the leading 'M'. It is __IMXRT1052__. There are two leading underscores and two trailing underscores.
    Just to be clear, is it __IMXRT1052__ or __IMXRT1062__ ?

    Thanks

  6. #6
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,070
    1062, 1052 will not be used anymore

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,551
    Quote Originally Posted by neroroxxx View Post
    just waiting to see the 4.0 in stock somewhere to get my hands on it!
    Don't wait. If you place an order, you'll get into the queue. First we ship to everyone who has been waiting. Then the website will show "in stock" only if more are left over. We're currently 80% of the way through the 2nd production batch. Odds are slim we'll show "in stock" again for the 2nd batch.

    We did recently send stock to several distributors. Their situation with backorders is probably similar. Maybe you'll find some who show it in stock, before they sell out.

    The 3rd batch is starting production tomorrow. It's a larger batch than the first 2, so in a couple weeks we should have plenty. If you wait for the website to say "in stock", you'll probably get one of those 3rd batch boards.


    And yeah, only __IMXRT1062__. In December 2018 to February 2019, 20 boards were shipped to beta testers with the 1052. I know one of them died and was returned here, so only 19 of those boards exist in the wild. Everyone who has one has been sent either a late beta or final Teensy 4.0 with 1062 chip. Most of the code still has __IMXRT1052__ checks, but the reality is only 19 of those boards exist (outside PJRC - and I have maybe half a dozen here). Everyone who got them also has the new hardware.

  8. #8
    1080 bytes of ram, that's a bit disappointing, I was hoping there would be more than that as I need storage space for user presets, and 1080 only gets me maybe 8 presets

  9. #9
    Junior Member
    Join Date
    Sep 2019
    Posts
    2
    Quote Originally Posted by PaulStoffregen View Post
    The EEPROM lib provides 1080 bytes, using wear leveling across 60K of the flash.
    I was looking at your post on Teensy LC about increasing the EEPROM size. You mentioned that it had a max limit of 254 bytes

    https://forum.pjrc.com/threads/34537...ROM-Size/page2

    Can the Teensy 4.0 EEPROM size also be increased by editing eeprom.h and if so is there also a safe max limit?

  10. #10
    Junior Member
    Join Date
    Sep 2019
    Posts
    3
    From my reading of eeprom.c, it can be increased pretty significantly - up to 0xEC6, for a total of 3783 byte addresses. 0xEC3 is realistically what you should probably set it to if you're storing 32-bit values and need as much space as possible. That's 945 32-bit values.

    0x86F, or doubling the stock amount, is probably a reasonably safe bet. Of course, that halves your write cycles.


    Technical details below:

    The wear leveling took me a minute to understand, but it looks like it groups 32 bits at a time across the 15 flash blocks. It does some bit shuffling on the address to determine an index within each block, with 0xFF being used to mean an unused slot where a value can be stored (this is why there's a max address of 254 in implementations that use a single flash block). I didn't really feel like doing the math on what that means for valid addresses, so I went ahead and wrote a little program to find the first invalid address:

    Code:
    fn main() {
        for i in 0..(256*15) {
            let upper = (i >> 2) / 15;
            let lower = i & 3;
            let idx = (upper << 2) | lower;
            if idx >= 0xFF {
                panic!("{}", i);
            }
        }
    }
    If 945 dwords aren't enough for you, there are a couple ways to eke out a bit more storage:

    There are 42 more valid addresses above 0xEC6, but they're non-contiguous. Any address above 0xEC6 with the bottom two bits set is invalid (that is, any hex address ending in 3, 7, B, or F cannot be used). If you were feeling brave you could set your max address higher and avoid the invalid addresses to get those extra bytes. eeprom.c caps the limit at 0xEF0, but there are valid addresses up to 0xEFE. You'd have to adjust eeprom.c to allow that, though.

    If you don't care about the recovery program, you could possibly also steal its space for a 16th flash block, which would increase the maximum contiguous address to 0xFC2, with 45 non-contiguous values above that point up to 0xFFE. I'm unsure if there are any flash protection settings or fuses that prevent this, and I don't intend to find out on my own Teensies . If you wanted to do this and keep the stock wear leveling, it'd be a max address of 0x47F or 1152 bytes.

  11. #11
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,070
    you could use the flexcan memory region while it’s in freeze mode to access the RAM in that area for temporary data (wiped on reset). They are at offsets 0x080 to 0x47F. Since theres 3 controllers, you have 3 areas for temporary writes. The area must be initialized on reset. That range has 2 memory blocks that can be written in increments as they are next to each other.

    0x47F -0x80 == 0x3FF? ... 1023 dwords ram per CAN controller? ;P

    Since it’s ram you don’t need to worry about wear levelling, copy it to SD/EEPROM over a schedule time while keeping the values updated live in RAM

  12. #12
    Junior Member
    Join Date
    Sep 2019
    Posts
    2
    Thanks for all the info!!! Makes a lot more sense now as to way it is limited. Will be fun to mess around with the values to see what happens. I got a board to learn and play with so I'll only cry a little if I kill all the write cycles lol.

    Forgive me for my ignorance, I'm new to the micro-controller world. With the limit on EEPROM, I'm guessing that means it is really only used for storing configurations and such. Any kind of data logging should be done with either SD card or sending it off to a server. Maybe use the EEPROM to cache data if the connection is lost and what not.

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,551
    Wow, you really read through the code and understood it very well.

    But on this part...

    Quote Originally Posted by Branan View Post
    If you don't care about the recovery program, you could possibly also steal its space for a 16th flash block
    The top 4096 bytes are read-only. As we test each Teensy 4.0, test fixture writes the recovery program and then it sets the flash chip's permanent lock bits to make the top 4K of flash forever fixed to read-only access. You can't erase or alter those last 4096 bytes.

    If you were really determined to get more non-volatile storage, you could try to also use more of the flash chip below the top 64K. You might wish to edit the linker script so the compiler "knows" less flash is available for your code. But the main downside to using flash below the top 64K is Teensy Loader will erase any data each time you upload a new program.

  14. #14
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,188
    FWIW, during T4 beta testing I wrote a little sketch eeprom_meta.ino that would report the underlying metadata for managing the EEPROM wear-leveling. If you updated or added new data to the EEPROM, you could see how the meta data changed. And you could see the result of garbage-collection when a sector became full.
    Last edited by manitou; 09-03-2019 at 02:51 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •