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

Thread: Teensyduino 1.56 Beta #3

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

    Teensyduino 1.56 Beta #3

    Here is a third beta test for Teensyduino 1.56.


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

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

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

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

    MacOS 10.10 to 10.15:
    https://www.pjrc.com/teensy/td_156-b...S_Catalina.zip

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

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


    Changes since Teensyduino 1.56-beta2:

    Teensy Loader updates Teensy 4.0, 4.1, MicroMod to bootloader 1.07
    Improve SD.mediaPresent()
    Fix SD compile error on Teensy LC
    Show helpful error if original SdFat used
    Fix SdFat example compile errors, FsFile & SD_FAT_TYPE
    Delete SdFat examples not needed for Teensy
    Improve SdFat format speed with SHARED_SPI
    Improve SdFat free cluster count speed with SHARED_SPI
    Add SdFat restart(), to reinitialize hardware & card
    SdFat FAT16/32 format use existing buffer (Kurt E)
    SdFat support for GPT partitions (Kurt E)
    SdFat fix use of USE_SIMPLE_LITTLE_ENDIAN
    SdFat fix exfat corruption when using timestamps (Kurt E)
    Wire use inline functions for AVR
    Wire increase buffer size on Teensy 3 & 4
    Wire fix ambiguous requestFrom with bool
    FS use block write (Kurt E)
    Fix IMXRT_DMA_TCD define
    Add comments in imxrt.h for clock gate requirements
    Fix MTP count of bytes transferred (Kurt E)
    Improve usbMIDI.send_now() on Teensy 3.x (Robert Jonkman)
    Improve Stream comptibility with newer Arduino (Kurt E)
    Audio add play queue setMaxBuffers() (Mark T)
    Audio add play queue play() for raw data (Mark T)
    Update FastLED to 3.4
    FastLED fix OctoWS2811 driver on Teensy 4 (Shawn Silverman)
    FastLED fix WS2812B timing on Teensy 4
    OctoWS2811 add BasicTest_FastLED example
    FreqCount fix for reading less slower than gate interval (mjs513)
    FreqCount add missing end() function (mjs513)
    LittleFS update internal littlefs to version 2.4.1 (mjs513)
    Tlc5940 minor update for compiler flag setting (Adam Phelps)
    OneWire minor updates for non-Teensy boards
    USBHost_t36 fix HIDDumper example for Linux (Kurt E)
    USBHost_t36 increase enum buffer for complex MIDI devices (Robert Jonkman)
    Improve Teensy 4 Secure fusewrite and locksecuremode
    Allow some old Teensy 4.x boards to run EHEX files
    Add usage info with -h to teensy_post_compile and teensy_ports
    Fix teensy_ports -L on Windows

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,478
    Fresh IDE 1.86 unzip to assure no leftover and Win install of TD 1.86 beta 3 : No issues.
    > Only Windows security note was for JAVA access for the new IDE 1.86 install to be allowed.

    Plugged in a production T_4.0 and successful Bootloader updated from 1.05 to 1.07 to run BlinkWithoutDelay.ino

    Also uploaded that to two T_4.0 unlocked Beta boards already running 1.07 to blink.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,471
    Should probably mention, the main benefit from the 1.07 update is LittleFS_Program will persist across code uploads, if the filesystem size is within these limits.

    Code:
    Board            Normal  Secure
    -----            ------  ------
    Teensy 4.0       1472K   960K
    Teensy 4.1       7424K   6912K  
    MicroMod Teensy  15616K  15104K
    1.07 should also solve the long initial lag at the beginning of uploading when Teensy 4.1 & MicroMod were previously written with a very large program.

  4. #4
    Senior Member
    Join Date
    Dec 2015
    Location
    LA
    Posts
    235
    Installed ok on Mac Catalina 10.15.7.

    Not sure if me or FreqCount() is still not able to have its interval changed and expect good output in the first cycle. This is the T4 FreqCount example code modified to show the issue.

    Code:
    #include <FreqCount.h>
    
    int incr;
    
    void setup() {
      Serial.begin(57600);
    
      delay(2000);
      analogWriteFrequency(8, 1000000);  // test jumper 8 to 9
      analogWrite(8, 128);
        
      FreqCount.begin( 1000000); 
    }
    
    void loop() {
      if (FreqCount.available()) {
        unsigned long count = FreqCount.read();
        Serial.println(count);
        incr++;
        if(incr%3==1){   //only restart every 3rd time
          FreqCount.end();
          FreqCount.begin( 1000000);  //this would be modified to a new interval in a non trivial example
        }
      }
    }
    Here is the output. Note the second and third time is ok.
    Code:
    999871
    131
    1000000
    1000000
    4292967296
    1000000
    1000000
    4292967295
    1000000
    1000000
    4292967296
    1000000
    1000000

  5. #5
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,848
    Quote Originally Posted by PaulStoffregen View Post
    Should probably mention, the main benefit from the 1.07 update is LittleFS_Program will persist across code uploads, if the filesystem size is within these limits.

    Code:
    Board            Normal  Secure
    -----            ------  ------
    Teensy 4.0       1472K   960K
    Teensy 4.1       7424K   6912K  
    MicroMod Teensy  15616K  15104K
    1.07 should also solve the long initial lag at the beginning of uploading when Teensy 4.1 & MicroMod were previously written with a very large program.
    Downloaded a bit earlier and been testing flash with MTP - have to saw that 1.07 seems to really improve uploading at least from anecdotal experience. Didn't time it but just seems faster. So now it makes sense. You are right a lot of updates since beta2

  6. #6
    Quote Originally Posted by bicycleguy View Post
    Not sure if me or FreqCount() is still not able to have its interval changed and expect good output in the first cycle.
    The reason the first reading is wrong is that static uint32_t count_prev is not initialized. In file util\FreqCountTimers.h, add the line to init count_prev = 0, as shown below. This yields good results, as shown further below, though there is still a very small error on the first measurement. In your sketch, add a call to delay(100) between calling analogWrite() and FreqCount.begin(). This gives the PWM time to get going so that you get a better result on the first measurement.

    Code:
    static inline uint16_t timer_init(uint32_t usec)
    {
    	itimer.begin(timer_callback, usec);  //timer correction
    	count_prev = 0; // ** add this line **
    	return usec;
    }
    
    1000001
    1000000
    1000000
    1000002
    1000000
    1000000
    1000002
    1000000
    1000000
    1000002
    1000000
    1000000
    1000001
    1000000
    1000000

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,478
    Quote Originally Posted by joepasquariello View Post
    The reason the first reading is wrong is that static uint32_t count_prev is not initialized. In file util\FreqCountTimers.h, add the line to init count_prev = 0, as shown below. This yields good results, as shown further below, though there is still a very small error on the first measurement. In your sketch, add a call to delay(100) between calling analogWrite() and FreqCount.begin(). This gives the PWM time to get going so that you get a better result on the first measurement.

    ...
    Or the sketch can ignore the first reading after the change:
    Code:
    #include <FreqCount.h>
    
    int incr;
    bool firstRead = true;
    int myFreq = 1000000;
    
    void setup() {
      Serial.begin(57600);
      delay(2000);
      analogWriteFrequency(8, myFreq);  // test jumper 8 to 9
      analogWrite(8, 128);
      FreqCount.begin( myFreq);
    }
    
    void loop() {
      if (FreqCount.available()) {
        unsigned long count = FreqCount.read();
        if ( !firstRead ) {
          Serial.println(count);
        }
        else {
          Serial.print("\tPartial Period :: ");
          Serial.println(myFreq);
          firstRead = false;
        }
        incr++;
        if (incr % 3 == 0) { //only restart every 3rd time
          FreqCount.end();
          myFreq -= 10000;
          if ( myFreq < 950000 )
            myFreq = 1000000;
          FreqCount.begin( myFreq );  //this would be modified to a new interval in a non trivial example
          firstRead = true;
        }
      }
    }
    showing:
    Code:
    1000000
    1000000
    	Partial Period :: 990000
    990000
    990000
    	Partial Period :: 980000
    980000
    980000
    	Partial Period :: 970000
    970000
    970000
    	Partial Period :: 960000
    960000
    960000
    	Partial Period :: 950000
    950000
    950000
    	Partial Period :: 1000000
    1000000
    1000000

  8. #8
    I agree that’s a fine work-around, but the missing init of count_prev is a bug.

  9. #9
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,478
    Quote Originally Posted by joepasquariello View Post
    I agree that’s a fine work-around, but the missing init of count_prev is a bug.
    Seems right - that is a lot of work around, that makes sense as demo'd - but isn't needed if the static values in the code don't carry over from one .begin to the next.

  10. #10
    Senior Member
    Join Date
    Dec 2015
    Location
    LA
    Posts
    235
    @joepasquariell
    The count_prev = 0; in the library seems to have done the job and fixed the problem in some other programs I'm working on.

    thanks

  11. #11
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,848
    Quote Originally Posted by joepasquariello View Post
    I agree that’s a fine work-around, but the missing init of count_prev is a bug.
    So I should have left it in: https://forum.pjrc.com/threads/68386...l=1#post292786 but maybe not in that place.

  12. #12
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,976
    Just installed on 64 bit Ubuntu... I think I removed the links to my versions of libraries, but SDFat does not build.

    Tried the SD Example ListFiles

    Code:
    /home/kurte/Desktop/arduino-1.8.16/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=156 -DARDUINO=10816 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH -I/tmp/arduino_build_879456/pch -I/home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/cores/teensy4 -I/home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SD/src -I/home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SdFat/src -I/home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SPI /home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SdFat/src/ExFatLib/upcase.cpp -o /tmp/arduino_build_879456/libraries/SdFat/ExFatLib/upcase.cpp.o
    In file included from /home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SdFat/src/ExFatLib/upcase.cpp:25:0:
    /home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SdFat/src/ExFatLib/upcase.h:31:25: error: 'ExChar16_t' does not name a type
                       const ExChar16_t* name, size_t offset, size_t n);
                             ^
    /home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SdFat/src/ExFatLib/upcase.h:33:30: error: 'ExChar16_t' does not name a type
     uint16_t exFatHashName(const ExChar16_t* name, size_t n, uint16_t hash);
                                  ^
    /home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SdFat/src/ExFatLib/upcase.cpp:207:25: error: 'ExChar16_t' does not name a type
                       const ExChar16_t* name, size_t offset, size_t n) {
                             ^
    /home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SdFat/src/ExFatLib/upcase.cpp:230:30: error: 'ExChar16_t' does not name a type
     uint16_t exFatHashName(const ExChar16_t* name, size_t n, uint16_t hash) {
                                  ^
    Multiple libraries were found for "SD.h"
     Used: /home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SD
     Not used: /home/kurte/Desktop/arduino-1.8.16/libraries/SD
    Using library SD at version 2.0.0 in folder: /home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SD 
    Using library SdFat at version 2.1.0 in folder: /home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SdFat 
    Using library SPI at version 1.0 in folder: /home/kurte/Desktop/arduino-1.8.16/hardware/teensy/avr/libraries/SPI 
    Error compiling for board Teensy 4.1.
    Will investigate later... Have diversions right now

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,471
    Quote Originally Posted by KurtE View Post
    but SDFat does not build.
    Recommend extracting a clean copy of Arduino 1.8.16 and installing 1.56-beta3 again.

    Looks like src/ExFatLib/upcase.cpp is a leftover file from a prior SdFat version. It's now src/common/upcase.cpp, without any ExChar16_t types.

    I should probably make the installer check for these leftover files and delete them...

  14. #14
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,976
    Thanks, that took care of it...
    I had been running with my own copy of sources, but thought I should start off with the "released"

    At times wish there was an option in Teensyduino installer, like Install Clean option. Although clean install (I simply deleted hardware\teensy branch... did remove my boards.local.txt file...

  15. #15
    Senior Member
    Join Date
    Dec 2015
    Location
    LA
    Posts
    235
    Just wanted to report on Mac Catalina 10.15.7 a fairly complex T4.1 web server program that moves a directory full of sub folders and files from the SD to the PSRAM on startup works with no changes. Probably my imagination but it seems to do that copy and serve web pages much faster than whatever libraries it used back in August.

    Was curious about the Multiple libraries on SD.h , both from the same distribution. I guess that's the new normal for SD.h?

    Code:
    Memory Usage on Teensy 4.1:
      FLASH: code:291512, data:81800, headers:9120   free for files:7744032
       RAM1: variables:38916, code:146200, padding:17640   free for local variables:321532
       RAM2: variables:12416  free for malloc/new:511872
     EXTRAM: variables:8388608
    Multiple libraries were found for "SD.h"
     Used: /Applications/Teensyduino1-8-16t1-56b3.app/Contents/Java/hardware/teensy/avr/libraries/SD
     Not used: /Applications/Teensyduino1-8-16t1-56b3.app/Contents/Java/libraries/SD
    Using library SD at version 2.0.0 in folder: /Applications/Teensyduino1-8-16t1-56b3.app/Contents/Java/hardware/teensy/avr/libraries/SD 
    Using library SdFat at version 2.1.0 in folder: /Applications/Teensyduino1-8-16t1-56b3.app/Contents/Java/hardware/teensy/avr/libraries/SdFat 
    Using library SPI at version 1.0 in folder: /Applications/Teensyduino1-8-16t1-56b3.app/Contents/Java/hardware/teensy/avr/libraries/SPI 
    Using library NativeEthernet at version 1.0.5 in folder: /Applications/Teensyduino1-8-16t1-56b3.app/Contents/Java/hardware/teensy/avr/libraries/NativeEthernet 
    Using library FNET at version 0.1.3 in folder: /Applications/Teensyduino1-8-16t1-56b3.app/Contents/Java/hardware/teensy/avr/libraries/FNET 
    Using library myProcessorStuff in folder: /Users/michaelrunyan/Documents/Arduino/libraries/myProcessorStuff (legacy)
    Using library LittleFS at version 1.0.0 in folder: /Applications/Teensyduino1-8-16t1-56b3.app/Contents/Java/hardware/teensy/avr/libraries/LittleFS

  16. #16
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,569
    My ma might be more interested, but I thought, ok, never give up, and test if that gets fixed before I put work into and do a fix for (many) other things that not get merged

    ... TD misses https://www.arduino.cc/reference/en/...o/pulseinlong/

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,471
    I've added a placeholder src/ExFatLib/upcase.cpp file, so installs "on top of" older SdFat will avoid this problem.

    https://github.com/PaulStoffregen/Sd...f294e6243e9d52


    Arduino pulseInLong() is a very low priority, unlikely to be implemented anytime soon (if ever).

  18. #18
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,478
    This relates to the TD 1.56 b3 doing secure stuff on a Beta T_4.1:

    >> The Following is (typical confusing?) ANSWER at the bottom – I showed my work in getting through the problem: Works in the end but there is a bug.

    Paul, Did you get the better ‘LOCK’ stamp? Not seeing them listed on web yet. I can find my last beta T_4.0’s – but not the T_4.1? Was it RED stamped the same on the MCU? Seems I gave it the same two tone added markings and I can’t ID a last Beta T_4.1 from the ~10 T_4.1’s I find?

    The one I think it is has no LOCK stamp or underside ‘lock drawing’? And it Is giving this on running LockSecureMode and this isn’t the latest T_4.1 beta board ???:
    Set Lockable Teensy into secure mode
    Fail: Teensy has old serial number, before HAB support.
    It has the RED nail polish pattern I expect on a lockable Beta – including the WHITE under the red of the LAST one – but no RED stamp? I see that can be rubbed off on a 4.0 – so it seems that happened to this T_4.1.

    Running what I think was the last edited ‘INFO’ sketch version of PrimeTemp.ino ( with updated CSF not called PJRC ) not sure if this Fuses== tells anything?
     Also attached Loader Verbose of the programming.

    Verify secure code is running properly

    Pass: Bus Encryption Engine is active
    Pass: Encryption region starts at proper address
    Pass: Program data is entirely within encrypted region
    Pass: isEncrypt() is within encrypted region
    Pass: title_text[] is within encrypted region
    Pass: CSF is 48 bytes with HAB version 4.0
    NOTE: hab_version == 0x40307
    NOTE: hab_status == 0xF0
    Secure mode NOT SET :: Fuses == 0x97063708B018
    The Serial # on this unit is showing in Verbose as :: 9706370
     Any chance this ‘beta unit’ wasn’t made with the right serial number to pass:
    o if (serialnum >= 1086820) {
    I removed that code and it is now:
    Set Lockable Teensy into secure mode
    Success: Secure mode set
    > Odd because loader value of 9,706,370 IS somewhat larger than 1,086,820
     Seems the ‘LockSecureMode’ isn’t getting the serial# right? I had to REMOVE that code as edits for that number failed.
     With code edit – the number is not getting the *10 it needs as shown when edited to show value of serialnum
    o Set Lockable Teensy into secure mode
    o Fail: Teensy has old serial number, before HAB support.
    o serialnum==970637
     USING :: const uint32_t serialnum = HW_OCOTP_MAC0 & 0xFFFFFF;

    Going back to PrimeTemp.ino maybe it didn’t try uploading the .eHex on next upload?
    23:56:50.891 (loader): File "PrimeTemp.ino.hex". 50176 bytes
    23:56:50.901 (loader): set background IMG_ONLINE
    23:56:50.910 (reboot 116): Status: 1, 1, 1, 29, 2, 8, R:\Temp\arduino_build_98557\, PrimeTemp.ino.hex
    23:56:50.914 (loader): nxp_write: success
    23:56:50.920 (loader): HAB security error 3330E11E, can't access

    Did a NEW IDE upload and it worked – all of the Loader Verbose is in the attached WhatTeensy2.txt :: WhatTeensy2.txt
    Verify secure code is running properly

    Pass: Bus Encryption Engine is active
    Pass: Encryption region starts at proper address
    Pass: Program data is entirely within encrypted region
    Pass: isEncrypt() is within encrypted region
    Pass: title_text[] is within encrypted region
    Pass: CSF is 48 bytes with HAB version 4.0
    NOTE: hab_version == 0x40307
    NOTE: hab_status == 0xF0
    Secure mode IS set :: Fuses == 0x97063704C8B01A
    Also in that WhatTeensy2.txt you’ll see I loaded BlinkWithoutDelay – that was when the T_4.1 went ‘RED Blink’ on me trying to re-upload the sketch befor eit a second time and then refused to take any upload.

  19. #19
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,471
    To tell if Teensy Loader is using the HEX or EHEX file, look for these lines.

    When opening the HEX file:

    23:57:14.764 (loader): File "PrimeTemp.ino.hex" opened, but "PrimeTemp.ino.ehex" will actually be used

    Just before transmitting data:

    23:57:14.818 (loader): using encrypted ehex (required - secure mode is locked)
    23:57:14.850 (loader): begin operation


    Yes, some of the earliest lockable betas had serial numbers before the cut-off check. Those early betas also had minor bootloader bugs, particularly with false alarm red LED blinks. That's why I sent uploaded lockable boards with the final bootloader which fixes those minor but confusing bugs.

  20. #20
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,478
    Quote Originally Posted by PaulStoffregen View Post
    To tell if Teensy Loader is using the HEX or EHEX file, look for these lines.

    When opening the HEX file:

    23:57:14.764 (loader): File "PrimeTemp.ino.hex" opened, but "PrimeTemp.ino.ehex" will actually be used

    Just before transmitting data:

    23:57:14.818 (loader): using encrypted ehex (required - secure mode is locked)
    23:57:14.850 (loader): begin operation


    Yes, some of the earliest lockable betas had serial numbers before the cut-off check. Those early betas also had minor bootloader bugs, particularly with false alarm red LED blinks. That's why I sent uploaded lockable boards with the final bootloader which fixes those minor but confusing bugs.
    Must just be Beta confusion over unit ser# or device tracking ... perhaps on this end - but no other unit found fits the bill.

    Indeed after editing the provided INO to remove the Ser# check the unit was locked and requires .eHex
    Code:
    11:06:25.131 (loader): HAB locked secure mode
    ...
    11:06:25.963 (loader): File "mtp-test.ino.hex" opened, but "mtp-test.ino.ehex" will actually be used
    11:06:26.010 (loader): elf appears to be for Teensy 4.1 (IMXRT1062) (8126464 bytes)
    11:06:26.010 (loader): elf binary data matches hex file
    11:06:26.010 (loader): elf file is for Teensy 4.1 (IMXRT1062)
    11:06:26.010 (loader): using encrypted ehex (required - secure mode is locked)
    AFAIK:This was the latest last T_4.1 Lockable Beta unit received that was still unlocked when that process was tried and documented as noted.
    > seems it wasn't prepared as expected perhaps. I have many other T_4.1's it could be confused with - except it is lockable and was not locked before this instance as noted.
    > or Maybe ser# 9706370 says otherwise? But it is working as expected with the latest TD. And indeed that number should not pass the test - so not a *10 issue.
    --> that ser# is oddly sequential to this known older unit #9706380 - but that has the hand drawn 'lock' on the bottom that the 9706370 unit does not have.

    Two locked T_4.0's do show passing Ser#'s : 10883550 and 10883540

  21. #21
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,478
    Paul: that has to be the newest beta lockable unit with the latest bootloader. Now that it is locked it ignores the 15s [-/+ 2 secs] Restore - no blink and releasing at 15sec does nothing.

    And from my notes I put pins in it before doing QSPI - so I went back with PSRAM's because they were easier to solder over the header rails.

    Maybe just a snafu on the Serial number?

    But, it proves out the rejection code for Serial # ... which I bypassed to work.

  22. #22
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,471
    Yup, the final 1.07 bootloader ignores 15 sec button press when locked in secure mode. The early beta bootloaders, which went to only 5 people, will try (and fail badly) to do the 15 sec restore in secure mode.

    The serial number check when locking security is meant to protect the relatively small number of custom boards made with early version of the T4 bootloader chip. Those boards are all lockable, because they didn't go through the PJRC test process which sets the fuse to prevent changes to boot settings. But the early T4 bootloader chips don't handle secure mode properly, so setting secure mode could potentially brick those boards. The chips we have now do handle secure mode. That number in the code is near the point where we started shipping the new chips which are safe to use with secure mode.

    Even if the serial number check is deleted, you can't lock secure mode on a standard Teensy because the fuses are configured to prohibit any changes to the boot settings. I put a lot of work into standard Teensy to prevent it from being brickable, and with lockable Teensy I tried to build in as much safety as I could to the 3 auto-generated sketches.

  23. #23
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,478
    Good to have that resolved. I went through about 10 T_4.1's multiple times - and searched for another that didn't exist - trying to make sure I wasn't missing the one that was right in front of me ... with that silly ser #.

    So great work keeping the dev work straight to work right in the end. Not just the bits inside - but those generic looking chips and boards that even when marked up tend to shed them.

  24. #24
    Senior Member
    Join Date
    Mar 2017
    Location
    Oakland, CA, USA
    Posts
    387
    Will the final 1.56 release update the bootloader on older Teensy 4’s and 3’s to 1.07? How can I tell which bootloader version I have?

    Update: I did notice this in the beta 3 notes: Teensy Loader updates Teensy 4.0, 4.1, MicroMod to bootloader 1.07

  25. #25
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,478
    Quote Originally Posted by shawn View Post
    Will the final 1.56 release update the bootloader on older Teensy 4’s and 3’s to 1.07? How can I tell which bootloader version I have?

    Update: I did notice this in the beta 3 notes: Teensy Loader updates Teensy 4.0, 4.1, MicroMod to bootloader 1.07
    Yes, TD 1.56 beta 3 is currently doing that.

    The change to 'Production' versions of a 1062 from post #3:
    Quote Originally Posted by PaulStoffregen View Post
    Should probably mention, the main benefit from the 1.07 update is LittleFS_Program will persist across code uploads, if the filesystem size is within these limits.

    Code:
    Board            Normal  Secure
    -----            ------  ------
    Teensy 4.0       1472K   960K
    Teensy 4.1       7424K   6912K  
    MicroMod Teensy  15616K  15104K
    1.07 should also solve the long initial lag at the beginning of uploading when Teensy 4.1 & MicroMod were previously written with a very large program.

Posting Permissions

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