I have a program which runs reliably long term but has occasional lockups (possibly due to our sightly “iffy” mains supply. I have added a timer interrupt routine using TimerThree library and the program produces corruption of integer array data within minutes of running. I have looked for several days and introduced a debug routine after each function call to try and find the point at which the corruption occurs. This hasn’t helped me as the data at the end of the main loop() is ok and at the start of the next pass through loop() it is corrupted even though there aren’t calls to other functions.
I suspect my coding but the fact that the corruption appears to happen during the return to loop() start and the simple act of commenting the interrupt calls return the program to it’s normal state.
Attached is the top level code only and attached is some of the serial output I’ve been able to copy and paste from the output window (there must be a correct way!).
The code for the functions amounts to some 40-50kB and I thought it might be irrelevant at this stage. (Could save me some embarrassment
I didn't post because the forum posting system told me it was too big and In my ignorance I assumed that the functions couldn't be causing it because it happens only during the loop() flyback (always).
However, further ignorance stops me from effectively collecting the Serial.print output for displaying the debugging as I'm trying to use copy and paste.
Do I need to try and recode to a minimalist sketch?
Which board / processor? How much memory (SRAM) available for dynamic data after compile? I don't have all those libraries so can't compile to check. I suspect that you're either using too much memory or you have a buffer overflow.
You state that the problems started after adding the timer3 interrupt but don't post that routine? Please post all your code (zip it and attach as it seems quite big); the problem might very well be caused in a function that you did not post.
Multiple libraries were found for “Ethernet.h”
Not used: /opt/arduino-1.6.5/libraries/Ethernet
Not used: /home/david/Arduino/libraries/arduino_372926
Multiple libraries were found for “TimerThree.h”
Not used: /home/david/Arduino/libraries/Timer3
Sketch uses 57,796 bytes (22%) of program storage space. Maximum is 253,952 bytes.
Global variables use 4,826 bytes (58%) of dynamic memory, leaving 3,366 bytes for local variables. Maximum is 8,192 bytes.
// Sink current to drain charge from C2
// Give enough time for C2 to discharge (should discharge in 50 ms)
// Return to high impedance
I will zip the code and try to attach later when I have checked any obvious stuff which can be removed.
Can someone explain why the problem shows up between end of loop and restart of loop? I’d love to know what happens as it goes around!
It's a lot of files to go through Just started, but found one mistake in File2Status that can cause undefined behaviour.
If the opening of the file fails, you do not read the file (good) but you still close the file (bad). Move the close() to with the if block.
Digging a little more, Status2File does not even check if the file was opened successfully or not, another possible cause of undefined behaviour.
Suggestion: you might have been a little bit extreme in splitting the functionality over multiple files. Those above 2 functions actually belong together in a file. Call it e.g StatusFile and place both functions in there.
I might dig a bit more in the coming days and see if I can find obvious flaws.
If you decide to rewrite your code, try to start using cpp and h file instead of ino files. All your function prototypes and defines can go e.g. in a file called MainControl.h (you can actually now already do that).
@NickGammon@sterettje Thank you both for constructive points. There is a lot to go through and I do appreciate your help
Unfortunately there would be no point in the routine because the delay is to discharge the capacitor and reset a hardware (555 timer) watchdog, because I have failed totally to get the system watchdog to work. If there is a way to get the inbuilt watchdog running, a reference to it would be nice because I am led to understand that a bug in the boot loader is the problem.
I will certainly make the changes you recommend and removing the logging would reduce the code significantly, especially as it was to give me something to check on whether the code was working. As regards cpp coding, I'm having a hard enough time in the IDE, can I code with the most basic ANSI C as I do now?
I'll give it a try Nick, but basically when the interrupt fires I end up with a vicious circle of reboots and I can't upload the sketch again to recover the board. This is despite have a reset and/or a disable as the first statement in the setup(). I end up having to upload a blank sketch (setup() and loop() with just a one line Serial.print so I check it is running) and upload whilst holding reset (requires quick reflexes to release reset).