The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
my Netduino 2 is stuck in BootLoader mode and its driver will not respond
hi, i cant seem to work my netduino 2 due to a driver malfunction, if it matters i am running it on a windows 7 operating system and it has version 4.2. when i plug it in, i have to hold the onboard_BTN or it will not show up
in my control panel, this problem started while debugging a program that uses pins 5V,GND,D13,D12,D11,A0,A1 and A2. the blue onboard_LED is permanently on, and i do not use it in my program, even when my netduino is in bootloader mode, when running my program it gives me the message "Error1Device not found or cannot be opened - USB:Netduino". if you understand the problem, please write back
i have the same problem more often than I would like to.
I'm currently trying to get my N2(+) devices running, and found out, that the N2-series is much more fragile when it comes to handling data (currently only evaluated the serialport).
When the driver does not respond, in 99% it's a "Buffer overflow" message.
How to identify?
You try to deploy new assemblies via Visual Studio and the debugger does not attach
After deploying new assemblies, the device restarts on it's own every few seconds
Messages like "Device not found" or similar shown when trying to deploy new assemblies
Detach any debugger and open the "MFDeploy" tool from the Micro Framework SDK. Select "USB" and after connecting the USB cable press the "Ping" button a few times. The "buffer overflow" messages or any Debug.Print output can be seen there.
How to solve?
If VS shows message that it's waiting for the device to reboot, after deployment was successfull. Just unplug and replugin the USB cable, in most cases the debugger automatically attaches.
If even deployment is not possible with messages like "Device not found" or similar. Following sequence works for me in most cases. Unplug USB cable. Rebuild in VS (F6). Clean Solution. Start deployment with debugging (F5), without the device attached. Now the console in VS should show something like "Iteration 1, Iteration 2...", now plugin the USB cable again. This should at least make it successfull to deploy the new assemblies. If the debugger then does not attach, try step 1.)
If step 1.) and 2.) do not work try to erase the app via the "Netduino Update Tool", in 50% of the cases this helps, if not for me the only solution was redeploy the firmware.
Altogether I'm not really happy with the new N2(+) series, by only introducing a Thread.Sleep(100) after reading the buffer on a SerialPort I got the buffer overflow problem again, while on the N1(+) series it works without any problem for month. Also working with the DataReceived event on the SerialPort causes a "buffer overflow" working with the same code in a simple while() did not make any problem.
Netduino 2 is faster so, ironically, code runs faster and buffer overflows could occur more easily.
This is one area in NETMF where it might be better to discard the overflow data (gracefully degrade) rather than shut you out. Would you like to file a bug report on netmf.codeplex.com, and I'll be sure to discuss it with the NETMF team? If there are no obvious side-effects, we could tweak the core NETMF runtime to suppress that shorter-term as well.
Thank you very much for your feedback on this. We want both NETMF and Netduino to be awesome platforms for you--and this really helps us identify and smooth out the rough spots.
sure the N2 is faster but from my point of view there must be another problem. Imagine the following:
- GPS sensor sends data with 115200 baud and 10Hz updates (Adafruit Ultimate GPS v3), so the amount of data is always the same regardeless of N1 or N2.
- N1 which is slower, so cannot read the data so fast --> I would expect the buffer overflow, but works fine.
- N2 which is faster, so can read the data faster, to make memory free for new incoming data throws a buffer overflow...
=> Again the source of the data behaves the same. The code is the same, just the Netduino is different.
If you want that I file a bug, I can do this - but is discarding really the solution?
What I'm missing is some kind of advice how things should be done - I tried several implementations of reading data from the serial port here from the forum and none of them is by default stable, all of them ran into the same problem after seconds or less than 5 minutes ;-( (and buffer or allocation problems only occured on N2)
If really discarding the data is the only way, than I think it would be somehow helpful to throw an exception which can be caught via code once a buffer overflow was detected, that you at least know what happened. Because currently it's just a lot of effort to find out what happened and get a fixed version again on the device (see my last post)
So this is on incoming data only? Are there any other threads running? If you just create a simple program with a DataReceived event and you pull in all the data there...does that keep up?
If you're just capturing data, Netduino 2 should perform as fast or better than Netduino 1.
Also...are you by any chance doing a lot of Debug.Print calls in your application? If you've installed the 4.3 SDKs, the NETMF SDK on the PC slows things down a bit more when dealing with older versions of NETMF due to the new timings instituted for 4.3.
- Windows 7 with NETMF 4.3 (QFE1) and Netduino SDK 4.3, I deinstalled the older versions before
- VS2012 Premium (VS2013 Premium installed but not used for Netduino development - if this info is relevant)
When I make a simple program without any Threads and just reading the data from the Serial Port even then I get errors.
I attached a small solution which does nothing else then configuring the Hertz and Baudrate for the GPS receiver and then starts waiting for data.
In the "Main" there are two options when calling the Start-method. One works using a while loop and one using the DataReceived Event.
The while loop works better but even there I get the following (can be seen when doing a Ping with MFDeploy)
Both occur multiple times
- Failed allocation for 5 blocks, 60 bytes
- Buffer OVFLW
When running with the DataReceived event MFDeploy shows only
- Buffer OVFLW
The Thread.Sleep at the beginning of the main is used to be able to redeploy stuff, because as soon as the Buffer OVFLW happens
it's a problem.
The implementation for the N1(+) does a lot more than just reading the data from the serial port, is using threads and works fine.
My question is the following, how can I prevent these errors? Is there anything I can do in the coding to detect that it might happen sooner or later or to clear something to get rid of it?
Hi,I have purchased a netduino plus 2 lately and i was going through 'Getting started wth netduino excercises'.Something weird has happend to my netduino.Its not powering up.The power led and the blue led comes on and goes off. VS2012 aslo showing device not found.Have i damaged my netduino,worried,Please help.