I set TyComm Beta to not upload - it refuses without an ENV var set that I removed. It also - like TeensyLoader when 'Not Auto' will see a Teensy in Bootloader and ignore it until told to upload - unless it initiated it - but to rule that out I'm not starting it - I've been using it only because it allows Dual (+) Serial Monitor windows - and this is a twin T4 test.
No TyComm - Did a Verify Build - TeensyLoader opened - only the two T4B2m's active t1 and t2. Two T4's have all 7 Serial# ports cross wired to each other.
> Program t1 then t2 - timing was okay.
> Program t1, saw Reboot TLoader msg, pressed Button on t2
>> Deactivated AUTO, gave message about 'too fast'
> In this case t1 was left programmed, t2 was left in bootloader
>> … pressed button the 'too fast' message went away but not programmed … repeat press 'TLoader shows normal press button image, then back to MCU image' similar … Pressed AUTO and it was programmed:
View attachment TwinT4Button.txt
> Removing 5V power and restoring 5v returns to 'Button' image - but no Auto so Button just goes to MCU image - maybe this is normal once interrupted until 'AUTO' reenabled.
You are correct - it normally works right. Pressing t2 Button too fast properly programs the t1, then halts with t2 in bootloader w/fast message.
In setup() for t1 it does LED_BUILTIN blink { so programmed and running at least 300 ms } and pressing t2 Button then can generate the 'too fast' "Automatic mode has been disabled …" - given it is on a different USB port I wouldn't expect that (unless by design) - or in the transition it conflates t2 Button with t1 device just programmed - in which
case there may be a window where the blank for t2 Button hits t1? {
if not this then there is no issue I can repro easily }
>> Though GENERALLY it works - I just alternated programming t1...t2..t1... as the setup LED was blinking and got away with it like 5 times {not rushing after first LED blink 100ms on/off/on } before 'too fast', but no Dual RED LED's repro
I cannot repro the DUAL RED LEDS just now - it is almost like t1 was programmed, t2 Button caused it to Blank t1, and then leave t2 in bootloader - perhaps I hit it at the exact right moment programming t1 was done and it responded to t2 Button by blanking the still 'active' t1?
Another ODD thing - Seems this relates to a prior issue where a T4 in this state would stay offline that you corrected by restarting USB when repowered, which is happening - but somehow the 'unpowered' T4 is semi conscious with UART & VBat power.
> When I started the IDE the one T4 was 'switched' off - the 5V line was 'open' Data +/- and GND still connected and VBat installed, 7 UART pairs connected from active T4 - but the IDE loaded and showed both T4's in Ports menu. Once TLoader was active - turning it on and off showed '_DEVICEREMOVECOMPLETE' message and then it was then not on the port menu:
Repeating that then Manually opened TLoader ( teensy.exe ) and Verbose shows this - is that two T4's reported?
Code:
02:36:15.130 (loader): Teensy Loader 1.47-beta4, begin program
02:36:15.469 (loader): Listening for remote control on port 3149
02:36:15.470 (loader): initialized, showing main window
02:36:15.584 (loader): HID/win32: vid:046D pid:C534 ver:2901
02:36:15.584 (loader): HID/win32: vid:1B80 pid:B406 ver:0100
02:36:15.585 (loader): HID/win32: vid:046D pid:C534 ver:2901
02:36:15.585 (loader): HID/win32: vid:1B80 pid:B406 ver:0100
02:36:15.586 (loader): HID/win32: vid:0764 pid:0501 ver:0001
02:36:15.586 (loader): HID/win32: vid:1B80 pid:B406 ver:0100
02:36:15.586 (loader): HID/win32: vid:046D pid:C534 ver:2901
02:36:15.587 (loader): HID/win32: vid:1B80 pid:B406 ver:0100
02:36:15.587 (loader): HID/win32: vid:046D pid:C534 ver:2901
02:36:20.444 (loader): Verbose Info event
Did a verify after verbose and no 'Remove' reported and both are still in the Port list.
To verify opened TyComm ( then closed ) it shows that T4 as ''running' but an 'x' through connect on highlighted/selected T4:
Verbose logged this when I switched the 5V back on:
Code:
02:44:43.044 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
02:44:43.050 (loader): remote connection 1388 opened
02:44:43.056 (ports 2): remove: loc=usb:0/140000/0/8/6
02:44:43.056 (ports 2): usb_remove: usb:0/140000/0/8/6
02:44:43.056 (ports 2): nothing new, skipping HID & Ports enum
02:44:43.085 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
02:44:43.086 (ports 2): nothing new, skipping HID & Ports enum
02:44:43.086 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
02:44:43.087 (ports 2): nothing new, skipping HID & Ports enum
02:44:43.260 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
02:44:43.261 (ports 2): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#5889290#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
02:44:43.261 (ports 2): found_usb_device, loc=usb:0/140000/0/8/6 Port_#0006.Hub_#0009
02:44:43.261 (ports 2): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0279
02:44:43.261 (ports 2): found_usb_device, devinst=00000001
02:44:43.262 (ports 2): add: loc=usb:0/140000/0/8/6, class=Ports, vid=16C0, pid=0483, ver=0279, serial=5889290, dev=\\?\usb#vid_16c0&pid_0483#5889290#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
02:44:43.262 (ports 2): comport_from_devinst_list attempt
02:44:43.262 (ports 2): found Ports in classguid_list at index=0
02:44:43.262 (ports 2): port COM30 found from devnode
02:44:43.262 (ports 2): found_usb_device complete
02:44:43.264 (ports 2): usb_add: usb:0/140000/0/8/6 COM30 (Teensy 4-Beta2) Serial
02:44:43.344 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
02:44:43.344 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
02:44:43.346 (ports 2): nothing new, skipping HID & Ports enum
02:44:43.392 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
02:44:43.393 (ports 2): nothing new, skipping HID & Ports enum
> There is something odd about 'garbage' showing from t1 UARTS when t2 is removed - but until I can see it isn't my code ... the buffer is set [0]=NULL before & after each use now - and added return check on .readBytes() ???