Freeze after 4 to 6 weeks.

[Stanleyvc]

Hai,

A have a project with Teensy 3.6 with SGTL 500.
A have more project 's with this.
all wil freeze after 4 to 6 weeks.

What can happens?

Thanks

[Theremingenieur]

Without seeing what your stuff does, one could only guess wildly around. That’s why we have that forum rule
Forum Rule: Always post complete source code & details to reproduce any issue!
to make sure that someone being willing to help can exactly reproduce your setup to reproduce and diagnose your problem.

[Frank B]

+1, also post some photos.

[MichaelMeissner]

Obviously posting code and pictures will help possibly identify the problem.

I can think of several things that might be an issue:

• The millis/micros clock ticks over and you aren't using unsigned long arithmetic to figure out the amount for a delay (or if you are using unsigned long, you coded it wrong);
• Some other counter overflows in 4-6 weeks;
• You are allocating memory (possibly being done in a library) that isn't being freed and the heap is exhausted -- or there may be space available, but the heap is fragmented since adjacent blocks are not released, and the memory allocation cannot find a big enough block;
• You are using recursion and eventually the stack runs out of space;
• You are using alloca in a loop, and the stack memory is not being released because the function doesn't return;
• You are using external communication to other boards/devices, and you get some corruption on the transfer;
• You get the random memory corruption from gamma rays;
• Perhaps power is not stable, and you get something that causes the Teensy to continue to run, but other devices getting zapped;
• You access variables from an interrupt handler that take 2 or more read/write accesses or are unaligned, and eventually you get an interrupt between the first access and the second; (or)
• You use word pointers to access unaligned memory, and the Teensy 3.2 has one location where you will get a trap because it crosses segment/page boundaries (I suspect the 3.5/3.6 may have a similar issue) -- there one solution is to insure you never have a block of memory that crosses that particular boundary, or possibly don't use unaligned load/stores.

[tonton81]

He might also be using the String class..

[MichaelMeissner]

He might also be using the String class..

Well that is the allocation issue.

String class: Just say no.

[defragster]

If it is Memory this might help see it - if the code's mechanics are right for the Teensy in use?

>> Memory-Status-and-Monitoring
Update: Now on SourceForge

[KurtE]

My top guesses are more or less the same as everyone elses Especially since we have no hints.

a) power - Always one of my top guesses.

b) Overflows or the like with timers, timeouts...

c) memory corruption/leaks - As mentioned maybe using heap and something not being freed. Or finally gets too fragmented, Or maybe allocations done on Interrupts like Interval timer or...

d) Or some timing issue. Example I have seen (done) and fixed bugs like:

    CallOftoSomethingThatwillInterruptAtCompletion();
    interrupt_happened = false;
    while (!interrupt_happened) ;
...

Works most of the time, but maybe some other interrupt happens during the CallOff.. And the actual interrupt is triggered, before we reutn and clear interrupt_happened...
So then are wait will wait for ever...

...

Again knowing nothing about your program or setup hard to recommend stuff.

But could maybe use @defragster stuff - Although hard to know if you need some other hardware sitting there with Serial port or like for 4-6 weeks.

Again check for everywhere you wait for something and make sure you don't have code like above and/or you have timeouts in all loops.

Maybe setup something like watchdog timer? to make sure things are running and try to recover...

Again hard to say

Kurt

[Frank B]

A glitch in the matrix. I'm sure.

[defragster]

This wasn't designed to detect all forms of 'glitches in the matrix' - but ...

My last posted debug_t3 is here

In that one I integrated the above RamMonitor - not sure how well or helpfully it is documented/implemented. It can keep track of RAM using using that code as I found it - and will also trigger if a FAULT happens at the point "wil freeze after 4 to 6 weeks."

That might help see if RAM is going away or perhaps a FAULT indication if properly instrumented up to that point - what the fault is or how it got there.

[WMXZ]

Hai,

A have a project with Teensy 3.6 with SGTL 500.
A have more project 's with this.
all wil freeze after 4 to 6 weeks.

What can happens?

Thanks

Let's continue with wild guesses
Are you using SD library to read/write a lot of files?

In this case:
Note there seems a memory allocation issue in File object:
File constructor calls malloc(), but File destructor does not call delete(), or better delete() is never called.