Call to arms | Teensy + SDRAM = true

Got this on first run of download not changing the speed with No Cap
Test capacitor effect effect on SDRAM read timing margin
Clock set 254.12 MHz

Could not initialize SDRAM hardware
So no cap at that speed and no .begin() intialize.

At 206 requested this is the result: 625.73 seconds:
Code:
Test capacitor effect effect on SDRAM read timing margin
Clock set 205.71 MHz

    SDRAM hardware initialized.

    This test takes approximately 5 minutes to complete.
    Progress:: '#'=fixed pattern, '.'=PsuedoRand patterns, and 'F' shows Failed test pattern
    If built with DUAL Serial second SerMon will show details.


  --- START 57 test patterns ... wait ...
#############............................................
Test result: 0 read errors (0.0000%)

Normally no read errors is good, but for comparing the effect of your
capacitor connected to DQS (EMC_39) you need errors!  When all reads are
correct, you can not know if the error-free result is because you have
good timing margin or your SDRAM reads are just barely succeeding.  Only
when you see errors can you estimate your capacitor's effect on timing.
Please increase the speed and re-run this test for each capacitor.  Use
a speed fast enough for all tests to give at least some errors.  The
difference in number of errors allows you to gauge the relative effect
of various capacitors to choose the best capacitor for your PCB design.
Extra info: ran for 625.73 seconds



Compile Time:: C:\Users\TimLabs\Documents\GitHub\SDRAM_t4\examples\CapReadSDRAM\CapReadSDRAM.ino Jan 30 2024 17:32:51
EXTMEM Memory Test, 32 Mbyte   SDRAM speed 205.71 Mhz F_CPU_ACTUAL 600 Mhz begin@ 80000000  end@ 82000000
 
Got this on first run of download not changing the speed with No Cap

So no cap at that speed and no .begin() intialize.
I think it would be best to disable the pattern test at the end of begin() in the case where you explicitly want to experience read errors (or just call begin() and blindly ignore the returned value).
 
Good catch. That test within begin() isn't wonderful for this overclock usage.

If we don't change begin(), maybe as an alternate we could just retry calling begin() many times.
 
No doubt - but until tomorrow - no caps here - and then we'll know what that expected range is if @Dogbone06 and I get together with testing. Europe time had me up late for his start ... then it went on forum before I got back ...
In about 9 hours I will test it, that's when I'll be home. The 10pF cap is still on the board.
 
Wrote this and neglected to post. Might be good to have it optional. In real use (not tested yet) data may survive a warm restart and that could be useful. And when in normal usage - the library only used when hardware is known to be there from prior use, and outside NO CHIP - the fixed val test isn't much help in finding it to be faulty.
I think it would be best to disable the pattern test at the end of begin() in the case where you explicitly want to experience read errors (or just call begin() and blindly ignore the returned value).
Oh yeah - forgot that was added to detect no installed SDRAM case - when that was termed 'user error' for using hardware library without the hardware installed.

In testing the FIXED patterns seem to survive when PRand's are more likely to fail. If that fails then the test would have little value in completing.

Ran NoCap at 221 MHz with these 5min 10 sec result:
Code:
#####F####F##FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Test result: 106286599 read errors (0.2223%)

Extra info: ran for 610.59 seconds
Shows 11 of 14 Fixed patterns passed. Should use 'f' for fixed to delineate the PRand Error tests.
 
I see you've made another copy of the capacitor test, with a confusingly similar name, putting back in all the code I specifically wanted removed.

I wanted all that code deleted because the practical effect is people report their results without clearly starting how they ran the test. Now we have all that uncertainty back again, plus the additional confusion of 2 tests with basically the same name. When people comment about number of read errors, we'll not only have to wonder how long the test was, but also which of the 2 similarly named programs they ran!

Not good. :(
 
Last edited:
BTW. it is possible to overclock the normal PSRAM to 166MHz without many errors that is nearly 2 times the normal speed.

176MHz will not work. The PSRAM IC used was APS6404L-3SQR-SN


FLEXSPI2_CLK_SEL = 10
LPSPI_PODF = 11
CCM_CBCMR=75AE8204 (166.2 MHz)

EXTMEM Memory Test, 8 Mbyte begin, 70000000 middle, 70400000 end, 70800000
testing with fixed pattern 5A698421
testing with fixed pattern 55555555
..............
test RndSeed HalfCopy 1100533073 Write 90331 us Read/Test 85486 us Read Cnt 6
test ran for 12.15 seconds
Fixed Pattern Write ran for 2.32 and Read/Test 2.10 secs
Fixed Pattern Test 47.03 MB per sec
Fixed Pattern Test WRITES 44.86 MB per sec
Fixed Pattern Test & READ 49.42 MB per sec
PsuedoRnd Patt Write ran for 3.97 and Read/Test 3.76 secs
PsuedoRnd Patt Test 91.05 MB per sec
All memory tests passed :) (readRepeat 6)
Loop doTest() count=2 readRepeat=6 bTimer=0 LoopTest() Mins=0.84
 
Just ran the test on my board with no cap at 221 and 211/ note 208 gives no errors

Rich (BB code):
#####f####f##F.FF.F..F.FFFF...FFF.F.FFF.F.F.FFFFFFFFFFFFF
Test result: 2975261 read errors (0.0062%)

Extra info: ran for 610.63 seconds

Compile Time:: D:\Users\Merli\Documents\Arduino\SDRAM-TEENSY\CapReadSDRAM\CapReadSDRAM.ino Jan 31 2024 08:24:27
EXTMEM Memory Test, 32 Mbyte   SDRAM speed 221.54 Mhz F_CPU_ACTUAL 600 Mhz begin@ 80000000  end@ 82000000

Code:
 --- START 57 test patterns ... wait ...
#####f#######......................................F.....
Test result: 31705 read errors (0.0001%)

Extra info: ran for 617.35 seconds



Compile Time:: D:\Users\Merli\Documents\Arduino\SDRAM-TEENSY\CapReadSDRAM\CapReadSDRAM.ino Jan 31 2024 08:52:29
EXTMEM Memory Test, 32 Mbyte   SDRAM speed 216.00 Mhz F_CPU_ACTUAL 600 Mhz begin@ 80000000  end@ 82000000
 
Found an interesting thread: https://community.nxp.com/t5/i-MX-RT/i-MXRT1060-SEMC-SDRAM-Data-Corruption/m-p/1170738

Basically boils down to: set the BMCR0 and BMCR1 registers to 0x81 if you don't want reads/writes to end up possibly out of order when different devices are accessing the same location in the SDRAM. Although I can't think of a situation offhand where such behavior wouldn't already be considered a race condition (with undefined results).
 
Found an interesting thread: https://community.nxp.com/t5/i-MX-RT/i-MXRT1060-SEMC-SDRAM-Data-Corruption/m-p/1170738

Basically boils down to: set the BMCR0 and BMCR1 registers to 0x81 if you don't want reads/writes to end up possibly out of order when different devices are accessing the same location in the SDRAM. Although I can't think of a situation offhand where such behavior wouldn't already be considered a race condition (with undefined results).
I can but not with the 1060 chips. But if you are using a 1070 or a H7 that have 2 cores sharing memory (SDRAM) you might get into a race condition.
 
I see you've made another copy of the capacitor test, with a confusingly similar name, putting back in all the code I specifically wanted removed.

I wanted all that code deleted because the practical effect is people report their results without clearly starting how they ran the test. Now we have all that uncertainty back again, plus the additional confusion of 2 tests with basically the same name. When people comment about number of read errors, we'll not only have to wonder how long the test was, but also which of the 2 similarly named programs they ran!

Not good. :(
Yes, I did that when you did those quick hacks to the WIP current sketch I wrote and am working with and altered it under the same name.

At this early point the universe of folks working on this will be two when Mouser delivery is received here today.
 
Have managed to get my USB Host library to work with the micro usb port on a Teensy 4.1 - should also work with a USB-C port on the devboard but I need to be able to run multiple startup_middle_hook() functions first...
 
CapReadSDRAM

Gives this result with a 10pF cap.
Code:
Test capacitor effect effect on SDRAM read timing margin

    SDRAM hardware initialized.

    This test takes approximately 5 minutes to complete.
    Progress:: '#'=fixed pattern, '.'=PsuedoRand patterns, and 'f' or 'F' shows Failed test pattern
    If built with DUAL Serial second SerMon will show details.


  --- START 57 test patterns ... wait ...
#####f####f##FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Test result: 1161152 read errors (0.0024%)

Extra info: ran for 579.27 seconds



Compile Time:: C:\Users\Dogbone06\Documents\Arduino\libraries\SDRAM_t4-main\examples\CapReadSDRAM\CapReadSDRAM.ino Jan 31 2024 20:39:29
EXTMEM Memory Test, 32 Mbyte   SDRAM speed 254.12 Mhz F_CPU_ACTUAL 600 Mhz begin@ 80000000  end@ 82000000
 
Last edited:
@Dogbone06 - CAPS arrived before dark! 10 pF soldered - wow size 0402 is harder to get ON than OFF so close to MCU!
> Soldering it isn't square or clean - so less than ideal CAP attachment. Turned on the iron before swapping to smaller tip.

Speeds are: speedRange[]= {196,206,216,227,240,254,270,288}; // Array in custom test that iterates those speeds with a restart in between
First pass sanity check with only 3 ReReads initial test to test soldering and similar function to your second run board.

It is working without error only up to 227 MHz here. Were you seeing 0 errors at 240 MHz?
> Gave 447 Read Errors at 240 MHz [no FIXED patt errors]
> That jumps to 23,773,409 read Errors at 240 MHz. [Errors on 4 fixed patterns]
 
Last edited:
And now for something completely different to find out what CAP helps up to what SDRAM speed.
Evolving the test now with a 10 pF cap installed. Very surprising so many CAPS worked to such high speeds!
No Errors through 227 MHz with 10 pF!
Compared 2 .vs. 5 .vs. 25 ReReads and 5 seems to catch the trend.
When 240 MHz Errors start they are on passes 1-5 with FIXED and ALWAYS FIRST pass with Psuedo Random.
At 254 MHz: ReRead on the PRand Values. 25 does gives some proportion more (0.60% .vs. 0.54% ) than 5 ReReads { 9700 .vs. 1300[*5) )
Next jump to 270 and 280 MHZ give extreme 19.6% and 20.7% so a clear out of bounds for usability - and with 10 pF both are in the same failure region.
When Errors appear at 254 MHz they are always on FIRST pass ReRead.

THE TEST: https://github.com/mjs513/SDRAM_t4/tree/main/examples/CapReadSDRAMTest
@Dogbone06 :
This updated test (new SKETCH NAME given old test name/code was usurped prematurely)
Given these possible values: uint32_t speedRange[] = {133, 166, 196, 206, 216, 227, 240, 254, 270, 288};
The values 196 to 227 work with NO ERRORS and 10 pF CAP in place.
To confirm BEST CAP is ideal need to be added and run across ALL MHz values.
Test uses EEPROM to store index into speedRange[] and it runs for ReRead number of times in each of the 57 tests, then RESTARTS to next value.
Test just altered to run from 227 to 288 MHz to allow test of "A CAP of user choice" across those speeds. About 11 minutes.
Hold pin16 PULLED to 3.3V after UPLOAD to start test from beginning:: SDRAM testing PAUSED w/Restart Pin 16 HIGH : Will run when pin 16 goes low. It is PULLDOWN, so jumper to 3.3V and upload, then pull jumper and testing will begin.
Pin13 LED will 200 ms Blink when testing is complete, the EEPROM value is reset and it stops to blink, but pin #16 enforces a clean start at 227 MHZ with code above from github.

10 pF RESULTS:
> showing run speed and number of Errors in 57 tests at 227-288 MHz.
> 'a' or 'A' shows first read on that test showed Errors, ERRORS on subsequent passes 2-25 will be b-y or B-Y when used (z/Z over 25)
> below at 240 MHz shows Errors started on Fixed and PRand on 2nd pass with 'b' and 'B', so first pass worked.
Code:
    SDRAM testing PAUSED w/Restart Pin 16 HIGH : Will run when pin 16 goes low.

Start 57 test with 5 reads 227.37 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 125.52 seconds at 227 MHz


Start 57 test with 5 reads 240.00 MHz ... wait ...:#####a####b##AAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1383 read errors (0.0000%)
Extra info: ran for 123.26 seconds at 240 MHz


Start 57 test with 5 reads 254.12 MHz ... wait ...:a#a##a####a##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 49794255 read errors (0.5207%)
Extra info: ran for 121.23 seconds at 254 MHz


Start 57 test with 5 reads 270.00 MHz ... wait ...:aaaaaaaaaaaa#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1873163227 read errors (19.5876%)
Extra info: ran for 119.36 seconds at 270 MHz


Start 57 test with 5 reads 288.00 MHz ... wait ...:aaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1978384746 read errors (20.6879%)
Extra info: ran for 117.24 seconds at 288 MHz

    SDRAM Stop/Restart Pass Complete

@Dogbone06 : This more appropriate test should give needed details to test against various CAP pF values to see if any make a difference for better or worse to find the 'best' one for the current library code.

NOTE: The .begin() check_fixed_pattern() using the single FIXED value test is NOT triggering even at 288 MHz, but it should be removed to allow 'WARM Restart' data recovery for those that find it to work (still not tested here).

ReRun after array/index edit still with 10 pF and 5 ReReads - shows 240 MHz count of Errors at 992 .vs. 1383 above, and diff first fail 'd':
SDRAM testing PAUSED w/Restart Pin 16 HIGH : Will run when pin 16 goes low.

Start 57 test with 5 reads 227.37 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 125.52 seconds at 227 MHz


Start 57 test with 5 reads 240.00 MHz ... wait ...:#####d#######AAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 992 read errors (0.0000%)
Extra info: ran for 123.88 seconds at 240 MHz


Start 57 test with 5 reads 254.12 MHz ... wait ...:a####a####a##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 61748626 read errors (0.6457%)
Extra info: ran for 121.23 seconds at 254 MHz


Start 57 test with 5 reads 270.00 MHz ... wait ...:aaaaaaaaaaaa#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1869249094 read errors (19.5467%)
Extra info: ran for 119.36 seconds at 270 MHz


Start 57 test with 5 reads 288.00 MHz ... wait ...:aaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1978586473 read errors (20.6900%)
Extra info: ran for 117.22 seconds at 288 MHz

SDRAM Stop/Restart Pass Complete
 
Last edited:
Gives this result with a 10pF cap.

Thanks for running the test. At this point, I believe your best course is to wait for @defragster to finish running his tests, and also wait until the library's testing program is finalized. No point doing all the work to solder those parts and run so many tests when the software is still in a state of flux.
 
@Dogbone06 : Github code CapReadSDRAMTest.ino is current and working as expected for me!
> Jumper p#16 to 3.3V and upload and look for SerMon, remove Jumper.
> Test runs to completion {227, 240, 254, 270, 288} MHz, then resets and stops with quick BLINK, for next restart.
> If you find the 'PERFECT' CAP you can edit this line #6 from 5 to 0 to run all speeds in the array with a REBUILD/UPLOAD.
#define FIRST_SPEED 0 // index into speedRange to start testing: [0]==133 and [5]==227

Using code as posted p#716 CAP changed to 6.8 pF: lowest of those purchased.
This shows that 240 MHz is WORSE than 10 pF as is 254 MHz - 270 & 288 MHz are now both over 20% Error.
> 240 MHz 2nd FIXED errors on same {11th offset} test but now ReRead #1 'a' instead of "b,c,d, or e" seen before.
Code:
Start 57 test with 5 reads 227.37 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 125.52 seconds at 227 MHz


Start 57 test with 5 reads 240.00 MHz ... wait ...:#####a####a##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 587990 read errors (0.0061%)
Extra info: ran for 123.88 seconds at 240 MHz


Start 57 test with 5 reads 254.12 MHz ... wait ...:aaaaaaa#aaaa#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 640309309 read errors (6.6957%)
Extra info: ran for 121.23 seconds at 254 MHz


Start 57 test with 5 reads 270.00 MHz ... wait ...:aaaaaaaaaaaa#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1968410929 read errors (20.5836%)
Extra info: ran for 119.36 seconds at 270 MHz


Start 57 test with 5 reads 288.00 MHz ... wait ...:aaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1978301413 read errors (20.6870%)
Extra info: ran for 117.24 seconds at 288 MHz

Will change CAP to largest 12 pF - and run test 133-288 MHz and then go offline.
> DANG those 0402 things are SMALL! Installed finest tip and it was more usable.
 
@Dogbone06 : Github code CapReadSDRAMTest.ino is current and working as expected for me!
> Jumper p#16 to 3.3V and upload and look for SerMon, remove Jumper.
> Test runs to completion {227, 240, 254, 270, 288} MHz, then resets and stops with quick BLINK, for next restart.
> If you find the 'PERFECT' CAP you can edit this line #6 from 5 to 0 to run all speeds in the array with a REBUILD/UPLOAD.
#define FIRST_SPEED 0 // index into speedRange to start testing: [0]==133 and [5]==227

Using code as posted p#716 CAP changed to 6.8 pF: lowest of those purchased.
This shows that 240 MHz is WORSE than 10 pF as is 254 MHz - 270 & 288 MHz are now both over 20% Error.
> 240 MHz 2nd FIXED errors on same {11th offset} test but now ReRead #1 'a' instead of "b,c,d, or e" seen before.
Code:
Start 57 test with 5 reads 227.37 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 125.52 seconds at 227 MHz


Start 57 test with 5 reads 240.00 MHz ... wait ...:#####a####a##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 587990 read errors (0.0061%)
Extra info: ran for 123.88 seconds at 240 MHz


Start 57 test with 5 reads 254.12 MHz ... wait ...:aaaaaaa#aaaa#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 640309309 read errors (6.6957%)
Extra info: ran for 121.23 seconds at 254 MHz


Start 57 test with 5 reads 270.00 MHz ... wait ...:aaaaaaaaaaaa#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1968410929 read errors (20.5836%)
Extra info: ran for 119.36 seconds at 270 MHz


Start 57 test with 5 reads 288.00 MHz ... wait ...:aaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1978301413 read errors (20.6870%)
Extra info: ran for 117.24 seconds at 288 MHz

Will change CAP to largest 12 pF - and run test 133-288 MHz and then go offline.
> DANG those 0402 things are SMALL! Installed finest tip and it was more usable.
Should I test it? And if so, should I run the 4 caps again that Paul said earlier?
no cap, 4.7, 10, 15 ?
 
Should I test it? And if so, should I run the 4 caps again that Paul said earlier?
no cap, 4.7, 10, 15 ?
Yes, See p#718. And p#716 for more details and CODE link.
12 pF soldered and started now ...
p#718 shows 6.8 pF had more Errors than 10 pF.

PARTIAL results coming in for 12 pf - 240 MHz BETTER with 15 ERRORS ( versus 900+ above)
> and at 254 MHz: 9 FIXED values passed 0 Err - versus ALL had errors at 10 pF

PERHAPS: start at 6.8 pF and if your results match those shown then proceed to higher values at 10 pF, then go up.
You can compare against my 6.8 and 10 and soon 12 pF will be complete - but the useful part is done now:
Code:
Start 57 test with 5 reads 227.37 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 125.52 seconds at 227 MHz


Start 57 test with 5 reads 240.00 MHz ... wait ...:#############B.E.D..EAB.A..................B..D.A.....B..
Test result: 15 read errors (0.0000%)
Extra info: ran for 123.26 seconds at 240 MHz


Start 57 test with 5 reads 254.12 MHz ... wait ...:aa###a####a##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 2926352 read errors (0.0306%)
Extra info: ran for 121.23 seconds at 254 MHz


Start 57 test with 5 reads 270.00 MHz ... wait ...:aaaaaaaaaaaa#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1551875644 read errors (16.2279%)
Extra info: ran for 119.36 seconds at 270 MHz


Start 57 test with 5 reads 288.00 MHz ... wait ...:aaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1980043171 read errors (20.7052%)
Extra info: ran for 117.23 seconds at 288 MHz


    SDRAM Stop/Restart Pass Complete

Just started 12 pF with ALL MHz in array to confirm 133 to 216 (not shown above) are Error free.
If you Edit the code - especially the line #6 start value - make sure to use Pin #6=3.3V for UPLOAD as it resets the EEPROM value in this case from 5 to 0.
 
Last edited:
Wow - night chores take longer than this test.
12 pF with same 5 ReReads across ALL: uint32_t speedRange[] = {133, 166, 196, 206, 216, 227, 240, 254, 270, 288};
using : #define FIRST_SPEED 0

240 MHz show the same type of glitches this time 25 instead of 15 read Errors - so 12 pF (as soldered) is better than 10 pF

For 'sleep' run bumped from 5 to 50 ReReads just to verify the results for 240 MHz are close to 10 times higher, and all below are really stable.
> #define TYPICAL_REREADS 50
Note: Extra SerMon SPAM does appear on each restart for speeds under 200 MHz, disabled over that.
Also: The "SCB_AIRCR = 0x05FA0004;" and EEPROM maybe be overkill, but then the SDRAM and clocks are in a "normal" state for setup().
Code:
    SDRAM testing PAUSED w/Restart Pin 16 HIGH : Will run when pin 16 goes low.

    SUCCESS sdram.init()

    Progress:: '#'=fixed, '.'=PsuedoRand patterns: when no Errors other wise first pass with error a-z or A-Z
    If built with DUAL Serial second SerMon will show details.

Compile Time:: C:\Users\TimLabs\Documents\GitHub\SDRAM_t4\examples\CapReadSDRAMTest\CapReadSDRAMTest.ino Feb  1 2024 01:11:46
SDRAM Memory Test, 32 Mbyte   F_CPU_ACTUAL 600 Mhz begin@ 80000000  end@ 82000000

Start 57 test with 5 reads 132.92 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 157.23 seconds at 133 MHz


    SUCCESS sdram.init()

    Progress:: '#'=fixed, '.'=PsuedoRand patterns: when no Errors other wise first pass with error a-z or A-Z
    If built with DUAL Serial second SerMon will show details.

Compile Time:: C:\Users\TimLabs\Documents\GitHub\SDRAM_t4\examples\CapReadSDRAMTest\CapReadSDRAMTest.ino Feb  1 2024 01:11:46
SDRAM Memory Test, 32 Mbyte   F_CPU_ACTUAL 600 Mhz begin@ 80000000  end@ 82000000

Start 57 test with 5 reads 166.15 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 142.00 seconds at 166 MHz


    SUCCESS sdram.init()

    Progress:: '#'=fixed, '.'=PsuedoRand patterns: when no Errors other wise first pass with error a-z or A-Z
    If built with DUAL Serial second SerMon will show details.

Compile Time:: C:\Users\TimLabs\Documents\GitHub\SDRAM_t4\examples\CapReadSDRAMTest\CapReadSDRAMTest.ino Feb  1 2024 01:11:46
SDRAM Memory Test, 32 Mbyte   F_CPU_ACTUAL 600 Mhz begin@ 80000000  end@ 82000000

Start 57 test with 5 reads 196.36 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 132.59 seconds at 196 MHz


Start 57 test with 5 reads 205.71 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 130.36 seconds at 206 MHz


Start 57 test with 5 reads 216.00 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 128.59 seconds at 216 MHz


Start 57 test with 5 reads 227.37 MHz ... wait ...:#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 125.52 seconds at 227 MHz


Start 57 test with 5 reads 240.00 MHz ... wait ...:#############.DE.CCAD.E.DC.A..EAC....D..C...BAC...AAA.E..
Test result: 25 read errors (0.0000%)
Extra info: ran for 123.26 seconds at 240 MHz


Start 57 test with 5 reads 254.12 MHz ... wait ...:a####a####a##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 5987024 read errors (0.0626%)
Extra info: ran for 121.23 seconds at 254 MHz


Start 57 test with 5 reads 270.00 MHz ... wait ...:aaaaaaaaaaaa#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1571378156 read errors (16.4318%)
Extra info: ran for 119.36 seconds at 270 MHz


Start 57 test with 5 reads 288.00 MHz ... wait ...:aaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1980711386 read errors (20.7122%)
Extra info: ran for 117.23 seconds at 288 MHz


    SDRAM Stop/Restart Pass Complete

NOTE DMA TEST: It might be good to have a DMA test like an earlier test I was doing:
> Write/Test known values to an ORIGINAL portion of SDRAM
> DMA COPY that portion to another {1st 16MB to 2nd 16MB. or maybe in smaller block sizes}
-> maybe (also) do in 256K blocks from DMAMEM or DTCM buffer work area.
> Read Test the COPY to compare to the ORIGINAL
> I could make test work when I find the DMA COPY code.
 
12 pF:: Back to find DevBaord OFFLINE ?? - and TyCommander Stored SerMon TEXT file not showing much output captured from what was to be a longer run ??? No CrashReport on restarting.

So restarted at 240 MHz and it ran nicely today. Just restarted 50 ReReads at 227 MHz to see if it stays Error Free as expected.
Above 5 ReReads 25 Errors and now 50 ReReads 291 Errors : so 16% more captured over time than directly the 10X multiple.
Any letters after 'E' are errors caught after 5th ReRead. All are in the first 25 alpha A-Y, any after would be 'Z'.
50 ReReads takes 18.8 minutes at 240 MHz, so should be under 10 minutes for 25 ReReads and those 25 should give a
Results on 254 MHz are the same - any fails are on first ReRead: 4 of 13 FIXED and ALL PRand patterns.
Need to remove the '...' after wait as it clutters the progress bar now on same line.
Code:
SDRAM testing PAUSED w/Restart Pin 16 HIGH : Will run when pin 16 goes low.

Start 57 test with 50 reads 240.00 MHz ... wait ...:#############HINABEBAFGFPABNSQAFDBMAMAPPAGCBQTAAGCJTMDCAK
Test result: 291 read errors (0.0000%)
Extra info: ran for 1128.74 seconds at 240 MHz

Start 57 test with 50 reads 254.12 MHz ... wait ...:aa###a####a##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 38012501 read errors (0.0397%)
Extra info: ran for 1108.53 seconds at 254 MHz

12 pF with 50 ReReads completed at 227 MHz with zero Errors, so on this DevBaord with 12 pF as soldered seems stable:
Code:
Start 57 test with 50 reads 227.37 MHz ... wait::#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 1150.80 seconds at 227 MHz
And that fell into retest of 240 MHz with only 237 Errors versus 291 above and below 10X the Errors on 5 ReReads:
Code:
Start 57 test with 50 reads 240.00 MHz ... wait::#############EFNMVLABGCIBAPAAARCJBDJIAGWAAEBCQBJKDCFPAEAD
Test result: 237 read errors (0.0000%)
Extra info: ran for 1128.74 seconds at 240 MHz
Found this DMA memCopy posted by @PaulStoffregen with cache attention:
 
Last edited:
This test is a little weird. I ran it at 254MHz and it restarted a bunch of times. It tested 254, then went down to 240 and then back to 254, I left it running and then some time later it was finished and this is the result:

Code:
Start 57 test with 5 reads 288.00 MHz ... wait ...:aaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1973322126 read errors (20.6349%)
Extra info: ran for 117.24 seconds at 288 MHz


    SDRAM Stop/Restart Pass Complete
 
This test is a little weird. I ran it at 254MHz and it restarted a bunch of times. It tested 254, then went down to 240 and then back to 254, I left it running and then some time later it was finished and this is the result:

Code:
Start 57 test with 5 reads 288.00 MHz ... wait ...:aaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 1973322126 read errors (20.6349%)
Extra info: ran for 117.24 seconds at 288 MHz


    SDRAM Stop/Restart Pass Complete
Wierd was a requirement :)

Yes, currently it RESTARTS: But progressing from LOWER to HIGHER MHz - Should look like posted in #720.
Assumes SerMon stays online to collect and aggregate output - as above ... TyCommander does that as long as DevBoard not offline over ~10 seconds. Thought TyComm was in use? Other SerMon may or not appreciate the Restart.

Next step was to test calling sdram.begin() without restart and comparing the results.
 
To be honest I can't get it to run properly. Maybe I need to reset the entire board so it clears the EEPROM because now it wont reboot. It just runs one test. But when it did restart, it prints each test once done, but after reboot that gets cleared. So the data gets lost.
 
Back
Top