Teensy 4.1 psram memtest

J

Jayjer66

Member
Hey Guys I have installed PSRAM but when I run memtest tells me that I am missing header files H on my computer library?
 
Starting with a T_4.1 and PSRAM soldered - Cool. github.com/PaulStoffregen/teensy41_psram_memtest

Then A copy of the Arduino IDE needs to be installed 1.8.x or 2.x.

Then Current TeensyDuino 1.57 for the IDE 1.8.x, or Teensy in IDE 2.x Board Manager after installing the PJRC URL to the Preferences Additional board mgr URL section:
https://www.pjrc.com/teensy/package_teensy_index.json

Then selecting the T_4.1 board in the IDE should build and work properly.

If Errors the Verbose console output might explain what went wrong.

<edit>
Downloaded and tested here to work with IDE 2.0.3 and TD 1.58 beta 3 ( 0.58.3 ) on T_4.1 w/8MB PSRAM:
Code: 
EXTMEM Memory Test, 8 Mbyte
 CCM_CBCMR=B5AE8304 (88.0 MHz)
testing with fixed pattern 5A698421
testing with pseudo-random sequence, seed=2976674124
...
testing with fixed pattern 00000000
 test ran for 36.43 seconds
All memory tests passed :-)

build notes:
Code: 
...
Memory Usage on Teensy 4.1:
  FLASH: code:36796, data:6040, headers:8360   free for files:8075268
   RAM1: variables:6944, code:34176, padding:31360   free for local variables:451808
   RAM2: variables:12384  free for malloc/new:511904
...
 
It comes up with-

Invalid library found in /users/justin/documents/arduino/libraries/teensy41_psram_memtest: no header files (.h) found in /users/justin/documents/arduino/libraries/teensy41_psram_memtest

am i missing somthing?
 
Last edited:
Yes, that is not a 'library' - just a 'sketch' folder.

Don't place the folder in "/users/justin/documents/arduino/libraries"

Put it in your normal sketchbook or other folder and in the IDE just open the file: "teensy41_psram_memtest.ino"

The PSRAM 'library' code is included in the CORES directly for the T_4.1 processor.
 
memory Usage on Teensy 4.1:
FLASH: code:28100, data:7064, headers:8864 free for files:8082436
RAM1: variables:7680, code:25432, padding:7336 free for local variables:483840
RAM2: variables:12384 free for malloc/new:511904

Cool thanks is this what it meant to say? sorry for thew noob questions.
 
Jayjer66 said:
memory Usage on Teensy 4.1:
FLASH: code:28100, data:7064, headers:8864 free for files:8082436
RAM1: variables:7680, code:25432, padding:7336 free for local variables:483840
RAM2: variables:12384 free for malloc/new:511904

Cool thanks is this what it meant to say? sorry for thew noob questions.
Click to expand...

That looks close to what I have here. If you have TeensyDuino 1.57 it would have diff size as the Beta of 1.58 is in use here with an updated tool chain that grows code.

Glad to help. The IDE gives a decent usable and reproducible build system - but there are some things to learn. Under the covers there is a lot going on that just works.

The important thing is the output in the Serial Monitor showing the PSRAM to store and recall expected values provided by the memtest.
 
Jayjer66 said:
i cant get it to test the memory but
Click to expand...

Is there any output on the serial monitor?

Built with USB Type: Serial
There should be output when it connects. That program will sit and do nothing until Serial connects with: while (!Serial) ; // wait

That is as it should be - but a Serial Monitor needs to connect and then output as abbreviated in post #2 should show in some fashion.

If nothing is displaying, then there is a problem of some sort.

There is a photo to compare here (below): pjrc.com/store/psram.html

That should match the chip 'pin 1'/DOT orientation and the soldering should be mostly clean as shown with no shorts or flux between the pins.

teensy41_memory2.jpg
 
First, go to /users/justin/documents/arduino/libraries and delete anything you copied there. That "libraries" folder is a special location. Putting normal program there could cause problems. So before you go any farther, look in that folder and delete any folders and files you put there.

Quit and restart Arduino IDE, just in case it's remembering anything about stuff that was incorrectly placed in that libraries folder.

Then in Arduino, click File > New Sketch. You'll get a new window with a sample program that has 2 empty functions called setup() and loop(). Delete all that, so the window has nothing. Then go to this page on github for the memory test code.

https://github.com/PaulStoffregen/teensy41_psram_memtest/blob/master/teensy41_psram_memtest.ino

Select all 147 lines and then copy to clipboard, either with CTRL-C (or Command-C if MacOS) or menu Edit > Copy. Then in blank Arduino window, where you deleted the sample do-nothing program, paste with CTRL-V or Edit > Paste. You'll see all 147 lines of code appear in the Arduino window. Then quickly check Tools > Board to make sure Teensy 4.1 is selected, and click the Upload button (2nd from the left in the green menu bar, shown with a right arrow).

After the code is uploaded, click Tools > Port to quickly check that your Teensy board is selected. Then open the serial monitor window, which can be done by clicking the button on the far right side of the green menu bar, or with the menu Tools > Serial Monitor. If using the older Arduino IDE 1.8.x this opens another window. If using newer Arduino IDE 2.0.x, the serial monitor opens as tab in the bottom part of the main window. Either way, you should see the memory test results.

If you want the program stored on your PC, in Arduino use File > Save As. It will give you a normal file save window with the proper location where Arduino expects to find saved files.


Hopefully this helps you get past this initial hurdle and run the memory test. If you get stuck or something goes wrong, please remember we can't see your screen. Helping over the internet like this goes so much better if you show us a screenshot, so we can see whatever error message is on your screen, together with details like the tiny text that appears in the bottom part of the Arduino IDE window.
 
Jayjer66 said:
Yep I have a ext memory test 0mbyte better check something
Click to expand...

If you are seeing this: "EXTMEM Memory Test, 0 Mbyte"
> And the Teensy LED is FLASHING then the PSRAM is not being recognized. That is what I see on a T_4.1 with NO PSRAM installed.
> When a PSRAM is found and properly passes the tests the LED will just be ON continuously without any flashing.
> It will stay OFF if the test never starts.

Paul's p#11 steps are good to assure a clean build after that sketch was placed in the libraries folder - but with the text above it seems to have properly built.

Given that "0 Mbyte" text is presented: It would be best to unplug the Teensy and examine the soldering and compare to the p#10 image - and notes on the linked PJRC site to assure the PSRAM is installed in the right location - when only one it needs to be in the end position between pins #31 to #34. And the soldering must be 'clean enough'. No shorts, good looking solder from all pins to pads, and even flux residue can interfere with this device at the high speeds it runs at.
 
@Jayjer66 if you can upload a picture of the soldered PSRAM we can see it to confirm.

And the Pin1/DOT of the PSRAM as shown in p10 image should be nearest corner Pin #32.

Also, where did you get the PSRAM - and does it match one of those shown on the linked page where four are displayed on there?
 
Jayjer66 said:
https://photos.app.goo.gl/W6e5RH5GmvSzVc3P8
Click to expand...

ICK - Flooded with Flux - if all that shine around the pins (on both PSRAM and FLASH) is flux and not a photo aberration.

Chip label isn't legible to confirm make or type. But if a normal 8 MB PSRAM it should work, but that excess flux has to go.

The solder looks well placed and connected - if a bit generous - but no apparent solder shorts.
t41Flux.jpg

It probably should not hurt to carefully reflow each pin lightly given the flux will hopefully liquify and melt with the solder making sure if it does to contact the pad and the pin leg a brief time with the tip.

With that done then the board needs washed of the flux. Some are water washable - here 91% Isopropyl alcohol works with an old clean toothbrush. The flux between the legs needs to be removed and rinsed free, then properly dried before powering.

Given that all pins but the CS are common to both chips - both need to be clean to have best chance of either working properly.

At least one user in past has done the reflow and flux removal to get it working. In fact one soldered here may have started odd and gone working with better flux removal.
 
defragster said:
Starting with a T_4.1 and PSRAM soldered - Cool. github.com/PaulStoffregen/teensy41_psram_memtest

Then A copy of the Arduino IDE needs to be installed 1.8.x or 2.x.

Then Current TeensyDuino 1.57 for the IDE 1.8.x, or Teensy in IDE 2.x Board Manager after installing the PJRC URL to the Preferences Additional board mgr URL section:
https://www.pjrc.com/teensy/package_teensy_index.json

Then selecting the T_4.1 board in the IDE should build and work properly.

If Errors the Verbose console output might explain what went wrong.

<edit>
Downloaded and tested here to work with IDE 2.0.3 and TD 1.58 beta 3 ( 0.58.3 ) on T_4.1 w/8MB PSRAM:
Code: 
EXTMEM Memory Test, 8 Mbyte
 CCM_CBCMR=B5AE8304 (88.0 MHz)
testing with fixed pattern 5A698421
testing with pseudo-random sequence, seed=2976674124
...
testing with fixed pattern 00000000
 test ran for 36.43 seconds
All memory tests passed :-)

build notes:
Code: 
...
Memory Usage on Teensy 4.1:
  FLASH: code:36796, data:6040, headers:8360   free for files:8075268
   RAM1: variables:6944, code:34176, padding:31360   free for local variables:451808
   RAM2: variables:12384  free for malloc/new:511904
...
Click to expand...

Hey, i want to mention that PSRAM memtest provided is not completely trustful and may say "all is fine" while it is really not :) It costed me a couple of hours until i figured it out btw. I'm working on a hobby project which will read/write the data to some 5v TTL bus (LVC4245a translators were used for level shifting). I was wondering if it would be possible to avoid adding WAIT states to Z80 when reading data from EXTMEM but measurements shown that it is not ok. During those measurements i had boosted PSRAM clock to 133MHz and memtest was giving green light (with two Adafruit's unbranded memory chips installed). Though, while the direct FlexSPI2 commands were executing correctly, and giving the best predictable timing, it was still not enough so i decided to use WAITs and switched back to regular access (using regular C for indexing an array to get the data), which as i now undertand uses AHB protocol and gives bigger delay in worst case but as well has better general throughoutput. So, i had painful times understanding what's wrong, until i guessed that's not my handling of signa;s, then i've just made a copy of the same data in regular memory, and was comparing read data from both arrays on the fly, and surprise-surprise, it was bad! In my case reducing clock to 110.77MHz made it stable. I think it would be good to extend PSRAM testing sketch to cover this use as well, so those errors are caught by the test itself :)

P.S. i'm experienced dev, but quite a rookie in low level embedded stuff yet, as i've started recently with digital circuits and MCUs and stuff, so pardon for any ignorant statements btw if you have found any ;) just correct me where i'm wrong
 
Pencioner said:
Hey, i want to mention that PSRAM memtest provided is not completely trustful and may say "all is fine" while it is really not :) It costed me a couple of hours until i figured it out btw. I'm working on a hobby project which will read/write the data to some 5v TTL bus (LVC4245a translators were used for level shifting). I was wondering ...
Click to expand...
Would be interesting if the method of clock speed change details were included and any test sketch that showed the FAIL issue.

The speed is limited for a reason since it hasn't been proven/tested good above the current default speed where that PJRC test was meant to run.

Some similar testing using that code as a base was done using an external SDRAM chip on a custom PCB that wires it up. Not sure if that extension of the test might find these errors if the nature of the read failure was indicated.
 
defragster said:
The speed is limited for a reason since it hasn't been proven/tested good above the current default speed where that PJRC test was meant to run.
Click to expand...

The 88 MHz default is mostly for compatibility with various flash memory chips people solder to the 2nd set of pads.

Perhaps for future software we might consider faster speed if we can be certain the 2nd location is also PSRAM or has no other chip soldered.
 
Pencioner said:
I think it would be good to extend PSRAM testing sketch to cover this use as well, so those errors are caught by the test itself
Click to expand...

Could you share the specific test code you believe should be incorporated into the PSRAM test? Your description "just made a copy of the same data in regular memory, and was comparing read data from both arrays on the fly" leaves a lot of imagination. A much more specific proposal would be needed to consider adding another test to the published code.
 
PaulStoffregen said:
Could you share the specific test code you believe should be incorporated into the PSRAM test? Your description "just made a copy of the same data in regular memory, and was comparing read data from both arrays on the fly" leaves a lot of imagination. A much more specific proposal would be needed to consider adding another test to the published code.
Click to expand...
Actualy there is a 16Kb rom in uint8_t array which i initially used (source generated with Python from actual file) to check if signals are ok, an it is located in the fastest (tight coupled) memory. Then as a next step i added EXTMEM array, and copied data over to it (with a very bold approach of dst[i] = src[i] loop) and then in the main loop added WAIT signaling to mitigate possible delays (without it data was arriving too late on bus). And it was working very bad, i almost pulled my hair out as i do not have oscilloscope or data logic analyzer (yet) figuring out what's wrong with my WAITs...

I do not use Arduino, as i wanted to be on full control on what's going on so i'm using a Makefile and copy of Teensyduino sources, and the clock change was done by modifying startup.c:

C: 
@@ -366,7 +359,7 @@ FLASHMEM void configure_external_ram()
 
        // turn on clock  (TODO: increase clock speed later, slow & cautious for first release)
        CCM_CBCMR = (CCM_CBCMR & ~(CCM_CBCMR_FLEXSPI2_PODF_MASK | CCM_CBCMR_FLEXSPI2_CLK_SEL_MASK))
-               | CCM_CBCMR_FLEXSPI2_PODF(5) | CCM_CBCMR_FLEXSPI2_CLK_SEL(3); // 88 MHz
+               | CCM_CBCMR_FLEXSPI2_PODF(5) | CCM_CBCMR_FLEXSPI2_CLK_SEL(2); // 110.77 MHz
        CCM_CCGR7 |= CCM_CCGR7_FLEXSPI2(CCM_CCGR_ON);
 
        FLEXSPI2_MCR0 |= FLEXSPI_MCR0_MDIS;

BTW, i'm gonna make a short sketch which reproduces the issue without any irrelevant code and will post it here. Actually, at the moment i'm not completely sure those were read errors. It might happen that those were write errors on copying data look (huh?). But i have no idea how to distinguish. So i'll just try to reproduce
 
Pencioner said:
BTW, i'm gonna make a short sketch which reproduces the issue without any irrelevant code and will post it here. Actually, at the moment i'm not completely sure those were read errors. It might happen that those were write errors on copying data look (huh?). But i have no idea how to distinguish. So i'll just try to reproduce
Click to expand...
That 'fail on write' is actually what I was looking at last on the SDRAM test evolution across speed changes.

The PSRAM spec notes a condition where less than the 133 MHz full speed is supported.
 
You must log in or register to reply here.
Back
Top