Call to arms | Teensy + SDRAM = true

Did you set up the PIN #16 ? { Post # 716 }
Jumper that to the many 3.3V header pins. It will start and wait for it to be disconnected and then run the test as expected
 
Posted a trivial github update that removes extra 'wait ...'s and will not bother running the speeds after 254 as they surely fail while 240 is showing some errors and 254 gets many errors.

Will update soon with a tested NON-Restart version if the results show the restart is not changing the results.

Just finished running that here for this output:
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...D.B.E.A.....ACA.BE...C..E........
Test result: 18 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: 4469787 read errors (0.0467%)
Extra info: ran for 121.23 seconds at 254 MHz


    SDRAM Stop/Restart Pass Complete
12 pF
 
Last edited:
Updated: https://github.com/mjs513/SDRAM_t4/tree/main/examples/CapReadSDRAMTest

It appears to run the same with multiple calls to sdram.begin() using updated speeds and no RESTARTS required.
Using TyCommander the ongoing SerMon output persists across restarts - and somehow understood that was in use.

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::#############.E....CB......A...ADBCAE.C.....B...D..B.C.CD
Test result: 24 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: 2385192 read errors (0.0249%)
Extra info: ran for 121.23 seconds at 254 MHz


    SDRAM Stop/Restart Pass Complete
12 pF CAP
 
Last edited:
This is the result I get with the latest sketch you just pushed to Git.
Board has the 10pF cap mounted.

Seems like the sketch hangs on 254MHz, It sat like this for minutes.

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.51 seconds at 227 MHz


Start 57 test with 5 reads 240.00 MHz ... wait::#############............................................

Test result: 0 read errors (0.0000%)

Extra info: ran for 123.88 seconds at 240 MHz


Start 57 test with 5 reads 254.12 MHz ... wait::aa###a####
 
Just updated github with copy here.

Using the current version on github there are no restarts and no calls to anything EEPROM.
 

Attachments

  • CapReadSDRAMTest.ino
    11.3 KB · Views: 46
Opps prior post was based on reading old posts - DOH - but it was UPDATED.
Seems like your 2nd Run DevBoard is maybe acting odd?
> Wonder if all the CAP resoldering near the MCU edge has affected the Ball solder or gotten flux under it?

Those longer PRand tests with 5 ReReads should be updating the Progress Bar every ~3 seconds and the pin#13 LED toggles as well.
Then the 200ms On/OFF blink when tests complete.

I did have the ODD Board Offline first thing here - but no problems since.
Are you plugged into the USB-C toward the board Center? The other brand connector used on the edge close to B0_00 corner jiggles and disconnects if the board is touched at times.
 
Finally a clean test. Running the sketch you attached in post #731. Result with 10pF cap:


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::#############............................................

Test result: 0 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##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Test result: 539154 read errors (0.0056%)

Extra info: ran for 121.23 seconds at 254 MHz



    SDRAM Stop/Restart Pass Complete
 
:cool:
Not sure what the hang up was (other than SerMon in use)? Using the same code on the DevBoard you sent ???

Indeed, you are having better results and NO ERRORS at 240 MHz

Currently using 12 pF here and it improved the 240 MHz and 254 - though your 254 MHz at 10 pF is better than here at 12 pF
 
defragster said:
:cool:
Not sure what the hang up was (other than SerMon in use)? Using the same code on the DevBoard you sent ???

Indeed, you are having better results and NO ERRORS at 240 MHz

Currently using 12 pF here and it improved the 240 MHz and 254 - though your 254 MHz at 10 pF is better than here at 12 pF
Click to expand...
Second pass below. The 10pF is the best one, maybe some tweaking such as for example 10.3 or 9.7 or something could improve it, I don't know. But I hope that Paul got his answers from these tests. Let me know if I should test something else.

Second pass 10pF cap and sketch from post #731

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::#############............................................

Test result: 0 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##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Test result: 628466 read errors (0.0066%)

Extra info: ran for 121.23 seconds at 254 MHz



    SDRAM Stop/Restart Pass Complete
 
If you are still at 10 pf change this line from 5 to 25: #define TYPICAL_REREADS 5
Going to 25 did catch some more errors.

Then perhaps swap for 12 pF? And put above line back to 5 for a shorter run. Somehow this board got better at 12 pF.

I got one between 10 and 12 - I'll swap to that then try under 10
 
Dropping from 12 to 11 pF and it shows marginally more errors (.v.s p#279) - so seems higher is better here.

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::#############DBAAB.ABBC.BACDA.DBACA.BA.A.CBADCCC.BEA.BBDA
Test result: 89 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: 8391074 read errors (0.0877%)
Extra info: ran for 121.23 seconds at 254 MHz
 
defragster said:
Dropping from 12 to 11 pF and it shows marginally more errors (.v.s p#279) - so seems higher is better here.

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::#############DBAAB.ABBC.BACDA.DBACA.BA.A.CBADCCC.BEA.BBDA
Test result: 89 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: 8391074 read errors (0.0877%)
Extra info: ran for 121.23 seconds at 254 MHz
Click to expand...
Test the 10pF like I’m running and see if you get the same results as me.
 
Dogbone06 said:
I’ll try that tomorrow.
Click to expand...
Very good. Glad the sketch tuned up to work to give you usable results.

10pF sure works better there than it did here before. Did another 12 pF run and it shows more errors on both 240 and 254 than above posted run.

I can go back to a fresh 10 pF - maybe my soldering will make a difference with a few trial runs now.
 
defragster said:
Very good. Glad the sketch tuned up to work to give you usable results.

10pF sure works better there than it did here before. Did another 12 pF run and it shows more errors on both 240 and 254 than above posted run.

I can go back to a fresh 10 pF - maybe my soldering will make a difference with a few trial runs now.
Click to expand...
Hot air gun and syringe with solder paste is the way to go.
 
No hot air gun here - and solder paste is older so not tried.
Odd thing is using iron to remove it often seats better just as it is getting pushed off - not sure if that is too much heat for the cap.
 
Not to get in the way of your progress, but I'm curious if someone can summarize or just comment on what you've learned about the relative speed of SDRAM to TCM, RAM, PSRAM?
 
joepasquariello said:
Not to get in the way of your progress, but I'm curious if someone can summarize or just comment on what you've learned about the relative speed of SDRAM to TCM, RAM, PSRAM?
Click to expand...
Nothing telling or concrete IIRC. It's been alive almost 5 weeks and that had some quick look and then various diversions (not in build but stand alone lib but with malloc support) and a search for the mystical CAP for higher speeds. Some more boards came along with diversion of displays - one effort seemed a bit slow to interface without some OC it seems?

@joepasquariello - if you have code links, or ideas, that could direct address or malloc map a pointer?
 
I'm seeing several results posted that have error rate so low the code prints "0.0000%". Please keep in mind concluding any capacitor is better than another is quite dicey if the error rate is very low. When the test runs for a fairly short length of time, even less reliable to draw any conclusions.
 
joepasquariello said:
Not to get in the way of your progress, but I'm curious if someone can summarize or just comment on what you've learned about the relative speed of SDRAM to TCM, RAM, PSRAM?
Click to expand...
Speed-wise, SDRAM sits between RAM and PSRAM. Even in a worst-case scenario (random access reads that negate the benefits of a cache and burst-access) it's more than twice the speed of PSRAM.
 
PaulStoffregen said:
I'm seeing several results posted that have error rate so low the code prints "0.0000%". Please keep in mind concluding any capacitor is better than another is quite dicey if the error rate is very low. When the test runs for a fairly short length of time, even less reliable to draw any conclusions.
Click to expand...
Indeed many millions with dozens or hundreds of errors gives 0.0000% with the precision specified. Doing more tests takes both up in proportion - though sometimes more and some less - each run is its own thing it seems not from a specific value or address it seems.
Any measurable number of Errors suggests it isn't 100% reliable - but when it goes to 0.0### that is bad and then totally worst case seems to top out at 20-21%. Unless there is a perfect CAP then 227 MHz seems to be the last one giving zero Errors even with elevated repeat test counts on both boards.
joepasquariello said:
Not sure what you mean. Can you say more?
Click to expand...
Perhaps you had some prior code showing such testing?
 
Been trying to follow the testing results but it does get confusing. when doing your testing with caps have you tried to see the impact of running at official speeds like 133Mhz and 166Mhz.
 
Just put a Fresh 10 pF on this original DevBoard and 240 MHz still seems to resolve better with 12 pF at 5 ReReads:
12 pF p#729: 24 read errors {p#272 was: 18 read errors}
10 pF fresh: 933 read errors {similar to prior CAP and soldering}
mjs513 said:
Been trying to follow the testing results but it does get confusing. when doing your testing with caps have you tried to see the impact of running at official speeds like 133Mhz and 166Mhz.
Click to expand...
Yes, post#157 https://forum.pjrc.com/index.php?threads/call-to-arms-teensy-sdram-true.73898/post-338077

As with No CAP at all - these low value CAPs seem to have to problem like the 'factory' too big cap did and seems to work well: 133 ... 227 MHz.
 
You must log in or register to reply here.
Back
Top