Using FRAM and Non-QSPI Chips On Teensy 4.1 PSRAM RAM Expansion Pads

Status
Not open for further replies.

Michael2

Member
Setup: Teensy 4.1, VisualTeensy, VScode, Modified copy of Teensy Core in project folder

I have a project where I want to add non-volatile memory but I want to be able to access it using "EXTMEM" or an equivalent just like when adding on an extra PSRAM chip to the Teensy 4.1.

I came up with two possible ideas but I don't know if they will work.
First: Use a QSPI SOIC-8 FRAM or MRAM chip
Second (I really don't want to do this): Use an SPI NVSRAM chip and somehow connect the battery to it using some wire and solder

Question 1:
I was wondering if it was possible to somehow use a chip that did not have QSPI (only SPI) (Maybe by disabling QSPI in "setup.c"?). This would allow the use of a SOIC-8 NVSRAM chip like the 23LCV1024 on the PSRAM pads. Then you could just solder some wires onto it to connect it to the battery.
If you could use standard SPI that would increase your choices for FRAM/MRAM chips too.

Question 2:
Could I just swap the PSRAM out for a QSPI SOIC-8 FRAM chip like the CY15B104QSN-108SXI? or an MRAM chip like the M1016204 I don't see why it would not just work (plug&play) other than differences in how the FRAM and PSRAM communicate like different addresses or commands or something.
 
Last edited:
When the MRAM's were searched during T_4.1 Beta - usable QSPI's weren't found/tested.

This looks good except for the 1.8V:
Non-Volatile 16Mb High Performance MRAM, 1.8V
The M1016204 series is a 16Mbit high performance non-volatile MRAM with speed up to 108MHz.

The first linked : Excelon™-Ultra 4-Mbit (512K × 8) Quad SPI F-RAM
Decent size - for a price ... $25.34
Does show a part w/MAX 3.6V accepted: 16 mA (typ) active current for 108 MHz QSPI SDR
> As SOIC 8 that might bottom mount and map into EXTMEM for direct addressing - but would take coding work

@mjs513 might give it a look and confirm the pinout is right and there aren't any stopping issues.
 
The simple answer to most of these "it is possible" questions is: no, not really, unless you resort to bitbanging SPI.


I don't see why it would not just work (plug&play) ....

First, as Defragster mentioned, the power and signals are 3.3 volts. If you solder a 1.8V or 2.5V chip, it'll be ruined.

Second is the SPI hardware. The IMXRT chip has 2 completely different types of SPI hardware, called FlexSPI and LPSPI. Sadly, when NXP designed the chip, they didn't route them to the same pins in a way where you could connect a chip and then in software decide which of those actually controls the pins. So when soldering a chip to the bottom of Teensy 4.1, you only options are extremely fast FlexSPI or slow software bitbanging. The pins just aren't mapped in a way where LPSPI can work. The main limitation of FlexSPI is it's extreme speed. You just can't use slow SPI chips like 23LC1024. FlexSPI just can't clock that slow.

Third is the software side. For chips very similar to the ones already supported, often porting is pretty simple. But if you're going to stray off the well worn path, the complexity of FlexSPI and figuring out how to program its LUTs awaits you. Now that we have more code for many chips, it's not the daunting task it once was, but still not something to underestimate.
 
An even more simple answer is, that the PSRAM chips just need power to keep their data. If you lift of the VCC pin and _not solder it to that pad and provide its power by using an other method it should work.
Unfortunately, they are not designed to be very power saving..
 
Last edited:
I'm not sure if this will help, but I was also looking to add extra memory to a Teensy. My goal was to mimic an SD card with an external memory chip to save data, then later dump the contents of the memory chip to an SD card--long story.

I finally got an SPI based memory chip to work using with a teensy 4.0.

https://ww1.microchip.com/downloads...V-SPI-Serial-Flash-Data-Sheet-DS20005397E.pdf

My code has a few functions such as Print and Println so you can use the memory chip like an SD card Print("the cat in the hat") for example. No file creation and such but at least i got something working.

If you want my code, you are more than welcome to it.

Kris
 
Just for reference LittleFS does support SPI FRAM. Specifically, the:
Code:
Cypress	CY15B108QN-40SXI	8Mb
...	FM25V10-G	1Mb
...	FM25V10-G rev1	1Mb
...	CY15B104Q-SXI	4Mb
ROHM	MR45V100A	1Mb

@KrisKasprzak - the commands for the Microchip look like you could add it to littlfs for spiflash but not QSPI would have to look closer at the commands to get it working though. At 40Mhz it does look similar to FRAM.
 
When the MRAM's were searched during T_4.1 Beta - usable QSPI's weren't found/tested.

This looks good except for the 1.8V:


The first linked : Excelon™-Ultra 4-Mbit (512K × 8) Quad SPI F-RAM
Decent size - for a price ... $25.34
Does show a part w/MAX 3.6V accepted: 16 mA (typ) active current for 108 MHz QSPI SDR
> As SOIC 8 that might bottom mount and map into EXTMEM for direct addressing - but would take coding work

@mjs513 might give it a look and confirm the pinout is right and there aren't any stopping issues.

Looks like the pinouts are the same but as @Paul said if you want to use it as QSPI going to take work.
Third is the software side. For chips very similar to the ones already supported, often porting is pretty simple. But if you're going to stray off the well worn path, the complexity of FlexSPI and figuring out how to program its LUTs awaits you. Now that we have more code for many chips, it's not the daunting task it once was, but still not something to underestimate.
 
Good the pinout follows the QSPI standard. And it does offer needed higher 108 MHz speed, unlike the slower clocked SPI's. And using as SPI won't map to EXTMEM the same way as the QSPI work does.

Indeed also posted : "would take coding work"
 
So if I understand correctly,
I will need to make sure it is a 3.3v chip
First, as Defragster mentioned, the power and signals are 3.3 volts. If you solder a 1.8V or 2.5V chip, it'll be ruined.
I will also need to check the pinout (and package size)
Looks like the pinouts are the same
and I need to make sure it is QSPI because the pins are FlexSPI only
You just can't use slow SPI chips like 23LC1024. FlexSPI just can't clock that slow.
But I am unfamiliar with how these memory chips work so explain to me on a basic level how would the chips be similar/different to eachother than the memory technology, package, and interface. If you have MRAM, SRAM, PSRAM, FRAM chips and they all have QSPI and the same pinout, package size, voltage, speed, etc, what would require you to use different code or software for each one?
For chips very similar to the ones already supported, often porting is pretty simple
My guess would be the commands they use or something, but again I don't know much about any of this.
 
That's where "would take coding work" comes in - as Paul mentioned -: " the complexity of FlexSPI and figuring out how to program its LUTs awaits you."

For QSPI there is some LUT, say 'microcode', it seems that controls the interface to the chip addressing and I/O as needed - never looked at it as it got worked out for the PSRAM - then the supported FLASH NOR and NAND chips.

The MRAM and FRAM - were only SPI so not clear if theses are subtle changes or more as Paul indicated to figure out.

Some sources:
\hardware\teensy\avr\cores\teensy4\startup.c
\hardware\teensy\avr\libraries\LittleFS\src\LittleFS.cpp
\hardware\teensy\avr\libraries\LittleFS\src\LittleFS_NAND.cpp
 
But I am unfamiliar with how these memory chips work so explain to me on a basic level how would the chips be similar/different to eachother than the memory technology, package, and interface.

Each chip has a distinct set of commands it supports. To really understand, I want to emphasize that you really must read the datasheets carefully.


For example, here's the PSRAM from page 9 of its APS6404L_3SQR datasheet.

a1.jpg


For comparison, here are the commands the flash memory chip on Teensy 4.1 supports, from pages 24-27 of the W25Q64JV-DTR datasheet.

a2.jpg

a3.png

a4.jpg

a5.png
 
The supported commands tables aren't the only difference. Again, it is critically important to actually read the datasheets carefully if you intend to write the code which will access each chip.

An important detail about the flash chip is its 3 different status registers, which are 6 of the commands in 2 of those tables. The meaning of each bit or group of bits within those status registers is documented in the datasheet. If you will only read and write raw data, you might only need 1 bit from the first register, which lets you ask the chip if it's still busy with the previous write or erase operation. But if you will use more of the chip's special features, those other bits are there for reasons....

The PSRAM chip has no status registers at all. But it's far from simple, even though it has a small table with just 11 supported commands. Like most of these chips, it has simpler command which only work at relatively slow clock speeds, 33 MHz max for this PSRAM chip. I believe we're running FlexSPI2 at 88 MHz on SCK, so you can't use those commands unless you lower the clock speed (and whether it can run slower than 49 MHz is a good question). Like most of these chips, it has a QPI mode where the commands are 4 bits wide, and SQPI commands where the first byte uses only 1 data pin, then the rest of the command uses all 4, and some commands which use only 1 data pin. If you want the low latency of QPI mode, you need to write code to make sure the chip gets into that mode.

Comparing with the flash chip, it also has a QPI mode. But the similarity of commands ends when you move beyond the most basic stuff. PSRAM uses command 0xF5 to go from SPI to QPI mode. Winbond uses 0x38.

This particular flash chip also has DDR / DTR commands, where data transfer is done twice per clock. But it doesn't support those up to the full clock frequency, so they're not really much more efficient than data once per clock cycle.

While there is a lot of similarity, especially between chips from the same manufacturer using the same memory technology, some chips are *very* different. For example, the NAND flash chips don't have a single read command at all. Instead you send a command which causes the chip to fetch 1 row from its memory matrix into a special buffer. Then you have to query a status register to wait while it fetches the data and does error correction. Then you can use other commands to fetch some of all of that buffer, or access the extra bits for the error correction & other special info.

This is why you must carefully read the datasheets for the chips you will use. The specific commands each chip supports and use you use those commands and whatever internal registers the chip provides can vary quite a lot.
 
Ok, I think I am out of questions and thank you all for the help! I am definitely way over my head but I always like to understand as much as possible to build up my knowledge base even if I know I don't have the skills or knowledge (Yet!) to follow through with my ideas.
You guys were very helpful and you were patient with me even though I literally have the knowledge and understanding of a high schooler (I am in 11th grade). I have never met a kinder community online and I look forward to talking to you guys in the future and being part of this amazing community!
 
Update:
I tried but I could not keep myself from continuing to research and try to make this work. I really did try to stop multiple times.
So basically I modified the teensy 4 core and after hours of reading the imxrt documentation and googling literally everything I read, I finally think I got it.
I would appreciate it if someone smarter than me would take a look at it and tell me if it might work.

https://github.com/Michael2MacDonald/teensy4_core_extmem_improvments

I basically added a second memory section in the linker file and allowed you to change the size of both sections using the makefile or the arduino tools menu in the ide. This allows you to use 1 or 2 memory chips and it allows you to use them separately using 'EXTMEM' and 'EXTMEM2' or you can configure the first memory section to cover the size of both chips allowing you to use them both with 'EXTMEM'. I also added the ability to change the instruction set to one of two presets (teensy PSRAM or AS3001204) for each chip. It is built in a way that should be easy to add more instruction sets for different chips to expand the options to choose from. By default, it is set up to work normally with the teensy PSRAM chips without the need to change or set up anything.

There is still a lot to improve and add (I have not touched the extmem.c file with the alloc() functions) but it is a good start if it works.
 
Status
Not open for further replies.
Back
Top