- Netduino Forums
- → Viewing Profile: Posts: rhamer
Community Stats
- Group Members
- Active Posts 29
- Profile Views 5875
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
-
Gender
Not Telling
-
Location
Melbourne Australia
User Tools
Friends
rhamer hasn't added any friends yet.
Posts I've Made
In Topic: When will V4.2 really be released and working?
20 June 2012 - 09:32 AM
In Topic: When will V4.2 really be released and working?
19 June 2012 - 11:46 PM
Here's a template I knocked up per my earlier description. Give it a whirl and tell me what you think. Couple of key points:
- You only get the kill switch in debug builds. In release builds no handler is attached to the SW1 so it functions as a reset switch.
- In debug builds the watchdog doesn't reboot, it fires an OnStall event which gives you a chance to find out what stalled.
- You have to explicitly register methods for the co-op manager. I had intended to use custom attributes to mark up methods with their intervals and implicitly register them, but NETMF doesn't do custom attributes. The template produces two sample co-op methods to illustrate registration and the required method signature.
- If a co-op task runs for more than a minute the watchdog detects it as stalled.
- Coop mult-tasking only ever runs one logical process at a time so it is effectively single threaded.
- This is an application watchdog.
An application watchdog operates at a different level of abstraction to the framework watchdog already present. If you wrote this:
static void Main() { Thread.Sleep(Timeout.Infinite); }the built-in watchdog would not detect it because the NETMF framework has not locked up.
Thanks for your effort Arbiter, I will try it out as soon as I can and let you know how I go.
Regards
Rohan
In Topic: When will V4.2 really be released and working?
19 June 2012 - 11:40 PM
Hi Rohan,
So sorry that you're having issues with .NET MF 4.2 and the beta firmware.
The reason we haven't taken the firmware out of beta is because .NET MF 4.2 hasn't met our quality criteria yet. The one outstanding issue is the blue screens with the proprietary NETMF driver.
We have been working with Microsoft on the issue since summer 2010. It was actually an issue with .NET MF 4.1, but we created a workaround which fixed the issue most of the time. This workaround no longer works with the changes made in .NET MF 4.2, so both Secret Labs and Microsoft have been doing extensive repro cases to determine the root cause.
After much effort, it was determined that there the issues are driver-related and specific to certain computer+software configurations, and that they seem to affect all .NET MF 4.2-based firmware images using USB to some extent.
So Microsoft is working hard on a new, permanent resolution to the issue. They're replacing the proprietary NETMF drivers with standard WinUSB drivers. WinUSB is a much better solution because it's built into Windows and therefore well-tested across a wide number of devices and computers.
The new WinUSB support is scheduled to be available by mid-July in beta form, and sometime this summer in the QFE2 patch to .NET MF 4.2.
Full details:
http://netmf.codeple...m/workitem/1049
Once the community reports that the QFE2-based WinUSB drivers have fixed the BSOD glitches in relation to .NET MF 4.2, we'll move the Netduino firmware rapidly to RTM.
BTW, we implemented some hardware tweaks in the Netduino Go hardware to reduce the BSOD occurances to .NET MF 4.1 levels (which is why we were able to ship it with .NET MF 4.2 support). We're still not happy with the occurance of any driver crashes, so we're really looking forward to transitioning the full line of USB-capable Netduinos to WinUSB.
Thank you for your patience while Microsoft finishes up their work on the new drivers. So sorry for any pain you are encountering on your computer in relation to .NET MF 4.2 and the beta firmware. We're listening, and many people are working hard behind the scenes to make .NET MF 4.2 a strong platform with RTM firmware.
Chris
P.S.
If you want to switch your Netduino to serial debug/deploy, you can use D0/D1 or D2/D3 and a USB TTL adapter with the 4.2 firmware. You could also use an RS232 shield. This will allow you to write code without any possibility of driver-related BSODs.
Hi Chris,
I appreciate the sentiment, but I don't think you really understand the scale of these problems. To be blunt, commercial development against V4.2 is unworkable.
Add to this the annoyance I have when I see talk about other products being designed such as the GO when there are existing products that simply dont work. In my view, any and all available effort should be focused on sorting out the existing issues, rather than new products. All you are going to end up with is a bunch of products that half work, rather than a couple that are really good. i.e exactly how it is now.
There are at least 3 show stopping problems with V4.2 right now.
1/ BSOD
2/ Deployment Fails
3/ VS2010 crashes when hovering over a variable during debugging.
There are probably more, but I cant get past these to see any further.
I know in past posts you have pointed to various problems falling into various camps, but to me I don't care, I just want it fixed. It feels like I'm constantly being told it's not my problem, thats some other guys issue. I dont know what parts fall into who's area and I don't want to. I just want it to work.
I realise I'm being a bit grumpy about this, but you have to realise I'm not in this for the journey, I need to get to the destination as quickly as possible, and that is the suposed main spruking point of .NET MF. I need to use it as part of a robust reliable commercial product, and not some pet egg timer project.
To give you some idea, I have the whole product designed, and prototypes built. In the attached photo of an early prototype you can see that the Netduino is only a small (but significant) part of the project. If I have to scrap it and move to something else, it will be a major setback, but I equally can't continue on this way.
Please can you provide a proper realistic list of known issues and when they will be fixed, with a commitment to sorting out the issues with existing products, before using resources for new development.
BTW I cant use serial for deployment, as I'm using both serial ports as part of the project.
Regards
Rohan
In Topic: When will V4.2 really be released and working?
18 June 2012 - 03:18 AM
... As for a way to reliably trigger a deployment hang this seems to work for me on any PC (win7 x64) i try it on.
If other people can hang their deployment that way at least that will be a step towards getting a fix for this issue, as AFAIK its the reproducibility of the issue that is the sticking point on this issue...
- Deploy code first time no problem
- Deploy code n times no problem
- Stop debugging and restart (either through a reset or power cycle) the ND and let the program run i.e. debug build running in a more production like context
- Try and redeploy/attach debugger, deploy hangs reseting or unplugging ND causes a BSOD (windbg analysis says either memory corruption or vista driver error) waiting about 5 mins raises a deployment error dialog in vs...
Nak.
That is pretty much the trigger for me as well.
Going on what others have said here, it appears to be when the program is executing on it's own you cant break into it to deploy another.
something else I have also seen is, it sort of half deploys before failing and leaves the Netduino no longer able to receive a new deployment, or even free run the old one, even with the USB disconnected and power cycled.
I have seen this because my project has an LCD screen for output and during the program init it writes a few lines of stuff. When it gets half updated, I only get some of the text on the screen, and the netduino just appears to freeze, even ignoring the reset button sometimes.
Regards
Rohan
In Topic: When will V4.2 really be released and working?
14 June 2012 - 11:18 PM
- Netduino Forums
- → Viewing Profile: Posts: rhamer
- Privacy Policy