Hey Chris you couldn't help a guy out could ya?

I'm using a servo off an old helicopter (link) and no matter what I do, I can't get it to move using code. If I apply power to it, after about 2-3 secs it spins all the way to the right, is that what it's supposed to do?

I'm very new to all this in case you couldn't tell

The blue Netduino boxes are actually shipping boxes, not product boxes. Most resellers will ship the Netduino in its black conductive bag alone...they know how to protect electronics for shipping without the extra box.

That said, the blue boxes do look nice. So a few resellers buy them as an extra bonus for their customers.

Got mine from CoolComponents, and it came without the box in a jiffy bag, if someone had put any pressure on the package those headers would have snapped stright off

Luckily it was all good, loved the colour scheme of the board and bag/label (how awesome does the board look powered on!), and the tag sticker was a fantastically geeky little touch

Arecon,

If you get bootloader build info when you ping the device, do you get "Pinging...TinyCLR" or "Pinging...Netduino by Secret Labs LLC"?

If you get the latter, the .NET MF runtime was unable to boot. The blue LED should also still be on... The remedy for this is to erase the current Netduino app through MFDeploy and, if that doesn't work, to reflash the Netduino .NET MF firmware.

Chris

I got "Pinging...Netduino by Secret Labs LLC", however the LED was off. How do you go about erasing the app through MFD? Is it as simple as clicking erase? If so I will reflash the Alpha and play around with it a bit more tonight (I only had about 20 mins with it last night after reflashing .2).

I have the same problem running 4.1.0.3 and the QFE1 bugfix.

Running on XP SP3, virtual PC is installed but not running, and VS 2010 Express is running from the main OS.

Pressing the button on the netduino doesn't fix it.

Waiting till deployment is complete, VS gives a message along the lines of "The debugging target is not in an initialized state, rebooting..." but will sit there forever.

If I unplug and replug the netduino when VS gives the "The debugging target is not in an initialized state, rebooting..." message, debugging goes ahead normally.

Also, similar symptoms sometimes occur when stopping debugging, VS will sit there forever waiting for it. Unplugging the netduino hastens things along a bit.

Have you tried reflashing .2? That was what sorted it for me. Also does your MFDeploy hang upon flashing the Alpha like mine did?

That's the Netduino resetting. We might need to increase the timeouts on your machine.

If you go into "Programs and Features" in Windows' Control Panel, does the .NET Micro Framework SDK say "QFE1" after it?

That's probably okay. Only one program can talk to the Netduino at a time. If Visual Studio still has a connection to the Netduino, MFDeploy won't be able to ping it. Once Visual Studio gives up, can MFDeploy ping the Netduino successfully?

Chris

Yes it's the QFE1 version. Visual Studio doesn't give up, I have to force close it from task manager as otherwise it will quite happily sit there for more than 5 mins doing nothing . After I kill VS, the device is still unpingable.

After MFDeploy is force closed (after hanging on connecting to tinybooter), when I ping the device it returns bootloader build info, and it doesn't do that normally?

Edit: After reflashing .2 it seems to be working fine so far? Very strange, if you want me to go back to the Alpha for more testing just let me know I'd be happ to help. I'll be sure to post back if it crops again in the meantime, thanks for the help!

hmm, not sure really, are you using the same usb cable? Maybe worth retrying the flashing again but to the more stable .2 version, but not really sure, it did take me two attempts to get it to flash fully - it is a bit hair raising seeing the memory getting erased!
Could well be the OS or drivers, take it you've tried reinstalling the sdk, rebooting etc.

Not sure I can help much, other than mention I'm on 64 bit windows 7 ultimate, 64 bit cpu, and a uniwill laptop - rebranded acer, esystem etc., with the express version of visual studio 2010 C#, if that gives you any pointers.

Failing that find a reason to borrow your machine from work

Same USB cable, will try .2 again next. Yes it was slightly scary ! It still hangs when reflashing it now, so something is amiss!

Will try the reinstall after testing .2 again, hope I dont have too though!

Arceon,

Are you running inside of a VM (Parallels, VMWare, VirtualBox, etc.)? What operating system are you running?

Also, are you running the .NET MF 4.1 SDK or last week's "QFE1" bugfix release?

Finally, if you push the pushbutton on the Netduino when Visual Studio hangs, does that prompt Visual Studio to finish deploying?

Chris

I used the downloads on the Main Download page (the 1,2,3 section) for both home and work.

Work: Windows 7 Ultimate 64Bit, VS C# Express 2010, 64bit SDK (Non-VM)
Home: Windows XP 32bit, VS C# Express 2010, 32bit SDK (Non-VM)

When it hangs, the LED lights up for around 2-3 seconds, then goes off, nothing happens after that. If I press the button while hung, the LED comes on and stays on, but Visual Studio remains hung.

Also I can't ping the device from MFDeploy while VS has hung.

Are you sure the newer firmware flashed fully? It may appear to have - but actually have hung, only if you get both progress dialogs followed by a fair bit of output in MFDeploy (along the lines of sectors, read, written to) will it actually have been updated.

Yes I got the full output with all the attributes and assemly info printed out, the weird thing is it worked perfectly fine whilst I was trying it out at work, but upon getting home these problems started (shame I cant find the time to develop for it at work ). Could it be IDE/OS related?

Ok I've flashed the Aplha firmware, and now it hangs on:
The debugging target is not in an initialized state, rebooting...

There was a hairy moment during flashing when the MFDeploy tool locked up on connecting to tinybooter, and I had to start the process again. Should I try reflashing?

Edit: Tried reflashing, is still locking up on connecting to tinybooter

Arceon,

Have you tried the v4.1.0.3 ("alpha") firmware? We're about to upgrade a subset of it to "beta" status, and would love your input (you can move back to 4.1.0.2 if it doesn't work well for you).

Chris

I'll give it a go now and let you know how i get on!

I'm still having this issue even with the newer firmware any ideas on what else might cause it?