Teensyduino 1.56 Beta #3

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
Here is a third beta test for Teensyduino 1.56.


Linux 32 bit:
https://www.pjrc.com/teensy/td_156-beta3/TeensyduinoInstall.linux32

Linux 64 bit:
https://www.pjrc.com/teensy/td_156-beta3/TeensyduinoInstall.linux64

Linux ARM:
https://www.pjrc.com/teensy/td_156-beta3/TeensyduinoInstall.linuxarm

Linux ARM64:
https://www.pjrc.com/teensy/td_156-beta3/TeensyduinoInstall.linuxaarch64

MacOS 10.10 to 10.15:
https://www.pjrc.com/teensy/td_156-beta3/Teensyduino_MacOS_Catalina.zip

MacOS 10.8 to 10.14:
https://www.pjrc.com/teensy/td_156-beta3/TeensyduinoInstall.dmg

Windows:
https://www.pjrc.com/teensy/td_156-beta3/TeensyduinoInstall.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
 
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.
 
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.
 
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
 
PaulStoffregen said:
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.
Click to expand...

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
 
bicycleguy said:
Not sure if me or FreqCount() is still not able to have its interval changed and expect good output in the first cycle.
Click to expand...

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
 
joepasquariello said:
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.

...
Click to expand...

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
 
@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
 
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
 
KurtE said:
but SDFat does not build.
Click to expand...

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...
 
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...
 
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
 
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 :: View attachment 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.
 
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.
 
PaulStoffregen said:
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.
Click to expand...

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
 
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.
 
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.
 
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.
 
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
 
shawn said:
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
Click to expand...

Yes, TD 1.56 beta 3 is currently doing that.

The change to 'Production' versions of a 1062 from post #3:
PaulStoffregen said:
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.
Click to expand...
 
Status
Not open for further replies.
Back
Top