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

Thread: Teensy 4.1 - Using the internal flash memory

  1. #1
    Junior Member
    Join Date
    Nov 2020
    Posts
    4

    Teensy 4.1 - Using the internal flash memory

    I was wondering if I could use the internal flash memory to store my sensor data. Is the internal flash faster than a microSD card? My data is collected at about 200Hz and it is about 50 - 100 bytes. I do not want to accumulate large amounts of data in RAM before writing them because I do not want to lose data in case of a power failure/crash. Thanks!

  2. #2
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,921
    Quote Originally Posted by SeanT View Post
    I was wondering if I could use the internal flash memory to store my sensor data. Is the internal flash faster than a microSD card? My data is collected at about 200Hz and it is about 50 - 100 bytes. I do not want to accumulate large amounts of data in RAM before writing them because I do not want to lose data in case of a power failure/crash. Thanks!
    Note, in addition to the flash memory used to hold the program and initial values of the static/global variables, you can solder a second flash memory chip to the Teensy 4.1. Typically something like a W25Q128JVSIQ (128 megabits or 16 megabytes) is used. You can mount a file system on it and use the file commands like you would for a microSD card, or just write to it. In the 1.54 beta versions, they are changing the whole file layer.

    One issue is this memory is cached. That means if your access patterns are small, it will be extremely fast, but as you access more memory, it has to flush the cache. As I said, it likely will still be faster than microSd. However, unlike a microSD card, to get to the flashed memory, you have to have a program to copy it from flash, while with a microSd card, you can just take the card out to the other system.

    Note, if you are using the main flash memory, you need to make sure you get the data before re-programming the Teensy. The secondary flash memory is not erased by re-programming.

  3. #3
    Member
    Join Date
    May 2019
    Location
    Colorado, USA
    Posts
    66
    Hi Sean, data can be stored in flash memory. Look up PROGMEM in the Arduino reference to see how it works. I don't know the relative speeds of SD card vs flash memory, but you could write a quick program to time some reads and writes to get your answer.

    EDIT: My bad... You can only write PROGMEM at program burn time, not dynamically during run time.
    Last edited by KD0RC; 11-22-2020 at 02:03 AM.

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,141
    There is a new TD 1.54 Beta 5 development called LittleFS that allows using a file system on FLASH.
    I'm about to head over to that thread - it has a full chip LOW LEVEL FORMAT that should minimize the long block format times - but the wait SPEW was disabled - writes take 20-30 ms in blocks when the media needed format. It uses a 16MB QSPI Flash on the T_4.1 large underside pinout.

    When formatting is done 'inline' the speed may be +/- similar at times to SD or worse - except for the longest SD blocking. Pre-Formatting external FLASH may result in better write consistency.

    The Internal Flash can be used with LittleFS as well - it is reFormatted fully with each upload - but repower or restarts leave it intact. This is true of ANY bootloader upload BTW. It can use any portion of the Flash not needed for program storage and needs to be specified on startup.

    If the internal Flash is used the data would need to be retrieved before any new code upload using the code already present.

    Also WRITES to the internal Flash storage disables interrupts - this is noted on the LittleFS development thread. 11 pages long now - starts here : LittleFS-port-to-Teensy-SPIFlash

  5. #5
    Junior Member
    Join Date
    Nov 2020
    Posts
    4
    I tried the sd card and it usually takes just under 5 ms to write to it and upto 11 ms on occasion. I need faster write times and I can't have my code blocked for that long. So is writing to flash faster? Plus, my sensors are read using interrupts, so disabling the interrupts wouldn't be acceptable.
    I don't know how to use the internal flash memory to test it for speed. My program is not going to be more than one MB, so the flash memory is more than enough for my purpose. I searched on the internet but didn't find anything helpful.
    Any pointers are appreciated.

  6. #6
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,541
    Maybe you should just use a battery-backup, Battery backed SRAM, or an other memory technology like MRAM. MRAM is expensive.
    Flash and SD are not things you want, if you really need low latency for writes.
    The question ist, if you really need that, or if you can buffer the data.

    What kind of measurements do you do? It would be helpful to know this.

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,141
    Writing to FLASH is not faster in general - and the onboard program flash will stop interrupts to assure the write workas noted on linked thread.

    Also I went and tested preformatted FLASH that was expected then to not have large block format times ... but it currently does :: as noted in this postLittleFS-port-to-Teensy-SPIFlash?p=260480&viewfull=1#post260480

    Getting an 8 MB PSRAM will give the desired and better write times - but will be lost with power. If you can assure no power loss - it will give excellent I/O times for 8 or even 16 MB if two chips are added.

    Indeed SD writes can be slow and go much higher when the card takes efforts to maintain itself.

    The battery backup is in line with Frank_B notes - also how the logging operates could offer options - record to PSRAM in batches if logging can pause - then transfer to SD or other storage.

    Also look for a USB HOST thread - it can write to USB Flash drive, SSD or HDD - I don't remember the lag times that was work done months back as T_4.1 came to market - but the throughput is good.

  8. #8
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,541
    Or lift the VCC pin of a PSRAM and connect a battery there.
    Should work, I think. If there is no code that erases the RAM on reboot.

  9. #9
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,141
    Quote Originally Posted by Frank B View Post
    Or lift the VCC pin of a PSRAM and connect a battery there.
    That seemed interesting - but haven't tried it yet ...

  10. #10
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,541
    Quote Originally Posted by defragster View Post
    That seemed interesting - but haven't tried it yet ...
    Me too Maybe it gets erased on reboot. But it shouldn't be too hard to modify that, if that's the case.
    Anyway, without knowing more details, and how Sean measures his data, its difficult..

  11. #11
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,141
    Quote Originally Posted by Frank B View Post
    Me too Maybe it gets erased on reboot. But it shouldn't be too hard to modify that, if that's the case.
    Anyway, without knowing more details, and how Sean measures his data, its difficult..
    When SPIFFS was testing in PSRAM it would survive a restart IIRC. I don't think that changed with the check for chip to exist and do the setup.

    I looked at it wondering about using 3V3 when powered and having the battery takeover when that went down - and that was beyond me - and VCC was noted as not allowed below signal levels on other pins IIRC - or some other complications the SPEC indicated.

  12. #12
    Senior Member
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    115
    If you are worried about power failure why not use one of these with an 18650 battery to power your teensy. Keep it (the battery) powered all the time and should the power fail, with a 3000mAH battery for backup, you should be good for quite a long time before the power comes back on.

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,385
    Logging data to the program memory requires completely disabling interrupts while the chip is busy, so it is not a good solution if you need to keep continuously collecting incoming data while the memory is writing.

    Indeed, expensive MRAM or battery backed RAM are probably the only ways which write quickly enough to not require doing anything special with incoming data.

    But you could use something like IntervalTimer to run your data collection and write it to a circular buffer in memory. Then in the main program, read data from that buffer and write it to flash or SD card. Both can have substantial write latency, so choosing a large enough buffer is important to avoid data loss.

  14. #14
    Junior Member
    Join Date
    Nov 2020
    Posts
    4
    The Teensy will be reading several sensors at 1khz, and several at lower rates through IIC and SPI. Data reads are triggered by interrupt pins on sensors. Data read would be processed and output PWM signals set at about 50hz. I approximate the data capacity needed for one hour of operation is about 64MB. The processor should remain responsive at all times and can't be blocked for too long. After researching more and reading your kind inputs, it seems like MRAM/FRAM or battery backed SRAM are possible options. Issue with MRAM/FRAM option is that they are not cheap and don't provide larger capacities. I wonder if this chip "CY15B104Q-SXI" could be soldered to the Teensy 4.1 pads?
    Another possible solution could be, using another Teensy to receive the data from the main Teensy through SPI and handle the SD writes at a lower rate. How fast could the SPI run between two Teensy boards?
    Now for a battery backed SRAM solution, are there larger capacity chips available that I can solder to the pads and connect their power to a backup battery?

  15. #15
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,541
    Quote Originally Posted by SeanT View Post
    The Teensy will be reading several sensors at 1khz, and several at lower rates through IIC and SPI. Data reads are triggered by interrupt pins on sensors. Data read would be processed and output PWM signals set at about 50hz. I approximate the data capacity needed for one hour of operation is about 64MB. The processor should remain responsive at all times and can't be blocked for too long. After researching more and reading your kind inputs, it seems like MRAM/FRAM or battery backed SRAM are possible options. Issue with MRAM/FRAM option is that they are not cheap and don't provide larger capacities. I wonder if this chip "CY15B104Q-SXI" could be soldered to the Teensy 4.1 pads?
    Another possible solution could be, using another Teensy to receive the data from the main Teensy through SPI and handle the SD writes at a lower rate. How fast could the SPI run between two Teensy boards?
    Now for a battery backed SRAM solution, are there larger capacity chips available that I can solder to the pads and connect their power to a backup battery?
    64MB is very difficult. There are no SPI-chips with that size as far as I know.
    Your chip CY15B104Q-SXI is 4Mbit.
    So, I think SD is your only option. Or the 2nd Teensy with SD.

    SPI? Around 80..100MHz.

    But 1kHz is dead slow. Buffering should be easly possible.

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,385
    This flash chip might be an option. It's 64 Mbyte and only $5. I already have some on order with plans to support them in LittleFS.

    https://www.digikey.com/en/products/...JVEIQ/10244706

    The WSON8 package is difficult but not impossible to solder onto the pads on the bottom of Teensy 4.1. Much easier if you solder it before any headers or sockets which tend to obstruct soldering iron access.

    You will still need to use an interrupt or other way to collect data into a buffer while the chip is busy writing.

    That expensive FRAM might also be an option if you connect it to SPI. But with a 40 MHz max frequency, it's much too slow to be used on QSPI. It's also only 0.5 MByte size.

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,385
    If you read other threads, you'll see we've also talked at times about NAND flash chips. Today none of those are well supported. They require software to manage and remap bad blocks. NAND also has slightly worse latency. But the sizes are great, 128 Mbyte is cheap and 256 MByte is expected next year. Eventually we will support these, but it may be many months away. Best to avoid any NAND chips right now, unless you really want to get into writing that bad block management code...

  18. #18
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,141
    Yeah the static memory options are smaller 128KB'ish at $10'ish each. So hooking a second Teensy to buffer and push to SD would be a decent alternative. And the glance seen showed them to be i2c or SPI - not perhaps QSPI? - and slower speeds than the QSPI chips are running.

    64MB/hour - about 1 MB /minute isn't too much - given SD writes are greater than 1MB/sec - just fitful in timing.

    But the largest/only PSRAM seen/supported so far is just 8MB with room for two.

    SPI is Multi wire and short distance. @tonton81 made a GREAT FAST data checked tool for SPI connect of T_3.6 and earlier - but not sure it got updated for T_4.x support?

    Given that SPI is short wire - so is UART Serial and at 5M baud or less {1M baud is 100 KBytes/sec) with good buffers on both ends there should be a way of transferring 19 KB per second to the second Teensy over UART. And for the same 4 wires (as SPI) TWO Serial# UARTS could be alternated in parallel for alternate streams if that might help.

    T_4.1 also has USB Host that can run as USB Serial to plug the second Teensy into. Assuming that is DMA and non-blocking the main T_4.1 could export the data using that to a second T_4.1 as device for parsing and logging with 512 Byte USB packets at some decent part of 480 M bits/sec those ports run at. That would take good 5V power to the main T_4.1 to run the second Teensy though. @KurtE just improved this and other TD 1.54 beta distractions have kept from testing it here.

  19. #19
    Junior Member
    Join Date
    Nov 2020
    Posts
    4
    I was not able to find a large enough NVRAM solution and that was surprising to me. I like the UART suggestion and I will keep that in mind for possible upcoming needs. Is the UART hardware controlled? I setup another Teensy 3.6 to receive the data through SPI and save it to the SD card. I used tonton81's SPI slave library to code the slave Teensy. The setup worked but it was not reliable. The responses sent from the slave were randomly corrupted. But the main issue I had was that the slave would continue calling the SPI ISR (not resetting the interrupt) even when the select pin went high, and that was the deal breaker. Maybe you guys can point me to the right place to figure it out. So I continued looking for another solution. I learned that the SDfat library does not disable interrupts, so I decided to try an interrupt based sensor reading and let the SD card take its time while the reads happened. It worked. This is a more elegant solution and I do not need a second Teensy to save data and I don't miss any sensor reads. Here is an image of the scope.
    Click image for larger version. 

Name:	2020-12-19.jpg 
Views:	10 
Size:	53.2 KB 
ID:	22887

    I appreciate everyone's inputs that pointed me to the right direction. I will be back with more questions as this project is ongoing.

Posting Permissions

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