On Try #8 longer run 38600+ seconds … NOTE: IDE was NOT shut down after last #4261 - so been running some time and stable across a few sketches off and on - just closed the faulty t_sermon.
Anyhow - both T4's on their instance running well … going to resize …
FIRST: Single slowish slide lower right corner to smaller window and … SLEEP
SECOND: Single slowish lower right side corner to LARGER window and … SLEEP
So one single attempt to resize those two windows smaller or even larger and both stopped running after 10+ hours.
Found something ELSE to plug into USB - it seems any device that CHIMES IN to Windows USB will WAKE the sleeping t_sermon's
Then the one I made SMALL I dragged larger and it froze and one I made LARGE I dragged smaller and it froze.
Then I unplugged that other USB device and when it CHIMED OUT again BOTH t_sermon's WOKE back to running - now over 40K seconds since last T4 Upload to each of the two.
>> None of these SLEEP/WAKE events of t_sermon in either IDE CONSOLE showed any messages since the last:
TeensyPipeMonitor open usb:0/140000/0/8/7
opened, dev=COM37, name=Serial
REPRO UPDATE: those same two T4's running now at 89730 and 89920 seconds after the above SLEEP and RESTART … time to resize:
#1: Three simple drags narrow , then wide, then diagonal smaller, bigger - No Sleep - then SLOW long narrow and SLEEP at 89829
#2: Same here - grab, drag release no problem. But grab the corner drag as need without release and SLEEP at 90150 secs
>> Plug in a T_3.1 and on arrival running whatever and they BOTH wake and continue.
-- repeat slow corner drag and BOTH SLEEP, close TLOADER, plug in T_3.1 with Button held: Both WAKE and continue on Button release
??:: Seems like GUI processing time perhaps causes miss of USB data grab that then leaves data waiting for attention until USB event wakes the retrieve code?
Other thread I compiled TensorFlow and no errors - didn't scan the warnings - but got flashing LED showing processing, but I have no mic. Posted a quick 'no delay()' hack {with a static brightness and an elapsedMillis var} to make the LED cycle. The LED update code called about 175K/second at 600 MHz so that explains the LED cycling too fast and just being 'on'. Did the call count with T4 at 48 MHz and it was still hitting 17K/sec calls to that update - which is likely still faster than the 64 MHz processor that code was written for.