Teensyduino 1.56 Beta #1

Status
Not open for further replies.

Paul

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


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

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

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

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

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

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

Windows:
https://www.pjrc.com/teensy/td_156-beta1/TeensyduinoInstall.exe


Changes since Teensyduino 1.55:

Fix serial monitor stall on Windows
Fix upload failure to locked Teensy 4 if button pressed
FS.h support file create and modify time
SD support file create and modify time
SD automatically uses RTC
LittleFS support file create and modify time
LittleFS automatically uses RTC
Add makeTime, breakTime, DateTimeFields
Fix serial monitor regression with MTP on Linux
Fix digitalPinHasPWM for higher pin numbers on Teensy 4
MTP configure event endpoint on Teensy 4
 
Downloaded and installed Win 11 over prior 1.8.16 w/TD 1.55.

Only issue was a JAVA...CORES file orphaned alone down in TaskMan 'Background processes' after IDE/Loader closed.

First build of lps.ino shows promise for the good.

<edit> : Confirm Build was fixed for "Ctrl+Alt+S" 'Export compiled binary' copied .hex and .ehax to Sketch folder.
 
Seems that ran about three hours on a T_4.1 (since prior post).

Had to close t_SerMon once as it was showing nothing but fitful garbage.

Then reopened t_sermon with IDE button and it seems to have kept running then?
Code:
...
count=3405760583, lines/sec=579057
count=3405760584, lines/sec=579057
...

Wasn't watching it until just now trying to upload a new sketch when that was captured and then closed.

As far as the first 'run' after upload - it showed garbage quickly then proper output - then dug into a hole showing garbage? Not sure if the garbage printing might have caused grief?

Odd thing it starts with LOW lines/sec numbers - then creeps higher?
 
Beta Locked T_4.1 - posted here Teensyduino-File-System-Integration-including-MTP-and-MSC

Three other .eHex sketches built and uploaded ... No Issues.

Code:
Pinned up new T_4.1_Lb. Added 1Gb NAND and 8MB PSRAM and USB_Host headers.

>> LittleFS to PSRAM works! :: C:\T_Drive\Arduino_1.8.16_155\hardware\teensy\avr\ libraries\LittleFS\examples\Integrity\PSRAM\PSRAM.ino
  -> 23:59:09.046 (loader): File "PSRAM.ino.hex" opened, but "PSRAM.ino.ehex" will actually be used
>> LittleFS to NAND works! :: C:\T_Drive\Arduino_1.8.16_155\hardware\teensy\avr\ libraries\LittleFS\examples\Integrity\QSPI\QSPI.ino / TEST_QSPI_NAND
  -> 00:02:02.359 (loader): File "QSPI.ino.hex" opened, but "QSPI.ino.ehex" will actually be used

Long DIR of a read only 16GB Flash drive with Windows 10 install sources and other files - 4,090 lines of output.
Truncated :: C:\T_Drive\tCode\libraries\UsbMscFat\examples\list filesUSB\listfilesUSB.ino (@mjs513 ZIP)
  -> 23:10:55.394 (loader): File "listfilesUSB.ino.hex" opened, but "listfilesUSB.ino.ehex" will actually be used
> not actually all pinned - just 2 QSPI and USB_Host
 
@Paul got a FLASHING Red LED pattern { 9 Blink, Pause, ... repeat } on T_4.1 Not yet Locked Beta 1.07 board:

-> Using TyCommander for sermon - it has a '-delegate' option to take Serial Offline and trigger bootloader which alerts T_Loader to upload the IDE Command line builder passed sketch.
-->> This is the Normal way SublimeText editor is used with TSET, now that integrating TyComm into IDE won't work for upload

Well TyComm also logs the names of HEX files, and has an option ( that works on PRE 1.07 bootloaders ) {to upload prior HEX files}

On the 1.07 bootloader it reports in its log:
Permission denied for device '\\.\COM37'
[upload@9706430-Teensy] Permission denied for device '\\.\COM37'
Permission denied for device '\\.\COM37'
[upload@9706430-Teensy] I/O error while writing to '\\.\HID#VID_16C0&PID_0478#8&295A2D2B&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}'

Not surprising - as it cannot perform an upload to a 1.07 { <edit> when running like this with Loader teensy.exe open }. This is reproducible.

As far as Teensy Loader. It is sitting in Auto mode, below is the last update shown in Verbose. I assume it saw TyComm at work and loaded the last sketch it knew about and took over from TyComm.

However - the following looks like a normal reprogramming, It takes a Button to excite TLoader to do an upload.
> And a USB Power OFF/ON returns to the Red LED blink ... twice ... This seems to be a persistent state?
> Doing a Button allows TLoader to upload the last valid sketch is was linked to
> Maybe that gives you a clue? My guess is there one more step needed after burning the Flash and a 'busybody' sermon ( TyComm or maybe t_sermon } is interceding leaving it in a persistent non booting state without that completed?
Code:
00:16:30.075 (loader): redraw, image 9
[B]00:39:32.512 (loader): encryption is optional, public key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
00:39:32.519 (loader): Device came online, code_size = 8126464
00:39:32.528 (loader): Board is: Teensy 4.1 (IMXRT1062), version 1.07
00:39:32.543 (loader): File "R:\temp\arduino_build_USB-Serial-Print-Speed-Test.ino\USB-Serial-Print-Speed-Test.ino.hex", 21504 bytes
[/B]00:39:32.551 (loader): File "R:\temp\arduino_build_USB-Serial-Print-Speed-Test.ino\USB-Serial-Print-Speed-Test.ino.ehex", 21504 bytes, and 4992 loader utility
00:39:32.558 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
00:39:32.566 (loader): File "USB-Serial-Print-Speed-Test.ino.hex". 21504 bytes, 0% used
00:39:32.577 (loader): File "USB-Serial-Print-Speed-Test.ino.hex" opened, but "USB-Serial-Print-Speed-Test.ino.ehex" will actually be used
00:39:32.607 (loader): set background IMG_ONLINE
00:39:32.620 (loader): File "R:\temp\arduino_build_USB-Serial-Print-Speed-Test.ino\USB-Serial-Print-Speed-Test.ino.hex", 21504 bytes
00:39:32.629 (loader): File "R:\temp\arduino_build_USB-Serial-Print-Speed-Test.ino\USB-Serial-Print-Speed-Test.ino.ehex", 21504 bytes, and 4992 loader utility
00:39:32.635 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
00:39:32.643 (loader): File "USB-Serial-Print-Speed-Test.ino.hex". 21504 bytes, 0% used
00:39:32.655 (loader): File "USB-Serial-Print-Speed-Test.ino.hex" opened, but "USB-Serial-Print-Speed-Test.ino.ehex" will actually be used
00:39:32.687 (loader): elf appears to be for Teensy 4.1 (IMXRT1062) (8126464 bytes)
00:39:32.694 (loader): elf binary data matches hex file
00:39:32.704 (loader): elf file is for Teensy 4.1 (IMXRT1062)
00:39:32.712 (loader): using encrypted ehex (optional - secure mode not yet locked)
00:39:32.744 (loader): begin operation
00:39:32.793 (loader): flash, block=0, bs=1024, auto=1
00:39:32.800 (loader): flash, block=1, bs=1024, auto=1
00:39:32.817 (loader): flash, block=2, bs=1024, auto=1
00:39:32.830 (loader): flash, block=3, bs=1024, auto=1
00:39:32.840 (loader): flash, block=4, bs=1024, auto=1
00:39:32.867 (loader): flash, block=5, bs=1024, auto=1
00:39:32.874 (loader): flash, block=6, bs=1024, auto=1
00:39:32.883 (loader): flash, block=7, bs=1024, auto=1
00:39:32.893 (loader): flash, block=8, bs=1024, auto=1
00:39:32.900 (loader): flash, block=9, bs=1024, auto=1
00:39:32.913 (loader): flash, block=10, bs=1024, auto=1
00:39:32.923 (loader): flash, block=11, bs=1024, auto=1
00:39:32.930 (loader): flash, block=12, bs=1024, auto=1
00:39:32.938 (loader): flash, block=13, bs=1024, auto=1
00:39:32.947 (loader): flash, block=14, bs=1024, auto=1
00:39:32.957 (loader): flash, block=15, bs=1024, auto=1
00:39:32.966 (loader): flash, block=16, bs=1024, auto=1
00:39:32.974 (loader): flash, block=17, bs=1024, auto=1
00:39:33.013 (loader): flash, block=18, bs=1024, auto=1
00:39:33.021 (loader): flash, block=19, bs=1024, auto=1
00:39:33.029 (loader): flash, block=20, bs=1024, auto=1
00:39:33.062 (loader): sending reboot
00:39:33.070 (loader): begin wait_until_offline
00:39:33.078 (loader): offline, waited 0
00:39:33.087 (loader): end operation, total time = 0.338 seconds
00:39:33.110 (loader): set background IMG_REBOOT_OK
00:39:33.166 (loader): redraw timer set, image 14 to show for 1200 ms
00:39:33.263 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
00:39:33.271 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
00:39:33.280 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
00:39:33.287 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
00:39:33.294 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
00:39:33.302 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
00:39:33.309 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
00:39:33.317 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
00:39:34.372 (loader): redraw, image 9

<EDIT>: Closing Teensy Loader and asking TyCommander to upload a .HEX WORKS, as the T_4.1 is not yet Locked to .eHex only. And that indicates prior .Hex upload process is unchanged in 1.07 from 1.06
 
Last edited:
SERMON NOTE:
Using TyCommander against : USB-Serial-Print-Speed-Test.ino

Shows it taking ~26% of this machines CPU, but only ~160 MB of RAM.

Looking at the TaskMan Graph of CORES it seems:
> 1 CORE at 100% - ALL DARK indicating KERNEL TIME
> 3 or 4 COREs at 50% - ALL DARK indicating KERNEL TIME
> 1 CORE at ~80% - HALF DARK indicating KERNEL TIME - and the upper half showing 'TyCommander APP' time?
** Note: TyComm logs to disk - set to the last 20MB - in this case a RAM DISK - so that RAM DISK could account for the Kernel overhead.
View attachment 25983
> CPU drop shown after TyComm GUI Serial deselected and it stopped monitoring.

Starting IDE and teensy_serialmon - it sits at 0% and JAVA shows ~12% CPU and ~340 MB of RAM

It seems that TyComm is a better Serial Monitor program for that fast output Lines per second sketch, though not perfect as it goes 'not responding' and sluggish UI, and also shows patches of 'buffer garbage'. So a T_4.1 throttling USB shows a Windows issue.
 
@Paul got a FLASHING Red LED pattern { 9 Blink, Pause, ... repeat } on T_4.1 Not yet Locked Beta 1.07 board:

-> Using TyCommander for sermon - it has a '-delegate' option to take Serial Offline and trigger bootloader which alerts T_Loader to upload the IDE Command line builder passed sketch.
-->> This is the Normal way SublimeText editor is used with TSET, now that integrating TyComm into IDE won't work for upload

Well TyComm also logs the names of HEX files, and has an option ( that works on PRE 1.07 bootloaders ) {to upload prior HEX files}

...

@Paul - Quickly tried repro of this on Locked beta T_4.0: Was left with Teensy.exe 'Out of Auto' mode.
> USB Power Off/On - returns to bootloader : Red LED Solid (fast PWM blink)

-> Close loader as Off/ON it comes up 'Non Booting' no Red LED.
-> Push button - Nothing
- Open Teensy.exe : Red LED On, and Teensy.exe goes into Auto Off - with active: Program and Reboot
- Hit Reboot and nothing
- Hit Program and program uploads to function.

>> This is 'like' behavior reported before IIRC - some Uploads require a Button press ???

> Seems a variant of the #9_Blink in p#5 ?

Sleep now ... Again this was Quick - but trying on 'unlocked' but key fused Beta T_4.0 this didn't show.
 
Soldered up one of the secure T4.1s this morning and added a PSRAM and Flash chip while I was at it. But I had a couple of strange things happen and not sure why. Note this was before writing the fuses.

1. As @defragster noted Blink was loaded on the T4.1 but came up as a normal T4.1 serial device so while the QSPI test sketch was compiling I opened TyCommander just to see what was running and saw some output guess this isn't going be the production norm (if this is confidential please delete immediately
Code:
High Assurance Boot API Test - Show Logged Events
-------------------------------------------------

Unique ID: 5D45D01C 151199D7
Publish Key Hash:  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
AES128 Key:   00000000 00000000 00000000 00000000
Fuse Lock: 40128103
  Boot Config is unlocked
  Misc Config is unlocked
  Mac Address is write locked
  GP1 is unlocked
  GP2 is unlocked
  GP3 is unlocked
  SW_GP1 is unlocked
  SW_GP2 write is unlocked
  SW_GP2 read is unlocked
Config: 0008B018
  Security is unlocked
  Region 0 key: SW GP2
  Region 1 key: SNVS master
Image Vector Table: (ref manual rev 2: 9.7.1.1, page 261)
  Header   432000D1
  Vector   60001429
  reserved 00000000
  DCD      00000000
  Bootdata 60001020
  Self     60001000
  CSF      60009C00
  reserved 00000000
Bootdata: (ref manual rev 2: 9.7.1.2, page 262)
  Start    60000000
  Length   0000A800
  Plugin   00000000
DCD: (ref manual rev 2: 9.7.2, page 262)
  No DCD (null)
CSF: (cst/docs/HAB4_API.pdf: 4.3, pages 23-42)
  TODO: parse and print CSF

HAB Version: 00040307
HAB Memory: 8192 bytes at 20200000

Failure!
 Failure: Invalid @ref csf in "hab_rvt.run_csf()"
 Failure: Invalid assertion in "hab_rvt.assert()"
  32 bytes at 60001000 not authenticated
 Failure: Invalid assertion in "hab_rvt.assert()"
  1 bytes at 60001020 not authenticated
 Failure: Invalid assertion in "hab_rvt.assert()"
  4 bytes at 60001429 not authenticated

Oh I did have to pusht PGM button - no adverse affects

and 2) got a windows warning on teensy_sermon that it wasn't trusted - been using all night and this morning before plugging in the new T4.1:
Capture.PNG

Ok now to secure and lock the chip - any issue with using the key that I already used for the T4 - really don't want to manage the keys during test :)
 
Soldered up one of the secure T4.1s this morning and added a PSRAM and Flash chip while I was at it. But I had a couple of strange things happen and not sure why. Note this was before writing the fuses.

1. As @defragster noted Blink was loaded on the T4.1 but came up as a normal T4.1 serial device so while the QSPI test sketch was compiling I opened TyCommander just to see what was running and saw some output guess this isn't going be the production norm (if this is confidential please delete immediately
Code:
High Assurance Boot API Test - Show Logged Events
...

Oh I did have to pusht PGM button - no adverse affects

and 2) got a windows warning on teensy_sermon that it wasn't trusted - been using all night and this morning before plugging in the new T4.1:
...

Ok now to secure and lock the chip - any issue with using the key that I already used for the T4 - really don't want to manage the keys during test :)

Good job on the soldering - was happy to see both worked here too. QSPI Flash LFS failed first run ... oops NAND not NOR :) - Phew

> Blink was 'not' loaded

Didn't see the bonus HAB Spew powering either one up here.

TeensyInstaller and all used parts were 'trusted' here, Win 11 and no Norton.

Same here - using single pem.key so single .eHex will be testable on same models. without having to manage or manipulate building.
 
PSRAM and QSPI flash on the bottom side of Teensy 4.1 are completely separate from the fuses and code security stuff.

Yes, on the latest round of beta boards I ran the HAB test program and didn't load the usual LED blink. Indeed it does mention the names of a couple "reserved" things, which were in the original Rev 0 08/2018 reference manual on NXP's website when I wrote the earliest version of that program (so long ago... before dresden-fx helped with the IVT issue that was preventing HAB from passing).

Yes, simplest to use the same key.pem on all boards. No need to test different keys.

Looks like I might need to start signing the utility exe files?

I'm having a hard time parsing much info from msg 2-7....
 
Right now I am running the USB_SERIAL_PRINT test. Ran on before and still running the after locking. Did see some corrupted data (spew) but quickly cleared up and notice the speed increased dramatically after the spew. But have not seen any slow downs yet and running for about 30minutes. Running in a range 500k to 850k lines/sec. Any recommendations on how long to let it run?

UPDATE:
Ok just froze sermonitor and cleared itself. Closed the IDE and it immediately restarted. So just confirmed what Tim mentioned post #3
 
Right now I am running the USB_SERIAL_PRINT test. Ran on before and still running the after locking. Did see some corrupted data (spew) but quickly cleared up and notice the speed increased dramatically after the spew. But have not seen any slow downs yet and running for about 30minutes. Running in a range 500k to 850k lines/sec. Any recommendations on how long to let it run?

Seems like what was seen here. Even TyComm seemed to get inhibited after some longer run of unending fast Spew. Since the high rate is somewhat overrated by buffers filling faster than the GUI can display ( and maybe lost or misdirected buffers? ) - seems 'limited bursts' at high rate is all a PC can reliably handle without loss or conflict.
> When having the Code4Code.ino Spew out 3 MB of code generated code in MakeCode.ino to SerialUSB1 the resulting 'code' was incomplete and required adding something like { delayMicroseconds( 200 ); } in SEVEN select places to get usable source text where it loops making the 4000 FUNC####()'s. Maybe not all needed and not that long - but has been reliable multiple times since.
-> Given the code that runs the code that makes the code is using Dual Serial - Teensy_serial couldn't be used to gather the USB1 code for a test without rewriting it, so TyComm saved the day again.

PSRAM and QSPI flash on the bottom side of Teensy 4.1 are completely separate from the fuses and code security stuff.

...
Looks like I might need to start signing the utility exe files?

@Paul - we were just celebrating that we managed soldering 2 chips each to function without destroying the 'limited edition' Teensy. It's been some months since doing that and in the mean time posts from folks seeing trouble give one wonder.

Signing the utility exe's won't hurt on the user end. Did have to 'unblock' the trial teensy_serial.exe from the ZIP. But no problem with Windows built in Defender ( or MalwareBytes ) now that the new installer certificate is 'trusted'.
-> Wonder if that 'Code Black' (?) would skip flagging a found 'virus looking signature' if it confirms the EXE is signed?
 
Looks like I might need to start signing the utility exe files?
Was just strange since its the first time norton ever flagged teensy_sermon - never had an issue before>

Anyway just had and issue with alternating orange and red LEDS again which I can not duplicate. I loaded up a simple QSPI test sketch just to write some files to the chip - ran fine no problem. Then went to load a another QSPI datalogger sketch (in the examples folder) and got the dual alternating LEDS. It rebooted and ran the previously loaded sketch. So I just recompliled and loaded the logger test sketch which worked fine this time around. No idea how to duplicate it. Again this is on the locked T4,1
 
Was just strange since its the first time norton ever flagged teensy_sermon - never had an issue before>

Anyway just had and issue with alternating orange and red LEDS again which I can not duplicate. I loaded up a simple QSPI test sketch just to write some files to the chip - ran fine no problem. Then went to load a another QSPI datalogger sketch (in the examples folder) and got the dual alternating LEDS. It rebooted and ran the previously loaded sketch. So I just recompliled and loaded the logger test sketch which worked fine this time around. No idea how to duplicate it. Again this is on the locked T4,1

@mjs513 - was this a pure IDE build and upload - or using TyComm at all for SerMon?

p#5 shows a trigger for a failed upload T_4.1 (w/key.pem but Unlocked) - not surprising and not a valid process - but it did show something Paul had noted as 'seen before' on his end - though IIRC his count was 7 and not 9?

In that p#5 test there was no sign of the Dual Orange+Red LEDs - but a clear repeatable {9 Red blink, repeat}. And it 'seems' the cause might have been TyComm triggering bootloader when Teensy.exe Loader then takes over, but TyComm on seeing the Teensy re-appear tried to connect the USB in some fashion.

Not knowing how teensy_serial might cause the same trouble - but probably less aggressively that TyComm given in p#5 it was tasked with performing an upload - so perhaps it does the same but 'more rarely' interfering with the timing?

Not sure how these differ but (assuming it relates unchanged for 1.07bl) this pjrc.com/store/ic_mkl02_t4.html shows :
Code:
7 Blinks = ARM JTAG DAP Communication Error
A communication error was detected, but after correctly detecting (4 blinks) and initializing the ARM JTAG DAP (9 blinks). This error may indicate a severe signal quality problem or any of the signal wires shorted to other lines which are initially high impedance but become output after a program is running.
.versus.:
Code:
9 Blinks = ARM JTAG DAP Init Error
The ARM JTAG DAP was detected (4 blinks) but could not be initialized. This error is rather unlikely!

That Troubleshooting & Diagnostic Blink Codes list doesn't show why Dual Orange/Red would be presented. Hopefully the 7 .vs. 9 blinks leads Paul to a solution perhaps from USB Comms being interrupted and may explain Dual LEDs too???

I should/will run a more exhaustive - .vs. quick - set of p#5 repro steps on T_4.0 and 4.1 when {locked and unlocked}, including terminating TyComm when TLoader begins uploading to see if it completes normally in that case.
 
-> Wonder if that 'Code Black' (?) would skip flagging a found 'virus looking signature' if it confirms the EXE is signed?

What is meant by 'Code Black' ?

Looked at the usb_serial_speed_test again. Windows is terrible.

As part of the work to support upcoming Arduino 2.0, I'm going to change from anonymous pipes (eg stdin / stdout) to localhost sockets. Hopefully that will avoid the horrible buffer bloat and result in useful flow control all the way from GUI to Teensy device side. But this isn't going to happen for 1.56.

But the occasional garbage is almost certainly a Windows driver bug. I can't fix that.
 
@mjs513 - was this a pure IDE build and upload - or using TyComm at all for SerMon?
Pure IDE and SerMon closed. This was similar to what we had with T4 and the dual blinks
 
What is 'Code Black' ?

Looked at the usb_serial_speed_test again. Windows is terrible.

As part of the work to support upcoming Arduino 2.0, I'm going to change from anonymous pipes (eg stdin / stdout) to localhost sockets. Hopefully that will avoid the horrible buffer bloat and result in useful flow control all the way from GUI to Teensy device side. But this isn't going to happen for 1.56.

But the occasional garbage is almost certainly a Windows driver bug. I can't fix that.

Actually have Arduino 2.0 on my machine. During T4 testing with sketch didn't see an issue using the IDE2.0 serial monitor. Can try it again to be sure. Not sure its worth spending anymore time improving it if its going to get overhauled in the future. Just my 2 cents.
 
Quick update: Picked up care package this morning in town :D

So far on one T4.1 Soldered on bottom RAM and FLASH, and locked it.

Had one or two times where it did not want to program... Probably user error. I closed out the IDE and the like and retried... And it working now.

More playing!
 
What is meant by 'Code Black' ?

Looked at the usb_serial_speed_test again. Windows is terrible.

As part of the work to support upcoming Arduino 2.0, I'm going to change from anonymous pipes (eg stdin / stdout) to localhost sockets. Hopefully that will avoid the horrible buffer bloat and result in useful flow control all the way from GUI to Teensy device side. But this isn't going to happen for 1.56.

But the occasional garbage is almost certainly a Windows driver bug. I can't fix that.

It was marked (?) ... actually the 'noticed Carbon Black antivirus software was complaining' from the other day WRT to the test ZIP of the teensy_serial.exe : pjrc.com/threads/68208-teensy_size-exe-Access-is-denied
-> (edit) : never heard of Carbon Black AV before. If it doesn't validate a signed EXE - but just flags based on 'signature' it won't help to have them signed.

Agreed - Windows is terrible at routing the high speed Serial. Even a 'dos' exe when testing back during the 'major rework' to get it where it is just reading and parsing with minimal validation without streaming output was not showing stellar speed. Adding in the GUI streaming is just a further load.
 
UPDATE:
Ok just froze sermonitor and cleared itself. Closed the IDE and it immediately restarted. So just confirmed what Tim mentioned post #3
got curious and tested with the IDE2.0 and it stalled that as well after about 10-15 minutes which was curious since when I tested the last time with the locked T4 it seem to work better.

So the glutton for punishment that I am I ran the sketch with the locked T4 with 1.56b1 and its now been runnding for over an 2 hours without an issue. Looking at the lps seems to mostly around 505k with some peaks up to 800k but mostly at the 505k mark. From what I remember the locked T4.1 lps was running on average quite a bit higher on average. This could be the reason, but not sure why the T4.1 has a higher output rate than the T4?

Just another data point.

Went back to the t4.1 lockup thread to check since I didn't remember it doing that: https://forum.pjrc.com/threads/68199-Teensy-4-1-Lockup?p=288912&viewfull=1#post288912. Did something else change
 
Went to Win 10 laptop that had IDE 1.8.16, installed TD 1.56b1

Built for T_4.1 - lockable Beta boards.
Pulled pem.key to typical sketchbook folder

Opps, like other machine - the sketchbook was in default location?

Moved sketchbook to 't:\tcode' and rebuilt - it did not pick up on the pem.key and build an .eHex?

Closed IDE and built again and it is using encrypted Hex.

Not sure what this was but an install and setup issue ... the kind of thing that might happen going from prototype to production setting up alternate machines?

This may be an IDE scan issue and not a PJRC controllable issue?

Scary thing is if there had been a pem.key in that folder that was not the intended during the LOCK operation?

Only note is : anything the BUILD or Sketch can present as a reminder/confirmation of what file was used from where.
> at least worth a good checklist line item in the docs?
 
@Paul - back to desktop with known config and pem.key placement.

WORKED: Did a LOCK on the one T_4.1 beta ( without QSPI parts for my ID )

Then IDE built USB-Serial-Print-Speed-Test.ino as shown below.

But the build was an 'Export compiled Binary' so I'd know where it was.
> in Teensy loader did OPEN HEX so it would use that folder
> then told TyCommander to upload that HEX and Teensy.exe looked there and saw to upload the .eHex, but doesn't find the .elf - which is okay even if 'error 2'?

But then due to TyComm USB interference (?) the device was left with RED bootloader lit. Unplugging and re-plugging returns with RED led lit while Teensy.exe is open, but out of 'Auto' because of fast restart?
> Closing Teensy.exe leave the device offline and unprogrammed to run, but no RED led.

Repro steps similar to p#5 - but T_4.1 now Locked and different result - no 9 Blink sequence.
> As before not expecting this to work - hoping it might suggest why when without TyComm programming fails and left in bootloader, or get failed upload and blinking LED's in some fashion {7, or 9, or DUAL}.
--> Doing the above telling TyCommander to upload then CLOSING TyCommander right away as teensy.exe begins programming allows it to complete without a problem.
-> not finding your post. IIRC you noted the upload process uses a multi connect protocol? If so then TyCommander is inserting itself, can teensy_serial (or other) do the same?
Code:
01:36:19.783 (ports 1): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
01:36:19.784 (ports 1): remove: loc=usb:0/140000/0/6/1/1
01:36:19.784 (ports 1): usb_remove: usb:0/140000/0/6/1/1
01:36:19.784 (ports 1): nothing new, skipping HID & Ports enum
01:36:19.994 (ports 1): WM_DEVICECHANGE DBT_DEVICEARRIVAL
01:36:19.996 (ports 1): nothing new, skipping HID & Ports enum
01:36:20.188 (loader): handle d64
01:36:20.188 (loader): Device came online, code_size = 100
01:36:20.188 (loader): Board is: NXP IMXRT1062 ROM
01:36:20.188 (loader): begin operation
01:36:20.188 (loader): File "C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.hex", 21504 bytes
01:36:20.204 (loader): File "C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.ehex", 21504 bytes, and 4992 loader utility
01:36:20.204 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
01:36:20.204 (loader): File "USB-Serial-Print-Speed-Test.ino.TEENSY41.hex". 21504 bytes
01:36:20.204 (loader): set background IMG_ONLINE
01:36:20.204 (loader): nxp_write: success
01:36:20.204 (loader): HAB locked secure mode
01:36:20.204 (loader): sending ehex loader utility, 4992 bytes
01:36:20.204 (loader): nxp_write: success
01:36:20.220 (loader): nxp_write: success
01:36:20.222 (loader): nxp_write: success
01:36:20.222 (loader): nxp_write: success
01:36:20.222 (loader): nxp_write: success
01:36:20.222 (loader): nxp_write: success
01:36:20.222 (loader): run it..
01:36:20.222 (loader): nxp_write: success
01:36:20.238 (loader): ehex loader utility sucessfully started
01:36:20.238 (loader): end operation, total time = 0.050 seconds
01:36:20.238 (loader): redraw timer set, image 80 to show for 2000 ms
01:36:20.272 (ports 1): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
01:36:20.273 (ports 1): nothing new, skipping HID & Ports enum
01:36:20.427 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:20.428 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:20.428 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:20.428 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
01:36:20.428 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:20.428 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
01:36:20.443 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
01:36:20.443 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:20.613 (ports 1): WM_DEVICECHANGE DBT_DEVICEARRIVAL
01:36:20.615 (ports 1): found_usb_device, id=\\?\usb#vid_16c0&pid_0478#000ecf8e#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
01:36:20.615 (ports 1): found_usb_device, loc=usb:0/140000/0/6/1/1    Port_#0001.Hub_#0010
01:36:20.615 (ports 1): found_usb_device, hwid=USB\VID_16C0&PID_0478&REV_0107
01:36:20.615 (ports 1): found_usb_device, devinst=0000001f
01:36:20.615 (ports 1): add: loc=usb:0/140000/0/6/1/1, class=HID, vid=16C0, pid=0478, ver=0107, serial=000ecf8e, dev=\\?\usb#vid_16c0&pid_0478#000ecf8e#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
01:36:20.615 (ports 1): hiddev_from_devinst_list: iface=0
01:36:20.615 (ports 1): found_usb_device complete
01:36:20.616 (ports 1): usb_add: usb:0/140000/0/6/1/1  [no_device] (Teensy 4.1) Bootloader
01:36:20.686 (loader): encryption is required, public key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
01:36:20.686 (loader): Device came online, code_size = 8126464
01:36:20.696 (loader): Board is: Teensy 4.1 (IMXRT1062), version 1.07
01:36:20.696 (loader): File "C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.hex", 21504 bytes
01:36:20.706 (loader): File "C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.ehex", 21504 bytes, and 4992 loader utility
01:36:20.706 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
01:36:20.716 (loader): File "USB-Serial-Print-Speed-Test.ino.TEENSY41.hex". 21504 bytes, 0% used
01:36:20.716 (loader): File "USB-Serial-Print-Speed-Test.ino.TEENSY41.hex" opened, but "USB-Serial-Print-Speed-Test.ino.TEENSY41.ehex" will actually be used
01:36:20.746 (loader): set background IMG_ONLINE
01:36:20.756 (loader): File "C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.hex", 21504 bytes
01:36:20.766 (loader): File "C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.ehex", 21504 bytes, and 4992 loader utility
01:36:20.766 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
01:36:20.776 (loader): File "USB-Serial-Print-Speed-Test.ino.TEENSY41.hex". 21504 bytes, 0% used
[B]01:36:20.781 (loader): File "USB-Serial-Print-Speed-Test.ino.TEENSY41.hex" opened, but "USB-Serial-Print-Speed-Test.ino.TEENSY41.ehex" will actually be used
01:36:20.809 (loader): can't open file 'C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.elf' (error 2: the system cannot find the file specified.)[/B]
01:36:20.813 (loader): elf file is for Unknown Board
01:36:20.818 (loader): using encrypted ehex (required - secure mode is locked)
01:36:20.850 (loader): begin operation
01:36:20.890 (loader): flash, block=0, bs=1024, auto=1
01:36:21.046 (loader): flash, block=1, bs=1024, auto=1
01:36:21.053 (loader): flash, block=2, bs=1024, auto=1
01:36:21.058 (loader): flash, block=3, bs=1024, auto=1
01:36:21.062 (loader): flash, block=4, bs=1024, auto=1
01:36:21.069 (loader): flash, block=5, bs=1024, auto=1
01:36:21.077 (loader): flash, block=6, bs=1024, auto=1
01:36:21.082 (loader): flash, block=7, bs=1024, auto=1
01:36:21.088 (loader): flash, block=8, bs=1024, auto=1
01:36:21.125 (loader): flash, block=9, bs=1024, auto=1
01:36:21.131 (loader): flash, block=10, bs=1024, auto=1
01:36:21.136 (loader): flash, block=11, bs=1024, auto=1
01:36:21.142 (loader): flash, block=12, bs=1024, auto=1
01:36:21.149 (loader): flash, block=13, bs=1024, auto=1
01:36:21.155 (loader): flash, block=14, bs=1024, auto=1
01:36:21.187 (loader): flash, block=15, bs=1024, auto=1
01:36:21.193 (loader): flash, block=16, bs=1024, auto=1
01:36:21.202 (loader): flash, block=17, bs=1024, auto=1
01:36:21.209 (loader): flash, block=18, bs=1024, auto=1
01:36:21.216 (loader): flash, block=19, bs=1024, auto=1
01:36:21.223 (loader): flash, block=20, bs=1024, auto=1
01:36:21.255 (loader): sending reboot
01:36:21.262 (loader): begin wait_until_offline
01:36:21.267 (loader): offline, waited 0
01:36:21.273 (loader): end operation, total time = 0.417 seconds
01:36:21.280 (loader): set background IMG_REBOOT_OK
01:36:21.285 (ports 1): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
01:36:21.288 (ports 1): remove: loc=usb:0/140000/0/6/1/1
01:36:21.288 (ports 1): usb_remove: usb:0/140000/0/6/1/1
01:36:21.288 (ports 1): nothing new, skipping HID & Ports enum
01:36:21.302 (loader): redraw timer set, image 14 to show for 1200 ms
01:36:21.460 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:21.460 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:21.460 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:21.476 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
01:36:21.476 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:21.491 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
01:36:21.491 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
01:36:21.491 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:21.524 (ports 1): WM_DEVICECHANGE DBT_DEVICEARRIVAL
01:36:21.526 (ports 1): nothing new, skipping HID & Ports enum
01:36:21.714 (loader): handle b30
01:36:21.714 (loader): Device came online, code_size = 100
01:36:21.729 (loader): Board is: NXP IMXRT1062 ROM
01:36:21.729 (loader): begin operation
01:36:21.745 (loader): File "C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.hex", 21504 bytes
01:36:21.745 (loader): File "C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.ehex", 21504 bytes, and 4992 loader utility
01:36:21.761 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
01:36:21.761 (loader): File "USB-Serial-Print-Speed-Test.ino.TEENSY41.hex". 21504 bytes
01:36:21.776 (loader): reboot too soon timer still running, oh no!
01:36:21.808 (loader): set background IMG_ONLINE
01:36:21.820 (loader): nxp_write: success
01:36:21.825 (loader): HAB locked secure mode
01:36:21.825 (loader): sending ehex loader utility, 4992 bytes
01:36:21.841 (loader): nxp_write: success
01:36:21.841 (loader): nxp_write: success
01:36:21.841 (loader): nxp_write: success
01:36:21.856 (loader): nxp_write: success
01:36:21.856 (loader): nxp_write: success
01:36:21.872 (loader): nxp_write: success
01:36:21.872 (loader): run it..
01:36:21.872 (loader): nxp_write: success
01:36:21.888 (loader): ehex loader utility sucessfully started
01:36:21.903 (loader): end operation, total time = 0.174 seconds
01:36:21.903 (loader): redraw timer set, image 80 to show for 2000 ms
01:36:21.931 (ports 1): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
01:36:21.934 (ports 1): nothing new, skipping HID & Ports enum
01:36:21.966 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:21.966 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:21.981 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:21.981 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
01:36:21.981 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:21.997 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
01:36:21.997 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
01:36:21.997 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
01:36:22.275 (ports 1): WM_DEVICECHANGE DBT_DEVICEARRIVAL
01:36:22.277 (ports 1): found_usb_device, id=\\?\usb#vid_16c0&pid_0478#000ecf8e#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
01:36:22.277 (ports 1): found_usb_device, loc=usb:0/140000/0/6/1/1    Port_#0001.Hub_#0010
01:36:22.277 (ports 1): found_usb_device, hwid=USB\VID_16C0&PID_0478&REV_0107
01:36:22.277 (ports 1): found_usb_device, devinst=0000001f
01:36:22.277 (ports 1): add: loc=usb:0/140000/0/6/1/1, class=HID, vid=16C0, pid=0478, ver=0107, serial=000ecf8e, dev=\\?\usb#vid_16c0&pid_0478#000ecf8e#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
01:36:22.277 (ports 1): hiddev_from_devinst_list: iface=0
01:36:22.278 (ports 1): found_usb_device complete
01:36:22.279 (ports 1): usb_add: usb:0/140000/0/6/1/1  [no_device] (Teensy 4.1) Bootloader
01:36:22.486 (loader): encryption is required, public key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
01:36:22.486 (loader): Device came online, code_size = 8126464
01:36:22.496 (loader): Board is: Teensy 4.1 (IMXRT1062), version 1.07
01:36:22.506 (loader): File "C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.hex", 21504 bytes
01:36:22.516 (loader): File "C:\T_Drive\tCode\PJRC\USB-Serial-Print-Speed-Test\USB-Serial-Print-Speed-Test.ino.TEENSY41.ehex", 21504 bytes, and 4992 loader utility
01:36:22.526 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
01:36:22.526 (loader): File "USB-Serial-Print-Speed-Test.ino.TEENSY41.hex". 21504 bytes, 0% used
01:36:22.536 (loader): File "USB-Serial-Print-Speed-Test.ino.TEENSY41.hex" opened, but "USB-Serial-Print-Speed-Test.ino.TEENSY41.ehex" will actually be used
01:36:22.577 (loader): set background IMG_ONLINE
01:36:22.736 (loader): HID/win32: HidD_GetPreparsedData ok, device still online :-)
01:37:08.327 (ports 1): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
01:37:08.328 (ports 1): update_usb_device, devinst list change, old had 1, new has 2
01:37:08.328 (ports 1): hiddev_from_devinst_list: iface=0
01:37:08.329 (ports 1): hid, found devinst=00000020
01:37:08.329 (ports 1): hid, path=\\?\hid#vid_16c0&pid_0478#8&3742ec8f&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
01:37:08.329 (ports 1): hid,  opened handle
01:37:08.329 (ports 1):  devinst=00000020, location=usb:0/140000/0/6/1/1
01:37:08.329 (ports 1):  vid=16C0, pid=0478, ver=0107, usepage=FF9C, use=0025
01:37:08.329 (ports 1):  devpath=\\?\hid#vid_16c0&pid_0478#8&3742ec8f&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
01:37:08.329 (ports 1): usb_add: usb:0/140000/0/6/1/1  hid#vid_16c0&pid_0478 (Teensy 4.1) Bootloader
01:37:08.429 (ports 1): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
01:37:08.430 (ports 1): nothing new, skipping HID & Ports enum

Re-Open Teensy.exe and click enable Auto mode proceeds to program and restart the T_4.1 running.
 
@Paul - @mjs513 and myself have been playing with the MTP integration with the updated date/time code plus other changes.

Found that the updated initializing the Event Endpoint in core was not working well, we were having some hangs when we sent more than one event... Maybe only one...

Differences was one in library has a callback function, and one in core did not... So updated the core one to have callback that incremented a counter like was in library and now things appear to be happy again.

Issued PR: https://github.com/PaulStoffregen/cores/pull/617

Need to update the Integration thread to mention what is current set of libraries you need...
Update is in the fork/branch: https://github.com/KurtE/cores/tree/FS_Integration_mtp_endpoint
(Will delete my current cores FS_Integration branch as out of date as now out of date... Has old date/time format...
 
Moved sketchbook to 't:\tcode' and rebuilt - it did not pick up on the pem.key and build an .eHex?

Closed IDE and built again and it is using encrypted Hex.

I believe what probably happened is the Arduino IDE started using the new location, but kept the new location in memory and didn't flush it to {AppData}/Arduino/preferences.txt until you quit the program. Sadly, the platform.txt recipes don't provide a macro to pass the sketckbook folder to commands (or if that capability does exist, it's not documented), so the encryption utility has to look up the AppData location from Windows, find preferences.txt, and parse it to discover where your sketchbook folder is located. If the IDE hasn't actually written your new settings to that preferences.txt file, the encryption utility will look for key.pem in whatever old location is still in preferences.txt.

I've added this to the code security documentation.

Your key.pem file is stored in your "sketchbook" folder, which by default is {Documents}/Arduino. If you change the sketchbook location from File > Preferences, the Arduino IDE may need to be restarted before your key.pem file is used from the new location.

I could patch the Java code to make the IDE flush the settings to preferences.txt when you click OK on the File > Preferences dialog box. But unless this becomes a common issue, I'm not feeling eager to add more Java modifications to the patch set I maintain for every Arduino IDE release.
 
Status
Not open for further replies.
Back
Top