Please help me, it's urgent.

C

cho kyungpill

New member
We are currently using Teensy version 4.1 for our development equipment.
However, after a certain period, Teensy reboots and ceases to function properly.
We have checked the related board and I/O, and there are no issues.
Is there a way to disable the reboot function in Tinge 4.1?
What methods are available? Hardware or software solutions are both acceptable.
This is very important to us.
 
How do you conclude that the Teensy reboots?
And what do you exactly mean by "ceases to function properly"? Does it refuse to reboot and run your code again? Very detailed description of the behaviour does help!
Can you do the Memory Wipe as described on this page?
Memory Wipe & LED Blink RestoreTeensy 4.0 will fully erase its non-volatile memory and return the flash memory to a simple LED blink program if the program button is held between 13 to 17 seconds. The red LED flashes briefly at the beginning of this time window. During flash erase, the red LED is on bright. When completed, Teensy 4.0 will automatically reboot and run the LED blink program, causing the orange LED to blink slowly.
Click to expand...

Paul
 
Nothing normal or included in Teensy to do that except a Crash.
If the code is crashing - in which case it would restart after 8 seconds.

Is there any flash or light from the RED LED by the USB connector?

The only other expected way to Halt the Teensy is applying GND to the On/Off pin on the Teeny for about 5 seconds. In which case it will be non-responsive until that same pin is held to GND for another second, or power removed.

When in this state is it connected to a USB Host computer?
If so can that computer perform an Upload without a button press?

If not connected is there any code like:
while (!Serial) ;
In setup() where it is restarting and no Serial Monitor is connecting to allow that code to pass.
 
PaulS said:
How do you conclude that the Teensy reboots?
And what do you exactly mean by "ceases to function properly"? Does it refuse to reboot and run your code again? Very detailed description of the behaviour does help!
Can you do the Memory Wipe as described on this page?


Paul
Click to expand...
Yes, that's correct. If there is code that normally progresses from 1 to 10 to complete, it progresses from 1 to 4, then has a brief delay time before starting again from 1 to 10
 
Last edited:
If you have not already done so, you might try seeing if there is a crashreport or the like:

Something like:
Code: 
while (!Serial && millis() < 4000) {} // wait for up to 4 seconds for Serial monitor
if (CrashReport) Serial.print(CrashReport);

This outputs to Serial, you can have it output to any class that is derived from the Print class.
Note: Stream is derived from Print.
Classes like HardwareSerial, File, ... are derived from Stream.

So for example you could log it to a log file as well.
 
Is there a pin map for reboot or reset the teensy4.1 board?
Currently Teensy4.1 has I/O related sensors and such connected. Could that be the problem?
 
Last edited:
There is no reset pin. It reboots when the program crashes. If it didn't, it would just hang indefinitely so disabling the reboot function won't achieve anything.
Add the code that Kurt posted above to see where the crash is happening so you can fix it.
 
As KurtE said, you really should try to retrieve the crash dump to see if it was filled out with information about the reason for reset. You may be experiencing a brown out due to activating sensors. Or, you may be overflowing memory. Or, there could be a null pointer deref or any number of other things. You really need to get it to tell you why it crashed before you have much hope of finding the cause.
 
Post #3 asked about various things ... unanswered.

OP didn't mention 8 second restart - so not a crash?

Given answer to that then CrashReport would make sense ...
Not sure if connected to a Host? USB Active to SerMon - is there a while (!Serial) halting the Crash restart if so?

Is it really halted - maybe USB running and an Upload from Host would work - which would be odd but telling ...

Is OFF somehow being triggered? Would ON bring it back?
 
He did say "after a certain period, Teensy reboots".

If the certain period is approx 8 seconds, that would strongly suggest a software fault.

This thread is really reminding me that I had a to-do item of writing a web page to document CrashReport and breadcrumbs after the 1.59 release. (as today's it's only documented with examples and forum conversations) Maybe tonight would be the perfect to finally get around to that work...
 
Another blind guess... we've seen other projects where certain usage of C++ new/delete or malloc/free or classes like Arduino String which do those things internally would eventually lead to memory fragmentation and strange problems. No idea if this project has that type of code. Just a blind guess.
 
PaulStoffregen said:
"after a certain period, Teensy reboots".
Click to expand...
Perhaps that is why it was considered and the follow up questions as they were: Host connected, RED LED, any while (!Serial)

Lots of guesses needing more detail ...

That https://github.com/PaulStoffregen/MyFault/blob/main/examples/TypicalUse/TypicalUse.ino looks like one @defragster provided, that is helpful when there is a HOST running SerMon
Code: 
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
  }
 
  // ...
}
 
defragster said:
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
}

// ...
}
Click to expand...

@defragster:

In the code that you provided, Is there ever any danger that Serial will not be ready immediately, and therefore, the CrashReport will not be reported in the case where the result of the if check is false because Serial is not ready ?? This might give the false impression that no crash occurred. If Serial initialization/activation is fast enough that it will always be ready before this check, then is if (Serial && CrashReport) actually necessary, or would if (CrashReport) be sufficient ?? If Serial initialization/activation really does take some time, then it seems that the form that @KurtE provided would probably be more reliable, and therefore preferable.

Mark J Culross
KD5RXT
 
kd5rxt-mark said:
Is there ever any danger that Serial will not be ready immediately, and therefore, the CrashReport will not be reported
Click to expand...
Yes, the Serial.begin() waits until millis reaches some 2.3 seconds from start - if no SerMon/Host connects it exits. Wrote code the other week - and posted - and saw the measured time - not recalled now. Would also be apparent in CORES source ... but didn't look. Did now and it is a relative 2 seconds from the time called - that would be after the 300 ms wait to enter setup() - if no Active Host cable connected (?) - it only waits 750 ms.
Code: 
    // Serial.begin(baud) is optional on Teensy.  The main USB device port
    // is always initialized early during startup.  The baud rate setting
    // is not used.  Communication occurs at USB native speed.  For
    // compatibility with Arduino code, Serial.begin waits up to 2 seconds
    // for your PC to open the virtual serial port.
        void begin(long baud_unused __attribute__((unused))) {
        uint32_t millis_begin = systick_millis_count;
        while (!(*this)) {
            uint32_t elapsed = systick_millis_count - millis_begin;
            if (usb_configuration) {
                // Wait up to 2 seconds for Arduino Serial Monitor
                if (elapsed > 2000) break;
            } else {
                // But wait only 3/4 second if there is no sign the
                // USB host has begun the USB enumeration process.
                if (elapsed > 750) break;
            }
            yield();

A test for if (CrashReport){} then wait longer or forever could be added in the case of need to see it. The example forces a fault to demonstrate and assumes the user will have SerMon that will be active ASAP being under the ~2.3 seconds that would take.

Though the CrashReport will persist another warm restart as the Serial test being first would not hit the CrashReport code that would wipe the stored data.
 
I filled in most of the CrashReport page. Added examples for logging to SD card and LittleFS_Program. Can anything think of important CrashReport info I missed (besides addr2line...) ?
 
@PaulStoffregen:

Thanks for adding the CrashReport page.

Just a few typos/clarifications noted:

- under the Using Breadcrumbs heading, "Each breadcrumb stores a 32 bit number which infers where your program had *recently* run."
- under the Using Breadcrumbs heading, "When the CrashReport info is printed, multiple breadcrumbs can give you an idea of what every portionof work your programs performs *which portions of work performed by your program* had recently been completed."
- under the Logging CrashReport heading, "Instead of immediately printing to the *Serial* Monitor"
- under the Logging CrashReport heading, "you can also use LittleFS to log CrashReport information to a small unused portion *of* Teensy's program memory."
- under the Limitations heading, "These hardware features can give you *resilience* to software flaws, but understanding their limitations is important to actually *achieving* good results."


Thanks !!

Mark J Culross
KD5RXT
 
You must log in or register to reply here.
Back
Top