Teensy 4.1 Beta Test

@manitou
One problem I am having is that I am not getting the same errors that you and @defragster are getting when I do a compile - the only difference I see I that you still are using extRAM_t4 - you don't need that library anymore for using spiffs. Essentially its now part of the spiffs_t4 library. In other words I moved the old extRAM_t4.h and extRAM.cpp files into the old SPIFFS_t4 library and renamed them spiffs_t4.h and spiffs.cpp.:
View attachment 20165

Does this make sense. Just Delete the extRAM_t4 directory.

No. i'm still confused.
From your link https://github.com/PaulStoffregen/teensy41_extram/tree/SPIFFS-FLASH-ONLY
I cloned the SPIFFS-FLASH-ONLY branch, and moved the directory SPIFFS_t4/ into my libraries folder. that folder has this in src/
Code:
SPIFFS_t4/src
extRAM_t4.cpp	spiffs_check.c	 spiffs.h	    spiffs_nucleus.h
extRAM_t4.h	spiffs_config.h  spiffs_hydrogen.c  spiffs_t4.cpp
spiffs_cache.c	spiffs_gc.c	 spiffs_nucleus.c   spiffs_t4.h
I don't have an extRAM_t4 directory. Should i delete everything from that src/ directory except spiffs_t4.h and spiffs.cpp
 
@PaulStoffregen - @manitou - @defragster - @KurtE

I'm working on a second half of the PSRAM/FLASH to set up a wrapper for direct writes to the PSRAM or the FLASH but am running into a use case challenge. No issues with direct writes that works but the challenge comes up with have 2 PSRAM chips available. I looking at a few cases that I am trying to get my head around:
1. 1 FLASH - no real issue
2. 1 FLASH - 1 PSRAM no real issue
but here are the cases that I am getting myself confused on when I have 2 PSRAM chips
1. 1 PSRAM setup for direct writes and the 2nd can be set up for SPIFFS as @defragster suggested.
2. 2 PSRAMS for direct writes - not an issue since addressing is just relative to the base
3. what if some one whats to use 2 PSRAMs SPIFFs - as I am typing this think I will deal with this case.

EDIT: Maybe I am just overthinking this and making it more complicated than it has to be.
 
No. i'm still confused.
From your link https://github.com/PaulStoffregen/teensy41_extram/tree/SPIFFS-FLASH-ONLY
I cloned the SPIFFS-FLASH-ONLY branch, and moved the directory SPIFFS_t4/ into my libraries folder. that folder has this in src/
Code:
SPIFFS_t4/src
extRAM_t4.cpp	spiffs_check.c	 spiffs.h	    spiffs_nucleus.h
extRAM_t4.h	spiffs_config.h  spiffs_hydrogen.c  spiffs_t4.cpp
spiffs_cache.c	spiffs_gc.c	 spiffs_nucleus.c   spiffs_t4.h
I don't have an extRAM_t4 directory. Should i delete everything from that src/ directory except spiffs_t4.h and spiffs.cpp

Got it - now I understand - some how I messed up with GitHub. Just delete extRAM_t4.h and extRAM_t4.cpp. Think I know what I did - just pushed up the change with the deleted files.
 
@mjs513, if you setup a SPIFS using the upper memory locations, we obviously would want to modify what address the extmem_malloc() would return...

I have not played with any of this for awhile, been busy on other stuff.
 
@mjs513, if you setup a SPIFS using the upper memory locations, we obviously would want to modify what address the extmem_malloc() would return...

I have not played with any of this for awhile, been busy on other stuff.
Actually forgot about that maybe better off not doing SPIFFS at all on PSRAM since uses are going to be so varied and spiffs on PSRAM are just going to be confusing the issue


EDIT:
@KurtE - just thought of something else. If a user is using EXTMEM or malloc_extmem and then want to use PSRAM for direct writes we are going to get in trouble I think if we don't pre alloc space on a PSRAM chip or have some sort of way to determine how much space is available for direct writes. Not sure how to handle this at this point.
 
Last edited:

Before posting I confirmed the now 'Deleted extraneous files ' really were in the ZIP - and were extra - not leftover as the DIR was new. Will update fresh.

The build problem may be it is the first TSET build I've done since TD 1.52 released. All other builds yesterday were from the IDE. The Frank_B/TSET CMDLine build does seem to scour the build tree a bit differently?
> those 'Deleted extraneous files' may be ignored from IDE
> one other time is the Dual .INO files of the Ethernet sample.

Left SD card Fill last night that datalogger lib stops near end of Disk - again using 15.4MB PSRAM:
Code:
Warning, all data on the card will be erased.
Enter 'Y' to continue: 
Card size:   29.723  GiB (GiB = 2^30 bytes)
Card will be formated exFAT
Writing FAT .................................
Writing upcase table
Writing root
Format done

Card Type is exFAT
File system initialization done.
RTC has set the system time

Starting Logger.

File name is:  <LOG_0313.bin>
Pre-allocating 1GB file space 
Allocation succeeded.

Opened  File LOG_0313.bin
 
   4.345,   Records:   1086250   Overflows:    0
   9.480,   Records:   2370000   Overflows:    0
  14.220,   Records:   3555000   Overflows:    0
…
7963.990,   Records:1990997500   Overflows:    0
7969.520,   Records:1992380000   Overflows:    0
Halting logging.  Getting near end of SD Card.

Stopping Logger.
Logger Status:

MBytes Written: 30410.35   SdCard free space:     9.78 MBytes
Collection time: 7972 seconds
Max Collection delay: 1 microseconds
Average Write Time: 285.946 milliseconds
Maximum Write Time: 809.916 milliseconds

Verifying last file

Recnum: 1000000
Recnum: 2000000
…
Recnum: 915000000
Recnum: 916000000
…
Recnum: 1013000000
Recnum: 1014000000
…  
Recnum: 1989000000
Recnum: 1990000000
Recnum: 1991000000
Recnum: 1992000000
End of file playback.

[B]Verification errors:  0
Verification complete
[/B]

<Edited> Verify Done - All Good
30GB written to SD through 15.4 MB of PSRAM as buffer during 250Ksps of memory data.
 
Last edited:
Actually forgot about that maybe better off not doing SPIFFS at all on PSRAM since uses are going to be so varied and spiffs on PSRAM are just going to be confusing the issue

EDIT:
@KurtE - just thought of something else. If a user is using EXTMEM or malloc_extmem and then want to use PSRAM for direct writes we are going to get in trouble I think if we don't pre alloc space on a PSRAM chip or have some sort of way to determine how much space is available for direct writes. Not sure how to handle this at this point.

FULL FLASH only SPIFFS is trivial - and not too much harder to add 1 or 2 FULL PSRAM. But in handling SPLIT FLASH - the same could be applied to SPLIT PSRAM with needed values settable in .config but indeed when used with dynamic malloc PSRAM_heap it would need to know - unless SPIFFS used that PSRAM_heap malloc to reserve the space?- That could prevent reliable use of semi-static PSRAM across warm restarts though if PSRAM_heap order changed?
 
Got it - now I understand - some how I messed up with GitHub. Just delete extRAM_t4.h and extRAM_t4.cpp. Think I know what I did - just pushed up the change with the deleted files.

OK, that got example eram_spifffs working so i got directory listing from EFLASH, and I added memcpy() tests using 0x70800000
Code:
        memcpy 32768 bytes from 0x70800000 flash 779 us
        memcpy 32768 bytes from 0x70800000 flash 235 us
first memcpy is after arm_dcache_delete(), then a 2nd memcpy() presumably using dcache. arm_dcache_delete
clocked @132.9 MHz

(just for the record, I get different cache performance of ERAM/EXTMEM depending on whether i do the memcpy() tests before or after Paul's ERAM tetsts??, see post #491) EFLASH memcpy() times show little variation.
 
Last edited:
FULL FLASH only SPIFFS is trivial - and not too much harder to add 1 or 2 FULL PSRAM. But in handling SPLIT FLASH - the same could be applied to SPLIT PSRAM with needed values settable in .config but indeed when used with dynamic malloc PSRAM_heap it would need to know - unless SPIFFS used that PSRAM_heap malloc to reserve the space?- That could prevent reliable use of semi-static PSRAM across warm restarts though if PSRAM_heap order changed?
@defragster
In actuality to SPLIT PSRAM into 2 regions I think I can do (already did it in the past as a test) if I don't get myself confused with configurations :) So if you tell me to reserve 4Mb for extmem in the lower half of the PSRAM then can do and you can use the other half for direct addressing. But there is nothing in the core to prevent EXTMEM to go over that 4Mb. So back to where we started from you can overwrite stuff easily.
 
OK, that got example eram_spifffs working so i got directory listing from EFLASH, and I added memcpy() tests using 0x70800000
Code:
        memcpy 32768 bytes from 0x70800000 flash 779 us
        memcpy 32768 bytes from 0x70800000 flash 235 us
first memcpy is after arm_dcache_delete(), then a 2nd memcpy() presumably using dcache. arm_dcache_delete
clocked @132.9 MHz

(just for the record, I get different cache performance of ERAM/EXTMEM depending on whether i do the memcpy() tests before or after Paul's ERAM tetsts??) EFLASH memcpy() has little variation.

Ok confused on the timings. Where did you put the memcpy's in the sketch and did you specifically call arm_dcache_delete?

Have no comment about ERAM/EXTMEM that I don't get?
 
Ok confused on the timings. Where did you put the memcpy's in the sketch and did you specifically call arm_dcache_delete?

Have no comment about ERAM/EXTMEM that I don't get?

Code:
#define BYTES 32*1024
DMAMEM uint8_t ocram[BYTES] __attribute__ ((aligned(32)));
PROGMEM uint8_t prog[BYTES] __attribute__ ((aligned(32)));
uint8_t dst[BYTES] __attribute__ ((aligned(32)));
uint8_t src[BYTES] __attribute__ ((aligned(32)));
  ...  and then following injected after all the SPIFFS file tests
  uint8_t *p = (uint8_t *)0x70800000;
  arm_dcache_delete(p, BYTES);
  uint32_t us = micros();
  memcpy(dst, p, BYTES);
  us = micros() - us;
  Serial.printf("%d bytes from 0x70800000 flash %d us\n", BYTES, us);
  us = micros();
  memcpy(dst, p, BYTES);
  us = micros() - us;
  Serial.printf("%d bytes from 0x70800000 flash %d us\n", BYTES, us);

I also have confirmed that memcpy is correctly copying data from EFLASH to DTCM
 
Ok confused on the timings. Where did you put the memcpy's in the sketch and did you specifically call arm_dcache_delete?

Have no comment about ERAM/EXTMEM that I don't get?

The QSPI clock speed changes when SPIFFS is loaded/started with .begin() ? Entering setup() it is <90Mhz and after spiffs__.begin() it is >130 Mhz right?

RE SPIFFS split - yes, that was in mind when it seemed it was certainly do-able - but it does get complex and 'brittle' when other memory is in use … and mortals try to do hEx math :) When extmem_malloc() comes into play there is the 'stack hits heap' issue - but in KurtE's demo it seemed he built like heap top down so that could work with care. Or if there was working 'extmem_malloc()' in play then SPIFFS could just get the memory given desired size - and then use extmem_malloc() call to get the start and start+len==end and go from there.

I spent a minute confused with SPIFF from github - not sure which is PSRAM example and needed lib. So I restarted the PSRAM logger and filled the SD again while sitting in the sun.
Code:
...
7964.385,   Records:1991096250   Overflows:    0
7969.520,   Records:1992380000   Overflows:    0
Halting logging.  Getting near end of SD Card.

Stopping Logger.
Logger Status:

MBytes Written: 30410.35   SdCard free space:     9.78 MBytes
Collection time: 7971 seconds
Max Collection delay: 1 microseconds
Average Write Time: 287.477 milliseconds
Maximum Write Time: 863.907 milliseconds

Verifying last file
Recnum: 1000000
Recnum: 2000000
...

So again this 16MB PSRAM T_4.1 passed a full use ( of 15.4MB ) to cycle through 30GB … rough math says 2000 _isr() write/ to SD read cycles without issue in 7971 seconds with no sign of trouble.
 
Code:
#define BYTES 32*1024
DMAMEM uint8_t ocram[BYTES] __attribute__ ((aligned(32)));
PROGMEM uint8_t prog[BYTES] __attribute__ ((aligned(32)));
uint8_t dst[BYTES] __attribute__ ((aligned(32)));
uint8_t src[BYTES] __attribute__ ((aligned(32)));
  ...  and then following injected after all the SPIFFS file tests
  uint8_t *p = (uint8_t *)0x70800000;
  arm_dcache_delete(p, BYTES);
  uint32_t us = micros();
  memcpy(dst, p, BYTES);
  us = micros() - us;
  Serial.printf("%d bytes from 0x70800000 flash %d us\n", BYTES, us);
  us = micros();
  memcpy(dst, p, BYTES);
  us = micros() - us;
  Serial.printf("%d bytes from 0x70800000 flash %d us\n", BYTES, us);

I also have confirmed that memcpy is correctly copying data from EFLASH to DTCM

Now after you posted there was something I realized. If you do the memcpy at the end of the SPIFFS tests the SPIFFS file system is still mounted. So not sure what that effect would be. To avoid that in the future adding another function call - fs_unmount so you can unmount the SPIFFS - didn't even think of that before now - just pushed up a change and some clean up to initialization. Ok I added your code to a skinny down sketch and used the unmount function and got the following:
Code:
32768 bytes from 0x70800000 flash 780 us
32768 bytes from 0x70800000 flash 80 us
about the same on the memcpy afte the dcache_delete and quite a bit faster on the second memcpy. If I don't do the delete dcache:
Code:
32768 bytes from 0x70800000 flash 758 us
32768 bytes from 0x70800000 flash 84 us
about the same?

Heres's the sketch I am playing with for reference:
Code:
extern "C" uint8_t external_psram_size;

#include <spiffs_t4.h>
#include <spiffs.h>

spiffs_t4 eRAM;

//Setup files IO
spiffs_file file1;

#define BYTES 32*1024
DMAMEM uint8_t ocram[BYTES] __attribute__ ((aligned(32)));
PROGMEM uint8_t prog[BYTES] __attribute__ ((aligned(32)));
uint8_t dst[BYTES] __attribute__ ((aligned(32)));
uint8_t src[BYTES] __attribute__ ((aligned(32)));
uint8_t *p = (uint8_t *)0x70800000;
  
#define DO_DEBUG 1

char buf[512] = "Hello World! What a wonderful World :)";
char fname[32] = "my_file1";
int szLen = strlen( buf );
elapsedMicros my_us;

uint8_t valERAM;
uint8_t *ptrERAM = (uint8_t *)0x70000000;  // Set to ERAM
const uint32_t  sizeofERAM = 0x7FFFFE / sizeof( valERAM ); // sizeof free RAM in  } }

//random address to write from

void setup() {
  while (!Serial);
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  Serial.printf("PSRAM: %d MB\n", external_psram_size);

  Serial.println("\n Enter 'y' in 6 seconds to format FlashChip - other to skip");
  uint32_t pauseS = millis();
  char chIn = 9;
  while ( pauseS + 6000 > millis() && 9 == chIn ) {
    if ( Serial.available() ) {
      do {
        if ( chIn != 'y' )
          chIn = Serial.read();
        else
          Serial.read();
      }
      while ( Serial.available() );
    }
  }
  if ( chIn == 'y' ) {
    eRAM.begin();
    eRAM.eraseFlashChip();
  }

  Serial.println();
  Serial.println("Mount SPIFFS:");
  eRAM.begin();
  eRAM.fs_mount();

  Serial.println("Write file:");
  Serial.println(buf);
  eRAM.f_writeFile(fname, buf, SPIFFS_CREAT | SPIFFS_TRUNC | SPIFFS_RDWR);

  Serial.println();
  Serial.println("Directory contents:");
  eRAM.fs_listDir();

  memset(buf, 0, sizeof(buf)); //emtpy buffer
  Serial.println("Read file:");
  eRAM.f_readFile(fname, buf, sizeof(buf)/sizeof(char), SPIFFS_RDONLY);
  Serial.println(buf);

  Serial.println();
  delay(100);

  Serial.println();
  Serial.println("Mount SPIFFS:");
  eRAM.fs_mount();
  Serial.println("Directory contents:");
  eRAM.fs_listDir();
  
[B][COLOR="#FF0000"]  eRAM.fs_unmount();[/COLOR][/B]

  arm_dcache_delete(p, BYTES);
  uint32_t us = micros();
  memcpy(dst, p, BYTES);
  us = micros() - us;
  Serial.printf("%d bytes from 0x70800000 flash %d us\n", BYTES, us);
  us = micros();
  memcpy(dst, p, BYTES);
  us = micros() - us;
  Serial.printf("%d bytes from 0x70800000 flash %d us\n", BYTES, us);
}

void loop() {
}
 
defragster said:
The QSPI clock speed changes when SPIFFS is loaded/started with .begin() ? Entering setup() it is <90Mhz and after spiffs__.begin() it is >130 Mhz right?
Correct :)

RE SPIFFS split - yes, that was in mind when it seemed it was certainly do-able - but it does get complex and 'brittle' when other memory is in use … and mortals try to do hEx math When extmem_malloc() comes into play there is the 'stack hits heap' issue - but in KurtE's demo it seemed he built like heap top down so that could work with care. Or if there was working 'extmem_malloc()' in play then SPIFFS could just get the memory given desired size - and then use extmem_malloc() call to get the start and start+len==end and go from there.
Ultimately that would be the idea but don't want to do a library hack until Paul does the final implementation. To play with using KurtE's extmem_malloc is good but don't want to base the lib on that approach. More issues to deal with later.

spent a minute confused with SPIFF from github - not sure which is PSRAM example and needed lib. So I restarted the PSRAM logger and filled the SD again while sitting in the sun.
SPIFFS_4 only uses the full flash for SPIFFS, no more playing with PSRAM from using that lib. You can still do direct memory addressing from with the sketch for the PSRAM though. All my questions on PSRAM challenges came as a result of me trying to build something for PSRAM that could possibly address SPIFFS and direct addressing.
 
Makes sense on PSRAM SPIFFS - maybe extmem_malloc() will be the first thing added to TD 1.53 B1 :)

I made note of the timing change in case that is what was puzzling @manitou

I went back to punishing PSRAM with data logger. Instead of a nice pretty 16 byte struct I extended to a packed 33 byte struct that is written Binary with SD Fat Beta.
Code:
struct datrec {
  uint32_t microtime;    //  time in microseconds
  uint32_t millitime;   // millis() since collection start at time collection occurred
  uint32_t numrecords;  // number of structures collected
  uint8_t *cptr;        // pointer to last storage location to check out-of-bounds writes
  uint8_t aByte;
  uint32_t microtime2;    //  time in microseconds
  uint32_t millitime2;   // millis() since collection start at time collection occurred
  uint32_t numrecords2;  // number of structures collected
  uint32_t microtime3;    //  time in microseconds
} __attribute__((packed));

Before the VERIFY on reading back the file could only know millitime progressed over time, and numrecords always went ++.

Now I can assert that : microtime3 == microtime2 == microtime, and second copy of numrecords2 and millitime2 all went to PSRAM > to SD and read back from SD as expected. As well as abusing that ODD aByte to pass this as stored :: (dp->aByte != (dp->microtime & 0xff))

Had to slow sample rate to 120K sps … oppps it started fine for 15,857,783 records ... now need to investigate:
Code:
Recnum: 15000000
Record number error at 15857784  File: 15857784  local: 15425784
millitime2 2 number error at 15857784  File: 126863  local: 123407
microtime2 2 error at 15857784  File: 126862281  local: 123407
microtime3 3 error at 15857784  File: 126862281  local: 123407
millitime number error at 15857785  File: 126863  local: 123407
millitime2 2 number error at 15857785  File: 126863  local: 123407
millitime number error at 15857786  File: 126863  local: 123407
millitime2 2 number error at 15857786  File: 126863  local: 123407
millitime number error at 15857787  File: 126863  local: 123407
millitime2 2 number error at 15857787  File: 126863  local: 123407
millitime number error at 15857788  File: 126863  local: 123407
millitime2 2 number error at 15857788  File: 126863  local: 123407
 
Now after you posted there was something I realized. If you do the memcpy at the end of the SPIFFS tests the SPIFFS file system is still mounted. So not sure what that effect would be. To avoid that in the future adding another function call - fs_unmount so you can unmount the SPIFFS - didn't even think of that before now - just pushed up a change and some clean up to initialization. Ok I added your code to a skinny down sketch and used the unmount function and got the following:

Interesting your cached times are faster. the fs_unmount() is good, but i'm surprised that it would make a difference. I would think the SPIFFFS would be inactive. what memcpy() times do you get without the fs_unmount(). My test was read-only (no erase, no SPIFFS write's), but I don't think that should influence cached memcpy times. maybe the memcpy() test is not an effective measure.
 
Last edited:
Hi,
I finally received the pre-sample last Thursday. This w-e I soldered the psram and the test went ok. Then I decided to solder the header pin and test my Amiga emulator port now running on the T4.0 but it seems I don't have 3.3 v on none of the 2 pins. There is a small wire from the regulator to the pin 3 but no voltage on pin 3 also. Is there an easy location I can use to bridge. I was thinking usb header or psram track. I need to power my display from the 3.3 v.... What is best to use. Anyone had same issue with presamples?
 
Wow - painfully long delivery delay :(

I didn't get/see one of those pre-production boards. See notes from Paul early in the thread? - panelization resulted in some disconnected power and gnd pins. That may be what the small wire was about?

The middle row of pins has 3.3V and GND in the same order as the T_4.0. Not sure which pins were affected or corrected.
 
That white wire should have been delivering 3.3V to that pin (at least it was on mine).

To the best of my recollection, the middle row of pins across the end of the uSD socket (Vbat, 3.3V, Gnd, Program, On/Off) did have 3.3V on it. The ground on that row was also okay. Of the pins along the outer edge, the only ground that was hooked up was the one in the corner by D0 (RX1), pin 1 if you like.
 
You are a lucky one!
Mine left USA but is still between Germany and Italy.
... mine left PJRC on April, 21st, spent 18 days in San Francisco and has now been held in customs in Frankfurt for two days, we´ll see when it arrives ;-).
I purchased two T4.1 with exp-tech, which arrived the next day after the order . . .
 
Interesting your cached times are faster. the fs_unmount() is good, but i'm surprised that it would make a difference. I would think the SPIFFFS would be inactive. what memcpy() times do you get without the fs_unmount(). My test was read-only (no erase, no SPIFFS write's), but I don't think that should influence cached memcpy times. maybe the memcpy() test is not an effective measure.

Without fs_unmount I get:
Code:
32768 bytes from 0x70800000 flash 779 us
32768 bytes from 0x70800000 flash 68 us
about the same. Out of curiosity I added the same code when I before doing anything with the sketch with SPIFFS, I get another set of timings:
Code:
D:\Users\Merli\Documents\Arduino\T41\flashMemCpyTimming\flashMemCpyTimming.ino May 18 2020 05:56:39

PSRAM: 8 MB
[B]32768 bytes from 0x70800000 flash 1143 us
32768 bytes from 0x70800000 flash 43 us[/B]

 Enter 'y' in 6 seconds to format FlashChip - other to skip

Mount SPIFFS:
Mount ADDR 0x800000 with res: 0

Write file:
Hello World! What a wonderful World :)

Directory contents:
my_file1 [0001] size:38
Read file:
Hello World! What a wonderful World :)

Mount SPIFFS:
Mount ADDR 0x800000 with res: 0
Directory contents:
my_file1 [0001] size:38

[B]32768 bytes from 0x70800000 flash 779 us
32768 bytes from 0x70800000 flash 62 us[/B]

I did change the flash initialization which may be the reason we have different times at the same time I added fs_unmount. Not sure if that would make a difference but maybe.

I did make a decision though at least for now to add that if there are 2 PSRAM chips you can put SPIFSS on the second chip. Going to work that change this morning.
 
Without fs_unmount I get:
...
I did change the flash initialization which may be the reason we have different times at the same time I added fs_unmount. Not sure if that would make a difference but maybe.

I did make a decision though at least for now to add that if there are 2 PSRAM chips you can put SPIFSS on the second chip. Going to work that change this morning.

Just noticed there is a Branch :: PaulStoffregen/teensy41_extram/tree/SPIFFS-FLASH-ONLY

Last I got was the master I suppose - thus my confusion :( The readme show the old name and {Both the SPIFFS_t4 and the extRAM_SPIFFS_t4 } and the MultiFile sketch shows just:
Code:
#include <spiffs_t4.h>
#include <spiffs.h>

Having SPIFFS only on one of twin PSRAMS is a good answer for now depending on how the Emalloc() works out it could go high or low and be mostly safe. Will looks for new update on the right branch.

I keep hoping to see some perfection with the datalogger and PSRAM to SD - and last effort packed struct 33 Bytes or unpacked with extended Verify - finds errors on playback from read - rare just a couple dozen in a batch of millions - on both 8(1) and 16(2) MB PSRAM 4.1's :( Now I need to hack the lib and verify the buffer on write in case the trouble is data on SD or read from SD. But each T_4.1 has their own card. Hopefully easy to special case this and see it work.

Just booted with new MSFT Edge - hoping system likes it better for all the web pages I leave open. So many distractions.
 
I removed the comments about guessing about order of pin numbers.... They are the pin numbers.
As for everything correct. I hope I have not made too many mistakes. Today I did update the XBar pins as I found I missed a couple and I was off by one row in the pins 0-5 area.
Again updated and pushed up to Github.

Pins 38, 39 SPI pins. They are in RED as they are not the default pins for this functionality. Although in case of CS1-0 it probably does not need to be RED as no pin by default is setup as hardware CS pin...

But in case of MOSO1

by default if you do SPI1.begin();
Pin 1 will be configured as the MISO pin. But you change this by doing: SPI1.setMISO(39);

Thank you. If you like, I can go through the datasheet and double-check for you.
 
Just noticed there is a Branch :: PaulStoffregen/teensy41_extram/tree/SPIFFS-FLASH-ONLY

Last I got was the master I suppose - thus my confusion :( The readme show the old name and {Both the SPIFFS_t4 and the extRAM_SPIFFS_t4 } and the MultiFile sketch shows just:
Code:
#include <spiffs_t4.h>
#include <spiffs.h>

Having SPIFFS only on one of twin PSRAMS is a good answer for now depending on how the Emalloc() works out it could go high or low and be mostly safe. Will looks for new update on the right branch.

I keep hoping to see some perfection with the datalogger and PSRAM to SD - and last effort packed struct 33 Bytes or unpacked with extended Verify - finds errors on playback from read - rare just a couple dozen in a batch of millions - on both 8(1) and 16(2) MB PSRAM 4.1's :( Now I need to hack the lib and verify the buffer on write in case the trouble is data on SD or read from SD. But each T_4.1 has their own card. Hopefully easy to special case this and see it work.

Just booted with new MSFT Edge - hoping system likes it better for all the web pages I leave open. So many distractions.

@defragster
Ok just spent some quality time with PSRAMS and FLASH again. For now here is what has been implemented:

spiffs_t4 library
1. If FLASH is available it uses FLASH for the SPIFFS
2. IF 2 PSRAM's are available it uses the second PSRAM for SPIFFS
3. IF no chips are installed it exits :)

extRAM_t4 Library
This is essentially a wrapper library for direct access to the PSRAM with the following use cases:
1. If 2 PSRAM chips installed the first 4Mbs are reserve for EXTMEM and playing with extmem_malloc (experimental) so you have 12 MB available
2. If 1 PSRAM chip installed the first 4Mbs are reserve for EXTMEM and playing with extmem_malloc (experimental) so you have 4 MB available
3. To change this edit the following in the extRAM_t4.h file:
Code:
	uint32_t eramBaseAddr = 0x70400000;
	uint32_t bytesAvaialbe  = 4194305u;
oops as I am typing this just thought of another place this has to change - have to do something creative :) so easier. In the .cpp file has to change here as well:
Code:
	if(external_psram_size == 16){
		if(spiffs == 1){
			Serial.println("2 PSRAM Chips Installed !!!");
			Serial.println("SPIFFS requested on 2nd PSRAM chip,");
			Serial.println("4Mb in upper half of 1st PSRAM chip available");
			Serial.println("for direct writes !!");
			bytesAvaialbe = 4 * 1024 * 1024;
		} else if(spiffs == 0){
			Serial.println("2 PSRAM Chips Installed !!!");
			Serial.println("12Mb available for direct writes !!");
			bytesAvaialbe = 12 * 1024 * 1024;
		}
	} else if(external_psram_size == 8){
		Serial.println("1 PSRAM Chip Installed !!!");
		Serial.println("4Mb in upper half of 1st PSRAM chip available");
		Serial.println("for direct writes !!");
		bytesAvaialbe = 4 * 1024 * 1024;
4. If you included spiffs_t4.h in your sketch to use spiffs on the 2nd PSRAM the extRAM_t4 lib detects it and limits you to use 4Mbs on the on the 1st PSRAM chip

The wrapper library supports:
Code:
	void	readArray (uint32_t ramAddr, uint32_t items, uint8_t data[]);
	void	writeArray (uint32_t ramAddr, uint32_t items, uint8_t value[]);
	void	readByte (uint32_t ramAddr, uint8_t *value);
	void	writeByte (uint32_t ramAddr, uint8_t value);
	void	copyByte (uint32_t origAddr, uint32_t destAddr);
	void	readWord(uint32_t ramAddr, uint16_t *value);
	void	writeWord(uint32_t ramAddr, uint16_t value);
	void	readLong(uint32_t ramAddr, uint32_t *value);
	void	writeLong(uint32_t ramAddr, uint32_t value);
	void	eraseDevice(void);

EDIT: Just thought of another use case - direct access for FLASH with extRAM_t4 :)
 
Last edited:
Back
Top