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

Thread: Usable flash on Teensy-LC

  1. #1
    Junior Member
    Join Date
    Oct 2015
    Posts
    15

    Usable flash on Teensy-LC

    According to NXP's manual, the chip used on the Teensy-LC (MKL26Z64VFT4) has 64K of flash.
    I'm attempting to reseve the top 2 kB for nonvolatile storage, so I have a section located at the end of flash (using a Gnu ld script) and put some 'variables' in it. Examining the resulting map file, these variables are correctly located, 2K down from the top of flash.
    However, attempting to load this image into the LC, the programmer throws an error '... is too big'. Indeed, PJRC's data on the LC (https://www.pjrc.com/teensy/techspecs.html) says it only has 62K available, and if I define the end of flash as (0+62K) everything works OK.
    My question is, why is the 'available' flash on the LC different from that shown on NXP's datasheet for the MKL26Z64VFT4, but is the same for other devices (e.g. that used on Teensy 3.2)?

  2. #2
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,583
    upper 2K of LC flash is used for EEPROM emulation.

  3. #3
    Junior Member
    Join Date
    Oct 2015
    Posts
    15
    Manitou, thanks for the response. Do you mean 'the Arduino runtime system uses the top 2K to implement an EEPROM emulator'? (This isn't an Arduino project - is the [what I thought was completely generic] Teensy programmer making an assumption here?)

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,637
    Yes, Teensy Loader only writes to the first 62K. It will not erase or write the top 2K.

    You can use that top 2K however you like. But Teensy Loader won't write to it for you. You'll have to run code to write there. Look in eeprom.c in the core library for the code Teensyduino uses to write to that top 2K if you would like an example.

  5. #5
    Junior Member
    Join Date
    Oct 2015
    Posts
    15
    Thanks Paul. Not really a problem for me because I'm not running out of program memory and I could construct something (as you suggest) to access that region of memory at runtime. It's vaguely irritating that the (low-level) loader makes an assumption about the (high-level) system runtime memory usage but anyway that's all explained now, thanks.

Posting Permissions

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