The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I was proposing a solution to the original request, which is "but I want to trigger a reset if the switch has been held down for an extended period of time." - to handle a switch interrupt, the code is supposed to be in operational state.
Well, there are a few issues with that:
* first the watchdog would be a workaround for that feature (long button press for reboot) -- as it would make more sense to just reenable the switch to function as a reset (and that obviously can be achieved somehow, since it works if the switch is not "reprogramed" as an InterruptPort).
* second, I agree with above posters that Watchdog functionality is very nice to have (I too am building a home automation system that will be unattended **most** of the time). And resets in such a case would be very nice (let's hope that they won't be needed, but ...)
* As for reboot, it can obviously be done (I mean, the VS debugging process can reboot it, so it can be done via software, it is just not accessible to us, or we don't know how to access it (more likely)).
So to reiterate:
* Watchdog would be very nice to have
* Programmable reset would be very nice
* Workarrounds for the above anyone? (I still don't know if I can just wire D0 to reset and expect it to work??)
I also believe that it's important to have an easy way to soft-reset the device using a watchdog timer.
However, for more critical applications, it's best to have a completely external watchdog (using an ATtiny85 for instance) controlling the hardware reset of the device.
Cheers,
-Fabien.
BTW, I can confirm that PowerState.Reboot() is working.
Hi Miha,
We're thinking that this will be enabled through the new runtime native code interop feature of the next firmware release (v4.1.2). If that can't handle it, we can add it in the native code core.
We're thinking that this will be enabled through the new runtime native code interop feature of the next firmware release (v4.1.2). If that can't handle it, we can add it in the native code core.
Actually, I have the same question for Firmware 4.2.0.0 (RC 5), since the following code doesn't work and the debugger always prints 00:00:00 for the Watchdog.Timer.
using System;using System.Net;using System.Net.Sockets;using System.Threading;using Microsoft.SPOT;using Microsoft.SPOT.Hardware;using SecretLabs.NETMF.Hardware;using SecretLabs.NETMF.Hardware.NetduinoPlus;namespace NetduinoPlusApplication1{ public class Program { public static void Main() { Debug.Print(Watchdog.Timeout.ToString()); TimeSpan t = new TimeSpan(0, 0, 1); Watchdog.Timeout = t; Debug.Print(Watchdog.Timeout.ToString()); Watchdog.Enabled = true; Thread.Sleep(3000); Debug.Print("not rebooted yet!!!"); } }}
Great I saw this post, I didn't know how to provoke a reboot from software.
The code you attached before would restart the device repeatedly between 10:00 and 11:00 AM, effectively rendering it unusable during that time. Am I right?
Personally, I think there's no such thing as a software watchdog. You can't write software to check if another piece of software has locked up. If I remember correctly it's one of those NP complete problems within the theories of complexity.
The code you attached before would restart the device repeatedly between 10:00 and 11:00 AM, effectively rendering it unusable during that time. Am I right?
Yes, you are right , but by using the Timer class, you can implement it more effectively.
Personally, I think there's no such thing as a software watchdog. You can't write software to check if another piece of software has locked up. If I remember correctly it's one of those NP complete problems within the theories of complexity.
I partially agree with you , you know in multi-threading world, sometimes one thread blocks all its processes (e.g., this problem), and the problem is solved by a simple reboot. At this time, one thread can be in charge of software reboot, and the other threads are doing their tasks. If any fail or error situation occurs, the reboot thread can perform its task
Simple operation, your micro periodically "checks in" by toggling the detector pin every 100ms. Should the device not hear from you in 140ms, it will briefly de-assert your reset pin, effectively causing an actual reboot.
I'm sure you can find a watchdog IC that is available in DIP8 - just stick it down the breadboard, connect 2 wires (plus power) and you're good.
The one I referred to is named ADM682x where x is 3, 4 or 5 depending on small differences in functionality (it's all in the datasheet) but it's only available in a 5-pin SOT23 package which is SMD (surface mount device) and thus cannot simply be snuck down a breadboard.
Instead, you probably want to use the classic DS1232 which is available in breadboard friendly DIP8 package. A nice feature is that timeout can be configured up to 2 seconds, so you don't have to check in that often, saving you some cpu time. It's about 1.50 USD and available at most electronic part resellers:
See figure 1 on page 3 on how to wire it. Another thing to consider is whether your Netduino has a soft or hard reset pin - if it's soft, a hardware watchdog won't be bullet proof after all. However, in the case of a soft reset, you could have the watchdog chip control the powerline to make sure the board actually reboots for sure no matter what.
Good luck and be sure to check back to report on your progress. I'm sure many here at the forum would be interested in a driver class for that chip so perhaps you could take on writing one...