12 replies to this topic

[JerseyTechGuy]

The project I am working on is meant to be a black box to the user. What I mean is they will not have direct access to the SD storage or the USB connection on the Netduino Plus. I am working on a Windows Application that will communicate with the Netduino Black Box via FTDI board (com1). I have the communication between the windows app and the Netduino app working fine. I can update the DS1307 clock on the Netduino Shield via the Windows App over RS232. I can also change some settings that are stored either on the SD Card or in Flash Ram. My next hurdle is to allow the user to update their Netduino's software (not firmware) via the Windows App. I want them to be able to download an update and deploy it to the Netduino. The first part is easy... I've been writing windows apps for a very long time. The second part is the hurdle. I can't find any information if there is a possible way to update the software via COM1. Is this even a possibility since the Netduino app is listening on the port while running?

[Chris Walker]

Hi dvanderwekke,

I'm just thinking out loud here, but perhaps you could have the app:

• use the comm port as its debug port
• wait a few seconds after boot before it opens up that comm port
• at runtime, listen for a command which causes the app to reboot the board

Then you could use MFDeployEngine in your Windows app. You'd send the "reset" command via the COM port and then switch to using MFDeployEngine. With MFDeployEngine, you'd then erase your current app and deploy a new one. Finally, you'd issue a reboot CLR command to restart your app again.

If you need an example of MFDeployEngine using serial, download the custom MFDeploy app from our Mono (Linux/Mac) forums. You can just pull the appropriate code into your app...

Does that help?

Chris

[JerseyTechGuy]

Chris, That sounds like a good working solution. So I guess I should then be able to comment out my port code (so there is no port open on the netduino) and use MFDeploy to update the software via Comm port. This doesn't seem to work. It first says "Connecting to Device..." then "Connecting to TinyBooter..." Any thoughts?

[Chris Walker]

Hi dvanderwekke,

Chris,

That sounds like a good working solution. So I guess I should then be able to comment out my port code (so there is no port open on the netduino) and use MFDeploy to update the software via Comm port. This doesn't seem to work. It first says "Connecting to Device..." then "Connecting to TinyBooter..."

Any thoughts?

You'll need to use the comm port as its debug port. If you grab the special version of MFDeploy we wrote, it'll have an option to "change deployment transport" to one of the serial ports.

Once you can successfully deploy-and-debug via serial, the rest should be fairly straightforward...

Did I answer your question correctly? Or just make things more confusing?

Chris

[JerseyTechGuy]

I had already downloaded that version a couple weeks ago and forgot about it. Tried it and it worked perfectly! Thanks again for the advice. This should work great!!

[JerseyTechGuy]

Here's the problem I found... I have used MFDeploy to Change the deployment transport to "Com1". I can then deploy and debug without an issue. The problem arises when I try to establish serial communications between my windows app and the netduino. When I send it data, I seem to get a large bucket is mis-sized data back. If I switch deployment back to USB, I can communicate over serial fine. So I am guessing the firmware is overriding the software. Is there any way to avoid this?

[Chris Walker]

Here's the problem I found... I have used MFDeploy to Change the deployment transport to "Com1". I can then deploy and debug without an issue. The problem arises when I try to establish serial communications between my windows app and the netduino. When I send it data, I seem to get a large bucket is mis-sized data back.

Are you sure that your app has taken over the COM port at that point (and consequently disabled the debug stream)?

What data are you getting back in your mis-sized data? Is it Debug.Print statements by any chance?

Chris

[JerseyTechGuy]

Are you sure that your app has taken over the COM port at that point (and consequently disabled the debug stream)?

What data are you getting back in your mis-sized data? Is it Debug.Print statements by any chance?

Chris

With no debugging stream open, my Netduino has a menu system, that I scroll down and choose "Update Software". This opens COM1 port and give's instructions to the user to click update on the Windows App. The first thing the windows app does is send a command down to turn the LCD backlight color from White to Red (this indicates we're connected) however I am getting data back to the windows app from the Netduino (which I shouldn't).

The data looks like this -> text = "SdbgV1\0|�ɹquC
\0\0\0-
\0\0
\0\0\0\0\0Data Received\r\nMSdbgV1\0��1��g��
\0\0\0.
\0\0
\0\0J\0\0"

Per your question, "Data Received" is a Debug.Print Statement.

[Chris Walker]

Try commenting out your debug.print statements. Does that help? The other data is debug wireline data... Chris

[JerseyTechGuy]

Try commenting out your debug.print statements. Does that help?

The other data is debug wireline data...

Chris

After a little more digging here is what I see...

I commented it all out and no difference, but here is what I see from the Netduino end.

When Debug and Communication are using the same Com 1 Port, my received data event still gets fired when I send a single byte of numeric "2". I put an LCD Write at the very beginning of the method right after this code. bytes is showing as 0 (zero) whereas when debug is set for USB port, it shows the proper size. This is where it bombs out and apparently the data coming back is really exception data.

        	// Get the number of incoming bytes
        	int bytes = port.BytesToRead;

Any thoughts why it would be a packet size of zero?

[Chris Walker]

Hmm, this may or may not be a scenario supported by NETMF after all. I'm sure it could be made to work by mucking around in the NETMF firmware source, but I'm a little afraid what the unintended consequences would be... Chris

[JerseyTechGuy]

Yeah, I don't think I want to mess around with NETMF and make something worse. The main thing here is I want the end users to have an easy way to upgrade the product when I release new software. This seemed like it would have been a slick way of doing it. I also wanted to have a way for the Windows Application to communicate with the Netduino to set the DS1307 clock and maybe change some other settings. Was trying to keep it to one USB port on the box. Is there any way to update the software from say an SD card? This would then be an internal upgrade instead of an external upgrade. I'll have to sit back and re-evaluate the windows app and the software on the Netduino in regards to the needed functionality. I'll have to post the project in the project section. Might claify what I am trying to accomplish here.

[JerseyTechGuy]

After doing some research, I may be leaning towards a hardware solution on this. Thinking about going with an Analog Devices ADG772: CMOS Low Power Dual 2:1 Mux/Demux USB 2.0 (480 Mbps)/USB 1.1 (12 Mbps) .

Link to ADG772 Data Sheet

I am thinking about having the ADG772 be controlled by the Netduino and have menu selections on the Netduino corresponding to these modes (IE: "Software Update" and "Configuration"). Depending which you choose, it switches the external USB to either the onboard Netduino Plus USB or to the USB on the FTDI card.

In the end I am likely going to design a new circuit board so this can be built into it.