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.
OK, I have been looking at the code, and my plan for fixing the MFDeploy issue is to use the onboard switch and led like this:
Short press on power-up -> onboard led lights up, then turns off -> watchdog disabled, CLR starts normally
Long press on power-up -> onboard led lights up, then blinks quickly a few times -> watchdog disabled, waits for firmware upload
No button press on power-up -> watchdog enabled, CLR starts normally
Additionally, I've been thinking how to feed the watchdog from the managed application side. If I introduce any new methods or properties etc. it means that all applications using those must also link with additional DLL's. I was thinking of this:
The CLR feeds the watchdog until the first time 'Watchdog.enabled = true' is called
After this, each call to 'Watchdog.enabled = true' would reset the watchdog counter and the CLR would not feed the watchdog any more
A bit ugly, but wouldn't require any extra DLL's. Now I just need to implement these
What you said about [color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]feeding the watchdog from the managed application side. would probably provide a quick fix for the issues that I'm seeing in my setup.[/color]
Connects to locally hosted server application via TCP/IP socket communication
Once Netduino plus connects to server I use a GUI tied to the server to command and keep track of connections
Problem:
Once Netduino plus connects to the server, something causes the watchdog to kick in and reset the chip at set time intervals roughly 1 min 14 secs after the Netduino plus connects to the server.
Note 1: If I leave the Netduino there not connected the server the watchdog won't trigger a reset
?Note 2: This doesn't happen with non custom firmware, with non custom firmware the problem comes from when I do something like manually disconnecting the Ethernet cable which causes it to hang.
What I wanted it do:
If there was ever a network disconnect for whatever reason (e.g. I unplug the Ethernet cable), if the Netduino plus couldn't resolve the socket connection to the server it would force a reset after a set time of hanging.
If some how you got the watchdog managed from the application side, I could kick it every X amount of seconds. Like you said ugly fix to the issue, but it will work until i can narrow down what's forcing the resets at set time intervals during connections.
Gavin G.
"The most important thing is to keep the most important thing the most important thing."
- From the book "Foundation design", by Coduto, Donald P.
Additionally, I've been thinking how to feed the watchdog from the managed application side. If I introduce any new methods or properties etc. it means that all applications using those must also link with additional DLL's.
It is also possible to add private fields and access them via reflection, in derived classes or extension methods. This has been done by Secret Labs for I2C (Custom_InternalAddress), SPI (Custom_BitsPerTransfer in ExtendedSpiConfiguration).
Yes, I noticed the same. Actually, I somehow got the firmware all messed up if I didn't follow this procedure:
You need to have the firmware deployed
Connect the Netduino Plus to USB while holding the onboard botton down
When you do a 'Ping' in MFDeploy, it should tell you it's running the tinybooter, not CLR
Now do the network setup
I already implemented the TinyBooter feature to react differently on short and long press on bootup, now I need to focus on the watchdog side. I also compiled the whole software with RVDS 4.1.
Hi Erik, still working on it. I think I got it all done, but I need to do some more tests tomorrow evening. If I don't find any problems, I'll publish the binaries tomorrow.
OK, here's my new 1-wire + watchdog firmware for Netduino Plus, based on official 4.2.0.1, with CW2's 1-wire, compiled with RVDS 4.1.
Flashing instructions:
[*]Reset the NetduinoPlus by connecting 3.3V to the golden square [*]Disconnect and reconnect the USB [*]Install the TinyBooterDecompressor.bin with SAM-BA [*]Disconnect the USB cable and reconnect it while PRESSING AND HOLDING THE ONBOARD BUTTON until the onboard LED blinks quickly [*]Deploy the firmware using MFDeploy [*]Disconnect and reconnect the USB AGAIN while PRESSING AND HOLDING THE ONBOARD BUTTON until the onboard LED blinks quickly [*]Set the network configuration with MFDeploy [*]Disconnect and reconnect the USB (don't press the button), and you're done [/list]
The Tinybooter has three modes:
Onboard button is not touched -> boot up with watchdog enabled
Press the onboard button while connecting the USB -> release the button after the LED turns off but before it starts blinking -> boot up with watchdog disabled -> can use MFDeploy to deploy large applications
Press and hold the onboard button while connecting the USB until the onboard LED first turns off and then blinks -> boots to TinyBooter for firmware upload and for setting the network configuration
The watchdog also has three modes on the application
'Watchdog.enabled' is not set in the program -> watchdog is active and is automatically fed by the CLR
'Watchdog.enabled = false' -> watchdog is explicitly disabled -> same functionality as in the stock firmware
'Watchdog.enabled = true' -> watchdog is explicitly enabled and cannot be disabled -> the watchdog must be fed by the application by calling 'Watchdog.enabled = true' periodically. If this is not done, or if the application crashes, a watchdog reset will happen
A sample application
Please note that the watchdog is not active when connected to the debugger -> stop debugging and reconnect the USB
To verify the functionality, comment out the 'Watchdog.enabled' row in FeedWatchdog and see the board doing a reset after a short while
using System;using System.Net;using System.Threading;using Microsoft.SPOT;using Microsoft.SPOT.Hardware;using SecretLabs.NETMF.Hardware;using SecretLabs.NETMF.Hardware.NetduinoPlus;namespace WatchdogDemo{ public class Program { static void FeedWatchdog(object o) { // Each time the watchdog is enabled, it's also fed // This is a bit of a workaround, but at least it didn't // require any interface changes Watchdog.Enabled = true; } public static void Main() { OutputPort led = new OutputPort(Pins.ONBOARD_LED, false); // When the watchdog is enabled, it also must be fed from the managed app Watchdog.Enabled = true; Timer WatchdogTimer = new Timer(new TimerCallback(FeedWatchdog), null, 1000, 1000); while (true) { Thread.Sleep(50); led.Write(!led.Read()); } } }}
have you tried out my firmware build? 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') ?
But CW2 sample application does not work. If I start it, using the Debugger I get an [font="arial, helvetica, sans-serif;"]'System.NotSupportedException' occurred in OneWireTestApp.exe'[/font]
when the follwing line is executed:
oneWire = new OneWire(Pins.GPIO_PIN_D8);
Any ideas what goes wrong here? For me it Looks as the CLR can't find the entrypoint for CW2 OneWire functions. But why?
