@ JREndean - thanks for the tip. I downloaded both files. the DFU process went smoothly.
But i still get the same error.
A lot of sleepless night are coming for Gus :o :o
Please for clairification:
Which NET MF 4.2 : RTM or is ok also RTM QFE1 ?
FEZ hydra needs â.sigâ files for 4.2 fw update ⌠where they are ? :â(
I think itâs better to stay with 4.1. Lot of problem rising.
@ dobova, thatâs the reason for calling it beta. Itâs not advised to download it unless you want to help getting rid of the bugz.
I canât help in any case, just stopped at Hydra firmware update ⌠
It seems that if you create new gadgeteer app v4.1, in any case vs 2010 try to deploy version 4.2.0 modules, so without fw update canât do anything.
UPDATE: After manually disinstalling and reinstalling of the âGHI. NET Gadgeteer SDK v4.2.msiâ, deleting and recreating gadgeteer app for 4.1, modules seems to deploy correctly now on 4.1.8 Hydra fw.
I forgot about QFE1, but original post is updated to point to QFE1, which we all should be using.
@ ianlee74
The Gadgeteer.dll file was broken up into multiple files, so SoftwareI2C is now located in Gadgeteer.DaisyLink. Add a reference to that and you should be fine.
Thanks, Steven. All red squiglies are gone. 
Is there a firmware update also required? There was no mention of it in the original post. I tried the new UpdateFEZHydra.bat and this is what I got in my log.
[quote]-I- Waiting âŚ
-I- TCL platform : Windows NT
-I- SAM-BA CDC 2.10 on : windows
-I- Retrieved arguments from command line :
-I- argv 0 : at91sam9rl64-ek
-I- argv 1 : TinyBooterLoader.tcl
-I- argv 2 :
-E- Connection at91sam9rl64-ek not found
-E- Connection list : [/quote]
Hi Ian,
What did you put in the command line?
:-[ Been so long since weâve had to do this through the command line, I forgot to specify the com port. Iâll try again tonight. :-[
@ ianlee74 - I think if you leave .NET Microframework 4.1 installed you would still have had the 4.1 targetframework available and in VS you would have been able to switch between versions in each of the projects properties.
@ jdal - The firmware I installed was located at %ProgramFiles(x86)%\GHI Electronics\GHI OSHW NETMF v4.2 SDK\FEZ Cerberus\Firmware\Cerberus_4_2_0_0.dfu. If you used the same one then I do not know what could be causing it. You could always get the MF code from Codeplex and step into it to find out where it is throwing that exception :).
More update: Fw 4.2 finally is up on FEZ Hydra, using the .sig files of 4.1 fw version.
Now can make some test on 4.2.
Sure, but then I wouldnât be following Gusâ instructions and I might end up testing 4.1 instead of 4.2 
@ JREndean - thanks for this tip, that was the problem. I downloaded the dfu from the FEZ Cerberus Developer WIKI. They should probably update wiki.
Though the first time i ran the debugger it got hung up and i pressed the reset button on the board and got the blue screen of death on Win7. Never seen that befor on Win 7. rebooted the computer and tried it again. same results. Tried it a 3ârd time and changed the USB port to where it was plugged into and then it worked normally. Have no idea what the heck that was all about.
@ jdal: [quote]Though the first time i ran the debugger it got hung up and i pressed the reset button on the board and got the blue screen of death on Win7.[/quote]
The same hapend to me several time, i thing it is a bug in the cerberus driver, so far the workaround is to take careful notice when you unplug or reset the cerberus. If deployment and/debuging is in progres you have to stop it before reseting. Debugign seems OK most of the time, but if i do reset the device while deploying i get 100% BSOD. You can cancle the deployment by CTRL + BREAK key combination.
@ Pavel Dvoracek - whew, glad i am not the only one. I am going to put this to bed until some kinks get worked out.
I think itâs a bug in the 4.2 somewhere as I had the same with Hydra.
I accidentally created code that caused a tight loop. This caused the debugger to no be able to connect to the hydra to download a new app. Resetting the board during the deploy attempt caused BSOD three times in a row. Also Win7.
I got a BSOD once with a Cerb40.
It shouldnât be possible for the Cerb40 to cause it, from what I understand. Something weird hardware-side, coupled with a bug or poor error handling on the computer-driver side, is my theory.
Is it still late May for the Panda IIs?
1 Like
A BSOD for me to report, as well, with a Cerberus. The firmware update went fine. I deployed and ran a simple LED7R module animate program just fine. Tweaked the program and started to deploy again. As sometimes happens, VS stalls at âpreparing to deployâŚâ, or Iâm just impatient. On other boards I hit the reset button and that usually jumpstarts the deploy. In this case, I got a BSOD. I saved the dump details if that will help. It is reproducible.
edit - I recreated the project from scratch and the program would not deploy, stalling at âpreparing to deployâŚâ as above. I reflashed the Cerberus and now it behaves.
There seem to be a 4.2 BSOD problem on all devices. We are trying to see what we can do to help Microsoft find the problem. It is vs2010 related not device related.