Call to arms | Teensy + SDRAM = true

defragster · Feb 1, 2024

@PaulStoffregen ran again with prec 4 to 8 digits for percentage and with 25 ReReads using 10 pF it shows:

Code:

Start 57 test with 25 reads 240.00 MHz ... wait::#####e#######AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAA
Test result: 4202 read errors (0.00000879%)
Extra info: ran for 573.23 seconds at 240 MHz

Start 57 test with 25 reads 254.12 MHz ... wait::aa#a#a####a##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 217063760 read errors (0.45396522%)
Extra info: ran for 560.03 seconds at 254 MHz

The 240 MHz that works with 0 Errors for @Dogbone06 doesn't meet tha same bar on this 'same' board.
There is a clear move to worse at 254 MHz.

Another run at 240 same 25 rereads on 10 pF - more errors this time. Same Fixed pattern fail - but on one pass later:

Code:

Start 57 test with 25 reads 240.00 MHz ... wait::#####f#######AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 5322 read errors (0.00001113%)
Extra info: ran for 573.24 seconds at 240 MHz

PaulStoffregen · Feb 1, 2024

In msg #746, I was *not* suggesting to increase the number of digits printed. Doing so seems to miss the point.

jmarsh · Feb 2, 2024

I sent a pull request for cores to support multiple startup hook functions: https://github.com/PaulStoffregen/cores/pull/734
The reason I need this is because both the SDRAM library and a threading library that my USB Host implementation uses, rely on overriding startup_middle_hook(). Without it I have to patch one of them to call the other, which I'd prefer not to do since they are designed to function independently.

Example usage:

Code:

/* demonstration of multiple startup hooks
 * Expected output (last two lines may be switched - order of custom registered hooks is not defined)
 * > Hello from startup_late_hook
 * > Hello from first_late_hook
 * > Hello from second_late_hook
 */

extern "C" void startup_late_hook(void)
{
  Serial.begin(0);
  while (!Serial);

  Serial.println("Hello from startup_late_hook");
}

static void first_late_hook(void)
{
  Serial.println("Hello from first_late_hook");
}

static void second_late_hook(void)
{
  Serial.println("Hello from second_late_hook");
}

REGISTER_LATE_STARTUP(first_late_hook);
REGISTER_LATE_STARTUP(second_late_hook);

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH);
  delay(1000);
  digitalWrite(LED_BUILTIN, LOW);
  delay(1000);
}

Dogbone06 · Feb 2, 2024

jmarsh said:
I sent a pull request for cores to support multiple startup hook functions: https://github.com/PaulStoffregen/cores/pull/734
The reason I need this is because both the SDRAM library and a threading library that my USB Host implementation uses, rely on overriding startup_middle_hook(). Without it I have to patch one of them to call the other, which I'd prefer not to do since they are designed to function independently.

Example usage:

Code:

/* demonstration of multiple startup hooks * Expected output (last two lines may be switched - order of custom registered hooks is not defined) * > Hello from startup_late_hook * > Hello from first_late_hook * > Hello from second_late_hook */ extern "C" void startup_late_hook(void) { Serial.begin(0); while (!Serial); Serial.println("Hello from startup_late_hook"); } static void first_late_hook(void) { Serial.println("Hello from first_late_hook"); } static void second_late_hook(void) { Serial.println("Hello from second_late_hook"); } REGISTER_LATE_STARTUP(first_late_hook); REGISTER_LATE_STARTUP(second_late_hook); void setup() { pinMode(LED_BUILTIN, OUTPUT); } void loop() { digitalWrite(LED_BUILTIN, HIGH); delay(1000); digitalWrite(LED_BUILTIN, LOW); delay(1000); }

So you got the USB Host stuff to work by removing the diode and supplying your own power to the board?

Dogbone06 · Feb 2, 2024

defragster said:
@PaulStoffregen ran again with prec 4 to 8 digits for percentage and with 25 ReReads using 10 pF it shows:

Code:

Start 57 test with 25 reads 240.00 MHz ... wait::#####e#######AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAA Test result: 4202 read errors (0.00000879%) Extra info: ran for 573.23 seconds at 240 MHz Start 57 test with 25 reads 254.12 MHz ... wait::aa#a#a####a##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Test result: 217063760 read errors (0.45396522%) Extra info: ran for 560.03 seconds at 254 MHz

The 240 MHz that works with 0 Errors for @Dogbone06 doesn't meet tha same bar on this 'same' board.
There is a clear move to worse at 254 MHz.

Another run at 240 same 25 rereads on 10 pF - more errors this time. Same Fixed pattern fail - but on one pass later:

Code:

Start 57 test with 25 reads 240.00 MHz ... wait::#####f#######AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Test result: 5322 read errors (0.00001113%) Extra info: ran for 573.24 seconds at 240 MHz

Did you try the 10pF? And if so, please show the cap on the board. I want to see if perhaps soldering is affecting it.

jmarsh · Feb 2, 2024

Dogbone06 said:
So you got the USB Host stuff to work by removing the diode and supplying your own power to the board?

Yes it works just like the Teensy 4.1 host port. Except I'm very careful not to hot plug since there's no protection IC.

Dogbone06 · Feb 2, 2024

jmarsh said:
Yes it works just like the Teensy 4.1 host port. Except I'm very careful not to hot plug since there's no protection IC.

Pretty cool that it works tho. I actually have a USB PD curcuit for another project. It can do 5, 9, 12, 15, 20V. It negotiates with the other side. Would be cool to implement that on a gen5 dev board for USB HOST. It can also do up to 3A of current on all of the voltages above except for 20V where the current is 2.25A.

Rezo · Feb 2, 2024

jmarsh said:
Yes it works just like the Teensy 4.1 host port. Except I'm very careful not to hot plug since there's no protection IC.

How does usb serial work with usb host on the same port? Can it support both at the same time?

jmarsh · Feb 2, 2024

Rezo said:
How does usb serial work with usb host on the same port? Can it support both at the same time?

It doesn't. The USB Host library resets the port and replaces the interrupt handler.

defragster · Feb 2, 2024

@Dogbone06 Here is an extended 50 ReRead Run at 10 pF currently installed - similar to prior.
Not seen 240 MHz complete without errors even with 10 pF and the error count is lower when I run 12 pF

10 pF	50 ReReads
Mhz	Errors	%	Time Secs
133	0	0	1462
166	0	0	1312
196	0	0	1220
206	0	0	1199
216	0	0	1811
227	0	0	1151
240	12525	0	1129
254	540,189,631	0.5469	1109
270	1,028,575,964	19.0405	1090
288	2,597,339,105	20.6809	1069

Here is another quick run after the 2nd (smaller) picture when I hit with solder again

Code:

Start 57 test with 25 reads 240.00 MHz ... wait::#####c####w##AAABBAAAAABAAAAABABACABAABAAAAAAAAAAAAAAAAAA
Test result: 3072 read errors (0.0000%)
Extra info: ran for 573.23 seconds at 240 MHz

PaulStoffregen said:
In msg #746, I was *not* suggesting to increase the number of digits printed. Doing so seems to miss the point.

Indeed, wasn't sure of the point.

PaulStoffregen · Feb 2, 2024

defragster said:
Indeed, wasn't sure of the point.

From msg #746: "concluding any capacitor is better than another is quite dicey if the error rate is very low"

I see you're showing results from 10 different frequencies, but the one you choose to show in detail is (rounded off) 0.0000% error rate.

defragster · Feb 2, 2024

@Dogbone06: have you tried going higher than 10 pF - 12 improved here and 13.6 seems even better.

Just put two 6.8 pF's on this DevBoard and running at 240 MHz.
Test off to best start ever for 240 MHz. It finished - started another run of 240 and 254 to see if it goes downward:

Code:

Start 57 test with 25 reads 240.00 MHz ... wait::#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 570.14 seconds at 240 MHz

I had them stacked and iron grabbed them before the tweezers were in place

Got them together side by side and held them down and did not fry them

How heat tolerant are these LITTLE things?

@PaulStoffregen: Haven't gotten to the point of Any good CAP for 240 MHz on this board - where if it doesn't complete with zero errors it isn't fit to use. The Timing must be GOOD/CLOSE no doubt - or it wouldn't run with so few errors - but the best CAP isn't in hand yet.

Puzzled why @Dogbone06 seeing 240 work without Error so well/easy - maybe I solder better

defragster · Feb 2, 2024

second run 13.6 pF (twin 6.8's) 25 ReReads 240 MHz then 254 MHz:
> Error count at 254 here with 13.6 is: 3,662,306 Versus Above 50 ReReads with 10 pF: 540,189,631/2== ~270,094,815
> New 50 ReRead start 227 MHz-288 ... results in some hours.

Code:

Start 57 test with 25 reads 240.00 MHz ... wait::#############............................................
Test result: 0 read errors (0.0000%)
Extra info: ran for 570.14 seconds at 240 MHz


Start 57 test with 25 reads 254.12 MHz ... wait::#####a####b##AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 3662306 read errors (0.0077%)
Extra info: ran for 560.03 seconds at 254 MHz

Prior 50 ReRead at 10 pF and 254 MHz didn't do as well on the Fixed patterns - failing more earlier - this seems to be in the best direction for this (same board different build run):

Code:

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

defragster · Feb 2, 2024

@Dogbone06 - Look for Updated code "CapReadSDRAMTest.ino" - will post again with edit notes to tune the test range if desired.

Don't trust the LARGE numbers above/prior - the printf(%u) wasn't bothering with some 64 bit uint added value picked up by printf(%llu)

Just got a lower % on 270 MHz and the count was larger ... since it overflowed LESS into the upper 32 bits - only 13.8 Billion Errors.

@PaulStoffregen : CapReadSDRAM.ino % Error fixed : Read is count of DWORDS not Bytes
> also edited to %llu

Code:

  const double totalReads = (double)size * 1048576 * 25 * testCnt;
  const double totalReads = (double)size/sizeof(uint32_t) * 1048576 * 25 * testCnt;

> So All reported Error % are 4 Times too small as well ...
Output from Pauls code edit {25 ReReads at 254 MHz}

Code:

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

Extra info: ran for 579.27 seconds

13.6 pF repeated again with 50 ReReads and it is 4.5% better than with 10 pF ... so perhaps an 18% improvement ...

Arrgggh ... will run all for what may be accurate number reporting ... but Only Near Fit (32bit Errors) CAPs were giving good raw counts.
Corrected 64 bit Errors here ONLY for 13.6 pF CAP to show the DIFF - see how 270 MHz went 19% to %14.48 with bigger count? And 288 MHz is still no good and those errors are 1/4% (underlined values are suspect/wrong)

10 pF	50 ReReads			13.6 pF 2*6.8	50 ReReads
Mhz	Errors	%	Time Secs	Mhz	Errors	%	Time Secs
240	12525	0	1129	240	0	0	1129
254	540,189,631	0.5469	1109	254	3,584,626	0.0037	1109
270	1,028,575,964	19.0405	1090	270	13,851,503,015	14.4845	1090
288	2,597,339,105	20.6809	1069	288	19,819,291,638	20.7039	1069

A Quick run completed here with 5 ReReads: {CapReadSDRAMTest.ino v1.0}

*13.6 pF (26.8)**	5 ReReads
Mhz	Errors	%	Time Secs
240	0	0	123.88
254	931,389	0.039	121.23
270	1,384,692,306	57.9187	119.36
288	1,981,353,010	82.8757	117.24

Dogbone06 · Feb 2, 2024

defragster said:
@Dogbone06 Here is an extended 50 ReRead Run at 10 pF currently installed - similar to prior.
Not seen 240 MHz complete without errors even with 10 pF and the error count is lower when I run 12 pF

10 pF 50 ReReads
Mhz Errors % Time Secs
133
0
0
1462
166
0
0
1312
196
0
0
1220
206
0
0
1199
216
0
0
1811
227
0
0
1151
240
12525
0
1129
254
540,189,631
0.5469
1109
270
1,028,575,964
19.0405
1090
288
2,597,339,105
20.6809
1069

View attachment 33130 View attachment 33131
Here is another quick run after the 2nd (smaller) picture when I hit with solder again

Code:

Start 57 test with 25 reads 240.00 MHz ... wait::#####c####w##AAABBAAAAABAAAAABABACABAABAAAAAAAAAAAAAAAAAA Test result: 3072 read errors (0.0000%) Extra info: ran for 573.23 seconds at 240 MHz

Indeed, wasn't sure of the point.

Concerning that you can’t get 10pF to run without fault like I do. It’s the same capacitor (you ordered the same parts right?) and the same board.

For you 12pF works better and for me 10pF works better. Interesting!

defragster · Feb 2, 2024

Dogbone06 said:
Concerning that you can’t get 10pF to run without fault like I do. It’s the same capacitor (you ordered the same parts right?) and the same board.

For you 12pF works better and for me 10pF works better. Interesting!

Correct, Until this board went to 13.6 pF (twin 6.8's) 240 MHz always had errors - using the lead solder shown in the images I have done a few runs with 240 MHz and No Errors. <edit> And 'Yes' I plugged posted part numbers into Mouser and got 'Murata Multilayer Ceramic Capacitors MLCC' - image of order was posted.

I just updated the Test on github example: 5 ReReads at MHz: 216, 227, 240, 254, 270

SDRAM_t4/examples/CapReadSDRAMTest/CapReadSDRAMTest.ino at main · mjs513/SDRAM_t4

Contribute to mjs513/SDRAM_t4 development by creating an account on GitHub.

github.com

Top sketch lines control the Starting array zero based index, and how many of the end elements should be skipped, and of course the ReRead count is adjustable. The code below (as on github) will run with the details above.:

Code:

#define FIRST_SPEED 4 // ZERO BASED index: into speedRange to start testing: [0]==133 and [5]==227
#define SKIP_LAST_SPEEDS 1 // COUNT: Set 0 to run to end of array. When 2 it will skip the last two {270, 288}

// index offset 1st ref:   0    1    2    3    4    5    6    7    8    9
uint32_t speedRange[] = {133, 166, 196, 206, 216, 227, 240, 254, 270, 288}; // ? frequencies 173,180,187,196,206,216,227,240,254,270,288

#define TYPICAL_REREADS 5 // 25 // 100
uint32_t speed = 0; // If speed not ZERO do a single SPEED test. If ZERO follow loop with control index #defines above

NOTE: When added as CODE - BOLD does not work

- so I can't point out the items on lines: #1, #2, #7 where the Array is Line #5.
The comments are there as well - and the last line 'speed' needs to be 0 unless you want to run only a single speed.

Running that code here just finished with this output using the installed 13.6 pF:

Code:

Start 57 tests 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 tests 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 tests 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 tests with 5 reads 254.12 MHz ... wait::#####a#######AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Test result: 627222 read errors (0.0262%)
Extra info: ran for 121.23 seconds at 254 MHz

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

defragster · Feb 3, 2024

One Added Note: Whenever the 'Progress Bar' shows 'a' or "A" it is possible that value failed on Write, meaning #ReRead fails after that on each DWORD tested of the 8M.

The Test could .begin() @166 for Write, then Jump to Read test speed to catch that. Or Write at Test Speed and Drop to 166MHz for a Read/Test so see if it failed. That would require not having the 'patternTest' in the .begin().

That wouldn't be a solution for USE, but it would explain something about Error counts.

As shown above for 254 MHz: only ONE Fixed pattern failed - and it was on the FIRST Read/Test. The PsuedoRandom number patterns put 'Psuedo' unique number in 44 repeatable orderings - and perhaps some few of those values won't write?

Dogbone06 · Feb 3, 2024

With the latest code: https://github.com/mjs513/SDRAM_t4/blob/main/examples/CapReadSDRAMTest/CapReadSDRAMTest.ino
Testing 3 different capacitors to compare my results to the ones of @defragster.

Either his new code is the reason to why I now get better results then before, or there are some other factor in play. I did add a tad more solder to the cap(s) to try to match @defragster's solderwork after getting a picture from him.

Results:

Cap Value	Speed	Read fails (No)	Read fails (%)	Time (seconds)

10 pF	227MHz	0	0	125,52
	240MHz	0	0	123,26
	254MHz	175176	0.0018%	121,23

12 pF	227MHz	0	0	125,52
	240MHz	0	0	123,26
	254MHz	387393	0.0041%	121,23

13,6 pF (6.8*2)	227MHz	0	0	125,52
	240MHz	0	0	123,88
	254MHz	486701	0.0051%	121,23

defragster · Feb 3, 2024

Interesting to see @Dogbone06 - fun that twin PCB design boards somehow diverge on ideal CAP.
That Hot Air station on the way for 2/4 - fresh paste 2/5. might give it a try to get matching range of results and do the speed reversion on fail with reread just out of curiosity.

PaulStoffregen · Feb 4, 2024

Dogbone06 said:
It’s the same capacitor (you ordered the same parts right?) and the same board.

The capacitor part numbers I gave were all 1% or 2% tolerance capacitors.

The PCBs are also probably pretty similar if made by the same vendor. With JLCPCB several factories are in play, but even if their different factories use different layer stackup, the PCB is expected to have only a minor effect because the trace is short and SMT pads are fairly small.

However, the chips are anticipated to have a large effect. Even chips with the same date code can have details like mosfet channel resistance change by 20% or more from wafer to wafer, or even chips cut from opposite sides of the same wafer.

Temperature is can also be expected to play a strong role. Generally speaking, with mosfet transistors driven by fixed gate voltage, you can expect better performance as temperature decreases. If you want repeatable results testing on the same PCB with the same 2 chips, best to keep your room temperature consistent and minimize external air flow and place the PCB with the same orientation so its natural convection cooling is consistent.

defragster · Feb 4, 2024

Mouser order shows 12 pF was 2% and the rest chosen from the @Dogbone06 list shipped 1% parts.

The CAP placement/replacement should be easier with Hot Air and much lower temp (<300 instead of >>300) and time on the part should be less with solder paste doing the job.
Interesting if that shows any change - if not then the two 'twin PCB' boards made weeks apart indeed have other collective influences.

Giving a try to 166 MHz read after errors found and it took more than removing the begin() overwriting call to check_fixed_pattern().

Putting in a DoneOnce bool to skip the chip IP setup commands seems to have left the chip readable the same way with change of MCU Access clocks and then doing a 166 MHz read.

Certainly not an ideally Kosher test - but suggests that often the one and only write is what is failing when an 'a' or 'A' shows on progress bar.
The count of Errors then just multiplies with each ReRead of that value that was never right.
Dropping speed to 166 and doing a Read/Test again shows that some 1K-4K of the 8M reads do not match the expected value.
> Only 'proof' it is working as expected is that setting to 166 MHz requires resetting to current 'speed', and first run did not do that and all following tests passed that would normally show Errors. Second effort is to use 206 MHz instead of 166 for the Read/Test after Errors that should change the measured run time for the extra Read/Test pass - but now at higher speed - indeed it finishes 9 seconds faster.

defragster · Feb 4, 2024

Was questioning own results at 3AM so didn't post - but woke up to a better understanding of the one puzzle.
At 254 MHz with 13.6 pF hand soldered 5 fixed patterns have no errors and overall errors are 0.0753% so this case is far from 58% errors at 270 MHz. And on the @Dogbone06 board he registered on 0.0051% errors at 254 MHz.

Puzzle was one 'aa' - which of course means the one had Read/Test fails after valid Writes! Though all 7 other fixed did indicate Write fails.
And the Slow Read/Test after known Errors found finding what suggests a 'simple' failed initial write.
However, writing that sentence leads to a Rerun of the test with 1 ReRead and the results are telling.
Table below left column with @254 MHz and 5 ReReads shows the 'aa' - where first fixed pattern indicated no write errors (with 206 MHz Read/Test). The write column repeats the same test with a Single ReRead - and All Fixed patterns indicate the write worked there. The 'slower Read/Test' pass was 'hacked inline' - so the RetestWrite output is 'inline' with the 'progress bar' output 'a's and "A"s showing first pass Errors.

Conclusion type notes together:
> @PaulStoffregen had an idea that ReReading could scramble the SDRAM contents - and the 5 ReReads differences below 'confirm' that.
> Having the perfect/better CAP does allow more reliable MCU access even at OC speeds well in excess of the SDRAM chip spec.
> Write failures on starting Read/Test passes are a factor and assure some portion of all following Read/Tests will see Errors
> There are many factors at work that a 'Single Number' test output fail to capture @PaulStoffregen
> There are other mysteries: Why is 1024 the recurring count of RetestWrite Errors? SDRAM design with 8M DWords in 32 MB?
> Sample size is TWO, though not the same tester - but the boards are as 'identical' as parts and assembly allow.

Start 57 tests with 5 reads 254.12 MHz ... wait::#####aa		Start 57 tests with 1 reads 254.12 MHz ... wait::#####aaaaaaaaA
RetestWrite @166 Error 6 Pattern #Errs=3936a		RetestWrite @166 Error 0 pRand #Errs=1024A
RetestWrite @166 Error 7 Pattern #Errs=3936a		RetestWrite @166 Error 1 pRand #Errs=1024A
RetestWrite @166 Error 8 Pattern #Errs=3936a		RetestWrite @166 Error 2 pRand #Errs=1024A
RetestWrite @166 Error 9 Pattern #Errs=3936a		RetestWrite @166 Error 3 pRand #Errs=1024A
RetestWrite @166 Error 10 Pattern #Errs=3936a		RetestWrite @166 Error 4 pRand #Errs=1024A
RetestWrite @166 Error 11 Pattern #Errs=3936a		RetestWrite @166 Error 5 pRand #Errs=1024A
RetestWrite @166 Error 12 Pattern #Errs=3936A		RetestWrite @166 Error 6 pRand #Errs=1024A
RetestWrite @166 Error 0 pRand #Errs=1024A		RetestWrite @166 Error 7 pRand #Errs=1024A
RetestWrite @166 Error 1 pRand #Errs=1024A		RetestWrite @166 Error 8 pRand #Errs=1024A
RetestWrite @166 Error 2 pRand #Errs=1024A		RetestWrite @166 Error 9 pRand #Errs=1024A
RetestWrite @166 Error 3 pRand #Errs=1024A		RetestWrite @166 Error 10 pRand #Errs=1024A
RetestWrite @166 Error 4 pRand #Errs=1024A		RetestWrite @166 Error 11 pRand #Errs=1024A
RetestWrite @166 Error 5 pRand #Errs=1024A		RetestWrite @166 Error 12 pRand #Errs=1024A
RetestWrite @166 Error 6 pRand #Errs=1024A		RetestWrite @166 Error 13 pRand #Errs=1024A
RetestWrite @166 Error 7 pRand #Errs=1024A		RetestWrite @166 Error 14 pRand #Errs=1024A
RetestWrite @166 Error 8 pRand #Errs=1024A		RetestWrite @166 Error 15 pRand #Errs=1024A
RetestWrite @166 Error 9 pRand #Errs=1024A		RetestWrite @166 Error 16 pRand #Errs=1024A
RetestWrite @166 Error 10 pRand #Errs=1024A		RetestWrite @166 Error 17 pRand #Errs=1024A
RetestWrite @166 Error 11 pRand #Errs=1024A		RetestWrite @166 Error 18 pRand #Errs=1024A
RetestWrite @166 Error 12 pRand #Errs=1024A		RetestWrite @166 Error 19 pRand #Errs=1024A
RetestWrite @166 Error 13 pRand #Errs=1024A		RetestWrite @166 Error 20 pRand #Errs=1024A
RetestWrite @166 Error 14 pRand #Errs=1024A		RetestWrite @166 Error 21 pRand #Errs=1024A
RetestWrite @166 Error 15 pRand #Errs=1024A		RetestWrite @166 Error 22 pRand #Errs=1024A
RetestWrite @166 Error 16 pRand #Errs=1024A		RetestWrite @166 Error 23 pRand #Errs=1024A
RetestWrite @166 Error 17 pRand #Errs=1024A		RetestWrite @166 Error 24 pRand #Errs=1024A
RetestWrite @166 Error 18 pRand #Errs=1024A		RetestWrite @166 Error 25 pRand #Errs=1024A
RetestWrite @166 Error 19 pRand #Errs=1024A		RetestWrite @166 Error 26 pRand #Errs=1024A
RetestWrite @166 Error 20 pRand #Errs=1024A		RetestWrite @166 Error 27 pRand #Errs=1024A
RetestWrite @166 Error 21 pRand #Errs=1024A		RetestWrite @166 Error 28 pRand #Errs=1024A
RetestWrite @166 Error 22 pRand #Errs=1024A		RetestWrite @166 Error 29 pRand #Errs=1024A
RetestWrite @166 Error 23 pRand #Errs=1024A		RetestWrite @166 Error 30 pRand #Errs=1024A
RetestWrite @166 Error 24 pRand #Errs=1024A		RetestWrite @166 Error 31 pRand #Errs=1024A
RetestWrite @166 Error 25 pRand #Errs=1024A		RetestWrite @166 Error 32 pRand #Errs=1024A
RetestWrite @166 Error 26 pRand #Errs=1024A		RetestWrite @166 Error 33 pRand #Errs=1025A
RetestWrite @166 Error 27 pRand #Errs=1024A		RetestWrite @166 Error 34 pRand #Errs=1024A
RetestWrite @166 Error 28 pRand #Errs=1024A		RetestWrite @166 Error 35 pRand #Errs=1024A
RetestWrite @166 Error 29 pRand #Errs=1024A		RetestWrite @166 Error 36 pRand #Errs=1024A
RetestWrite @166 Error 30 pRand #Errs=1024A		RetestWrite @166 Error 37 pRand #Errs=1024A
RetestWrite @166 Error 31 pRand #Errs=1024A		RetestWrite @166 Error 38 pRand #Errs=1024A
RetestWrite @166 Error 32 pRand #Errs=1024A		RetestWrite @166 Error 39 pRand #Errs=1024A
RetestWrite @166 Error 33 pRand #Errs=1024A		RetestWrite @166 Error 40 pRand #Errs=1024A
RetestWrite @166 Error 34 pRand #Errs=1024A		RetestWrite @166 Error 41 pRand #Errs=1024A
RetestWrite @166 Error 35 pRand #Errs=1024A		RetestWrite @166 Error 42 pRand #Errs=1024A
RetestWrite @166 Error 36 pRand #Errs=1024A		RetestWrite @166 Error 43 pRand #Errs=1024
RetestWrite @166 Error 37 pRand #Errs=1024A		Test result: 176269 read errors (0.0369%)
RetestWrite @166 Error 38 pRand #Errs=1024A		Extra info: ran for 55.85 seconds at 254 MHz
RetestWrite @166 Error 39 pRand #Errs=1024A
RetestWrite @166 Error 40 pRand #Errs=1024A
RetestWrite @166 Error 41 pRand #Errs=1024A
RetestWrite @166 Error 42 pRand #Errs=1024A
RetestWrite @166 Error 43 pRand #Errs=1024
Test result: 1800249 read errors (0.0753%)
Extra info: ran for 151.29 seconds at 254 MHz

AMZN delivered the Hot Air station - fresh paste tomorrow.

PaulStoffregen · Feb 4, 2024

defragster said:
There are many factors at work that a 'Single Number' test output fail to capture

The real question is whether any of this extra detail is actually meaningful?

defragster · Feb 4, 2024

PaulStoffregen said:
The real question is whether any of this extra detail is actually meaningful?

Indeed - was it worth the effort to get toward the CAP detail you asked for?
Seemed an important question you had - without this hardware - for some reason.

Going beyond the SDRAM 166 MHz has no reason to work reliably.
Perhaps some tweaks to the SEMC Config would stretch the timing to let the SDRAM even at these speeds for improved overall throughput - like they do every time the add an Increment to the DDR3>DDR4>DDR5.

But, it does prove the 1062 MCU is capable - at least with these direct Write then Read testing cases, of giving reliable data storage with an external SDRAM at speeds beyond 166 MHz and seemingly reliable to 227 MHz with some proper CAP and even 240 with a select CAP ... on the boards at hand.

PaulStoffregen · Feb 4, 2024

defragster said:
Indeed - was it worth the effort to get toward the CAP detail you asked for?

I believe you've misunderstood what I wanted. I have wanted and still wish to see a variety / range of capacitors tested in a highly consistent way. I wanted to keep the results to a simple summary for easy comparison of many capacitors. An important aspect of comparable results is certainty all tests were performed the same way.

If you're having fun testing just a few capacitors of similar value in many of ways, and focusing a massive variety of tests at one specific capacitor combination, great. Last thing I want to do is get in the way of fun exploration. Who knows, maybe you'll discover something unexpected?

Just please don't say that is what I requested. Complex results and tests performed in many different ways on only a few capacitors covering a fairly narrow range with the code used to perform the test changing throughout the testing process is pretty much the opposite of what I wanted to see.

Call to arms | Teensy + SDRAM = true

Senior Member+

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member