Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 11 of 11

Thread: Freeze after 4 to 6 weeks.

  1. #1
    Junior Member
    Join Date
    May 2018
    Posts
    15

    Freeze after 4 to 6 weeks.

    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

  2. #2
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,069
    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.

  3. #3
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,774
    +1, also post some photos.

  4. #4
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,828
    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.

  5. #5
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,809
    He might also be using the String class..

  6. #6
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,828
    Quote Originally Posted by tonton81 View Post
    He might also be using the String class..
    Well that is the allocation issue.

    String class: Just say no.

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,101
    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

  8. #8
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,704
    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:
    Code:
        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

  9. #9
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,774
    A glitch in the matrix. I'm sure.

  10. #10
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,101
    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.

  11. #11
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,941
    Quote Originally Posted by Stanleyvc View Post
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •