Teensyduino 1.55 Beta #1

Status
Not open for further replies.
@Paul
I just saw the DUAL LED's flash again on Bootloader request (third time?). Perhaps the Orange noticeably ahead of the RED - but both then persist ON some second(s) of time and go out ... and repeat for several cycles.
> No repro on trying: 10 Button presses, 10 tries with TLOader not in AUTO mode hitting 'Program' icon.

LittleFS for DMAMEM.ino I find this to work reliably across Restart and Upload:
Code:
#define LFS_BUF_SIZE 430*1024 // Define the desired size that fits in DMAMEM
void *LFS_BUF = (void*)(0x2027ff00-LFS_BUF_SIZE); // RAM2 Addr :: typically survives Restart/Upload, avoid lower 32KB 0x2020000, upper CrashReport area
     // ...
void setup() {
  	if (!myfs.begin(LFS_BUF, LFS_BUF_SIZE)) {

And this - Manually jumping the 32KB HAB and not using the explicit end of RAM2 ptr does not survive:
<edit>:
- Does survive only software commanded 'R'eset Teensy from sketch
- does not survive Button upload of same code
- does not survive TyComm bootloader upload of same code
- does not survive TyComm USB commanded Reset
Code:
#define LFS_BUF_SIZE 430*1024 // Define the desired size that fits in DMAMEM
#define BUF_OFFSET 32768 // Must be 32768 when using DMAMEM to survive warm restart
DMAMEM char LFS_BUF[ LFS_BUF_SIZE ];  // DMAMEM Uses RAM2 :: Typically survives Restart/Upload
     // ...
void setup() {
  if (!myfs.begin(&LFS_BUF[BUF_OFFSET], sizeof(LFS_BUF) - BUF_OFFSET)) {
 
Last edited:
I just saw the DUAL LED's flash again on Bootloader request (third time?). Perhaps the Orange noticeably ahead of the RED - but both then persist ON some second(s) of time and go out ... and repeat for several cycles.

Is the problem reproducible or only intermittent?
 
Is the problem reproducible or only intermittent?

Missed this jump to Next page ... Updated above purposeful Repro fails.

It is intermittent - Third time observed since the Beta unit arrived.

Noted each time before - at least one included verbose Tloader info. Lost Verbose this time with copious repro tries.
 
I'm sad to say Teensy Loader's verbose info will not help with this problem.

I'll try to make some change in 1.55-beta2 to prevent it. If this keeps happening, I'll work on a way to get some info logged.

At this moment I'm reworking how Teensy Loader handles a "closed" device. As you've seen, certain errors with locked chips completely tie up Teensy Loader's GUI. I'm adding the ability for Teensy Loader to ignore specific devices from the time they're closed until they disconnect. Unfortunately it has to be written 3 times, as the device detection and HID APIs and location semantics are completely different on each operating system. In a strange turn of events, I did MacOS first this time but didn't test it much, then did Windows and tested it thoroughly yesterday. Now I'm testing MacOS, then will go back to Linux.

I really need to wrap this up quickly, as Arduino just put 1.8.16 on their website...
 
Didn't think it would help as I saw no relevant notes - but compelled to include first 2 times.

I see one thing possibly part of your current 3*DeviceIgnore?
> Integrity Sketch 'Restart Teensy' { SCB_AIRCR = 0x05FA0004; } does not trigger TLoader
> TyComm USB Reset command triggers RED led and TLoader image change - but does not upload : though as noted in p#376 it does destroy DMAMEM buffer alloc, where it does not destroy DMAMEM with hardcoded pointer.

I did note the one PANIC p#330 : pjrc.com/threads/67989-Teensyduino-1-55-Beta-1?p=287172&viewfull=1#post287172
 
FYI: I've been doing mostly 'Verify' IDE builds. Sometime Button pushes, but usually TyCommander 'Bootloader' GUI buttons for USB Upload.
>> because I have 1,2,3,4 and 5 T_4.0's on the same computer at times. TyComm allows keyboard selective Bootloader showing Ser#. Though only one powered just now.

>> This is on T_4.0 Beta with Secure Mode LOCKED

Just did that again with Verify then TyComm Bootloader and TLoader showed 'Erasing' image.
> It did not erase and did not program
> Then I hit TyComm Bootloader again and TLoader turned off Auto Mode
> Pressed TLoader 'Upload' and Restart and it worked normally

This is also intermittent and has worked some hundred times.

Here is Verbose where you'll recognize the 'erase image' draw and see the before and after perhaps:
Code:
3:06:16.482 (loader): remote connection 4812 opened
03:06:16.482 (loader): remote cmd from 4812: "comment: Teensyduino 1.55-beta1 - WINDOWS (teensy_post_compile)"
03:06:16.482 (loader): remote cmd from 4812: "status"
03:06:16.482 (loader): remote cmd from 4812: "dir:C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\"
03:06:16.482 (loader): remote cmd from 4812: "file:DMAMEMt.ino.hex"
03:06:16.489 (post_compile 13): Begin, version=1.55-beta1, high-res time
03:06:16.495 (post_compile 13): Sending command: comment: Teensyduino 1.55-beta1 - WINDOWS (teensy_post_compile)
03:06:16.496 (post_compile 13): Status: 1, 0, 0, 107, 5, 0, C:\Users\Tim\AppData\Local\Temp\arduino_build_308927\, DMAMEM.ino.hex
03:06:16.496 (post_compile 13): Sending command: dir:C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\
03:06:16.497 (post_compile 13): Sending command: file:DMAMEMt.ino.hex
03:06:16.513 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.hex", 105472 bytes
03:06:16.526 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.ehex", 105472 bytes, 4960 extra
03:06:16.526 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
03:06:16.532 (loader): remote cmd from 4812: "status"
03:06:16.534 (loader): remote cmd from 4812: "auto:on"
03:06:16.534 (post_compile 13): Status: 1, 0, 0, 107, 5, 0, C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\, DMAMEMt.ino.hex
03:06:16.534 (post_compile 13): Sending command: auto:on
03:06:16.535 (post_compile 13): Disconnect
03:06:16.560 (loader): remote connection 4812 closed
03:06:22.051 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
03:06:22.055 (ports 2): remove: loc=usb:0/140000/0/6/1/1
03:06:22.055 (ports 2): usb_remove: usb:0/140000/0/6/1/1
03:06:22.055 (ports 2): nothing new, skipping HID & Ports enum
03:06:22.074 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
03:06:22.074 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:22.074 (ports 2): nothing new, skipping HID & Ports enum
03:06:22.235 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
03:06:22.237 (ports 2): nothing new, skipping HID & Ports enum
03:06:22.343 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:22.344 (ports 2): nothing new, skipping HID & Ports enum
03:06:22.377 (loader): handle 10fc
03:06:22.377 (loader): HID/win32: HidD_GetPreparsedData ok
03:06:22.379 (loader):  security: 03  12 34 34 12
03:06:22.380 (loader):  response: 04  12 8A 8A 12
03:06:22.380 (loader): nxp_write_register32 success, 12343412 128a8a12
03:06:22.380 (loader): Device came online, code_size = 100
03:06:22.380 (loader): Board is: NXP IMXRT1062 ROM
03:06:22.380 (loader): begin operation
03:06:22.396 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.hex", 105472 bytes
03:06:22.408 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.ehex", 105472 bytes, 4960 extra
03:06:22.408 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
03:06:22.408 (loader): set background IMG_ONLINE
03:06:22.414 (loader): state STATE_NXP_BEGIN
03:06:22.415 (loader):  security: 03  12 34 34 12
03:06:22.416 (loader):  response: 04  12 8A 8A 12
03:06:22.416 (loader): HAB locked secure mode
03:06:22.417 (loader): state STATE_NXP_CLOSED
03:06:22.418 (loader): sending ehex access, 4960 bytes
03:06:22.421 (loader):  security: 03  12 34 34 12
03:06:22.422 (loader):  response: 04  88 88 88 88
03:06:22.422 (loader): run it..
03:06:22.424 (loader):  security: 03  12 34 34 12
03:06:22.436 (loader): end operation, total time = 0.056 seconds
03:06:22.439 (loader): redraw timer set, image 80 to show for 2000 ms
03:06:22.441 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
03:06:22.442 (ports 2): nothing new, skipping HID & Ports enum
03:06:22.617 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:22.617 (ports 2): nothing new, skipping HID & Ports enum
03:06:22.628 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:22.628 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:22.628 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:22.629 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:22.629 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:22.629 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:22.629 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:22.629 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:22.858 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
03:06:22.859 (ports 2): found_usb_device, id=\\?\usb#vid_16c0&pid_0478#000fd6ad#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
03:06:22.859 (ports 2): found_usb_device, loc=usb:0/140000/0/6/1/1    Port_#0001.Hub_#0009
03:06:22.859 (ports 2): found_usb_device, devinst=00000006
03:06:22.859 (ports 2): found_usb_device, hwid=USB\VID_16C0&PID_0478&REV_0107
03:06:22.859 (ports 2): add: loc=usb:0/140000/0/6/1/1, class=HID, vid=16C0, pid=0478, ver=0107, serial=000fd6ad, dev=\\?\usb#vid_16c0&pid_0478#000fd6ad#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
03:06:22.859 (ports 2): hiddev_from_devinst_list: iface=0
03:06:22.860 (ports 2): found_usb_device complete
03:06:22.860 (ports 2): usb_add: usb:0/140000/0/6/1/1  [no_device] (Teensy 4.0) Bootloader
03:06:22.865 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:22.866 (ports 2): hid, found devinst=00000019
03:06:22.866 (ports 2): hid, path=\\?\hid#vid_16c0&pid_0478#8&31719e78&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
03:06:22.866 (ports 2): hid,  opened handle
03:06:22.866 (ports 2):  devinst=00000019, location=usb:0/140000/0/6/1/1
03:06:22.866 (ports 2):  vid=16C0, pid=0478, ver=0107, usepage=FF9C, use=0024
03:06:22.866 (ports 2):  devpath=\\?\hid#vid_16c0&pid_0478#8&31719e78&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
03:06:22.866 (ports 2): usb_add: usb:0/140000/0/6/1/1  hid#vid_16c0&pid_0478 (Teensy 4.0) Bootloader
03:06:22.881 (loader): encryption is required, public key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
03:06:22.881 (loader): Device came online, code_size = 2031616
03:06:22.881 (loader): Board is: Teensy 4.0 (IMXRT1062), version 1.07
03:06:22.896 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.hex", 105472 bytes
03:06:22.909 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.ehex", 105472 bytes, 4960 extra
03:06:22.909 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
03:06:22.910 (loader): set background IMG_ONLINE
03:06:22.927 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.hex", 105472 bytes
03:06:22.940 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.ehex", 105472 bytes, 4960 extra
03:06:22.940 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
03:06:22.943 (loader): elf appears to be for Teensy 4.0 (IMXRT1062) (2031616 bytes)
03:06:22.943 (loader): elf binary data matches hex file
03:06:22.943 (loader): elf file is for Teensy 4.0 (IMXRT1062)
03:06:22.943 (loader): using encrypted ehex (required - secure mode is locked)
03:06:22.980 (loader): begin operation
03:06:22.984 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
03:06:22.985 (ports 2): remove: loc=usb:0/140000/0/6/1/1
03:06:22.985 (ports 2): usb_remove: usb:0/140000/0/6/1/1
03:06:22.985 (ports 2): nothing new, skipping HID & Ports enum
03:06:23.025 (loader): flash, block=0, bs=1024, auto=1
03:06:23.397 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
03:06:23.398 (ports 2): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#10379970#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
03:06:23.398 (ports 2): found_usb_device, loc=usb:0/140000/0/6/1/1    Port_#0001.Hub_#0009
03:06:23.398 (ports 2): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0279
03:06:23.398 (ports 2): found_usb_device, devinst=0000001a
03:06:23.398 (ports 2): add: loc=usb:0/140000/0/6/1/1, class=USB, vid=16C0, pid=0483, ver=0279, serial=10379970, dev=\\?\usb#vid_16c0&pid_0483#10379970#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
03:06:23.398 (ports 2):   comport_from_devinst_list attempt
03:06:23.398 (ports 2): found_usb_device complete
03:06:23.400 (ports 2): usb_add: usb:0/140000/0/6/1/1  [no_device] (Teensy 4.0) Serial
03:06:28.109 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:28.109 (ports 2): update_usb_device, devinst list change, old had 1, new has 2
03:06:28.109 (ports 2):   found Ports in classguid_list at index=1
03:06:28.109 (ports 2):   comport_from_devinst_list attempt
03:06:28.109 (ports 2):   port COM9 found from devnode
03:06:28.110 (ports 2): usb_add: usb:0/140000/0/6/1/1  COM9 (Teensy 4.0) Serial
03:06:28.349 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:28.350 (ports 2): nothing new, skipping HID & Ports enum
03:06:28.419 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
03:06:28.419 (ports 2): nothing new, skipping HID & Ports enum
03:06:29.033 (loader): HID/win32:   write failure, num = 0
03:06:29.033 (loader): program: write error
03:06:29.033 (loader): HID/win32: HidD_GetPreparsedData failed, device assumed disconnected
03:06:29.044 (loader): end operation, total time = 6.064 seconds
03:06:29.047 (loader): set background IMG_DOWNLOAD_ERROR
03:06:29.049 (loader): redraw timer set, image 11 to show for 4000 ms
03:06:29.054 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:29.055 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:29.055 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:29.055 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:29.055 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:29.055 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:29.055 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:29.055 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:33.055 (loader): redraw, image 9
03:06:38.559 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
03:06:38.562 (ports 2): remove: loc=usb:0/140000/0/6/1/1
03:06:38.562 (ports 2): usb_remove: usb:0/140000/0/6/1/1
03:06:38.562 (ports 2): nothing new, skipping HID & Ports enum
03:06:38.587 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:38.588 (ports 2): nothing new, skipping HID & Ports enum
03:06:38.592 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
03:06:38.593 (ports 2): nothing new, skipping HID & Ports enum
03:06:38.740 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
03:06:38.743 (ports 2): nothing new, skipping HID & Ports enum
03:06:38.864 (loader): handle c50
03:06:38.864 (loader): HID/win32: HidD_GetPreparsedData ok
03:06:38.865 (loader):  security: 03  12 34 34 12
03:06:38.866 (loader):  response: 04  12 8A 8A 12
03:06:38.866 (loader): nxp_write_register32 success, 12343412 128a8a12
03:06:38.866 (loader): Device came online, code_size = 100
03:06:38.866 (loader): Board is: NXP IMXRT1062 ROM
03:06:38.866 (loader): begin operation
03:06:38.882 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.hex", 105472 bytes
03:06:38.894 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.ehex", 105472 bytes, 4960 extra
03:06:38.895 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
03:06:38.895 (loader): set background IMG_ONLINE
03:06:38.901 (loader): state STATE_NXP_BEGIN
03:06:38.903 (loader):  security: 03  12 34 34 12
03:06:38.904 (loader):  response: 04  12 8A 8A 12
03:06:38.904 (loader): HAB locked secure mode
03:06:38.906 (loader): state STATE_NXP_CLOSED
03:06:38.906 (loader): sending ehex access, 4960 bytes
03:06:38.909 (loader):  security: 03  12 34 34 12
03:06:38.910 (loader):  response: 04  88 88 88 88
03:06:38.910 (loader): run it..
03:06:38.912 (loader):  security: 03  12 34 34 12
03:06:38.927 (loader): end operation, total time = 0.061 seconds
03:06:38.929 (loader): redraw timer set, image 80 to show for 2000 ms
03:06:38.933 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
03:06:38.937 (ports 2): nothing new, skipping HID & Ports enum
03:06:39.107 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:39.108 (ports 2): nothing new, skipping HID & Ports enum
03:06:39.119 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.119 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.119 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.119 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.119 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.119 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.119 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.119 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.344 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
03:06:39.345 (ports 2): found_usb_device, id=\\?\usb#vid_16c0&pid_0478#000fd6ad#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
03:06:39.345 (ports 2): found_usb_device, loc=usb:0/140000/0/6/1/1    Port_#0001.Hub_#0009
03:06:39.345 (ports 2): found_usb_device, hwid=USB\VID_16C0&PID_0478&REV_0107
03:06:39.345 (ports 2): found_usb_device, devinst=00000006
03:06:39.345 (ports 2): add: loc=usb:0/140000/0/6/1/1, class=HID, vid=16C0, pid=0478, ver=0107, serial=000fd6ad, dev=\\?\usb#vid_16c0&pid_0478#000fd6ad#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
03:06:39.345 (ports 2): hiddev_from_devinst_list: iface=0
03:06:39.346 (ports 2): found_usb_device complete
03:06:39.347 (ports 2): usb_add: usb:0/140000/0/6/1/1  [no_device] (Teensy 4.0) Bootloader
03:06:39.363 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:39.364 (ports 2): update_usb_device, devinst list change, old had 1, new has 2
03:06:39.364 (ports 2): hiddev_from_devinst_list: iface=0
03:06:39.364 (ports 2): hid, found devinst=00000019
03:06:39.364 (ports 2): hid, path=\\?\hid#vid_16c0&pid_0478#8&31719e78&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
03:06:39.364 (ports 2): hid,  opened handle
03:06:39.364 (ports 2):  devinst=00000019, location=usb:0/140000/0/6/1/1
03:06:39.364 (ports 2):  vid=16C0, pid=0478, ver=0107, usepage=FF9C, use=0024
03:06:39.364 (ports 2):  devpath=\\?\hid#vid_16c0&pid_0478#8&31719e78&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
03:06:39.365 (ports 2): usb_add: usb:0/140000/0/6/1/1  hid#vid_16c0&pid_0478 (Teensy 4.0) Bootloader
03:06:39.368 (loader): encryption is required, public key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
03:06:39.368 (loader): Device came online, code_size = 2031616
03:06:39.368 (loader): Board is: Teensy 4.0 (IMXRT1062), version 1.07
03:06:39.383 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.hex", 105472 bytes
03:06:39.396 (loader): File "C:\Users\Tim\AppData\Local\Temp\arduino_build_110334\DMAMEMt.ino.ehex", 105472 bytes, 4960 extra
03:06:39.397 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
03:06:39.398 (loader): set background IMG_ONLINE
03:06:39.476 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
03:06:39.477 (ports 2): remove: loc=usb:0/140000/0/6/1/1
03:06:39.477 (ports 2): usb_remove: usb:0/140000/0/6/1/1
03:06:39.477 (ports 2): nothing new, skipping HID & Ports enum
03:06:39.573 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:39.574 (ports 2): nothing new, skipping HID & Ports enum
03:06:39.618 (loader): HID/win32: HidD_GetPreparsedData failed, device assumed disconnected
03:06:39.618 (loader): Device went offline
03:06:39.866 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.866 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.866 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.867 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.867 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.867 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.867 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.867 (loader): HID/win32:  vid:046D pid:C52B ver:1211
03:06:39.872 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
03:06:39.873 (ports 2): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#10379970#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
03:06:39.873 (ports 2): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0279
03:06:39.873 (ports 2): found_usb_device, loc=usb:0/140000/0/6/1/1    Port_#0001.Hub_#0009
03:06:39.873 (ports 2): found_usb_device, devinst=0000001a
03:06:39.873 (ports 2): add: loc=usb:0/140000/0/6/1/1, class=USB, vid=16C0, pid=0483, ver=0279, serial=10379970, dev=\\?\usb#vid_16c0&pid_0483#10379970#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
03:06:39.873 (ports 2):   comport_from_devinst_list attempt
03:06:39.873 (ports 2): found_usb_device complete
03:06:39.873 (ports 2): usb_add: usb:0/140000/0/6/1/1  [no_device] (Teensy 4.0) Serial
03:06:39.878 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:39.878 (ports 2): update_usb_device, devinst list change, old had 1, new has 2
03:06:39.878 (ports 2):   comport_from_devinst_list attempt
03:06:39.878 (ports 2):   found Ports in classguid_list at index=1
03:06:39.878 (ports 2):   port COM9 found from devnode
03:06:39.879 (ports 2): usb_add: usb:0/140000/0/6/1/1  COM9 (Teensy 4.0) Serial
03:06:39.890 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
03:06:39.891 (ports 2): nothing new, skipping HID & Ports enum
03:06:40.364 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
03:06:40.364 (ports 2): nothing new, skipping HID & Ports enum
03:06:53.626 (loader): Open File event
03:06:59.095 (loader): Verbose Info event
 
Published 1.55-beta2 just now.

This is also intermittent and has worked some hundred times.

While not mentioned in the changelog, I did adjust the timing slightly. It's really just a guess, as lots of other things could cause this problem too. If it keeps happening with 1.55-beta2, I'll work on adding a way to get more info about how things went wrong.
 
I'm reviewing the nearly 400 messages on this thread. I missed many of them earlier, especially while I was writing the code security documentation (which took a lot more work than I had anticipated). Trying to make sure my list of known bugs has everything reported.

Regarding the 15 sec restore...

Re #p164
Also not tested 15sec Restore - but it has to FAIL the code upload part as the factory stored 'short' code is not encrypted. I had that wonder the other day but held back - ... Don't suppose the Locked bootloader could leave that Flash Unlocked and when made LOCKED push up a properly Encrypted 'Factory 'short' code and then lock it?

The secure mode lock is controlled by fuse memory inside the IMXRT chip. It's not part of the flash.

Early on, I had a plan for making the 15 second restore work in secure mode, involving storage of a special signature for the blink program which gets restored. But I didn't implement it because I was worried it might create a security vulnerability, at least if done in the way I had originally imagined. That was pretty early in my work with HAB and BEE. Now I believe I might know a way to do it securely, but it's difficult and would probably take several more weeks of work. At this point I believe the best path is to clean up the remaining Teensy Loader GUI stalls and improve the fusewrite sketch (so it won't corrupt already-written fuses if a different key is used) and quickly release 1.55. Those extra weeks would just going to delay important work like FS & MTP integration.
 
I'm reviewing the nearly 400 messages on this thread. I missed many of them earlier, especially while I was writing the code security documentation (which took a lot more work than I had anticipated). Trying to make sure my list of known bugs has everything reported.

Regarding the 15 sec restore...



The secure mode lock is controlled by fuse memory inside the IMXRT chip. It's not part of the flash.

...

Wasn't seeing it as viable, but the 'LOCK' referring to FLASH was the Restore code stored there :: "when made LOCKED push up a properly Encrypted 'Factory 'short' code and then lock it?" ... where the last "it" is the Flash holding the Restore code.
 
May want to clarify under protection: Code, strings, variable & array data can not be read or copied.
That is I assume my sketch can still work with strings and variables...

Ah yes, that's a good point.

I've changed the wording to "Program code (code, strings, variable & array data) can not be extracted from Lockable Teensy in secure mode. Removing & reading the flash chip gives only encrypted data."
 
QUICK note on first calc so far: Decrypt from LOCKED Encrypted T_4 adds 7.5% to runtime versus the three unlocked/unencrypted T_4.0's. - with the current 1,000 cascading calls.
Code:
 Current code just posted here : [URL="https://github.com/Defragster/T4LockBeta/tree/main/Code4Code"][B]T4LockBeta/tree/main/Code4Code[/B][/URL]

.....

Undocumented copy of current run results from 4 Teensy 4.0's - you can guess which is which for now:
Code:
42.0898, 54.33
Complete Count 1000	digit  took 1286852 us [766530580 piCycles] : net 9302

41.6433, 51.16
Complete Count 1000	digit  took 1287843 us [766689424 piCycles] : net 10028

41.1847, 46.68
Complete Count 1000	digit  took 1286849 us [766544700 piCycles] : net 9275

43.3343, 52.02
Complete Count 1000	digit  took 1286909 us [766544182 piCycles] : net 9336

Very interesting that the BEE on-the-fly decryption can have a performance impact. I'm not sure what all these numbers mean. I downloaded it from github and I'm running it here on a Teensy 4.0. It's printing even more numbers without giving a clear idea of which really is the timing result.

Code:
8899780 ENC SM: @600
8899780 ENC SM: @600 Completed CASCADE Count 4000	Cascading took 5141308 us [3065715389 piCycles] : net 31783
Direct calls took 5111748 us [3065846465 piCycles] : net 2004

0.0001, 54.47
8899780 ENC SM: @600 Completed CASCADE Count 4000	Cascading took 8788368 us [943590072 piCycles] : net 7215718
Direct calls took 8734084 us [941192880 piCycles] : net 7165430

8899780 ENC SM: @600 Completed CASCADE Count 4000	Cascading took 8790458 us [944361277 piCycles] : net 7216523
Direct calls took 8732829 us [940571348 piCycles] : net 7165211

8899780 ENC SM: @600 Completed CASCADE Count 4000	Cascading took 8792401 us [946042024 piCycles] : net 7215665
Direct calls took 8733997 us [941138268 piCycles] : net 7165434

Is there any chance you could turn this into a benchmark program that's simple to run and see the result?
 
Very interesting that the BEE on-the-fly decryption can have a performance impact. I'm not sure what all these numbers mean. I downloaded it from github and I'm running it here on a Teensy 4.0. It's printing even more numbers without giving a clear idea of which really is the timing result.

Code:
8899780 ENC SM: @600
8899780 ENC SM: @600 Completed CASCADE Count 4000	Cascading took 5141308 us [3065715389 piCycles] : net 31783
Direct calls took 5111748 us [3065846465 piCycles] : net 2004

0.0001, 54.47
8899780 ENC SM: @600 Completed CASCADE Count 4000	Cascading took 8788368 us [943590072 piCycles] : net 7215718
Direct calls took 8734084 us [941192880 piCycles] : net 7165430

Is there any chance you could turn this into a benchmark program that's simple to run and see the result?

Cool that you look and ran it! ... Code4Code.ino

I can give it a look. As posted indeed it runs forever - doing the same thing - and currently it starts the _isr() at high rate slowing the loop() test tremendously.

Primary goal was {shotgun spec} to stuff a lot of code and reference data in FLASH and see that it:
A: Worked at all - some repeat task that worked out a known result of 60 Pi digits.
B: Could deal with odd ptr[] boundary reads, sizes, directions in the added _isr()
C: Dealt with Code Cache being a bit to small - for some 100 KB's
D: Dealt with data Cache being a bit small for 4,000 copies of const szPi[64] == 256KB
E: Then monitoring cycles used I found some measure of the run rate
F: Run Forever meant it could show changing Temp
G: Run the 4,000 cascading func####()'s - or call the terminal Func0() 4,000 times

I finished the spec'd task list and all seemed well and first indication was ~5% overhead ...
 
If my sketch crashes and I have
Code:
  Serial.print(CrashReport);
The crash report (as well as other stuff early on in next run) shows up in the Serial Monitor window when I use the (not in the build)
USB type of MTP Disk Serial (Experimental)

Looking into this today.

I'm guessing your program may have "Serial.begin(9600)" but not "while (!Serial) ; //wait" before it tries to print the CrashReport info?

1.54 added a 0.7 or 2.0 second wait in Serial.begin(), but only for actual USB serial. It wasn't implemented for HID serial emulation. It was also only done on Teensy 4, not on Teensy 3. I've committed a fix.

https://github.com/PaulStoffregen/cores/commit/285ecd2c1bdb69dec3687107f4b805ae572db6a0
 
Looking into this today.

I'm guessing your program may have "Serial.begin(9600)" but not "while (!Serial) ; //wait" before it tries to print the CrashReport info?

1.54 added a 0.7 or 2.0 second wait in Serial.begin(), but only for actual USB serial. It wasn't implemented for HID serial emulation. It was also only done on Teensy 4, not on Teensy 3. I've committed a fix.

https://github.com/PaulStoffregen/cores/commit/285ecd2c1bdb69dec3687107f4b805ae572db6a0

The changes look good - and user can avoid 2 second wait removing the Serial.begin() and it will come up when it connects if included.

Not sure but issue noted in that post may relate to sluggish USB connect when MTP negotiation is ongoing. At least it seemed that way months back when I was running that code. if (Serial) wouldn't show true until after MTP fired up and perhaps was running ... sometimes after leaving setup() into loop(). I did something in a post back then that seemed to help - but stalling kept the MTP from starting?
 
Looking into this today.

I'm guessing your program may have "Serial.begin(9600)" but not "while (!Serial) ; //wait" before it tries to print the CrashReport info?

1.54 added a 0.7 or 2.0 second wait in Serial.begin(), but only for actual USB serial. It wasn't implemented for HID serial emulation. It was also only done on Teensy 4, not on Teensy 3. I've committed a fix.

https://github.com/PaulStoffregen/cores/commit/285ecd2c1bdb69dec3687107f4b805ae572db6a0

Hi Paul,

This I believe is very specific to MTP and it's interactions with Serial or Serial Emualtion...
I have discussed more of it in the thread: https://forum.pjrc.com/threads/6813...ng-MTP-and-MSC?p=288117&viewfull=1#post288117

But the code sort of started off like:
Code:
#define DBGSerial Serial
void setup()
{
  // Open serial communications and wait for port to open:
  DBGSerial.begin(115200);
  while (!DBGSerial && millis() < 5000) {
    // wait for serial port to connect.
  }
  DBGSerial.print(CrashReport);
  DBGSerial.println("\n" __FILE__ " " __DATE__ " " __TIME__);


  DBGSerial.print("Initializing MSC Drives ...");

  mtpd.begin(); //New method removing need to initize MTPD

  DBGSerial.println("Initializing LittleFS and/or SD Drives");
  storage_configure();

  DBGSerial.println("MSC and MTP initialized.");

  menu();

}
And the code would typically hang for the 5 seconds on the while loop waiting for Serial. ...

My current theory is that there is an issue where in the current release code, when the PC sees that it is an MTP device it sends out a request to the MTP Interface, to say lets start a Session... With the current code we will not receive and process this message until the complete setup code completes and the code in loop() calls mtpd.loop()...

During this time, I don't believe the Serial objects are for example receiving or processing the Special message to say that the Serial Monitor is there and ready to go... Serial and Emulated Serial react differently during this.
Serial - Will then output the stuff up till then...
Emulated Serial - appears to not output anything up until that point.


In my current debug branch, I have the MTPD code early on start up an Interval timer to receive these messages and respond with valid data for some messages or DEVICE_BUSY for everything else... I also have some other hacking going on during this as well, (I output everything to a quick and dirty memory stream, and once Serial is valid, it dumps that memory stream to Serial...

More in the other thread.
 
Hi Paul,

This I believe is very specific to MTP and it's interactions with Serial or Serial Emualtion...
I have discussed more of it in the thread: https://forum.pjrc.com/threads/6813...ng-MTP-and-MSC?p=288117&viewfull=1#post288117
...
And the code would typically hang for the 5 seconds on the while loop waiting for Serial. ...

My current theory is that there is an issue where in the current release code, when the PC sees that it is an MTP device it sends out a request to the MTP Interface, to say lets start a Session... With the current code we will not receive and process this message until the complete setup code completes and the code in loop() calls mtpd.loop()...
...

Yeah - 'that'... the host sees device presenting MTP and focuses on that before standard Serial it seemed.

I can't find my prior post in prior thread (early abandoned) ... I found something that inspired a faster usable Serial ... in the state of the code at that time ... didn't seem then that post got noticed ...
 
Paul - follow on to the above posting about not seeing crash report...
Here is a stupid simple sketch:
Code:
#include <LFS_MTP_Callback.h>
#include <MTP.h>
#include <SDMTPClass.h>
#include <Storage.h>
#include <USB_MSC_MTP.h>

void setup() {
  while (!Serial && millis() < 5000) ;
  Serial.begin(115200); 
  Serial.print(CrashReport);

  Serial.println("Enter something to go boom");
  while (Serial.read() == -1);
  uint8_t *ptr = 0;
  *ptr = 99;
}

void loop() {
  
}
Compile it with MTP as USB type.

Open up Serial Terminal... Nothing will display
Enter something... It will reboot after the 10 seconds... Again nothing shows up...

EDIT: Note I am running on Windows 10...
Have not tried on Ubuntu yet... Note: MTP code can run on Ubuntu... Will talk more about that on appropriate therad.
 
Paul - follow on to the above posting about not seeing crash report...
Here is a stupid simple sketch:
...

@KurtE - tried to build sketch.

Got the latest 5 from Github >> Teensyduino-File-System-Integration-including-MTP-and-MSC

Ended up getting this:
Code:
Linking everything together...
"T:\\Arduino_1.8.16_155\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TT:\\Arduino_1.8.16_155\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_228521/MTP_Boom.ino.elf" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_228521\\sketch\\MTP_Boom.ino.cpp.o" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_228521\\libraries\\MTP_t4\\LFS_MTP_Callback.cpp.o" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_228521\\libraries\\MTP_t4\\MSC_MTP_Callback.cpp.o" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_228521\\libraries\\MTP_t4\\MTP.cpp.o" 
...
"C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_228521\\libraries\\Time\\Time.cpp.o" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_228521/..\\arduino_cache_786345\\core\\core_teensy_avr_teensy40_usb_mtp,speed_600,opt_o2std,keys_en-us_81236e5e254cc6e65443778b67d59786.a" "-LC:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_228521" -larm_cortexM7lfsp_math -lm -lstdc++
[B]C:\Users\Tim\AppData\Local\Temp\arduino_build_228521\libraries\MTP_t4\SD_MTP_Callback.cpp.o:(.bss.pfsLIB+0x0): multiple definition of `pfsLIB'
C:\Users\Tim\AppData\Local\Temp\arduino_build_228521\libraries\MTP_t4\SDMTPClass.cpp.o:(.bss.pfsLIB+0x0): first defined here
t:/arduino_1.8.16_155/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions
C:\Users\Tim\AppData\Local\Temp\arduino_build_228521\libraries\MTP_t4\USB_MSC_MTP.cpp.o:(.bss.pfsLIB1+0x0): multiple definition of `pfsLIB1'
C:\Users\Tim\AppData\Local\Temp\arduino_build_228521\libraries\MTP_t4\MSC_MTP_Callback.cpp.o:(.bss.pfsLIB1+0x0): first defined here
[/B]collect2.exe: error: ld returned 1 exit status
Multiple libraries were found for "LittleFS.h"
 Used: T:\tCode\libraries\LittleFS
 Not used: T:\Arduino_1.8.16_155\hardware\teensy\avr\libraries\LittleFS
Multiple libraries were found for "SD.h"
 Used: T:\tCode\libraries\SD
 Not used: T:\Arduino_1.8.16_155\libraries\SD
 Not used: T:\Arduino_1.8.16_155\hardware\teensy\avr\libraries\SD
Using library MTP_t4 at version 1.0.0-beta.1 in folder: T:\tCode\libraries\MTP_t4 
Using library LittleFS at version 1.0.0 in folder: T:\tCode\libraries\LittleFS 
Using library SPI at version 1.0 in folder: T:\Arduino_1.8.16_155\hardware\teensy\avr\libraries\SPI 
Using library SD at version 2.0.0 in folder: T:\tCode\libraries\SD 
Using library SdFat at version 2.0.5-beta.1 in folder: T:\Arduino_1.8.16_155\hardware\teensy\avr\libraries\SdFat 
Using library UsbMscFat at version 1.0.0 in folder: T:\tCode\libraries\UsbMscFat 
Using library USBHost_t36 at version 0.1 in folder: T:\Arduino_1.8.16_155\hardware\teensy\avr\libraries\USBHost_t36 
Using library Time at version 1.6.1 in folder: T:\Arduino_1.8.16_155\hardware\teensy\avr\libraries\Time 
Error compiling for board Teensy 4.0.
 
Try removing all header files except MTP.h...

The others were simply extras from current stuff...
 
No Joy?
Were all the used_libs listed above looking right?
Maybe there was an orphaned header - I just over wrote form github ZIPS???
Code:
#include <MTP.h>

void setup() {
  while (!Serial && millis() < 5000) ;
  Serial.begin(115200); 
  Serial.print(CrashReport);

  Serial.println("Enter something to go boom");
  while (Serial.read() == -1);
  uint8_t *ptr = 0;
  *ptr = 99;
}

void loop() {
  
}

Console ... not very consoling :) :
Code:
C:\Users\Tim\AppData\Local\Temp\arduino_build_228521\libraries\MTP_t4\SD_MTP_Callback.cpp.o:(.bss.pfsLIB+0x0): multiple definition of `pfsLIB'
C:\Users\Tim\AppData\Local\Temp\arduino_build_228521\libraries\MTP_t4\SDMTPClass.cpp.o:(.bss.pfsLIB+0x0): first defined here
t:/arduino_1.8.16_155/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions
C:\Users\Tim\AppData\Local\Temp\arduino_build_228521\libraries\MTP_t4\USB_MSC_MTP.cpp.o:(.bss.pfsLIB1+0x0): multiple definition of `pfsLIB1'
C:\Users\Tim\AppData\Local\Temp\arduino_build_228521\libraries\MTP_t4\MSC_MTP_Callback.cpp.o:(.bss.pfsLIB1+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
 
THIS >> "Maybe there was an orphaned header - I just over wrote from github ZIPS???"

I emptied the MTP folder and dumped in the ZIP and then no errors.

But the sketch doesn't run right :) :)

Wish I could find my forgotten post ... there was something that occurred in context 'back then' that was added triggered Serial to come online ...
 
If you run the sketch with the Serial Termainal window open.
Nothing exciting:
Screenshot 2021-09-10 160251.jpg
Noticed it is connected, but empty after a bit put the mouse cursor into the area type something and hit enter..

It will then fault and after the fault reset, it will come back up... Hopefully
I should probably try it out on an unmodified usb_desc.h...

Mine is slightly modified to make the emulated serial as 1 and MTP 2... where released is 2 1
 
There were double Smileys with not 'right' :)

I got that far and still wishing I could recall the 'epiphany' I posted before to try again ...

So far I got this ... blink mostly off ... then mostly on and it sat forever until I added the BREAK for .available() - though how it has that when no Serial is odd?
Code:
#include <MTP.h>
#include <SDMTPClass.h>
#include <Storage.h>
#include <USB_MSC_MTP.h>

void setup() {
  pinMode( 13, OUTPUT );
  digitalWrite( 13, 1 );
  while (!Serial && millis() < 5000) {
    delay( 50 );
    digitalWrite( 13, 0 );
    delay( 200 );
    digitalWrite( 13, 1 );
  }
  Serial.begin(115200);
  digitalWrite( 13, 0 );
  while (!Serial ) {
    delay( 250 );
    digitalWrite( 13, 0 );
    delay( 50 );
    digitalWrite( 13, 1 );
   [B] if ( Serial.available() ) break;[/B]
  }

  Serial.print(CrashReport);

  Serial.println("Enter something to go boom");
  while (Serial.read() == -1);
  uint8_t *ptr = 0;
  *ptr = 99;
}

void loop() {

}
 
@defragster @Paul @mjs513...

Sorry I know I may not be explaining this very well.

But I was simply trying to give a minimal case that shows, that if you do not make the MTP USB interface happy and respond to a USB request from the other side, then the Serial (and Emulated Serial) objects won't be happy either.

As mentioned in the other thread, I have found that I can get these to respond once MTP responds. There are/will be other tricky chicken and Egg ordering thing on when we should respond with data, delay responding, or respond that we are busy...
But I thought I would mention basic test case...

Paul - I am not sure any of this is something you may want to tackle during this release cycle. Only cases I can potentially see would be if you thought that the USB Descriptor for MTP could be improved...
My MTP one is slightly modified from the current ones in builds. Mainly the order of the Interfaces...

I changed it to be closer to that of Audio...

Code:
#elif defined(USB_MTPDISK_SERIAL)
  #define VENDOR_ID             0x16C0
  #define PRODUCT_ID            0x0476 //fake an include everything device
  #define RAWHID_USAGE_PAGE 0xFFAB  // recommended: 0xFF00 to 0xFFFF
  #define RAWHID_USAGE    0x0200  // recommended: 0x0100 to 0xFFFF
  #define DEVICE_CLASS    0xEF
  #define DEVICE_SUBCLASS 0x02
  #define DEVICE_PROTOCOL 0x01

  #define MANUFACTURER_NAME     {'T','e','e','n','s','y','d','u','i','n','o'}
  #define MANUFACTURER_NAME_LEN 11
  #define PRODUCT_NAME          {'T','e','e','n','s','y',' ','M','T','P',' ','D','i','s','k','/','S','e','r','i','a','l'}
  #define PRODUCT_NAME_LEN      22
  #define EP0_SIZE              64

  #define NUM_ENDPOINTS         5
  #define NUM_INTERFACE         3
  #define CDC_IAD_DESCRIPTOR    1
  #define CDC_STATUS_INTERFACE  0
  #define CDC_DATA_INTERFACE    1 // Serial
  #define CDC_ACM_ENDPOINT      2
  #define CDC_RX_ENDPOINT       3
  #define CDC_TX_ENDPOINT       3
  #define CDC_ACM_SIZE          16
  #define CDC_RX_SIZE_480       512
  #define CDC_TX_SIZE_480       512
  #define CDC_RX_SIZE_12        64
  #define CDC_TX_SIZE_12        64

  #define ENDPOINT2_CONFIG  ENDPOINT_RECEIVE_UNUSED + ENDPOINT_TRANSMIT_INTERRUPT
  #define ENDPOINT3_CONFIG  ENDPOINT_RECEIVE_BULK + ENDPOINT_TRANSMIT_BULK

  #define MTP_INTERFACE         2 // MTP Disk
  #define MTP_TX_ENDPOINT       4
  #define MTP_RX_ENDPOINT       4
  #define MTP_EVENT_ENDPOINT    5
  #define MTP_TX_SIZE_480       512
  #define MTP_RX_SIZE_480       512
  #define MTP_TX_SIZE_12        64
  #define MTP_RX_SIZE_12        64
  #define MTP_EVENT_SIZE        32

  #define MTP_EVENT_INTERVAL_12 10  // 10 = 10 ms
  #define MTP_EVENT_INTERVAL_480 7  // 7 = 8 ms

  #define ENDPOINT4_CONFIG  ENDPOINT_RECEIVE_BULK + ENDPOINT_TRANSMIT_BULK
  #define ENDPOINT5_CONFIG  ENDPOINT_RECEIVE_INTERRUPT + ENDPOINT_TRANSMIT_INTERRUPT  // ????
 
Status
Not open for further replies.
Back
Top