The fault handler on Teensy 4

Teensy 4.x ( and MicroMod with same 1062 MCU ) in release of TeensyDuino 1.54 offers a CrashReport feature.

It can be tested and printed with code like the following that will expose a Crash if recorded - it will also CAUSE a crash to show the behavior when one was not present to start.

// Typical Usage Example : when a sketch is leaving the Teensy non-responsive // Compile this sketch with USB Serial // With Serial Monitor attaching it will restart and show the CrashReport // If Serial Monitor is not active it will continue to Crash and restart

void setup() { Serial.begin(9600); // With TeensyDuino 1.54 Serial.begin() may return connected if ( Serial && CrashReport ) { // Make sure Serial is alive and there is a CrashReport stored. Serial.print(CrashReport); // Once called any crash data is cleared // In this case USB Serial is used - but any Stream capable output will work : SD Card or other UART Serial } else { // Following code will cause a Fault of the processor from writing to a NULL pointer // Don't run it again until the next restart showing normal after a fault uint32_t *y = 0; y[0] = 5; // Comment or remove this line to preevent causing a Crash } pinMode( LED_BUILTIN, OUTPUT ); }

elapsedMillis blinkTime; void loop() { if ( blinkTime > 1000 ) { digitalToggle( LED_BUILTIN ); blinkTime = 0; } }

In the event of a found CrashReport the persistent ( while powered ) nature of the RAM2/DMAMEM can retain data values in use before the Crash restart can be present on restart after the watchdog time out.

DMAMEM byte myWarmRam[13]; // This array will be in RAM2 and present with prior values on restart. When allocated this way it will reside at a specific location between restarts, and this memory is not zero initialized or otherwise overwritten - unless new code upload has it moved during the build. // As long as the cache was flushed to physical RAM before the Crash arm_dcache_flush(myWarmRam, sizeof(myWarmRam));