Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 3 1 2 3 LastLast
Results 1 to 25 of 61

Thread: Teensyduino 1.55 Beta #3

  1. #1
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    415

    Teensyduino 1.55 Beta #3

    Here is a third beta test for Teensyduino 1.55.


    Linux 32 bit:
    https://www.pjrc.com/teensy/td_155-b...nstall.linux32

    Linux 64 bit:
    https://www.pjrc.com/teensy/td_155-b...nstall.linux64

    Linux ARM:
    https://www.pjrc.com/teensy/td_155-b...stall.linuxarm

    Linux ARM64:
    https://www.pjrc.com/teensy/td_155-b...l.linuxaarch64

    MacOS 10.10 to 11.x:
    https://www.pjrc.com/teensy/td_155-b...S_Catalina.zip

    MacOS 10.8 to 10.14:
    https://www.pjrc.com/teensy/td_155-b...inoInstall.dmg

    Windows:
    https://www.pjrc.com/teensy/td_155-b...inoInstall.exe


    Changes since Teensyduino 1.55-beta2:

    SdFat use MAINTAIN_FREE_CLUSTER_COUNT on 32 bit Teensy
    Do not build .lst file - very slow for large code
    Sketch > Export Compiled Binary now saves .ehex, if possible
    Consistent startup sequence on Teensy 3 & 4
    Add startup_default_middle_hook()
    Fix Serial.begin() delay with serial emulation and Teensy 3
    String compatibility with Arduino for C++ iterators
    Fix DMAChannel triggerContinuously() on Teensy 4 (Kurt E)
    Fix CCM_ANALOG_PLL_ENET define (Shawn Silverman)
    Improve arm_dcache_delete() documentation
    Rename LittleFS example folders
    LittleFS_RAM always starts blank
    Update ST7735_t3
    Update TeensyThreads
    Fix Teensy Loader GUI stalls with locked Teensy 4
    Show .ehex filename in status bar when automatically using .ehex
    Clearer messages about hex vs ehex in Verbose Info
    Only show percentage flash used after connecting to real hardware
    Avoid fusewrite fuse memory corruption if different key used
    Improve error messages in fusewrite sketch

  2. #2
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,551
    Something different - went to install TD but gave me an error that it could upload to the folder. Checked in Task Manager and had 2 copies of Teensy_reboot.exe still running. Once closed it installed without an issue.

    Sketch > Export Compiled Binary now saves .ehex, if possible
    Verified that an .ehex and .hex are both save to the sketch directory.

    Do not build .lst file - very slow for large code
    verified that the .lst file is not created using Tim's code4code sketch but took about 1:47 seconds to go from upload arrow to when TeensySize prints. Not sure anyway around this for that large of a program.

    Show .ehex filename in status bar when automatically using .ehex
    Very nice and thank you.
    Name:  Capture.PNG
Views: 292
Size:  49.6 KB

    Improve error messages in fusewrite sketch
    Not sure how much clearer that can be
    Code:
    17:58:31.485 (loader): File "Code4Code.ino.hex". 1337344 bytes, 66% used
    17:58:31.485 (loader): File "Code4Code.ino.hex" opened, but "Code4Code.ino.ehex" will actually be used
    17:58:31.532 (loader): elf appears to be for Teensy 4.0 (IMXRT1062) (2031616 bytes)
    17:58:31.532 (loader): elf binary data matches hex file
    17:58:31.532 (loader): elf file is for Teensy 4.0 (IMXRT1062)
    17:58:31.532 (loader): using encrypted ehex (required - secure mode is locked)
    Ok next up is the fusewrite with wrong key and see what happens.

    UPDATE:
    Avoid fusewrite fuse memory corruption if different key used
    Like the message that TL shows that ehex can not be written because wrong key and nothing uploads and sketch already on T4 continues to run.

    Also checked if the correct key is used with fuse write - nice output to let you know it was already written don't remember if that was there before:
    Code:
    ....
    Decryption key was previously written & locked, so
    it can not be directly verified, but the following
    test will confirm whether decryption works.
    
    Bus Encryption Engine is active (this program is encrypted)
      Encryption is assumed to be working if this program runs.

  3. #3
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,081
    Installed okay, no complaints - except I left IDE open even after it told me teensy_ports was open.
    > Backed up both times and completed as desired

    Rebuilt C4CbenchM @4,000 func#()'s WIP okay. Faster without .lst!

    Upload to Locked_Beta and Prod boards worked - but something funny happened - may have triggered second before first was complete?
    > Got bumped from 'AUTO' for fast reboot?

    four _isr rates give this for T4_Locked - not shown yet the 4 rates 24, 48, 96, 192 us update rates on the IntervalTimer:
    Code:
    PERF _isr() char[] Test % Diff versus production T4:
    	_isr() char[] Test @24 us % Diff of 0.997
    	_isr() char[] Test @48 us % Diff of 0.965
    	_isr() char[] Test @96 us % Diff of 0.945
    	_isr() char[] Test @192 us % Diff of 0.918
    Refining the 'net' diffs from the Cascade versus Direct calls like in Excel.
    Last edited by defragster; 09-13-2021 at 12:12 AM.

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,081
    Just triggered the mystery 'erasing' sequence from TeensyLoader hitting 'TyComm USB Reset' : after Button Upload
    > It doesn't program because TyComm is monitoring for Serial connect and it does?

    Here is full Verbose since Beta 3 loaded ...
    Attached Verbose : B3_log.zip

    Needed to be ZIPped because 296 KB is bigger than limit 195.3

    Long time idle so a big break in time stamps to find the events:
    17:11:46.113 (loader): redraw, image 9
    19:07:11.023 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    Here is a shorter Log.txt: B3_log2.txt
    > Verify Build
    > TyComm 'Bootloader' on production
    -> Proper upload
    > TyComm 'Reset' on Locked Beta T4
    -> FALSE upload - valid Reset
    > TyComm 'Bootloader' on Locked Beta T4
    -> Proper upload

    NOTE: Works the same doing UPLOAD to EACH of the above, then hitting Reset on the first
    > Verify Build
    > TyComm 'Bootloader' on Locked Beta T4
    -> Proper upload
    > TyComm 'Bootloader' on production
    -> Proper upload
    > TyComm 'Reset' on production
    -> FALSE upload - valid Reset
    Last edited by defragster; 09-13-2021 at 04:05 AM.

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,081
    Just triggered the DUAL LEDS RED & ORANGE:

    > Did a new Verify
    > on Production accidental with TyComm Reset not Bootloader
    > Changed to Beta_T4 : Did TyComm Bootloader
    -->> Looked down and saw DUAL LEDS
    - > last Verify code was NOT uploaded

    Here are Four T_4's running the same variation of Code4Code > C4CbenchM.ino::
    >> Both UPDATED : https://github.com/Defragster/T4LockBeta { c4cbenchM has non printing version of isEncrypt( bool ) for ID string create }

    Code:
    10379960 nor ns: @600 PERF _isr() char[] Test % Diff versus production T4:
    	_isr() char[] Test @24 us % Diff of 1.000
    	_isr() char[] Test @48 us % Diff of 1.000
    	_isr() char[] Test @96 us % Diff of 1.001
    	_isr() char[] Test @192 us % Diff of 1.000
    
    10379960 nor ns: @600 PERF Cascade .vs. Direct Func#()'s Test :
    	 Test Diff of 14.019
    	% Diff to Production of 0.999
    
    10379960 nor ns: @600 PERF with ISR Cascade .vs. Direct Func#()'s Test :
    	 Test Diff of 18.934  {this is most nebulous}
    	% Diff to Production of 0.951
    Hint: this is the locked T4_Beta
    Code:
    10379970 ENC SM: @600 PERF _isr() char[] Test % Diff versus production T4:
    	_isr() char[] Test @24 us % Diff of 0.996
    	_isr() char[] Test @48 us % Diff of 0.969
    	_isr() char[] Test @96 us % Diff of 0.950
    	_isr() char[] Test @192 us % Diff of 0.892
    
    10379970 ENC SM: @600 PERF Cascade .vs. Direct Func#()'s Test :
    	 Test Diff of 16.962
    	% Diff to Production of 0.826
    
    10379970 ENC SM: @600 PERF with ISR Cascade .vs. Direct Func#()'s Test :
    	 Test Diff of 24.728  {this is most nebulous}
    	% Diff to Production of 0.728
    Code:
    6052840 nor ns: @600 PERF _isr() char[] Test % Diff versus production T4:
    	_isr() char[] Test @24 us % Diff of 1.000
    	_isr() char[] Test @48 us % Diff of 1.000
    	_isr() char[] Test @96 us % Diff of 1.001
    	_isr() char[] Test @192 us % Diff of 1.000
    
    6052840 nor ns: @600 PERF Cascade .vs. Direct Func#()'s Test :
    	 Test Diff of 14.072
    	% Diff to Production of 0.996
    
    6052840 nor ns: @600 PERF with ISR Cascade .vs. Direct Func#()'s Test :
    	 Test Diff of 20.643  {this is most nebulous}
    	% Diff to Production of 0.872
    Code:
    6683800 nor ns: @600 PERF _isr() char[] Test % Diff versus production T4:
    	_isr() char[] Test @24 us % Diff of 1.000
    	_isr() char[] Test @48 us % Diff of 1.000
    	_isr() char[] Test @96 us % Diff of 1.001
    	_isr() char[] Test @192 us % Diff of 1.000
    
    6683800 nor ns: @600 PERF Cascade .vs. Direct Func#()'s Test :
    	 Test Diff of 14.020
    	% Diff to Production of 0.999
    
    6683800 nor ns: @600 PERF with ISR Cascade .vs. Direct Func#()'s Test :
    	 Test Diff of 20.153  {this is most nebulous}
    	% Diff to Production of 0.893
    If you don't see near 1.000 on Production board it comes from nearest build values seen with bool bPrintExtra = true

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,081

    TSET command line build works from SubLime

    @Paul - All looking good for general use Arduino and Command line call of the builder - ala TSET!
    > many builds and uploads and no faults or issues - that can't be perhaps explained by jumping between 2 or 4 T4's doing Reset and Bootloader Upload via USB command.
    > Not doing .lst file in each build (plus perhaps local system changes) results in expected build times. with upload just over 10 secs for 10 func() c4cBM and just over 1 minute with 4,000 func()'s

    Not sure I changed anything in TSET (core local file date was 8/28) from Beta1 ... may have been a timing error or caught something since beta improved.
    > The Upload doesn't finish before TyCommander reports 'failed to reset' - but the upload completes - at least with 4K func()'s in C4CbenchM
    NOTES for TSET:
    > answer LAST question "T" not "Y" to upload with TeensyLoader
    > For MULTI INO sketches :: Do the build of Compile.cmd from the MAIN INO! {then any file in folder will run Build right}
    > tested BUILD UPLOAD (normal), Verify (notifies TLoader of new HEX location) , CLEAN (Full rebuild empties TEMP)
    > New copy of TSET on github, as always save or edit CMD1.BAT

    BTW: If you have Multiple of same Teensy online - it works to pick one to upload directly, then Button or GUI 'Bootloader' the others. All work as normal on TyComm serial Monitor.
    And of course don't integrate TyComm for the Beta Locked - then building opens Teensy Loader

    UPDATED :: Defragster/T4LockBeta/tree/main/C4CbenchM
    > had not replaced the .txt content to swap number of funcs() with reduced number of Pi Digits calculated from 60 to 12, so saw ERRORS.
    > Results seem to change with build So for side by side compare use bool bPrintExtra = true; to see the raw numbers.
    -> it does shows the decrypting from FLASH adds overhead, though the 'nebulous' Combo ISR & char[] test are very close so it may be that the decrypt [data & code] happens in parallel, or it is so busy with lost cache that the difference is a wash - or maybe there is an error in the calc logic.
    > Hitting 'Enter' triggers loop() to run repeatedly and show the Temp, and allows resetting of bool "bPrintExtra = false;" at compile time -

    Here is Console output - you can see it is not from IDE because the string "teensy_size:" is present:
    Code:
    Building Sketch: ".\C4CbenchM.ino"
    Using board 'teensy40' from platform in folder: C:\T_Drive\Arduino_1.8.16_155\hardware\teensy\avr
    Using core 'teensy4' from platform in folder: C:\T_Drive\Arduino_1.8.16_155\hardware\teensy\avr
    Detecting libraries used...
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=155 -DARDUINO=10600 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr\\cores\\teensy4" "R:\\temp\\arduino_build_C4CbenchM.ino\\sketch\\C4CbenchM.ino.cpp" -o nul
    Generating function prototypes...
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=155 -DARDUINO=10600 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr\\cores\\teensy4" "R:\\temp\\arduino_build_C4CbenchM.ino\\sketch\\C4CbenchM.ino.cpp" -o "R:\\temp\\arduino_build_C4CbenchM.ino\\preproc\\ctags_target_for_gcc_minus_e.cpp"
    "C:\\T_Drive\\Arduino_1.8.16_155\\tools-builder\\ctags\\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "R:\\temp\\arduino_build_C4CbenchM.ino\\preproc\\ctags_target_for_gcc_minus_e.cpp"
    Compiling sketch...
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/precompile_helper" "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr/cores/teensy4" "R:\\temp\\arduino_build_C4CbenchM.ino" "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -x c++-header -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=155 -DARDUINO=10600 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr/cores/teensy4" "R:\\temp\\arduino_build_C4CbenchM.ino/pch/Arduino.h" -o "R:\\temp\\arduino_build_C4CbenchM.ino/pch/Arduino.h.gch"
    Using previously compiled file: R:\temp\arduino_build_C4CbenchM.ino\pch\Arduino.h.gch
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=155 -DARDUINO=10600 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IR:\\temp\\arduino_build_C4CbenchM.ino/pch" "-IC:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr\\cores\\teensy4" "R:\\temp\\arduino_build_C4CbenchM.ino\\sketch\\C4CbenchM.ino.cpp" -o "R:\\temp\\arduino_build_C4CbenchM.ino\\sketch\\C4CbenchM.ino.cpp.o"
    Compiling libraries...
    Compiling core...
    Using precompiled core: R:\temp\arduino_cache_C4CbenchM.ino\core\core_4291cde6f2aeb6bd53a075bd323e65cd.a
    Linking everything together...
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TC:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.elf" "R:\\temp\\arduino_build_C4CbenchM.ino\\sketch\\C4CbenchM.ino.cpp.o" "R:\\temp\\arduino_build_C4CbenchM.ino/..\\arduino_cache_C4CbenchM.ino\\core\\core_4291cde6f2aeb6bd53a075bd323e65cd.a" "-LR:\\temp\\arduino_build_C4CbenchM.ino" -larm_cortexM7lfsp_math -lm -lstdc++
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.elf" "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.eep"
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.elf" "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.hex"
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/teensy_secure" encrypthex TEENSY40 "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.hex"
    encrypting 1107968 bytes to R:\temp\arduino_build_C4CbenchM.ino/C4CbenchM.ino.ehex
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/teensy_post_compile" -file=C4CbenchM.ino "-path=R:\\temp\\arduino_build_C4CbenchM.ino" "-tools=C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/" -board=TEENSY40
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/stdout_redirect" "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.sym" "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.elf"
    "C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/teensy_size" "R:\\temp\\arduino_build_C4CbenchM.ino/C4CbenchM.ino.elf"
    teensy_size: Memory Usage on Teensy 4.0:
    teensy_size:   FLASH: code:972344, data:134680, headers:9132   free for files:915460
    teensy_size:    RAM1: variables:90848, code:28968, padding:3800   free for local variables:400672
    teensy_size:    RAM2: variables:12384  free for malloc/new:511904
          upload@10379970-Teensy  Uploading to board '10379970-Teensy' (Teensy 4.0)
          upload@10379970-Teensy  Triggering board reboot
          upload@10379970-Teensy  Waiting for Teensy Loader
          upload@10379970-Teensy  Failed to reset board '10379970-Teensy'
    [Finished in 70.9s]
    Last edited by defragster; 09-13-2021 at 09:56 AM.

  7. #7
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,551
    @Paul

    As @defragster said
    All looking good for general use Arduino ........
    > many builds and uploads and no faults or issues - that can't be perhaps explained .......
    Last night and this morning I tried to fault the Locked T4 doing successive uploads of Tim's code4code sketch and then hitting the pgm button a couple of times in between to reload the sketch without any faults. In addition I uploaded several sketches one after the other with PGM button pushes in between without faulting. Only one time did I get the RED and orange light at the same time but that was my fault - I pressed the PGM button at almost the same time as a sketch was uploading I did see a Message window pop up from TL but wasn't on the screen long enough to read it - another PGM push loaded the sketch properly so again was probably me.

  8. #8
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,564
    Morning all,
    Installed latest beta...

    I am not sure if the SEREMU fix is working properly now in this build? That is I build MTPD sketch (using the in build MTP Disk) and lost most of the startup output and also it felt like I was back to longer delays on startup...
    So Again ran slightly modified test:
    Code:
    //#include <MTP.h>
    
    void setup() {
      while (!Serial && millis() < 5000) ;
      Serial.begin(115200);
      if (!Serial) Serial.println("!Serial");
      Serial.println(millis(), DEC);
      Serial.print(CrashReport);
    
      Serial.println("Enter something to go boom");
    }
    uint16_t loop_count = 0;
    void loop() {
      if (Serial.read() != -1) {
        uint8_t *ptr = 0;
        *ptr = 99;
      }
      Serial.printf("Loop Count: %u\n", ++loop_count);
      delay(250);
    }
    When I run this With USB type of Serial I get:
    Code:
    461
    CrashReport:
      A problem occurred at (system time) 5:24:28
      Code was executing from address 0x88
      CFSR: 82
    	(DACCVIOL) Data Access Violation
    	(MMARVALID) Accessed Address: 0x0 (nullptr)
    	  Check code at 0x88 - very likely a bug!
    	  Run "addr2line -e mysketch.ino.elf 0x88" for filename & line number.
      Temperature inside the chip was 48.98 C
      Startup CPU clock speed is 600MHz
      Reboot was caused by auto reboot after fault or bad interrupt detected
    Enter something to go boom
    Loop Count: 1
    Loop Count: 2
    Loop Count: 3
    When I run it with USB Type of: MTP Disk (experimental) It runs, but notice difference in how long it takes to run:
    Code:
    6030
    CrashReport:
      A problem occurred at (system time) 5:26:42
      Code was executing from address 0x88
      CFSR: 82
    	(DACCVIOL) Data Access Violation
    	(MMARVALID) Accessed Address: 0x0 (nullptr)
    	  Check code at 0x88 - very likely a bug!
    	  Run "addr2line -e mysketch.ino.elf 0x88" for filename & line number.
      Temperature inside the chip was 48.33 C
      Startup CPU clock speed is 600MHz
      Reboot was caused by auto reboot after fault or bad interrupt detected
    Enter something to go boom
    Loop Count: 1
    Loop Count: 2
    Loop Count: 3
    Loop Count: 4
    I ran this both with locked T4 and normal T4... Maybe something screwy on my machine, but ...

  9. #9
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,551
    Quote Originally Posted by KurtE
    Morning all,
    Installed latest beta...

    I am not sure if the SEREMU fix is working properly now in this build? That is I build MTPD sketch (using the in build MTP Disk) and lost most of the startup output and also it felt like I was back to longer delays on startup...
    So Again ran slightly modified test:
    Code:
    //#include <MTP.h>
    
    void setup() {
      while (!Serial && millis() < 5000) ;
      Serial.begin(115200);
      if (!Serial) Serial.println("!Serial");
      Serial.println(millis(), DEC);
      Serial.print(CrashReport);
    
      Serial.println("Enter something to go boom");
    }
    uint16_t loop_count = 0;
    void loop() {
      if (Serial.read() != -1) {
        uint8_t *ptr = 0;
        *ptr = 99;
      }
      Serial.printf("Loop Count: %u\n", ++loop_count);
      delay(250);
    }
    Just ran it here on my Win10x64 machine and got very similar results:

    With USB type of Serial = 412
    With USB Type of: MTP Disk (experimental) = 6048


    This is on a locked T4 with the latest updates.

  10. #10
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,564
    Just ran on Ubuntu machine and with Beta2 and latest, timing was about 880ms with Beta3 about 990... Not sure if real difference or just slight delta... Will see how it runs on MAC next

  11. #11
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,551
    Went back to the Beta1 thread and found @KurtE's initial timing timing test: https://forum.pjrc.com/threads/67989...l=1#post288241, which shows it was 1011ms. Only thing not 100% sure about is if that was with Windows or Ubuntu. @KurtE?

  12. #12
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,564
    Quote Originally Posted by mjs513 View Post
    Went back to the Beta1 thread and found @KurtE's initial timing timing test: https://forum.pjrc.com/threads/67989...l=1#post288241, which shows it was 1011ms. Only thing not 100% sure about is if that was with Windows or Ubuntu. @KurtE?
    That one was Windows 10...

    Note on MAC it was about 300ms...
    But I am not sure if MAC has any MTP stuff built in...
    At one point was playing with OpenMTP... But...

    Sorry Paul, I know this is not an MTP release... Am just checking for differences from Beta2 to Beta3 and it felt like it had changed between the two betas...

    Edit: tried running beta 2 with Arduino 15 with current cores\teensy4 same timings... Not sure what changed... Or maybe I was dreaming when it came up in about a second earlier... (Beta 1 thread)
    Last edited by KurtE; 09-13-2021 at 02:52 PM.

  13. #13
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,564
    MTP Disk - startup timing differences...

    Figured out what was different, between then and now. I believe I mentioned I had a modified usb_desc.h file that I was trying.
    That I changed it to be closer to Audio...

    That is it has two interfaces: MTP and SEREMU...
    Current in build:
    Code:
    #define MTP_INTERFACE		0	// MTP Disk
    #define SEREMU_INTERFACE      1 // Serial emulation
    Timeout in this case about: 6 seconds

    Change to:
    Code:
    #define MTP_INTERFACE		1	// MTP Disk
    #define SEREMU_INTERFACE      0 // Serial emulation
    Timeout < 1 second:
    Code:
    994
    CrashReport:
      A problem occurred at (system time) 8:42:21
      Code was executing from address 0x88
      CFSR: 82
    	(DACCVIOL) Data Access Violation
    	(MMARVALID) Accessed Address: 0x0 (nullptr)
    	  Check code at 0x88 - very likely a bug!
    	  Run "addr2line -e mysketch.ino.elf 0x88" for filename & line number.
      Temperature inside the chip was 53.52 C
      Startup CPU clock speed is 600MHz
      Reboot was caused by auto reboot after fault or bad interrupt detected
    Enter something to go boom
    Loop Count: 1
    Loop Count: 2
    Loop Count: 3
    To late to change?

  14. #14
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,551
    @KurtE
    Just made the changed and on my locked T4 shows even better:
    Code:
    344
    CrashReport:
      A problem occurred at (system time) 11:53:50
      Code was executing from address 0x88
      CFSR: 82
    	(DACCVIOL) Data Access Violation
    	(MMARVALID) Accessed Address: 0x0 (nullptr)
    	  Check code at 0x88 - very likely a bug!
    	  Run "addr2line -e mysketch.ino.elf 0x88" for filename & line number.
      Temperature inside the chip was 57.06 C
      Startup CPU clock speed is 600MHz
      Reboot was caused by auto reboot after fault or bad interrupt detected
    Enter something to go boom
    Loop Count: 1
    Loop Count: 2
    Loop Count: 3
    Loop Count: 4
    before booming the T4
    Code:
    1001
    No Crash Data To Report
      Hopefully all is well, but certain types of crashes can't be reported:
    	stuck in an infinite loop (technically, hardware still running properly)
    	remaining in a low power sleep mode
    	access to certain peripherals without their clock enabled (eg, FlexIO)
    	change of CPU or bus clock speed without use of glitchless mux
    Enter something to go boom
    Loop Count: 1
    Loop Count: 2

  15. #15
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,564
    Quote Originally Posted by mjs513 View Post
    @KurtE
    Just made the changed and on my locked T4 shows even better:
    Thanks,

    I went ahead and created a PR: https://github.com/PaulStoffregen/cores/pull/608

    Edit: I meant to also mention I tried running the same sketch with T3.6, but it does not show the same delays.
    Also does not go boom and does not support CrashReport

  16. #16
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,081
    Quote Originally Posted by KurtE View Post
    Morning all,
    Installed latest beta...

    I am not sure if the SEREMU fix is working properly now in this build? That is I build MTPD sketch (using the in build MTP Disk) and lost most of the startup output and also it felt like I was back to longer delays on startup...
    ...
    When I tested with the dual while() {blink mostly off then on} on prior thread - the change to .begin() in cores showed function - but it was still slow - where the first 5 second wit exhausted - it didn't make it any faster for Serial to come online with the patch applied.

    i.e.: it worked - but was still slow to come online with MTP_exp

    Just tried that USB==Serial build fine on TyComm with :: firstSerial @462
    -> but never starts on USB==MTP_exp as before

    with USB==MTP_exp Opening IDE and starting t_serial.exe gives :: firstSerial @6851 - hadn't printed first Serial millis() before - but that is what the blinks showed.

    <crosspost - hand edited the PR==608 and it works better here>
    Making Kurts usb_desc.h edits: #elif defined(USB_MTPDISK)
    #define MTP_INTERFACE 1 // MTP Disk
    #define SEREMU_INTERFACE 0 // Serial emulation


    IDE t_SerMon reports a faster and good :: firstSerial @792

    > change doesn't help TyComm for whatever reason.

    Did get same results with CmdLine :: teensy_serialmon.exe -v usb:0/140000/0/6/1/1


    <EDIT> :: BTW - I built the MTP_Boom.ino from TSet {as Serial and MTP_exp} and it worked! { only problem hinted at above } is that not having IDE open means there is no easy way to start a usable SerMon - either open IDE or dig the USB: out of TLoader/Verbose in a DOS box.

  17. #17
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,081
    Didn't build any LittleFS - but just confirmed all RAM drives : PSRAM or DMAMEM that can generally persist across warm restart for some avenue of utility have been set to destroy on .begin()

    > memset(ptr, 0xFF, size); // always start with blank slate

    Not sure why YMMV loss of utility ... but that is now the case.

    <edit>: yes, I was a big fan of the old awesome behavior.
    > If the user wanted this destructive 'safe' behavior it is easy to do low level format or even Quick format on start in the examples with YMMV note on removing that.
    Last edited by defragster; 09-13-2021 at 06:02 PM.

  18. #18
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,551
    Quote Originally Posted by defragster View Post
    Didn't build any LittleFS - but just confirmed all RAM drives : PSRAM or DMAMEM that can generally persist across warm restart for some avenue of utility have been set to destroy on .begin()

    > memset(ptr, 0xFF, size); // always start with blank slate

    Not sure why YMMV loss of utility ... but that is now the case.

    <edit>: yes, I was a big fan of the old awesome behavior.
    > If the user wanted this destructive 'safe' behavior it is easy to do low level format or even Quick format on start in the examples with YMMV note on removing that.
    Wouldn't worry too much about LittleFS @KurtE and I have been testing the heck out of it while testing MTP. Think the only thing we haven't tested was QSPI since we have been primarily using the Locked T4. Tested NAND, SPI flash, RAM, Program etc. Works very well with what we have been doing with MTP as well.

  19. #19
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,081
    Quote Originally Posted by mjs513 View Post
    Wouldn't worry too much about LittleFS @KurtE and I have been testing the heck out of it while testing MTP. Think the only thing we haven't tested was QSPI since we have been primarily using the Locked T4. Tested NAND, SPI flash, RAM, Program etc. Works very well with what we have been doing with MTP as well.
    My worry was with the RAM feature/function loss

    I migrated "LittleFS usuage" <sic> into C4CbenchM.ino running it to PROG Flash before starting the C4C code.

    Just added the INO to the sketch folder and had to prototype the two versions of PrintDir - and take out the SPI usage for PROG and luckily downsize the PROG to 824 KB:
    Code:
    teensy_size: Memory Usage on Teensy 4.0:
    teensy_size:   FLASH: code:1003656, data:136800, headers:8468   free for files:882692
    teensy_size:    RAM1: variables:90848, code:56808, padding:8728   free for local variables:367904
    teensy_size:    RAM2: variables:12384  free for malloc/new:511904
    So it works with Func4000()'s !!!

    Then I had to comment :: //myfs.quickFormat();
    >> which is what RAM_drive could do if they worried about prior content

    So the first thing that Example does is WIPE drive Media before each start Upload, cold or warm start.

    So with that gone I duped the bigfile to bigfile2 and it Persists and grows with each Restart or Upload.


    >> Just decided to try the same on second Unlockble T4 Beta
    - It works to Not Full Erase Flash

    ALSO TESTING BUG FIX - on Unlockable Beta with Locked Bad pem.key from Beta 2
    It seems to have properly recognized the issue
    Code:
    Writing public key hash
    Error: public key hash not written properly!
           Secure mode will not run your programs
    
    Decryption key was previously written & locked, so
    it can not be directly verified, but the following
    test will confirm whether decryption works.
    
    
    Testing Bus Encryption Engine
    Success: ciphertext decryption test passed :-)
    
    Notice: JTAG is still enabled
    
    Notice: Secure mode is not yet set, unencrypted
            programs are still allowed to run
    @Paul Question on FuseWrite.ino_BETA3 as written:
    Those [8] sequential tests seem ODD - perhaps it pans out as the best and proper way . But what if one of the 8 was keyed with no bits set as parts of a proper key? Perhaps impossible, or not likely, one set of 32 bits would have the same 'unset' value. Just seems all [8] should be tested and if ANY fails - then none should be written?

    And as noted above there is a typo in comment of LittleFS_Usage.ino :: LittleFS usuage from the LittleFS library

  20. #20
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,551
    And as noted above there is a typo in comment of LittleFS_Usage.ino :: LittleFS usuage from the LittleFS library
    PR issued, https://github.com/PaulStoffregen/LittleFS/pull/27, changing the comment to "usage". But primarily the PR was issued to update keyword.txt to add "LittleFS_SPINAND" and "LittleFS_QPINAND" to the list. Thanks for pointing out the spelling error.

  21. #21
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,081
    Quote Originally Posted by mjs513 View Post
    PR issued, https://github.com/PaulStoffregen/LittleFS/pull/27, changing the comment to "usage". But primarily the PR was issued to update keyword.txt to add "LittleFS_SPINAND" and "LittleFS_QPINAND" to the list. Thanks for pointing out the spelling error.
    Cool, and MERGED.

  22. #22
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,564
    Paul and all,

    As @mjs513 mentioned, we have been testing out lots of the LittleFS versions, as well as some SD card stuff. And as mentioned doing most of it with T4 and T4.1 as to compare locked version versus unlocked...

    I have also done a little now with T3.6, as a quick and dirty sanity test to make sure our updates to FS two classes compiles and the like.

    I used one of @mjs513 sketches that does do a little FS on several different media, including the Memory board that Paul built with 4 memories. As well as an SD Card connected to pin 8...

    It built and runs.

    Ran into a few interesting things.

    A couple of times, I receive the message in the build area, about not being able to open the port... Something like reporting ready before it was...

    Also had issue with one SDCard that this sketch could not open. Also the listfiles SD example could not open...

    But then I ran the SD example: SDFat_usage and it appeared like it worked... I then took card over to PC, which looked ok, copied a few more files to it...And then brought back to T3.6 and it liked the cared then...
    Probably some hiccup like corrupted. Or maybe it does not like a Card with nothing on it... Will play some more.

    LittleFS_RAM ... So far I am only using this mostly for test cases and I can see if I want a quick and dirty drive for MTP... sometimes persist/never-persist. Probably something to discuss after the release cycle...

    But maybe the right answer for this is to make two different classes for it... That is if you want you can create something like: LittleFS_RAMPERSIST... or some such name.

    But since it is setup to not persist, wondering if this code within the class is needed
    Code:
    	static int static_sync(const struct lfs_config *c) {
    		if ( c->context >= (void *)0x20200000 ) {
    			//Serial.printf("    arm_dcache_flush_delete: ptr=0x%x, size=%d\n", c->context, c->block_count * c->block_size);
    			arm_dcache_flush_delete(c->context, c->block_count * c->block_size );
    		}
    		return 0;
    	}
    Also wondering how often it is called. That is, is this called every time LittleFS writes out a block of memory? Or when file closed...
    What overhead does this give us: That is if I am reading this right, if I have a T4.1 with an 8MB SRAM on it with LittleFS, this will call the arm_dcache_flush_delete on the whole 8mb range, so
    the loop in the call will loop 262144 times... So hope not called often. Also not sure why it does flush_delete? So the next memory reads in LittleFS will then have to fetch back from real memory.

    Anyone bench marked this to see if any differences?

    Just wondering

    EDIT: Tried with T4.1... Created RAM of 4mb... so far working... Calls static_sync reasonably infrequent. I built it with MTP... When I copied files to it maybe twice for the file... Actually maybe one per file plus one for index...
    Last edited by KurtE; 09-14-2021 at 12:01 AM.

  23. #23
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,081
    Quote Originally Posted by KurtE View Post
    Paul and all,

    As @mjs513 mentioned, we have been testing out lots of the LittleFS versions, as well as some SD card stuff. And as mentioned doing most of it with T4 and T4.1 as to compare locked version versus unlocked...

    I have also done a little now with T3.6, as a quick and dirty sanity test to make sure our updates to FS two classes compiles and the like.

    I used one of @mjs513 sketches that does do a little FS on several different media, including the Memory board that Paul built with 4 memories. As well as an SD Card connected to pin 8...

    It built and runs.

    Ran into a few interesting things.

    A couple of times, I receive the message in the build area, about not being able to open the port... Something like reporting ready before it was...

    Also had issue with one SDCard that this sketch could not open. Also the listfiles SD example could not open...

    But then I ran the SD example: SDFat_usage and it appeared like it worked... I then took card over to PC, which looked ok, copied a few more files to it...And then brought back to T3.6 and it liked the cared then...
    Probably some hiccup like corrupted. Or maybe it does not like a Card with nothing on it... Will play some more.

    LittleFS_RAM ... So far I am only using this mostly for test cases and I can see if I want a quick and dirty drive for MTP... sometimes persist/never-persist. Probably something to discuss after the release cycle...

    But maybe the right answer for this is to make two different classes for it... That is if you want you can create something like: LittleFS_RAMPERSIST... or some such name.

    But since it is setup to not persist, wondering if this code within the class is needed
    Code:
    	static int static_sync(const struct lfs_config *c) {
    		if ( c->context >= (void *)0x20200000 ) {
    			//Serial.printf("    arm_dcache_flush_delete: ptr=0x%x, size=%d\n", c->context, c->block_count * c->block_size);
    			arm_dcache_flush_delete(c->context, c->block_count * c->block_size );
    		}
    		return 0;
    	}
    Also wondering how often it is called. That is, is this called every time LittleFS writes out a block of memory? Or when file closed...
    What overhead does this give us: That is if I am reading this right, if I have a T4.1 with an 8MB SRAM on it with LittleFS, this will call the arm_dcache_flush_delete on the whole 8mb range, so
    the loop in the call will loop 262144 times... So hope not called often. Also not sure why it does flush_delete? So the next memory reads in LittleFS will then have to fetch back from real memory.

    Anyone bench marked this to see if any differences?

    Just wondering

    EDIT: Tried with T4.1... Created RAM of 4mb... so far working... Calls static_sync reasonably infrequent. I built it with MTP... When I copied files to it maybe twice for the file... Actually maybe one per file plus one for index...
    I can say - having put the cache_flush there it is called often and regularly on block and indexing changes - often enough that nothing in the cache is at risk of not being in RAM with restart it seemed - seeing the .printf() output. I put in a PR that it doesn't need the _delete - but that was on the line I copied into the code. I asked at the time in that Beta and it wasn't discussed and left in - that was when the persistent was enabled - and it should not delete.

    I never paid attention to the length of the flush - given LFS often duplicates changes - the flush/sync may be associated with the cleanup after changes when blocks are committed.

    Having a way to maintain a persistence - certainly across 8-16 MB of PSRAM makes sense and was tested directly and indirectly. A large amount of data could be quickly 'buffered' there and in the event of warm restart - it would not have been lost. Now it is encoded with LFS storage structures - and deleted on .begin(). It does add overhead to direct memory storage - but as planned it is common file storage interface.

  24. #24
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,081
    @KurtE - can only test DMAMEM on T_4's active. Sync is HUGE on each file - the whole media size.

    Code:
    [  0.35 M](0.35438 M elap) Awaiting input 0123456789RdDwcghkFqvplmusSBbyYxfan+-? loops left 0 >1
    :: /B_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
        arm_dcache_flush_delete: ptr=0x20200000, size=399360
        arm_dcache_flush_delete: ptr=0x20200000, size=399360
     +++ size 0: Add 1152 @KB/sec 774.19 	  Verify 1152 Bytes  @KB/sec 2456.29
    :: /C_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
        arm_dcache_flush_delete: ptr=0x20200000, size=399360
     +++ size 0: Add 1664 @KB/sec 1218.16 	  Verify 1664 Bytes  @KB/sec 2548.24
    :: /1_dir/D_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
        arm_dcache_flush_delete: ptr=0x20200000, size=399360
     +++ size 0: Add 2176 @KB/sec 1314.80 	  Verify 2176 Bytes  @KB/sec 2696.41
    :: /1_dir/E_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
        arm_dcache_flush_delete: ptr=0x20200000, size=399360
     +++ size 0: Add 2688 @KB/sec 1338.65 	  Verify 2688 Bytes  @KB/sec 2734.49
    :: /2_dir/A_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
        arm_dcache_flush_delete: ptr=0x20200000, size=399360
     +++ size 0: Add 5760 @KB/sec 1555.92 	  Verify 5760 Bytes  @KB/sec 2830.47
    :: /2_dir/B_file.txt     arm_dcache_flush_delete: ptr=0x20200000, size=399360
        arm_dcache_flush_delete: ptr=0x20200000, size=399360

    Indeed on a volatile/discardable disk - like RAM1 where addresses were excluded - there is no point in the sync.

  25. #25
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,057
    Quote Originally Posted by defragster View Post
    -->> Looked down and saw DUAL LEDS
    Quote Originally Posted by mjs513 View Post
    Only one time did I get the RED and orange light at the same time but that was my fault - I pressed the PGM button at almost the same time as a sketch was uploading...
    Oh, now that is a valuable piece of info! It very likely may be a bootloader bug in 1.07. The bootloader is supposed to ignore the Program button during certain critical times, but probably isn't in this case with a locked chip.


    Edit: just so you know, this is absolutely not your fault. The both LEDs blink pattern is an error that's never supposed to happen.
    Last edited by PaulStoffregen; 09-14-2021 at 01:35 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •