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

Thread: Teensyduino 1.56 Beta #1

  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,264
    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,264
    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,264
    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,264
    @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.

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

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

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

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

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

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

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

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

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

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

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

  18. #18
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,729
    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!

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

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

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

  23. #23
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,729
    @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/...n_mtp_endpoint
    (Will delete my current cores FS_Integration branch as out of date as now out of date... Has old date/time format...

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

    ...
    @KurtE - Quick glance shows that edit in Teensy4 cores - will the same apply to T_3.6 with RTC and USB_Host?

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

Posting Permissions

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