Non-volatile alternatives for PSRAM.

P

Peter_R

Member
Moving my queries to a more relevant thread since PROGMEM was not the problem ...

I did a search and found this thread, which contains a link to a GitHub project.

This project contains a number of updates to enable the use of MRAM and varying memory sizes on the extra memory pads.

Has anybody used this? What results did you get?

Before fitting any MRAM I decided to try it with the standard PSRAM, which it should handle due to its claimed backward compatibility but sadly I am having problems, the standard setup works as expected but the updated file version causes memory corruption.

Not sure if the author is still here, his account went quiet about two years ago ...
 
Sorry, I don't have any answers about that code, as I've never used it.

But I do have a quick question. As I recall, on your other thread you mentioned a MRAM part number which can handle 100 MHz clock speed. Most of the other MRAM chips people have mentioned are limited to speeds too slow for FlexSPI. Can you give that info here? Also can you mention where to actually buy this speedy MRAM part?
 
Don't recall ever seeing signs of that github author here posting notes on the work.

If there is a FAST MRAM option of decent size and usable QSPI operation - it would be higher cost - but cool.

BTW: PSRAM does survive across WARM restarts (Teensy never loses power) - as long as it doesn't lose power or get wiped on restart. Initial LittleFS RAM did that and then got set to always wipe. Quick changes to test on start for valid signature, and also add cache flush on every write for the data to be stored on warm restart.
 
defragster said:
BTW: PSRAM does survive across WARM restarts (Teensy never loses power) - as long as it doesn't lose power or get wiped on restart. Initial LittleFS RAM did that and then got set to always wipe. Quick changes to test on start for valid signature, and also add cache flush on every write for the data to be stored on warm restart.
Click to expand...
It does but it shouldn't; it's a violation of C spec for uninitialized static variables to not be set to zero.
 
Density ranging from 1Mbit to 16Mbit. MRAM (AS3001204, AS3004204, AS3008204, AS3016204)
MRAM.png
 
defragster said:
Don't recall ever seeing signs of that github author here posting notes on the work.
Click to expand...
He gives the GitHub project reference at the end of this thread ...

PaulStoffregen said:
I ordered a few AS30042040108X0PSAY from Mouser. With the holiday and ground shipping, like to arrive sometime after next week.
Click to expand...
Not too expensive so I ordered mine before Christmas, so they are due now (Monday as FedEx don't normally deliver at the weekend).

As I said, I tried the updates with the standard PSRAM, which is supposed to work unaltered but I saw data corruption.
The problem lies in the startup.c file, I thought it may be a misconfiguration on my part but I think I tried every sensible variation so it leaves me wary of trying the MRAM.
 
jmarsh said:
It does but it shouldn't; it's a violation of C spec for uninitialized static variables to not be set to zero.
Click to expand...
Like Flash chips outside the processor are set to zero? It is an external storage device - especially if it can maintain data across restarts like those things.
 
Peter_R said:
I was referring to his posting notes on his work, not on the price of MRAM (which I bought 512k pats from Mouser ...).
Click to expand...
Correct - The alien face was because 'defragster' posted on that thread 3+ years ago. And bringing forward the note on pricing as more reasonable now.
 
defragster said:
Like Flash chips outside the processor are set to zero?
Click to expand...

Flash memory isn't uninitialized static variables. PROGMEM is const which requires initialization.

But DMAMEM and EXTMEM are indeed static uninitialized, which probably does run afoul of the spec. A few times questions have come up because we don't support initializing them at startup. I would really like to find a way to make that happen, but so far all my attempts have ended with linker script frustration. If anyone can demonstrate a way to make this work, I would really like to put it into future core library releases.

As for MRAM, despite the official C spec, wiping it at startup would obviously not be a "feature" anyone would want.
 
Even if pre-Zeroed - any Free()'d memory would then need to be zero'd on return. Not an issue for perpetual allocations.
CrashReport takes advantage of this persistence in RAM2/DMAMEM. Extending that to purposeful RAM2&PSRAM usage for data access in warm restart case seems a user choice: lost data versus exposed data.
Like QSPI Flash the QSPI PSRAM is given reserved memory space - but is a 'user' controlled space/device.
 
defragster said:
If zero for first use - it would need to be zero for re-use? Not sure of all the reasons behind the spec - but handing out somebody's used data comes to mind?
Click to expand...
Static uninitialized data should be zeroed. Memory handled by malloc/free is not static, it is dynamic. If you want a dynamic allocation to be cleared when allocated you should explicitly use calloc.

If you have int foo EXTMEM; then the value of foo must be 0 when the program begins. Currently that is not the case because EXTMEM is not cleared at startup, which can cause some pretty major bugs.
 
Okay, so my MRAM has arrived and I have fitted one to an unused Teensy 4.1.

Testing my project with the updated code fails with MRAM in a similar way to the PSRAM failure I originally noted.

So, my conclusion is that either I am not configuring it correctly or there is something wrong in the updated code, which explicitly states it is untested ...

Looking into this is a project in itself and I have other work on my project to pursue and whilst I may get lucky and get something to work, the code would be highly unlikely to be anything other than a 'nasty hack'.
So, hopefully, one or more of you more accomplished developers who have shown interest in looking at MRAM will get a chance to make some headway soon.
 
Peter_R said:
accomplished developers
Click to expand...
@PaulStoffregen has parts ordered and will look at making it work Not sure of his schedule to look into it, but if it can work it will. Added one MRAM to an order for another item and ready to test.

If a known correct PSRAM was tested with untouched shipping PJRC TeensyDuino code and failed to work with a simple example and the chip was properly oriented, then the issue would likely be bad solder or presence of soldering Flux that needs to be cleaned.
 
defragster said:
If a known correct PSRAM was tested with untouched shipping PJRC TeensyDuino code and failed to work with a simple example and the chip was properly oriented, then the issue would likely be bad solder or presence of soldering Flux that needs to be cleaned.
Click to expand...
Let me clarify:
The "PSRAM failure I originally noted." refers to a data corruption problem using the updated core code, not a hardware problem.
In my project code I set up my array of structures and then initialise it to all zeros:
The standard core code works perfectly, as expected, whilst using the updated core code the array initialises to a variety of zero and non-zero values (I sample at given points rather than dump the whole array).
 
Peter_R said:
Let me clarify
Click to expand...
Good note, wasn't sure if that was the alternate LIB or the 'untouched shipping PJRC TeensyDuino code' in use.
So, a good PSRAM is mounted and working as it should with PJRC code..

Seems that if the MRAM can MAP usably onto the QSPI at speed, it will take a unique 'interface' for its likely unique access commands - like FLASH .vs. PSRAM. That would require those LUT CMDS and then a unique access path to trigger those versus the PSRAM.

The fact that the PSRAM won't work with that Alt Lib suggests the efforts made didn't make good changes.

@Paul - Mouser to deliver MRAM here tomorrow - seems one of those and a PSRAM would make a good test T_4.1 when you get yours working.
 
This seems like it would be a little bit problematic with the default core behaviour, specifically the smalloc code since it treats the external RAM as a large volatile heap.
 
jmarsh said:
default core behaviour
Click to expand...
Given its static nature - like Flash - if it could just be given a unique address space* it wouldn't call for any other 'core' overhead or access? i.e. integration into dynamic or other memory. And perhaps a variant of 'external_psram_size'

Though for LittleFS it would be a custom blend of LittleFS_RAM and LittleFS_SPIFram with the cache_flush for any writes().
 
You must log in or register to reply here.
Back
Top