Hi Chris,

Thank you so much for your reply and your attention.

The line I get those exceptions is this one:

mem = new FileStream(path, FileMode.Append, FileAccess.Write, FileShare.None, 512);

In addition, I didn't try it with any lower-capacity card.

Cheers,

Mohammad

Hi all,

I upgraded the firmware of my Netduino Plus from 4.1.0.6 to the new firmware introduced in this thread.

Now, I am writing something on a 4GB MicroSD, but I faced with the following errors. Would you please help me solve this problem?

My Code:

using System;using System.IO;using Microsoft.SPOT.IO;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    {        static string path = "SDSWEIoT.log";        public static FileStream mem;        public static void Main()        {            try            {                mem = new FileStream(path, FileMode.Append, FileAccess.Write, FileShare.None, 512);            }            catch (Exception e)            {                Debug.Print(e.ToString());            }        }    }}

The received exceptions:

A first chance exception of type 'System.NotSupportedException' occurred in Microsoft.SPOT.IO.dllA first chance exception of type 'System.NotSupportedException' occurred in System.IO.dllSystem.NotSupportedException

Thanks in advance,

Mohammad

Hi Chris,

 

Thank you so much for your reply and your attention.

The line I get those exceptions is this one:

mem = new FileStream(path, FileMode.Append, FileAccess.Write, FileShare.None, 512);

In addition, I didn't try it with any lower-capacity card.

 

Cheers,

Mohammad

 

Hi all,

The problem was solved by Micro SD 2GB. It seems the Firmware 4.2.0.X doesn't know the Mirco SD 4GB and up.

If you experience bugs with the .NET MF 4.2 RC5 firmware, please post about it in this thread.

A first chance exception of type 'System.NotSupportedException' occurred in Microsoft.SPOT.IO.dll
A first chance exception of type 'System.NotSupportedException' occurred in System.IO.dll
System.NotSupportedException

I developed a program for Netduino Plus to work (read/write) with Micro SD 4GB.
This program worked perfect with firmware v4.1.1 betta, but after upgrading to firmware v4.2.0 RC4, I got these errors:

A first chance exception of type 'System.NotSupportedException' occurred in Microsoft.SPOT.IO.dll
A first chance exception of type 'System.NotSupportedException' occurred in System.IO.dll
System.NotSupportedException

Would you please help me solve this problem?

Thanks Chris for your comment. Finally, I figured it out: http://forums.netdui...lus/#entry49735

Is the watchdog usable now ?

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!!!");        }    }}

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

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.

Thanks for your information. I will try to buy one. Since I am not expert, is there any specific name/ID for the IC your mentioned?

Hi Chris,

Thank you so much for your response. Does the following code act like what Watchdog does?

namespace WatchdogSimulation{    public class WatchdogSimulation    {        public static void Main()        {            while (true)            {                Debug.Print(DateTime.Now.Hour.ToString());                if (DateTime.Now.Hour > 10)             //Watchdog.Timeout = 10h                    PowerState.RebootDevice(false);     //Watchdog.Enabled = true;                Thread.Sleep(300000);                   //Wait 5min            }        }    }}

The purpose of mine is to simulate the reboot button pressing every 10 hours.

This might be useful for your watchdog prodecures: http://forums.netdui...-netduino-plus/ (although it is a software reboot).

Latest version is much more stable, thanks ToniA!

 

Unfortunately my SD Card that worked fine in 4.1, doesn't work in 4.2

Throws the Unsupported Exception in System.IO

Is your SD card more than 2GB? The firmware 4.2 only knows the SD cards 2GB and 1GB.

That's not a watchdog, it's a scheduled reboot.

 You are right, so I should not consider them interchangeably.

have you tried out my firmware build?

No, since the firmware of your library was different from mine.

What are the problems you mention in the other thread ('I had a problem for 1 month to use a Watchdog mechanism in Netduino Plus') ?

The watchdog problem to reboot the Netduino Plus after a specific time.

Hi all,

After spending 2 months on this problem, finally I could solve it. It was fixed by using a watchdog solution: http://forums.netdui...lus/#entry49735

Now, my device is working well and continuously for 10 days.

Good Luck

Hi all,

I have the same problem with some minor differences.

I am sending heart beats every 1min to a data service. My Netduino Plus has a Valid IP address with DHCP enabled in its network configurations. After some hours (e.g. max 56 hours, mean 32 hours in 10 experiments), the network thread stops with no exception.

I tried 10 different methods as probable solutions, but all failed:

• Using single threading instead of multi-thread programming (asking Netduino to only process the single networking task).
• Using C# HttpWebRequest/Response library
• Socket Programming instead of the C# HTTP library.
• Considering a fixed value for Thread.sleep() in the infinite loop (while true) of heart beat instead of WaitUntilNextPeriod() function which uses the CPU ticks.
• Removing the infinite loop and trigger the heart beat function by the event driven function (based on the value received on COM port).
• Using Debug.GC(true) at the beginning and end of each function to clean the memory.
• Trying different heart beat frequency such as 1min, 2min, and 3min.
• Considering Try-Catch in each function followed by relevant logs.
• Mutex_lock and Mutex_unlock for the networking functions.
• and so forth ....

Unfortunately, the problem exists after 2months and I couldn't find the solution yet Any help is appreciated a lot since this project is a part of my thesis and it should be done asap.

If you are interested to view my code, I attached into this message. This is the version with "Socket Programming" and "Thread.Sleep(Constant Value = 2min)" which worked longer than other versions (56 hours).

Cheers,

Mohammad

Hi all,

Just to keep you updated, my problem was fixed by using a watchdog solution: http://forums.netdui...lus/#entry49735

Now, my device is working well and continuously for 10 days.

Thanks all specially Ziggurat29 for your valuable comments.

Hi FVN.Net,

I exactly have the same problem. Could you solve the problem? I followed this post and tried everything Kem said (Thanks Kem), but all failed.

I really appreciate if you help me solve it.

Thanks,

Mohammad

Hi there,

My Netduino Plus has been programmed in a way that it sends heart beat requests (every minute) frequently to a data service. Unfortunately, after 1 (or sometimes 2) day(s) it stops running with no error or no reason. Is there any limitations on the Netduino Plus hardware structure?

I tested the data service with my PC as a client (instead of Netduino Plus) to send heart beat requests, so I was convinced there is no problem on the data service.

FYI. It has no power limitation. I mean its power is provided by a USB cable connected to my computer.

Any comments, advice and solutions are more than welcome.

Thanks for your time and attention,

Mohammad

Hi!

 

The problem could be such that it won't show as an exception but simply lock up. Could be you run out of memory in such away that there's not enough memory to even be able to fire and exception.

 

Here are a few questions for which answers might help you in trouble shooting:

 

1. Are you debugging the Netduino for the whole duration of the test?

2. Does it run for a longer time or about the same when not debugging?

3. Does it run for a longer time when not attached to USB but using an external power source?

4. What do you have to do in order for the Netduino to run again - is a soft reset enough or do you have to cycle power (i.e. USB)?

5. Can you talk to the Netduino from MFDeploy when it has stopped?

 

For this kind of long running "critical" stuff you could use a watch dog. I don't know if you can access the integrated watch dog from managed code but if not, there are watch dog modules/chips that you can connect externally. A watchdog could automatically restart your Netdunino every two hours or whatever as appropriate by power cycling (most reliable) or by issuing a reset.

Hi Hanzibal,

Thanks a lot for your valuable reply. The reason that I am replying late is becasue I was testing my Netduino+ based on your comments.

1. It is not dependent of my debugging. I have the same problem when I also run it in a non-debug environment.

2. Almost the same (the working time is not constant in both situation).

3. I didn't try.

4. Soft reset is enough.

5. I haven't tried it yet.

Honestly, I have no watch dog module. How does it understand when it should restart? Can I implement it in my code? Any advice would be appreciated.

Thanks again,

Mohammad

fwiw, mohammad,  I have had a similar problem; in my case with ethernet.  an easy way to stimulate it:

 

*  have a persistent connection to my server.  this runs in a separate thread.

*  in the absence of other traffic, periodically I send heartbeat, and if connection is lost or non-responsive, it loops around to restore the connection, with appropriate backoff, etc.  this code is all thoroughly tested when running on desktop.  I can unplug cables, take interceding routers and server process up and down, and things are resilient.

*  if, however, I am running the same code on the netduino, if the server process it taken down

*  the netduino will detect it, try to reconnect (to the not-yet-back-up server process)

*  and hang forever

*  but only the thread that is handling the ethernet server connection is affected.  my other threads are lively.

*  I confirmed that, while in the fail mode with the locked ethernet thread, I can successfully issue a PowerState.RebootDevice() and at least restart the system.

 

The lockup you are experiencing seems to be similar, but I don't know what stimulates the problem in your case, so maybe it is different.  Anyway, here is what I have done to cope with it -- and mind you I haven't finished implementing yet because I'm on other things just now, so fair warning, but initial testing makes me confident that it works:

 

*  the netduino chip has a hardware watchdog, but it is not really available to us, alas.  so, in lieu of that....

*  I made a software watchdog.  (I also added a MAX824 (-compatible; I think it is actually a diodes inc chip) to my PCB, but that was last minute and I haven't written code for it)

*  the software watchdog works like this:

  *  all my various 'app services' (worker thread that do stuff, like handling the ethernet connection to my infrastructure)

  *  call a 'checkin' function with my 'watchdog service'.  that checkin() says 'reboot if you don't hear back from me in XXX ms, and oh please call this method if you reboot because someone else failed'

  *  a checkin discards any previous outstanding checkin

  *  the watchdog service periodically checks for expired checkin()s (Kentucky Fried Checkins?) and if any were found, it will issue the reboot

 

In my case, I did it this way because I already had all these app services coded, so I needed to retrofit to that impl.  They did handily have idle() methods which I could use those to do the checkin(), but the duration needed to vary because some activities would normally block for up to 3 min in some cases (like cranking up GSM).  The particulars of your design my mean you can do it more simply that I was able to do or think of.

 

hth; dave

Hello,

 

I just want to let you know that there is firmware with software watchdog added:

 

http://forums.netdui...o-plus/?p=47334

 

Maybe it will solve your problem.

 

Regards

Hello again Mohammad,
I really think you should read carefully what the other two guys just wrote, but in answer to your question, a watchdog normally listens to some kind of "alive beacon", "heartbeat" or "check-in" (like the others wrote). When the watchdog has not seen/heard the beacon for some pre-defined time (timeout), it issues a reset causing a "reboot". This way, a watchdog could keep your application from locking up.

Watchdogs are for the situations where you can't actually figure out why things eventually go wrong and so instead of trying to solve the actual issue, you simply restart the whole thing. This is a "when all else has failed" type of thing to do but sometimes it's the only thing to do. Personally, I would never trust a software watchdog, instead I want someone to "pull the plug" and then reinsert it again afterwards.

Hi All,

Thanks for your valubale comments. I am exactly doing as the same as Ziggurat29. Based on my understanding, I should reboot my Netduino after some time (e.g. 10 hours). At this time, the only thing I did was a software reboot by means of Powerstate.RebooteDevice(false). Is it right?

Thanks,

Mohammad

First of all, the watchdog functionality is not there in the stock firmware. All the interfaces are there, but no functionality.

 

If you would want to use the firmware I built, look at this message, it has a code sample: http://forums.netdui...ge-2#entry47334

Hi ToniA,

Thanks for your reply. It is a bit rediculous that the interfaces and methods are available, but they are fake

Anyway, I gave up to use watchdog for now, but I will surely use your firmware someday.

Hi all,

My "network die problem" was solved after spending 2 months on it Now, I am so happy. The solution I used was software watchdog developed by my own. If you are interested in the solution, take a look at this link: http://forums.netdui...lus/#entry49735

I will later publish a post to elaborate the whole procedures and solutions that were useless except the software watchdog.

Good luck