I'm a little concerned about an infinite rebooting going too quickly. Many PCs take over 1 second just to complete USB enumeration. Windows 7 takes about 5 seconds with some combinations of HID and other interfaces.
Obviously we can't protect or even anticipate all crash scenarios. But we can think about likely ones. I especially want a NULL pointer deref in C++ constructors or early in setup() to result in USB enumeration completing and a least a few seconds for user-level programs on the PC to be able to notice before the hardware disconnects USB and reboots. That was the reasoning behind 8 seconds.
No perfect answer. Given a new/unknown feature and only valid with SerMon online - or Serial# ready to receive. And given how rare Faults are getting it 'known' won't likely happen fast or even be noticed/understood.
Currently a fault/Crash just takes the Teensy stopped into 'wait for usb'.
Assuming the CrashReport scheme will be 'always on' with TD1.54?
So on Crash it will sit 8 seconds ( longer if over temp until cooled? As noted it will cool faster at 24 MHz when a Temp Fault and still work to 'wait for USB' ).
> maybe if temp not 'safe' after some time (30 secs?) it should just shutdown?
Granted, this seems this would be an effective emulation/replacement of current behavior where the user would now see '8 sec reboot' instead, and as noted the Forum could hopefully catch and inform those users about the CrashReport feature.
If it is going to stall 8 secs - and not temp related - it seems equivalent to have the long delay (8 seconds) just before setup() entry while Serial if available comes online to respond to CrashReport ASAP - and then even hardcode the rest of the 'long' wait into return from CrashReport.
Though of course without the call to CrashReport - then there would be 'fast' repeated reboot. Unless there was a 'weak' call the user could add to sketch to replace the default wait for reaction of their choosing.
> That "weak void userCrashReport() { // on prior Crash wait 8 secs }" then enter setup()
> Sketch "void userCrashReport()" - could wait for Serial - or other - and then stream the output to a place of their choosing - that might solve KurtE's issue where it could go to elsewhere.
Not a simple as "if ( CrashReport ) {" - but that would still work, and pasting a template copy of userCrashReport() could give more control?