I don’t seem to be able to download my program from VS consistently. More often than not after I hit the “Start Debugging” green arrow I get the following
Loading start at 202d5eb8, end 2030534c
Assembly: mscorlib (188.8.131.52) Assembly: Microsoft.SPOT.Native (184.108.40.206) Assembly: Microsoft.SPOT.Security.PKCS11 (4.3
.1.0) Assembly: System.Security (220.127.116.11) Assembly: Microsoft.SPOT.Hardware (18.104.22.168)
Assembly: Microsoft.SPOT.Graphics (22.214.171.124) Assembly: Microsoft.SPOT.TinyCore (126.96.36.199)
Assembly: Microsoft.SPOT.IO (188.8.131.52) Assembly: System.IO (184.108.40.206) Assembly: Microsoft.SPOT.Hardware.Usb (220.127.116.11)
Assembly: Microsoft.SPOT.Hardware.SerialPort (18.104.22.168) Assembly: Microsoft.SPOT.Touch (22.214.171.124)
Assembly: Microsoft.SPOT.Ink (126.96.36.199) Assembly: Microsoft.SPOT.Hardware.PWM (188.8.131.52)
Attaching deployed file.
Assembly: CPF_43 (184.108.40.206) Attaching deployed file.
Assembly: System (220.127.116.11) Attaching deployed file.
Assembly: GHI.Pins (18.104.22.168) Attaching deployed file.
Assembly: GHI.Hardware (22.214.171.124) Attaching deployed file.
Assembly: Microsoft.SPOT.Net (126.96.36.199) Resolving.
GC: 2msec 292416 bytes used, 66813348 bytes available
Type 0F (STRING ): 24 bytes
Type 15 (FREEBLOCK ): 66813348 bytes
Type 17 (ASSEMBLY ): 30180 bytes
And VS hangs after the “Ready” with no other output. My Raptor is inside a sealed pressure housing and I have to go through a non-standard, non USB, non impedance controlled oceanographic connector to get my 3 meter USB cable connected. However, I don’t remember seeing this problem nearly as often (maybe never) before I upgraded to 4.3. Any thoughts would be greatly appreciated.
Thanks - Gene
Haha - My activity feed just said “Gene started Trouble… Earning 10points”. I’m not sure we should be rewarding this kind of behaviour.
I also have that same problem sometimes . Can you cycle the power?
Does you application allows the CPU to go into idle state? (do have sleeps or waits in all threads?)
A simple program like tis:
usually blocks the Debugger from attaching for deploy.
@ hagster, you are the latest in a long line of people who think “Trouble” is my middle name.
Power cycling doesn’t help, rebooting my PC doesn’t help. I can’t say for sure but I’ve tried running FezConfig and if I ping the Raptor and check for updates that my solve the problem on random occasions. At this point, nothing has worked and I can’t download/debug anything.
I’ve worked very hard to write non-blocking code with no infinite loops or long thread.sleeps. I may have something hidden away but this appears to be a new problem that has only cropped up since my upgrade to 4.3. I do have a Debug.Print(“Program Started”) line as the first line in my code and I’m not seeing that in the output window.
Is there a way to use FezConfig to erase just my application?
Yes there is an erase application button in Fez Config. I think it’s on the deployment tab.
I normally put a shortish sleep as the very first thing that happens or put a quick check for an IO pin and if it’s set then start a long sleep.
I’m afraid this is a G400 specific thing that you’ll just have to live with
@ Simon - I’m pretty sure that means you’ve experienced the same thing. Any idea what the issue is? Is there no solution other than cross my fingers and keep trying?
Debugging issues hit me since day-1 when I got the G400 Beta Test Kit, and never left. Unfortunately
For me personally, USB3 causes lots of trouble, but I saw people complaining even on USB2 ports. So I guess that depends a lot on the developing system itself…
BuiltIn ethernet is a nightmare, too, even worse than USB3…
Well that’s disappointing. Luckily as soon as I posted my last comment, I was able to start debugging again. Very frustrating.
Is there a way to bring this issue to someone at GHI’s attention and get their input on the issue?
there’s another thread here that says in the last 24 hours GHI identified a core USB issue that they’ve addressed. Possibly related to what you’re seeing. Raising this here is enough to get it to GHI’s attention but you may not always get that acknowledged
The sdk is in its final testing stage. Possible release on Monday.
I’ve been trying to download/debug my program for about an hour now without success. I’ve tried a billion combinations of power cycling, hitting the green Start Debugging arrow, Fez Config, reloading the booter and the firmware and still can’t download a program and start debugging. I really hope the new release comes out Monday and fixes my issue.
@ Gene - No program is able to be deployed? Not even a new empty one? Does this happen with multiple Raptors?
After a fairly careful and time consuming set of tests, it turns out the Raptor board inside the sealed pressure housing failed for some unknown reason. Reloading the bootloader and the firmware didn’t fix it. Installing a new Raptor board was the final fix.
Since it is of some importance to understand the various failures I experience, I’d value any input. The only thing I can think of (other than bad karma, gremlins and malevolent spirits) is ESD.
From Wikipedia “Failure modes of electronics”:
Catastrophic failures require the highest discharge voltages, are the easiest to test for and are rarest to occur. Parametric failures occur at intermediate discharge voltages and occur more often, with latent failures the most common. For each parametric failure, there are 4-10 latent ones.
 R. W. Welker, Ramamurthy Nagarajan, Carl E. Newberg (2006). Contamination and ESD control in high-technology manufacturing. John Wiley and Sons. p. 68. ISBN 0-471-41452-2.
This might be a case, actually. I also discard G400D modules once in a while, maybe every 1 of 10. For whatever reasons, they[em] just sometimes don’t work right[/em]. Since I am really under difficult time schedule, I do not try to find out what is wrong with them, although I would really love to…
@ Gene - You were successfully able to redeploy the bootloader and firmware on the failed device though?
@ John - No, I pulled a brand new Raptor for the go to sea prototype in the pressure housing. The formerly bricked Raptors have been relegated to shore side testing as a background task. I’ve asked the guy who may have unbricked them for more details.
This problem has reared it’s ugly head again. As I mentioned in a previous post, I installed a new Raptor and everything was fine for a week or so. However, I’m stuck in that place where I can’t download programs or connect with FezConfig. Here’s what I know:
I know the last program I downloaded starts up when I power cycle the Raptor since my program spits up a status message every 3 seconds over Bluetooth as it cycles through its states and I can see the messages on TerraTerm.
If I connect my USB cable through the non-USB connector on my pressure housing to the Raptor inside the pressure housing I can see it enumerate as a G400 device on my PC. While this connection is not standard USB it has worked fine for a year with both Spider and Raptor boards.
FezConfig doesn’t see the G400.
VS2012 sometimes sees the G400 and sometimes doesn’t. If it sees it, it will try to start downloading but never finish.
My program is a state machine and does a Thread.Sleep at the end of every cycle so it shouldn’t be stuck in some endless loop using 100% of the CPU.
Any help will be greatly appreciated as this is a complete roadblock to progress at this point.
@ Gene - Is there any way you can run your program on a known-good raptor outside of its housing and ideally without any custom wiring for awhile and see if it fails?