Hi lor3,
Can you try using COM2 for debug really quickly, instead of COM1?
COM1 shares an IRQ with the reset pin. So using COM1 may be causing odd interrupts. The reset register should filter those...but we may need to add some extra protection.
COM2 is on its own IRQ.
Chris
How to deploy over COM
Started by BanksySan, Apr 19 2012 08:34 PM
24 replies to this topic
#21
Posted 19 November 2012 - 10:20 PM
#22
Posted 20 November 2012 - 12:01 AM
Can you try using COM2 for debug really quickly, instead of COM1?
Just tried with COM2, exactly the same (reset on boot).
#23
Posted 20 November 2012 - 01:07 AM
Hi lor3,
Okay, just did some research. The Transport change resets the device. Which makes sense, since NETMF needs to allocate those resources during boot.
Try putting the following code before the transport change...
The first time you run the app, press the button to change the transport. Then once it reboots, erase the current app (using the new transport port) and you'll be good to go.
Right now...if you're already working on COM2 now, just press ERASE in MFDeploy and erase the current app. If the debugger can't connect quickly enough for that (since it may already be rebooting) you may need to start from scratch (using the pushbutton trick, above).
Chris
Okay, just did some research. The Transport change resets the device. Which makes sense, since NETMF needs to allocate those resources during boot.
Try putting the following code before the transport change...
InputPort port = new InputPort(Pins.ONBOARD_BTN, ...); while (port.Read() == false);
The first time you run the app, press the button to change the transport. Then once it reboots, erase the current app (using the new transport port) and you'll be good to go.
Right now...if you're already working on COM2 now, just press ERASE in MFDeploy and erase the current app. If the debugger can't connect quickly enough for that (since it may already be rebooting) you may need to start from scratch (using the pushbutton trick, above).
Chris
#24
Posted 20 November 2012 - 01:43 PM
The first time you run the app, press the button to change the transport. Then once it reboots, erase the current app (using the new transport port) and you'll be good to go.
Fantastic, works like a charm. I've tried with COM1 and COM2 and both work fine so the reset IRQ doesn't appear to be a problem. The only thing I did notice is that MFDeploy doesn't work via serial (Ping/Erase) but VS can deploy and debug fine.
Thanks for your help Chris.
#25
Posted 20 November 2012 - 04:28 PM
OK all is working well... a slightly unrelated question; is Microsoft.SPOT.Hardware.UsbClient supported by the Netduino+ 4.2 firmware (or standard Netduino)? I'm getting an UnsupportedException from the UsbController constructor so I'm guessing not?
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users