Teensyduino 1.54 Beta #7

[Paul]

Here is a seventh beta test for Teensyduino 1.54.

Digital signatures have changed on Windows. Edge/IE might show a dire warning.
Please click the site is safe button.

Install into a clean copy of Arduino if you previously installed beta3 or beta4.

The USBHost_t36 change is likely to break some drivers...


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

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

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

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

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

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

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


Changes since Teensyduino 1.54-beta6:

Windows digital signature changed - old cert expired
Improved memory usage info for Teensy 4.0 & 4.1
Audio input PDM on Teensy 4.x (Mark T)
Audio ladder filter (Richard van Hoesel)
Audio fixes on Teensy LC (Frank B)
USBHost_t36 improve MIDI transmit speed
Fix Teensy Loader slow startup on Ubuntu 20.04
Update Linux udev rules - NOTE: filename changed!
Fix Teensy Loader excessive CPU use on Linux
SD typecast to SdFat reference, for libs like MD_MIDIFile
SdFat fix corrupted filename from getName()
Wire Scanner update known chips
Wire initializion code in flash memory only (Frank B)
Fix USB audio volume range (Frank B)
Improve individual audio object CPU usage info
Fix EEPROM on Teensy 4.x when compiled with -Os (Frank B)
Fix Arduino IDE Java IOException on quit

[PaulStoffregen]

Two questions for everyone using Windows

1: Is Teensy Loader chewing up CPU while idle, like it was on Linux?

2: How difficult is the download & install (before Microsoft's servers re-learn PJRC is safe)?

[kd5rxt-mark]

@PaulStoffregen:

Just installed on Windows10pro 64-bit. Received a warning that the app was unrecognized, but simply clicked on "Run anyway". No problems w/ installation. With Arduino not running, Windows Task Manager shows "teensy.exe" at 0%, & rose to 1.5% when Arduino made use of it during a build.

Did receive the following (previously unseen) warnings (building w/ Smallest Code optimization):

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\output_i2s.cpp:340:55: warning: default argument given for parameter 1 of 'static void AudioOutputI2S::config_i2s(bool)' [-fpermissive]
 void AudioOutputI2S::config_i2s(bool only_bclk = false)
                                                       ^
In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\output_i2s.cpp:28:0:
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\output_i2s.h:55:14: note: previous specification in 'static void AudioOutputI2S::config_i2s(bool)' here
  static void config_i2s(bool only_bclk = false);
              ^

And I really like the new usage reports !!

Memory Usage on Teensy 4.0:
  FLASH: code:243852, data:37764, headers:7212   free for files:1742788
   RAM1: code:229376, variables:255008   free for local variables:39904
   RAM2: variables:202880  free for malloc/new:321408

Mark J Culross
KD5RXT

[defragster]

This new up to date Win 10 Pro machine gave this clicking the '...':


Keep ... Then it gave this after clicking the '^' option carat:


Keep Anyway ... Then this usual prompt because I had not done 'Properties Unblock' for the file and 'more info':


Run Anyway ... Installed and completed fine.

[Frank B]

I think two blank lines and a little formatting would make it clearer.

"C:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.elf" "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.hex"
"C:\\Arduino\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.lst" "C:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -d -S -C "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.elf"
"C:\\Arduino\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.sym" "C:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.elf"
"C:\\Arduino\\hardware\\teensy/../tools/teensy_post_compile" -file=I2S_test.ino "-path=C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build" "-tools=C:\\Arduino\\hardware\\teensy/../tools/" -board=TEENSY40
Opening Teensy Loader...
"C:\\Arduino\\hardware\\teensy/../tools/teensy_size" "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.elf"
Memory Usage on Teensy 4.0:
  FLASH: code:57116, data:6476, headers:7212   free for files:1960812
   RAM1: code:65536, variables:17088   free for local variables:441664
   RAM2: variables:17600  free for malloc/new:506688
Bibliothek Audio in Version 1.3 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\Audio  wird verwendet
Bibliothek SPI in Version 1.0 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\SPI  wird verwendet
Bibliothek SD in Version 2.0.0 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\SD  wird verwendet
Bibliothek SdFat in Version 2.0.5-beta.1 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\SdFat  wird verwendet
Bibliothek SerialFlash in Version 0.5 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\SerialFlash  wird verwendet
Bibliothek Wire in Version 1.0 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\Wire  wird verwendet
Bibliothek PU2CLR_SI4735 in Version 2.0.6 im Ordner: C:\Users\Frank\Documents\Arduino\libraries\PU2CLR_SI4735  wird verwendet

vs.

"C:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy"  -O ihex -R .eeprom  "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.elf"   "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.hex"
"C:\\Arduino\\hardware\\teensy/../tools/stdout_redirect"   "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.lst"  "C:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump"  -d -S -C  "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.elf"
"C:\\Arduino\\hardware\\teensy/../tools/stdout_redirect"   "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.sym"  "C:\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump"  -t -C  "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.elf"
"C:\\Arduino\\hardware\\teensy/../tools/teensy_post_compile"  -file=I2S_test.ino  "-path=C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build"  "-tools=C:\\Arduino\\hardware\\teensy/../tools/" -board=TEENSY40
Opening Teensy Loader...
"C:\\Arduino\\hardware\\teensy/../tools/teensy_size"   "C:\\Users\\Frank\\Documents\\Arduino\\_____T4\\Si4735\\I2S_test\\build/I2S_test.ino.elf"

  FLASH:      code: 57116,      data:  6476, headers:  7212   free for files:           1960812
   RAM1:      code: 65536, variables: 17088                   free for local variables:  441664
   RAM2: variables: 17600                                     free for malloc/new:       506688

Bibliothek Audio in Version 1.3 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\Audio  wird verwendet
Bibliothek SPI in Version 1.0 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\SPI  wird verwendet
Bibliothek SD in Version 2.0.0 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\SD  wird verwendet
Bibliothek SdFat in Version 2.0.5-beta.1 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\SdFat  wird verwendet
Bibliothek SerialFlash in Version 0.5 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\SerialFlash  wird verwendet
Bibliothek Wire in Version 1.0 im Ordner: C:\Arduino\hardware\teensy\avr\libraries\Wire  wird verwendet
Bibliothek PU2CLR_SI4735 in Version 2.0.6 im Ordner: C:\Users\Frank\Documents\Arduino\libraries\PU2CLR_SI4735  wird verwendet

The line "Memory Usage on Teensy 4.0:"

is not needed.

[Frank B]

also, for flash, perhaps just add the numbers for "data" and "headers"... the information "headers" is not that useful, i think.
Also, "free for files" is not correct. is can be used for code and data , too - same for "free for local variables", i'd just omit the text, and print "free:" or "unused" instead:
Also, eeprom is missing perhaps(?)

  FLASH:      code: 57116,      data: 14000 free: 1960812
 EEPROM:      size: 0
   RAM1:      code: 65536, variables: 17088 free:  441664
   RAM2: variables: 17600                   free:  506688

Edit: Variables are data, and to make it an general information tool, something like this would be useful:

  Teensy 3.6, F_CPU 180MHz, F_BUS 75MHz, F_PLL: foo.. USB: Serial+Midi
 EEPROM:      size: 0
  FLASH:      code: 57116, data: 14000 free: 1960812
   RAM1:      code: 65536, data: 17088 free:  441664
   RAM2:                   data: 17600 free:  506688

If Audio is used, it could print the number of audio blocks... the audio lib could add a section to detect this.
If audio blocks is <2, print an red error.

for messages copied to the forum, this would be great and easier to find.

[defragster]

All seems well with the Beta 7 - ran the IDE some to good effect. Then back to in editor command line and all is well.

Two questions for everyone using Windows

1: Is Teensy Loader chewing up CPU while idle, like it was on Linux?

2: How difficult is the download & install (before Microsoft's servers re-learn PJRC is safe)?

re #1 :: Teensy.exe cycling between 0.0%. 0.1% and rare 0.2% of CPU usage on Windows 10 here. And it starts fast.

re #2 : see p#4 above

For Beta #8:: - notes on github ...
LFSIntegrity and the LittleFS didn't get updated before release in Beta 7 and Beta 6 wasn't clean - put in a PR #8 for those.

Also FrankB HardFaults pr#535 - need to edit that into startup.c again.

[Frank B]

No offense, really! - but usually "no response" or "no statement" means that something is unlikely to be adopted So, I don't spend more time for this. The weather is good - I enjoy the sun.
In fact, I really don't care. As long as _something_ comes!
(edit: I think my first suggestion was in 2015)

It doesn't have to be my suggestion.

In sum, a useful fault-printout has the potiential to save countless hours auf debugging.. No all users a good programmers.

Again, no offense.

[defragster]

@Paul - for reference on this new Win 10 machine that doesn't like the NEW 2021 certificate I just downloaded this file with NO WARNING from browser or the system or BLOCKING - even the EXE runs without 'UNBLOCK' with the old and now expired 5 year old Certificate - just the UAE confirmation before starting :: pjrc.com/teensy/td_153/TeensyduinoInstall.exe

No offense ...

Yeah - doesn't pay to be offended. This beta dropped fast - there was a post about testing the Windows signing on the Linux loader slow start ... then there was a release. Somehow MSFT isn't respecting the newly made PJRC certification it seems - at least on this machine where maybe I didn't disable some extreme verify of downloads.

There is still work ahead and more beta time/releases expected AFAIK if MTP/MSC/USBHost etc are to get made release ready ... and more work on LittleFS ...

Really hoping for the HardFault inclusion 'option' as it was something I was trying to work out since T_3.6 days with debug_tt - this doesn't help there (yet?) - but the use of the T_4.x's RAM2 for fault recording and restart was a great leap of an idea! Avoids the issue with instant notify when the processor just faulted. Faults are not common enough for general requests - but when they happen having a restart notify instead of a 'hang' is fabulous. With pending added complexity on next Teensy 1170 it seems this might even be more useful and perhaps more common as things develop.

[mjs513]

@Paul
Just downloaded Beta7 and pretty much saw what @defragster saw in post #4. I did one additional step. Before telling defender to Keep file I clicked on REPORT THIS FILE AS SAFE:

Once you click on report file you get presented with a simple edge form to fill out:

I filled it out and submitted. Everyone should probably do that to let MS know its safe. Did notice that it has the option for the owner of the site - think @defragster mentioned this before that maybe you want to fill out.

[mjs513]

Did notice the new memory usage in both Verbose and non-verbose. In verbose I am seeing this additional info:

Linking everything together...
"F:\\arduino-1.8.13-beta6\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--print-memory-usage,--gc-sections,--relax "-TF:\\arduino-1.8.13-beta6\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062_t41.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776/CommandStation-EX.ino.elf" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\sketch\\CommandStation-EX.ino.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\CommandDistributor.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\DCC.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\DCCEXParser.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\DCCWaveform.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\EEStore.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\EthernetInterface.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\LCDDisplay.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\MemStream.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\MotorDriver.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\Outputs.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\PWMServoDriver.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\RingStream.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\Sensors.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\StringFormatter.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\Timer.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\Turnouts.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\WiThrottle.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\WifiInboundHandler.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\WifiInterface.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\CommandStation-EX\\freeMemory.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\Wire\\Wire.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\Wire\\WireIMXRT.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\Wire\\WireKinetis.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\Wire\\utility\\twi.c.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776\\libraries\\EEPROM\\EEPROM.cpp.o" "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776/..\\arduino_cache_794816\\core\\core_6b6c10b1932602ba3169f4a248d78bec.a" "-LC:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776" -larm_cortexM7lfsp_math -lm -lstdc++
Memory region         Used Size  Region Size  %age Used
            ITCM:       40556 B       512 KB      7.74%
            DTCM:       17088 B       512 KB      3.26%
             RAM:       12384 B       512 KB      2.36%
           FLASH:       57380 B      7936 KB      0.71%
            ERAM:          0 GB        16 MB      0.00%

and in both modes I get also this:

Memory Usage on Teensy 4.1:
  FLASH: code:43444, data:6716, headers:7212   free for files:8069092
   RAM1: code:65536, variables:17088   free for local variables:441664
   RAM2: variables:12384  free for malloc/new:511904

I think I would agree with Frank about adding a newline or two - see post #5

[defragster]

I also reported the download site as safe again in the process. There was a pre release test version I did that on as well the other day - and did that again this time when I tested to see if that version might be accepted - but it was treated the same.

The test safe 'I think this is a safe website' - so that suggests it isn't verifying the certificate or the exe but the source site. Which is odd given the noted TD 1.53 from the same server but different folder still works - as have all the prior downloads from that site that used the prior certificate.

Seems like the certificate - which has valid looking entries (new dates and details) and notes somehow isn't passing their test? Maybe MSFT needs to pass out a secure database of valid certificates?


Note: I have gotten an Insider advance build of Windows on this machine the 21H1 build to be released sometime in first Half of 2021- but since you are seeing the same that shouldn't be an issue.

[mjs513]

Two questions for everyone using Windows

1: Is Teensy Loader chewing up CPU while idle, like it was on Linux?

2: How difficult is the download & install (before Microsoft's servers re-learn PJRC is safe)?

Item #1: teensy.exe is staying around 0% with periodic jumps to 0.1%. Java Platform SE Binary goes between 0% and 0.7%

Item #2: see post #10

A couple things for Beta8:
1. USBHS_USBCMD_ITC(0) in usbhost_t36 ehci.cpp really needs to be changed to USBHS_USBCMD_ITC(1). When I tested at itc=0 was having some issues with Bluetooth connections and MSC connections.
2. Really would like to see Frank B's hardfault PR incorporated as @defragster mentioned.
3. Would it possible to add in MTP+Serial in boards,txt and usb_desc.h. Getting tired of keep adding that.

[defragster]

Did notice the new memory usage in both Verbose and non-verbose. In verbose I am seeing this additional info:

Linking everything together...
"F:\\arduino-1.8.13-beta6\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--print-memory-usage,--gc-sections,--relax "-TF:\\arduino-1.8.13-beta6\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062_t41.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o ...
"C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776/..\\arduino_cache_794816\\core\\core_6b6c10b1932602ba3169f4a248d78bec.a" "-LC:\\Users\\Merli\\AppData\\Local\\Temp\\arduino_build_524776" -larm_cortexM7lfsp_math -lm -lstdc++
Memory region         Used Size  Region Size  %age Used
            ITCM:       40556 B       512 KB      7.74%
            DTCM:       17088 B       512 KB      3.26%
             RAM:       12384 B       512 KB      2.36%
           FLASH:       57380 B      7936 KB      0.71%
            ERAM:          0 GB        16 MB      0.00%

and in both modes I get also this:

I think I would agree with Frank about adding a newline or two - see post #5

That 'verbose info looks like the linker output as it parses the ELF with this line added to build.txt?

## teensy41.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062_t41.ld"

That was in my .local. copy and now commented out. It appears like this when uncommented:

Memory region         Used Size  Region Size  %age Used
            ITCM:       70572 B       512 KB     13.46%
            DTCM:       21184 B       512 KB      4.04%
             RAM:       12448 B       512 KB      2.37%
           FLASH:       95396 B      7936 KB      1.17%
            ERAM:          0 GB        16 MB      0.00%

[mjs513]

@defraster
Don't remember ever having a boards.local.txt file there before. Anyway that is in there now for all Teensy's not the the T4.1

[defragster]

Item #1: teensy.exe is staying around 0% with periodic jumps to 0.1%. Java Platform SE Binary goes between 0% and 0.7%

Item #2: see post #10

A couple things for Beta8:
1. USBHS_USBCMD_ITC(0) in usbhost_t36 ehci.cpp really needs to be changed to USBHS_USBCMD_ITC(1). When I tested at itc=0 was having some issues with Bluetooth connections and MSC connections.
2. Really would like to see Frank B's hardfault PR incorporated as @defragster mentioned.
3. Would it possible to add in MTP+Serial in boards,txt and usb_desc.h. Getting tired of keep adding that.

@mjs513 - if these lines are in this file (thanks FrankB) : ...\hardware\teensy\avr\boards.local.txt

teensy41.menu.usb.mtpserial=MTP Disk Serial (Experimental)
teensy41.menu.usb.mtpserial.build.usbtype=USB_MTPDISK_SERIAL

teensy40.menu.usb.mtpserial=MTP Disk Serial (Experimental)
teensy40.menu.usb.mtpserial.build.usbtype=USB_MTPDISK_SERIAL

teensy36.menu.usb.mtpserial=MTP Disk SERIAL (Experimental)
teensy36.menu.usb.mtpserial.build.usbtype=USB_MTPDISK_SERIAL

teensy35.menu.usb.mtpserial=MTP Disk SERIAL (Experimental)
teensy35.menu.usb.mtpserial.build.usbtype=USB_MTPDISK_SERIAL

They persist across installs - that is where the above "--print-memory-usage" is on this machine.

@mjs513 - if you get a chance to view the state of https://github.com/PaulStoffregen/LittleFS/pull/8 from github.com/Defragster/LittleFS that should match your NAND and other work with the eearly exit blockIsBlank() edit and the updated LFSIntegrity. The LITTLEFS fork had to be recreated and it gave grief about the prior merge and made me verify conflicts for the debug print removal and ??? - and the diff review is no CodeCompare - which should work if you get both side by side.

[defragster]

@defraster
Don't remember ever having a boards.local.txt file there before. Anyway that is in there now for all Teensy's not the the T4.1

That is a hack that doesn't help the desc.h issue. It came up a beta or so back and it handy. Anything there adds to or overrides anything in the base boards.txt. Offline about now - will look for USBHost/MSC/MTP notes and help asap

[mjs513]

@defragster
Nope the those lines are in my version. Note - never created a build.local.txt file that I remember but then who knows may have did that a long time ago and just got use to it being there. Going to add the MTP lines in but you need the mods that @KurtE did for the usb_desc.h.

@mjs513 - if you get a chance to view the state of https://github.com/PaulStoffregen/LittleFS/pull/8 from github.com/Defragster/LittleFS that should match your NAND and other work with the eearly exit blockIsBlank() edit and the updated LFSIntegrity. The LITTLEFS fork had to be recreated and it gave grief about the prior merge and made me verify conflicts for the debug print removal and ??? - and the diff review is no CodeCompare - which should work if you get both side by side.

Yes I did a CodeCompare on the NAND to make sure it was the as what I had and they were. Believe I posted on the LittleFS thread. However, never spent much time checking the new BlockIsBLank changes. Got sidetracked with a few other things with the T4.1/

[PaulStoffregen]

Yeah, this beta was prompted by changes to the builds on all 3 operating systems.

On Windows, we were forced to get a new code signing cert. They rubber stamp reissue the old one if you renew within 39 months. The idea is the maximum allowed term is 3 years, so you get a 3 month grace period to renew without going through the whole identity check process (but of course they still charge the same either way). Trouble is, they used to allow up to 5 years. PJRC's old cert, which had been rubber stamp renewed a few times, was renewed only months before they changed the policy to allow only 3 years. So we were about 1.5 years past their new policy deadline to auto-renew. Now we have to start over on Microsoft SmartScreen "reputation". They do offer a *much* more expensive cert which SmartScreen trusts immediately. But it comes with restrictions, mainly a proprietary hardware dongle. Since I build all the Windows software by cross compiling from Linux, a Windows-only dongle isn't an option.

On Linux, we have 3 big changes. The udev rules were updated (fixes HID serial emulation access), Teensy Loader now links against GTK3 instead of GTK2 (solves the startup delay on Ubuntu 20.04.2), and the method Teensy Loader uses to talk to libudev1 was rewritten (greatly reduces idle CPU usage). Fortunately, GTK3 seems to be pretty well supported on all modern Linux systems, all the way back to Ubuntu 14.04, which is also the oldest supported Linux because we depend on libudev1 (older had libudev0 or hotplug).

On Macintosh, I use a convoluted and fragile build system with 3 different macs. One of those machines was updated to Mojave for security reasons, which broke the digital signature process for pre-Catalina systems. Adding the new size utility also required updating my build scripts for Catalina & Big Sur. It took a few tries to get it to pass Apple's notarization process. PJRC's support for old macs is really on borrowed time. Sooner or later one of the old machines I use is going to break, either physically or from some incompatible software update I can't work around. Our cert from Apple also expires in just under 2 years...

Normally these betas are mostly driven by changes to the Teensy-side code. There are a number of things pending, including the hard fault stuff which indeed I haven't commented on yet, and several improvements I wanted to make in the audio library before publishing this beta. But with so many things changed on the PC/Mac side, I really wanted to push this out quickly. All this PC-side stuff happened only in the last 2 weeks (which is part of the reason I've not reviewed things with long-term ramifications like the hard fault handler). If there are problems on Windows, Linux or Macs, it'll be much easier to fix now. That's why I rushed this beta without reviewing and merging more Teensy-side code as I normally do.

Please, I hope you'll install and run this beta. Watch for any problems is has on your PC or Mac. That's the main focus of this beta.

[Frank B]

@Paul
Just downloaded Beta7 and pretty much saw what @defragster saw in post #4. I did one additional step. Before telling defender to Keep file I clicked on REPORT THIS FILE AS SAFE:

Once you click on report file you get presented with a simple edge form to fill out:

I filled it out and submitted. Everyone should probably do that to let MS know its safe. Did notice that it has the option for the owner of the site - think @defragster mentioned this before that maybe you want to fill out.

Done that too.
Had to use the "Edge" Browser .... I never use that
Thanks, MJS.

[defragster]

Just poking at the downloaded EXE I got to a dialog - Install Certificate on Machine (versus user) ...

Hit the download again and - same grief.

So the SmartScreen doesn't seem to ask the machine if the cert is valid ... apparently just goes ' "on Microsoft SmartScreen " reputation'. Which as noted as odd since the user verify is of the 'site' that is unchanged from the working TD 1.53 release EXE.


Will be interested to hear about future for HardFault addition. It seems well done and functional ... and something I've been angling to do for years. The dumb ESP's store a whole stack dump of useful info.

[Frank B]

Yup, I tried, but could'nt get more usable data to print.
At least it prints that something bad happened and what kind of problem it was. With a bit digging, it is possible to find where it was, because it prints the address.

Enabling exceptions might help... did not try that.
It would need more Flash (and RAM?)

Yes, the ESP prints way more info - by using their external "Exception decoder" tool you'll see the problem immediately.
AND it has watchdogs everwhere in the core, which is very useful, especially with an RTOS.

[mjs513]

Ok here is one for you all

Out of curiosity I just downloaded it again but used Firefox. No issues with defender and my Norton pop-up came up and said it was a safe file. I added that rule a long time ago.

Now - i went into defender and to check settings and it said rules were managed by Norton. Then I looked at what Norton was reporting and it was looking at a file download name other than TeensyDuino something to the effect of download######.exe so Norton was reporting an issue. But didn't run into that with Firefox.

[defragster]

Odd ...

Maybe https://sectigo.com/cps-repository hasn't reported the cert details to MSFT yet?

I see these unfilled filed looking at the exe?:

[PaulStoffregen]

I see these unfilled filed looking at the exe?:

Pretty sure that's on me. I've never bothered to put metadata beyond the bare minimum into the resource file. It only has the program's icon and an XML file that prevents the "This program might not have installed correctly" message (which has absolutely nothing to do with how the program installed).

All the stuff from Sectigo / Comodo will be under the Digital Signatures tab, and probably only if you click the button to view the cert.

Even then, I'm pretty sure Sectigo never sends anything to Microsoft about individual certs. That's not how the system works (or at least my understanding of it). Microsoft puts their own public key in Windows. Then when Microsoft wants to allow a company like Sectigo to issue certificates, Sectigo sends their public key to Microsoft and Microsoft uses their private key to sign a cert saying Microsoft trusts Sectigo. Then when PJRC wants to become trusted by Windows, we send our public key (and $80/year) to Sectigo. Sectigo uses their private key and their cert from Microsoft to sign a cert saying they trust PJRC. Then when I build the software, I use PJRC's private key and the cert from Sectigo to say PJRC trusts the software. Microsoft doesn't need any info about PJRC from Sectigo. Windows checks PJRC's signature and sees it's has a cert from Sectigo. Then it check's Sectigo's cert to verify it was signed by Microsoft (or by yet another intermediary between them). If there is a chain of signatures & certs which ultimately lead back to Microsoft's signature, then the digital signature check passes. It's all built on top of delegating trust with digital signatures using asymmetric encryption, so there's no need to register who is trusted with Microsoft. Checking doesn't require any internet communication, only public key encryption to check each signature until one ultimately ends up as Microsoft's.

But the OV level verification Sectigo does is pretty weak. It could easily be faked by any common criminal. So it makes sense Microsoft created SmartScreen which collects feedback from end users to build up a database of which identities are actually trustworthy. But until you download the software and Windows "phones home" to Microsoft, they've probably never heard of PJRC.