mhstr

Hi Chris,

could you please specify conditions for activation of TinyBooter and for activation of bootloader? Actually what is the different between TinyBooter and bootloader - here I do not have too much knowledge about "loaders" stuff.

I suppose following procedure:

1) build GSM-modem connection (so "air" RS232 wire is created)

2) Start MFDeploy on remote modem in the office(through COM1 which is used in N+2 application for communication with GSM modem)

3) try Ping

4) switch to TinyBooter/bootloader from MFDeploy by Plug-in->Debug->Reboot and Stop

5) Upload new application by Deploy Image file(hex)

6) during finishing deployment MFDeploy automatically start new application again

So I thought that when MFDeploy start to upload new application then TinyBooter takes over the control so the old application is not running. Isn't it like that?

Mark

Hi Chris,

I am here again with some update.

It seems that it is not true that the COM port used by the application can't be used also for deployment.

I have again changed deployment port from USB to COM 2 and then I have uploaded some test application which send some test data to the COM2 and read data from COM2. Then I connect MFDeploy through COM2 and I was able  to e.g. update the application.

It seems that the data received from deployment port , here COM2, are first processed by the low level layer (where the MFDeploy command are normally processed) and then send to the application layer - let say it is "change of responsibility design pattern".

This is really good because by this approach it is e.g. possible to update the application through GSM modem connected directly to the COM2.

Chris, can you please confirm this behaviour? Because I would like to use this approach for remote update through GSM modem.

But it is probably be careful with Debug print when using GSM modem because Debug messages would be sent to the GSM modem......

Mark

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

Hi,

I have updated the firmware(actually to the same version 4.2.2.2 as it was before) according

http://forums.netdui...-v422-update-2/

and now everything works fine, also deployment through COM2.

So my recommendation is: do not change deployment from USB to COM2 if COM2 is already used by the application..

Mark