CrashReport crashes T4 on startup

[pr8x]

Seems that the trying to print out CrashReport crashes my T4 right on startup (I can see it appear as serial device briefly but then it directly disconnects):

if (CrashReport) {
    Serial.print(CrashReport);
}

Not sure if this directly related with CrashReport. I often get really weird crashes when trying to call certain functions from LVGL. For example having a call to (not even calling it yet) lv_spangroup_create in my code causes the T4 to crash instantly. I was trying to narrow down the issue by commenting parts of the function until I reached some utf8 handling code where it did a bunch of bit shifting. Uncommenting that part fixed the crash. This seems really weird and my intuition tells me there's certainly some other problem at play here. Honestly have no idea how I can even properly diagnose this though.

I am using Teensyduino 1.57 (via PlaformIO). Also have dual serial enabled for TeensyDebug (which doesn't seem to work, but that's a different issue I guess).

 

[defragster]

After sending the CrashReport to USB for transmit the code continues as written.

If the Crash is encountered again it will just cycle until the cause is eliminated.

Try:

if (CrashReport) {
    Serial.print(CrashReport);
    delay(20000); // wait 20 seconds before continuing, this prevents RAPID repeat crashing and also assures the USB has time to transfer the current CrashReport.
}

Also need to make sure Serial is online before printing otherwise the CrashReport data is cleared after .print().
If the complete set/paragraph of output is displayed then this is not an issue.

So given it crashes repeatedly after that .print() - the reason it is crashing again is faulty code running into a 'new/repeat' Crash after printing clears the prior CrashReport.

The info in the report should point to a place in the code related to the Crash depending on the nature of the event and using the location information provided.

Also there are "void breadcrumb(unsigned int num, unsigned int value)" calls to place in code to mark progress - if used {values 1-6} they will print the LAST stored 'unsigned int' value:

				CrashReport.breadcrumb( 1, 1 );
// some code
				CrashReport.breadcrumb( 2, 2 );
// some code
				CrashReport.breadcrumb( 1, 3 );
// some code
				CrashReport.breadcrumb( 2, 4 );

 

[PaulStoffregen]

This seems really weird and my intuition tells me there's certainly some other problem at play here.

I agree with this sentiment.

If you want us to help you look for whatever's crashing, rather than trying to trim a huge code base down to something small, try to trim it to code that reproduces the crash on a Teensy 4 without any extra hardware connected. If we can reproduce the problem, odds are much better of someone figuring out what's causing it.

 

[pr8x]

Ok, spent some time investigating the issue and it seems that it has something to do with optimization flags. I was compiling LVGL with -Os since it would otherwise exceed the memory of the Teensy. PIO was set to debug, so -Og I assume. By forcing everything to compile with -Os it does not crash anymore and I am now able to see crash report. Nonetheless this seems really strange. Linking TUs with different optimization levels should not be a problem and if the -Og exceeded available size teensy_memory shouldn't have allowed uploading it .

Interestingly -Os also fixed TeensyDebug for me. It's now properly halting on exceptions.

 

[KurtE]

Couple of thoughts here:

I have had times where the crash is very near to startup code and kept in an endless beep reset, beep reset.
So sometimes I put code in like:
i

f (CrashReport) {
    while (!Serial && millis() < 5000) ; // wait awhile.
    Serial.print(CrashReport);
    Serial.println("Press any key to continue");
    while (Serial.read() == -1) ;
    while (Serial.read() != -1);
}

Depending on the crash sometimes you may have several Serial.prints() queued up and get a hard crash and data lost. And you spend a lot of time debugging something that is not the issue.
So I start doing stuff like: Serial.println("Got here xxx"); Serial.flush();
So that I know the last things debug data went out.

Note there are times where it maybe issue with USB, in which case I might switch to a hardware Serial port, like Serial4 (this is the one that the low level core debug uses when enabled)

Some crashes corrupt the CrashData. Like a very large memory overwrite... Been there. Ended up finding those, by editing the unused_interrupt_vector where it does the crash report
saving and added in debug: printf() statements that printed out similar data that Crash report does.
The printf output only happens if you then turn it on in to debug\printf.h and enable the PRINT_DEBUG_STUFF, which again defaults to Serial4 at 115200

 

[PaulStoffregen]

PIO was set to debug, so -Og I assume.

Oh, that would explain it. A bug in the startup code affecting -Og and -O0 was recently fixed.

I should really get on with a last 1.58 beta and wrap up 1.58 soon, so everyone can get the newer toolchain and some important fixes...

 

[pr8x]

@PaulStoffregen Ah, that's good to hear. Would be nice to get an official beta channel for PlatformIO at some point. I tried following the instructions in but it wasn't working for me. It didn't set the correct gcc path. Would really love to test 1.58 Beta.