Teensy 4 disconnecting from Windows 11 every 10.5 seconds (descending blip-blip sound)

G

geof

Member
(Edit: Problem solved! See below.)

Hello,
If someone has faced this issue before, or similar, could you please advise me on what may be causing this? Below is a summary of the problem, and below that some more relevat facts.
Thank You in advance!!
-Geof

Summary:

I am using the latest PlatformIO to program a Teensy4 on a long-running big project, which involves use of serial communication (via Serial) to a COM port. Suddenly, for no reason I can think of, when the Teensy4 is plugged in and running the program, I hear the descending "blip blip" that the operation system gives when a device is unplugged, and it repeats every 10.5 seconds (I measured it- it is regular). When this happens, I am unable to establish a COM port link with the Teeny4. The program compiles and uses no dynamic memory allocation (other than what standard Arduino/Teensy functions may already perform).

More details:

* Windows 11
* Using PlatformIO with the Teensy40 framework and Teensy40 environment
* It is a large program that I have been working on / building for several years without issue, even with fast speed serial communications between the Teensy4 and MATLAB. I've reduced array sizes to allow plenty extra heap memory in case.
* I've tried a) a fresh Teensy4 with nothing attached (other than USB to computer), b) rebooting the PC, c) restarting PlatformIO, d) different USB cable, e) different USB port
* For commenting out code I've tried commenting out code. Sometimes with code commented out it stops behaving like this, but with differnet code commented out the error returns. I haven't found any logic between code commented out and not. Though there is one handler that monitors Serial bytes coming in from the PC (essentially checking Serial.available() and running a handler if data has been received). That handler is unchanged for two years. When I comment it out the error disappears. When I comment it out and replace it with a simple Serial.available() check the error still disappears. However with different code commented out, I can have that function uncommented and the program runs fine.

I have not yet tried a different PC or reinstalling PlatformIO. Also I have not yet tried the Arduino IDE, however my program has a complex library and header structure that I'd rather not subject to the Arduino IDE. :)

Could this be something particular to PlatformIO? I've enjoyed it immensly in the past but it may be that I should try another IDE. I'm curious your thoughts on this.

Again, I really appreciate your help. Can I send a bottle of whisky? :)

Edit: Problem is solved. I am summarizing what I learned here in case anyone else faces this:
(1) The regular disconnecting was due to the Teensy4 crashing and rebooting due to some fault.
(2) In my case, the error was due to a function that was declared to return an "int", however the body of the function did not return anything.
(3) Also in my case, I was using code that compiled and worked over a year ago, but no longer worked recently. This is because the toolchain has had a substantial update, including using a different compiler, and the new compiler is less tolerant to poor coding such as my (2) above
(4) It is recommended that one address not only the "errors" that the compiler finds, but "warnings" as well, as some of these warnings identify issues that may cause the Teensy4 to crash, even sporadically or seemingly without logic (such as crashes occurring or not occurring due to commenting out different unassociated code)
(5) Tools that can also help identify the cause of a crash include the CrashReport added in Teensyduino 1.54 and the associated "breadcrumbs" feature added in Teensyduino 1.57.
 
Last edited:
Your program is crashing. The USB disconnection noise is caused by the Teensy restarting itself, which happens automatically when an unhandled fault is detected.
 
@Paul Thank You for that. I read about CrashReport and the breadcrumbs feature (nice work!!) and tinkered with it a bit. Very ironically, it is the act of using Serial.print(CrashReport) that now seems to be causing the crash, e.g. the code

Code: 
void setup() {
    CrashReport.breadcrumb(1,0xAA);
    pinMode(2,OUTPUT);
    CrashReport.breadcrumb(1,0xAB);
    Serial.begin(115200); // Serial port to PC via USB
    CrashReport.breadcrumb(1,0xAC);
    if (CrashReport)
        Serial.print(CrashReport);
    CrashReport.breadcrumb(1,0xAD);
    ...

is causing the crash report

Code: 
CrashReport:
  A problem occurred at (system time) 0:4:19
  Code was executing from address 0x1FB4
  CFSR: 82
    (DACCVIOL) Data Access Violation
    (MMARVALID) Accessed Address: 0x14 (nullptr)
      Check code at 0x1FB4 - very likely a bug!
      Run "addr2line -e mysketch.ino.elf 0x1FB4" for filename & line number.
  Temperature inside the chip was 61.94 °C
  Startup CPU clock speed is 600MHz
  Reboot was caused by auto reboot after fault or bad interrupt detected
  Breadcrumb #1 was 172 (0xAC)

If I can add more details shed light- Most of my coding of this project was in the year 2020 to 2022 timeframe. I made no updates to the project from about November 2022 until this past December 2023. One peculiarity I noticed is that when I opened PlatformIO, it updated the toolchain- I am guessing this was the latest Teensyduino (and possibly a new compiler if I read your Teensyduino version history correctly).

When I recompiled the project using the latest toolchain, the data memory did not fit. (In other words, the project compiled in Nov 2022 but not in Dec 2023 after the toolchain update.) So I had to reduce some variable sizes. It compiled, but the serial interface with MATLAB still did not work. I reduced the variable sizes further and all worked again. However as I made updates to the code, the serial link would sometimes work and sometimes not, often without a clue why. For example once I added a function but did not call it and that was enough to break the serial link. Another time I added a class object (with just ~10-20 bytes of member variables) and the act of just declaring one object of that class was enough to break the serial link.

EDIT: To clarify- Dec 2023 I started working with the project again and discovered the exact same code from Nov 2022 no longer compiled. Then in Dec 2023 and these past few weeks I started discovering the above peculiarities, but was able to progress by just playing with code until I got the serial working. Today is the first day I noticed it rebooting every 10 1/2 seconds, even after commenting out a lot of code.

I get the sense that the latest toolchain is a bit more strict than a year ago. Does this make sense?
 
Last edited:
PS I found some posts on how to use addr2line, but could not find where to run that program. I did add the -g compiler option (I think...). But the breadcrumb feature is probably good enough. One can fit a lot of tracking into 6 32-bit breadcrumbs...
 
Well no... You're setting the breadcrumb to 0xAC and then printing the crashreport... which is printing the details of the previous crash, with the most recent breadcrumb value written.
If printing the crashreport was actually crashing, it wouldn't be successfully printed. You need to run the addr2line tool as it suggests to see where in your program the actual crash is happening.
 
geof said:
PS I found some posts on how to use addr2line, but could not find where to run that program. I did add the -g compiler option (I think...). But the breadcrumb feature is probably good enough. One can fit a lot of tracking into 6 32-bit breadcrumbs...
Click to expand...

Take a look at <this> thread. Make sure to read further down to get the correct path to use when running addr2line.

Hope that helps . . .

Mark J Culross
KD5RXT
 
@jmarsh <insert Homer D'oh> You are correct. Perhaps I've been working on this too long today... Now the program seems to be crashing depending on how many breadcrumbs I insert. In other words, suppose the program crashed after breadcrumb is set to "10". Then before that I add code to set the breadcrumb to "5". Now the program no longer gets to 10.
@kd5rxt-mark Thank You. I did see that thread and others particular to finding addr2line on PlatformIO. I've had no luck finding that program (or variations of it) anywhere. I think I did find the .elf file though. 73 DE AA3RQ
Good night. I think a good night sleep will help. Thank You all again for your help. -Geof

PS. I think a telling sign is that a project that I compiled and ran successfully in Nov 2022 no longer compiled (verbatim no changes) in Dec 2023, so something that worked before no longer works now due to the interaction of the toolchain with my code. Probably I have been doing something wrong this whole time that didn't matter until now.
 
I had this start - crash - start - crash sequence recently, when I compiled older programs with new TD 1.59.4. In all cases, the use of Wire was the culprit. Changing the way Wire was initialized and used resolved the problem. I guess this has to do with new GCC toolchain.
 
WMXZ said:
I had this start - crash - start - crash sequence recently, when I compiled older programs with new TD 1.59.4. In all cases, the use of Wire was the culprit. Changing the way Wire was initialized and used resolved the problem. I guess this has to do with new GCC toolchain.
Click to expand...
Odd- does adding Crashreport present any info before restart? It wait 8 seconds before restart.
Is there a simple sketch that does a repro? Wire and no device required and setup() or whenever does the restart?
 
defragster said:
Odd- does adding Crashreport present any info before restart? It wait 8 seconds before restart.
Is there a simple sketch that does a repro? Wire and no device required and setup() or whenever does the restart?
Click to expand...
Well, as I could overcome the issue, I did not enquire further. As the OP asked for similar experience, I gave my own one. Maybe I can try to reproduce the problem as I have still earlier versions of the code.
 
@WMXZ Thank You for the response and for confirming this is indeed a new toolchain. I did have #include <wire.h> but never actually initialized/opened/used it. I commented that out. I am still getting the same error message.

Any anecdotes are really helpful!

Right now, according to the breadcrumbs, the program is crashing somewhere in the instance of the fast ADC from the ADC.h library:
Code: 
#include <ADC.h>
..
ADC *FastADC; // global variable towards top of main.cpp
...
    // this is in setup()
    FastADC = new ADC();
    FastADC->adc0->setAveraging(FASTADC_AVERAGING);
    FastADC->adc0->setResolution(12);
    FastADC->adc0->setConversionSpeed(ADC_CONVERSION_SPEED::VERY_HIGH_SPEED);
    FastADC->adc0->setSamplingSpeed(ADC_SAMPLING_SPEED::VERY_HIGH_SPEED);

I correct my earlier statement that I did not use any dynamically allocated variables. :) I may have one or more of things like this elsewhere in the code, but nothing big and certainly no sophisticated data structure arrays. (I am a mere engineer, not a computer scientist! ;) )

I've other things to take care of today, but will get back to this in the evening
-Geof

Edit: Corrected CODE /CODE use and grammar, added statement about dynamically allocated variables.
 
Last edited:
geof said:
PS. I think a telling sign is that a project that I compiled and ran successfully in Nov 2022 no longer compiled (verbatim no changes) in Dec 2023
Click to expand...

Does PlatformIO give you a way to install the older version of the Teensy software?

My other suggestion is to pay close attention to any compiler warnings. In Arduino IDE we always compile with "-Wall" but PlatformIO gives you control to change the compiler settings, so make sure you have "-Wall" to actually see the compiler warnings.

For a specific case, just a few days ago we had someone who was sure the new GCC had a bug because his code worked on the old version. After many messages he finally showed the code. It showed several compiler warnings and I and others copied into Arduino and clicked Verify. In the end, it turned out the newer GCC is less forgiving about functions declared to return a value but don't actually have a return value. All versions give a compiler warning. But it works on the old version and the warning is harmless. Not so with the newer version. My guess is the newer version has more sophisticated "global" optimization between functions, where older traditional optimization (without LTO) focused mostly on each individual function. So not returning a value when the function is declared as returning something can cause problems, even though it worked on the old version. In the end, his code worked with the new version once the function was changed to "void" rather than declared to return something.
 
PaulStoffregen said:
For a specific case, just a few days ago we had someone who was sure the new GCC had a bug because his code worked on the old version. After many messages he finally showed the code. It showed several compiler warnings and I and others copied into Arduino and clicked Verify. In the end, it turned out the newer GCC is less forgiving about functions declared to return a value but don't actually have a return value.
Click to expand...
... can confirm an upload where ignoring/missing a warning about a function failing to return as declared will CRASH in a non helpful way - i.e. Very Ugly. Saw/Posted it some months back - forget the context - may have been a wasted HOUR on a Live Chat with @shawn?

Indeed, it was back in May 2023:
defragster said:
Lesson Learned: CHECK console output for WARNINGS!
- talked about UDP Chat example mod was failing ... called out to class member that expected 'int' return and func() had no return
>> Resulted in CrashReport !!!
Click to expand...
 
@Paul @defragster Indeed, I had a function that was declared as type int but did not return anything, and it was called during setup(). I fixed that and my heavily commented out program suddenly worked. And indeed I have a zillion compiler warnings that I ignored in the past because, well, they're just warnings, right? (The only thing more dangerous than a computer scientist with a soldering iron is an engineer with a compiler, as Wise Man once said...) I am going to restore my original program and see if in between 1) making function declarations consistent with their returns and 2) addressing other warnings, that I can make this thing work! I will report on that in a day or two, but until then, Many Thanks!!!
 
Maybe we should consider using something like "-Werror=return-type" for the compiler options?

Or maybe some of the problem is we're using -fpermissive because some old Arduino libraries don't compile. As I recall, the issue there was -Wnarrowing. Maybe it's time to reconsider whether we should be compiling with -fpermissive?
 
PaulStoffregen said:
Maybe we should consider using something like "-Werror=return-type" for the compiler options?

Or maybe some of the problem is we're using -fpermissive because some old Arduino libraries don't compile. As I recall, the issue there was -Wnarrowing. Maybe it's time to reconsider whether we should be compiling with -fpermissive?
Click to expand...
Seems like a good idea, given those things "don't compute" - and the time lost when not fixed before uploading.

What happens with the PJRC random build test without the -fpermissive? Perhaps all such Error>>Warning issues already addressed? So included TD Libs likely would not be any trouble. If so, only issue would be the 'other' included libs - and user code - that break and need to be fixed.

Would be nice to have a console ending line "## Warnings reported" - as the small window for build console can scroll off with unseen warnings (not always in bright color?) scrolled way back ... (like when doing quick edits on a skype call and not watching it and losing an hour like p#16).
 
@Paul @defragster Yay! I can confirm that the error was due to a function not returning a value even though it was declared to do so. I edited my original post at the top to summarize what was learned for future people.

Regarding use of -fpermissive- Speaking as a (primarily) hardware engineer (actually a chip designer) who does enough coding to be dangerous- I prefer the permissive settings, but sometimes I find that the warnings overflow the console output to the point that I occasionally get an error message and it has already scrolled off. I just recompile when that happens- it seems that less warnings get printed if doing a recompile with no changes. Anyway, I just wanted to put that down so you know how one person is (ab)using the toolchain! :)
 
You must log in or register to reply here.
Back
Top