Call to arms | Teensy + SDRAM = true

Using 'this image' giving what should be 5pF at 221 MHz
1703966591222.png

two green WW 30ga on PCB pads. 1st soldered to leg of 22pF that has WW30 shorted across to first 10pF passing through 2nd 10pF where 2nd ww30 hits 2nd pad

And just running PRand seeds 0-5 this shows:
Code: 
  --- START ------

    >>**>> PseudoRand(0) Seed 2976674124 with readRepeat 10  ...
PseudoRand seq. written does not match: Errors Cnt: L=1 H=0 < INSTANT FAIL (2)

    >>**>> PseudoRand(1) Seed 1438200953 with readRepeat 10  ...
PseudoRand seq. written does not compare: Errors Cnt 1 < INSTANT FAIL (1)
PseudoRand seq. written does not match: Errors Cnt: L=0 H=1 < INSTANT FAIL (2)

    >>**>> PseudoRand(2) Seed 3413783263 with readRepeat 10  ...
PseudoRand seq. written does not match: Errors Cnt: L=1 H=0 < EXIT FAIL
Fail pseudo-random sequence not same in both HalfCmp with seed=3413783263
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 1

    >>**>> PseudoRand(3) Seed 1900517911 with readRepeat 10  ...
PseudoRand seq. written does not compare: Errors Cnt 1 < INSTANT FAIL (1)
PseudoRand seq. written does not match: Errors Cnt: L=2 H=0 < INSTANT FAIL (2)

    >>**>> PseudoRand(4) Seed 1227909400 with readRepeat 10  ...
Fail pseudo-random sequence not same in both HalfCmp with seed=1227909400
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 51
Same 4M PRand written to Low and High 16 MB.
> INSTANT FAIL (1) is when they do not read back compare Low to High
> INSTANT FAIL (2) is when PRand math done and checked against Low and High halves and one or the other fails
> EXIT FAIL is same PRand math done and checked against Low and High halves and fails after series of repeat read back compares


Opps the second wire wasn't wrapped tight - adjusted and still on the edge? - but two runs complete like this:
Code: 
  --- START ------
<edit>
Same test run at 198 MHz shows the speed change for the test from above running at 221 MHz.  That is 17% faster!
[QUOTE]
    >>**>> PseudoRand(3) Seed 1900517911 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 4.62 with Error Cnt 0
[/QUOTE]

    >>**>> PseudoRand(0) Seed 2976674124 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 5

    >>**>> PseudoRand(1) Seed 1438200953 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 0

    >>**>> PseudoRand(2) Seed 3413783263 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 0

    >>**>> PseudoRand(3) Seed 1900517911 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 0

    >>**>> PseudoRand(4) Seed 1227909400 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 0

Total errors found 5
  --- START ------

    >>**>> PseudoRand(0) Seed 2976674124 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 0

    >>**>> PseudoRand(1) Seed 1438200953 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 0

    >>**>> PseudoRand(2) Seed 3413783263 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 0

    >>**>> PseudoRand(3) Seed 1900517911 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 0

    >>**>> PseudoRand(4) Seed 1227909400 with readRepeat 10  ...
Same pseudo-random sequence in both HalfCmp Compare time secs 3.95 with Error Cnt 0

Total errors found 0
 
Last edited:
Again I'd like to ask for features like "INSTANT FAIL (1)" to be disabled on tests meant to compare C29 capacitors.

The test should always run exactly the same set of writes and reads, counting the total number of reads giving wrong data. Hopefully it's easy to understand how a "standard" benchmark which always performs exactly the same test is essential for comparing the results of tests to each other. A huge number printed at the end (directly comparable to the single number from all other tests) is actually much more useful to understand a bad C29 choice, rather than having to read through a lot of text.

Consistency is key. Please create a test program without a lot of (or any) configuration options. Then as more people run it, if everyone has used the same benchmark and all copies did the same test, we can compare the results.

As a practical human limitation, the test result needs to be just a single number. Nuance might be nice for other times, but when comparing boards tested by 3 or more different people, each trying several different C29 capacitors, a simple single number result is key.
 
@PaulStoffregen
Starting looking a bit at I2C/MPU setting issue and something strange that might be a clue.

I was working with Scanner (wire example) and when I ran it with SDRAM enabled (my term since I have the define) I decided to decided to add in crashreport to see what happened:
Code: 
  Wire.begin();
  Serial.begin(9600);
  while (!Serial);        // Leonardo: wait for serial monitor
  if (CrashReport) {
   Serial.print(CrashReport);
  }
  Serial.println(F("\nI2C Scanner"));

To my surprise it work to loosing hang:
Code: 
Scanning...
No I2C devices found
Scanning...
No I2C devices found
Scanning...
No I2C devices found...

if I remove it I get the hang!!!!!!!!!!!!!!!

EDIT: the graphicstest sketch also works when I include the crashreport.
 
Looking at the SDK SEMC Example configuration for the MPU (with my notes):

Code: 
/**
* MPU Region Attribute and Size Register Value
*
* \param DisableExec       Instruction access disable bit, 1= disable instruction fetches.
* \param AccessPermission  Data access permissions, allows you to configure read/write access for User and Privileged mode.
* \param TypeExtField      Type extension field, allows you to configure memory access type, for example strongly ordered, peripheral.
* \param IsShareable       Region is shareable between multiple bus masters.
* \param IsCacheable       Region is cacheable, i.e. its value may be kept in cache.
* \param IsBufferable      Region is bufferable, i.e. using write-back caching. Cacheable but non-bufferable regions use write-through policy.
* \param SubRegionDisable  Sub-region disable field.
* \param Size              Region size of the region to be configured, for example 4K, 8K.
*/       


/* The define sets the cacheable memory to shareable,
 * this suggestion is referred from chapter 2.2.1 Memory regions,
 * types and attributes in Cortex-M7 Devices, Generic User Guide */
#if defined(SDRAM_IS_SHAREABLE)
    /* Region 8 setting: Memory with Normal type, not shareable, outer/inner write back */
    MPU->RBAR = ARM_MPU_RBAR(8, 0x80000000U);
    MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 1, 1, 1, 0, ARM_MPU_REGION_SIZE_32MB);
    
    DisableExec             0
    AccessPermission        ARM_MPU_AP_FULL
    TypeExtField            0
    IsShareable             1
    IsCacheable             1
    IsBufferable            1
    SubRegionDisable        0
    Size                    ARM_MPU_REGION_SIZE_32MB
    
#else
    /* Region 8 setting: Memory with Normal type, not shareable, outer/inner write back */
    MPU->RBAR = ARM_MPU_RBAR(8, 0x80000000U);
    MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_32MB);
    
    
    DisableExec             0
    AccessPermission        ARM_MPU_AP_FULL
    TypeExtField            0
    IsShareable             0
    IsCacheable             1
    IsBufferable            1
    SubRegionDisable        0
    Size                    ARM_MPU_REGION_SIZE_32MB
    
#endif
But the interesting thing is that they reserve 2mb of the SDRAM:

Code: 
    /* Region 9 setting, set last 2MB of SDRAM can't be accessed by cache, glocal variables which are not expected to be
     * accessed by cache can be put here */
    /* Memory with Normal type, not shareable, non-cacheable */
    MPU->RBAR = ARM_MPU_RBAR(9, 0x81E00000U);
    MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, ARM_MPU_REGION_SIZE_2MB);

wonder if this is why - would like to try it but not sure what RASR settings to use.
 
They probably just wanted a non-cacheable region. Since the Cortex-M7 doesn't have any direct load/store instructions it can be awkward to atomically update anything less than 32 bytes (an entire cache line) of cached memory.
 
@Paul RE:p#202 With Dual Serial the main can do something minimal like this in main Serial:
--- START ------
IIIII
Total errors found 3962
--- START ------
IIIII
Total errors found 6729
Click to expand...
Right now testing is in flux ...
 
mjs513 said:
Looking at the SDK SEMC Example configuration for the MPU (with my notes):
...
But the interesting thing is that they reserve 2mb of the SDRAM:

Code: 
    /* Region 9 setting, set last 2MB of SDRAM can't be accessed by cache, glocal variables which are not expected to be
     * accessed by cache can be put here */
    /* Memory with Normal type, not shareable, non-cacheable */
    MPU->RBAR = ARM_MPU_RBAR(9, 0x81E00000U);
    MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, ARM_MPU_REGION_SIZE_2MB);

wonder if this is why - would like to try it but not sure what RASR settings to use.
Click to expand...

That puzzled me looking at their example as well ... why 30MB and then 2MB ...
 
Here's USB output from an hour of 3 20 minute runs - 44 SEED tests only 50 re-reads each:
--- START ------ with 50 reReads ... wait ...
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Total errors found 19059476
--- START ------ with 50 reReads ... wait ...
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Total errors found 286004
--- START ------ with 50 reReads ... wait ...
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Total errors found 8276
Click to expand...
Here's a quick parse of the USB1 data where only the first 23 seconds is needed for crude correction:
1st 221 no cap - opps
2nd 221 MHz - two 10 pF in series
3rd 221 MHz - three 10 pF in series :: The resulting capacitance is: 3.333 pF
Summary data is 44*8M*50 data reads
--- START ------ with 50 reReads ... wait ...

>>**>> PseudoRand(0) Seed 2976674124 with readRepeat 50 ...
Fail pseuRand seq. not same with seed=2976674124
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 435972
...
>>**>> PseudoRand(43) Seed 1100533073 with readRepeat 50 ...
Fail pseuRand seq. not same with seed=1100533073
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 375884
--- START ------ with 50 reReads ... wait ...

>>**>> PseudoRand(0) Seed 2976674124 with readRepeat 50 ...
Fail pseuRand seq. not same with seed=2976674124
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 6444
...
>>**>> PseudoRand(43) Seed 1100533073 with readRepeat 50 ...
Fail pseuRand seq. not same with seed=1100533073
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 4823
--- START ------ with 50 reReads ... wait ...

>>**>> PseudoRand(0) Seed 2976674124 with readRepeat 50 ...
Fail pseuRand seq. not same with seed=2976674124
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 175
...
>>**>> PseudoRand(43) Seed 1100533073 with readRepeat 50 ...
Fail pseuRand seq. not same with seed=1100533073
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 38
Click to expand...
The goal of 'UI' was to while assuring a repeatable setpoint (no user sketch edit) - facilitate initial test at lower test counts. If the first test gives large number of errors then waiting for 43 more tests will add nothing but time. Even this '50 repeat test' is far from the 50-1000 iteration re-read suggested. Once 50 looks good then committing 6+ hours for a run makes sense. Rebuilding to alter the test is riskier than self documenting UI - that can be hidden in USB1.
 
@Dogbone06 - Something to aim to in your more controlled testing:
--- START ------ with 50 reReads ... wait ...
...........................F................
Total errors found 49
Click to expand...

Seem to have found a winning Series combo for a start point:
1704006186263.png

Two 10's soldered then a 10 and 22 with WW30ga on the legs twisted together.
To answer my question 'sloppy CAP connections' seem to be functional/suggestive.
I'll hit wrapped joints with solder and repeat ...
And from USB1 where all other 42 tests give zero errors:
>>**>> PseudoRand(27) Seed 2125248865 with readRepeat 50 ...
Fail pseuRand seq. not same with seed=2125248865
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 49
Click to expand...
And after soldering the wrapped joints:
--- START ------ with 50 reReads ... wait ...
........F..F.F.......F..FF.F.....FF......F..
Total errors found 207
Click to expand...
And USB shows the only one to fail before with 49 now failed with only 1:
Fail pseuRand seq. not same with seed=110497896
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 24
Fail pseuRand seq. not same with seed=2280382233
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 37
Fail pseuRand seq. not same with seed=3978544245
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 25
Fail pseuRand seq. not same with seed=2169216599
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 11
Fail pseuRand seq. not same with seed=2959727213
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 13
Fail pseuRand seq. not same with seed=4219363395
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 15
Fail pseuRand seq. not same with seed=2125248865
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 1
Fail pseuRand seq. not same with seed=381313790
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 19
Fail pseuRand seq. not same with seed=4174769276
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 36
Fail pseuRand seq. not same with seed=85016565
Test pseudo-random sequence Compare time secs 23.73 with Error Cnt 26
Click to expand...
Rebuilt for 100 reReads - ... so far ...
--- START ------ with 100 reReads ... wait ...
FFFFF.FFFF.FFFFF.FFFFFF.FF.FFFFFFFFF..FFFFF.
Total errors found 4031
Click to expand...

So subtle differences (soldering wrapped mess) changed the effective CAP value.
And run to run not definitive or telling as to what fails where - even with same reRead count.
The current testing is back to writing ALL 32MB with Pseudo Rand values and calc and compare on each reRead.
Need to add in the FIXED value patterns as they are telling as well.
 
Last edited:
So there should be more than one cap? Why not just go for single caps with the correct value? I’m confused.

Also, I feel like the I2C and SPI issue needs fixing before we optimize speed right?
 
Dogbone06 said:
So there should be more than one cap? Why not just go for single caps with the correct value? I’m confused.

Also, I feel like the I2C and SPI issue needs fixing before we optimize speed right?
Click to expand...
Indeed, if the i2c/SPI issues are really there - that needs to be resolved.

It seems lucky that 221 MHz on a 133 MHz part is anywhere near working - and seems to be a secondary issue when 198 MHz works easily here and is already 48% overclocked. Starting prior 100 reRead test on 198 MHz (with CAP string in place) - results in the virtual tomorrow - given it is after 12AM already here.
--- START ------ with 100 reReads ... wait ...
............................................
No Errors. All memory tests passed :)
Click to expand...

Single caps don't seem to cover that range - so stacking seems to be involved if one of the standards alone doesn't work { 2.7pF or 3.0pF +/-}- if this WEB info matches suppliers:

Standard Capacitor Values Conversion Chart pF - nF - µF

www.petervis.com

Standard Capacitor Values Conversion Chart pF - nF - µF​

1704011499898.png
1704012044842.png

From Verbose USB1 output: 100 reReads at 198 MHz takes secs 48.99 versus at 221 MHz secs 47.22 and at 166 MHz secs 52.03.
And @Dogbone06 - the point being that a cap in that range ( or NO_CAP ) seems to leave 198 MHz and below functioning fine.
 
Last edited:
I will try actual 0402 capacitors in the range Paul posted earlier: 4.7pF, 10pF, 15pF
To start with atleast.

@Paul Can you give me ALL values you think should be tried? I don't wanna have to order caps twice. I will place one order from Mouser/Digikey with all values we could possibally need. Also, please tell me what brand you think is the best and I will order from only that/those brands.
 
Dogbone06 said:
I will try actual 0402 capacitors in the range Paul posted earlier: 4.7pF, 10pF, 15pF
To start with atleast.

@Paul Can you give me ALL values you think should be tried? I don't wanna have to order caps twice. I will place one order from Mouser/Digikey with all values we could possibally need. Also, please tell me what brand you think is the best and I will order from only that/those brands.
Click to expand...
based on crude experimentation here noted in prior posts - aim for 2.895 pF look for perhaps two steps below and three above in that range with standard parts as available. All the flying wires shown probably add some measurable amount above calculated.
Perhaps an 'EE'ducated guess from the photo might suggest what that is doing to the 'calculated value' - given the nature of the caps used from a SparkFun bulk kit as it will related to a single SMD part as supplied. Stacking SMD for parallel (should be cleaner than series as done here) a 1.3 and 1.5 would hit 2.8 and a 1.3 and 1.6 a 2.9. 3.0 is available and 1.5 and 1.6 would stack to a 3.1 ...
 
When searching I can't seem to find any cap with such exact value. Guess I'll have to stack them. This is new to me and a little challgenging.
If one of you guys can just give me a list of values to buy of the shelf, I'll buy all of them so I can then experiement.

Mouser or LCSC.com is prefered for me.
 
@Dogbone06 - is your 402 INCH or MM? (note update p#211 above re added cap)

And does DC voltage matter (only if too low) - for 10V at Mouser those common values noted seem to appear (more than 6.3V) if 402 is an Inch part.
 
It's really hard to follow some of the comments in this thread so is it possible to get a simple yes/no answer to this question:
Does I2C/SPI still hang when the SDRAM MPU entry is active and the board actually has SDRAM present and initialized?

If the MPU entry is only causing problems for boards that don't have SDRAM, I would imagine there's some code being speculatively executed that is accessing the SDRAM region. When the SDRAM memory isn't mapped by the MPU, that access will be skipped (due to hitting entry 0) but when the entry is defined, it will trigger a bus transfer to memory that isn't present. The nature of speculative access may explain why checking for a crash report avoids the problem.
 
Dogbone06 said:
@Paul Can you give me ALL values you think should be tried? I don't wanna have to order caps twice. I will place one order from Mouser/Digikey with all values we could possibally need. Also, please tell me what brand you think is the best and I will order from only that/those brands.
Click to expand...
Dogbone06 said:
Mouser or LCSC.com is prefered for me.
Click to expand...

Here's a shopping list with Mouser part numbers:

Code: 
1.0 pF  81-GRM1555C1H1R0WA1D
1.5 pF  81-GRM1555C1H1R5WA1D
2.2 pF  81-GJM1555C1H2R2GB1D
2.7 pF  81-GJM1555C1H2R7GB1D
3.3 pF  81-GJM1555C1H3R3WB1D
3.9 pF  81-GJM1555C1H3R9GB1D
4.3 pF  81-GJM1555C1H4R3GB1D
4.7 pF  81-GJM1555C1H4R7GB1D
5.6 pF  81-GJM1555C1H5R6FB1D
6.8 pF  81-GJM1555C1H6R8FB1D
7.5 pF  81-GJM1555C1H7R5WB1D
8.2 pF  81-GJM1555C1H8R2FB1D
9.1 pF  81-GJM1555C1H9R1FB1D
10 pF   81-GRM1555C1H100FA1D
11 pF   81-GCM1555C1H110FA6D
12 pF   81-GRM1555C1H120GA1D
13 pF   81-GRT1555C1H130FA2D
15 pF   81-GRM1555C1H150GA1D
18 pF   81-GRM1555C1H180GA1D
22 pF   81-GRM1555C1E220GA1D

Edit: this is more an answer to "all values we could possibally need" than "ALL values you think should be tried". A realistic strategy would test just a few at first, then do a second round with others from a smaller range based on results of the first round. But if you want to pay for shipping just once, this list should cover the anticipated range. The parts are inexpensive, each under $1 for 10 and for most only a few dollars to get 100.
 
Last edited:
@jmarsh
The MPU entry is causing problems for any board without SDRAM (just hangs it someplace - assuming hang since nothing appears in SerMon) and the TMM with SDRAM installed and initialized I2C-SPI so far does not work (does the same thing as non-sdram boards - hangs it).

Now with all that said if I add one statement after Serial.begin();
Code: 
if(CrashReport) {}

Everything works even on non-SDRAM boards like the T4.1. Just finished verifing it.
 
jmarsh said:
so is it possible to get a simple yes/no answer to this question:
Click to expand...

It's pretty unrealistic to expect definitive answers this early. Defragster received the first hardware only 8 days ago, and Mike got his just (or maybe the package still in transit?) I do not have the hardware, and I don't plan to even ask for it unless this is still needing serious work in February-March time frame. I discovered this Wire library crash only 2 days ago.

Rght now, while pretty much everything is new and still in flux, the simple answer is MPU config for SDRAM used on Teensy 4.1 without any SDRAM chip causes the Wire library to crash. So far, nobody knows why. I'm pretty sure none of us even have a clear idea of the full scope of which hardware and software combinations trigger the problem. That's the nature of new unknown problems, a simple answer just isn't possible until the problem is better understood.
 
Last edited:
Using that kludge to get SPI working, i.e., putting CrashReport after Serial.begin (Again - no idea why it works but it does ran a test on using a framebuffer for display graphics data on a ILI9341.

Method: Using @KurtE's ILI9341_t3n library and running the graphicstest sketch which has too comparisons on for using a framebuffer (filled rectangles and rounded rectangles:
Code: 
ILI9341 Test!
After TFT Begin
15
Display Power Mode: 0x0
MADCTL Mode: 0x0
Pixel Format: 0x0
Image Format: 0x0
Self Diagnostic: 0x0
Benchmark                Time (microseconds)
Screen fill              205288
Text                     9266
Lines                    70127
Horiz/Vert Lines         17469
Rectangles (outline)     11198
Rectangles (filled)      421571
Circles (filled)         67289
Circles (outline)        48066
Triangles (outline)      16550
Triangles (filled)       146115
Rounded rects (outline)  24663
Rounded rects (filled)   467529
Hit key to continue
Done!
Rectangles (filled) FB     45310
Hit key to continue
Done!
Rounded rects (filled) FB   47392
Hit key to continue
Done!

EXTMEM  (Teensy 4.1 with 8mb PSRAM.
Rectangles (filled) FB     111649
Hit key to continue
Done!
Rounded rects (filled) FB   112164
Hit key to continue
Done!


DMAMEM
Rectangles (filled) FB     45519
Hit key to continue
Done!
Rounded rects (filled) FB   47559
Hit key to continue

Rectangles (filled) FB     52483
Hit key to continue
Done!
Rounded rects (filled) FB   57302
Hit key to continue


SDRAM
Rectangles (filled) FB     52094
Hit key to continue
Done!
Rounded rects (filled) FB   55768
Hit key to continue

Looks like its as fast as using DMAMEM - note running at 133Mhz
 
Last edited:
PaulStoffregen said:
Here's a shopping list with Mouser part numbers:

Code: 
1.0 pF  81-GRM1555C1H1R0WA1D
1.5 pF  81-GRM1555C1H1R5WA1D
2.2 pF  81-GJM1555C1H2R2GB1D
2.7 pF  81-GJM1555C1H2R7GB1D
3.3 pF  81-GJM1555C1H3R3WB1D
3.9 pF  81-GJM1555C1H3R9GB1D
4.3 pF  81-GJM1555C1H4R3GB1D
4.7 pF  81-GJM1555C1H4R7GB1D
5.6 pF  81-GJM1555C1H5R6FB1D
6.8 pF  81-GJM1555C1H6R8FB1D
7.5 pF  81-GJM1555C1H7R5WB1D
8.2 pF  81-GJM1555C1H8R2FB1D
9.1 pF  81-GJM1555C1H9R1FB1D
10 pF   81-GRM1555C1H100FA1D
11 pF   81-GCM1555C1H110FA6D
12 pF   81-GRM1555C1H120GA1D
13 pF   81-GRT1555C1H130FA2D
15 pF   81-GRM1555C1H150GA1D
18 pF   81-GRM1555C1H180GA1D
22 pF   81-GRM1555C1E220GA1D

Edit: this is more an answer to "all values we could possibally need" than "ALL values you think should be tried". A realistic strategy would test just a few at first, then do a second round with others from a smaller range based on results of the first round. But if you want to pay for shipping just once, this list should cover the anticipated range. The parts are inexpensive, each under $1 for 10 and for most only a few dollars to get 100.
Click to expand...
I fully understand. You gave me just what I wanted, a complete list so that I don’t have to order several times.

I’ll order all of these, thanks!

@mjs513, it’s even faster then DMAMEM, that’s amazing!!
 
PaulStoffregen said:
Rght now, while pretty much everything is new and still in flux, the simple answer is MPU config for SDRAM used on Teensy 4.1 without any SDRAM chip causes the Wire library to crash. So far, nobody knows why. I'm pretty sure none of us even have a clear idea of the full scope of which hardware and software combinations trigger the problem. That's the nature of new unknown problems, a simple answer just isn't possible until the problem is better understood.
Click to expand...

I just ran the Wire Scanner sketch again with the following MPU configuration for the sdram region:
Code: 
    SCB_MPU_RBAR = 0x80000000 | REGION(i++); // SEMC: SDRAM, NAND, SRAM, etc
    SCB_MPU_RASR = MEM_CACHE_WBWA | READWRITE | NOEXEC | SIZE_1G;
    // SDRAM PCB: https://forum.pjrc.com/index.php?threads/73898/#post-334041
    SCB_MPU_RBAR = 0x81E00000 | REGION(i++); // SEMC: SDRAM, NAND, SRAM, etc
    SCB_MPU_RASR = MEM_NOCACHE | READWRITE | NOEXEC | SIZE_2M;

Tried to make it match whats in the EVKB config and with that 2MB reserved space as shown in msg #204 seems to get SPI and I2C working without crashing. Tested on a T4.1 with SDRAM disabled and on the dev board with it enabled. For SPI I ran the graphics test sketch.

Why - no idea - first foray into reading DD0403E
 
You must log in or register to reply here.
Back
Top