mhstr

Hi,

I have changed deployment source from USB to COM2 in MFDeploy and now it is not able to connect to the Netduino Plus 2 through MFDeploy at all.

It seems that Rx pin of the COM2 is not working and I have such a suspicion that it is blocked by running application - the last application which was running was an example from NeoMika Webserver and some time ago I have read that somebody was not able to open COM2 inside NeoMika Webserver because the resource is somehow blocked inside Webserver. Could it be the reason here?

When I connect Tx COM2 pin to the terminal I can see some messages from COM2 Tx so based on this I suppose that deployment way was changed successful from USB to COM2. But trying to "listen" also Rx COM2 pin(=PC Tx pin) there is nothing when I try to Ping in MFDeploy(I can see communication only when the pin is not connected to Rx COM2 pin but only connected to my "listener hardware").

I though that MFDeploy is so clever so if the COM is reserved for deployment then application can't use these pins but it seems it is not the case here...

Is there any workaround to solve this issue or it is necessary to erase whole Netduino Plus 2 and make all installation of firmware and Booter again?

I have already read thread "Steps to restore an Erased Netduino"

but I can't find valid TinyBooterDecompressor.bin and firmware.

The firmware version of my Netduino Plus 2 is probably 4.2.2.

I can see this text in my terminal connected to COM2 Tx pin during start:

ARM Compiler version 410894

TinyCLR (Build 4.2.0.0)
......
Create TS.
 Loading start at 806a988, end 8085288
Assembly: mscorlib (4.2.0.0)
Assembly: Microsoft.SPOT.Native (4.2.0.0)
Assembly: Microsoft.SPOT.Hardware (4.2.0.0)
Assembly: Microsoft.SPOT.Net (4.2.0.0)
Assembly: System (4.2.0.0)
Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0)
Assembly: Microsoft.SPOT.IO (4.2.0.0)
Assembly: System.IO (4.2.0.0)
Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1)
Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0)
Assembly: SecretLabs.NETMF.Diagnostics (4.2.0.0)
Assembly: SecretLabs.NETMF.Hardware.Netduino (4.2.1.0)
Assembly: Microsoft.SPOT.Hardware.OneWire (4.2.0.0)
Assembly: Microsoft.SPOT.Time (4.2.0.0)
Loading Deployment Assemblies.
Attaching deployed file.
Assembly: JSONLib (1.0.0.0)
Attaching deployed file.
Assembly: SecretLabs.NETMF.Hardware.NetduinoPlus (4.2.2.0)
Attaching deployed file.
Assembly: NeonMika.Webserver (1.0.0.0)
Attaching deployed file.
Assembly: NeonMika.XML (1.0.0.0)
Attaching deployed file.
Assembly: SecretLabs.NETMF.Hardware.PWM (4.2.2.0)
Attaching deployed file.
Assembly: NeonMikaWebserver (1.0.0.0)
Attaching deployed file.
Assembly: SecretLabs.NETMF.Hardware.AnalogInput (4.2.2.0)
Attaching deployed file.
Assembly: SecretLabs.NETMF.Hardware (4.2.0.0)
Attaching deployed file.
Assembly: NeonMika.Util (1.0.0.0)
Resolving.
Ready.

Any idea how to "rescue" my Netduino?

Mark

Hello,

we would like to implement remote software update via Ethernet or GSM(GPRS) in our application.

Is there already any solution supported directly by .NET micro framework? I have read some threads about this topic but there was pointed out that standard .NET solution is not suitable for Netduino becuase it uses half of Flash memory for update etc.(maybe SD card could be used as intermediate storage for new application..)

My idea is that application will somehow write image of Netduino application(hex) to the SD card and then Netduino is reset(ideally by Watchdog) and bootloader will detect new application on SD card which will be burned to Flash and run the application...

As far as I remember Chris mentioned MonoBootloader(I do not know the exact name) which also uses SD card. SD card can be used here as a mediator between application and bootloader so the bootloader does not have to implement all complex network communication stuff which is more less always implemented in the main application...

Has somebody already implemented some similar solution for remote update?

Mark.

Hello,

I am new here and we would like to use Netduino as a replacement of previous control board based on the x51 platform in some commercial application(dozens...hundreds pieces). The application must run 365/7/24 without human assistence.

Becuase of reliabilty the hw Watchdog is I would say a must(it is also used in current system). I have read in some other tread that there was a plan to support HW Watchdog in the firmware(somewhere in 2012) but I have such a filling that Watchdog is still not supported but I am not sure.

I am asking becuase I have also read some other thread which mentioned that Netduino Plus 2 application was frozen because of some problem with network initialization(DHCP) where some part of Flash memory is overwritten too frequently or something like that...

Chris has recommended to use some external hw circuit as a Watchdog but this is not an elegant solution and it leads to a problem when bootloader is activated as bootloader does not know anything about external Watchdog the "burning process" would be interrupted...

And also Watchdog would be an elegant solution how to make a real HW reset e.g. during remote update procedure.

Thanks for any idea.

Mark