Call to arms | Teensy + SDRAM = true

Bummer the comment and code didn't match - that was pulled from the ReadMe.
Logic was right back when I was testing CAPS :(

Great the TEST worked in the end on 2nd pass and such a wide range of CAPS at 221 MHz!
I mentioned when testing started 6 hours ago that the TIME is constant for a given speed.

And INDEED [ @PaulStoffregen ] the Test just spits out a number of Errors for a given fixed set of testing!
 
mjs513 said:
Yeah - my fault - that should all be fixed now both in the readme and the examples
Click to expand...
Was worried about that with remote testing when I didn't have a CAP to verify - but @Dogbone06 persisted after swapping and tested to see it work.

I saw some improvement with the crude CAP array - but nothing as good as observed now across a wide range! That made it seem that if it was going to work it would be a narrow window not such a wide range from 11 to 22 pF!
 
This is the latest info. I tried without any cap and it only gave 2 faults on the 57 test. I am pretty certain that all the caps I have will work.
Feels pointless to continue testing at 221MHz, we need more speed.

Cap Value13 test result in secondsErrors found57 test result in secondsErrors found57 test with 100 reReads in secondsErrors found
11 pF10,08084,4402439.020
12 pF10,08084,4402439.020
13 pF10,08084,4402439.020
15 pF10,08084,4402439.020
18 pF10,08084,4402439.020
22 pF10,08084,4402439.020
 
So Cool to see it work. Good thing it printed the time for test with error count since your first build was at 150 MHz :)

Wonder what you see if you leave the code the same and build for Teensy at 720 or 816 MHz OC speeds?
 
defragster said:
So Cool to see it work. Good thing it printed the time for test with error count since your first build was at 150 MHz :)

Wonder what you see if you leave the code the same and build for Teensy at 720 or 816 MHz OC speeds?
Click to expand...
I tested at 720 and 816. The 720 works but 816 gives errors.

Is it possible to go higher than 221 for the SDRAM? And how do we do that?
 
Dogbone06 said:
I tested at 720 and 816. The 720 works but 816 gives errors.

Is it possible to go higher than 221 for the SDRAM? And how do we do that?
Click to expand...
What did time on 720 look like?
Not sure about clock adjustments - just saw it was done. 196 is unique from the others - so there are some limited options.
 
I don’t remember but I can test again tomorrow. Problem is that we don’t know what the SDRAM speed is when going 720 on the NXP. But I’ll test again and we can see the time.
 
Dogbone06 said:
I tried without any cap and it only gave 2 faults on the 57 test.
Click to expand...

Why is the 0 pF result not shown in the table of results?


defragster said:
And INDEED [ @PaulStoffregen ] the Test just spits out a number of Errors for a given fixed set of testing!
Click to expand...

The test is overly complicated and really should be greatly simplified.

It has at least 3 ways it can be configured. Not good for a benchmark. It should run in only 1 way. When people not familiar with the code say they ran it and share their result, we should have zero doubt how it was actually run. Giving ANY ability to configure how the test runs only invites opportunity for confusion when different people share results, because we can't be certain they chose the same option.

The test seems to print at least 2 results, one involving 13 tests and another with 57 tests. This too is counterproductive. The 13 test should be removed. It just makes everything far more complicated for humans to share and compare results. A test that takes a very long time and gives only 1 result is far superior when you factor in the casual way humans communicate.

If you want the test to be "user friendly", print a message at the beginning to advise the user how long they will wait. Even if it's over an hour, simply state the expected length of time and people who want to run the test can deal with it.

We can also see from Dogbone06 results that show just 2 errors on the longest test that the test duration is not long enough.
 
Last edited:
Printing the time taken also just adds unnecessary information. Look at msg #550 to see how printing extra info causes confusion.

Please update the test to show the results more clearly. If you really want to show extra info, please print something like:

Code: 
Test Result: 0 read errors

Extra info: ran for 2439.02 seconds

Remember, people who do not understand how the test works or even what it really does will run this program and then attempt to communicate the results. Humans communicate casually and without precision. A more technically complete set of info shown isn't helpful.
 
Test as written was to allow for having to swap caps and repeat tests without any real hope of having it work.
Feedback presented to that end gave an idea of the time required for repeat runs as needed so you could set a timer and come back.
Feedback and operation were specifically done for somebody not understanding the code.
Now that results are showing much better than the long wired attempt here it can be further refined knowing it can work.

It worked as needed and written to find that first really big range of usable CAP values.
In fact as noted having it run by @Dogbone06 and seeing one result I knew it was not running write as built because of an IDE setting showing the results were unusable.

Modification of the results is almost trivial ... hardly worth the repeat negative lengthy pounding on it, it seems to get about 4 times now after first real use. Very off putting :(

Something easily constructive and worked with:
Test Result: 0 read errors

Extra info: ran for 2439.02 seconds
Click to expand...

Edited to run on power up - giving system spec notes SDRAM and F_CPU speed, then runs FAST test with result for 3 ReReads, proceeds to then run longer 100 ReRead test that will take over 40 minutes and can be allowed to complete if the FAST test shows it is worth waiting.

Now on github:
Code: 
EXTMEM Memory Test, 32 Mbyte   SDRAM speed 198 Mhz F_CPU_ACTUAL 600 Mhz begin@ 80000000  end@ 82000000

  --- START 57 test patterns ------ with 3 reReads ... wait ...
#############............................................
Test result: 0 read errors

Extra info: ran for 85.80 seconds

  --- START 57 test patterns ------ with 100 reReads ... wait ...
#############............................................
Test result: 0 read errors

Extra info: ran for  2480.03 seconds

@mjs513 - should be using your prior update for useDQS and without a CAP onboard it was failing until I set this - which seems to contradict the comment as edited?
uint32_t useDQS = true; // "false" if a capacitor is not present on pin EMC_39
 
Last edited:
PaulStoffregen said:
Why is the 0 pF result not shown in the table of results?
Click to expand...
Because the tests I’m performing are with the caps you told me to buy. I’m running through them all.

But it’s all irrelevant at this point because 221MHz seems to work with all or atleast most of the caps with 0 errors. So we need more speed.

EDIT: This should work, but I'm a noob when it comes to low-end code.
I've added // 2 which should give 332MHz, may be to fast, but we wont know until I try it with the caps.
Other speeds in between 221 and 332 would be nice to have if possible.
if(clockdiv == 2) {
CCM_CBCDR = (CCM_CBCDR & ~(CCM_CBCDR_SEMC_PODF(7) | CCM_CBCDR_SEMC_ALT_CLK_SEL)) |
CCM_CBCDR_SEMC_CLK_SEL | CCM_CBCDR_SEMC_PODF(clockdiv-1);
/* If it doesn't work, maybe try soldering a 5pF or 10pF capacitor at C29
*/
} else {
// use PLL3 PFD1 664.62 divided by 4 or 5, for 166 or 133 MHz
// 5 = 133mhz
// 4 = 166mhz - SDRAM rated, see post #60
// 3 = 221mhz
// 2 = 332mhz // ADDED BY DOGBONE06
CCM_CBCDR = (CCM_CBCDR & ~(CCM_CBCDR_SEMC_PODF(7))) |
CCM_CBCDR_SEMC_CLK_SEL | CCM_CBCDR_SEMC_ALT_CLK_SEL |
CCM_CBCDR_SEMC_PODF(clockdiv-1);
}
Click to expand...
 
Last edited:
I would add to the speed select switch case:
CASE: 332: clock_div = 1;

Then in the code posted above:

Code: 
if(clockdiv == 2) {
CCM_CBCDR = (CCM_CBCDR & ~(CCM_CBCDR_SEMC_PODF(7) | CCM_CBCDR_SEMC_ALT_CLK_SEL)) |
CCM_CBCDR_SEMC_CLK_SEL | CCM_CBCDR_SEMC_PODF(clockdiv-1);
/* If it doesn't work, maybe try soldering a 5pF or 10pF capacitor at C29
*/
}
else if (clockdiv == 1){
// 1 = 332mhz // ADDED BY DOGBONE06
CCM_CBCDR = (CCM_CBCDR & ~(CCM_CBCDR_SEMC_PODF(7))) |
CCM_CBCDR_SEMC_CLK_SEL | CCM_CBCDR_SEMC_ALT_CLK_SEL |
CCM_CBCDR_SEMC_PODF(1);
}
else {
// use PLL3 PFD1 664.62 divided by 4 or 5, for 166 or 133 MHz
// 5 = 133mhz
// 4 = 166mhz - SDRAM rated, see post #60
// 3 = 221mhz
CCM_CBCDR = (CCM_CBCDR & ~(CCM_CBCDR_SEMC_PODF(7))) |
CCM_CBCDR_SEMC_CLK_SEL | CCM_CBCDR_SEMC_ALT_CLK_SEL |
CCM_CBCDR_SEMC_PODF(clockdiv-1);
}

It's a little ugly but might work
 
I think it's safe to assume that all these cap values work fine with 221MHz, I don't think more testing is needed at these speeds. Lowest value works and highest values work. I tested the higher ones first but I switched to the lowest as it worked so good. And because the lowest work as well, the midrange should as well.

Once the sketch supports higher speeds I will continue, until then I will suspend testing.
Cap Value13 test result in secondsErrors found57 test result in secondsErrors found57 test with 100 reReads in secondsErrors found
1.0 pF10,08084,4402439.020
1.5 pF
2.2 pF
2.7 pF
3.3 pF
3.9 pF
4.3 pF
4.7 pF
5.6 pF
6.8 pF
7.5 pF
8.2 pF10,08084,4402439.020
9.1 pF10,08084,4402439.020
10 pF10,08084,4402439.020
11 pF10,08084,4402439.020
12 pF10,08084,4402439.020
13 pF10,08084,4402439.020
15 pF10,08084,4402439.020
18 pF10,08084,4402439.020
22 pF10,08084,4402439.020
 
Last edited:
@dogbone - can you run the current posted sketch and see which way that useDQS value needs to be set with your CAP installed?
It would tak getting the current SDRAM_t4 library from github and overwrite your current copy then check the value used at the top of the file for speed and that DQS value when there is a working CAP installed?
defragster said:
@mjs513 - should be using your prior update for useDQS and without a CAP onboard it was failing until I set this - which seems to contradict the comment as edited?
uint32_t useDQS = true; // "false" if a capacitor is not present on pin EMC_39
Click to expand...
 
defragster said:
@dogbone - can you run the current posted sketch and see which way that useDQS value needs to be set with your CAP installed?
It would tak getting the current SDRAM_t4 library from github and overwrite your current copy then check the value used at the top of the file for speed and that DQS value when there is a working CAP installed?
Click to expand...
I have. With the updated version from mjs513, useDQL = true, is the way to go when using a capacitor. Just like the logic says.

These are the settings used:
Code: 
#include "SDRAM_t4.h"
uint32_t readRepeat = 3;  // Writes once to Test memory, will repeat Reads and Test compare 'readRepeat' times
uint32_t readFixed = 1; // start loop and run only Fixed Patterns once
uint32_t speed = 221; // 133, 166, 198, 221
uint32_t useDQS = true; // "false" if a capacitor is present on pin EMC_39
 
This top 1 pF value works with no errors as noted?
Dogbone06 said:
I think it's safe to assume that all these cap values work fine with 221MHz, I don't think more testing is needed at these speeds. Lowest value works and highest values work. I tested the higher ones first but I switched to the lowest as it worked so good. And because the lowest work as well, the midrange should as well.

Once the sketch supports higher speeds I will continue, until then I will suspend testing.
Cap Value13 test result in secondsErrors found57 test result in secondsErrors found57 test with 100 reReads in secondsErrors found
1.0 pF10,08084,4402439.020
Click to expand...
 
Dogbone06 said:
I have. With the updated version from mjs513, useDQL = true, is the way to go when using a capacitor. Just like the logic says.

These are the settings used:
Code: 
#include "SDRAM_t4.h"
uint32_t readRepeat = 3;  // Writes once to Test memory, will repeat Reads and Test compare 'readRepeat' times
uint32_t readFixed = 1; // start loop and run only Fixed Patterns once
uint32_t speed = 221; // 133, 166, 198, 221
uint32_t useDQS = true; // "false" if a capacitor is present on pin EMC_39
Click to expand...
Thanks for the note.
Very odd that with no CAP here at 198 MHz that same value was required, or I got All Errors on the PRand tests????
Just rebuilt and tested on the DevBoard here again.

ALSO: thanks for confirming even 1 pF works - my CAPs were in that range but wrong type or poor soldering with added wire to attach the through hole parts.
 
defragster said:
Thanks for the note.
Very odd that with no CAP here at 198 MHz that same value was required, or I got All Errors on the PRand tests????
Just rebuilt and tested on the DevBoard here again.

ALSO: thanks for confirming even 1 pF works - my CAPs were in that range but wrong type or poor soldering with added wire to attach the through hole parts.
Click to expand...
The caps I use are all from the same brand and ofc the right size, which eliminates errors. And If I may say so myself, I'm quite good at soldering small stuff. It's pretty cool that 221MHz is so stable. It's overclocked by 55MHz. Wonder where the limit is.
 
defragster said:
@mjs513 - should be using your prior update for useDQS and without a CAP onboard it was failing until I set this - which seems to contradict the comment as edited?
uint32_t useDQS = true; // "false" if a capacitor is not present on pin EMC_39
Click to expand...
Actually that comment should be totally reworked. Yes its correct that useDQS should be set to false if no cap is present however as @jmarsh pointed out you have to set useDQS = true if you want to go above 133mhz

see this post: https://forum.pjrc.com/index.php?threads/call-to-arms-teensy-sdram-true.73898/post-337700

in addition it defaults to true in the library.
 
Opps, I left in a Serial.printf() line. Might be helpful for initial testing, but should be commented out after this code is actually tested on the real hardware.

Edit: also see a silly mistake I made, pushed another commit. Please grab the latest if trying this.
 
Last edited:
You must log in or register to reply here.
Back
Top