13 replies to this topic

[Chris Walker]

These drivers are deprecated.

.NET MF 4.2 QFE2+ now supports WinUSB drivers.

Attached Files

•  NETDUINO_4.2_SIGNED_DRIVERS.zip   43.3KB   318 downloads

[Cabadam]

This means I no longer have to remember to "Disable Driver Signature Enforcement" every time I reboot my computer now doesn't it? Hurray! Also, do you know if any other particular changes are in here since the beta version of the driver? I ask because just the other night I managed to make my computer reboot at the same instant I hit the reset button on the ND+. I didn't even get an error notification. Event Viewer on my machine only had a message indicating "The previous system shutdown at 10:43:51 PM on 4/11/2012 was unexpected". And I agree with it! I had not seen anything like that since installing the beta drivers. Anyway, I'll try updating to these this weekend.

[Chris Walker]

Also, do you know if any other particular changes are in here since the beta version of the driver?

I believe that the only changes are:
1. Compiled as release-mode instead of debug drivers.
2. Digitally signed.

If you can consistenly repro any crashes with these new drivers, please let us know.

Chris

[Gutworks]

Hey Chris, I just tried the drivers and I now have my Plus back in working order. No BSOD's as of yet and now the debugger seems to working correctly. Thanks! Steve Happy Camper

[Cabadam]

If you can consistenly repro any crashes with these new drivers, please let us know.

Will do. So far, I believe it is only that one time with the beta drivers (I had STOP errors fairly frequently before the beta drivers). Aside from this one time it rebooted, the worst problem I've had with the beta drivers are it being a little quirky in terms of deployment working or not working. A few times I've had to unplug it (USB) and plug it back to get it to deploy.

I'll give you a heads up if I come across anything reproducible. Thanks!

[Valkyrie-MT]

We have compiled the .NET MF 4.2 drivers in release mode, and signed them.

Yay!

[gbreder]

Hi Chris,
I've one repro for two bugs. I've written a small program:

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace I2CIssue
{
public class Program
{
	private static I2CDevice _I2CDevice;
	private static Timer _Timer;
	private static OutputPort _OnboardLed;

	public static void Main()
	{
		_Timer = new Timer(TimerElapsed, null, new TimeSpan(0, 0, 15), new TimeSpan(0, 0, 15));

		//Initialize the I2CDevice with a dummy configuration
		_I2CDevice = new I2CDevice(new I2CDevice.Configuration(20, 100));
		_OnboardLed = new OutputPort(Pins.ONBOARD_LED, false);

		Thread.Sleep(Timeout.Infinite);
			
	}

	private static void TimerElapsed(object state)
	{
		var bytesToRead = new byte[2];

		var configuration = new I2CDevice.Configuration(0x48, 100);
		_I2CDevice.Config = configuration;

		var transactions = new[] { I2CDevice.CreateReadTransaction(bytesToRead) };

		_OnboardLed.Write(true);
		Thread.Sleep(50);
		_OnboardLed.Write(false);

		Debug.Print("Beginning read on disconnected I2C bus...");
		// Execute the read or write transaction, check if byte was successfully transfered
		int bytesTransfered = _I2CDevice.Execute(transactions, 200);

		Debug.Print("Bytes transferred '" + bytesTransfered + "' at " + DateTime.Now);
	}
}
}

This code should try a read on a disconnected I2C bus. All pullups have to be removed as well. After 200ms the read should be aborted with an exception or an result of zero byte or something (_I2CDevice.Execute(transactions, 200)). But on Firmware 4.2 RC4 the Netduino stops completetly. Now you should try a deploy to such an unresponsive board. And while Visual Studio is desperately trying to deploy the application to the unresponsive Netduino, hit the reset button on the board. Your computer will reboot immediately.

I hope my repro steps can be reproduced by others.

Regards
Guido

[Coskun]

My issues with being have to unplug and replug 1000 times is resolved with this driver.

[Coskun]

My issues with being have to unplug and replug 1000 times is resolved with this driver.

However, I started getting BS if I have to unplug because the Netduino becomes unresponsive.

I highly recommend you to solve this issue because either unplug/replug or BS makes it not such a pleasant experience to play with Netduino (Plus). If the time spent for fixing the things takes longer than playing with your toy, it does not become a "hobby" anymore.

I see that tons of people are having similar issues. It should not be hard for you to reproduce these issues on your computer or a test environment.

If this issue is not solved (which is the case for a while), I will seriously consider looking for other brands of development boards.

Netduino is the best of the boards I have found so far but development issues with this driver are too much sometimes, it can make me post you this message at 3:24am.

I hope you understand.

BR.

[Chris Walker]

Hi Coskun,

If this issue is not solved (which is the case for a while), I will seriously consider looking for other brands of development boards.

Thank you for the feedback. This is an issue with .NET MF, not with Netduino...but obviously it affects both. It also seems to effect every other NETMF-based board out there.

Microsoft spent a significant amount of time trying to reproduce the issue--but couldn't get consistent blue screens. Maybe it would crash every once in a while...but not often enough to be able to grab debug data.

My hope is that we can create a consistent test case that works on any computer--and then Microsoft can dig in and we can create updated drivers which fix the edge cases. As a backup plan, if we can create a consistent case on one computer here, we can ship that computer off to Microsoft. We just need to be able to crash on demand Or at least on a regular basis.

The new 4.2 drivers seems to have fixed most crashing drivers...which is a good thing, but I wish I could get the ocassional crash to become more consistent as it would make things easier to debug.

Chris

[Chris Walker]

Hi Guido,

I hope my repro steps can be reproduced by others.

Can you reboot your computer a few times and make sure that this crashes every time? If so, we can narrow down why this is happening for you...and this could really help.

I'm hoping we can find a crash scenario which _doesn't_ relate to another NETMF bug (such as an I2C glitch). But only because I'm afraid it will not be reproducible once the other bug is fixed...

Thank you so much for the great reporting here...

Chris

[Coskun]

Hi Coskun,

Thank you for the feedback. This is an issue with .NET MF, not with Netduino...but obviously it affects both. It also seems to effect every other NETMF-based board out there.

Microsoft spent a significant amount of time trying to reproduce the issue--but couldn't get consistent blue screens. Maybe it would crash every once in a while...but not often enough to be able to grab debug data.

Please do not get me wrong. It is neither blaming you or threatening you with buying one of your competitors. If Netduino was not a good product, I would have gone for another board anyway. I share my (negative) feedback in order to improve your product and nothing else. Otherwise, I appreciate your intelligence and efforts behind Netduino.

However, considering that the result is the most important thing rather than what is the reason behind the bug, it just simply affects the satisfaction of your customers.

I know, it can be very painful to work with MS guys sometimes. They won't really investigate a bug (well, they will up to a certain point) but what they usually hope is not to be able to reproduce it so they can close the issue. I have come across to that scenario so many times, I could not blame you.

What is more, I am spending 5 hours a week for Netduino and I face problems with the driver a thousand times. I just cannot and would not believe in that MS could not find enough debug data. Just does not make sense...

You are right about many things being fixed. I can deploy without any problems with the new driver. It is just BS if I really have to unplug while deploying.

Hopefully, some of the next releases will solve the BS issue.

BR.

[gbreder]

Hello Chris, I've rebooted my computer by Netduino reset several times. To reproduce the error the step "Slowly count to ten" has to be inserted between "Hit deploy in VS" and "Press reset button on Netduino". I've attached the solution with the I2C issue and my "msinfo32" system information to show my hardware and installed drivers. (In case you need to by a computer to reproduce the error... ) I hope this helps. If you need further information feel free to contact me. Regards Guido

Attached Files

•  repro hardware.zip   59.55KB   10 downloads
•  I2CIssue.zip   6.36KB   5 downloads

[gbreder]

Hi,
at last I've posted the issue in Codeplex. Everyone should try the repro and vote for it.
If something should be added or changed please send me a message.

Guido

P.S. There is another bug I'm interrested in: Read on a disconnected I2C Bus takes forever. The foundation of the bluescreen repro is this bug. Everyone can also try the repro, vote for it, send me his or her results (with board type and firmware) and of course his or her opinion...

Guido