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
 
Could you please describe the addr2line?
Because everytime a program of mine crashes, e.g.:
Code was executing from address 0x41F24
addr2line never seems to be able to convert that:
$ /home/folkert/.platformio/packages/toolchain-gccarmnoneeabi-teensy/bin/arm-none-eabi-addr2line -e .pio/build/Teensy4_1/firmware.elf 0x41F24
??:?
I always get ??:?
 
flok said:
Could you please describe the addr2line?
Click to expand...
The 'Build Tools correct version' for the OS in use must be used.

On Windows I found a version that worked on prior TOOLS Ver# and had it on my path to use easily.
When the Build Tools were updated, needed to locate the correct version for new formatting to work and give valid results.
 
defragster said:
The 'Build Tools correct version' for the OS in use must be used.

On Windows I found a version that worked on prior TOOLS Ver# and had it on my path to use easily.
When the Build Tools were updated, needed to locate the correct version for new formatting to work and give valid results.
Click to expand...

I think I do so. I use platformio which automatically installs all the dependencies with the correct version.
 
flok said:
correct version.
Click to expand...
TeensyDuino installs the RIGHT version for Windows - but it is hidden deep in the tools with a nonsense name, not addr2line.

Not stated what OS in use there.

Managed to find it and it is like this: "C:\Users\yup\AppData\Local\Arduino15\packages\teensy\tools\teensy-compile\11.3.1\arm\bin\arm-none-eabi-addr2line.exe":
That is the IDE 2 install that is more involved before 'tools' than IDE 1.8.19, but still called: arm-none-eabi-addr2line.exe
 
I'm running Linux with platformio.
I'm kind of certain that I got the right version of addr2line:
/home/folkert/.platformio/packages/toolchain-gccarmnoneeabi-teensy/bin/arm-none-eabi-addr2line
as there's teensy in thee directory-name, and it is the only teensy-addr2line on my system :)

I eventually found that with a few extra switches, the program at least prints the function where things goes wrong. So still no line-number, but an indication nevertheless:

Code: 
$ /home/folkert/.platformio/packages/toolchain-gccarmnoneeabi-teensy/bin/arm-none-eabi-addr2line -e .pio/build/Teensy4_1/firmware.elf -a -i -p -f -r 0x41ACA
0x00041aca: _free_r at ??:?

So now I'm going to add breadcrumps to each and every free-alike function.
Hopefully @Paul will one day add a more elaborate backtrace :)
 
flok said:
Hopefully @Paul will one day add a more elaborate backtrace :)
Click to expand...

Have you tried with .elf files compiled by Arduino IDE using the toolchain and config PJRC provides? Please try with Tools > Optimize set to Debug.

Or if that's not practical (you've designed your project to depend on PlatformIO) can you at least compile a basic LED blink in both and compare the command line parameters? The amount & quality of debug info within your .elf file depends heavily on the specific command line options given to the compiler. PlatformIO lets you customize this stuff, which is great if you want powerful capability to customize, but it tends to be much less of "known quantity" compared with Arduino IDE, which is why I'm specifically asking you to comment on addr2line capability when using .elf output compiled by Arduino IDE when optimize is set to debug. That is the software PJRC actually ships (PlatformIO packages are made by 3rd parties using the PJRC packages but aren't assured to be the same), so if you want to talk about what I might do in future software, please test with Arduino IDE using the package PJRC provides. Then test whether PlatformIO gives the same capability, and if it comes up short, open an issue with the PlatformIO or whoever made the package you're using on PlatformIO.

But if it doesn't work with Arduino IDE using the latest published code (beta version if we're in a beta cycle, as we are now), of course I do want to hear about it if you're willing to share a complete program I can use to reliably reproduce the problem. Please understand I can't really do much without a test case that lets me reproduce the problem.
 
Last edited:
You must log in or register to reply here.
Back
Top