Search results

  1. defragster

    How to read/write a non filesystem USB storage drive on T4.1

    Exactly. I wanted to see it work but not trash anything, so I buffered and restored the affected data - and that worked. Indeed @Richard H doesn't have that concern wanting just raw data space. So, nice example code that works!
  2. defragster

    How to read/write a non filesystem USB storage drive on T4.1

    Yes, that is how it was before edits - once I programmed the right T_4.1 with USB Host and Flash drive connected. I just added this before to a second buffer to restore later and it did not destroy the drive - but passed the test: mscError =...
  3. defragster

    How to read/write a non filesystem USB storage drive on T4.1

    Opps - powered/programmed the wrong T4.1 on power switching Hub YES, it works on TD 1.59. Edited the code to READ/Show {all 0's) first sector to second buffer first and restore it after the test write. This left the drive filesystem usable. Odd it faulted - probably from not checking return...
  4. defragster

    How to read/write a non filesystem USB storage drive on T4.1

    Any chance this was tried with TD 1.59? Code as above keeps restarting to a CrashReport building IDE 1.8.19 with TD 1.59. hardware: T_4.1 with a USB drive on USB Host adapter plug
  5. defragster

    Teensy 3.2 with FastLED library doesn't work

    What version of TeensyDuino is in use? IIRC: Another recent poster found 1.58 to work when the new 1.59 did not on a T_3.2.
  6. defragster

    Teensy 4.1 Software Reset Code

    Good, it is very good that way - especially for multiple connected devices or Dual/Triple Serial
  7. defragster

    Teensy 4.1 Software Reset Code

    Try using TyCommander :: https://forum.pjrc.com/index.php?threads/teensy-qt.27825/
  8. defragster

    Teensyduino 1.59 Released

    Does the verbose console show any warnings? Does changing the optimization setting make a difference: Faster to Debug or other?
  9. defragster

    Teensy 4.1 Software Reset Code

    USB presents on startup. Some terminal programs don't always reconnect after it drops and returns - the IDE SerMon has shown that at times.
  10. defragster

    Call to arms | Teensy + SDRAM = true

    I made quick note somewhere on past pages with initial speed results showing longer at faster - but not seen with current test. Another thing the 'OneScanCap.ino' occasionally shows is an added 3 seconds to all times across the tests between one build and another? > like p# 871 .vs. 873 {EDIT...
  11. defragster

    Call to arms | Teensy + SDRAM = true

    Okay, Thanks. Something else then ... MCU cycling faster and leaving the SDRAM behind it seems ...
  12. defragster

    Call to arms | Teensy + SDRAM = true

    As for the problems at MCU F_CPU over 600 MHz - perhaps it is these likely these ns_to_clocks() timing based values not adjusting for enhanced F_CPU_ACTUAL clock rates so recovery times are being violated ? // configure SDRAM parameters SEMC_BR0 = 0x80000000 | SEMC_BR_MS(13 /*13 = 32...
  13. defragster

    Call to arms | Teensy + SDRAM = true

    More fun trivia? Seemed the "wfi" would wake to allow incoming USB Serial data so indeed this works: if (CrashReport) { Serial.print(CrashReport); Serial.print("Any Key to continue ..."); delay(50); while (1) { if ( Serial.available() ) break; asm ("wfi"); }...
  14. defragster

    Potential Issue with OVERCLOCK_MAX_VOLT in clockspeed.c for Teensy 4.0

    There was some amount of temp watching with OC and the start of the tempmon library in the Beta thread. 816 was marked as highest speed for OC where heatsink wasn't required. But if temps climb then heat a problem as used. Smaller T_4.0 PCB more sensitive than more mass/surface/pins of T_4.1...
  15. defragster

    Call to arms | Teensy + SDRAM = true

    Wondered what happened with an MCU OC build - went to 720 MHz - Not good ... Should the freq math calc's be adjusted?: Start 57 tests with 5 reads 132.92 MHz ... wait::##########CrashReport: A problem occurred at (system time) 18:41:47 Code was executing from address 0x2A2 CFSR: 400...
  16. defragster

    Call to arms | Teensy + SDRAM = true

    Nice, as expected no cap seems to work up to 206 MHz - based on prior runs by one or more others, and here. Odd though it should have a line for 133 MHz if the downloaded sketch LINE#1 wasn't changed from: #define FIRST_SPEED 0 And looking at the top results line - I should add F_CPU_ACTUAL...
  17. defragster

    Call to arms | Teensy + SDRAM = true

    Posted this just now: https://github.com/mjs513/SDRAM_t4/tree/main/examples/OneScanCap and running with DevBoard v 4.0 and twin 6.8 pF caps the summary is: Test results 57 tests with 5 ReReads: At 133 MHz in 157 seconds with 0 read errors At 166 MHz in 142 seconds with 0 read errors...
  18. defragster

    Call to arms | Teensy + SDRAM = true

    Interesting - that case in use here would be easy to test.
  19. defragster

    Help with Teensy Loader

    Seemed I had seen it - thanks for confirming details! And good to know the .eHex process is otherwise doable. It just might be that @rvh could make use of a custom app if a single program allowed his process to complete.
  20. defragster

    Call to arms | Teensy + SDRAM = true

    Working without cache attention seems called for and beneficial. And only reads suffer with cache not covering that region that is only used for writes? Posted twice the note from NXP reads go to ~1/4 speed without cache - writes drop 1 MB/sec from 323 to 322 by their measure. @Rezo - did you...
  21. defragster

    Help with Teensy Loader

    Okay - that makes sense. It seems that @luni (?) has made a version that can push .eHex? Someone did (??) - so that could be incorporated into TyComm if so - not sure of @Koromix having bandwidth to do that ... @KurtE has made some builds/edits to TyComm - not sure if it might be done as a pull...
  22. defragster

    Call to arms | Teensy + SDRAM = true

    If Paul suggests that, it would be worth a try to emulate the needed parts of that config function to add that new non-cache region. As I read the startup.c code for the configure_cache() it seemed like altering the cache/MPU when already set might be 'disallowed' > // TODO: check if caches...
  23. defragster

    Help with Teensy Loader

    Not sure what this means? TyCommander cannot upload .eHex - it has a Bootloader GUI button that will invoke the Teensy.exe loader program without a physical Button press? Perhaps that is what is desired? A way to have Teensy.exe when not in Auto Mode enable the 'Manual Gui' button for "Program"...
  24. defragster

    Help with Teensy Loader

    Seeing this I went to the Code4Code example done to test on Beta Locking Teensy4 with TD 1.59. Memory Usage on Teensy 4.1: FLASH: code:2959140, data:808368, headers:9000 free for files:4349956 RAM1: variables:179680, code:45864, padding:19672 free for local variables:279072 RAM2...
  25. defragster

    EHEX has EOF twice in the file - Confuses FlasherX

    Confirmed. Even with Verify the Teensy.exe grabs/reuses .eHex part #2 when it is missing. But Close and Open Teensy.exe and point to an .eHex with No part #2 and: Still interesting that .eHex part #2 is marginally unique - but any .eHex part #2 seems to work for any sketch that requires it.
  26. defragster

    EHEX has EOF twice in the file - Confuses FlasherX

    I scanned that partially once following the link - it has expanded since I last looked at it. So, without regard to much of that ... I've built 3 sketches that upload to a LOCKED T_4.1. :: 02:51:42.798 (loader): using encrypted ehex (required - secure mode is locked) > simple 'Hello" to USB >...
  27. defragster

    Teensy interfacing with ADAFRUIT I2S MEMS MICROPHONE BREAKOUT - SPH0645LM 4H

    Perhaps this later in that same thread: https://forum.pjrc.com/index.php?threads/teensyduino-1-52-beta-3.60599/post-238070
  28. defragster

    Call to arms | Teensy + SDRAM = true

    Prior work to assure alignment just over allocated by the alignment bytes needed then set the usable address masked upwards to that alignment boundary - perhaps that is what you did? This 32 byte example from ...\arduino-1.8.19\hardware\teensy\avr\libraries\ILI9488_t3\src\ILI9488_t3.cpp if...
  29. defragster

    The power consumption of Teensy's processor?

    Opps - My bad - the blink is 1 millisecond not a whole second - of course it is not a visible blink. I was taking a quick run with the code and wrongly expecting to see a 1 sec blink like this: void setup() { pinMode(13, OUTPUT); CCM_CLPCR &= ~CCM_CLPCR_ARM_CLK_DIS_ON_LPM; // Interrupt on...
  30. defragster

    The power consumption of Teensy's processor?

    Running this code on T_4.1 or T_4.0 or T_MM not seeing any LED blink? IDE 2.3 with TD 1.59.0 on Win 11
  31. defragster

    Teensyduino 1.59 Released

    Updated IDE 2.3 JSON as posted, it was downloaded by IDE Board manager showed 1.59 to update when Teensy was searched. Clicked update and Install completed: It seems to have closed Teensy.exe and nothing else open conflicting prevented instalation. Downloaded TeensyDuino EXE for IDE 1.8.19 and...
  32. defragster

    Teensyduino 1.59 Beta #6

    Put a T_3.5 on IDE 2.3 here and it was recognized and uploaded okay - w/tycomm But that WINDOW won't MOVE with title bar? Has NO Title bar - only menu bar on top. IDE is odd? Got that restart dialog again - it only restarted one sketch window and it won't move with title bar (only menu bar...
  33. defragster

    Teensyduino 1.59 Beta #6

    IDE 2.3.0 installed fine and worked for DevBoard build. Seems a good idea with a couple forum installs showing no new issues. Opened 2.1 and got some weird 'something changed restart' - did that twice and close and then the offer for 2.3 stayed and did download and install no problem. Opened...
  34. defragster

    Teensy 4.1 psram memtest

    Yes, that worked on the SDRAM - though had to change clock setting only - resending the IP commands to the SDRAM causes it to lose prior data. That may not apply to the PSRAM as it persists across warm restarts where the full init is already repeated using same SPI setup.
  35. defragster

    Teensy 4.1 psram memtest

    That 'fail on write' is actually what I was looking at last on the SDRAM test evolution across speed changes. The PSRAM spec notes a condition where less than the 133 MHz full speed is supported.
  36. defragster

    Teensy 4.1 psram memtest

    Would be interesting if the method of clock speed change details were included and any test sketch that showed the FAIL issue. The speed is limited for a reason since it hasn't been proven/tested good above the current default speed where that PJRC test was meant to run. Some similar testing...
  37. defragster

    Teensyduino version number available in code?

    Libs installed with the IDE by TeensyDuino or the Boards Manager will be updated.
  38. defragster

    Teensyduino version number available in code?

    Looking at verbose console output this shows for major release build number:
  39. defragster

    Teensyduino 1.59 Beta #6

    Works here: Installed on IDE 2 and Unzipped to IDE 1.8.19 and current sketch built and uploaded for both. Noted above - this is using a new URL: https://www.pjrc.com/teensy/package_teensy_159b6_index.json
  40. defragster

    Call to arms | Teensy + SDRAM = true

    ... no words ...
  41. defragster

    Call to arms | Teensy + SDRAM = true

    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...
  42. defragster

    Call to arms | Teensy + SDRAM = true

    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...
  43. defragster

    Call to arms | Teensy + SDRAM = true

    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...
  44. defragster

    Call to arms | Teensy + SDRAM = true

    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.
  45. defragster

    Call to arms | Teensy + SDRAM = true

    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...
  46. defragster

    Call to arms | Teensy + SDRAM = true

    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...
  47. defragster

    Call to arms | Teensy + SDRAM = true

    @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...
  48. defragster

    Call to arms | Teensy + SDRAM = true

    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. Start 57 test with 25 reads 240.00 MHz ...
  49. defragster

    Call to arms | Teensy + SDRAM = true

    @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: Start 57 test...
  50. defragster

    Call to arms | Teensy + SDRAM = true

    @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...
Back
Top