Is there a specific USB driver to use? I set up on another computer (without any Arduino or Teensyduino software) and at first the teensy was there as Teensy under an unknown device until the device drivers finished loading/installing then it moved to portable devices as MTP USB DEVICE with a yellow ! next to it and the error message "Device driver software was not successfully installed" came up. BTW the serial port only displays in Device Manager when the port is set to serial. Goes away when set to MTP disk and programed.

Maybe a driver issue?
Or teensyduino? I just don't know.

Thanks for the reply.
I am using a new T3.5 with arduino 1.8.15 and Teensyduino-beta9 with the built-in SD. Both with a fresh install. I'm not sure what you mean "if you declare multiple sd devices (as with mtp-test.ino) : sdx[0] MUST exits." I'm only using the one onboard SD with the out of the box install, do I need to change something in the test program? What versions did you test with and what example program are you using? I have followed the install directions to the letter and tested using the included MPT-test.ino.

Can you review the discussion on the PJRC forum MTP responder? You can see I worked with Defragster on this and verified the SDfat is working and my install is good and working, at least the SD part...

Good Morning Paul Made 1 slight addition to the crash report. I added printing the System clock to report. Only affects crashreport.cpp.

Unless you want to crash the panic temp from shut down to cool down. I can't see me making any other changes.

Let us know when you want to freeze changes to crash reporting.

Thanks Mike

MTP does work on T3.5. Just compiled and run it. compiled with USB type "MTP Disk Serial (Experimental)".

In Device Manager portable device shows as Teensy USB Serial Com port is accessible.

Note: if you declare multiple sd devices (as with mtp-test.ino) : sdx[0] MUST exits. If you are using jumper cables to connect micro sd boards, the spi speed (33 MHz) may be too high. reduce to say 15 MHz.

Work is happening right now on better fault handling and crash reporting. So if you wait a while, we may have 1.54-beta11 with that work included.

no worries, whenever is fine

Expect some delays because I’m currently out of the office, but will give a try most probably begin of July.

Hey, Sorry for the delay. will give a try as soon as I can. thanks for the support.

Good Morning Paul Made 1 slight addition to the crash report. I added printing the System clock to report. Only affects crashreport.cpp.

Unless you want to crash the panic temp from shut down to cool down. I can't see me making any other changes.

Let us know when you want to freeze changes to crash reporting.

Thanks Mike

Tim - see my response in https://forum.pjrc.com/threads/66403-Re-enable-bootloader-interrupts-after-a-hard-fault-Teensy-4-1?p=281920&viewfull=1#post281920

Okay - saw both githubs same 4 hrs old.

It is against first plan to restart - shutdown seems safe path. In your test case of a heating lamp dropping speed wouldn't help - in the real world it might be a fan or airflow failure causing over temp.

Only issue is that the crash data won't survive is power shutdown happens for system restart.

But an ill behaving Teensy in any oddly controlling of critical stuff could wake up and half baked and do bad stuff without supervision.

Also not sure what the Teensy state of I/O is in that 8 second time period? No interrupts or programmatic response can happen - what is the state of the outputs? Are they maintained as last set? Assuming a proper design would fail safe if the Teensy went off/poof ... what is it

Would be nice to commandeer 11 DWORDS of EEPROM for more permanent recall.

Tim: the shutdown on panic alarm. Yes it us. For testing I made set him temp to 50 and panic temp to 55 and ran over clicked at >800

Mike: is this code in the current PJRC github as last merged?

@PaulStoffregen and @Defragster Between sleep cycles and doing this response - I must be crazy. In response

Looks like we still need checking to only start the 8 seconds when temperature is safe.

Right now on panic alarm there is no reboot. The T4.1 shuts down on panic alarm with the following messages:

Reboot was caused by temperature sensor Panic Temp Exceeded Shutting Down Can be caused by Overclocking w/o Heatsink or other unknown reason

If you still want it to restart as opposed to shutdown let me know. I did mention this up on the thread as well. Tim seemed to agree:

Shutdown seems right.

As I said I am leery of continuing to reboot when the cause for the panic temp is unknown. Before the merge tempmon would shutdown the T4 if the panic temp was reached. Agree more than likely its due to overclocking but ....

The only thing I'm wondering is startup.c might have is in https://forum.pjrc.com/threads/66403-Re-enable-bootloader-interrupts-after-a-hard-fault-Teensy-4-1?p=281851&viewfull=1#post281851

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?

Figured not ... doing a flush() that waits forever would be bad.

perhaps auto clear is weak - better to see it twice and then have it clear()'d, than to not get to see it at all if the user codes it wrong - they still can if they do a clear() with a ready stream. Given how easy it is to call Serial.print(CrashReport); it wasn't much harder to overtly call .clear() when the user so chooses confirming the Report was seen ... as the user sees fit to code it.

No, there is no API to query buffer status. But the API does have a flush() function which waits (or is supposed to wait) until all data is actually transmitted.