.NET MF 4.2 QFE2+ now supports WinUSB drivers.
Drivers for .NET MF 4.2
#1
Posted 13 April 2012 - 04:12 AM
.NET MF 4.2 QFE2+ now supports WinUSB drivers.
#2
Posted 13 April 2012 - 01:56 PM
#3
Posted 13 April 2012 - 02:22 PM
I believe that the only changes are:Also, do you know if any other particular changes are in here since the beta version of the driver?
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
#4
Posted 13 April 2012 - 02:52 PM
Twiiter: https://twitter.com/Gutworks
#5
Posted 13 April 2012 - 03:32 PM
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!
#6
Posted 13 April 2012 - 05:08 PM
We have compiled the .NET MF 4.2 drivers in release mode, and signed them.
Yay!
#7
Posted 13 April 2012 - 08:23 PM
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
#8
Posted 14 April 2012 - 12:11 AM
#9
Posted 14 April 2012 - 12:33 AM
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.
#10
Posted 14 April 2012 - 01:40 AM
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.If this issue is not solved (which is the case for a while), I will seriously consider looking for other brands of development boards.
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
#11
Posted 14 April 2012 - 01:42 AM
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 hope my repro steps can be reproduced by others.
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
#12
Posted 14 April 2012 - 01:51 AM
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.
#13
Posted 14 April 2012 - 07:49 AM
Attached Files
#14
Posted 21 April 2012 - 09:38 PM
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
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users