I have been having the controller completely lock up, about every 2 days or so.
I am debugging, and think it might be my code at fault.
But really - it should never truly lock up.
If it does that when one of the dosers is on, everything in my tank is toast. Really!
So having a watchdog timer might be a really good plan.
(This was with the latest development libraries)
It is not hard.
#include <avr/wdt.h>
Enable = wdt_enable
clear in your main loop = wdt_reset
The only concern is if you already use that timer.
Request watchdog timer reset
Re: Request watchdog timer reset
Interesting. so you would do the wdt_enable in your setup() function and then call the wdt_reset in your loop() function. What is the time frame between reboots without touching/resetting the timer?rygh wrote:I have been having the controller completely lock up, about every 2 days or so.
I am debugging, and think it might be my code at fault.
But really - it should never truly lock up.
If it does that when one of the dosers is on, everything in my tank is toast. Really!
So having a watchdog timer might be a really good plan.
(This was with the latest development libraries)
It is not hard.
#include <avr/wdt.h>
Enable = wdt_enable
clear in your main loop = wdt_reset
The only concern is if you already use that timer.
I'm not aware of anybody having issues with their controller locking up every 2 days or so. Maybe there is something wrong with the controller or with the code on the controller.
curt
Re: Request watchdog timer reset
Yes, that would be how to do it.
The timeout could be very small. Even less than 1 second, since you get back to the loop very quickly.
Although probably 5 seconds or so is best.
--
I did track down what I am 90% sure is the problem.
I had a bug in my add-on code where I was updating a relay value continuously.
So every time through the loop, it set the value. It set it the same, over and over.
Which means I was sending I2C commands to the relay board non-stop for days.
Since I2C is technically an async interface, there is a non-zero probability of a hang.
The next few days will tell if that was the root cause, but it is really the only major thing I changed,
and before it was working very reliably.
At any rate, if that is the root cause, that means there is a very very low,
but non-zero chance of a hang in everyone's system.
With such a low probability, not surprising it has not been hit before.
Probably something you could test in your lab pretty easy.
--
A watchdog timer is likely not a high priority, but might be good to add for robustness.
The timeout could be very small. Even less than 1 second, since you get back to the loop very quickly.
Although probably 5 seconds or so is best.
--
I did track down what I am 90% sure is the problem.
I had a bug in my add-on code where I was updating a relay value continuously.
So every time through the loop, it set the value. It set it the same, over and over.
Which means I was sending I2C commands to the relay board non-stop for days.
Since I2C is technically an async interface, there is a non-zero probability of a hang.
The next few days will tell if that was the root cause, but it is really the only major thing I changed,
and before it was working very reliably.
At any rate, if that is the root cause, that means there is a very very low,
but non-zero chance of a hang in everyone's system.
With such a low probability, not surprising it has not been hit before.
Probably something you could test in your lab pretty easy.
--
A watchdog timer is likely not a high priority, but might be good to add for robustness.
Re: Request watchdog timer reset
I'm pretty sure the bootloader doesn't handle the WDT flag as it is right now.
You would need to burn the bootloader again with the watchdog mod.
I'm pretty sure you would be in an endless reset loop if you enable the flag.
What happens is that when watchdog flag is set, it will need a reset every x ms, even after a reset.
The bootloader takes about 1s to start the sketch and even longer when you are uploading a code.
Anything after the x ms would cause the uC to reset again, making it impossible to get out of it, unless the bootloader clears the flag.
The trick is to distinguish between power-on reset and watchdog timer expired reset and clear the flag accordingly.
Let me see what can be done about adding the clearing of the flag on the bootloader.
You would need to burn the bootloader again with the watchdog mod.
I'm pretty sure you would be in an endless reset loop if you enable the flag.
What happens is that when watchdog flag is set, it will need a reset every x ms, even after a reset.
The bootloader takes about 1s to start the sketch and even longer when you are uploading a code.
Anything after the x ms would cause the uC to reset again, making it impossible to get out of it, unless the bootloader clears the flag.
The trick is to distinguish between power-on reset and watchdog timer expired reset and clear the flag accordingly.
Let me see what can be done about adding the clearing of the flag on the bootloader.
Roberto.
Re: Request watchdog timer reset
Well, it was not the I2C problem. Hung again last night after the fix.
I am a bit unsure what to do now.
I think I will add a separate thread on that for help. Does not belong here really.
--
On the watchdog timer, it might make sense to just do that as a standard interrupt.
Similar:
Enable timer and interrupt at setup.
Update timer every time through main loop.
If timer is not update, triggers interrupt.
Interrupt resets.
The obvious disadvantage is that it is not quite as robust. If CPU is truly stuck,
or you have a bug in interrupt handler, it will not work.
The advantages:
No need to worry about boot loader.
You can actually log the failures in the handler.
I am a bit unsure what to do now.
I think I will add a separate thread on that for help. Does not belong here really.
--
On the watchdog timer, it might make sense to just do that as a standard interrupt.
Similar:
Enable timer and interrupt at setup.
Update timer every time through main loop.
If timer is not update, triggers interrupt.
Interrupt resets.
The obvious disadvantage is that it is not quite as robust. If CPU is truly stuck,
or you have a bug in interrupt handler, it will not work.
The advantages:
No need to worry about boot loader.
You can actually log the failures in the handler.
Re: Request watchdog timer reset
That would require some sort of mod because there is no I/O connected to the reset pin.
Also, I don't think it would work because of the reason you already mentioned. If the uC is stuck, it would do nothing.
Also, I don't think it would work because of the reason you already mentioned. If the uC is stuck, it would do nothing.
Roberto.