@ twospoons - I seriously doubt you have the same problem. Please check what SDK you have for QFE2 and download the latest SDK release couple days ago. Let us know how it goes please.
I just installed the new SDK (I did these exact same steps for the first board). Followed all the procedures outlined in the update.
This my second attempt.
Opened up my second brand new bee, started up visual studio, tried deploying. It says the firmware is not correct.
I closec visual studio. Updated the tiny boot loader and the firmware.
Start visual studio and try deploying. It attaches to the debugger
Attaching deployed file.
Assembly: JadDayGad (1.0.0.0) Attaching deployed file.
Assembly: Gadgeteer (2.42.0.0) Resolving.
The debugging target runtime is loading the application assemblies and starting execution.
I detach the debugger and try deploying a second time then I get the error message posted in the previous post. Iām now have two bricked bees which I cannot deploy to.
It does seem to be able to attach the debugger when I deploy; I see output messages from a timer I had in code. However, it cannot interrupt to deploy.
Was it a gadgeteer project or netmf?
Gadgeteer. Just as an FYI I had somewhat similar issues before but was able to resolve them by pressing reset or what not (if I had a tight loop). But as I said, this code doesnāt have anything but a timer which outputs a message to debug every 10 seconds.
Attached are the versions installed.
Tried a netmf project. Same issue and same behavior. I do notice that it displays;
------ Deploy started: Project: USBizi Application1, Configuration: Debug Any CPU ------
------ Deploy started: Project: USBizi Application1, Configuration: Debug Any CPU ------
An error has occurred: please check your hardware.
Request failed
Source: Microsoft.SPOT.Debugger
Stack :
at Microsoft.SPOT.Debugger.Engine.Request.Wait() in c:\depot\current\CLIENT_V4_2\Framework\Debugger\Engine.cs:line 761
at Microsoft.SPOT.Debugger.Engine.SyncMessage(UInt32 cmd, UInt32 flags, Object payload, Int32 retries, Int32 timeout) in c:\depot\current\CLIENT_V4_2\Framework\Debugger\Engine.cs:line 1993
at Microsoft.SPOT.Debugger.Engine.GetAssemblies() in c:\depot\current\CLIENT_V4_2\Framework\Debugger\Engine.cs:line 2928
at Microsoft.SPOT.Debugger.Engine.ResolveAllAssemblies() in c:\depot\current\CLIENT_V4_2\Framework\Debugger\Engine.cs:line 2941
at Microsoft.SPOT.Debugger.VsProjectFlavorCfg.Deploy() in c:\depot\current\CLIENT_V4_2\Framework\CorDebug\VsProjectFlavorCfg.cs:line 869
at Microsoft.SPOT.Debugger.VsProjectFlavorCfg.<Microsoft.VisualStudio.Shell.Interop.IVsDeployableProjectCfg.StartDeploy>b__0() in c:\depot\current\CLIENT_V4_2\Framework\CorDebug\VsProjectFlavorCfg.cs:line 634
========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========
Notice the deploy line twice? Not sure if that is significant or not.
Do you have issues if you make a netmf project?
See above post.
I can reproduce this over and over by re-flashing the device. I do notice that the first time you deploy (the only time you can deploy) it does not display any messages from the debug output (if you do a Debug.Print).
Try this please, create simple vanilla netmf and remove all references and deploy, tell us if that worksā¦
This is exactly what I asked for but my question maybe wasnāt clear.
Deploy a netmf project with no changes please.
Created a MF Window Application. I can deploy that over and over without issues.
A couple of observations; this app is only 4616 bytes.
Gadgeteer is a whooping 90316 bytes.
The firmware.hex file for the cerb (non-ethernet) is from 8/22/12 2:32PM, all the other files are from 8/24/12 12:18PM (tiny boot loader and so forth).
The firmware.hex for the ethernet version has the ācorrectā time stamp.
The first time I deploy I get this;
Found debugger!
Create TS.
Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0) Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1)
Assembly: Microsoft.SPOT.Net.Security (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Touch (4.2.0.0) Attaching deployed file.
Assembly: GadgeteerApp2 (1.0.0.0) Attaching deployed file.
Assembly: System.Net.Security (4.2.0.0) Resolving.
The debugging target runtime is loading the application assemblies and starting execution.
And nothing. Iāve set breakpoints in Program.generated.cs / Main(). Itās never triggered.
Again, this should be pretty easy to reproduce. Iāll keep on trying different things.
Iām running windows 7 64bit.
Iām setting up a clean windows 7 vm install now to see if that helps.
i started a VM with Windows XP 32 bit installed that never had NetMF install on it, so i grabbed the latest beta and installed everything, started MFDeploy, erased my Spider, next started VS2010 created a new Gadgeteer project hit deploy and it failed with same exact errorā¦
So now i know this is not related to my BOX ā¦ any other ideasā¦ what could cause the EMX to refuse accepting Deploymentā¦ This one is for GHI to answerā¦ i really need to knowā¦
Edit: and when i deploy a NETMF Project with nothing on it but the default templateā¦ it deploysā¦ as long as the size is below 1KBā¦ but if i add a single line of code for example a Thread.Sleep(-1); that requires referencing System.dll the application fails to deployā¦ WHY??? so this sounds like a MEmroy Problem in my Spider where either i have bad sectors or something ā¦ please talk to meā¦ iām loosing it here.
Iām pretty sure itās not the memory unless all my Cerb bees have memory issues. The code will deploy and run, but I can only deploy once.
Seems like this issues should have been pretty easy to detect during QA.
I know itās beta and all so Iām hoping for a quick hot fix. Iām totally stuck on my project.
twospoons,
when you are updating the firmware what is the exact process that you followed? Did you remember to create from map first and erase the chip?
Yes. I use STDFU tester. Click create from map, check erase, click go. Check download and load DFU file click go.
I have done this with other boards and earlier versions of the SDK / drivers without problems.
I reconnect the board, load up mfdeploy pick both hex files and click deploy.
I do feel that something is up with the hex files since the date stamp is obviously wrong on the firmware.hex.
Check screenshot. The sig file is even from 8/24.
@ twospoons
Have you tried to use a different USB port on your hub/computer? Perhaps try to change the USB cable that is connected to the device.
I have tried different cables, different boxes, different main boards.
Since I can deploy once (that ALWAYS works), I would expect this NOT to be an issue with cables or what not. The code also runs when I deploy once.
It ALWAYS fails on the second attempt to deploy.
I do not have any debugging tools to dive in further to figure out why it fails.
I can however replicate this very easily. Have you guys been able to replicate this (FEZ Cerb bee) using the latest SDK?
We have tried to replicate the issue of not deploying here but we have been able to deploy and redeploy multiple times with no issue.
@ Aaron
I am also having this issue (Except I canāt even deploy once)
I noticed the date of 8/24 on the sig file also while the hex is 8/22
Do you guys test with all version of visual studio or just express? Could that make a difference?