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

Thread: Teensyduino 1.56 Beta #1

Hybrid View

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

    Teensyduino 1.56 Beta #1

    Here is a first beta test for Teensyduino 1.56.


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

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

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

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

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

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

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


    Changes since Teensyduino 1.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

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    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.

  3. #3
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    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?

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    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

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    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.
    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.

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    @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#{4d1e 55b2-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
    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
    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 by defragster; 09-26-2021 at 09:53 AM.

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    Quote Originally Posted by defragster View Post
    @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.

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

    Seven RED Blinks on T_4.1 now that it is locked

    Quote Originally Posted by defragster View Post
    @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:

    ...
    @Paul - update to this post #5.

    Now with Beta T_4.1 LOCKED - performing these steps ( abusing TyComm while TLoader is open )

    The Locked Teensy is giving SEVEN blinks and a pause then Repeat - where the pause seems longer than I recall on the 9 Blinks
    -> though now Teensy.exe is still in AUTO mode while the Teensy blinks and pauses
    > where before 9 blinks appeared when the same T_4.1 had been pem.key fused before being locked

    Push of the button cause a normal upload and return to function.

    Repro repeat:
    Did build and Teensy upload of : R:\temp\arduino_build_PrimeTemp.ino\PrimeTemp.ino. hex
    Gathering that path I went to TyComm and told it to upload that same file.

    > The upload began - BY Teensy.exe loader when TyComm started by triggering the bootloader.
    > was interrupted before completion it seems and teensy went offline to 7 blinks

    clearing verbose before repeating that now shows:
    Code:
    21:48:54.307 (loader): encryption is optional, public key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
    21:48:54.307 (loader): Device came online, code_size = 8126464
    21:48:54.307 (loader): Board is: Teensy 4.1 (IMXRT1062), version 1.07
    21:48:54.318 (loader): File "R:\temp\arduino_build_PrimeTemp.ino\PrimeTemp.ino.hex", 49152 bytes
    21:48:54.321 (loader): File "R:\temp\arduino_build_PrimeTemp.ino\PrimeTemp.ino.ehex", 49152 bytes, and 4992 loader utility
    21:48:54.327 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
    21:48:54.327 (loader): File "PrimeTemp.ino.hex". 49152 bytes, 1% used
    21:48:54.327 (loader): File "PrimeTemp.ino.hex" opened, but "PrimeTemp.ino.ehex" will actually be used
    21:48:54.352 (loader): set background IMG_ONLINE
    21:48:54.368 (loader): File "R:\temp\arduino_build_PrimeTemp.ino\PrimeTemp.ino.hex", 49152 bytes
    21:48:54.368 (loader): File "R:\temp\arduino_build_PrimeTemp.ino\PrimeTemp.ino.ehex", 49152 bytes, and 4992 loader utility
    21:48:54.377 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
    21:48:54.382 (loader): File "PrimeTemp.ino.hex". 49152 bytes, 1% used
    21:48:54.384 (loader): File "PrimeTemp.ino.hex" opened, but "PrimeTemp.ino.ehex" will actually be used
    21:48:54.407 (loader): elf appears to be for Teensy 4.1 (IMXRT1062) (8126464 bytes)
    21:48:54.407 (loader): elf binary data matches hex file
    21:48:54.407 (loader): elf file is for Teensy 4.1 (IMXRT1062)
    21:48:54.412 (loader): using encrypted ehex (optional - secure mode not yet locked)
    21:48:54.438 (loader): begin operation
    21:48:54.478 (loader): flash, block=0, bs=1024, auto=1
    21:48:54.518 (loader): flash, block=1, bs=1024, auto=1
    21:48:54.521 (loader): flash, block=2, bs=1024, auto=1
    21:48:54.523 (loader): flash, block=3, bs=1024, auto=1
    21:48:54.525 (loader): flash, block=4, bs=1024, auto=1
    21:48:54.531 (loader): flash, block=5, bs=1024, auto=1
    21:48:54.534 (loader): flash, block=6, bs=1024, auto=1
    21:48:54.537 (loader): flash, block=7, bs=1024, auto=1
    21:48:54.540 (loader): flash, block=8, bs=1024, auto=1
    21:48:54.543 (loader): flash, block=9, bs=1024, auto=1
    21:48:54.547 (loader): flash, block=10, bs=1024, auto=1
    21:48:54.559 (loader): flash, block=11, bs=1024, auto=1
    21:48:54.561 (loader): flash, block=12, bs=1024, auto=1
    21:48:54.564 (loader): flash, block=13, bs=1024, auto=1
    21:48:54.567 (loader): flash, block=14, bs=1024, auto=1
    21:48:54.570 (loader): flash, block=15, bs=1024, auto=1
    21:48:54.574 (loader): flash, block=16, bs=1024, auto=1
    21:48:54.577 (loader): flash, block=17, bs=1024, auto=1
    21:48:54.577 (loader): flash, block=18, bs=1024, auto=1
    21:48:54.588 (loader): flash, block=19, bs=1024, auto=1
    21:48:54.591 (loader): flash, block=20, bs=1024, auto=1
    21:48:54.594 (loader): flash, block=21, bs=1024, auto=1
    21:48:54.598 (loader): flash, block=22, bs=1024, auto=1
    21:48:54.601 (loader): flash, block=23, bs=1024, auto=1
    21:48:54.601 (loader): flash, block=24, bs=1024, auto=1
    21:48:54.607 (loader): flash, block=25, bs=1024, auto=1
    21:48:54.616 (loader): flash, block=26, bs=1024, auto=1
    21:48:54.620 (loader): flash, block=27, bs=1024, auto=1
    21:48:54.626 (loader): flash, block=28, bs=1024, auto=1
    21:48:54.629 (loader): flash, block=29, bs=1024, auto=1
    21:48:54.629 (loader): flash, block=30, bs=1024, auto=1
    21:48:54.629 (loader): flash, block=31, bs=1024, auto=1
    21:48:54.629 (loader): flash, block=32, bs=1024, auto=1
    21:48:54.656 (loader): flash, block=33, bs=1024, auto=1
    21:48:54.661 (loader): flash, block=34, bs=1024, auto=1
    21:48:54.661 (loader): flash, block=35, bs=1024, auto=1
    21:48:54.661 (loader): flash, block=36, bs=1024, auto=1
    21:48:54.710 (loader): flash, block=37, bs=1024, auto=1
    21:48:54.716 (loader): flash, block=38, bs=1024, auto=1
    21:48:54.721 (loader): flash, block=39, bs=1024, auto=1
    21:48:54.725 (loader): flash, block=40, bs=1024, auto=1
    21:48:54.726 (loader): flash, block=41, bs=1024, auto=1
    21:48:54.726 (loader): flash, block=42, bs=1024, auto=1
    21:48:54.726 (loader): flash, block=43, bs=1024, auto=1
    21:48:54.742 (loader): flash, block=44, bs=1024, auto=1
    21:48:54.749 (loader): flash, block=45, bs=1024, auto=1
    21:48:54.754 (loader): flash, block=46, bs=1024, auto=1
    21:48:54.759 (loader): flash, block=47, bs=1024, auto=1
    21:48:54.793 (loader): sending reboot
    21:48:54.793 (loader): begin wait_until_offline
    21:48:54.855 (loader): offline, waited 1
    21:48:54.856 (loader): end operation, total time = 0.419 seconds
    21:48:54.856 (loader): set background IMG_REBOOT_OK
    21:48:54.856 (loader): redraw timer set, image 14 to show for 1200 ms
    21:48:54.959 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
    21:48:54.964 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
    21:48:54.968 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
    21:48:54.972 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
    21:48:54.976 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
    21:48:55.029 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
    21:48:55.029 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
    21:48:55.029 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
    21:48:56.064 (loader): redraw, image 9
    And again TyComm flagged a RED onscreen error expecting the Teensy to be ready and it logged this from both trials:
    Code:
    [reboot@9706430-Teensy] Failed to reboot board '9706430-Teensy
    [upload@9706430-Teensy] I/O error while writing to '\\.\HID#VID_16C0&PID_0478#8&295A2D2B&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}'
    [upload@9706430-Teensy] I/O error while writing to '\\.\HID#VID_16C0&PID_0478#8&295A2D2B&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}'

  9. #9
    Member
    Join Date
    Sep 2021
    Posts
    74
    It can't be the USB drivers, otherwise no USB stick would work. It must be something else.
    It is remarkable that H-Term does not log or output random characters.
    The problem of missing lines also seems to occur in H-Term only after a certain amount.

    In the end, however, it doesn't matter. As you can see once again, it's up to the PC. One should simply do without these tests.
    After all, it leads to nothing.

  10. #10
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,217
    Quote Originally Posted by Mcu32 View Post
    It is remarkable that H-Term does not log or output random characters.
    That is indeed remarkable, as Coolterm and others do it.

    I downloaded Hterm, but it wants various DLLs my Windows test system doesn't have.

    Click image for larger version. 

Name:	capture.png 
Views:	15 
Size:	16.0 KB 
ID:	26004

    Please keep in mind I'm not a Windows user (I primarily use Linux and occasionally MacOS for video stuff) - my Windows test system has only Arduino and Teensyduino and Coolterm installed. I don't actually use the computer for anything other that testing the Windows version of Teensyduino, so a lot of the software that's commonly installed on well-used Windows systems isn't here.


    The problem of missing lines also seems to occur in H-Term only after a certain amount.
    Yes, with Java-based serial monitor and Coolterm and others, the problems only occur after a huge amount of data has been transferred at sustained high speed.

  11. #11
    Member
    Join Date
    Sep 2021
    Posts
    74
    The output to screen is slow in h-term. But logging to file seems to be very good.
    Maybe Defragster can send you the missing DLLs. For me, it worked out of the box.

  12. #12
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    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:
    Click image for larger version. 

Name:	Capture.PNG 
Views:	22 
Size:	21.8 KB 
ID:	25989

    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

  13. #13
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    Quote Originally Posted by mjs513 View Post
    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.

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,217
    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....

  15. #15
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    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

  16. #16
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    Quote Originally Posted by mjs513 View Post
    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.

    Quote Originally Posted by PaulStoffregen View Post
    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?

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,217
    Quote Originally Posted by defragster View Post
    -> 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.

  18. #18
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    Quote Originally Posted by PaulStoffregen View Post
    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.

  19. #19
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    Quote Originally Posted by PaulStoffregen View Post
    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.

  20. #20
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    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

  21. #21
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    Quote Originally Posted by mjs513 View Post
    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.

  22. #22
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    @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

  23. #23
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,734
    Quick update: Picked up care package this morning in town

    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!

  24. #24
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    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...l=1#post288912. Did something else change

  25. #25
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    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?

Posting Permissions

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