Call to arms | Teensy + SDRAM = true

Dogbone06 said:
I guess what we want to find is the test that takes the least amount of time.
Click to expand...

No, it's the total number of errors that matter. The time taken is irrelevant. Early on I asked over and over for this test to always try a consistent number of reads (no early abort) and to always print 1 simple number. But as so often happens with software development, the best intentions to provide more features and extra information that might be useful usually end up just making everything more complicated and difficult to understand and use.

The general idea is to first find a frequency where adding different capacitors actually makes a difference. Then test some or all capacitors at that frequency.
 
jmarsh said:
This is why I made my code automatically use DQS for any frequency above 133MHz... it's guaranteed not to work otherwise, so why make it an option.
Click to expand...
I am really curious to see what you come up with regarding eLCD and generalt display stuff. I understand that you possess much knowledge about that stuff.

@Paul, So the test I'm doing now, is it relevant at all or should I change it before continuing?
 
Just to explain a bit more, the idea is to find an overclock frequency just slightly too fast for the SDRAM to work, but not so fast than it's failing 100% of the reads.

This is why the total number of read errors matters. Or really the percentage of the reads that failed is what really matters.

We might end up using an overclock frequency where the SDRAM is never really reliable, no matter what capacitor is used. Obviously nobody would use such a frequency for a real project. But for the sake of exploring the timing margin, a fast frequency where the SDRAM is sometimes giving errors (even 20% or more) but sometimes reading correctly is just what we need. We want to push it to the limit where it's just starting to fail.

That is the place where we can expect to best see the effect of using the different capacitors. Even if no capacitor makes it 100% reliable at this speed, what we're looking for here is comparing the percentage of failed reads.
 
I understand. So the test I'm running now (https://github.com/mjs513/SDRAM_t4/blob/main/examples/CapReadSDRAM/CapReadSDRAM.ino), is it relevant enough for this?
So far this is the data I've gathared. If it's not right then @defragster and/or @mjs513 may be able to alter the code to suit the needs.

What I got so far:
Cap Value13 test result in secondsErrors found57 test result in secondsErrors found57 test with 100 reReads in secondsErrors found
15 pF10,08084,4402439.020
18 pF10,08084,4402439.020
 
Hopefully it's not a huge stretch of imagination that if a specific capacitor improves or reduces the number of read errors at some impractically high overclock frequency, then using that capacitor at the rated 166 MHz speed (probably) gives better / best timing margin.
 
Last edited:
I guess we'll see from this test. We will learn from it, and from there we can continue with more in-depth tests. :)
 
Zero errors found on all tests (including the test with no capacitor soldered) means a higher frequency is needed.

Don't waste a lot of time testing every capacitor. Just test no capacitor and maybe 2 or 3 across the range. If all give no errors, there's no point wasting more time testing at that frequency.

Hopefully I've explained the rationale?
 
Dogbone06 said:
I am really curious to see what you come up with regarding eLCD and generalt display stuff. I understand that you possess much knowledge about that stuff.
Click to expand...
The code is on my github, with instructions in the elcdif_vga example describing how to build the R2R ladder for VGA output (except the pin numbers are still for Teensy 4.1 since there's no equivalents for micromod)... I'm not hoarding it by any means, the LCD register field definitions were already added to the core to make them more usable.
 
Dogbone06 said:
I think that noCap set to true, means that the cap is there. Atleast from the tests I'm doing. It works at 221MHz. So I will continue as such.
Click to expand...
Sorry was busy with working the camera showed - trying to get camera working with FlexIO.

but in answer to your question Nope. noCap is just what is says no Cap is present on the board - comment next to says it:
Rich (BB code): 
uint32_t noCap = true; // "false" if a capacitor is present on pin EMC_39
 
mjs513 said:
Nope. noCap is just what is says no Cap is present on the board - comment next to says it:
Rich (BB code): 
uint32_t noCap = true; // "false" if a capacitor is present on pin EMC_39
Click to expand...
But it's wrong. With that set to FALSE, all tests fail with all capacitors.

With it set to TRUE, it works and I get these results:

Cap Value13 test result in secondsErrors found57 test result in secondsErrors found57 test with 100 reReads in secondsErrors found
15 pF10,08084,4402439.020
18 pF10,08084,4402439.020
 
I am performing tests with the highest speed of 221MHz, altho Paul says that we should go higher. So what other speeds can we do?
I suggest changing the name of noCap to "UseDQS" where TRUE is with Capacitor present and FALSE is without.
 
Dogbone06 said:
I am performing tests with the highest speed of 221MHz, altho Paul says that we should go higher. So what other speeds can we do?
I suggest changing the name of noCap to "UseDQS" where TRUE is with Capacitor present and FALSE is without.
Click to expand...
Will make that change right now - and you are right.

Code: 
    if(NOCAP == 1) {
        SEMC_MCR |= SEMC_MCR_MDIS | SEMC_MCR_CTO(0xFF) | SEMC_MCR_BTO(0x1F) | SEMC_MCR_DQSMD;
    } else  { // enable SEMC_MCR_DQSMD (EMC_39
        SEMC_MCR |= SEMC_MCR_MDIS | SEMC_MCR_CTO(0xFF) | SEMC_MCR_BTO(0x1F);
    }
 
mjs513 said:
Actually I believe you can go up to 166 or 198 without the cap - but its a good idea
Click to expand...
Without a capacitor yes, but the control register must have DQSMD set in those cases. If it's not set there is no chance of those speeds working no matter if the pin is floating or connected to anything.
 
jmarsh said:
Without a capacitor yes, but the control register must have DQSMD set in those cases. If it's not set there is no chance of those speeds working no matter if the pin is floating or connected to anything.
Click to expand...
thanks - probably worked because the test was wrong.
 
If CCM_CBCDR_SEMC_CLK_SEL and CCM_CBCDR_SEMC_ALT_CLK_SEL are both cleared in CCM_CBCDR, the base clock (before CCM_CBCDR_SEMC_PODF is applied) is the CPU clock*. So you can use that with dividers to get other frequencies... but the downside is it also changes the CPU clockspeed.
As examples, CPU set to 720MHz divided by 3 (SEMC_PODF = 2) gives 240MHz. Or 600Mhz / 2 would be 300Mhz.

(* as long as AHB_PODF is 0, which it nearly always is except for very low CPU speeds.)
 
jmarsh said:
If CCM_CBCDR_SEMC_CLK_SEL and CCM_CBCDR_SEMC_ALT_CLK_SEL are both cleared in CCM_CBCDR, the base clock (before CCM_CBCDR_SEMC_PODF is applied) is the CPU clock*. So you can use that with dividers to get other frequencies... but the downside is it also changes the CPU clockspeed.
As examples, CPU set to 720MHz divided by 3 (SEMC_PODF = 2) gives 240MHz. Or 600Mhz / 2 would be 300Mhz.

(* as long as AHB_PODF is 0, which it nearly always is except for very low CPU speeds.)
Click to expand...

It works because I flipped the boolean to true after I had performed all the Cap tests with false.
I am running this test sketch which I did not write. The stuff you mention is way above my league.

https://github.com/mjs513/SDRAM_t4/blob/main/examples/CapReadSDRAM/CapReadSDRAM.ino
 
Just retesting now on the test board with no cap present:
Settings:
Rich (BB code): 
uint32_t speed = 198; // 133, 166, 198, 221
uint32_t useDQS = true; // "false" if a capacitor is not present on pin EMC_39

Results:
Clock13 test result in secondsErrors found57 test result in secondsErrors found
16612.7093.380
19811.04087.370
22110.08084.44131

if I change useDQS to false
Clock13 test result in secondsErrors found57 test result in secondsErrors found
13315.40102.980
16612.7093.3822,145,853,510
 
mjs513 said:
Saw that in your stuff that was the only reason didn't add that to the lib.
Click to expand...
I want to go above 221MHz, I did a dirty test with 15pF cap and raised the NXP MHz to 720, it worked, but at 816MHz it gave errors.
So what is the next number after 221 to use with 600MHz NXP ?
 
You must log in or register to reply here.
Back
Top