defragster's latest activity

  • defragster
    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...
  • defragster
    @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...
  • defragster
    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...
  • defragster
    @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...
    • 1706925705057.png
  • defragster
    @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...
    • 1706919902128.png
    • 1706919924286.png
  • defragster
    @PaulStoffregen ran again with prec 4 to 8 digits for percentage and with 25 ReReads using 10 pF it shows: Start 57 test with 25 reads 240.00 MHz ... wait::#####e#######AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAA Test result: 4202 read errors...
  • defragster
    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} Yes...
  • defragster
    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...
  • defragster
    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...
  • defragster
    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.
  • defragster
    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...
  • defragster
    Dropping from 12 to 11 pF and it shows marginally more errors (.v.s p#279) - so seems higher is better here. Start 57 test with 5 reads 227.37 MHz ... wait::#############............................................ Test result: 0 read errors...
  • defragster
    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...
  • defragster
    :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 -...
  • defragster
    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...
  • defragster
    Just updated github with copy here. Using the current version on github there are no restarts and no calls to anything EEPROM.
  • defragster
    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...
  • defragster
    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...
  • defragster
    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
  • defragster
    Wierd was a requirement :) Yes, currently it RESTARTS: But progressing from LOWER to HIGHER MHz - Should look like posted in #720. Assumes SerMon stays online to collect and aggregate output - as above ... TyCommander does that as long as...
  • defragster
    12 pF:: Back to find DevBaord OFFLINE ?? - and TyCommander Stored SerMon TEXT file not showing much output captured from what was to be a longer run ??? No CrashReport on restarting. So restarted at 240 MHz and it ran nicely today. Just...
  • defragster
    Wow - night chores take longer than this test. 12 pF with same 5 ReReads across ALL: uint32_t speedRange[] = {133, 166, 196, 206, 216, 227, 240, 254, 270, 288}; using : #define FIRST_SPEED 0 240 MHz show the same type of glitches this time 25...
  • defragster
    Yes, See p#718. And p#716 for more details and CODE link. 12 pF soldered and started now ... p#718 shows 6.8 pF had more Errors than 10 pF. PARTIAL results coming in for 12 pf - 240 MHz BETTER with 15 ERRORS ( versus 900+ above) > and at 254...
  • defragster
    @Dogbone06 : Github code CapReadSDRAMTest.ino is current and working as expected for me! > Jumper p#16 to 3.3V and upload and look for SerMon, remove Jumper. > Test runs to completion {227, 240, 254, 270, 288} MHz, then resets and stops with...
  • defragster
    And now for something completely different to find out what CAP helps up to what SDRAM speed. Evolving the test now with a 10 pF cap installed. Very surprising so many CAPS worked to such high speeds! No Errors through 227 MHz with 10 pF...
  • defragster
    @Dogbone06 - CAPS arrived before dark! 10 pF soldered - wow size 0402 is harder to get ON than OFF so close to MCU! > Soldering it isn't square or clean - so less than ideal CAP attachment. Turned on the iron before swapping to smaller tip...
  • defragster
    defragster reacted to jmarsh's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
    Have managed to get my USB Host library to work with the micro usb port on a Teensy 4.1 - should also work with a USB-C port on the devboard but I need to be able to run multiple startup_middle_hook() functions first...
  • defragster
    Yes, I did that when you did those quick hacks to the WIP current sketch I wrote and am working with and altered it under the same name. At this early point the universe of folks working on this will be two when Mouser delivery is received here...
  • defragster
    Wrote this and neglected to post. Might be good to have it optional. In real use (not tested yet) data may survive a warm restart and that could be useful. And when in normal usage - the library only used when hardware is known to be there from...
  • defragster
    Got this on first run of download not changing the speed with No Cap So no cap at that speed and no .begin() intialize. At 206 requested this is the result: 625.73 seconds: Test capacitor effect effect on SDRAM read timing margin Clock set...
  • defragster
    No doubt - but until tomorrow - no caps here - and then we'll know what that expected range is if @Dogbone06 and I get together with testing. Europe time had me up late for his start ... then it went on forum before I got back ...
  • defragster
    Set to a testable speed and ran - the time disappeared - my last build here did too? Num ReReads not shown in any fashion. Test capacitor effect effect on SDRAM read timing margin Clock set 205.71 MHz SDRAM hardware initialized. This...
  • defragster
    Thanks for the warning - I'll set version here aside for testing.
  • defragster
    UPS says Mouser delivery: Tomorrow, Wednesday 1/31 - usually late in the day ... Back and forth at this point is counter productive - lost cycles on both ends. Board count is low and not half are worried about any CAP for the current state of...
  • defragster
    Much clearer and more specific - but premature - and costing me sleep. And as noted these are trivial changes (perhaps for a unique SDRAMmark.ino when testing leaves the ALPHA stage) - though misnamed readFixed will for now go to 0==false as: >...
  • defragster
    Building a chosen speed is undesired configuration element? It should have a fixed Speed setting for the SDRAM test? Still not following - as that would limit the use of the test at this point finding an unknown upper limit/CAP combination. At...
  • defragster
    Not following? This was a number of total reads for a one off run - not to be 'incorporated' in any other fashion? No configuration once compiled. When the sketch starts it does a 90 second test run with only 3 ReReads of all tests showing a...
  • defragster
    Over 57 tests with 3 ReReads :: Extra info: ran for 84.27 seconds {total reads 1,434,451,968} For 100 ReReads longer pass it would be about: 47,815,065,600 EXTMEM Memory Test, 32 Mbyte SDRAM speed 205.71 Mhz F_CPU_ACTUAL 600 Mhz begin@...
  • defragster
    Those 5 results at 254 MHz look pretty consistent to me! @defragster - could I talk you into doing a quick experiment? Not for the code to publish on github, just as a quick test run only once, could you add a uint64_t counter which increments...
  • defragster
    Not needed - I added extra vals over/under so i should get function at 240 MHz to prove the code.
  • defragster
    Just placed Mouser order - got 5 from your list 10pF and a couple under and over. Upgraded $8 ship to 2 day for another $2 - more than 10 each of the caps. Smallest I ordered before were .1 uF and larger footprint. $2.56 for 50 caps ... should...
    • 1706564109410.png
  • defragster
    TRUE! If that is building with the current INO from github then that is the case. Bummer not getting to see all the code and feedback as it goes to KNOW the code is right.
  • defragster
    Odd the Error Counts are in the same range - not much lower? There was clearly an issue with a per loop count transferring to the global and it was not starting at 0 for each loop repeating the read. So seeing the same number is surprising?
  • defragster
    Latest is here: https://github.com/mjs513/SDRAM_t4/tree/main/examples/CapReadSDRAM
  • defragster
    @Dogbone06 - that isn't the latest sketch copy where Error Count was made correct. Those numbers are suggestive - but they are improperly compounded so even a LOW error rate could report artificially high. 10 pF looks like a good value - for...
  • defragster
    Updated the CapReadSDRAM.ino to show after .begin(): Serial.printf("SDRAM speed %f Mhz ", sdram.getFrequency());
  • defragster
    That’s really cool! That the little 1062 can power that big screen.
  • defragster
    defragster reacted to jmarsh's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
    Added a mandelbrot sample that cycles the palette colors (still using only 4bpp/16 colors because it turns out I only have RAMDACs on hand, not direct VGA DACs...) A picture of 1920x1080 output for @Dogbone06 :
  • defragster
    Opps - Updated CapReadSDRAM.ino again : https://github.com/mjs513/SDRAM_t4/tree/main/examples/CapReadSDRAM The Error count counting was not right - blaming Github confusion since it was too dumb to be a human mistake :) On multiple ReReads the...
  • defragster
    Updated with 'Expected Output'
Back
Top